Skip to content
MPL AI Engineering Standards

Pillar 5: Guardrails and Quality

Constraints multiply output. No guardrails means no productivity.

AI coding assistants are pattern followers. Give them good patterns and enforce them through tooling, and the output is consistent and maintainable. Remove those constraints and you generate code at prodigious speed that fails in unpredictable ways. The guardrail system serves two purposes: it prevents code from escaping that does not meet your standards, and it empowers the AI to test its own output in agent mode.

If you are not using unit tests, linting, coding rules, and build tools as constraints, you are leaving the majority of your potential productivity on the table.

What We Expect

Section titled “What We Expect”

Every project has linting and formatting enforced automatically. This is not optional. Linting catches entire classes of errors before they reach review. Formatting removes style debates from AI output. These should be configured in the project and enforced via hooks or CI, not left to developer discretion.

You use test-driven development where it fits. TDD with AI is powerful: write the test first to define the expected behavior, then have the AI implement code that passes the test. The test acts as a specification the AI can verify against. This is especially effective for business logic, API endpoints, and utility functions.

Even when full TDD is not practical, tests should exist before the code is considered complete.

You configure hooks and CI checks to enforce standards automatically. Git hooks, pre-commit frameworks, and CI pipelines can run linting, formatting, and test suites automatically after code changes. Tools like Claude Code hooks and similar mechanisms in other AI coding tools take this further by giving the AI a direct feedback loop: it generates code, the hook catches issues, and the AI self-corrects within the same session.

Configure these per-project and check them into source control.

Type checking is active and enforced. Whether TypeScript, Python type hints with mypy, or equivalent, type checking catches mismatches between what the AI generates and what the codebase expects. AI-generated code that bypasses type checking often introduces subtle integration bugs that only surface in production.

You design your environment so the AI can verify its own output. The most productive AI workflows are closed loops: the AI generates, tests, and self-corrects without waiting for a human. Standard test suites and linters handle backend code, but many outputs lack built-in verification. If your AI is building frontend UI, configure headless browser testing (Playwright, Puppeteer) so the agent can visually confirm its work. If it generates data files, spreadsheets, or documents, create validation scripts or custom MCP tools that let the AI check its output programmatically. The goal is to minimize the surface area where “did it work?” requires a human pair of eyes. Every output type the AI produces should have a corresponding way for the AI to verify it. See Pillar 7: Workflow and Tooling for configuring tools and MCP servers.

You standardize code patterns and enforce them through examples. Consistent structure across your codebase (controller/service patterns, file naming conventions, test organization) makes AI output predictable. Provide scaffolding examples in your rules file or documentation. The AI follows patterns reliably when patterns are clearly demonstrated.

Anti-patterns

Section titled “Anti-patterns”
  • No linting or formatting in the project, leading to inconsistent AI output across developers
  • Writing tests after the fact as a checkbox exercise instead of using them to drive generation
  • Configuring guardrails for humans but not enabling them in the AI tool’s agent loop
  • Treating AI-generated code as “good enough” without running it through the same quality checks as human-written code
  • Expecting the AI to produce frontend, visual, or file-based outputs it has no way to test or verify on its own
  • Keeping guardrail configurations local instead of checking them into source control

Resources

Section titled “Resources”