AI-Assisted Delivery Methodologies Compared: Which One Fits Your Team?

For tech leads, developers and delivery leads choosing how their team works with AI coding agents, and for Salesforce admins whose teams are starting to. The terms table and the admin-led team row cover what admins need.

TL;DR

• At least eight named approaches exist for delivering software with AI coding agents, from vibe coding and spec-driven development to AWS's AI-DLC and the Intent → Spec → Test model I have been developing.
• They fall into three layers: how one developer works with an agent, how you prove the agent built the right thing, and how a whole organisation is set up. Most teams use something from each.
• They differ on where the thinking happens and how hard they make it to ship code nobody checked.
• The evidence is mixed: METR's 2025 trial found experienced developers 19% slower with AI while believing they were faster, and DORA's 2025 report links AI with both higher throughput and more change failures.
• Match the method to the team: a fast test loop for small teams, specs where there are contracts and hand-offs, and linked specs, tests and gates for regulated multi-team work.

What You'll Learn

• What each of the eight approaches is, in plain terms, and where it came from
• A side-by-side comparison of artifacts, upfront cost, guardrails and failure modes
• The real pros and cons of each, including the ones their advocates skip
• Which approach fits which team structure, from a solo builder to a regulated multi-team programme
• How to mix approaches by risk in one repository

The Problem

Many teams adopted AI coding tools one developer at a time. Someone installs Cursor or Claude Code, gets faster at writing code, and the team's process stays the same. Then the pull requests pile up, review turns into rubber-stamping, and change failures creep up.

The tools moved faster than the methods. There are now named methodologies for working with agents, and vendors, consultancies and practitioners each have one. They overlap, they use the same words for different things, and few of them say which kind of team they suit.

Common Questions This Article Answers:

• Is spec-driven development just waterfall with an AI on the end?
• Do I need a methodology at all, or can my team keep vibe coding with tests?
• Which approach fits my team, and does that change as it grows?

Quick Answer

Choose by team shape. A solo builder should use vibe coding for throwaway prototypes and a minimal loop (fast tests, small commits, agent iterating against the diff) for anything real. A small product team should add test-first discipline so agents cannot write tests shaped to pass. Teams with API contracts, migrations or several hand-offs benefit from spec-driven development (spec-kit or Kiro). Enterprise and regulated programmes with many parties need something heavier: AI-DLC's team rituals, or a model that links intent, spec and tests by ID and checks the links in CI. Whatever you pick, put the WIP limit on the review queue, because that is where AI delivery jams.

A few words you will see

The Eight Approaches, in Three Layers

These eight are not all alternatives to each other. Some describe how one developer works with an agent; some describe how you prove the agent built the right thing; some describe how a whole organisation is set up. A team might use AI-DLC for its rituals, harness engineering as its platform strategy, and Intent → Spec → Test for its riskiest changes, all at once.

Layer 1: The developer loop

1. Vibe coding

Andrej Karpathy named it in February 2025: you describe what you want, accept what the model writes, and judge it only by running it. You do not read the code.

• Pros: fastest way from idea to something working; great for learning and for throwaway prototypes.
• Cons: nobody understands the code; bugs and security holes ship silently; it falls apart once the code has to be maintained or extended.
• Use it for: spikes, demos, personal tools, anything you would happily delete.

2. The minimal loop

A lean instruction file (CLAUDE.md, AGENTS.md), a fast test suite, small commits, and an agent that iterates against git diff until the tests pass. No meta-framework. This is the working style Simon Willison and many experienced practitioners write about.

• Pros: almost no overhead; keeps a skilled developer in control; works with any tool.
• Cons: only as good as the tests and the developer; the agent can write tests that pass for the wrong reason; does not scale well past people who share context.
• Use it for: experienced developers on codebases they know.

3. Structured-Prompt-Driven Development (SPDD)

From Thoughtworks' internal IT team: prompts are first-class artifacts, versioned in the repository next to the code and reviewed in the same pull requests.

• Pros: makes prompts reviewable and reusable across a team; fits existing code review.
• Cons: governs the instructions, not the outcome; a well-reviewed prompt can still produce wrong code.
• Use it for: teams standardising how they prompt, especially across many developers.

