Agile Solved the Cost of Change. AI Solves the Cost of Starting.

The Vesting Rule Nobody Could Confirm on Paper

Ask a plan administrator to explain the vesting rule for the plans that came over in the 2004 acquisition and you will get a clear answer in about ninety seconds, exceptions included. Ask the same person to confirm a user story that describes that rule and the answer takes three weeks, because a story is a document, and documents get interpreted. Put the rule on a working screen with a terminated participant and an outstanding loan on it, and the same person will spot the mistake before the demo is over.

That is the whole argument of this paper in one scene. The people who know how a retirement plan actually works explain it well in conversation and struggle to confirm it in writing. They recognize a mistake immediately when they see it run. For twenty years, the methods we used to build software put weeks of writing between the conversation and the screen, because the screen was expensive. It is not expensive anymore.

We call the method that follows from that Beyond Agile. It pairs the person who knows the business with a developer working with AI, and goes from that conversation to a working, validated proof of concept without first building a backlog of epics, user stories and sprint plans. It keeps the discipline Agile taught the industry: review gates, traceability and testing. What it removes is the delay.

The Weeks Before the First Screen

The Agile Manifesto asked for working software over comprehensive documentation and customer collaboration over contract negotiation. That was the right instinct, and it still is. Our own tagline begins with "Be agile," and nothing in this paper argues with it. What this paper argues with is the setup stack that grew up around those values once Agile became the industry standard: discovery sessions, epic and story decomposition, acceptance criteria for every story, estimation and capacity planning, a sprint zero for environments and tooling, and sprint planning before anyone writes a line.

Every one of those steps has a purpose. Together they put weeks, and on larger programs months, between the moment a client explains what they need and the moment they can react to something that runs. That time is rarely tracked as a cost. In our experience it is often the longest single stretch of the project, and it is the stretch in which requirements are interpreted and reinterpreted through documents. Misunderstandings surface late, usually in the first sprint review, after the backlog has already been built around them.

Retirement makes this gap more expensive than most industries do. Plan rules, vesting schedules, loan provisions, contribution limits and remittance formats are detailed and full of exceptions, and the exceptions are the business. Jennifer Crawley has described on this site how retirement programs clear discovery cleanly and then stall in the messy middle, re-implementing rules that exist in legacy code but not in any document. The setup stack is where that gap opens: the rules were in someone's head, then in a story that approximated them, and only much later in software anyone could check.

What Changed

The bottleneck in software delivery has moved from building to describing and validating. Current AI coding tools can take a clear plain-language description and produce data models, business rules, screens and working code in a fraction of the time a team needed three years ago. In GitHub's controlled experiment, developers with an AI pair programmer completed a task 55.8 percent faster than the control group. Our own experience on retirement work, described below, is that a first working version of a bounded application now takes days.

Two cautions belong next to that claim, because they shape the method. In a 2025 randomized trial, experienced developers working in mature codebases were 19 percent slower with AI tools, while believing afterward that they had been 20 percent faster. And Google's 2024 DORA report found that higher AI adoption was associated with lower software delivery throughput and lower stability, even as code quality and review speed improved. Speed at the keyboard does not become speed in delivery on its own. It does so when the description is good and the output is checked by someone who knows what right looks like. Both of those are retirement-domain skills, not AI skills, which is why Beyond Agile is built around a pair of people rather than around a tool.

Three capabilities make the method possible:

• Understanding narration. AI can turn an unstructured working session into a structured set of entities, rules, roles and screens, with a list of what it could not resolve.
• Generating working software. It can produce a functioning application from that structure, not just fragments of code.
• Changing in one pass. A change described in a sentence can be applied across the data model, the logic and the screens together. The same step can check a new specification against the rules already implemented in neighboring applications, so a filter defined for one system does not contradict the one the enterprise already runs.

When building becomes cheap, the economics of setup flip. Detailed up-front decomposition was a hedge against expensive rework. If rework now takes hours, it is faster to build a version, show it and correct it than to plan every story in advance.

Others are working on the same idea. GitHub released an open-source toolkit for spec-driven development in September 2025. Beyond Agile shares the premise and differs in its starting point: a stakeholder's own narration rather than a written specification, because in a regulated business domain the specification is usually the thing nobody can write down, and a validated proof of concept as the goal rather than code.

The Beyond Agile Process

Beyond Agile has five steps, run by a pair: the client's product owner or subject-matter expert, and a Convergent developer working with AI. The business owner talks, the developer and the AI build, and both watch the same screen. The only loop in the process is driven by stakeholders reacting to working software.

A word on what we mean by a proof of concept. On this site we have been clear that production automation, not a demo, is the standard. The proof of concept in this method is not a throwaway. It is a working first version, built on the real data structures with masked or synthetic data that looks like the client's, validated by the people who will use it, that the production build starts from.

1. Narrate. The business owner or subject-matter expert describes the system to the developer, in their own words: who uses it, what they do, which rules apply, what data moves where and what the exceptions are. Narration can be a live working session, a recording, existing procedure documents or a mix. The developer guides the conversation so that edge cases are covered. Nobody writes user stories.

