Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices

Wes Reisz · rss · 2025-01-01 source ↗ Reader 🖥️

Agentic Engineering Agile & XP AI as Amplifier Feedback Loops Spec-Driven Development Vibe Coding

AI-first software delivery is not one-size-fits-all: teams should choose between supervised and unsupervised agentic approaches based on code longevity and their ability to verify outputs automatically, using structured human-AI collaboration (RIPER-5) to preserve engineering discipline — because AI amplifies whatever practices you already have, good or bad.

practical · conference presentation (QCon AI) with audience Q&A — practitioner report on adopting AI-assisted coding in a consultancy engagement — First-person account from a Thoughtworks technical principal describing a supervised AI-first approach on a three-month-old client project. Genre: experience report with prescriptive framework (RIPER-5). Includes live demo of building an MCP server.

Structure

Part	Role
Context and motivation	Establishes the speaker's situation: a Thoughtworks consultant three months into an AI-first greenfield project, constantly asked why he isn't using fully autonomous agents.
The two-by-two model (longevity x automated verification)	Introduces the decision framework: four quadrants (exploratory/vibe coding, domain sensing, supervised agents, unsupervised agents) mapped against code longevity and degree of automated verification.
Spec-driven development	Argues that specifications are the contract between developer and LLM, and outlines five qualities (proof-carrying output, step-by-step verification, execute-and-verify, pre/post-conditions, statistical verification) that make specs effective.
RIPER-5 framework	Presents the five-mode workflow (Research, Innovate, Plan, Execute, Review) with explicit forbidden actions per mode, codifying how engineers already work into a protocol the LLM can follow.
Engineering discipline amplification	Argues that AI amplifies existing practices — good or bad — so foundational practices (CI, TDD, pairing, trunk-based development, continuous delivery) are more important than ever.
MCP server demo with RIPER-5	Concrete demonstration of the full RIPER-5 workflow converting a single-shot tool-call into a multi-turn MCP server, showing the 10:1 spec-to-code ratio.
Q&A	Surfaces practical concerns: applicability to brownfield/large codebases, boredom during wait times, parallelization of tasks, model selection per RIPER stage, and the absence of hard DORA metrics.

Key terms

AI-first software delivery (AIFSD) Agentic Engineering
An approach that shifts AI usage as far left as possible in the SDLC — not synonymous with fully autonomous agents, but a spectrum from supervised to unsupervised depending on context.
RIPER-5 Agentic Engineering
A five-phase protocol (Research, Innovate, Plan, Execute, Review) that puts the LLM into the same mental mode as the developer, with explicit forbidden actions per phase to prevent the LLM from jumping ahead.
supervised vs. unsupervised agents Agentic Engineering
Supervised: developer actively pairs with and reviews agent output at each step. Unsupervised: agent operates autonomously with automated guardrails. The choice depends on domain knowledge and verification capability.
code longevity
How long the generated code will live — from throwaway explorations to long-lived production systems. Higher longevity demands more rigor.
degree of automated verification Feedback Loops
The team's ability to automatically verify that generated code is correct, which depends heavily on domain knowledge and available test infrastructure.
spec-driven development Spec-Driven Development
Using Markdown specifications as the contract between developer and LLM, with three variants: spec-first (generate then discard), spec-anchored (keep and reference), spec-as-source (code is byproduct).
sensible defaults Agile & XP
Thoughtworks' baseline engineering practices (CI, TDD, pair programming, trunk-based development, continuous delivery) that every engagement starts with before adapting to client context.
vibe coding Vibe Coding
Exploratory, throwaway coding where speed of learning matters more than code quality — valid for POCs and information gathering, not for production delivery.

Propositions

