# AI has made building software almost free. Making it good costs as much as it ever did. > More apps, fewer products - Published: 12 Nov 2026 - Category: Perspectives - Author: Josh Vilensky, Head of Product Design, CohesionX - Reading time: 4 min Most days I review something an AI built. It compiles, the tests pass, the screen loads. On paper there's nothing wrong with it. Then I use it the way a person would, and it falls apart in small ways. A back button that doesn't go where every other app has trained you to expect. A screen nobody designed for the moment there's no data in it. Spacing that's a few pixels off everywhere, so the whole thing feels slightly cheap and nobody can say why. None of it fails checks. All of it is the difference between something people put up with and something they'd choose. To be fair to the tools, the flood of output is mostly good. Anyone can build now. People build software for an audience of one, use it for an afternoon and bin it. There should be a lot more of that. But more code is a different thing from more product, and the data has started to show it. ## **The bottleneck moved** A year or two ago, the slow and expensive part of building software was writing it. That part is now close to free. The work didn't go away. It moved, and currently it queues up in front of whoever has to review it, decide on it and judge whether it's any good. Two Harvard researchers, Fiona Chen and James Stratton, studied work data from 718 companies. Where teams adopted AI coding agents, developers wrote about 30% more code. The amount of finished work didn't rise in any statistically significant way. Review is what changed: changes took 49% longer to get merged, and the share sent back for rework nearly doubled. Anyone who has run a factory floor will recognise this. If you speed up a step that isn't the bottleneck, the system doesn't get faster. You just get a bigger pile in front of the real one. The shift is easy to miss from the inside, because AI feels fast. In a study METR ran last year, experienced open-source developers took 19% longer on tasks with AI tools, yet believed the AI had made them 20% faster. METR has since said the tools have moved on and those numbers are out of date. The lesson still holds: feeling faster and being faster are different things. If your team feels quicker, go and look at where the work is actually waiting. A good example comes from Andrej Karpathy, one of OpenAI's founding team. He vibe-coded a small app called MenuGen and wrote up how it went. The app worked and payments went through. But the AI had matched payments to accounts by email address, and people don't always pay with the email they log in with. So some people paid and never got what they'd paid for. Nothing crashed and every check passed. He described getting from a local demo to a real deployed app as a slog. ## **AI eats what can be checked** Karpathy also has the best explanation for why this happens. In an essay late last year, he argued that AI works best on tasks that can be verified: work where there's a right answer, and a machine can check it, try again and check again. Code that compiles can be checked, and so can maths. "Does this feel right to a person?" can't. So AI eats the checkable parts of the work first and leaves the rest lying around. In design, this "rest" is often what matters most. The UX laws that get skipped are the ones about how people feel. Jakob's Law says people spend most of their time in other products, so they expect yours to behave like those. The aesthetic-usability effect says people find good-looking things easier to use, even when they aren't. The peak-end rule says people remember an experience by its best moment and its last one. No test suite checks any of these. **"Design is inherently non-verifiable."** Dylan Field, CEO of Figma, speaking in Bengaluru in October. ## **Someone has to say no** Which raises the obvious question. If AI is this weak on the parts nobody can check, why is some of what people make with it genuinely beautiful? Because someone with taste was standing at the gate. Everyone has access to the same tools now, so the difference comes down to whether anyone looked at the output and was willing to say no: no, that's a hack, no, that interaction is wrong. I try to test every new release of these tools as it comes out, and I rebuilt our company website this year with AI writing most of the code. The speed is phenomenal, and most of what it gave me "worked". But all of it has to be reviewed, and that's where taste comes in. What made the site good was all the times I looked at a screen, didn't like what I saw, and sent it back. That's the job now, for me and for anyone building with these tools. Less making, a lot more judging. ## **What this means if you run a business** Budget for checking the way you used to budget for building. Generation is cheap now. Review isn't, and that's where timelines will slip. Give someone the authority to stop a release because it isn't good enough, not only because it's broken. Most organisations have a process for bugs. Very few have one for mediocre. And be honest about where your advantage lives. Anything a model can produce easily, your competitor can produce by Friday. Joe Reis, co-author of _Fundamentals of Data Engineering_, made the point earlier this year that nobody prompts their way into a trusted brand. Trust sits on the side AI can't check, and so does judgement. Next time a team shows you something AI built, don't ask whether it works. It probably does. Ask who decided it was good.