IACDM: Interactive Adversarial Convergence Development Methodology -- A Structured Framework for AI-Assisted Software Development
Abstract
Adoption of AI-assisted development in 2025 exposed a tool-agnostic failure pattern: experienced developers using frontier models were measurably slower while believing they were faster, and 10.3% of applications in one production showcase leaked data through misconfigured access. These failures share a structural cause, the verification gap: absent external tool use, no language model can determine whether what it generated is correct. The tool is irrelevant; the process is determinative. We present IACDM (Interactive Adversarial Convergence Development Methodology), an 8-phase framework in which verification agents external to the generator operate at discrete gates, and the AI alternates between building artifacts and attacking them through specialized critique lenses. What distinguishes it from the review and red-teaming traditions it borrows from is that the gate is enforced by a state machine outside the model: the agent may request advancement, not grant it. One component has now been tested. A pre-registered experiment over twelve projects under a single frozen instrument asked whether the nineteen lenses are non-redundant, against a prior expectation from replications of Perspective-Based Reading, which found reading perspectives not to differ. Every lens found at least one defect no other lens found, under four independent judgements of what counts as the same defect. Two further results were unplanned: the taxonomy withstands testing while the criterion deciding when to apply it does not, and the method creates commitments nothing ever re-confronts with the built system. The method was otherwise developed at one industrial R&D institute. That evidence establishes applicability, not effectiveness: no project ran without the method, and the proponents are the evaluators. Whether IACDM outperforms direct prompting remains open, and this paper is written to make it refutable.
Figures & tables
| Without methodology (any tool) | With Iterative Convergence (any tool) |
|---|---|
| prompt → GA → artifact → delivery | design → G 0 → critique → G 1 → …→ G n → delivery |
| Verification gap open | Discrete gates with VA-automatic and VA-human |
| Errors detected at | Errors detected at |
| Perception: +20% Reality: 19% ( METR, 2025 ) | Measurable at each gate |
| 170 vulnerable apps / 1,645 analyzed ( Palmer, 2025 ) | Security verified by VA before delivery |
| # | Phase | Purpose | Primary artifact |
|---|---|---|---|
| 0 | Problem Discovery | Understand domain and problem before any technical solution | Validated document (score 90/100) + specs/ populated |
| 1 | Architecture | Define modules, interfaces, and technical contracts | Architecture V1 ( 2k tokens; author estimate [D]) |
| 2 | Adversarial Critique | Attack architecture with up to 19 specialized lenses (7 universal + up to 12 conditional) | Coverage matrix (modules lenses) |
| 3 | Simplification | Simplify without introducing bugs; generate V(N+1) | Simplified architecture |
| 4 | Convergence Gate | Validate convergence with rigorous criteria | Final approved architecture |
| 5 | Code Implementation | Implement without regression; one module at a time | Functional code |
| Tradition / Method | Incorporated principle | Adaptation in IACDM |
|---|---|---|
| Spiral Model ( Boehm, 1986 ) | Iterative cycles with risk analysis | Risk evaluated as design fragility; AI is risk analysis partner |
| Design by Contract ( Meyer, 1992 ) | Pre/postconditions and invariants | Explicit assumptions and negative scope as informal contracts |
| Falsificationism ( Popper, 1959 ) | Knowledge advances through refutation | Adversarial critique seeks to refute the design, not validate it |
| Red Teaming (NSA/DARPA) | Dedicated team to attack the system | AI assumes red team role under adversarial prompt |
| Perspective-Based Reading ( Basili et al., 1996 ) | Reviewers read one document from assigned perspectives, under procedural scenarios | Lenses are the same idea applied to a single generator rather than to distinct reviewers (Section 7.2 ) |
| ATAM ( Kazman et al., 2000 ) | Scenario-based architectural trade-offs | Each critique cycle evaluates trade-offs, forces explicit decisions |
| Lens | Central question | Exclusive failure class |
|---|---|---|
| Assumptions | What does this design assume without declaring? | Failures from flawed/outdated system models ( Leveson, 2011 ) |
| Architectural | Can each module be replaced, removed, or tested in isolation? | Hidden coupling, circular dependencies |
| Implementability | Can I code this module in one session with available context? | Incomplete specs, insufficient granularization |
| Scientific | Does every value, formula, and algorithm have a verifiable reference? | Invented parameters, plausibility-based logic |
| Security | How would an attacker exploit this surface with minimum effort? | Unanalyzed attack surface |
| Performance | Where are the bottlenecks and what is the asymptotic behavior? | Hidden bottlenecks, scale degradation |
| Lens | Activate when | Exclusive failure class |
|---|---|---|
| Resilience | External dependencies (APIs, DBs, queues) | Cascading failures, retry storms |
| UI/UX | Any surface a person operates — including a CLI or operational tooling, not only graphical end-user interfaces | Confusing flows, dead-end states, missing feedback, accessibility failures |
| Migration / Coexistence | Replacing or modifying existing production system | Data loss, regression vs. legacy, impossible rollback |
| Sustainability / Proportionality | The system decides, allocates, or consumes a resource whose cost grows with use — e.g. but not only AI/ML, high-volume data, elastic infrastructure | GPU where CPU suffices, heavy model for a simple task, infinite data retention |
| Ethical / Human Impact | Automated decisions affecting people | Algorithmic bias, absence of human recourse |
| Process / Workflow | Multi-actor flows, state machines, business processes | Orphaned states, missing actors, happy-path bias |
| Lens | Central question / Exclusive failure class | Activation signal |
|---|---|---|
| Control Engineering | Where does the system generate an error signal and correct it? Risk of oscillation or state drift? Failure class: systems that react to events but do not regulate state — oscillation, drift, runaway feedback. | State synchronization, runtime configuration affecting behavior, feedback-driven systems |
| Game Theory | Do system actors have aligned incentives? Where does the design assume cooperation and may encounter strategic defection? Failure class: architectures that work under cooperation assumptions but collapse under adversarial or strategic behavior. | Multiple independent actors, public API, marketplace or platform design |
| Linguistics / Grammar | Is the interface contract unambiguous? Can two correct implementations of the same contract produce incompatible behaviors? Failure class: protocol ambiguity — two correct implementations that are mutually incompatible. | Inter-component communication, message formats, interface contracts between independent teams |
| Mechanical Engineering | Where are the tolerances? Does the system work only at exact specification or does it tolerate variation? Failure class: rigid coupling disguised as tolerance — failure from small deviations in dependency versions, environment, or load. | Module maintenance, long-lived systems, technical debt accumulation |
| Phase | Gate | Primary VA | What it verifies |
|---|---|---|---|
| 0. Discovery | G 0 : Score 90/100 | VA-human | Problem understanding |
| 1. Architecture | G 1 : Design review | VA-human | All modules identified; interfaces between modules defined; no open questions that would block Phase 2 |
| 2. Critique | G 2 : Coverage matrix | VA-human + GA (7 universal + up to 12 conditional lenses) | Critique complete; criticals recorded for Phase 3; decision for importants |
| 3. Simplification | G 3 : Complexity audit | VA-human | Complexity previous version |
| 4. Convergence | G 4 : Convergence gate | VA-human | Structural change 15% vs. prior version [D, see §3.2]; zero critical findings; all important findings resolved or explicitly deferred with rationale |
| 5. Code | G 5 : Compile + lint | VA-automatic | Syntax, types, style |
AI-Assisted Software Development
AI-assisted software development uses language models and coding agents to help people design, write, test, review, and maintain software.
See all 107 papers