The Conventional Wisdom
Your team treats AI-generated code like intern submissions. Someone writes a prompt, the AI generates a function, and you spend the next hour fixing type errors, adding error handling, and rewriting database queries. You've built a review process around AI output, tracking how much time developers spend correcting suggestions and measuring acceptance rates.
This feels productive. You're using AI to draft while maintaining quality standards. The conventional approach says: use AI to draft, humans to refine.
Why We Disagree
You're optimizing the wrong loop.
Every minute your senior engineers spend fixing AI-generated authentication logic is a minute they're not building the guardrails that prevent the AI from writing insecure authentication in the first place. You've created a correction treadmill where the same errors appear in every sprint because you're treating symptoms, not causes.
Patrick Debois described this shift at PlatformCon: development is moving from deterministic to non-deterministic systems. The old CI/CD loop assumed predictable inputs and outputs. You write code, tests validate it, you deploy. AI doesn't work that way. The same prompt produces different code on Tuesday than it did on Monday.
The real work isn't correcting individual outputs. It's building the context and constraints that make AI agents produce acceptable code without human intervention.
The Evidence
Look at what breaks when teams rely on the correction model:
Your security requirements don't propagate. You fix SQL injection in one AI-generated query, but the next feature introduces the same vulnerability because the AI never learned your parameterized query standard. You're playing whack-a-mole with OWASP Top 10 violations.
Your compliance controls fragment. PCI DSS v4.0.1 Requirement 6.2.4 requires you to manage vulnerabilities in bespoke and custom software. When you're correcting AI code case-by-case, you can't demonstrate systematic coverage. Your SOC 2 Type II auditor asks how you ensure consistent security controls across AI-assisted development. You point to code reviews. They point to the inconsistency in your implementation.
Your team doesn't scale. You hired three engineers to correct AI output. What happens when you add five more AI agents to the workflow? You hire three more correctors? The economics break.
The development lifecycle Debois referenced isn't a single loop anymore. It's concentric loops where context flows between them. Your correction process sits in the innermost loop, fixing individual outputs. You need to work in the outer loops: the ones that shape what the AI can generate in the first place.
What to Do Instead
Build harness engineering into your workflow. This means creating the infrastructure and guardrails that make AI agents reliable without constant supervision.
Define your security context as code. Don't document your authentication requirements in Confluence. Encode them in schemas, linters, and policy-as-code that the AI can't bypass. If you require OAuth 2.0 with PKCE for all API endpoints, write a pre-commit hook that rejects anything else. The AI learns from rejection faster than from correction.
Instrument your non-deterministic systems. You can't test AI output the way you test deterministic code, but you can measure drift. Track when the AI generates code that passes tests but violates your architectural patterns. When you see the same anti-pattern three times, that's not a correction problem. That's a missing constraint in your harness.
Build context layers, not correction queues. Create a library of secure components the AI can compose rather than asking it to write cryptography from scratch. Your prompt shouldn't be "write a password hashing function." It should be "use the PasswordHasher from our security library." If the AI can't find that library in its context, you've got a tooling problem, not a code problem.
Make your compliance requirements machine-readable. If ISO 27001 Annex A.8.3 requires you to protect media in transit, don't rely on developers remembering to add TLS. Write infrastructure-as-code templates that enforce encryption. The AI should be physically unable to deploy an unencrypted endpoint.
Consider a team building a payment processing feature. The correction approach: review every AI-generated transaction handler for PCI DSS compliance. The harness approach: create a payment SDK that handles cardholder data according to Requirement 3.2.1, then constrain the AI to only use that SDK. The AI can't generate non-compliant code because the compliant path is the only path available.
When the Conventional Wisdom Is Right
You still need human review. The harness engineering model doesn't eliminate oversight; it changes what you're overseeing.
Review the harness, not the output. When you add a new security constraint, verify it actually prevents the vulnerability class you're targeting. When you update your context definitions, check that the AI's behavior changes accordingly. This is architectural review, not line-by-line code review.
Keep the correction loop for novel problems. If your AI generates something you've never seen before (good or bad), that's valuable signal. It means you've found a gap in your harness. Fix the individual case, then update the guardrails so it can't happen again.
For teams just starting with AI-assisted development, the correction model gives you data. You need to see what breaks before you know what constraints to build. Spend your first quarter correcting. Spend your second quarter building the harness that makes those corrections unnecessary.
The shift isn't about trusting AI more. It's about building systems where trust becomes measurable and enforceable through architecture, not hope.
