AI-First Software Delivery: Balancing Innovation with Proven Practices

Every team adopting coding agents eventually faces the same question from someone senior: why aren't you running a fully autonomous multi-agent loop yet? Wes Reisz, a technical principal at Thoughtworks and long-time QCon chair, gave this talk specifically to answer that question. His thesis is that AI-first software delivery (AIFSD) is not a one-size-fits-all approach: the right level of agent autonomy depends on how long the code will live and how well you can automatically verify it. The talk pairs that decision model with a concrete structured workflow called RIPER-5, and closes on a third argument about what happens to engineering discipline once code generation becomes cheap.

The context matters for reading his advice. Thoughtworks is a consultancy that embeds in a client's environment and uses the client's infrastructure — and, as Reisz puts it, "a lot of times we have to uplift the client", so the constraint runs in both directions: the team inherits whatever tooling and practice the client already has, and is simultaneously expected to raise that baseline. Reisz's current engagement is with a large U.S. state, building a knowledge graph from rules and regulations, fronted by a deep research agent so the state's systems can expose a modern AI interface. The team is about sixteen people and had been together roughly three months at the time of the talk. Their toolchain is Claude Sonnet 4.5 driving Cursor. Everything he recommends is filtered through the constraint of arriving cold into an unfamiliar domain.

These notes report what the speaker presented. Where I add context that was not stated in the talk, it is labelled as such.

What You Will Learn

• How to use a two-axis model — code longevity against degree of automated verification — to decide when supervised coding agents are the correct choice and when you have earned the right to go unsupervised.
• The difference between spec-first, spec-anchored, and spec-as-source development, which label Reisz gives his team's approach, and why the workflow he demonstrates does not quite match that label.
• Five properties that make a specification verifiable, drawn from a Databricks paper, and how to encode them in plain Markdown.
• The RIPER-5 workflow — Research, Innovate, Plan, Execute, Review — and why the forbidden actions in each mode matter more than the permitted ones.
• Why Thoughtworks still pairs human-to-human even when an LLM is in the loop.
• What the public demo repository ships — MCP server setup, Cursor configuration, written AIFSD principles, and the RIPER-5 rules and commands as a reusable git submodule.
• What a 10-to-1 specification-to-code ratio implies about where engineering effort is actually going.
• How a small MCP server over your own engineering context becomes the seed of shared agent memory.

The Framing Problem: A Trillion Dollars and a 95% Failure Rate

Reisz opens with two numbers that sit awkwardly together. An IDC projection says that by 2029, 26% of worldwide IT spend will go to agentic AI — about $1.3 trillion. His scale analogy: a U.S. $100 bill is roughly six inches long, so $1.3 trillion in $100 bills laid end to end would circle the Earth fifty times. Against that, he cites the widely-circulated MIT report claiming 95% of AI projects fail to deliver on ROI. (Transcript note: he says "$1.3 trillion" when introducing the figure and "$1.4 trillion" a moment later; the IDC number he is anchoring on is 26% of IT spend.)

His diagnosis of the gap is not that agentic AI does not work. It is that teams are not mapping their use of agentic AI to where their organization actually is. A technique that works for a team with three years of domain context in a codebase they wrote is not the same technique that works for a consultancy that walked in the door twelve weeks ago. The two-by-two that follows is his tool for making that mapping explicit.

He is careful to frame the model honestly: you will disagree with something on it, and he disagrees with something on it himself. A model is a map that gives people a common vocabulary for a conversation, not a claim to truth. That caveat is worth carrying into your own use of it.

The Two-by-Two: Longevity Against Verifiability

The vertical axis is longevity — how long will this code live? Is it a throwaway experiment, or will it sit in production facing customers? The horizontal axis is degree of automated verification — can you actually check that the thing you are producing is correct, automatically? Reisz explicitly ties verifiability to domain knowledge: you cannot write meaningful automated verification for a domain you do not yet understand, which is why a new team's position on this axis starts low and moves right over time.

Bottom-left: exploratory development

