Why generative AI won't create 10x developers

Long before GenAI agents were used in software engineering, we already had the concept of the '10x Developer'. They weren’t exactly ten times faster, but they did deliver value far more effectively and efficiently than average. 

But what did it take to create a high-performance team producing high-quality software at a high pace and with a high frequency of change? Enabled by culture and guided by principles, they followed practices that aimed for engineering excellence and superior product quality. It was an environment where design decisions and complex endeavors performed by developers weren’t downplayed as mere implementation details. These developers deeply cared about the software they built, and their genuine love for the craft made it natural to empathize with problems and delight customers.

Since then, what changed? Today, the obsession with short-term efficiency and the rush to have GenAI agents write all our code has shattered the implicit contract that made such excellence possible. The promise to turn every engineer into a 10x developer is, in fact, taking away the hands-on practice required for active cognitive modeling, leaving code to become legacy software the moment it’s written. By stripping away the joy of creation, we forced our best engineers to dissociate, abandoning mastery and joining the race toward faster but inherently mediocre software.

The fallacy of coding speed over code quality

High performance was never about raw typing speed. Teams that excelled did so by practicing continuous delivery protected by automated guardrails and architecting for change. They maintained a healthy balance between customer needs and system needs, keeping entropy in check with capabilities that were fundamental to the system building it even if they didn’t add immediate value. Above all, high performance relied on human principles: high trust, integrity, psychological safety, autonomy, mastery and a shared sense of purpose.

Maintaining these human principles when building software with GenAI is notoriously difficult. Agents lack integrity and were built unethically. They lie, take shortcuts that can cause harm and carry all the biases embedded in general human knowledge. We can grant them autonomy, but never a sense of purpose. The need to orchestrate them is today widely acknowledged, but what rarely is is that doing so requires a return to the friction of bureaucratic and pathological organizations this time by wrapping agents in rigid low-trust harnesses. These are the kind of environments described in Westrum’s Organizational Typologies, ones that early Agile and DevOps practitioners fought so hard to transform.

These harnesses are a far cry from lightweight CI/CD checks. To try to keep probabilistic models from breaking production, we build brute-force verification loops that rely on consuming millions of tokens from language models on each and every change. Instead of empowering developers with guardrails that foster flow, we’ve created an environment of continuous friction.

Passive engagement atrophies engineering skills

While technical inefficiencies may improve over time, the developer's detachment from the systems they build needs to be solved now. Burdened by micro-interruptions, superficial depth, endless proofreading and constant context switching, developers can no longer maintain the flow state required to engage with complex problems. Actively owning the system design but passively engaging with the code creation strips away mastery. It even affects those senior engineers who chose to stay hands-on precisely because they are passionate about building software.

This passion is not a luxury; it’s the stimulus that pushes the limits of creativity. Designing data structures, algorithms, state machines, concurrent processing and domain models requires active practice. Without it, these skills will atrophy, leaving senior developers unable to discern what good looks like and junior engineers without the opportunity to ever learn. Yes, these developers could channel their creativity into optimizing the agentic process that builds the system instead, but for many such work may feel lack meaning, leading to disengagement and possibly even burnout.

Some argue that writing specifications replaces this hands-on thinking, but natural language specs are inherently ambiguous. Great developers consolidate their thinking while writing code, as they lack sufficient context beforehand and lose flow state afterward. By passively reviewing output rather than engaging in the execution process, developers lose visibility into design decisions ostensibly made by the agent generating code. Those aren’t mere implementation details; they’re fundamental learnings that help us retain essential system knowledge.

Thinking, specifying and owning high-level architecture aren’t enough; hands-on practice is essential if we’re to properly master cognitive processes. By constantly bypassing synchronous active feedback loops, developers forget how the system works almost as soon as it is shipped. I’ve witnessed brilliant engineers who could fluently explain software built years prior, yet freeze when asked about code delivered by an agent the week before, a direct symptom of treating code merely as output, rather than the mental model we examine next.

Code is a mental model, not just output

This loss of individual mastery creates a systemic problem, as software engineering is fundamentally a collective cognitive effort. Yet some engineers seem to have accepted a shift toward coordinating the engineering process rather than executing it. Expecting one person to manage the output previously generated by an entire team is a fallacy, as humans cannot cope with the pace of information, decisions and communication required to effectively design and build an iterative, complex solution.

