Background & Context§
The democratization of code generation through large language models (LLMs) like Claude, GPT-4, and Cursor has fundamentally altered the economics of software development. What once took weeks of planning and collaboration can now be scaffolded in hours by a single developer with a prompt. While this surge in productivity promises to make teams more efficient, it also introduces a critical failure mode. According to a recent essay by Florian Herrengt, AI is not merely augmenting software engineering—it is actively destabilizing teams with weak engineering cultures, accelerating the accumulation of technical debt, and widening the gap between skilled architects and mere "prompters." The result? A middle class of software engineers—those who could implement but not architect—may be squeezed out entirely.
The News: What Happened Exactly§
Herrengt paints a vivid picture of a 2026 Monday morning: a senior engineer returns from a weekend (not a holiday) to find 7 pull requests awaiting review, one of them containing +24,506 and -3,938 lines of code, accompanied by an AI-generated description. The team has produced more changes in a single weekend than they used to in weeks. This is the new normal in AI-augmented development: anyone can prompt a coding agent for a few hours and open a PR, but the review process remains a bottleneck. Senior engineers are now expected to untangle decisions made by AI, often without clear rationale. When asked about a design choice, a coworker might respond by sharing a link to a Claude conversation—a sprawling, back-and-forth transcript where the model confidently recommends an architecture, apologizes, changes its mind, and eventually settles on something. The actual reasoning is buried in 15 rounds of prompt iteration, but the engineer who wrote the code may not understand it themselves.
The core thesis is that AI makes projects with weak engineering culture fail much faster. In the past, the speed of human implementation acted as a natural brake on technical debt. A developer might introduce a questionable database denormalization, but it would take weeks to propagate across the system. Today, an AI agent can add dozens of tables and services in a single afternoon. The problem compounds: once data is stored in those tables, the migration to correct the design is hard, risky, and costly. In the meantime, more PRs keep flowing in, each adding more abstractions, more layers, more complexity. By the time the senior engineer has untangled one bad decision, five more have been merged. The codebase becomes an inscrutable pile of "unnecessary complexity," as Herrengt calls it, that no single person understands. Attempts to fix bugs with AI often fail because the AI itself cannot comprehend the convoluted system it helped create. "Let's just turn on ultracode and ask it to double-check?" becomes a desperate plea, yet the AI returns confident but wrong answers.
The economic impact is profound. Herrengt argues that six-figure salaries in tech hubs like London or San Francisco were never justified by mere implementation skills—anyone could turn a spec into code cheaply elsewhere. Those salaries were for judgment: knowing what to build, how to manage complexity, and making decisions that scale. With AI now handling implementation, the value of pure coders drops. Simultaneously, the cost of hiring a "bad" engineer who relies on AI without understanding it skyrockets, because they generate complexity at a rate that drains the team's attention. The middle ground—engineers who were competent but not exceptional—becomes increasingly untenable. Good engineers become more valuable because AI amplifies their ability to move fast, while bad engineers become liabilities because they produce unmanageable debt.
This dynamic is not abstract. Herrengt describes the "tragic aspect" that, to the untrained eye, AI-generated code appears functional. A junior developer can pull a branch, test it, and see it work. So they keep going, adding more features, until the project reaches a point where no one knows how it works. Users start reporting bugs that resist repeated AI-based fixes. The engineering team sits side-by-side, watching a wall of text stream from Claude, uncertain if any of it is true. They have lost the ability to reason about the system because they never fully understood it in the first place. The project becomes a debt sinkhole, too expensive to fix and too tangled to maintain. The author suggests that fixing such a system would require "a colossal amount of work" and is impossible to justify to management.
Historical Parallels & Similar Incidents§
This phenomenon echoes earlier technological shifts that lowered the barrier to code production without improving judgment. In the early 2000s, the rise of web frameworks like Ruby on Rails and PHP's simplified deployment enabled a flood of so-called "script kiddies" to build database-driven websites with minimal training. Many of those projects suffered from massive security vulnerabilities (e.g., SQL injection) and structural debt, leading to costly rewrites or abandonment. The difference was that those frameworks constrained the architecture—they forced a certain structure (MVC, etc.) that provided guardrails. AI agents, by contrast, offer no such constraints; they generate arbitrary architectures based on vague prompts, leading to unprecedented variety and inconsistency. The result is a more chaotic codebase than anything seen in the framework era.
Another parallel is the "no-code/low-code" movement of the 2010s. Platforms like Airtable and Webflow allowed non-developers to build applications, but they often created unmaintainable monsters. A 2019 Gartner report predicted that by 2024, 80% of technology products would be built by those outside of IT, leading to "shadow IT" and unstructured systems. The core issue was the same: the tools made implementation easier but did not impart the discipline of software engineering—version control, testing, architectural pattern. When those applications needed to scale, they collapsed. Similarly, AI coding assistants remove the need for syntax knowledge, but they do not teach design principles. As Herrengt notes, "If you lack the judgment required to evaluate the LLM's recommendation, asking for more judgment doesn't solve the problem."
The most poignant parallel is the history of offshoring. In the 1990s and 2000s, many tech companies outsourced development to lower-cost countries to save money. The immediate result was cheaper code, but quality suffered because the offshore teams lacked context and collaboration with the rest of the business. Over time, companies realized that the hidden costs of communication and technical debt outweighed the savings. The lesson was that software engineering is not just about writing code; it's about shared understanding and collective ownership. AI tools today are like an offshore team that never sleeps and works for free, but they lack the contextual awareness of the product vision, the users, or the existing codebase's internal logic. This leads to a similar loss of context, but at a much faster pace. A 2023 study by the University of Cambridge found that AI-assisted developers introduced 15% more bugs than their unassisted counterparts, highlighting that the speed of production does not compensate for the lack of understanding. Herrengt's scenario of the 2026 Monday morning is the logical endpoint of this trend: a system nobody owns, held together by prompts rather than knowledge.
The lesson from history is clear: tools that amplify productivity without also amplifying engineering discipline lead to a day of reckoning. In the past, that day came years later, giving teams time to course-correct. With AI, the day comes in months or even weeks. To survive, companies must invest in strong engineering culture—code reviews, architectural governance, and continuous refactoring—and, more importantly, hire engineers who can think critically about AI outputs. As Herrengt concludes, the bar for employability is now "whatever the current best model du jour can do." Those who cannot rise above that level will find themselves competing with algorithms that work for free. The middle class of software engineering is not disappearing because AI replaces them; it is disappearing because their lack of judgment makes them a net negative in a world where code is cheap. The future belongs to those who can steer the AI, not just ride it.