This is the quadrant Karpathy's much-misquoted March 2025 "vibe coding" tweet points at. Reisz says he vibes every single day, and describes the workflow concretely: a client explains a problem, he lets them talk to his product person for a few minutes, then throws together a solution and asks "is this what you meant?" His stated best-case answer is "No, not at all, that's completely wrong, please don't ever do that again" — because that is a high-information result obtained cheaply. POCs and small R&D spikes live here too. None of it ships. The output is information, not software.

Bottom-right: domain sensing

Same short lifetime, but now with enough verification rigor that the output is safe to rely on. This is where deep research agents run, both outside and inside the firewall. Reisz uses them to comprehend legacy codebases when arriving cold at a client: where are the domain boundaries, how does this organization think about domain-driven design, where are the existing seams, where could he introduce new ones, what patterns recur. The artifact produced is understanding that informs subsequent architectural choices.

Top-left: supervised coding agents

This is where Reisz's current team operates and where most of the talk lives. The code is long-lived and going to production, but the team's domain knowledge is too thin to build the automated verifications that would make autonomy safe. Before you hand work to autonomous agents, he argues, you need to know how to evaluate the domain, how to put guardrails around agents, and how to establish identity for them. Until then, a developer is in the loop at every step.

Top-right: unsupervised agents

As domain knowledge accumulates, the team shifts right. His concrete first steps into this quadrant are narrow, background tasks: simple code validators, and agents that check the specifications themselves. He credits another QCon speaker (from Qodo) with the underlying observation — that an LLM may not actually execute the rules you gave it even though the rules file is present. Reisz's own current mitigation is to make the model echo the rules back so a developer can eyeball compliance, and his stated ambition is to go further and have an agent test that the rules genuinely ran, as part of the delivery pipeline.

The point of the model is permission-granting as much as decision-making: being in the supervised quadrant does not mean you are failing at AI-first delivery. It means you have matched the approach to your actual position on the verification axis.

Engineering Discipline Under Non-Determinism

The reason a structured process is needed at all is that LLMs are non-deterministic — and, Reisz points out, that non-determinism is the entire value proposition. If a model returned identical output for identical input, we would call it a pure function and would not need a model. The engineering challenge is therefore to wrap a non-deterministic component in a process that is nonetheless repeatable.

Spec-driven development, and three flavours of it

Reisz notes that the industry has coalesced around spec-driven development, and points to a martinfowler.com post by his Thoughtworks colleague Birgitta Bockeler that examines the available spec kits — Kiro, Spec Kit, and Tessl. His practical position is that you do not need any of them to start: his team uses plain Markdown files, which any team could adopt on Monday morning.

Bockeler's post also disentangles three things people mean by "spec-driven":

Reisz reports he has not had tremendous personal success with spec-as-source, and self-describes his team's approach as spec-first: generate the spec, produce code from it, and treat the code as the deliverable. It is worth flagging a tension here for anyone copying the workflow. Bockeler's definition of spec-first has the specification discarded once code exists, but the workflow Reisz then demonstrates keeps the spec alive throughout — research answers are folded back into it, the chosen innovate option is recorded in it, planning is derived from it, and accepted drift found in review is absorbed back into it. By the definitions in the table, the demonstrated practice sits closer to spec-anchored than to spec-first. Take his label as the team's own vocabulary and the observed behaviour as the thing to imitate.

He quotes Prince Valluri of LinkedIn, from a podcast he recorded with engineers speaking at the same conference, with the line that crystallized it for him: a spec is the contract between the developer and the LLM. The spec is where you state the boundaries and what you expect back from this particular execution.

What makes a specification a good contract

For the content of that contract, Reisz draws on a paper from December of the previous year by Databricks founders Ion Stoica and Matei Zaharia, describing properties that make a specification useful for LLM-generated work. He aspires to five, and uses four of them regularly:

1. Proof-carrying output — include something in the spec that lets the result verify itself. In practice, he generates end-to-end tests alongside the implementation that validate what the specification claimed.
2. Step-by-step verification — the familiar engineering instinct to decompose a problem, plus checking at each step. He reads this as steps plus BDD: write the behaviours you want as behaviour-driven development scenarios before the code exists.
3. Execute and verify — after generating code, confirm the outputs do what they were supposed to.
4. Pre-conditions and post-conditions — what must be true to start, what must be true to finish. Long-standing contract-design vocabulary.
5. Statistical verification — because the same prompt run six times yields six different outputs, some validation has to be probabilistic rather than exact. This is the one he admits he does not do much of.

