The Signal #068 — Dakota’s read on the AI news that actually matters to people running a business.

The pace feels great. Then one Monday morning it doesn’t.

That is the short version of a post that has been circulating among engineering and product circles this week. It describes a senior engineer sitting down with a fresh coffee, opening their laptop, and finding seven pull requests (proposed code changes ready to merge into the main codebase) waiting for review. The first one: plus 24,506 lines, minus 3,938 lines. More code changed since Friday than the whole team used to ship while the senior engineer was on a two-week holiday.

The post is not really about code volume. It is about what happens when speed outpaces understanding.

What happened

Florian Herrengt published “AI is removing the middle class of software engineering” and it landed hard with practitioners. The argument is not that AI tools are bad. It is that they removed what he calls the speed limit.

Here is the scenario he describes. A team uses AI agents to generate code quickly. Someone opens a 25,000-line pull request. Someone else reviews it without fully understanding it and merges it. A new database structure gets added because it was easier to prompt for than to think through. Kafka (a high-throughput messaging system typically reserved for large-scale data pipelines) appears in the stack without a clear reason why. Serverless functions multiply. Weeks later, a bug surfaces. The engineer who built the feature cannot explain where the data comes from without opening a Claude conversation and watching a wall of text scroll by.

The quote that stuck with me: “You can’t afford bad engineers anymore.” His point is not harsh for its own sake. It is practical. When a weak engineer produced 500 lines a week, the damage was slow and catchable. When that same engineer can produce 20,000 lines in an afternoon, the damage compounds faster than any senior person can review.

And the debt does not look like debt. It looks like a working feature. Until it doesn’t.

Why it matters for operators

You do not have to run a software company for this to land. If you run an e-commerce operation, a SaaS product, a healthcare platform, a real estate tech tool, or anything that ships software to paying customers, your engineering team’s output is your product. What accumulates in that codebase is your operational risk.

The classic picture of technical debt (code shortcuts that make future work harder and more expensive) always existed. But it moved slowly enough that competent teams could manage it between cycles. The post describes what happens when the accumulation rate outpaces the comprehension rate. A person can generate 20,000 lines of code in an afternoon, but you still have to sit and understand what those lines actually do. The generation speed went up. The understanding speed did not.

For an operator, that gap is a liability. It shows up as bugs that take four attempts to fix. It shows up as a migration plan that nobody can scope because nobody fully knows what the system does. It shows up as a senior engineer who spends more time untangling agent-generated decisions than shipping new value.

What most people get wrong

The easy read of this story is that AI coding tools are the problem. That is not what the post argues, and it is not the right takeaway.

The actual problem is process, not tooling. The engineer who opened the 25,000-line pull request should have stopped the agent long before it reached that size. The reviewer should have declined to review something that large rather than giving in. The person who added a major new infrastructure layer should have been able to explain exactly why it was needed, in plain terms, before a single line was written.

AI amplifies whatever engineering culture already exists. A team with strong review habits, small pull requests, and clear ownership of decisions will use AI agents to go faster with discipline. A team that already merged first and asked questions later will now do that at five times the speed.

The middle class the post refers to is not a salary band. It is the layer of intermediate engineers who used to learn by doing slow, human-paced work. They read other people’s code. They got their PRs rejected. They had to explain their decisions out loud. AI shortcuts that entire feedback loop. The skill gap does not disappear. It just gets hidden under generated code until something breaks in production.

The closing lesson

Speed is not the same as progress. Any operator who touches a technical team right now needs to be asking one question: does your team understand what it is building, or are they prompting and hoping?

The answer determines whether your AI investment is compounding or just deferring a bill.

If you want to think through what strong AI adoption actually looks like inside an operation, start at xovionlabs.com.