IACDM: Interactive Adversarial Convergence Development Methodology -- A Structured Framework for AI-Assisted Software Development

Jasmine Moreira

cs.SEMar 31, 2026

IACDM: Interactive Adversarial Convergence Development Methodology -- A Structured Framework for AI-Assisted Software Development

Authors: Jasmine Moreira

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 $t=\text{production}$	Errors detected at $t=\text{gate}_{k}$
Perception: +20% $\|$ Reality: $-$ 19% ( METR, 2025 )	Measurable at each gate
170 vulnerable apps / 1,645 analyzed ( Palmer, 2025 )	Security verified by VA before delivery

Table 1: Comparison of development modes: direct prompting vs. Iterative Convergence.

#	Phase	Purpose	Primary artifact
0	Problem Discovery	Understand domain and problem before any technical solution	Validated document (score $\geq$ 90/100) + specs/ populated
1	Architecture	Define modules, interfaces, and technical contracts	Architecture V1 ( $\sim$ 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 $\times$ 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

Table 2: The 8 phases of IACDM

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

Table 3: IACDM principles from established software engineering traditions.

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

Table 4: Universal lenses (always applied).

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

Table 5: Situational lenses (activated by project context).

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

Table 6: Domain Transfer Lenses (activated by signal detection).

Phase	Gate	Primary VA	What it verifies
0. Discovery	G 0 : Score $\geq$ 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 $\leq$ 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

Table 7: Gate structure and verification agents per phase.

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

Apr 20, 2026

Scaling Human-AI Coding Collaboration Requires a Governable Consensus Layer

Vibe coding turns natural-language intent into working software, but code generation alone does not give humans and agents a shared account of what they are building. As collaboration spans participants, components, and releases, design choices must remain understandable and open to revision. We argue that scaling human and AI coding collaboration requires a governable consensus layer. Agentic Consensus organizes collaboration around a versioned project-state model linking selected intent, structural commitments, executable artifacts, and evidence. Participants can clarify intent before implementation and coordinate proposed changes against commitments that humans can inspect and revise. Bidirectional synchronization connects intended changes to implementation and exposes conflicts or stale evidence as artifacts evolve. We implemented its review workflow in Consensus Control. In a small exploratory human study, 10 participants used the system on projects from their everyday work and reported clearer, faster understanding of agent-submitted changes. A three-condition comparison with the same participants collected 60 responses, with near-ceiling decision scores and measured representation and pipeline costs. Our research agenda asks how shared project state can preserve human understanding and control as agent contributions accumulate.

Tianfu Wang, Zhezheng Hao, Yin Wu +7

HKUST (GZ) Guangzhou, China · ZJU Hangzhou, China · USTC Hefei, China +1

AI Agent Benchmarks AI Agent Governance Knowledge Graphs Human-AI Collaboration

Ask PDF

Oct 2, 2026

GTDD: Generative Test-Driven Development for AI Coding Agents with Adversarial Testing

Test-driven development gives AI coding agents executable requirements for implementing software. Because these agents can adapt their implementations to the examples they observe, passing a predetermined collection of tests can leave substantial parts of the intended behavior unimplemented. We propose Generative Test-Driven Development (GTDD), a formulation of test-driven development in which a separate testing agent generates new inputs after each candidate implementation is fixed, using a human-specified behavioral contract and the feedback from earlier rounds. A trusted evaluator checks these inputs, returns reduced counterexamples to the coding agent, and saves them for regression testing, so development continually confronts failures beyond the initial examples. We characterize the evidence that this process provides through a finite-population analysis of false acceptance under adaptive candidate selection. The resulting bounds quantify how test visibility and repeated feedback affect acceptance, and show that fresh random audits after candidate commitment control false acceptance across development rounds. In a paired experiment on a stateful key-value store, both policies that regenerated tests during development ended with lower mean failure rates than the policy whose tests were generated once by the same language model, and giving the tester the candidate's source produced no detectable additional improvement. Further conditions requesting equal numbers of tests did not isolate any single feature of the policies as the source of this difference. GTDD combines this adaptive development feedback with established regression tests and an independent acceptance rule.

Masahiro Kato

Mizuho-DL Financial Technology Co., Ltd.

Automated Software Testing AI Coding Agents Automated Test Generation

Ask PDF

Apr 10, 2026

The AI Codebase Maturity Model: From Assisted Coding to Fully Autonomous Systems

AI coding tools are widely adopted, but most teams plateau at prompt-and-review without a framework for systematic progression. This paper presents the AI Codebase Maturity Model (ACMM), a 6-level framework describing how codebases evolve from basic AI-assisted coding to fully autonomous systems. Inspired by CMMI, each level is defined by its feedback loop topology - the specific mechanisms that must exist before the next level becomes possible. I validate the model through a 100-day experience report maintaining KubeStellar Console, a CNCF Kubernetes dashboard built from scratch with Claude Code (Opus) and GitHub Copilot, and through the initial production deployment of Hive - an open-source multi-agent orchestration system that realizes Level 6: full autonomy. The system currently operates with 74 CI/CD workflows, 32 nightly test suites, 91% code coverage, and achieves bug-to-fix times under 30 minutes - 24 hours a day. The central finding: the intelligence of an AI-driven development system resides not in the AI model itself, but in the infrastructure of instructions, tests, metrics, and feedback loops that surround it. You cannot skip levels, and at each level, the thing that unlocks the next one is another feedback mechanism. Testing - the volume of test cases, the coverage thresholds, and the reliability of test execution - proved to be the single most important investment in the entire journey. v2 extends the model from 5 to 6 levels, adding Level 6 (Fully Autonomous) with Hive as reference implementation and Beads for cross-agent memory continuity, plus throughput acceleration data showing 5x PR throughput and 37x issue throughput from Level 2 to Level 6.

Andy Anderson

IBM Research — Hybrid Cloud and AI Platform

AI-Assisted Software Development Software Engineering Multi-Agent Coding

Ask PDF

Abstract

AI-Assisted Software Development

Explore similar work

Scaling Human-AI Coding Collaboration Requires a Governable Consensus Layer

GTDD: Generative Test-Driven Development for AI Coding Agents with Adversarial Testing

The AI Codebase Maturity Model: From Assisted Coding to Fully Autonomous Systems