The BDD-first point deserves emphasis because it addresses a specific, very common failure. If you ask an LLM to generate tests after it has written the code, it fits the tests to the code that exists rather than to the behaviour you wanted, and the tests become brittle and near-worthless as regression signal. Writing the behaviour into the spec up front is simply test-first discipline re-applied to an LLM workflow.

RIPER-5: Putting the Model in Your Mental Mode

Reisz names a specific pain that most people using coding agents will recognize: you ask for something simple, and because of your rules files or accumulated context, the model returns layers of abstraction you did not want, while you were still trying to understand the problem space. What is missing is a way to put the LLM into the same mental mode you are currently in.

RIPER-5 is the team's answer, and it is borrowed rather than invented. The acronym comes from a March 2025 post on the Cursor forums by someone using the handle robotlovehuman; Reisz says plainly that this is "something we picked up". (Transcript note: he prefaces that attribution with "Actually, we did name it", which reads ambiguously. The forum post carrying the name predates the team he assembled roughly three months before the talk, so credit for the acronym belongs to that post, not to Thoughtworks.) It stands for Research, Innovate, Plan, Execute, Review. Crucially, each mode is defined as much by what the model is forbidden to do as by what it is asked to do.

Working through it in order: you start from the specification, then enter research mode, where the model's job is comprehension and interrogation — it asks you clarifying questions, and you feed the answers back into the spec. Innovate asks for three implementation options; you pick one and record the choice in the spec. Plan decomposes the specification into individual tasks, "just like you would prior to AI in a scrum team", such that anybody could pick one up. Execute writes the code. Review compares what was implemented against the contract and surfaces the delta.

Reisz observes that commercial tools are converging on the same idea: Cursor shipped plan and act modes, then debug mode, which he reads as the same mode-setting mechanism. He also relays a reaction from his colleague Nate Schutta, who said the process has nothing to do with AI — it is how he already works: understand the story, break it down, research, consider options, execute, check. Reisz's own framing is that RIPER-5 codifies the way engineers already work, which is what makes it portable to both interactive pairing and, later, multi-agent systems.

Because RIPER-5 is a logical construct rather than a framework, it is tool-independent. Reisz demonstrated it in Cursor, but explicitly said the same instructions work in Claude Code, Windsurf, or anything else — the difference is whether they land in a Cursor rules file or an AGENTS.md. In Q&A he added that he has seen RIPER-5 ports built specifically for Claude Code that you can simply clone. His team keeps rules and commands in a git submodule that every team member checks out, rather than in Cursor's own shared settings, specifically so they can migrate tools later without losing the work.

The public demo repo

The demo is not just slideware: Reisz ships a link to a public repository with the slide deck, and he walks through its README on stage. He describes it as carrying "a ton of information because it's a public repo shared", and the parts he calls out are the practical assets someone reproducing the workflow needs:

• How to set up and run the MCP server built in the demo.
• How to configure that MCP server in Cursor so the model can call it.
• How to set up a local development environment for the project.
• The AIFSD principles the team tries to follow, written down.
• The RIPER-5 rules and commands themselves, including the wording that defines what each mode means to the LLM, plus instructions for wiring them in as the git submodule and loading them into whichever tool's settings you use.

That last item is the reusable core. Reisz's guidance in Q&A was that whatever tool you use, you load these instructions into that tool's settings — the repo just happens to document the Cursor path in detail.

Architecture and Data Flow

The delivery loop his team runs, with the human review gate that defines the supervised quadrant. This diagram is my reconstruction of the flow from the talk's narration and demo, not a slide Reisz presented; the nodes and edges are assembled from what he described in sequence rather than copied from a source artifact.

flowchart TD
    S[Specification: Markdown contract] --> R[Research: read code, ask questions]
    R -->|answers fold back| S
    S --> I[Innovate: three options]
    I -->|chosen option recorded| S
    S --> P[Plan: one atomic task file per task]
    P --> H{Human pair reviews plan}
    H -->|adjust| P
    H -->|approve| E[Execute: generate code for task]
    E --> V[Review: compare output to plan, detect drift]
    V -->|drift accepted| S

