Rondowith Context Driven Development
How to build software with AI as a team: faster, safer and without losing knowledge
Michał Sobczak
Rondo is a project methodology that speeds up implementation and makes better use of knowledge in the organization through rotating specification sessions, in which knowledge is organized and written down. It can complement or replace classic project methodologies. CDD standardizes software development with AI assistants: the context, scope and evidence of changes.
Rondo speeds up implementation through rotating specification sessions. In them, experts' knowledge goes into specifications instead of staying in people's heads. Rondo can complement or replace classic methodologies. CDD brings order to work with AI assistants: context, scope and evidence of changes.
For leaders
Why it pays off, how it works and how it compares with other methodologies.
12 slides · approx. 7 min →For practitioners
Cookbook: CDD artifacts, specification structure, Rondo roles and rituals.
22 slides · approx. 10 min →From recording session to master
Working in Rondo is like producing a record in a music studio: from playing together, through notation, to mixing and mastering.
- Recording session→ Specification session
Musicians from different bands play together and find a shared sound in real time. In the session, people with business, functional and technical knowledge agree on the goal, scope and rules of the change.
- Notation→ Specification
What was created in the session goes into a score that every musician reads the same way. A CDD specification records decisions so that both a person and an AI assistant can read them.
- Producer and mix→ CDD operator
The producer takes the score and the recordings, arranges them and mixes them into a finished track. A CDD operator with an AI assistant turns a closed specification into code.
- Mastering→ Gates and tests
Before release, the master has to sound good on every system. Control gates and tests confirm that the change works before it reaches production.
Questions from production go back to the next recording session. The next recording starts before the previous one finishes post-production.
Session musicians are not tied to one band. They play wherever they are needed and move on to the next recording. In Rondo, people with knowledge and CDD operators rotate in the same way.
Rondo is also the name of two musical forms: a piece in which the main theme returns between successive sections, and a two-section operatic aria, first slow, then fast. The name comes from the Italian rondò, via the French rondeau from rond, meaning “round” (Latin rotundus). Rotation shares the same root: the Latin rota means wheel.
What doesn’t work in classic methodologies?
Project methodologies were created before teams started working with AI assistants. Today this shows in everyday work.
- Knowledge trapped in people’s heads
- No specification
- We don’t know when to bring in an expert
- Context gets lost in AI chats
- Only one person knows the system
- No reproducibility
- No tests
- AI without context guesses
- Team silos
- Decisions leave no trace
- Knowledge leaves with people
- Scope changes faster than the plan
- Code drifts from requirements
- Fixed teams, changing needs
- Late questions, costly fixes
- No single source of truth
- No up-to-date documentation
The next slides show how Rondo and CDD address these problems.
Is Rondo right for you?
Rondo works best where knowledge is scarcer than hands to write code.
Do many teams need the same experts?
Sessions set in advance when their knowledge is needed, and it stays in the specifications.
Do people work on several projects at once?
In Rondo rotation is the rule: roles move between teams as sessions require.
Does AI already write a large share of your code?
The bottleneck becomes knowing what to build. CDD gives AI assistants a precise specification.
Is knowledge of the system held in the heads of a few people?
Sessions and CDD artifacts move it into the specifications, the CHANGELOG and the README.
If you answer “yes” to at least two of these questions, Rondo and CDD are a good fit for you.
Why CDD?
Working with AI assistants requires a stable, verifiable context that connects business intent with implementation and tests.
1. Consequences of not having CDD
Shipping the wrong solution
We can deliver a system that works according to its code and tests but solves a different problem than the one the business needs.
Losing control of scope
Undocumented decisions and hidden assumptions lead to scope creep, conflicting interpretations and costly changes after release.
Growing context debt
Every new session starts by reconstructing knowledge, and the lack of a single source of truth increases rework, delays and dependence on individual people.
2. Benefits of using CDD
Faster delivery
Clear context reduces rounds of clarification, surfaces misunderstandings earlier and makes it easier to work on a change in parallel.
Decisions you can defend
Intent, scope, criteria and evidence are written down, so the team can assess a change deliberately and quickly reconstruct its rationale.
Scaling work with AI
Knowledge doesn’t stay in chat history or in individual heads; it becomes lasting context available to the next people and assistants.
Without CDD, every AI-assisted change carries the risk of paying for quickly delivered code many times over: in rework, incidents and reconstructing lost decisions.
Why Rondo?
Rondo organizes the flow of knowledge in rotating specification sessions and helps teams move faster from analysis to implementation.
1. Consequences of not having Rondo
Experts outside the process
Teams don’t know when to bring in an analyst or an architect, so their knowledge reaches the work too late or not at all.
Knowledge trapped in roles
Decisions stay in conversations and in individual heads, so the next teams start their analysis with an incomplete picture.
Late questions and rework
Problems only surface during implementation, which forces a return to analysis, delays delivery and raises the cost of the change.
2. Benefits of using Rondo
Experts at the right moment
Experts move between teams and domains, and sessions define in advance when their knowledge is needed.
Knowledge stays in the specification
Sessions produce written goals, rules and gates that everyone involved in later work can use.
Parallel flow
One team can implement closed items while the next session develops further areas and answers questions.
Without Rondo, limited knowledge remains the organization’s bottleneck, and a growing number of teams will pay for it with knowledge gaps discovered too late, delays and lost momentum.
Rondo + CDD
Rondo organizes the flow of knowledge, and CDD describes the lasting artifacts and evidence that come out of it.
Rondo
Rotation of knowledge and operators, and phase-shifted implementation.
CDD
Specifications, CHANGELOG, tests, README and acceptance gates.
What changes in the organization?
Rondo changes how people access knowledge and how work moves from analysis to implementation. The way work is accounted for can stay the same.
Sessions instead of queues
People with knowledge meet in specification sessions instead of handling queues of questions from many teams.
Roles instead of fixed teams
The owner, context expert, technical expert and CDD operator join wherever they are needed at the moment.
Specification as the output of a session
Every session ends with a written goal, scope and gates that can be handed over for delivery.
Phase-shifted implementation
CDD operators deliver closed specifications while the next session prepares the next area.
Tracker tasks and time tracking stay. The rituals change: from classic methodologies only a short daily remains, and specification sessions become the center of the work.
How does Rondo work?
Specification sessions feed parallel implementation, and knowledge flows between teams.
Reproducibility
Based on the artifacts — specs/, CHANGELOG, README and tests — it should be possible to rebuild the software within a finite time and scope using a different modern AI assistant.
Proof of compliance
Reproducibility shows that the result and the way it was produced stay consistent with the agreed requirements.
Risk management
Artifacts reveal missing decisions, incomplete context and dependence on individual people.
Oversight of AI work
The assistant’s output can be compared against the specification and tests, reducing the risk of hallucinations.
Accountability and scale
The whole process remains traceable, and a shared framework lets you scale productivity.
What matters most is accountability for the whole process: from intent and decisions, through the AI assistant’s work, to the tested result.
Research in the context of CDD
AI needs a precise, structured specification, not simply more description.
Precise context more than doubles AI's success rate
GitHub issues: 4.8% of tasks resolved with exactly the files the change touched, versus 1.96% with automatically retrieved context.
CDD The specification names the artifacts and the critical path of the change (B9, B11).
SWE-bench · Princeton · ICLR 2024Structure matters, not volume
When key information sits in the middle of a long context, accuracy drops by more than 20%, sometimes below the result with no documents.
CDD A fixed nine-section structure, with what matters most in the TL;DR up front (B3, B6).
Lost in the Middle · Stanford · TACL 2024General documentation doesn't help, specific instructions do
General repository overviews didn't raise agents' success rates and increased cost by over 20%. Agents followed specific instructions well.
CDD A separate specification for each change: goal, scope, control gates (B8, B12).
Evaluating AGENTS.md · ETH Zürich · 2026Research doesn't evaluate CDD directly, but it confirms its assumptions. Each card links to its source.
Research in the context of Rondo
The bottleneck in delivery is knowledge and collaboration, not writing code.
Projects fail on requirements and communication, not code
228 companies in 10 countries: the most common critical problems are incomplete or hidden requirements (48%) and communication with the customer (41%), the most frequent cause of failure.
Rondo The owner's and experts' knowledge goes into the specification at a joint session, before code (B17).
NaPiRE · Empirical Software Engineering · 2016With AI, people work more on their own
187,000 developers: with Copilot the share of solo coding rises, while the share of coordination and project management falls by a quarter.
Rondo Planned knowledge flow: experts and operators rotate between teams (B16, B18).
Generative AI and the Nature of Work · Harvard Business School · 2024Faster people don't mean faster delivery
With AI adoption, individual productivity rises, while delivery stability falls by about 7.2% and throughput by 1.5%. Better coding alone doesn't improve delivery.
Rondo A change of process, not just tools: sessions, roles and rituals (B15–B19).
DORA 2024 · GoogleResearch doesn't evaluate Rondo directly, but it confirms its assumptions. Some results are correlations. Each card links to its source.
Compared with other methodologies
Rondo and CDD connect the way people organize their work with context that an AI assistant understands.
| Methodology | Key trait | In common with Rondo and CDD | What Rondo and CDD add |
|---|---|---|---|
| Scrum | Iterations in sprints | Owner in the PO role, scope refinement | Team membership isn’t fixed because people with knowledge rotate; refinement takes the form of a session that ends with a specification for AI |
| Kanban | Work-in-progress limits | Continuous flow of work | Defines who prepares the knowledge for a task and in what form to record it; Kanban doesn’t prescribe this |
| SAFe | Scaling, shared PI Planning | Specialists shared across many teams (Shared Services) | Specialists rotate through sessions and their knowledge stays in the specification; four dynamic roles instead of an elaborate structure |
| LeSS | One backlog, many teams | Many teams and shared refinement of requirements | Rotation of people with knowledge instead of fixed teams; refinement produces a specification for AI |
| Team Topologies | Team types and their interactions | Deliberately steering the flow of knowledge between teams | Expert knowledge reaches teams through sessions and stays in specifications, without a permanent enabling team |
| Spec-driven development | Specification before code | Specification as the source of truth for AI | CDD adds a record of what was actually built (CHANGELOG, README), backfill for existing projects and a reproducibility requirement; Rondo organizes people around the specification |
Experts at the right moment the session defines when their knowledge is needed
Context ready for AI a session should end with a specification
Parallel work implementation continues during the next session
Rondo can be combined with Scrum or Kanban, but besides the analysis rituals it also changes team composition, because people rotate. The closest idea is the less known Dynamic Reteaming; Nexus and Shape Up share some elements too.
What to learn in the age of AI?
AI writes more and more code. An engineer’s value is shifting from writing to understanding, evaluating and designing.
Design patterns and anti-patterns
You’ll recognize when generated code is heading in the wrong direction before it reaches production.
Algorithms and data structures
You’ll be able to judge the complexity and performance of a solution proposed by an AI assistant.
System architecture
Module boundaries, integrations, scaling and fault tolerance: decisions AI won’t make for the team.
Engineering methodologies
TDD, CI/CD, code review, Rondo and CDD: a process that maintains quality no matter who wrote the code.
Specification and documentation
A precise record of intent, scope and criteria is now the main way of working with AI.
Testing and verification
Tests prove that the code does what it was meant to do, not just what could be generated.
Comparing solutions
Weighing alternatives, trade-offs and costs, and recording why you rejected the other options.
Domain knowledge
Processes, users and business rules that AI can’t read from the code alone.
The most valuable people can tell AI what to build and check whether it built it well.
Cookbook for practitioners
Everything a team needs to work with Rondo and CDD: artifacts, specification structure, adoption and rituals.
B1–B5 · CDD
Artifacts, the specification as a contract, its fixed structure, ways of working and getting started in a project.
B6–B14 · Specification
The nine sections of a specification, step by step.
B15–B19 · Rondo
Roles, specification sessions, phase shift and rituals.
B20–B21 · Adoption
A step-by-step pilot and verifying the adoption.
Context-Driven-Development
An SDD methodology with TDD and Continuous Delivery, independent of any specific AI model, vendor or tool.
README
The “here and now” state: a current picture of the domain, the functional architecture and the critical path.
specs/
“I would like”: the intent, scope, rules and constraints of every planned change.
CHANGELOG
“And this is what was actually built”: a chronology of what was really delivered.
Tests
Proof and confirmation of what we described in the CHANGELOG.
We define what we would like to be built and note what we believe was built, but we treat tests and the high-level state in the README as the proof.
Specification as a contract
A specification describes intent, constraints and proof of delivery.
Author
A spec can be written by anyone with access to business, technical and testing knowledge.
Scope
One specific change, the starting point, what’s out of scope and behavior in unusual situations.
Verifiability
Every key requirement must lead to a criterion and a test.
History
We keep specifications as a complete set so we can correlate the knowledge they contain.
A single source of truth should be linked to the code and tests. How SDD is introduced depends on organizational adoption and the team’s preferences.
Nine sections of a specification
- 1TL;DR
- 2Abstract
- 3Objective
- 4Artefact Inventory
- 5Functional Domain Changes
- 6Critical Path
- 7Control Gates
- 8Expected Outcome
- 9Additional Information
1–3
TL;DR, Abstract, Objective.
4–6
Artefact Inventory, Functional Domain Changes, Critical Path.
7–9
Control Gates, Expected Outcome, Additional Information.
The structure is fixed, so specifications can be compared and reviewed mechanically. A specification should be readable first by a machine and second by a person.
Variants
The variant depends on how the specification is developed and how wide a context we want to correlate code and knowledge in.
1. How we develop the specification
Conversationally
The specification emerges from a conversation and is developed iteratively.
During or after closing
Changes can be implemented while the specification is being written or after it is closed.
Manually
We can write the specification ourselves, without assistants; it can then serve as proof of delivery.
2. Where we store and correlate
Project repository
If the project has a repository, we keep the specifications in it, with no extra context.
Tracker and work context
We can keep the specification alongside the issue tracker when a broad work context is needed.
Grouping and correlation
We group projects locally according to the analysis context, depending on how widely we want to correlate code and specifications across repositories.
Context
CDD can be introduced in a new project, and also in an existing one after a suitable backfill and inventory.
Reference prompt
We write every specification using a shared prompt and an agreed structure.
CHANGELOG backfill
When starting CDD on an existing repository, we reconstruct the change history, also using the reference prompt.
Initial inventory
If needed, we prepare an initial inventory of the code and save it in the specifications folder as a reference point.
We recommend preparing an engineering manifesto: a set of basic implementation principles to apply when delivering specifications. This gives the project an initial context from which further specifications can be developed consistently and artifacts kept up to date.
Spec: TL;DR
One to three sentences after which the reader understands the change, who it is for and how the result will be confirmed. This form proves that we understand the change ourselves and can describe it minimally.
Spec: Abstract
3 to 15 sentences split into logical paragraphs. The abstract describes the context and the current state without repeating the TL;DR.
- Current state. What exists today.
- Gap or problem. What is incomplete, wrong or insufficient.
- Rationale for the change. Why the change is needed now.
- Decision history. Which earlier attempts or decisions affect the scope.
Spec: Objective
The goal must be separated from the scope and verifiable.
Goals
What must be achieved.
Out of scope
What we deliberately don’t do.
Success criteria
Which conditions mean it’s done.
This is the best place for information about the business context of the functional change described by the specification
Spec: Artefact Inventory
An inventory of everything the change touches or depends on.
System
Repositories, modules, services, containers, queues and jobs.
Data
Databases, schemas, tables, migrations, backups and retention.
Organization
Roles, responsible people, environments, documents and integrations.
State
exists, to create, to change, to remove or [TO BE DETERMINED].
By adding specifications iteratively and incrementally and describing the state of artifacts, we can track decisions and identify overlooked areas
Spec: Functional Domain Changes
A description of system behavior, not an implementation plan.
State
Current state and target state.
Rules
Business rules and edge cases.
Resilience
External service failure and concurrency.
Data
Impact on data, schema and migration compatibility.
Technical details, including implementation matters, should follow from the organization’s manifesto or the team’s design rules. This keeps principles consistent across specifications. A standard should be adopted.
Spec: Critical Path
The shortest sequence of steps from the current state to a working change.
Goal
The business result the change must achieve.
Minimum scope
Only what is needed to reach the goal, with no side work.
Order of evidence
A logical sequence of steps and dependencies that leads to confirming it works.
Completion condition
A clearly defined point at which the result can be considered achieved.
The critical path is the core of the change: it leads by the shortest route to the goal and the expected result, without side elements. It connects the goal with the result.
Spec: Control Gates
Checkpoints derived from the functional changes, which in turn define specific tests
Pass condition
A logical or numeric condition, with no room for judgment calls.
Verification
A test, query, command or metric.
Blocks
The merge, deployment or execution that gets blocked.
Negative gate
What the system must not do and when it must refuse to act.
Every specification should come with at least a minimal set of tests based on the critical path. Their technical form should follow the test pyramid: we pick the most suitable type for the problem.
Spec: Expected Outcome
The state of the system as seen from the outside after release.
Direct effect
What starts working.
Measurable effect
Which metric changes and over what time frame.
Side effects
What else changes, including unwanted effects.
Rollback
Whether the change can be reverted and at what cost.
We arrive at the outcome from the goal and the critical path.
Spec: Additional Information
A place for information that protects the project from returning to rejected ideas and hidden assumptions.
Rejected alternatives
Rejected ideas and the reasons for rejecting them.
Technical debt
Risk accepted because of constraints, not thoughtless acceptance of low quality.
External dependencies
Dependencies on external decisions.
Sources and questions
Source materials and open questions.
What is Rondo?
Rondo is a dynamic methodology for organizing analysis, knowledge and implementation around rotating specification sessions.
Dynamic roles
Analysts, architects, testers and people with business knowledge support successive teams and domains.
Specification sessions
A session produces the goal, rules, scope and gates needed to start implementation.
Phase shift
One team implements closed items while the next session develops the next area.
Flow of knowledge (CDD)
Knowledge passes between roles and is recorded in artifacts instead of staying in individual conversations.
Tasks and time tracking can stay as they are, but the project rituals must change. The project dynamics have to change too, because work centers on specification sessions and the rotation of people.
Dynamic roles
Project roles are not permanently tied to one domain; they change with the needs of each session and the flow of knowledge.
Owner
Describes needs, priorities and the expected result.
Functional context expert
Connects the requirement with processes, users and the existing behavior of the system.
Technical expert
Assesses feasibility, dependencies and the consequences of the solution.
CDD operator
Organizes the session, artifacts, gates and workflow.
There is no restriction on who can write a specification. In principle, though, it is collective work done during the session.
Specification sessions
A specification session organizes the knowledge needed to start and run a functional change.
We gather knowledge before the session
We identify the people with relevant knowledge and the documents describing the context of the change.
We split the workload
We plan the work so that each specification is delivered by one CDD operator. The operator’s presence at the session isn’t mandatory but is strongly recommended. This avoids chasing answers to obvious questions later.
We prepare the specification
We organize the gathered context, agree on the scope of the change and record decisions in artifacts.
We plan delivery
We agree on the order of sessions, participant availability and the plan for delivering the change.
Anyone with access to the knowledge can write a spec, but closing it requires joint review. A session can last from 1 to 8 hours and can also include parallel implementation of the specification.
Phase shift
Both people with knowledge and CDD operators are shifted. We don’t assume fixed teams.
Rondo inner circle
The work is based on specification sessions, in which we organize knowledge, make decisions and prepare the change.
Rondo outer circle
Implementation happens in the outer circle, where CDD operators deliver closed parts of the specification.
Knowledge and responsibility move between the circles as needed. This way, the work doesn’t depend on people being permanently assigned to one team.
Rituals
Rondo has rituals that link the specification session with agreeing on and delivering the implementation.
Specification session
This is the most important element of the process. The team organizes knowledge and sets the goal, scope and conditions for moving to delivery.
Implementation agreement
The specifying team agrees with the operator on how the closed specification will be taken over and delivered.
Operator shift
The operator moves on to the next specification according to current workload and delivery needs.
Shifting people from the specifying team
People who contribute knowledge can move on to further sessions and domains as the organization needs.
From classic methodologies we keep a short daily check-in plus reviewing and planning specification sessions. Manual or acceptance tests need separate coordination by the administrator or project maintainer. Tracker tickets can be created before the specification or after it is closed, because the process stays flexible.
How to adopt Rondo and CDD?
Start with a small pilot and refine the method after each step.
Identify the people
Name the context experts and specialists, the CDD operators and the owners.
Learn the specification
Each of these people studies the structure of the reference specification (B6–B14) and writes one specification on their own.
First session
Meet for a two-hour specification session and write the specification of one change together. Work within your context variant: a single repository or a group of them (B4).
Delivery
The CDD operator delivers the specification with an AI assistant, acting as the producer of the code. Before that, following B5, they backfill the missing artifacts.
Schedule
Set a schedule for specification sessions and acceptance tests. The goal is to make the best use of the experts’ time.
Rituals
Following B19, agree on the rules for shifting experts and CDD operators. Name the people responsible for formal sign-offs.
From the pilot: the hardest part is switching from traditional methods to high-velocity software development.
Verification
We recommend creating an organization-wide repository that teams learn from and use every day.
1. Organization-wide repository
Reference prompts
Prompts for writing specifications with a shared structure.
Historical backfill
Prompts and instructions for reconstructing the change history of existing projects.
Checkpoints
Criteria for verifying the quality of the CDD artifacts being produced.
2. When the adoption has succeeded
Rondo
You write specifications together, experts and CDD operators are interchangeable across projects, and knowledge is accessible and shareable.
CDD
Any modern AI assistant, given the specifications, CHANGELOG, tests and README, concludes that it can rebuild your project.
Contact
Want to get to know Rondo and CDD better, or need help with adoption? Feel free to get in touch.