A prompt will get you a login screen, a dashboard, and a cool-looking flow before lunch. It won't tell you what happens when two people hit that flow at the same second, what your database does under real load, or who else can read the table where you're storing passwords. Those aren't finishing touches. They're the actual engineering.
I review code for a living, so I see both ends of this. The tools are genuinely good. Custom software that took a year now takes weeks, sometimes days, and I too use AI coding assistants to get there. None of that changes the fundamental architectural challenges of custom software builds.
Speed and soundness are different measurements
A model can write a function. It can't tell you whether that function should exist, how it fails under concurrent requests, or what it costs to run a million times a day. Those are architecture questions, and architecture is a discipline, not an output. Someone still has to sit with the system and decide how it's structured, what it costs at scale, and where the unlocked doors are. That's not a task you delegate to the model that wrote the code. It's the task that comes after.
The demo tests one path. Production tests all of them.
A demo succeeds because it only has to survive the sequence the builder rehearsed. Put it in front of an operator who's never seen it, and they'll click the one thing nobody tested, in an order nobody planned for. The system doesn't fail because the demo was dishonest. It fails because it was built for one user instead of the tenth (or hundredth). That's an architecture gap, and it shows up exactly once: in front of a real operator, at the worst possible time.
A token meter that doesn't know your revenue
Every call to an AI model has a price, and that price runs whether a human is watching or not. I've audited systems with no cap on model selection, no limit on response length, no ceilings, nothing. One misconfigured bot hammering an uncapped endpoint can generate a five-figure bill overnight. Model selection, prompt caching, response limits, per-account caps: these are line items in the architecture, decided in week one. Skip them, and the first person to notice is your CFO, asking a question nobody can answer.
The vulnerabilities that never appear in a walkthrough
The patterns repeat because nobody's looking for them until it's too late: readable passwords stored in the open, payment keys sitting in public code, login pages with no cap on failures, sessions that never expire, so a lost phone becomes a stranger's account. None of this breaks a demo. All of it breaks trust the day a customer emails asking why their data turned up somewhere it shouldn't have. Catching it before that email arrives is not a nice-to-have. It's the job.
Where the discipline actually lives
Every product I build starts with a specific operational problem a specific industry has been quietly absorbing as overhead, not a template pulled off a shelf. So, domain first, always. Then I build the architecture with AI capability from the first line of code, not retrofitted after a demo works. And here's the critical piece: I put my name on the result before an operator touches it. That's engineer-built. The model gives us speed. What I check, harden, and sign off on is what makes that speed worth anything.
A prompt gets you to a demo. Everything that makes it a product happens in the weeks after, and is executed by experienced, credentialed developers.
AI-native. Engineer-built.