2. Synthesize. The developer uses AI to turn the narration into a structured specification, often while the session is still running: entities and fields, business rules, roles and permissions, screens and workflows, and a list of open questions. The subject-matter expert reviews that specification first, then the project team. This is the first review gate and the main record of what was agreed.

3. Generate. The developer directs AI to build the proof of concept from the approved specification: data model, business logic and user interface. The developer reviews the code and connects masked or synthetic data that looks like the client's. Design is a deliberate step here, not a by-product. AI tools have recognizable default layouts, and a proof of concept that looks like every other generated application is harder to validate and harder to own, so a short design pass covering brand, layout and the interaction patterns the client's users already know happens before anyone outside the team sees a screen.

4. Validate. Stakeholders use the working proof of concept and react to it, usually with the pair in the room. Feedback is concrete because it is about real screens and real calculations, not about how a document was interpreted.

5. Iterate. Changes are narrated the same way the original requirements were: "Loans should not be allowed if the participant is terminated." The change updates the specification first, and the proof of concept is regenerated from it, so the specification and the software stay in step. A cycle typically takes hours or days rather than a sprint. Progress is tracked through milestones, each an accepted increment of working software, rather than through epics, stories and velocity.

When the decision owner accepts the proof of concept, the last milestone of the phase, the specification, the code and the decision history move into the production build. That build may continue with Beyond Agile or hand off to an existing Agile delivery team, which starts from a validated design instead of a blank backlog.

What People Do Instead

Beyond Agile changes the shape of the team and what people spend their time on. It does not remove the need for skilled people. A conventional Agile team puts three to five developers around a sponsor and a product owner, with ceremonies to keep them aligned. Beyond Agile puts the product owner or subject-matter expert and one developer with AI in the same room, with a decision owner and a validation lead around them. The work moves from writing and managing tickets to guiding conversations, directing AI and judging results. Readers of The Translation Gap will recognize the shape: the pair, together, is the Domain Translator, and the developer is the Orchestrator.

Traditional Agile role	Beyond Agile focus	What changes
Business analyst	Narrative facilitator or validation lead	Draws out rules and exceptions alongside the developer and reviews the generated specification instead of writing stories
Product owner	The business half of the pair, and decision owner	Narrates the system, approves the specification and accepts each milestone instead of prioritizing a backlog line by line
Developer	The technical half of the pair	Sits with the business owner, directs the AI, reviews the generated code for quality and security, and handles the integration work AI cannot do alone
QA analyst	Validation lead	Builds test scenarios from the specification and leads stakeholder validation sessions
Scrum master or project manager	Milestone coordinator	Schedules narration and validation sessions and tracks milestones and decisions rather than ceremonies and velocity

Subject-matter expertise becomes more valuable, not less. The quality of the proof of concept depends on the quality of the narration, and the quality of the narration depends on people who understand the business deeply. As Chandran Monikandan put it in The Goalposts Moved. The Engine Didn't., the details of a recordkeeping system are in people's heads before they are anywhere else. Narration is how they get out.

Two Examples

Convergent has applied Beyond Agile on client and internal work in the retirement industry. Where a figure below compares the work with a traditional approach, it is our estimate, and we say so.

A retirement quote engine

The need. A multi-screen web application for quoting 403(b) and tax-sheltered annuity plans, used by several types of users with different permissions.

What was built. A full user-interface redesign with five role-based logins, an actuarial formula management module for administrators and a read-only rate display. Rate changes were delegated through a single-sign-on redirect to a third-party common remitter.

How Beyond Agile applied. The business owner narrated how each role uses the quote engine to the developer, who turned the actuarial and rate rules into working screens with AI for review rather than first writing them as stories.

Results.

• Time from first narration to a working proof of concept: 3 days
• Iteration cycles before acceptance: 3
• Our estimate of the same work under a conventional sprint plan: 2 to 3 sprints

MAPTIVA

The need. Retirement plan providers receive payroll and contribution files in many formats, and mapping each one is slow and manual.

What was built. MAPTIVA, Convergent's AI framework for retirement operations. Its payroll mapping capability takes incoming files in whatever format they arrive, maps them to the target format and checks them against the failure patterns that actually appear in retirement payroll.

How Beyond Agile applied. The platform was built by narrating specific mapping scenarios and business rules, generating the platform directly with AI coding tools, and refining it the same way, with our consultants directing and reviewing the work throughout.

Results.

• Time from concept to first working version: 3 months
• Team: one analyst and two developers
• Capabilities added through narrated iteration: reusable mapping rules, missing-field validation, date normalization, contribution-type mapping, exception review and reconciliation totals
• Our estimate of the same build by a traditional team: 6 to 12 months, with two analysts, three developers and two QA analysts

Governance and Traceability in Regulated Environments

Removing user stories does not remove the audit trail. It replaces it with a better one. In Beyond Agile, every requirement can be traced from the stakeholder's own words to the written specification and then to the code.

Retirement plan providers operate under ERISA, IRS plan qualification rules and SOC 1 and SOC 2 controls. Auditors and compliance teams need to know what was required, who approved it and how it was tested. The method answers each question:

