Faster to What? The Four Ways to Build Software with AI

Every engineering team I've worked with has had the same conversation at some point: "Can't we just use AI to build this faster?"

The answer is yes. But faster to what, exactly?

That question is the whole game, and almost nobody asks it before they start.

---

The Diagram Everyone's Sharing

There's an image making the rounds on LinkedIn that captures something real. It lines up four ways to build software and shows where each one takes you.

• Waterfall assembles all the parts first — engine here, chassis there, wheels in the corner — and you don't get a working product until the very end.
• Agile delivers something that runs at every step: a skateboard, then a scooter, then a bike, then a car. Each version actually works.
• AI Build skips the slow middle and rockets you straight to a gleaming supercar prototype in days.
• Vibe Coding hands you a running app on day one — then slowly buries itself in its own junk until the whole thing collapses under the weight of code nobody understands.

It's a good diagram because it's honest about the trade-off most hype ignores: speed to a demo is not the same as speed to something you can keep.

---

Most Teams Don't Want a Supercar

Here's what the image doesn't say out loud.

Most organisations don't actually want a supercar. A supercar is expensive to run, terrifying to modify, and useless the moment one custom part breaks and no one on the team knows how it was made.

What teams actually want is a reliable car — something closer to a well-built muscle car. It's quick enough. More importantly, the team can maintain it, extend it, and hand it off to the next person without fear. When something breaks, someone can pop the hood and understand what they're looking at.

That distinction matters more in the AI era, not less. AI is brilliant at producing the supercar prototype. It will generate an impressive, working-looking app faster than you can write the ticket for it. The trap is mistaking that prototype for the finished product — and then discovering, three months in, that no human on the team can safely change it.

I've watched this happen. The demo lands, everyone's thrilled, the timeline gets compressed because "AI already built it," and then the real cost shows up later as the bill for code that was written fast and understood by no one.

---

The Real Question

So the real question isn't which approach is fastest. It's which one gets you to a car your team can keep running.

That reframes the choice. Instead of "how do we go faster," ask "how long do we have to live with this code?" The answer tells you which lane you're actually in.

Throwaway and short-lived? Vibe coding and AI Build are perfect. A weekend prototype, an internal one-off, a spike to settle an argument, a demo for a pitch — let AI rocket you there. The junk doesn't matter because the thing has a short life. Speed is the only metric that counts, so optimise for it without guilt.

Long-lived and team-owned? Now the muscle car rules apply. Use AI aggressively — to scaffold, to draft, to handle the boring 80% — but every line that survives into production has to be code a human reviewed, understood, and can maintain. AI writes the first draft; your team owns the result. The Agile instinct of "always have something that works and that we understand" is exactly right here, and AI makes each increment cheaper, not optional.

The failure mode is using the throwaway approach to build the long-lived thing. That's vibe coding a system you'll still be running in two years. It feels fast for the first month and expensive forever after.

---

What This Means on Monday Morning

You don't have to pick one approach for your whole org. You pick per project, and you pick honestly.

Before the next "can't we just use AI for this," ask three things:

1. How long will this code live? A demo and a billing system are not the same project, even if AI builds both in an afternoon.
2. Who has to maintain it? If the answer is "the team," then the team has to be able to read it. Unreviewed AI output is technical debt with a delivery date attached.
3. What does "done" mean here? A running prototype, or a thing you can safely change next quarter? Name it out loud, because AI will happily give you the first while everyone assumes you meant the second.

AI genuinely made all four lanes faster. That's the good news. But faster is only a gift if you know where you're trying to go. A supercar in days is worthless if what you needed was a car you could still drive next year — and the teams that win the AI transition are the ones that figured out the difference before they hit the gas.

So the next time someone asks whether you can just use AI to build it faster, the honest answer is: yes — now tell me faster to what, and we'll know exactly how to build it.