The feedback edges back into the specification are the important part. Reisz raised in Q&A that when review detects drift you want to keep, you update the specification to absorb it, rather than regenerating code from a now-stale spec. Those edges are also the concrete reason the demonstrated loop behaves more like spec-anchored development than the spec-first label he gives it: the specification is never discarded, it is maintained.

The Worked Example: A Naive RAG Tool Becomes an MCP Server

To make the workflow concrete, Reisz reuses a system he built for a QCon London workshop in March. After each conference talk, the recording was uploaded to S3, which triggered a set of AWS Step Functions that transcribed the talk, chunked it, and loaded it into a vector database — naive RAG, in his words. He then exposed a single tool call from ChatGPT that hit an API backed by a dense retriever, so you could ask "what were the key takeaways from the platform engineering talk earlier today?" It worked, but it was fundamentally one-shot: a single retrieval against the vector database, with no ability to follow up.

Supplementary context, not from the talk: "dense retriever" means retrieval by embedding-vector similarity rather than keyword matching, and "naive RAG" is the common name for the simplest retrieval-augmented generation pipeline — chunk, embed, retrieve top-k, stuff into the prompt — with no reranking, query rewriting, or iterative retrieval.

The demo converts that one-shot tool into an MCP server, which gives the model multi-turn access: instead of a single retrieval, the LLM can decide to call the tool repeatedly, refining as it goes. In the recorded run, the model first asked which talks were platform engineering talks, then asked for the key takeaways of specific ones — Lesley Cordero on scaling organizations, Rachael Wonnacott on autonomy and fit for platform engineering teams — and only then decided it had enough to assemble an answer. That multi-turn behaviour is the whole reason for the migration.

The build itself followed RIPER-5. The specification was a single Markdown file named after a ticket ID from a free Jira account (SCRUM-5 in the demo), containing architecture components, acceptance criteria, definition of done, and an implementation tag — with the content of the research and innovate phases folded back in. Reisz notes candidly that he did not use BDD in this particular spec, despite recommending it. Planning produced a task list with dependencies, milestones, a critical path, and success criteria, and each task was written to its own .md file. In Q&A he explained why: tasks are kept atomic so different pairs can pick them up independently as the team ramps velocity, even though in practice they usually do not split them yet.

The supervised gate earned its place immediately. The generated plan for task 1 of this Python project did not create a virtual environment — nothing in the spec had asked for one. A developer amended the plan before execution rather than discovering the problem afterwards.

The ratio that should make you think

