How we rebuild your pilot from scratch in 6 weeks

Six weeks. Mobile app, admin portal, serverless backend, full cloud infrastructure as code, CI/CD, observability, payments, auth, messaging. Production-ready. Two engineers.

This is not a vibe coding story.

We did not open a chat window and ask an LLM to "build me an app." We built a pipeline. Disciplined, auditable, human-gated. AI does the mechanical lifting. Humans own every consequential decision.

We call it augmented engineering, not vibe coding. The difference is where the judgment lives.

The pipeline, end to end

The work moves through eight stages. Each stage has a clear input, a clear output, and a clear owner. AI accelerates every stage. A human approves every transition.

1. Recorded discovery sessions with the client

Every conversation with the client is recorded. Not for compliance theatre, because the conversation is the highest-fidelity source of truth we have, and we refuse to lose it to someone's note-taking shorthand.

Meetings are unstructured on purpose. We let the client think out loud. Contradictions, asides, "oh and another thing" moments, those are signal, not noise. A polished requirements document written after the fact erases exactly the parts we need.

2. Meeting analysis → Architecture Decision Records

Recordings are transcribed and run through an analysis pass that extracts three things:

Decisions the client actually made, as opposed to things they speculated about.

Constraints they revealed, often without realising it. Budget ceilings, timelines, existing vendor lock-in, regulatory exposure.

Open questions the meeting did not close, queued for the next session.

These feed into Architecture Decision Records. One ADR per decision. Each one states the context, the options considered, the choice, and the consequences we accept by making it.

ADRs are not generated and forgotten. An engineer reads each one, pushes back on the framing, sharpens the trade-off, and signs off. The AI's job here is to make sure nothing from the conversation is dropped. The human's job is to make sure the right thing was decided.

3. ADRs → SPECS

Once enough ADRs are locked in to define a coherent slice, we synthesise a technical specification.

The spec is the contract between the human-led design phase and the AI-accelerated build phase. It contains the data model, every entity, every field, every relationship, with reasoning. It contains API contracts, request and response shapes, status codes, error envelopes, per domain. It contains architecture rules that are non-negotiable, the kind of constraints that, if violated, cause the whole system to drift into incoherence.

Examples from this project: one Lambda per handler, strict three-layer domain pattern, pagination on every list endpoint, no service exposed without a CDN in front of it, separate authentication pools for end-users and admins.

It also contains non-functional requirements. Latency budgets, cost ceilings, availability targets.

This document is what we point AI agents at when they ask "how should this work?" It is also what we point ourselves at when we are tempted to take a shortcut at 2am.

4. SPECS → Intents on the board

The spec is decomposed into Intents. An intent is not a task. It is a statement of what we want to be true about the system. Small enough to fit in a single coherent piece of work, big enough to mean something to the product.

A guest can complete a booking for a paid event and receive confirmation.

Intents land on the Azure DevOps board. They are the unit of planning, and also the unit of conversation with the client. An intent is small enough to demo, big enough to matter.

We resisted the temptation to skip this layer and let AI generate tickets directly from the spec. It is exactly the wrong place to hand over judgment. Intents are where product priorities, client trade-offs, and engineering capacity collide. That collision belongs to humans.

5. Intent → Work items (the planning agent)

This is where AI starts pulling its weight as a participant, not just an editor.

A planning agent takes one intent and decomposes it into work items. Which Lambdas need to exist, which routes need wiring, which migrations are needed, which screens are affected, which contracts change, which tests must pass. It cross-references the spec, the existing codebase, and the ADRs.

The output is a structured plan that an engineer reviews. The review is fast, usually minutes, because the planner has already done the boring cross-referencing work. The engineer is checking that nothing was missed, that the decomposition matches the architecture rules, and that the plan does not quietly invent a new pattern.

If the plan looks wrong, we do not fix it inline. We push back to the planner with the specific objection. This keeps the agent's reasoning explicit and auditable, instead of getting laundered through engineer-typed edits.

6. Work items → Code (the builder agent)

The builder agent executes one work item at a time. Constrained scope, constrained context, constrained output. It reads the relevant slice of the spec, the relevant slice of the codebase, and produces a change.

Why this stage works at all is the tech stack, which I'll get into below. The short version: the codebase was deliberately designed to be predictable enough that an LLM can produce correct code without needing to hold the whole system in its head.

Every change is reviewed by a human before merge. Not skim-reviewed. Read.

This is the single most important guardrail in the pipeline. The cost of a bad merge compounds. The cost of a slow review does not.

7. CI/CD with real teeth

The CI pipeline is not decorative. It runs the type checker, the linter, the unit tests, the integration tests, and a CDK diff before any deployment. A failed pipeline blocks merge, and we treat hook bypasses as a serious smell, not a convenience.

Deployments are infrastructure-as-code, environment-promoted, dev to staging to prod. The same code that defines a development NAT instance defines a production NAT gateway, parameterised. AI helped write the CDK. Humans own the diff that goes to production.

8. Observability and feedback loops

