Ten plain claims aboutwhat AI is doingto the software industry

Producing a plausible function is no longer the slow step for anybody. The slow step is establishing that the function does what the sentence above it claims, under the inputs this particular system actually receives, in the presence of the four other things it touches. That work did not get faster, and most of it is not typing.

You can watch this in any team that adopted assistants quickly. Pull requests get opened sooner and merged later. The queue is not in the editor any more; it is in the heads of the two or three people who can tell a convincing diff from a correct one.

For twenty years we hired on the ability to produce. The interview was a blank editor. That signal has gone soft, because the blank editor is no longer blank for anyone. What separates engineers now is how quickly they can read something they did not write and say precisely where it will break.

This is a real skill with a real learning curve, and it was always undertaught. It means holding a system in your head, knowing which invariants matter, and having the nerve to reject something that looks finished. Teams that keep hiring for production speed and then wonder why review is a swamp have simply not updated the job description.

The practical response is small and unpopular: fewer, larger-stake reviews done properly, by people with the context, rather than everyone rubber-stamping everything in fifteen minutes between meetings.

A weak abstraction used to spread at the speed a human could copy it. Now it spreads at the speed of completion. Give an assistant a codebase where the wrong pattern appears in forty places and it will faithfully produce the forty-first, because consistency with what exists is exactly what it is good at.

The inversion is that the quality of your existing code is now a multiplier on everything written next, not merely a drag on maintenance. Cleaning up a confused module is no longer only housekeeping; it changes the output of every future session in that area of the repo.

So the old advice holds, with a sharper edge: name things honestly, delete dead paths, and keep one obvious way to do each common thing. Those were taste arguments before. They are throughput arguments now.

The tasks a junior engineer used to cut their teeth on — the small CRUD screen, the test backfill, the obvious refactor — are the ones most easily produced now. That is not the problem. The problem is that those tasks were the training apparatus, and nobody has replaced it.

If a junior spends a year accepting generated work and shipping it, they arrive at year two with the output of a mid-level engineer and the judgement of a first-week one. The gap shows up precisely when it is most expensive: during an incident, in a design review, at the moment somebody has to say this looks right and is wrong.

The teams handling this well are deliberate about it. Juniors are given problems rather than tickets, asked to explain a system back, and made to debug something nobody generated. It costs senior time. Not spending it is a decision to have no seniors in five years. Pairing came back for a reason that has nothing to do with nostalgia: it is the only reliable way we have found to transfer judgement.

An industry that spent fifteen years arguing that documentation is a smell now spends its day writing careful prose describing exactly what a system should do. We call it prompting, or context, or a rules file. It is a specification, and the quality of it determines the quality of what comes back.

The useful discovery is that this prose is worth writing even when no model reads it. A page that states what the feature must guarantee, what it must refuse, and what it deliberately does not handle is the fastest way to find out that two people in the room disagree. That was true in 2005 and it is true now; the difference is that there is finally an incentive to do it.

Two tasks that look identical on a board now differ by an order of magnitude, because one of them is a well-trodden shape with a thousand public examples and the other touches a private domain rule that nobody outside the building understands. The first finishes in an afternoon. The second takes the week it always took.

The effect is that velocity numbers have become noisier while appearing to improve, and the conversation with stakeholders gets harder rather than easier. Expectations are set by the afternoon tasks and then spent on the week ones.

What helps is sorting work by how much of it is novel to this organisation, and saying so out loud in planning. Not story points. Just a sentence: this is mostly standard, or this is mostly ours. The second kind has not sped up and will not.

When the cost of building a competent version of something falls, the number of competent versions rises. A category that supported four products supports forty, and every one of them demos well. Buyers notice this before vendors do, and they respond by discounting the demo entirely.

What survives that is not feature count. It is the things that are still expensive: a brand somebody trusts, support that answers, data nobody else holds, an integration that took two years of someone else's politics to land, and a track record of not breaking. Distribution and trust are the scarce goods now, and neither of them can be generated.

For agencies and product teams alike, the strategic consequence is to stop competing on what can be rebuilt in a fortnight and start accumulating the things that cannot.

More code reaching production per engineer per week, with less of it read closely by its author, is a straightforward increase in the surface area a reviewer must cover. The classic answer — a security pass before release — scales with releases, and releases are now continuous.

The workable shape is to push the checks into the path the code already takes: dependency policy enforced at install, secrets scanning at commit, authorisation tests that fail the build rather than a checklist item, and a short list of patterns that simply cannot be merged. None of this is new. The pressure that makes it mandatory is.

A four-person team with full context in every head can take a generated draft and judge it in minutes, because the people doing the judging already know the system, the customer and the constraint. The same draft in a four-hundred-person organisation enters a queue, crosses two team boundaries and needs three approvals before anybody with context sees it.

The gain, in other words, lands where coordination cost is lowest. That is a real competitive shift and it is not evenly distributed. Large organisations get the same tools and convert much less of the benefit, which is a structural problem rather than a tooling one.

The lever available to a big organisation is not more adoption. It is shortening the distance between the person who writes something and the person allowed to say yes to it.

Every claim above is about the middle of the work. None of them touch the start of it, which is sitting with a person who has a problem, understanding what they actually do all day, and deciding which of the twelve possible systems is the one worth existing. Nothing about that got cheaper.

If anything it got more valuable, because the penalty for building the wrong thing has risen with the speed of building it. A team that can produce four features a week and chooses badly will do more damage, faster, than one that produced one feature a week and thought about it.

So the honest summary of the last few years is narrow and unromantic. A large, tedious portion of the job was automated. The portion that was always hard — judgement, context, taste, responsibility for the consequence — is now most of what is left, and we should staff and train accordingly.