More AI-written code is not the same as better software
3 October 2026 / Always 49
If you only read the vendor story, 2026 is the year software engineering got solved. Assistants write a huge share of new code. Agents can attempt tickets. Demos look like magic. Then you read the other half of the research. Sonar’s State of Code survey found that AI already accounts for a large slice of committed code, and that the vast majority of developers do not fully trust it. A meaningful share do not always verify it before it ships. That is not a productivity miracle. That is a new way to industrialise doubt.
At Always 49 we are not interested in being the studio that produces the most lines. Lines are not value. A user who can complete a task without help is value. A codebase that a future developer can change without fear is value. Those two things are related. Incoherent software becomes incoherent experience. If an assistant has generated three different ways to do the same validation, the interface will eventually leak that confusion. Users should not have to feel your architectural indecision.
The maintainability research around AI-assisted code is messy, which is honest. Some studies find little difference when other developers later evolve the work. Other analyses point to more duplication, less refactoring, and more defects in AI-heavy pull requests. You do not need a single perfect paper to see the pattern in the room. People accept a suggestion because it runs. Running is not the same as belonging. Software quality is mostly belonging: does this fit the system, the data, the security model, and the user journey we already agreed?
That is why we keep AI inside a process rather than letting it become the process. Discover still comes first. Wireframes and prototypes still earn their keep. Development still happens in slices with demos a client can understand. Test still includes a human who was not in the build. If an assistant helps us implement a well-understood slice faster, good. If it tempts a team to skip the understanding, we have paid for speed with someone else’s Tuesday afternoon. Usually that someone is a user.
There is a cultural risk here that we care about as managers of work, not only as developers. Junior people can learn a great deal from assistants. They can also learn to outsource the part of the job that forms judgement. Senior people can move faster. They can also stop explaining the why, because the code appeared without a conversation. Collaborate without ego needs a shared understanding of the system. A pile of generated functions is not a shared understanding. We would rather a developer explain a decision out loud than merge a block nobody in the room could rewrite from memory.
Security and accessibility make the same point in sharper language. Models reproduce what they have seen, and they have seen a lot of inaccessible, barely authenticated, slightly wrong software. Focus order, target size, accessible authentication, and permission models are exactly the sort of thing a plausible generator can miss while still looking finished. In a year when European accessibility standards are moving from WCAG 2.1 thinking toward WCAG 2.2, “the assistant said it was fine” is not a defence. It is not even an explanation.
Clients feel this as project risk even if they never read a pull request. A sprint that generates a lot of surface area is hard to demo honestly, hard to test with a real user, and hard to estimate into the next two weeks. Our process exists to keep the work in slices people can understand. AI should make those slices cheaper to implement, not make the slices so large that nobody can tell whether they helped. If a demo needs a developer to narrate every click, the software is not done, however quickly the files appeared.
Our opinion is that the industry is about to spend two years cleaning up the first wave of unreviewed generation, in the same way it spent years cleaning up unreviewed copy-and-paste. The studios that will be worth hiring are the ones that treated AI as an accelerator of craft. That means automated checks, human review, and a UX standard that code has to meet before it is called done. Always 49 will keep using the tools for APIs, functions, and the dull glue. We will keep making the slow decisions ourselves. Users do not benefit from our velocity. They benefit from our judgement.