Better Bets, Not Bigger Burdens: Shaping Delivery with Specs, Prototypes, and Agent Factories

Over the last few months, I’ve been exploring how teams are rethinking delivery in an AI-first world, and a familiar pattern is re-emerging. After years of agile rituals leaning heavily on iteration and disposable prototypes, there is a swing back toward specs and toward finding ways to upgrade prototypes into production.

These are not the +50-page BRDs of old. They are lightweight, testable, code-expressed specs that act as rails for AI-assisted work. Specs give AI something to aim at. Without them, outputs drift. With them, AI agents and humans can iterate faster and with less waste.

Tools like Kiro are embedding specs directly into workflows, making them less about documentation and more about interfaces between product intent and delivery execution.

Prototypes remain appealing because business leaders can now explore solutions to their own problems without the telephone game of PRDs. The challenge is exploring far enough to extract insight while still handing off to engineering teams to reinforce the prototype with rigor: linting, testing, and CI pipelines.

I’ve been exploring the landscape of these shifts, and a pattern is emerging. Whether in lunchtime conversations at ELC Annual or watching my LinkedIn feed fill with folks running early experiments like Claude Code generating PRs directly from GitHub issues, the industry is clustering around three anchors: specs, prototypes, and agent factories.

This is not a how-to guide. It is a mapping exercise: what people are trying, why it matters, and how it connects back to the core principle of making better bets without adding bigger burdens.

Specs That Shape Work

For decades, specs have had a complicated place in software development. In the waterfall era, they were 100-page tomes. Agile reacted hard against that weight, putting people over process and valuing conversations over documents. But with AI entering the loop, the pendulum is shifting again.

Process is taking the stage because the old excuses are falling away. You cannot estimate with AI in the traditional sense since it will simply build the thing in the time it takes. You do not need endless meetings to get team alignment or to surface hidden edge cases, because AI can uncover them in seconds. In this world, specs are no longer ceremony. They are scaffolding for humans and machines to collaborate effectively.

In AI-assisted workflows, teams are rediscovering that clear specs are not bureaucracy. They are leverage.

• As constraints: Specs act as contracts AI can actually use. Without them, you get drifting outputs and poorly defined scope.
• As accelerators: The sharper the spec, the less rework once AI enters the loop. This is especially powerful on existing systems where context is already well-shaped.

What is new is how specs are showing up inside tools:

• In tools: Platforms like Kiro let you draft specs in natural language, then translate them into actionable tasks and scaffolds. Instead of producing a document no one reads, you are shaping intent that both humans and AI can act on.
• In practice: Teams are experimenting with spec-driven tickets that connect directly into code generation pipelines, shrinking the gap between intent and implementation.

The pattern is clear. Specs are no longer static documents. They are becoming living interfaces between product, humans, and agents, reducing ambiguity and enabling AI to work alongside us more effectively.

Prototypes That Teach

If specs are constraints, prototypes are probes. They are how we explore uncertainty, test feasibility, and ask: Is this possible? What would it look like? How might it behave in the hands of a user?

Historically, prototypes filled the gap when specs were absent. The fastest way to learn was to build something, show it, and adjust. That is still true, but AI has changed the economics. Prototypes are now dramatically cheaper to produce, which means the questions they answer can be broader, faster, and more ambitious than ever before.

The hard part is no longer creating a prototype. The real challenge is taking one to production. A rough demo can excite a business sponsor, but without linting, tests, and pipelines, it collapses under real-world conditions. That gap — from what could be to what reliably runs — is where many teams get stuck.

In the dual-loop framing of this series, prototypes live squarely in the innovation lane. Their job is not to deliver features but to retire risk, clarify requirements, and feed insights back into the delivery loop. The smarter bet is not whether a prototype looks good, but whether it:

• explores solutions quickly,
• surfaces feasibility and edge cases,
• reveals where production rigor will be needed, and
• reduces the uncertainty facing delivery teams.

The payoff is that the bridge from prototype to production is shrinking. With AI, what once took weeks of re-engineering may take only hours. But the principle remains: treat prototypes as scaffolding, not finished systems. Their value is in what they teach and how they sharpen the bets we place in delivery.

Agent Factories That Deliver

Agent factories are the frontier of AI-assisted delivery. Where prototypes explore what is possible, agent factories attempt to automate how work actually gets shipped. Think of the early days of continuous integration: teams built scripts to stitch together tests, builds, and deploys. At first, it was fragile and noisy, but over time CI/CD pipelines became essential. Agent factories feel like the next iteration of that story.

Tools like Claude Code as GitHub Actions, or Ry Walker’s work at Tembo, already demonstrate real “ticket → PR” pipelines. You file an issue, and an agent produces a mergeable PR. That may sound futuristic, but it is already happening in production environments.

The prerequisites are old but unavoidable:

• systems expressed fully in code,
• automated test coverage, and
• a working CI/CD pipeline.

Without those foundations, agent factories collapse into noise. With them, they collapse cycle time.

In the language of this series, agent factories live in the delivery lane. They are where the bets pay off — provided they are fed by clear specs and informed by disciplined prototyping. But they also carry their own risks.

Over-Estimating the State of Play

This is where most of the industry narrative runs ahead of reality.

• Many teams imagine they can drop AI into their delivery loop and immediately get production-grade code. In practice, most orgs lack the test coverage, modular architectures, and CI/CD maturity that make agent factories viable.
• There’s a belief that agent-generated PRs will “save time,” but reviewers often drown in low-value noise. Without spec clarity and gating mechanisms, automation becomes a burden.
• Review discipline, guardrails, and clear definitions of “done” become the hidden tax.

The smarter bet is not to replace engineers with factories, but to let factories free engineers to spend more time shaping intent and less time grinding boilerplate.

Done well, agent factories extend the principle at the heart of this series: making better bets, with less burden, by retiring risk and collapsing wasted effort.

Under-Estimating What’s Coming

• Specs are evolving into machine-actionable contracts that AI can consume directly, not just human docs.
• Prototypes will increasingly encode governance checks — bias, compliance, safety — not just features.
• Factories won’t stop at “ticket → PR”; they will evolve into adaptive delivery systems that integrate observability, risk scoring, and user feedback into the loop.

The Continuity: Better Bets, Not Bigger Burdens

Seen together, the pattern maps cleanly back to the series theme:

• Specs reduce ambiguity → smarter bets.
• Prototypes validate assumptions → safer bets.
• Agent factories collapse cycle time → faster bets.

The payoff isn’t hype-driven productivity. It’s a compounding system that removes burdens while sharpening the bets we make.

Expanding the Toolbox
This isn’t about replacing one way of working with another, it’s about adding new layers of leverage. Specs, prototypes, and factories complement each other:

• Specs set the intent and boundaries.
• Prototypes stress-test those boundaries before heavy investment.
• Factories operationalize what holds up, turning intent into delivery at speed.

Over time, the lines will blur. Prototypes will increasingly feed into factories as structured testbeds, and factories will become the natural extension of specs. But the state of the art today is knowing which tool to reach for, and which problems each is best at solving.

Closing Reflection

At ELC Annual, I heard leaders debating whether to double down on specs or lean harder into prototyping. To me, that is the wrong question.

The smarter lens is continuity. How do we connect specs and prototypes so agent factories can accelerate delivery without drowning us in noise?
The future of delivery will not be spec only, prototype only, or agent only. It will be the interaction between them, reinforced by the right tools and sharpened by knowing which lever to pull for which kind of problem.

That is the landscape I am mapping in this series. Not hype for hype’s sake, but a state of the art view of how the toolbox is expanding and where the bets get better as the burdens get lighter.