Software engineering is a social endeavour. The creation of a model tells a story. Design documents can capture key milestones, but they cannot capture the tacit learning that connects cross-functional teams and external stakeholders. This is why swapping team members while this story is being told is almost always disruptive. High-performance teams need to be stable to become effective and efficient; when they are, the shared mental model becomes embedded in the fabric of the organization, not unlike culture and institutional memory.

As Peter Naur argued in his 1985 paper 'Programming as Theory Building', the source code, not the documentation, helps communicate the mental model held by the people who built it. When this shared theory is lost, we call the software a “legacy system.” When GenAI writes the code and silently makes fine-grained design decisions, the software becomes legacy immediately upon creation. Neither the developer nor the agent learns.

Claiming code is disposable ignores the reality of live, complex systems where you have to implement unspecified behaviors, handle interface contracts or work around security and operational constraints. As formal language theory demonstrates, it’s not possible to precisely specify these complex behaviors in natural language. Doing so requires an unambiguous, context-free grammar. We can achieve this through a programming language. Even when code is raised to a higher abstraction like domain-specific languages (DSLs) or formal specifications, developers are still programming, building the model and telling the story.

Because we’re still fundamentally programming, all the cognitive and social constraints required for effective system building remain strictly necessary. As my colleague Valentina Servile observes: “if code is to remain a black box because an agent can do it faster, programmers will just have to increase the structure of their specs instead. At some point, we're no longer replacing programming, we're simply programming in a worse, more ambiguous programming language”.

Where GenAI fits and where it fails

The utility of GenAI in software engineering isn’t one-size-fits-all. For simple domains, boilerplate generation or glue code like infrastructure scripts, AI agents can be highly effective. Even in core domains, generating code using GenAI when prototyping or exploring, as per Kent Beck's 3X model, is also very useful. Likewise, low-stakes internal software or some simple generic domains can tolerate the trade-offs of agent-driven generation where we have simply accepted that mediocre is good enough.

However, beyond CRUD operations and simple tasks, GenAI code generation is simply not fit for purpose. In complex brownfield systems with subtle domain models, agents cannot anticipate unforeseen edge cases or unspecified behaviors. While automated harnesses can enforce architectural guardrails or cross-cutting concerns, they cannot guarantee system coherence, completeness or correctness. The developer must still specify and verify every single invariant themselves, requiring the very craftsmanship and deep understanding that passive code generation strips away.

This gap between simple and complex domains exposes a fundamental difference in execution. While both humans and LLMs produce non-deterministic outputs, their underlying mechanisms are entirely distinct. Agents rely on stochastic pattern matching, looping through brute-force iterations at the cost of millions of tokens and substantial inference compute. Human developers leverage intentional, abstract thinking to build a coherent mental model of the solution space. 

As an orthogonal mathematical analogy, agents attempt to reach system coherence through Monte Carlo convergence, whereas human software engineers follow gradient descent, using intentional feedback and domain intuition to steer straight towards an optimal architecture.

Cognitive debt and AI-first engineering

All of these factors combine into a heavy burden that is overwhelming engineers who were once called '10x Developers'. They're surrendering to cognitive debt not by choice, but for survival. After spending their careers fighting against Ivory Tower architecture to build high-performance teams, they are now forced to become Ivory Tower engineers themselves, just to justify the ROI of agents writing software on their behalf.

We have stripped away the joy and flow state of writing code, therefore it is unrealistic to expect developers to step down from this new Ivory Tower without a meaningful cognitive incentive. Senior developers who chose to remain hands-on late in their careers probably never had an interest in managing people, yet now they are expected to manage agents.

GenAI is an impressive technology, but it is still in its infancy. Several organisations are trading their culture and their people for a premature bet. Senior talent is leaving because the work has fundamentally changed, and their professional identity is devalued by corporate environments obsessed with raw output and velocity proxy metrics. These engineers are seeking environments where architectural oversight, deep technical thinking and software craftsmanship are still prioritised over prompt engineering and context management. 

What retains great talent is never ping-pong tables or extremely high salaries, it has always been autonomy, mastery and a shared sense of purpose. While the industry will eventually find a balanced equilibrium, many organisations will spend years recovering from the cultural and technical debt they are accumulating today. Just as with Agile and DevOps, the vast majority will once again take years to actually reap the rewards.