explicitdevelopedAI-first software delivery is not a one-size-fits-all approach: the choice between supervised and unsupervised agents should be driven by code longevity and the team's ability to verify outputs automatically.conf: high
refines ←A model that produces code which compiles and passes the tests it was given is not the same as a model that produces robust code · p1 — Marcus qualifies the automated-verification axis of the supervised/unsupervised framework: compiling and passing tests is not the same as robustness, so automated checks alone under-verify.
explicitdevelopedTeams should start with supervised agents and progressively move toward unsupervised as they accumulate domain knowledge and build automated verification capabilities.conf: high
refines ←LLMs Corrupt Your Documents When You Delegate · p8 — The DELEGATE-52 finding that even frontier models silently corrupt long delegated workflows adds an empirical caution to the advice to progressively move toward unsupervised agents.
explicitThe specification is the contract between the developer and the LLM, and its quality determines the quality of the generated output.conf: high
explicitPutting the LLM into explicit modes (Research, Innovate, Plan, Execute, Review) with forbidden actions prevents it from jumping ahead and producing over-abstracted or premature solutions.conf: high
explicitestablishedAI amplifies existing engineering practices — if foundations are weak, AI will amplify the weaknesses; if strong, AI will amplify the strengths.conf: high
supports ←AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action · p1 — Both state AI amplifies whatever engineering practices (weak or strong) already exist, from independent practitioner sources.
supports ←Finding Comfort in the Uncertainty · p10 — Restates the amplification thesis as a convergent retreat finding: AI magnifies existing conditions — strong foundations get faster, weak ones get messier.
supports ←11) AI-spesial med Vilde Opsal og Anders Sveen · p5 — DORA-style empirics confirm AI is a force multiplier in both directions: strong practices amplified, weak practices made worse faster.
supports ←Presentation: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs · p3 — Near-identical claim reached independently: AI amplifies existing engineering practices, whether strong or weak.
extends ←Looking back at the Future of Software Engineering unconference · p12 — Adds a temporal-divergence dynamic to the amplification thesis: because agentic engineering amplifies existing practice, early process-codifiers continuously widen the gap over slow adapters, with small firms gaining first and large firms risking fragmentation.
supports ←Thomas Nys' Post · p6 — Near-identical thesis stated more generally: AI amplifies existing engineering practice, so weak foundations get amplified into worse outcomes rather than fixed by AI.
supports ←TBM 428: Yes, Robot. Yes, Boss? · p1 — Generalizes the engineering-specific 'AI amplifies weak vs strong foundations' claim to organizational dynamics writ large.
explicitcontestedThe ratio of specification and planning effort to generated code is approximately 10:1, demonstrating that software delivery is primarily about thinking, not typing.conf: high
contradicts ←Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project · p9 — Wolff declares extensive upfront design and planning obsolete, against the 10:1 specification-to-code effort prescription.
extends ←Sam Hatoum's Post · p5 — Generalizes the empirical 10:1 spec-to-code effort ratio to its limiting case: with instant implementation, 100% of human effort goes to specification and design.
explicitcontestedPair programming remains valuable in AI-first delivery because reviewing AI-generated code is exhausting for a single developer and because the LLM is a tool, not a true pair — it generates output based on the average of its training data.conf: high
contradicts ←Patterns for Reducing Friction in AI-Assisted Development · p4 — Garg argues treating AI as a teammate (not a tool) yields better outcomes, while the AI-first talk insists the LLM is a tool and not a true pair.
explicitcorroboratedTests generated after code is written tend to be brittle because the LLM fits the test to the code rather than to the intended behavior; BDD specifications written before code avoid this trap.conf: high
supports ←[FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p13 — Same mechanism independently observed: without test-first discipline the LLM fits tests to the implementation instead of to intended behaviour.
extends ←Harness engineering for coding agent users · p9 — Takes the brittleness of post-hoc AI-generated tests further: reliance on AI test suites is not good enough for behavioural verification in high-autonomy workflows generally.
extends ←Podcast: Formal Methods for Every Engineer in an AI-Powered Future · p7 — That doc argues tests written after code are brittle because the LLM fits the test to the code, and specs-before-code avoid it. Model-based testing extends this: the tests are derived from a model that is deliberately MORE ABSTRACT than and independent of the implementation, so they cannot be fitted to the code at all.
explicitRIPER-5 codifies how good engineers already work — it is not a novel methodology but an explicit protocol that makes implicit engineering habits communicable to an LLM.conf: high
implicitdevelopedThe 95% failure rate of AI projects to deliver ROI is substantially caused by organizations not matching their AI approach to their actual context and capabilities.conf: high
extends ←Everyone Is Talking About Context for AI. Here's What Most Companies Still Miss. · p1 — This doc's McKinsey stat (90% adopt, 10% scale) is a concrete data point for the broader claim that most AI projects fail to deliver ROI because organizational approach isn't matched to actual context.
implicitDomain knowledge is the primary constraint on moving from supervised to unsupervised agents — it is not a technology problem but a learning problem.conf: high
explicitcontestedThe non-determinism of LLMs is a feature, not a bug — if they were deterministic, they would be pure functions and would not provide the generative capability that makes them valuable.conf: high
contradicts ←Article: Multi-Agent AI for Production Security Operations: An A2A and MCP Architecture in a 5G Core · p2 — Context-bound tension: this article treats LLM non-determinism as intolerable and disqualifying for production security actions, while the other article frames non-determinism as a general feature of LLMs (the source of their generative value) — the same property is a liability here and an asset there, depending on the stakes of the output.

Arguments

Teams should use a supervised agentic approach when they lack domain knowledge and automated verification capabilities, and progressively shift toward unsupervised as those grow. strength: medium

Explicit premises:

Three months into a new client engagement, the team knows too little about the domain to safely let agents operate unsupervised.
Unsupervised agents require the ability to evaluate their outputs automatically, which requires domain understanding.
The team is already beginning to shift rightward as domain knowledge accumulates.
95% of AI projects fail to deliver ROI, suggesting many organizations misapply autonomous approaches.

Implicit premises:

The cost of agent errors in production is high enough that unsupervised operation without verification is irresponsible.
Domain knowledge acquisition is inherently time-consuming and cannot be short-circuited by the AI itself.

Inferences:

Since verification depends on domain knowledge, and domain knowledge takes time to build, the right approach at any given moment is determined by where you are on that learning curve.

RIPER-5 produces better outcomes than unconstrained LLM interaction because it prevents premature solution generation. strength: medium

Explicit premises:

LLMs, unconstrained, produce over-abstracted solutions when the developer just wants to explore.
Forbidding the LLM from coding during research/innovate/plan phases keeps it aligned with the developer's current intent.
The framework mirrors how experienced engineers already work, which validates its structure.
Review phase catches drift between plan and implementation.

Implicit premises:

LLMs are stateless reasoning systems that benefit from external state management (the mode protocol) imposed by the human.
The cognitive overhead of enforcing modes is lower than the rework cost of unconstrained generation.

Inferences:

Explicit mode-setting compensates for the LLM's lack of meta-awareness about where in the development lifecycle the developer currently is.

Engineering discipline (CI, TDD, pairing, trunk-based development) is more important in AI-first delivery than in traditional delivery. strength: high

Explicit premises:

AI can generate code much faster than humans can review it.
Architecture boundaries can leak when defects scale faster than review.
If foundations are weak, AI amplifies the weaknesses.
Pair programming helps manage the review burden of AI-generated code.

Implicit premises:

The rate of code generation has outpaced the rate of quality assurance improvement, creating a growing gap that only discipline can close.
Most organizations' engineering foundations are not as strong as they believe.

Inferences:

The amplification property of AI means that the marginal cost of weak discipline is now higher than it was pre-AI, making investment in discipline more urgent.

Narratives

Reisz describes being on a new Thoughtworks client engagement building a knowledge graph for a large U.S. state, three months in, constantly asked why he isn't using fully autonomous agents.
→ Establishes the real-world tension that motivates the talk: the pressure to adopt maximally autonomous AI versus the practitioner's judgment that context matters. Makes the framework feel earned rather than theoretical.
During a client conversation, Reisz quickly vibe-codes a prototype while the product person talks, then shows it to the client who says 'No, not at all. That's completely wrong. Please don't ever do that again.' — and Reisz considers this a success.
→ Rehabilitates vibe coding as a legitimate information-gathering technique by reframing 'wrong' output as valuable learning. Illustrates the exploratory quadrant of the two-by-two.
The MCP server demo: converting a single-shot QCon question-answering tool into a multi-turn MCP server using the full RIPER-5 workflow, resulting in 5-6 files of ~50 lines each after extensive specification.
→ Makes the 10:1 spec-to-code ratio tangible and demonstrates that the framework is not just theory — it produces working software through a disciplined process.
Nate Schutta, a Thoughtworks colleague, sees RIPER-5 and says: 'I don't know that it has anything to do with AI. That's how I work anyway.'
→ Validates RIPER-5 by showing it codifies existing expert practice rather than imposing alien process. Makes adoption feel natural rather than burdensome.
The $100-bill visualization: $1.3 trillion in $100 bills laid end to end would circle the earth 50 times, yet 95% of AI projects fail to deliver ROI.
→ Creates visceral scale contrast to motivate the need for a more thoughtful approach to AI adoption.

Questions addressed

✅ Why not use a fully autonomous multi-agentic approach for software delivery?
Because the choice depends on domain knowledge and verification capabilities. Without sufficient domain understanding, unsupervised agents cannot be safely verified, so supervised approaches are appropriate.
✅ How should teams decide between supervised and unsupervised agentic workflows?
Use the two-by-two model: map code longevity (y-axis) against degree of automated verification (x-axis). Choose the quadrant that fits your current context.
✅ How do you prevent LLMs from generating over-abstracted or premature solutions?
Use RIPER-5: put the LLM into explicit modes with forbidden actions per phase so it cannot jump ahead to code generation before research, innovation, and planning are complete.
⭕ Does AI-first delivery actually improve productivity metrics?
Reisz admits he does not yet have DORA metrics for his current project. Developers 'feel faster' but he acknowledges that feeling can be wrong. A similar project elsewhere has instrumented DORA metrics showing productivity gains while holding MTTR constant.
⭕ Does RIPER-5 work for large, existing (brownfield) codebases?
Reisz has not applied RIPER-5 specifically to large brownfield codebases but sees no reason it wouldn't work, since the framework mirrors how engineers already approach such work.
⭕ How do you handle the boredom/wait-time problem of supervised AI workflows?
Partially addressed: the review stage can shortcut some iteration; agent mode allows more flow-like interaction; parallelizing tasks across pairs is the eventual goal. No fully satisfying answer given.
✅ Is pair programming still necessary when the LLM is your 'pair'?
Yes — the LLM is not a pair but a tool that generates average-of-training-data output. Human pairs are needed because reviewing AI-generated code is exhausting for a single developer.

Gaps

missing evidenceThe entire framework is grounded in a single three-month engagement. No DORA metrics, no controlled comparison with unconstrained approaches, no data on defect rates or rework costs. The talk is honest about this, but it means the prescriptive claims rest on practitioner intuition rather than empirical evidence.
Read next: Studies measuring productivity and quality outcomes of structured vs. unstructured AI-assisted development; DORA-instrumented teams using agentic workflows.
unasked questionThe talk never asks whether the 10:1 spec-to-code ratio is efficient or merely shifts the bottleneck from writing code to writing specifications. If specifications themselves become the primary artifact, what are the failure modes of spec-driven development? Can specifications be wrong in ways that are harder to detect than buggy code?
Read next: Literature on specification errors in formal methods; research on whether natural-language specifications introduce ambiguity that undermines the 'contract' metaphor.
closed by[FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — Pocock addresses the spec-bottleneck question directly: optimizing the PRD beyond the alignment point yields little (p28), specs-to-code without reading code fails (p5), and in-repo spec documents rot and poison later agent sessions (p17).
implicit premiseRIPER-5's forbidden-actions model assumes that constraining the LLM to one phase at a time produces better outcomes. But the LLM may actually benefit from lookahead — considering implementation feasibility during planning, or discovering specification gaps during coding. The framework may be imposing a waterfall micro-structure on a process that benefits from iteration.
Read next: Research on exploratory programming, the role of prototyping in specification discovery, and whether phase gates help or hinder creative problem-solving in AI-assisted development.
closed byNew Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets — PARTIAL, and pattern-not-evidence. That gap asks whether phase-gating helps or hinders AI-assisted work and points its reading direction at 'the role of prototyping in specification discovery'. This video supplies the practitioner workflow that reading direction names: a prototype-before-spec pattern (p8) that raises decision fidelity with a cheap concrete artifact, and phase-gated planning via Wayfinder's typed, session-sized sub-issues (p7). It takes the pro-prototyping, pro-phase-gating SIDE but offers no help-vs-hinder evidence — it shows the workflow exists and is used, not that the gates improve outcomes.
tensionThe talk argues that (1) AI amplifies whatever practices you have, and (2) pair programming is essential for reviewing AI output. But if your practice is already strong enough to benefit from amplification, why is the review burden so high? The high review burden suggests the AI is generating output that doesn't match team standards — which is the amplification-of-weakness problem the talk warns about.
Read next: Research on AI code quality vs. human code quality at different experience levels; studies on code review effectiveness for AI-generated code.
scope limitationThe framework addresses coding agents exclusively. It does not address other AI applications in the SDLC (testing agents, deployment agents, monitoring agents, design agents) or how the supervised/unsupervised choice might differ for those. The 'shifting left' claim is broader than the framework can support.
Read next: End-to-end SDLC automation literature; agent architectures for testing, deployment, and operations.
unasked questionThe two-by-two model places 'degree of automated verification' on the x-axis but never asks who builds the verification infrastructure. If the team is already stretched doing 10:1 spec work and exhausting code review, when do they build the automated verification that enables the rightward shift to unsupervised agents?
Read next: Research on testing infrastructure investment patterns; the bootstrapping problem in test automation for new domains.
closed byHarness engineering for coding agent users — Answers who builds the verification infrastructure: coding agent users themselves build an outer harness as an ongoing engineering practice, distributing computational and inferential controls across the lifecycle by cost and criticality.

Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents