The integration of artificial intelligence agents into software development workflows has moved from experimental curiosity to operational necessity. However, working with a code assistant for weeks or months reveals an inevitable pattern: the same mistakes recur, communication becomes ambiguous, and trust in the agent's responses erodes without a clear structure. At Q2BSTUDIO, where we have been developing custom software for clients across various industries for years, we have observed that the key lies not in the chosen AI model but in the collaboration protocol established with it. This article presents an original framework — which we call the Counterpart Doctrine — made up of seven axes that enable long-term technical coherence, auditability, and real efficiency in projects involving AI agents.
The doctrine was not born from theoretical planning but from the sedimentation of informal rules after countless recurring failures. Each axis responds to a specific failure mode identified in real development sessions with Claude, Copilot, or other agents. What is presented here is not a closed recipe but a living convention that any team can adopt and adapt. The core idea is simple: if you do not document how you interact with your AI agent, you end up rediscovering the same lesson every week.
Axis 1: Material verification — Every factual claim from the agent ('build successful', 'test passed', 'data confirmed') must be accompanied by supporting evidence in the same message. Without material evidence, the claim has no probative value. This means demanding raw command output, SQL traces, compilation logs, or HTTP responses. At Q2BSTUDIO we apply this rule even in AI tasks involving sensitive data: every reported number must be traceable to its source. A simple 'all good' without evidence is the seed of an error that can cost hours of debugging.
Axis 2: Bidirectional adversariality — Before closing a significant architectural decision (a database migration, a refactor involving more than ten files, a regulatory commitment), a challenger agent is invoked to produce objections, empirical tests, and a confidence score. The primary agent must respond to those objections with facts, not complacency. If the user pushes a change without new data, maintaining the original position is legitimate. This practice avoids confirmation bias and ensures decisions are based on evidence, not persuasion.
Axis 3: Data taxonomy and single source — Any stored derived column must be categorized in the commit that creates it as live (not stored, a view is created), snapshot (frozen at a business event), or cache (stored with a declared refresher). Without an explicit category, the migration is rejected. Business constants are centralized in a single file, and irrevocable invariants are protected at the database level (CHECK, triggers), not just in TypeScript. This axis is especially relevant in projects integrating cloud services like AWS or Azure, where the proliferation of derived data can lead to inconsistencies that are difficult to trace.
Axis 4: Session discipline — Before starting any project of more than two files, a one-page ADR (Architecture Decision Record) is drafted, including the decision, alternatives discarded, consequences, and references. The ADR is written before the first commit, not after. Additionally, a limit of three open projects in parallel is set, and a full symbol scan is required before proposing new abstractions. Recaps are limited to five lines; anything exceeding that is split into separate messages. This discipline prevents cognitive overload and keeps the agent focused on relevant context.
Axis 5: Root cause, not patch — Before applying a fix, the root cause must be identified. A workaround is only legitimate if explicitly declared in both the commit and a feedback file or ADR. Silent workarounds are forbidden. When a solution seems too simple for the observed symptom, the full input-to-output pipeline is required before acceptance. This principle also applies to patterns: if a case is confirmed, the full pattern must be searched in the database or code before correcting it. At Q2BSTUDIO, this axis is complemented by cybersecurity practices, where a poorly grounded fix can open vulnerabilities.
Axis 6: Implicit pedagogy and business transversality — In areas where the user is building expertise (PostgreSQL, EXPLAIN, tax compliance, regulations), the rule of three applies: first time done for the user, second done with them, third done by them. Regulated business vocabulary is used, not vendor vocabulary. Any mention of a norm requires a textual citation; without citation, it is marketing. A vendor's practice is not a constraint; it must be confronted with the project's ADRs before being treated as an invariant. This axis is crucial in BI/Power BI projects, where financial or regulatory terminology must be handled precisely.
Axis 7: Long-term auditability — ADRs are archived in docs/adr/NNNN-title.md. Significant sessions are logged. The memory index is kept to a maximum of 200 lines, with separate topic-specific files. Each feedback memory linked to an active drift must point to a probe that confirms it. Without a probe, the memory rots. A quarterly audit is scheduled where the index is read line by line asking 'is this still true?' The doctrine itself is versioned and audited like an ADR. This axis structures all the others and ensures that knowledge is not lost when the agent changes or the team rotates.
Implementing these seven axes is not a one-day task. It is recommended to start with the three minimums: material verification (the cheapest with immediate impact), root cause (the most protective), and long-term auditability (the one that sustains the rest). During the first sessions, producing at least one dated feedback file is enough. Within a month, those files become the raw material for a sedimented doctrine. At Q2BSTUDIO, we have seen how teams adopting this approach reduce debugging time by 30% and improve code consistency in projects integrating multiple technologies, from process automation to applied artificial intelligence.
The Counterpart Doctrine is not a dogma but a convention that is continuously reviewed. Each axis can be disabled for a sprint if the cost is explicitly assumed. The day an axis no longer serves, it is retired; the day a new recurring failure mode appears, an eighth axis is added. The discipline of long-term coherence is not a method for short-term productivity but the condition for AI-generated code to preserve its integrity as the project grows. In an environment where code generation speed doubles every quarter, having a solid collaboration protocol makes the difference between a functional prototype and a maintainable system.
