---
title: "Software Is Now Written Faster Than Anyone Can Review It"
description: "AI lets engineers generate code faster than colleagues can review it. The result is systems nobody understands and a labour market splitting in two."
dek: "An essay by a working software engineer argues that AI coding tools have removed the natural speed limit on bad architectural decisions. The people who still have to understand the system are the ones absorbing the cost."
published_at: "2026-08-13T17:40:08.843Z"
updated_at: "2026-08-13T17:40:08.843Z"
tags:
  - "AI"
  - "Labour"
  - "Business"
source_url: "https://blog.florianherrengt.com/ai-removing-middle-class-software-engineering.html"
source_domain: "blog.florianherrengt.com"
canonical: "https://hex37.com/software-is-now-written-faster-than-anyone-can-review-it"
---

For most of the history of [software engineering](https://en.wikipedia.org/wiki/Software_engineering), there was a hard physical limit on how much harm a team could do to its own product in a week: somebody had to type it. Bad decisions were made constantly, but they arrived one keystroke at a time, slowly enough that a colleague reading over the work had a fair chance of catching them before they became load-bearing.

That limit has been lifted. The question worth asking is what happens on the other side of it — whether a team can now damage its own systems faster than it can repair them, and what that does to the value of the people doing the work.

A [widely read essay](https://blog.florianherrengt.com/ai-removing-middle-class-software-engineering.html) by a working engineer sets the change out as two Monday mornings. In 2020, the worst case for a senior engineer was returning from a fortnight's holiday to find the codebase had drifted: colleagues had waved each other's work through, someone had bolted on infrastructure nobody could justify. Recoverable. In 2026, the same drift arrives over a single weekend, and nobody went anywhere.

## The arithmetic of a queue that will not clear

The unit of collaboration in modern software is the pull request, or PR: a proposed batch of changes that a colleague reads and questions before it becomes part of the live product. It is the industry's main quality control, and it depends entirely on someone having the time and the ability to read.

The essay's scene is a reviewer opening the first of seven PRs and finding roughly 24,500 lines added and 3,900 removed, with a summary of what it does that the AI wrote itself. This is the load-bearing fact of the whole argument, and it is arithmetic rather than opinion. A person with an AI agent can produce twenty thousand lines of code in an afternoon. Reading twenty thousand lines and genuinely understanding what they do takes exactly as long as it always did. Generation got faster by an order of magnitude; comprehension did not move at all.

What that gap creates is a textbook case of moral hazard — the situation where the person taking a risk is not the person who pays for it. The engineer who prompts an agent for an afternoon banks the speed. The cost lands on whoever has to hold the resulting system in their head, which is someone else, later.

## Decisions that arrive without an argument attached

The immediate casualty is architecture — the set of choices about how a system is shaped, which are cheap to make and enormously expensive to unmake. In the essay's account, a team acquires new database tables deliberately duplicating data across them because that made the queries easier to write, plus [serverless functions](https://en.wikipedia.org/wiki/Serverless_computing) and Kafka, a heavyweight system for shuttling data between services. None of it is accompanied by evidence that it was needed.

Previously, decisions of that size were preceded by people sitting in a room disagreeing. Now they appear inside a diff, already implemented, retrospectively justified by machine-written prose. Engineers who spend their working weeks on the receiving end of this report it as their central problem: one describes hours a week spent pushing back on infrastructure changes made through an AI agent, including having to book a call with a senior developer to explain why the change he had confidently made simply could not be operated the way he had built it. The code ran. That was never the question.

## Ten minutes to add a table, quarters to remove one

Here is where the compounding starts, and why "just get the AI to fix it" does not close the loop. Asking a model to add a set of tables and columns to a database takes minutes. Removing them, once real customers' data is sitting in them, takes a migration plan, a rollback plan for when the migration fails, and a guarantee that the system stays available for people paying to use it every day, with no orphaned references left pointing at rows that no longer exist. The asymmetry is brutal, and no model changes it.

Meanwhile the queue keeps filling. By the time one bad decision has been untangled, five more have been merged. This is [technical debt](https://en.wikipedia.org/wiki/Technical_debt) — the deferred cost of a shortcut, which accrues interest — accumulating faster than any team can service it.

## Nobody can say where the data comes from

Follow that far enough and you reach the scene the essay builds towards: a recurring bug, four failed attempts to fix it, and an engineer who cannot say where the data on his own feature originates. His answer is to open a chat with a [large language model](https://en.wikipedia.org/wiki/Large_language_model) and read its confident output alongside his colleague, neither of them able to judge whether any of it is true. Asked later why a piece of code exists, someone sends a link to a conversation transcript and, when asked which part to read, says: probably all of it.

At this point the honest options are gone. Repairing the system would cost more than anyone could justify to management, and would likely be undone within months. So the team keeps shipping.

That outcome is the opposite of what most people assume. The comfortable belief is that a weak engineering culture given powerful tools will expose itself quickly and fail, clearing the way for something better. It does not. It produces enough working software to look successful indefinitely while the underlying complexity becomes irreversible. The failure is invisible, and invisible failure has no natural end.

One caution is worth registering, and it comes from engineers who maintained large systems before any of this existed: the nostalgia is overdone. There was often nobody to explain anything, the documentation did not exist, the tests were not written, and you dug through the code alone. For the essay's argument to hold, understanding need not have been widespread before — only that it existed somewhere in the building and could be handed on. If it never really did, AI has changed the rate of decay rather than its kind.

## What the six figures were actually paying for

The economic conclusion follows directly. If what a company needed was someone to turn a specification into working code, it could have bought that cheaply, from anywhere in the world, for the last two decades. It paid London and San Francisco salaries for something else: judgment about which system to build, and the ability to keep its complexity from compounding. That is the part implementation speed does not touch, and the part that just became scarcer.

So the market splits. Engineers with judgment get more valuable, because AI lets them move without needing a layer of people beneath them doing the typing. Engineers without it get more expensive than they are worth, because their mistakes now scale. The employability bar becomes, roughly, whatever the best available model can already do — and clearing it means contributing something that does not come free with a prompt.

Which leaves an unanswered question, and the people already living it are the ones raising it. Entry-level and mid-level roles have rarely been harder to get, which means the route by which a junior engineer became a senior one has largely closed. The judgment that is now the only thing worth paying for was built by years of doing the implementation work that no longer exists as a job. Nobody has yet explained where the next set of people who understand these systems is supposed to come from.