Layer 2: Verification and contracts

4. Test-first agents

TDD applied to agent-written code. Tests are written, or at least specified, before the agent writes code, and two extra rules stop gaming: new tests must fail on the old code before they pass on the new, and some tests are held out from the agent entirely and run only in CI.

• Pros: strongest defence against tests written to pass; makes "done" mechanical; mutation testing can check the tests themselves.
• Cons: someone has to write good tests first, which is a skill many teams lack; covers behaviour, not whether the change was the right one.
• Use it for: business logic, security rules, anything where a wrong answer is expensive.

5. Spec-driven development (SDD)

Write a specification first, and let it drive the agent. Birgitta Böckeler of Thoughtworks describes three levels: spec-first (write a spec, use it, let it go), spec-anchored (keep the spec and update it as the feature changes), and spec-as-source (people edit the spec; code is generated from it). The main tools are GitHub spec-kit (a constitution of project principles, then /specify, /plan and /tasks), AWS Kiro (requirements.md in EARS notation, "WHEN [event] THE SYSTEM SHALL [behaviour]", plus design.md and tasks.md) and Tessl, which aims at spec-as-source.

• Pros: fewer invented field names and defaults; reviewable intent; good for contracts and anything another team depends on.
• Cons: high upfront cost; specs drift from code unless something checks them; critics call it "waterfall in Markdown", and Böckeler notes the resemblance to model-driven development.
• Use it for: APIs, data contracts, migrations, features with several hand-offs.

6. Intent → Spec → Test

The model I have been developing, which combines several of the above. Three layers, each written by people before the agent starts: intent (the outcome and a "must never" list), spec (concrete rules in when/then form), and tests (visible ones the agent iterates against, and held-out ones it never sees). Every item cites the one above it by ID, and CI fails the build if a must-never has no rule, a rule has no test, or a must-never has no held-out test. A Salesforce example: "a guest user must never read Contact records" becomes a rule and a held-out Apex test that only CI can see.

• Pros: makes gaps visible before any code is written; ties business intent to machine-checked evidence; scales to shared platforms where several applications inherit the same must-nevers.
• Cons: the most upfront work of the eight; applied to every change it becomes a traceability bureaucracy; still unproven on platforms where most change is configuration rather than code.
• Use it for: high-risk changes only, such as authentication, permissions, billing and guest access. The how-to, including where to keep held-out tests and when not to use it, is in Intent → Spec → Test: Linking Must-Nevers to Held-Out Tests.

Layer 3: Operating model

7. AWS AI-DLC (AI-Driven Development Lifecycle)

Introduced by AWS in July 2025 and available as a workflow in Kiro. Three phases: Inception (AI turns intent into requirements and units of work, validated by the team in "mob elaboration" sessions), Construction (work happens in "bolts" of hours or days instead of sprints, with "mob construction" sessions on design decisions), and Operations.

• Pros: a full lifecycle, not just a coding technique; the mob rituals keep the whole team engaged in what AI proposes; replaces sprints with something sized for agent speed.
• Cons: heavy for small teams; strongest inside the AWS toolchain; the rituals need facilitation skill to stop them becoming ceremony.
• Use it for: larger teams adopting AI across the whole lifecycle, particularly on AWS.

8. Harness engineering ("humans on the loop")

Kief Morris of Thoughtworks distinguishes humans in the loop (checking every output, which degrades into rubber-stamping at volume) from humans on the loop (designing the system that produces and checks the software). The specs, checks and workflow guidance around the agent form its harness.

• Pros: the right mental model for scale; shifts senior effort to guardrails that protect everyone.
• Cons: it tells you to build a harness but not what to put in it; you still have to choose the checks.
• Use it for: tech leads and architects designing how a whole team works with agents.

Context engineering, which all of them depend on

What the agent can see decides what it gets right. Instruction files, narrow tools that return only what is needed, and pruned context matter more than prompt wording. My own measurements of how much a Salesforce question costs through different tools show how much the tool design changes cost and accuracy.

Side-by-Side Comparison

The approaches that put the thinking in tests or gates are the ones that stop unchecked code, because a machine enforces them. The ones with the highest upfront cost pay for themselves only where mistakes are expensive.