Every Lambda emits structured logs. Every API surface is fronted by a CDN with a WAF. Every error class has a known dashboard. When something breaks in production, the loop back to step 1, a recorded conversation, a new ADR, a spec amendment, is the same loop. There is no hotfix culture that bypasses the pipeline. Hotfixes also become ADRs.

Vibe vs augmented, where the judgment lives

The vibe coder asks a model to build a thing and accepts what comes out.

The augmented engineer designs the system so that what comes out is constrained to be correct, and reviews every output against the design.

The difference shows up in five places.

Specifications are written first, by humans, with AI assistance. Not generated alongside the code.

Architecture rules are non-negotiable and codified. The AI does not get to choose patterns. It applies the patterns we chose.

Code review is mandatory and serious. Every diff is read. The model's confidence does not substitute for engineering judgment.

The pipeline is auditable. Every line of code traces back to a work item, traces back to an intent, traces back to an ADR, traces back to a recorded conversation. Provenance is preserved.

Failure modes are designed for. When something breaks, the loop is not "ask the AI to fix it." The loop is the same one we used to build it. Capture, decide, specify, plan, build, review, deploy.

The output of this approach is a codebase that does not look like AI built it. It looks like a small, opinionated team built it. Which is exactly the point. The AI is leverage, not a replacement for the team's taste.

Why the stack fits agentic methodologies

The pipeline above is not portable to any stack. It works because we picked tools that make AI-generated code legible, verifiable, and contained.

Go for the backend

Go is what you choose when you want every piece of code to look like every other piece of code. No metaprogramming. No clever DSLs. No magic frameworks where behaviour lives in annotations and runtime reflection. The cognitive surface a reader, human or model, has to hold is tiny.

For an AI agent, this is decisive. The model does not have to guess what a decorator does, or which of three competing ORMs is in scope, or whether a method is overridden somewhere it cannot see. Each Lambda is a single file with a single entrypoint, parameterised SQL, explicit error handling, explicit context propagation. The blast radius of any one generation is one file, one function, one handler.

The "one Lambda, one handler" rule is not an aesthetic preference. It is what makes AI-generated backend code safe. Each unit of work is small enough to fit in a context window with room to spare. There is no internal router for the model to reason about. There is nothing to break elsewhere.

Pair that with the three-layer domain pattern, Handler then Service then Repository, enforced with no exceptions, and the AI knows exactly where business logic goes, exactly where data access goes, exactly what to mock in tests. The agent stops needing creativity, which is exactly what you want from an agent.

TypeScript for CDK

Infrastructure as code, not YAML. This matters for two reasons.

First, the same model that reasons about application code can reason about infrastructure. The CDK is just TypeScript. An agent can refactor a stack, add an environment variable to a Lambda, wire a new route to a CloudFront distribution, and update the IAM in one coherent change. Because it is all in one language with one type system.

Second, the type system catches the entire class of "I forgot to wire the X to the Y" mistakes that AI-generated infrastructure is famous for. CDK constructs compose. If a construct expects a VPC and you pass a string, the build fails before any cloud resource is touched. This is the cheapest possible feedback loop.

We built reusable constructs that bake our conventions in. A GoLambda construct that always builds for the right architecture and applies minimum-privilege IAM. A Lambda wrapper that always sets the standard environment and database access. A Route construct that always attaches the right authoriser. The agent is not free to invent. It is given building blocks that are already correct.

Serverless for the client

The client is not a hyperscaler. They do not have idle infrastructure budget. Every dollar spent on a server that is not serving a request is a dollar that did not go into the product.

Serverless lets us deliver a system that costs near zero when nobody is using it and scales to demand when somebody is. Aurora Serverless v2 for the database, Lambda for compute, DynamoDB for messaging, CloudFront for delivery. We deliberately chose a NAT instance over a NAT gateway in non-production environments, saving the client roughly $30 a month on a single component because it was the right call for their stage.

This pairs with the agentic pipeline in a way that is easy to miss. Because each Lambda is independently deployable, an agent can ship a single small change without rebuilding a monolith. Because each piece of infrastructure is granular, an agent can reason about cost as a per-component concern. The architecture and the development methodology reinforce each other.

What it cost us to do this well

Building the pipeline took longer than building any one feature would have. The first ADR, the first spec, the first reusable construct, these were investments that did not show up in any demo.

The payoff was not gradual. It was a step function. By week three, we were closing intents in hours that would have taken days in a conventional setup. By week five, the client was watching demos of features they had described in a recording the same week.

The one constraint that did not slip: human review on every merge. We protected that above all others, and it is the reason the codebase is something we would still ship today.

Closing

Six weeks is not a stunt. It is what becomes possible when you stop treating AI as a chatbot and start treating it as a member of an engineering team. One with very specific strengths, very specific weaknesses, and a need for very clear instructions.

Augmented engineers ship more, not because they think less, but because they have offloaded the parts of the work that did not deserve their judgment in the first place.

The job didn't disappear. It moved upstream.

Originally published on LinkedIn.