Audit question	Beyond Agile evidence
What was required?	Narration recordings and written transcripts, and the AI-generated specification
Who approved it?	Signed-off specification versions at each review gate, and the record of accepted milestones
What changed and why?	Narrated change requests linked to specification versions
How was it built?	Generated code in version control, tied to the specification version
How was it tested?	Test scenarios derived from the specification and stakeholder validation results

Three controls are required on every engagement:

• Human review gates. No specification is used for generation, and no proof of concept is accepted, without named human approval. Subject-matter experts review first, then the project team.
• Data protection. Narration and testing use masked or synthetic participant data. Real personally identifiable information never enters an AI tool without client approval and an appropriate enterprise agreement.
• Code review. Generated code is reviewed by an experienced developer for security, performance and maintainability before it moves beyond the proof of concept.

Where It Fits, and What Changes at Scale

Beyond Agile works best where the main risk is building the wrong thing and the fastest cure is showing stakeholders something real. That describes the first phase of almost any program, including large ones. What changes at scale is not whether the method works but what happens after acceptance.

Strong fit, end to end	Strong fit for the first phase, then a hybrid handoff
Proofs of concept and pilots	Large platforms built by several teams at once
Internal tools and admin portals	Systems with heavy real-time integration to many external parties
Platform migrations and consolidations, such as moving plans between recordkeeping systems	Core transaction processing where a defect moves money at scale
Data mapping and file transformation	Work with fixed, externally imposed specifications and little room for interpretation
Quoting, calculation and rules engines	Long-running products with established Agile teams and backlogs

For work in the right-hand column, the accepted proof of concept and its specification become the starting point for a conventional delivery team. A Beyond Agile pilot also fits the structure Dave DePue has described on this site: it is a natural first 90-day block, with a measurable outcome that stands on its own.

Risks and Mitigations

The biggest risk in Beyond Agile is trusting AI output too much. Every mitigation below keeps a qualified person in the loop, and the two that matter most are the subject-matter expert review and the project team review that follows it.

Risk	What can go wrong	Mitigation
AI misreads the narration	A rule is captured incorrectly or an exception is missed	Specification review gate; an open-questions list generated with every specification
Over-trust in working software	A polished screen hides a wrong calculation	Test scenarios built from the specification; calculation checks by subject-matter experts
Weak narration	Gaps in what stakeholders say become gaps in the system	Developers trained to facilitate; narration checklists for common retirement domains such as loans, distributions and vesting
Generated code quality	Code works but is hard to maintain or insecure	Developer code review; coding standards supplied to the AI; security scanning
Sensitive data exposure	Participant data enters AI tools	Masked or synthetic data; enterprise AI agreements; client approval for any real data
Scope drift	Fast iteration encourages endless small changes	Decision owner approves each iteration; acceptance criteria agreed at the specification gate
Organizational resistance	Teams invested in current processes push back	Start with a bounded pilot; hand off to existing teams after acceptance

A Pilot That Answers One Question

The lowest-risk way to test Beyond Agile is a single, bounded pilot, run by one pair, that ends in an accepted proof of concept. We recommend this structure:

1. Select the use case. A contained business need with a clear decision owner and engaged subject-matter experts. A new calculator, an admin portal or a single migration workflow works well.
2. Hold narration sessions. Facilitated working sessions with the client's experts, captured as the source of requirements.
3. Review the specification. The experts review it first, then the decision owner approves it.
4. Build and validate. The pair builds the proof of concept and runs validation sessions with the people who will use it.
5. Iterate to acceptance. Changes are narrated and applied, milestone by milestone, until the decision owner accepts the result.
6. Decide what comes next. Continue with Beyond Agile, hand the work to an internal team, or stop with a clear record of what was learned.

The pilot is designed to answer one question: how much faster can we reach a validated solution, and what does it cost us in control? The specification, the decision history and the code belong to the client at the end of the pilot, whatever the decision.

Agile Solved the Cost of Change

For two decades the safest way to build software was to plan carefully before writing code, because code was slow and expensive. That assumption no longer holds. When a developer with AI can produce a working proof of concept from a conversation with the person who knows the business, the fastest path to the right solution is to build early, show it and correct it, with human judgment and governance at every gate.

Agile solved the cost of change. AI now solves the cost of starting. Beyond Agile is not a rejection of Agile values. It is those values, working software and customer collaboration, applied with tools that remove the delay Agile was never designed to eliminate.

We invite technology leaders across the retirement industry to discuss, challenge and test these ideas with us. If you have a bounded problem and an expert who can explain it, we would like to run the pilot.

---

Sources

• Sida Peng, Eirini Kalliamvakou, Peter Cihon and Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, February 2023
• Joel Becker, Nate Rush, Elizabeth Barnes and David Rein (METR), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025
• Google Cloud DORA, Accelerate State of DevOps Report 2024, 2024 (figures as published in the report announcement)
• GitHub, Spec-driven development with AI: Get started with a new open source toolkit, September 2025
• Kent Beck et al., Manifesto for Agile Software Development, 2001