Burdee Standards

This criterion evaluates whether the code is organized into distinct layers with clear responsibilities. Good separation of concerns is the first sign that a human guided the architecture rather than letting the AI pile code into a single file. This is the heaviest criterion in the standards because it determines the maintainability of the entire project.

This criterion measures the level of coupling between system components. Dependency injection and inversion of control are pillars of Clean Architecture. Tightly coupled code is code that cannot be tested in isolation — and is often the result of unsupervised AI generation, where each class directly instantiates its dependencies.

The quality of domain modeling reveals whether the developer thought about the business before coding. AI tends to produce anemic models (simple data containers with getters/setters) because it is the most common pattern in its training data. A rich domain, with entities that carry their business logic, immutable Value Objects and well-defined aggregates, is the mark of a developer who orchestrated the AI with a DDD vision.

Well-architected code is testable code. This criterion evaluates not only the presence of tests, but above all the ability of the code to be tested in isolation. AI often generates code that is difficult to test because it is tightly coupled to infrastructure (database, external APIs). A good orchestrator structures the code so that the domain can be tested without any external dependency.

This criterion evaluates whether the project is divided into autonomous modules with clear boundaries. AI does not know the bounded contexts of your project — it is up to the developer to define them and ensure that each module has a clear responsibility, well-defined contracts with other modules, and minimal cross-dependencies.

Can we identify, for each portion of the code, whether it was generated by AI or written manually? Traceability is essential for maintenance: when a bug occurs in generated code, you need to be able to find the generation context, the prompt used, and the decisions made. Without traceability, AI code becomes a black box that is impossible to debug effectively.

Was the AI-generated code systematically reviewed, understood and validated by a human before being integrated? Human validation is the keystone of orchestration. A developer who copy-pastes AI code without understanding it is not orchestrating — they are blindly delegating. Validation implies understanding, critical review and explicit approval of each generation.

Are the AI results reproducible? If the same prompt were run again in the same context, would a similar result be obtained? Reproducibility comes from documenting prompts, the context provided to the AI, and the parameters used. It is a fundamental principle of the scientific approach applied to AI-assisted software engineering.

Has the developer clearly defined what the AI can and cannot do in the project? A good orchestrator knows when to use AI and when to do without it. They define the constraints, conventions and limits before launching a generation. Architectural decisions, domain modeling and security choices must never be delegated to AI without supervision.

Is the code self-documenting? Do variable, function and class names clearly express their intent? AI often generates generic names (data, result, temp) or reproduces conventions from documentation examples. A good orchestrator enforces intentional and consistent naming that reflects the business domain language.

Are functions short and focused? Is cyclomatic complexity under control? AI tends to generate long functions with many conditional branches, because it optimizes for completeness rather than simplicity. An orchestrator ensures that each function operates at a single level of abstraction and remains understandable at a glance.

Is the same problem solved the same way throughout the project? One of the most common flaws of AI-generated code is stylistic inconsistency: each generation may propose a different pattern for the same type of problem. A good orchestrator enforces conventions and verifies that the AI follows them consistently.

Does the project contain dead code, orphan TODOs, unused dependencies or undocumented hacks? AI sometimes generates code "just in case" — classes never used, redundant methods, superfluous imports. A well-orchestrated project is a clean project where every line of code has a reason to exist and every technical compromise is documented.

Are data access patterns optimized? One of the most frequent pitfalls of AI code is the N+1 problem: a loop that executes one query per iteration instead of a single load. AI does not "see" the performance implications of its choices — it is up to the developer to verify that queries are efficient, indexed and paginated.

Is every project dependency justified? AI frequently suggests third-party libraries for simple tasks, creating dependency bloat that weighs down the project, increases the attack surface and complicates updates. A good orchestrator challenges every composer require and prefers native code when reasonable.

Does the code properly manage system resources? Files, connections, memory — every resource opened must be closed, every allocation must be freed. AI often forgets these details because they are not necessary for the code to "work" on the surface, but they cause insidious problems in production.

Does the project incorporate digital sobriety considerations? At a time when digital technology accounts for 4% of global greenhouse gas emissions, eco-design is a professional duty. A responsible orchestrator minimizes the footprint of their code: lightweight payloads, compression, HTTP cache, optimized images, no superfluous requests.

Is the code protected against the 10 most common web vulnerabilities? The OWASP standard is the global reference for application security. The most frequent flaws in AI-generated code are injections (SQL, XSS, command), missing CSRF, poor authentication management and exposure of sensitive data in API responses.

Are secrets (passwords, API keys, tokens) properly externalized and protected? This is one of the most serious and frequent errors in AI-generated code: hardcoded credentials in the source code, a .env file committed by mistake, API keys visible in the git history. A single leaked secret can compromise an entire system.

Is personal user data protected in compliance with GDPR and security best practices? AI has no notion of regulatory compliance. It can log personal data, store passwords in plaintext, or expose sensitive information in API responses. It is up to the developer to ensure that every piece of personal data is treated with the respect it deserves.