A Quarter’s Work in Five Weeks, Without Vibe-Coding

There is a popular myth about AI-assisted development going around: you type a prompt, a whole app falls out, and engineers become optional. That is not what we did — and it is not why it was fast.

We had an operational gap to fill and needed a new application. The traditional route — a detailed spec, a design phase, tickets, a build, a review queue — would have run three to four months. We tried something different: build it AI-first, end to end, but with more discipline, not less. It shipped in about five weeks.

The reframe: the demo is the spec

The heart of the change was dull to describe and powerful in practice: we stopped writing long specifications and started building prototypes instead.

A written spec is a description of something that does not exist yet. Everyone reads it, nods, and pictures something slightly different — and you discover the gaps months later, when the built thing finally meets its stakeholders. A prototype collapses that loop. It is the thing, near enough, so people react to what is in front of them instead of to what they imagined.

So the demo became the main thing we produced. Each round, we showed a working prototype aimed at the problem we were solving and gathered real reactions, then moved on. The formal documents still got written — but AI drafted the architecture decision records from the prototypes and the review comments, so the paperwork followed the work instead of blocking it.

What the pipeline actually looked like

The old pipeline front-loaded the writing. The new one front-loaded the building, and let AI absorb the parts that had always been drag.

BEFORE
  detailed spec  ->  design / Figma  ->  tickets  ->  build  ->  review queue  ->  release
  (weeks of writing and sign-off before anyone sees a working thing)

AFTER
  problem statement
    -> prototype + live demo         (the thing everyone reacts to)
    -> AI-drafted decision records   (captured from the prototype + comments)
    -> AI-assisted tickets           (deliverables managed, human-approved)
    -> human-in-the-loop milestones  (a person signs off each step)
    -> release

Notice what did not change: the milestones, the sign-off, the human judgement at each gate. Those are the guardrails that keep this from becoming that exaggerated version. What changed is that the slow, low-value work — writing specs nobody reads carefully, chasing tickets, transcribing decisions — moved to AI, and the people spent their time on the prototype and the problem.

The result, and what it cost

The project that would have taken a quarter took about five weeks. Better still, the stakeholders saw working software early and often, so what we shipped was closer to what they actually needed — the usual late-stage surprises did not arrive. Coming a few months after AI code review had earned its place, this build is what pulled the rest of engineering into working this way.

It was not free, and it was not magic.

Where this works, and where it doesn’t

Two honest caveats.

First, this was greenfield — a brand-new app with no legacy to respect. Greenfield is the easy case. Retrofitting a prototype-first, AI-drafted workflow onto a mature system with real users is a harder problem, and I would not promise the same speed-up there.

Second, the speed came from the parts inside engineering’s control: building, and generating the documents. The genuinely human part — getting several stakeholders to agree on the right problem — did not get faster. It never does. AI can draft the decision record; it cannot do the disagreeing for you.

The takeaway

AI-first delivery, done properly, is not a way to build without engineers. It is a way to spend their attention where it matters — on the problem and the prototype — while the machine takes the drag. Change what you produce, keep the discipline, and a quarter of work really can land in a month.