The final code was roughly five or six files at about fifty lines each. Reisz puts the ratio of specification and planning to generated code at about 10 to 1 for this example. (Earlier in the talk, discussing his production project, he gives the figure as 5 to 1; treat these as the speaker's rough experience rather than a measured constant.) His conclusion: software was never mostly about writing for-loops. The thinking required to produce this MCP server dwarfs the code, and "just generating fast code is not going to help us in creating production caliber software."

He closes the demo by pointing past the toy. Swap the corpus of conference talks for your architecture decision records, your merged PRs, or your accumulated engineering context, and the same small MCP server becomes a queryable memory of how your organization builds software — useful to a developer mid-Java-upgrade asking which files were last touched, and later usable as shared context between autonomous agents. That, he argues, is a practical foundation of agent memory reachable with very little machinery.

Sensible Defaults: What AI Amplifies

The third pillar of the talk is that AI is an amplifier of existing practice. Reisz enumerates the specific failure modes when the underlying foundation is weak:

• Code can be generated far faster than it can be reviewed, so defect volume scales with generation speed.
• Architecture boundaries leak when there are not enough evaluations in the system to verify that the boundaries still hold, producing leaky abstractions.
• You can build the wrong system efficiently if you do not understand the domain well enough to check you are building the right system, rather than trusting output.
• Traceability breaks down in regulated environments without deliberate guardrails.

Thoughtworks' countermeasure is a published set of sensible defaults: the practices they start from on every new engagement, before meeting a client where they actually are. The list Reisz names includes continuous integration, test-driven development, pair programming, trunk-based development, shifting security left, automated builds and deployment pipelines, continuous delivery, managing technical debt, and building for production as the goal. These are not adopted wholesale everywhere — some clients cannot support continuous deployment — but they are the shared starting position. The properties they buy are fast feedback, repeatability, and simplicity, and they map onto business-visible DORA metrics: mean time to restore, deployment frequency, lead time, and change failure rate.

Why pair when the LLM is your pair?

This is the objection Reisz says he fields most often, and he gives two answers. First, an LLM generates output based on the average of what it was trained on; it is a tool the pair uses, not a substitute for a second engineer's judgment. Second, and more pragmatically, reviewing the sheer volume of generated code and specification is exhausting — a pair is what makes thorough review sustainable at the pace AI-assisted generation produces work.

Trade-offs and Limitations

Several honest limits surfaced in the talk and Q&A, and they are worth preserving rather than smoothing over.

The evidence base for the productivity claim is thin on this project. Asked directly whether the output is faster, higher quality, or more feature-complete, and whether that is intuition or measurement, Reisz said he does not have DORA metrics in place after three months. What he has is developer intuition that they feel faster — and he immediately flags the well-known result, raised in other talks that day, that the feeling of being faster can be wrong when measured. The team is running developer surveys. He does point to a separate project that used a similar research-plan-execute-review vocabulary (not RIPER-5 by name), was fully instrumented with DORA metrics, and did show productivity improvement while holding MTTR constant. Treat that as a related data point, not as evidence for RIPER-5 specifically.

It is unproven on large legacy codebases. The current project is greenfield. Asked about large existing codebases, Reisz was explicit that he has not applied RIPER-5 to one. What he has used on legacy code is the domain-sensing quadrant. His argued extension is that research mode should work — instruct the agent to identify the patterns the codebase already uses and ask you how to apply the change within them, then fold answers back into the spec and iterate — but he labels this as reasoning rather than experience.

Latency and boredom are real. An audience member described the drag of waiting for a thinking model to reason, generate, update definitions, and generate code. Reisz's partial mitigation is the review stage: detect drift and update the specification to absorb it, instead of always regenerating code from the spec. He mentioned Cursor's newer agent mode as somewhat better for parallelism, and said the Cursor team recommended running multiple tabs — an approach he dislikes because of the cognitive load of tracking several concurrent threads. The dependency graph in his task plans exists partly so that future agents can parallelize independent tasks properly, which is his real hope for closing the gap.

Model choice is unstable. Asked whether different models suit different stages, he agreed: research is a thinking-heavy task where he tends to use Gemini, while Claude Sonnet is his preference for code generation. He explicitly noted that models leapfrog each other. On Gemini 3 his phrasing was hedged — "I've told my Google folks that Gemini 3 is much better. We'll see. I haven't got there yet" — so read it as a claim he has repeated rather than one he has verified. He has no fixed recommendation list.

The two-by-two is a conversation tool, not a law. Reisz says up front that you might use different axes, and that he disagrees with parts of his own model. The axes he chose — longevity and automated verification — are the ones that answer his question about supervision level, in a consultancy context where domain knowledge is the scarce resource.

Distributed brownfield estates are an open problem. Asked about microservices spread across many repositories, hard for humans to reason about, Reisz deferred tooling recommendations to a talk by Sepehr at the same conference, which he said worked through Claude Code and Cursor and broke down the different tools well. He confirmed only that RIPER-5 itself is framework- and tool-agnostic and applies fine to microservices, and that he has used Cursor against both monorepos and separate repos, sometimes mounting several projects at once. He did not claim a solution for cross-repo reasoning.

Additional risk worth naming, not from the talk: Reisz notes in passing that the original tool call shipped credentials such as API keys along to the server, and a system that indexes internal ADRs, PRs, and engineering context inherits the access-control and data-egress questions of everything it indexes. Any organization building the internal version of this demo needs to decide what the retrieval layer is allowed to return and to whom before it becomes shared agent memory.

Practical Takeaways

1. Answer "why aren't you fully autonomous?" with the verification axis. State the condition under which you will move right: the automated verifications you cannot build yet, and the domain knowledge you need first.
2. Place each workload in a quadrant before choosing tooling. Throwaway exploration, legacy comprehension, production feature work, and background validation are four different jobs with four different safety requirements.
3. Start spec-driven development with plain Markdown. You do not need Kiro, Spec Kit, or Tessl to begin. Get the contract written down first; adopt a kit later if it earns its place.
4. Write behaviour into the spec before the code exists. Tests generated after implementation get fitted to the implementation and turn brittle. BDD scenarios up front are the cheapest guard against that.
5. Give the model an explicit forbidden list per mode. "Research only, do not suggest, do not plan, do not code" is what stops an agent from racing ahead into an over-abstracted solution before you have understood the problem.
6. Keep rules and commands in a git submodule, not in your IDE's settings. Tool-agnostic prompt assets survive a switch from Cursor to Claude Code or whatever supersedes them.
7. Split the plan into one atomic task file per task. It preserves per-task context, lets different pairs work independently, and is a precondition for parallelizing tasks with agents later.
8. Keep a human gate on the plan, not just on the PR. The missing Python virtual environment was caught before execution, which is far cheaper than catching it in review.
9. Absorb accepted drift back into the specification. Otherwise the spec silently decays into fiction and every subsequent generation starts from a wrong contract.
10. Instrument before you claim a productivity win. Developer intuition that the team feels faster is not evidence; the speaker's own honesty about lacking measurement after three months is the model to follow.
11. Build a small MCP server over your own engineering context. ADRs, PR history, and design docs behind a multi-turn tool interface is a low-cost first step toward shared memory for both humans and future agents.
12. Reinvest in your sensible defaults rather than replacing them. Whatever baseline practices you already hold, treat AI adoption as a reason to fund them harder, not as a reason to retire them.

Key Terms

• AIFSD (AI-first software delivery) — Shifting AI as far left as possible in the SDLC, so it participates in specification and planning rather than only in code completion.
• Supervised coding agent — An agent whose plan and output a developer reviews at each stage before proceeding; the top-left quadrant.
• Unsupervised / background agent — An agent that completes work autonomously, safe only where automated verification is strong enough to catch its mistakes.
• Domain sensing — Using research agents to build an understanding of an unfamiliar codebase, its boundaries, seams, and patterns. The output is knowledge, not shipped code.
• Vibe coding — In popular usage, building by rapid, unreviewed LLM iteration, traced to Karpathy's March 2025 tweet; Reisz stresses that this popular reading misquotes the original. Used here strictly for short-lived exploratory work whose output is information rather than shipped software.
• Spec-first / spec-anchored / spec-as-source — Three spec-driven variants, differing in whether the specification is discarded after generation, retained as a reference, or treated as the only editable source of truth.
• Proof-carrying output — A specification property where the artifact includes the means of verifying its own correctness, in practice end-to-end tests derived from the spec.
• Statistical verification — Validating non-deterministic output probabilistically across multiple runs rather than by exact comparison.
• BDD (behaviour-driven development) — Expressing required behaviour as readable scenarios before implementation, so tests describe intent rather than existing code.
• RIPER-5 — Research, Innovate, Plan, Execute, Review; a mode-based prompting discipline where each mode has explicit permitted and forbidden actions.
• Drift — The divergence between what the plan specified and what was actually implemented; the object of the review mode.
• Sensible defaults — Thoughtworks' baseline engineering practices applied at the start of every engagement before adapting to client constraints.
• DORA metrics — Deployment frequency, lead time for change, change failure rate, and mean time to restore; the standard delivery-performance measures.
• Naive RAG — The simplest retrieval-augmented generation pipeline: chunk, embed, retrieve by similarity, insert into the prompt.
• Dense retriever — Retrieval by embedding-vector similarity rather than lexical keyword matching.
• MCP (Model Context Protocol) — A protocol for exposing tools to an LLM; used here to turn a one-shot API call into a multi-turn capability the model can invoke iteratively.

The most useful thing about the talk is not the specific two-by-two or the specific acronym — it is the posture of treating the level of agent autonomy as an engineering decision with stated preconditions, rather than as a badge of how modern your team is.

Reference: Wes Reisz, AI-First Software Delivery: Balancing Innovation with Proven Practices, QCon AI, published by InfoQ. Presentation length 50:33; notes based on the full published transcript including audience Q&A.