A Synthesis Engineering Craft

Systematic Quality Standards: The Second Pillar of Synthesis Coding

Originally published on rajiv.com

When teams first adopt AI for code generation, they tend to make one of two mistakes. Some treat AI-generated code as inherently suspect, reviewing it more carefully than they review human code, second-guessing every line. Others trust it because it compiles and the tests pass. Both responses miss the opportunity.

The second pillar of the synthesis coding framework is systematic quality standards: apply the same standards to AI-generated code as human-written code, but evolve how you achieve those standards.

Same Standards, Different Method

The quality bar does not change because the code was generated by AI. Code review still checks for correctness and maintainability. Tests still need to cover edge cases. Security review still matters. Performance still needs to meet requirements. Documentation still needs to be current.

What changes is how you get there. AI makes quality practices more systematic, more comprehensive, and less dependent on the diligence of individual engineers. That is a genuine improvement, but only if you design for it intentionally.

How Quality Standards Evolve

Testing shifts from writing tests to designing test strategy. In traditional development, an engineer writes an implementation, then writes tests covering the happy path and the edge cases they can think of. Coverage averages 60-70%. Edge cases get discovered in production.

In synthesis coding, the engineer designs the testing strategy: what needs coverage, including authentication failures, rate limiting, concurrent access, data validation, error recovery. AI generates comprehensive test cases systematically. The engineer reviews the suite for completeness and adds scenarios AI missed. Coverage exceeds 90%. Edge cases get caught before deployment.

The skill that matters shifts from “can you write good tests” to “can you design a testing strategy that leaves no important scenarios uncovered.” That is a higher-order skill, and it produces better outcomes.

Code review shifts from line-by-line to pattern-level. When a human writes code, you review it line by line because the bugs are in the lines. When AI generates code within well-defined constraints, the lines are usually correct. The bugs are in the patterns: did the AI follow the right architectural pattern? Does this component interact correctly with the rest of the system? Are the assumptions about input validation consistent with what the caller actually sends?

Pattern-level review is faster per line but requires deeper system understanding. You need to know the architecture well enough to recognize when generated code violates it.

Security review shifts from vulnerability scanning to threat modeling. AI can systematically scan for known vulnerability patterns, often more thoroughly than humans. But AI cannot reason about your specific threat model. It does not know that your regulatory environment prohibits certain data flows, or that your user base includes nation-state adversaries, or that a particular API is exposed to unauthenticated traffic despite what the code comments say.

The human role in security shifts toward defining the threat model and the constraints, then verifying that AI-generated code operates within them.

The Trap of Passing Tests

A test suite that passes is not the same as a correct system.

Tests validate what you thought to test. They say nothing about what you did not think to test. AI-generated test suites can be impressively comprehensive in their coverage numbers while missing the scenarios that actually matter in production.

I have seen AI generate 200 tests for an API endpoint, all passing, while missing the one scenario that caused the actual production outage: what happens when the upstream service returns a 200 status code with an empty body instead of a proper error? The AI tested error codes thoroughly. It did not test for services that lie about their status codes, because that is the kind of thing you learn from operating real systems, not from reading documentation.

This is why quality standards need human judgment at the strategy level. The engineer who has been on call at 3 AM knows which failure modes to test for. AI knows which test patterns to generate. Together, they produce a test suite that is both comprehensive and grounded in operational reality.

Making Quality Systematic Across Teams

One of the strongest benefits of the synthesis coding approach to quality is consistency. In a traditional team, quality depends heavily on the individual engineer. Some write thorough tests. Some do not. Some catch architectural violations in review. Some wave things through.

When quality practices are designed as strategies that AI implements, they become consistent. Every team member works with the same testing strategies, the same security review patterns, the same documentation approach. New team members can see the quality standards encoded in how the team works with AI. They do not have to infer them from inconsistent examples across the codebase.

An engineering director I worked with described the shift: “Our test quality improved dramatically when we moved from ‘AI writes some tests’ to ‘engineers design testing strategy, AI implements it comprehensively.’ We find bugs in code review now instead of production.”

Practicing This

If you are adopting AI in your development workflow, do not lower your quality bar, and do not raise it unnecessarily for AI-generated code. Instead, redesign how you achieve your existing standards.

Start with testing. Write down your testing strategy for a feature before asking AI to implement it. Specify the categories of tests you want: happy path, input validation, error handling, concurrency, performance under load. Then ask AI to generate tests in each category. Review the output not for correctness of individual tests but for completeness of coverage.

Do the same for code review. Before reviewing AI-generated code, remind yourself of the architectural constraints for this part of the system. Review against those constraints rather than against individual line quality.

Quality in synthesis coding is not about whether you can trust AI-generated code. It is about whether you have designed quality practices that produce reliable systems regardless of who or what wrote the code.

synthesis codingcode qualitytestingsoftware engineeringAI-assisted development