A true story about speeding up the wrong things

The original 40-minute talk is available on WeAreDevelopers.

This is genuinely useful, but it also exposes something that was easier to ignore while producing code required more effort: writing the implementation was never the whole engineering problem.

The difficult part increasingly sits around the code. A change has to belong in the system. An abstraction has to earn its place. An existing implementation may be ugly but sufficient. A requested feature may work and still not justify the additional surface area it creates. None of these questions are new, but their relative cost becomes more obvious once another implementation is almost free.

This also changes what productivity can look like. Generated code is visible and countable. Choosing not to build something leaves much less evidence of activity, although it may be the better engineering decision. The same is true when somebody avoids an unnecessary abstraction before it reaches the repository. Once production becomes cheap, volume becomes an increasingly poor proxy for progress.

If code becomes cheap and understanding stays expensive, systems do not become simple. They become easier to complicate. The factory got faster. The map did not get better.

Traditional software failures often provide something obvious to attack: the code does not compile, a test fails, an exception appears, or the behavior is visibly wrong. AI can produce something coherent enough to invite trust before that trust has been earned.

Fluent uncertainty is a dangerous user interface.

That changes the nature of review. The reviewer has to determine which assumptions entered the implementation, which constraints were available to the model, whether an abstraction solves a problem the system actually has, and whether a locally plausible solution fits the architecture around it. None of this becomes cheaper merely because the first draft appeared quickly.

In real projects, review time is finite and deadlines do not disappear when generation gets faster. An implementation that looks reasonable and already passes obvious checks therefore has a considerable advantage over one that visibly looks unfinished. “Good enough for now” can enter the repository easily, and repositories are very bad at remembering which parts were supposed to be temporary.

The important question is what a successful loop actually establishes. A green test suite tells us that the implementation satisfied the checks encoded in that suite. That is useful evidence, but it does not provide a design rationale. It does not tell us whether the implementation fits the surrounding system, whether its assumptions are sound, whether the added complexity is justified, or whether the checks cover the part of the problem we actually care about.

An agent can therefore discard several failed approaches and eventually produce a passing one without arriving at a particularly good explanation for the final shape of the solution. “It eventually passed the tests” is not the same as “we know why this is the right solution.”

The conversational interface makes that distinction surprisingly easy to overlook. Every retry can arrive with a plausible explanation, which makes a search through alternatives feel more deliberate than it may actually be. The useful part may simply be that the system can explore possibilities cheaply and react quickly to feedback. There is nothing wrong with that, as long as we do not confuse successful exploration with understanding.

Agentic AI can turn software development into brute force with a conversational interface. The conversation makes the process easier to follow; it does not automatically turn the result into an engineering argument.

AI can therefore reduce the cost of creating complexity without reducing the cost of carrying it. Complexity itself is not evidence of bad engineering. Seven dependencies may be entirely justified, and a new abstraction may solve a difficult problem elegantly.

What matters is whether the reason for that complexity exists and can be explained. A passing test can confirm observed behavior, but it cannot explain why a particular structure was necessary, why an additional dependency was worth introducing, or which constraint ruled out a simpler solution.

That distinction becomes more important as generation gets cheaper because costs can move rather than disappear. The implementation may take minutes instead of hours, while the resulting structure remains in review, maintenance, debugging, and every future attempt to understand that part of the system. Cheap code can still create expensive context.

Their value often lies precisely in the mess: somebody tried the obvious approach and discovered why it failed; somebody misunderstood an API and was corrected; a workaround looked clever until another developer explained what it broke.

That accumulated path is part of engineering knowledge. The accepted answer alone is often less useful than the discussion around it.

AI-assisted work increasingly happens in places where that trail is easy to lose. An IDE assistant proposes one approach, an agent tries another, a test exposes an unexpected constraint, the implementation changes again, and eventually the repository receives a working patch. The sequence that produced it may never become part of anything the team can search or reuse.

The failed approaches disappear with it, along with the assumptions they disproved. Another developer or another agent can rediscover the same dead end tomorrow because the system retained the answer but not the lesson. Cheap iteration then becomes less impressive than it first appears: the organization may repeatedly spend computation and developer attention learning things it has already learned once.

If only the final patch survives, the workflow has generated activity, not necessarily knowledge. A system that repeatedly starts from zero can become very efficient at forgetting expensively.