Building AI-Native Engineering Workflows

Executive summary

Specifications as the common contract between engineers, coding agents, tests and review: how a team can get more throughput from agents without giving up reliability or ownership.

Context and constraints

AI tools can produce code faster than anyone can review it. Used casually, that speed just moves the cost elsewhere: into review queues, missed edge cases and changes nobody can fully explain six months later.

The question isn't whether a team should use AI. It's how to fit it into the lifecycle so the output is specified up front, verified automatically, and accompanied by evidence a reviewer can trust, and so the practice spreads beyond the engineers who are already enthusiastic.

Constraints

• Regulated, client-facing software. Quality and security expectations don't relax because the code was generated.
• Humans stay accountable. Every merge needs an engineer who understands and owns it.
• Adoption has to be voluntary to stick. Workflows need to save engineers time on day one, or they won't be used.
• Tools change monthly. The approach has to survive a change of model or agent.

My role

Informed by my experience helping shape AI-assisted engineering practices. This describes the principles and a generalised workflow.

Technical challenge

Agents make producing code cheap. They don't make correctness, design quality or understanding cheap. The real challenge is moving the bottleneck from writing code to specifying and verifying it, without anyone losing ownership of what ships.

Architecture and decisions

The model, as I apply it:

• Start from a spec, not a prompt. A requirement becomes a structured specification with explicit scope, non-goals and acceptance criteria.
• Encode standards as reusable skills. Conventions, patterns and quality bars are written once and shared, so every engineer's agents start from the same baseline.
• Let agents work against the spec. The agent implements a scoped change with the spec as its contract, not an open-ended conversation.
• Make verification part of the output. Test plans are derived from the acceptance criteria, and end-to-end runs produce evidence that travels with the change.
• Review with assistance, decide as a human. Assisted review checks intent against the spec and highlights risk; a person stays accountable for the merge.
• Keep the evidence. Each change carries a trail of what was asked, what was done and how it was verified.

In this model the spec is the backbone: it's what the agent builds against, what the tests verify, what the reviewer checks intent against, and what remains as the record of why the change exists.

Alternatives considered

• Ad hoc assistant use. No setup, but quality depends on each engineer's prompting and nothing is repeatable or reviewable as a practice.
• Maximum autonomy. Impressive demos, but large change sets nobody can review properly and no clear owner when something breaks.
• A structured lifecycle (specification, shared standards, verification, human approval). More effort up front, but repeatable and reviewable, which is what a regulated environment needs.

Trade-offs

• Writing specs is slower up front. It pays back on anything bigger than a trivial change, and it's the step teams are most tempted to skip.
• Shared skills need an owner. Without maintenance they drift from how the team actually works and start producing confident, outdated code.
• Automated review can breed complacency. It should narrow what a human looks at, never replace the look.

Execution

Adoption is a change-management problem as much as a technical one:

• Start where it saves time on day one: review assistance and test planning, not autonomous feature work.
• Make standards shared and versioned, so improvements reach everyone rather than living in one engineer's prompts.
• Keep a human approving every merge, and make the evidence they review better, not the review optional.
• Let teams pull practices in rather than mandating them; adoption that spreads on its own merit lasts.

Results

Programme outcomes aren't published here. What I can say: the agent-assisted workflows I introduced for code review, test planning and end-to-end testing were adopted beyond my own team.

The aim is a way of working where AI output arrives specified, tested and explained, and where good practice lives in shared standards rather than in one engineer's prompts. Done well, moving faster no longer has to mean trading away understanding or quality.

Reflection

• The spec is the hardest part. Most agent failures I see trace back to ambiguity in the brief, not the model.
• Evidence beats confidence. A passing test run is worth more than a fluent explanation.
• Accountability doesn't delegate. Assistance can make review faster; it can't make it someone else's responsibility.

Technologies

• Spec-driven development
• Coding agents
• AI-assisted review
• End-to-end testing
• CI

Deep dive

What a useful spec looks like

The format matters less than the discipline: explicit scope, explicit non-goals, and acceptance criteria that can be turned directly into tests.

## Goal
Retry failed webhook deliveries without duplicating side effects.

## Out of scope
- New event types
- Changes to subscriber authentication

## Acceptance criteria
- [ ] Failed deliveries retry with exponential backoff
- [ ] Retries stop after a configurable number of attempts
- [ ] Every delivery carries an idempotency key
- [ ] Exhausted deliveries are recorded and can be replayed

## Evidence required
- Unit tests for backoff and the retry ceiling
- Integration test: a subscriber that fails twice, then succeeds