You Can Build an App in an Afternoon Now. The Bill Often Comes Due Three Months Later

A few weeks back I wrote about the biggest shift I've seen in software in years — that you can now describe the tool you need, in plain words, and have it built for you, no developer required. I meant every word of it. That door really is opening.

But I ended that piece with a warning I only had room to say in a sentence or two, and it deserves its own conversation. Because right now, all over the world, businesses are quietly discovering the other half of that story: building fast and building something that lasts are not the same skill, and the gap between them is starting to show up as a bill.

#The number that stopped me

Here's something worth sitting with. By some counts, more than four out of every ten lines of code written anywhere in the world last year were written by AI, not by a person typing at a keyboard. That's not a niche trend anymore — that's most of the software industry.

Now here's the part that should make you pause. As more developers lean on AI to write their code, fewer of them actually trust what it hands back. A couple of years ago, more than four in ten professional developers said they trusted AI-written code. Today that number has dropped below three in ten. People are using it more and believing it less — at the same time. That's not usually a sign of a tool maturing. That's usually a sign of a tool being used faster than it's being checked.

#What happens when nobody checks

Researchers who went digging through a huge sample of real, shipped code — over 150 million lines of it — found a pattern that matches what a lot of engineers already feel in their gut. The amount of copy-pasted, duplicated code went up by nearly half. The amount of time spent going back to tidy up and simplify what was written dropped by more than half. In plain terms: more gets written, less gets cleaned up. Code goes in fast and rarely gets a second look, the way a room fills up with things you meant to sort out "later."

And separately, when security researchers checked large samples of AI-written code specifically for holes — the kind that let someone steal data or slip into a system they shouldn't be in — they found a problem in nearly half of it. Not one AI, not one tool. Roughly one in two, across the board. In large companies that track this closely, the number of new security problems being flagged shot up tenfold in about six months.

None of this means the software is failing on day one. It works. That's exactly the trap. It works in the demo, it works for the first customer, it works for the first few months — and then, quietly, a crack that was there from the start finds its moment. I've watched this happen with clients who came to us after building something themselves or with a cheap shortcut: the front of the house looked finished, but nobody had ever checked what was holding it up.

#The part that worries me most

There was also a study on one of the well-known "AI software engineer" tools — sold as something close to a replacement for hiring a developer, priced like a mid-level salary. Independent testers gave it twenty real tasks. It fully finished three. Not because it's a bad tool — it genuinely is impressive — but because "sounds confident and gets most of the way there" and "can be trusted to finish the job unsupervised" are two very different things, and right now the industry is pricing and marketing the first one as if it were the second.

And here's the quieter, longer-term worry. A lot of companies are now hiring fewer junior developers, because the AI seems to cover the basic work those juniors used to do. That sounds efficient. But the junior developer of today is the senior engineer of ten years from now — the person who's spent years in the weeds learning to spot exactly the kind of subtle problem I've just described. If fewer people get that grounding because a machine is doing their early work for them, who exactly is going to catch the AI's mistakes a decade from now? We may be quietly cutting off the supply of the very people we'll need most.

#What this means for you, plainly

If you or someone on your team has used one of these tools to build something — a form, a small internal system, a customer-facing app, anything — none of this means throw it away or panic. It means be honest about what it's for.

A tool you built in an afternoon to track deliveries or tidy up a spreadsheet? Wonderful. Low stakes, easy to fix if something's off, exactly the kind of thing these tools are made for. But the moment a tool starts touching customer payments, private data, or anything where a quiet failure would actually hurt someone — that's not the moment to trust it because it looked fine when you tested it. That's the moment to get a second, human pair of eyes on it. Not because the technology is bad. Because "it worked when I tried it" has never been enough to know something is safe, not for AI-written software and not for anything else important either.

#A small habit for this year

Here's the habit I'd ask you to build, and it costs you almost nothing.

For anything built quickly — by you, by your team, by any of these tools — before it touches something that matters, ask one honest question out loud: "If this breaks in three months, who notices, and how much does it cost us?" If the honest answer is "nobody, and barely anything," ship it and move on with your life. If the honest answer involves a customer, their money, or their data, slow down just enough to have someone who knows what they're doing take a proper look before it goes live.

That's the whole habit. One question, asked honestly, before the stakes get high. It takes thirty seconds and it will save you from becoming one of the businesses quietly writing a much bigger check later to have someone come in and fix what got built too fast.

#Where I land on this

I'm not writing this to talk anyone out of using these tools — I use them myself, constantly, and I still believe what I wrote a few weeks ago: this is the biggest opening ordinary business owners have ever had to build the software they actually need. That hasn't changed.

What's changed is that the excitement has had a head start, and the caution is only now catching up. Speed was never the hard part of building software. Knowing what deserves care and what doesn't — that's always been the actual skill, long before AI showed up, and it still is now. The businesses that come out ahead over the next few years won't be the ones that built the most, the fastest. They'll be the ones who knew, every single time, which parts of what they built were allowed to be quick — and which parts needed someone to slow down and actually check.