Convergence Programming
Building software while discovering what it must do.
A prompt starts the work. Running the software reveals more. Our research asks how AI systems can discover missing requirements, check their behavior, and preserve what they learn as the software changes.
A preview of our researchThe requirement you never gave it.
A studio asks for a booking app. The important discovery comes from watching the studio work. Follow the requirement from its first observation to the next version that must preserve it.
Illustrative scenario. This sequence explains the research idea. It is not a recorded agent run or an empirical result.
- Build. A studio requests a booking app. The first version offers adjacent sessions.
- Discover. The studio's workflow reveals that the room needs preparation time between sessions.
- Clarify and repair. The owner confirms a 15-minute gap. The app reserves that interval, and the illustrated scenario is checked again.
- Revise. The owner asks for rescheduling. The preparation requirement stays attached to the new version.
- Preserve. Both booking and rescheduling are checked against the same requirement. The evidence concerns this studio and these scenarios.
- Reopen. A second location has different, unconfirmed operating rules. Its bookings need fresh evidence.
The interactive version adds a changing calendar and a persistent requirement record. The complete argument remains readable here.
The discovery becomes part of the program.
The preparation interval was absent from the request. The useful work included finding it, asking the owner what it meant, changing the behavior, and keeping it intact when rescheduling arrived.
Convergence Programming treats that entire trajectory as the programming object: the requests, procedures, actions, observations, revisions, and decisions through which incomplete intent becomes executable behavior.
- IntentWhat is needed
- ActionA proposal meets the world
- ObservationWhat actually happens
- RevisionWhat changes and stays
- DecisionWhat the evidence supports
A better process can reveal a worse score.
Finding a missing requirement exposes unfinished work. Repairing it changes the behavior. Explore five ways the same build can unfold, and keep those two kinds of progress separate.
This new illustration uses four explicit studio requirements. Opening hours and session duration are initially known; a preparation interval and cancellation cutoff must be discovered. Finding an unmet requirement increases the known unresolved count without changing the behavior. Repair lowers the unresolved count. An optional evaluator view exposes the full four-requirement world, which is not available to a deployed agent. True convergence discovers and repairs the requirements in this small world. False convergence keeps passing the known checks while hidden requirements remain unmet. Plateau stops with a known gap. Regression breaks an established rule. Premature action occurs before the required evidence. These are constructed trajectories, not model results or readiness percentages.
The same screen can hide different requirements.
Suppose an app offers a session at 10:15. Does that fit this studio? Choose what to inspect. An observation helps when it distinguishes the local conditions that change the decision.
Two possible studios produce the same request, calendar preview, and booking acceptance. One requires 15 minutes of preparation after a session; the other requires 30. Those rules are initially unobserved. Observing the workflow and confirming the requirement with the local owner distinguishes the worlds: a 10:15 booking after a 10:00 finish fits the first rule and conflicts with the second. The same observation history could not establish that distinction. This is a synthetic counterexample, not a recorded test.
A different way to recognize progress.
Discovery can make the score worse.
Before the preparation rule was known, every visible check could pass. Discovering it exposes work still to do. The behavior has not improved yet, but the process has acquired information that a green dashboard concealed.
Understand false convergenceA repair can erase earlier progress.
Adding rescheduling can break the interval that ordinary booking already respects. A useful revision needs to preserve established requirements as well as satisfy the latest request. The history tells us which checks the next change owes.
Why the trajectory mattersA pass has conditions.
Evidence from the original studio supports a claim about that studio. A second location may need a different setup interval. A known critical blocker stops the affected action; successes elsewhere do not cancel it out.
How evidence limits permissionWhat are we asking the system to produce?
These emphases can coexist in one workflow. The proposed shift is to make discovery, preservation, and evidence explicit parts of what we build and evaluate.
| Emphasis | Central object | Question it brings into focus |
|---|---|---|
| Implement a specification | Program and specification | Does the behavior satisfy the requirements we have stated? |
| Generate an app or complete a task | Artifact or outcome, refined through feedback | Did the system deliver what the request and checks ask for? |
| Convergence Programming | The entire trajectory | What did the process discover, preserve, and establish about the behavior required here? |
The first two can include iteration, external evidence, and requirement discovery. Convergence Programming proposes a common framework for examining these obligations across the whole process.
Read the paper's eight-paradigm comparisonIs this just good software engineering?
Much of the practice has precedents. Requirements engineering studies what a system must do in its environment. Iterative development accommodates changing needs. Testing and formal methods establish claims about behavior under stated conditions.
The research contribution we propose is a shared object and evaluation framework for a particular problem: powerful generators acting from incomplete intent, with people who cannot inspect everything those systems produce. It connects hidden-requirement discovery, preservation through repair, evidence sufficiency, critical blockers, and permission to act.
The framework is about the process. A ledger, verifier ensemble, or harness may support it; no particular tool defines Convergence Programming.
That proposal has to earn its value against strong existing workflows. A fair evaluation would compare systems at matched budgets on what they discover, what their revisions break, when they claim readiness without enough evidence, and how much human oversight they require. If a simpler workflow performs as well, that would weaken the case for the additional machinery.
Where the neighboring ideas fit
Agile's principles explicitly welcome changing requirements. Syntax-guided synthesis includes an iterative search-and-verification process. Agent workflows can already use feedback from tools and the environment. The distinction here is not the invention of interaction.
Formal verification remains valuable within its model and assumptions. Convergence Programming asks how the relevant assumptions enter the process, how their supporting evidence survives change, and which actions that evidence can justify.
The research behind the idea.
Convergence Programming: Iterative, World-Grounded Alignment of Lossy Human Intent with Executable Behavior
The paper is being prepared for release.
What the paper proposes
- A framework for false convergence: visible success while consequential requirements remain unsatisfied or unexamined.
- A trajectory as the unit of programming and evaluation.
- An evaluation design for discovering hidden constraints and calibrating permission to act.
A conceptual and evaluation-design contribution with a preliminary pilot. The figures here illustrate arguments; they are not measured results. The framework is scoped to defined task worlds and evidence conditions.
Take the argument further.
Read a chapter where your questions begin, or follow the complete explainer.
All 11 chapters About 27 minutes
- 1 The demo worksA clinic manager asks for an intake dashboard and gets one that works. Then a patient reports chest pain. 2 min
- 2 What changes when AI does the buildingHow Convergence Programming relates to iterative development, synthesis, and tool-using agents. 4 min
- 3 The failure gets a nameThe failure gets a name, the dashboard lies in one figure, and six ways it happens. 4 min
- 4 A build that carries its learning forwardA studio booking app reveals an unstated requirement, carries it through rescheduling, and reopens its assumptions at a new location. 4 min
- 5 Five things the same loop can doOne loop, five endings; only one is success and only two announce themselves. 1 min
- 6 What better models still need to observeFour structural limits explain why capability and evidence answer different questions. 3 min
- 7 When reviewers share a blind spotHow shared assumptions affect what multiple reviewers can establish. 2 min
- 8 How the framework shapes an evaluationConnect hidden requirements, observed behavior, repairs, and action decisions. 2 min
- 9 What existing methods establishWhere prompting, testing, formal methods, and monitoring help, and which questions they leave open. 1 min
- 10 Bounded on purposeThe epistemic contract, stated before anyone asks. 2 min
- 11 Calibrated permission to actThe clinic as numbers, and what calibrated permission to act means. 2 min
What should a system have to establish before its next action?
Bring us a concrete case