Thoughts on AI Development

The "One-Shot" Appeal

If you've been using Lovable, Replit, or more recently Figma Make, you know the one-shot appeal is real. The pitch is seductive: describe the product you want, and it gets built. Or at least vibe-coded into shape through a few iterations, leaving you feeling more like a product manager than a developer.

And honestly? I get it. It's hard to sell a $30/month subscription by telling people they'll need to architect a solution first. "Make your ideas real" sells. "Here's a thoughtful tool for iterative product development" doesn't. I don't blame the marketing teams — I just think we should be honest about what that framing sets people up to expect.

You have to admire how much AI has flipped the developer world upside down. Remember the old line — "ideas are worthless, execution is everything"? If AI drops the cost of execution down to the price of a good prompt, are ideas really still worthless? Whatever people are building out there, even if 99% of it has zero commercial value, the "Just for Fun" section on Figma Make is more entertaining than most of what's on Netflix right now.

Why One-Shot Fails

But scroll through the Apps and Dashboards sections and the cracks show up fast. Scheduling apps with beautiful calendars that don't actually schedule anything. Half-baked e-commerce sites. Dashboards that promise analytics, data integrations, and marketplace features but fall apart the moment you click past the landing page. The one-shot pitch is great for getting people in the door, but it's quietly setting them up to fail when they try to build something real.

Here's what's actually happening underneath. The bottleneck in software used to be typing the code. AI didn't remove the bottleneck — it moved it. The hard part now is specifying intent: knowing what your app actually needs to be before you ask for it. And that's the part one-shot prompts hide from you.

A model can generate a flawless e-commerce frontend from a one-line prompt. What it can't do is guess that your shop sells flowers that belong to multiple categories at once, or that your customers filter by season more than by price, or that your inventory is tracked in stems rather than units. None of that is in the prompt. None of it is in the training data for your business. So the model fills in the blanks with the median answer — and the median answer is exactly the kind of app that demos beautifully and breaks the moment a real customer touches it.

This isn't a model-quality problem that gets solved by the next release. It's structural. The information needed to build the right thing isn't in the prompt because you haven't worked it out yet.

What Replaces It

I don't actually think the one-shot pitch is bad. It's pulled a huge number of non-developers into building things they never would have attempted otherwise, and that's genuinely good for the world. The problem is that nobody tells you what to do when the one-shot doesn't work — when the app looks right but behaves wrong, when adding one feature breaks three others, when you realize the thing you built has no concept of "users" or "data" that persists.

The shift is smaller than you'd think. Instead of opening with "build me an e-commerce website for my flower business where customers can filter by season, type, and color" and praying, you start one layer deeper: what data does this thing actually need, and how does it flow? Model the data first, build the forms that create and edit it, then build the customer-facing layer on top. It's the same order a developer would follow, and it's the order the LLM needs you to follow too — because current models are great at generating code, but they're not great at guessing the shape of your business.

There's a second move that's become a habit for me: when you don't know enough to judge an AI's first answer, ask it to critique that answer from a different angle. If it defends the original, you can commit with confidence. If it doesn't, you've just avoided a mistake you wouldn't have caught on your own. This is the closest thing I've found to a substitute for domain expertise you don't have yet.

Both moves point at the same underlying truth. The work that used to be optional — thinking about your data, your users, your edge cases before you write code — is now the only work that matters. The code itself is cheap.

The Non-Dev Trap

Here's what bothers me about the current pitch. The people most attracted to one-shot tools are the ones who were locked out of building software before — founders without technical co-founders, designers tired of waiting on engineers, operators who know their domain cold but have never written a line of code. That's a great audience. They have the one thing AI doesn't: actual context about the problem.

But the marketing tells them the opposite. It tells them the typing was the hard part, and the typing is solved, so they're done. So they skip the part they're uniquely qualified to do — thinking carefully about their domain — and lean on the part the model is worst at: guessing what they meant.

The result is the apps you see in the gallery. They look like software, but they don't behave like software, because nobody did the thinking that turns a screenshot into a system.

If you're a non-developer reading this, the good news is that the thinking part isn't gated behind anything. It's mostly just: what are the nouns in my business, what are the relationships between them, and what happens when one of them changes? You don't need to know SQL to answer that. You just need to know it's the question.

The one-shot is a great front door. It's a terrible blueprint.