CD Projekt Red Called It Silosis, Almost Lost the Studio Over It

December 10, 2020. Cyberpunk 2077 launches on PS4 and Xbox One and it does not run. Cars spawn inside buildings. NPCs T-pose through cutscenes. The game crashes on base consoles so often that Sony pulls it from the PlayStation Store seven days later, something that had never happened to a AAA title at that scale. CD Projekt’s stock loses more than half its value over the following year. The company settles a shareholder class action for $1.85 million⊕ .

CEO Adam Kiciński later admitted what happened, in language executives rarely use about their own decisions: “We underestimated the scale and complexity of the issues, we ignored the signals about the need for additional time to refine the game on the base last-gen consoles. It was the wrong approach and against our business philosophy. On top of that, during the campaign, we showed the game mostly on PCs.”

That’s not an excuse. It’s a description of what shipped on purpose.

What Was Actually Broken

The easy story is that CD Projekt Red rushed a buggy game and got punished for it. That story is true and it explains almost nothing. “We shipped bugs” doesn’t tell you why a studio that made The Witcher 3, one of the most polished open-world games of its generation, couldn’t catch cars floating above roads before ten million people did.

The traffic AI wasn’t broken because nobody tested it. It was broken because it was never built as traffic AI. Developers had patched it together from animation triggers rather than real pathfinding logic, a workaround stacked on a workaround until the workaround was the system. REDengine 4, the studio’s proprietary engine, had been built for The Witcher 3: linear, story-driven, one character walking through hand-placed environments. Night City needed dense simulation, verticality, thousands of interacting agents. Instead of rebuilding the engine’s foundations for that job, the team kept adapting the old tools. The technical debt compounded until nobody could say with confidence what the game would do at scale.

That’s an engineering failure with an organizational cause. Internally, staff had a name for the deeper problem: Silosis. Art teams, code teams and quest teams built in isolation. Level designers placed objects in the world without talking to the rendering team, and the mismatch showed up later as a performance bottleneck nobody had budgeted time to fix. There was no automated test infrastructure to catch what the silos missed, so QA leaned entirely on manual playtesting, which cannot scale across the number of ways a system this large can fail. When COVID forced the studio remote overnight, the silos calcified. Many developers never saw the game running on a base PS4 until the final weeks before launch, because the reporting structure had been quietly prioritizing PC performance data over console data the whole time.

So when leadership says they “ignored the signals,” the signals existed. They just never made it up through the silo structure in a form anyone with launch authority had to look at directly.

The Rebuild Nobody Announced as a Rebuild

CD Projekt Red didn’t fix Cyberpunk 2077 by hiring more QA. The studio spent the better part of two years dismantling how it built games, and it started with the planning model. The old approach was waterfall: define the whole game up front, then execute department by department in sequence, art handing to code handing to quest design with minimal overlap. It’s the same structure that produced the silos in the first place, just formalized into a process. CD Projekt moved to agile, and not just for Cyberpunk. The next Witcher game, still early in development, adopted the same shift.

The concrete unit of that change was something the studio started calling strike teams. Designers, artists and engineers worked daily on one quest or one system together, instead of routing decisions through department leads who rarely spoke to each other. Art director Pawel Mielniczuk has said the silo problem was the specific thing strike teams were built to kill. Quest director Pawel Sasko has described making Phantom Liberty and the accompanying 2.0 update as something closer to group therapy for a team that had spent two years absorbing public failure, which is a strange thing for a studio to say out loud and a more honest one than most postmortems manage.

None of it worked immediately. CD Projekt didn’t pretend otherwise. Cyberpunk: Edgerunners, the Netflix anime tie-in, gave the game a real audience bump in 2022. Patch 1.6 followed. But Cyberpunk 2077’s Steam reviews didn’t cross into “Very Positive” until July 2023⊕ , two and a half years after launch, days before Phantom Liberty shipped. The studio earned that back one patch and one quest at a time. It didn’t declare a comeback and wait for the internet to agree.

The clearest signal of how seriously CD Projekt took the structural diagnosis over the technical one: REDengine itself is being retired. The new Witcher game is built on Unreal Engine 5. After years of patching a foundation that had outgrown its original design, the studio decided the foundation had to go, not get patched again.

What REDengine’s Retirement Actually Admits

A quality problem gets fixed with more testing, more time, more review gates. A structure problem gets fixed by changing who talks to whom, and when, and what happens to bad news between the person who finds it and the person who can act on it. CD Projekt Red’s launch failure looked, from the outside, like the first kind. Leadership’s own account of it, and the strike-team rebuild that followed, describes the second kind.

Most teams default to treating every recurring failure as a quality problem, because quality problems have a familiar toolkit: add a checklist, add a review, add a QA pass. Structure problems don’t have a toolkit. They have an org chart. Admitting the org chart is the problem means admitting the last several fixes were aimed at the wrong layer. That admission is expensive in a way a sprint retro never captures.