Verification-Driven Development (VDD) is a high-integrity software engineering framework designed to eliminate "code slop" and logic gaps through a generative adversarial loop. Unlike traditional development cycles that rely on passive code reviews, VDD utilizes a specialized multi-model orchestration where a Builder AI and an Adversarial AI are placed in a high-friction feedback loop, mediated by a human developer and a granular tracking system.
| Role | Entity | Function |
|---|---|---|
| The Builder | Claude (or similar) | High-level architectural planning, logic decomposition, and code implementation. |
| The Tracker | Chainlink | A custom issue tracker that breaks goals into a "bead-string" of Epics, Issues, and Sub-issues. |
| The Adversary | Sarcasmotron (Gemini Gem) | A hyper-critical reviewer prompted for low patience and high cynicism to detect structural flaws. |
The software goal is first ingested by the Builder. Using the Chainlink methodology, the task is atomized into a hierarchical structure:
- Epics: Broad feature objectives.
- Issues: Functional components.
- Sub-issues (The "Beads"): Atomic units of work that ensure no logic is left unaddressed.
Before adversarial stress-testing begins, the code must be functionally verified:
- Automated Verification: Test coverage is mandatory. The Builder must write unit and integration tests for all logic.
- Human-in-the-Loop (HITL): Manual testing to ensure the software matches the "spirit" of the requirement. Refinements are made here until the developer is satisfied with the initial feature set.
The verified codebase is presented to Sarcasmotron. This phase is defined by "The Roast":
- Negative Prompting: The Adversary is prompted to have zero tolerance for human error or "lazy" AI patterns (e.g., placeholder comments, inefficient loops, or generic error handling).
- Context Resetting: A fresh context window is used for Sarcasmotron on every turn. This prevents "relationship drift" or the AI becoming too agreeable, ensuring every critique is as harsh and detached as the first.
The critique from Sarcasmotron is fed back to the Builder. The Builder must then:
- Address legitimate flaws.
- Refactor weak logic.
- Update tests to cover the newly discovered edge cases.
As the refinement cycle progresses, the adversarial pressure often reveals edge cases that standard unit testing cannot fully guarantee against. This leads to the integration of Formal Verification tools into the GitHub Runners to ensure mathematical correctness:
- Model Checking & Symbolic Execution: Tools like Kani are integrated to prove that certain conditions (like memory safety or arithmetic overflows) are mathematically impossible within the code.
- Adversarial Cryptography/Security: Integrating suites like Wycheproof to test the implementation against known cryptographic vulnerabilities.
- Automated Correctness Gating: Once these formal methods are established, they are added to the CI/CD pipeline. The Builder is then tasked with ensuring every PR not only passes the "Roast" but also satisfies the mathematical proof requirements of the formal verifiers.
A unique feature of VDD is its hallucination-based termination. The cycle of refinement continues until the Builder detects that Sarcasmotron’s critiques have become hallucinated.
- Maximum Viable Refinement: When the code is so lean and robust that a hyper-critical adversary is forced to invent problems that do not exist, the software is considered "Zero-Slop."
- The Exit Signal: Once the Builder identifies that the critique is no longer grounded in the code’s reality, the cycle stops.
- Anti-Slop Bias: Assumes that the first "correct" version of code is likely the most dangerous due to hidden technical debt.
- Forced Negativity: Uses adversarial pressure to bypass the "politeness" filters inherent in standard LLM interactions.
- Linear Accountability: The Chainlink "beads" ensure that every line of code has a corresponding issue and verification step.
- Entropy Resistance: By cycling context windows, VDD resists the natural tendency for long-running AI conversations to lose focus or quality.
"VDD turns code generation into a survival-of-the-fittest environment where only the most robust logic survives the Sarcasmotron."
All makes sense. I've seen the problems you describe and basically play the role of sarcasmatron. Can you give us the prompts for sarcasmatron? Also, can you say more about chainlink? I have beaten Claude into tracking everything with issues and subissues etc. but I don't have any special support for that.