Depending on which headline you read this week, AI either writes production software better than any engineer, or it produces plausible-looking rubbish that will sink whoever ships it. Both stories sell. Neither survives contact with a working day.
We build software with these tools every day - they are the reason our firm is shaped the way it is. So this is an account from inside: what AI has genuinely changed about development, what it has not touched, and what that means if you are paying for software to be built.
The mechanical work really did get cheap
The parts of programming that were always mechanical - scaffolding a service, drafting an interface, writing the third variation of a test suite, turning a clear intention into unsurprising code - now cost a fraction of what they did. That is not hype. A senior engineer with today’s tooling drafts in minutes what used to take a day, holds more of the system in view at once, and no longer queues behind anyone to get a schema migrated or a test harness built.
Work that used to be split across several roles because no one person could carry it all can now, on most projects, be carried by one senior person with good tools. The disciplines survived. The hand-offs between them are what quietly disappeared.
The hard part was never typing
The durable difficulty in software was never producing code. It is deciding what to build and - harder - what not to. It is recognising the design that will hurt in six months, and knowing when a test proves something and when it is ceremony. None of that moved. A model generates the wrong thing with exactly the same fluency and confidence as the right thing, and nothing in the output tells you which one you got.
That is why these tools multiply judgement rather than replace it. Put a careful senior engineer in front of them and you get that engineer at several times the pace. Put carelessness in front of them and you get carelessness at the same multiple. The tooling has raised the price of not knowing what good looks like.
Where it actually goes wrong
The failure we see in real codebases is rarely the one from the headlines - a model inventing an API or a fact. Anyone paying attention catches those quickly. The expensive failure is quieter: code that works, merges and ships, and that nobody on the team actually understands. Accept enough suggestions without owning them and you accumulate a system whose author, in any meaningful sense, is no one.
The cost of software has shifted to match. Producing code is close to free; being sure it is right is not, and owning it for years certainly is not. Review, verification, and the taste to throw generated code away are where the real work has moved. A team can now generate a month of maintenance burden in an afternoon - velocity and liability come out of the same tap.
What this does to the shape of a team
Follow that logic and it changes who should be in the room. The layered delivery team - a manager coordinating designers, developers and QA through hand-offs - existed because the mechanical work was too much for a few people to carry. Now that it is not, much of that structure is coordination you pay for, and every hand-off sheds a little context on the way through.
What replaces it is not fewer people doing the same jobs but a different shape: a few senior engineers, each carrying design, build and verification with AI doing the mechanical share, working directly with the people whose product it is. Specialist depth - security, design, data - still comes in when a project genuinely needs it, as expertise on the team rather than a stage the work queues behind.
Where that leaves us
So the reality of AI in development is neither headline. It is the biggest change to how software gets made in a generation, and up close it is almost boring: the typing got cheap, the judgement got precious, and the teams doing the best work are the ones that rebalanced around that fact early.
That rebalancing is our whole firm. The longer version of the argument - including what it means for what you pay for - is on our vision page. And if you would rather test it against a real project, that is what the consultation is for.