Mixing Approaches by Risk in One Repository

Most teams should not pick one approach for everything. Route each change by how much damage a mistake would do:

How to route changes into tiers automatically is covered in the Intent → Spec → Test deep dive.

Starting From an Existing System

Most spec-driven writing assumes a system you understand. In an older org or a legacy monolith, map current behaviour first with a read-only agent and characterization tests (Michael Feathers' term for tests that record what the system does today), and only then write the new spec and must-nevers.

Which Team Structure Fits Which Approach

A note for Salesforce teams

Most of these approaches were designed for code, and a lot of Salesforce delivery is configuration. Test-first and mutation testing apply cleanly to Apex and only partly to Flows and metadata, where checks have to be Flow tests and queries against what was deployed. For admin-led teams the spec half (clear rules, must-nevers) pays off immediately; the test-and-gate half still needs adapting.

Whatever the approach, the agent's own access needs governing too: which MCP servers can reach your orgs (third-party MCP server governance), and a CI deploy user that holds only what it needs (deployable permission sets for a delivery team).

What Changes Whichever You Pick

• The bottleneck moves to review. Agents fill "in progress" quickly. Put the WIP limit on pull requests waiting for checks and review.
• The Definition of Done becomes CI gates. Anything a machine can check should be a required check, not a checklist item.
• Velocity stops meaning anything. Pull request counts balloon. Track change failure rate and lead time first.
• Measure before and after. METR's finding that people felt faster while being slower is the reason to trust measurements over impressions.

Frequently Asked Questions

Q: Is spec-driven development just waterfall?

A: It can become waterfall if the spec has to be complete before anything starts and nobody revisits it. The spec-first and spec-anchored styles avoid that by keeping specs small (one feature, one change) and updating them as the feature evolves. The risk grows as the spec gets more detailed: a spec precise enough to remove every ambiguity is effectively code, written in a worse language.

Q: Which approach gives the best productivity gains?

A: There is no good comparative data yet. METR's randomized trial found a 19% slowdown for experienced developers using early-2025 tools on code they knew well, and DORA's 2025 report found throughput up but instability up too. Whichever approach you choose, baseline your cycle time and change failure rate before rollout and measure again after a few months.

Q: Do these approaches replace Scrum?

A: Mostly they replace parts of it. AI-DLC replaces sprints with bolts. The others leave the cadence alone but change what "ready" and "done" mean, and move the bottleneck from building to checking. The closest ancestor of most of them is XP: test-first, continuous integration and small releases.

Key Takeaways

• The approaches sit in three layers, and most teams need one from each. They are not eight rival choices.
• The ones that put the thinking in tests and gates are the ones machines can enforce.
• Spend upfront effort in proportion to what a mistake would cost, and route changes by risk.
• Review is the new bottleneck in every approach. Plan for it before adopting any of them.

What's Next?

Recommended Reading:

• Intent → Spec → Test: Linking Must-Nevers to Held-Out Tests, and When Not To, the deep dive on approach 6
• Salesforce in Claude: Token Cost of OrgPulse vs DX MCP vs the sf CLI, measured cost of different agent tooling
• Third-party MCP server governance for Salesforce, controlling what agents can reach
• Post-ForcedLeak: Hardening Agentforce Against Prompt Injection, the agent as an attack surface

Action Items:

1. Write down how your team uses agents today, and which of the eight approaches it is closest to.
2. Measure how long changes take from request to production, and how often a release causes a problem, before changing anything. If you deploy with change sets or DevOps Center, a simple log of deployments and rollbacks is enough to start.
3. Pick one approach for one type of change (for example, test-first for business logic) and run it for a month before expanding.

Resources & References

• Kief Morris: Humans and Agents in Software Engineering Loops
• Birgitta Böckeler: Understanding Spec-Driven Development: Kiro, spec-kit, and Tessl
• Structured-Prompt-Driven Development (SPDD)
• AWS: AI-Driven Development Life Cycle
• Kiro: Specs
• GitHub spec-kit practical guide
• METR study, summarised by Simon Willison
• DORA 2025 State of AI-assisted Software Development (InfoQ)