The Problem With a Single Policy

When your team starts using AI coding tools seriously — not as curiosity but as daily workflow — the instinct is to write one document and hand it to everyone. Install this, configure that, follow these rules. Done.

That document fails almost immediately, because a junior engineer and a senior engineer have completely different failure modes with AI tools. The junior engineer accepts output they can’t explain. The senior engineer delegates architectural decisions they should be making themselves. One set of rules solves neither problem well.

The right approach is a tiered policy: specific guidance for engineers at each level of experience, focused on the failure modes actually common at that level.

The Foundation That Applies Everywhere

Before the tiers, a few rules that hold regardless of experience level:

Index before you start. AI tools give better suggestions when they have context. Before beginning any non-trivial task, load the relevant files and documentation. An AI with context writes code that fits the codebase; one without writes generic code that looks plausible and needs heavy revision.

Plan before coding. For anything that touches more than one file or shared logic, require a step-by-step implementation plan before any code is written. The plan surfaces assumptions, highlights integration points, and gives you a chance to catch a wrong direction before you’re committed to it.

No vibe coding. Treat the AI as a senior engineer, not a code generator. Expect it to reason about architecture and patterns, not just produce syntactically correct output. Vague prompts produce vague code. “Make a button toggle” is not a prompt — “Add a boolean field to the users table, expose it through the endpoint, and render the component conditionally based on that field” is a prompt.

Engineer I: Autocomplete Is Not a Reasoning Engine

Junior engineers benefit most from one foundational reframe: the AI does not understand your codebase. It predicts what code likely comes next based on what’s visible in the editor. It does not remember previous suggestions. It doesn’t know your architecture. It will confidently suggest methods that don’t exist.

The practical rules that follow from this:

• Write intent before accepting. Before letting the tool fill in a function, write a clear signature and a comment describing what it should do. If you can’t write that comment yet, you don’t understand the problem well enough to accept the suggestion.
• Tab only when you can explain it. If a suggestion looks right but you can’t explain what it does and why, don’t accept it. Ask a senior engineer or look it up first.
• Security lines are manual. Never accept autocomplete for authentication logic, permission checks, or database queries without careful review. Never let the tool fill in credentials even as placeholders.

The pattern that needs to stop: accepting a 20-line suggestion because it looked right, finding a subtle bug in review, and explaining that “the AI wrote it.” The AI wrote it, but you shipped it.

Engineer II: Prompt With Context, Not Just Intent

Mid-level engineers have enough experience to know what they need, but AI tools introduce a new failure mode: delegating judgment the engineer should be exercising themselves.

The key shift is moving from “fix my controller” to a scoped, context-rich prompt: “In OrderController.php, the store() method doesn’t validate the quantity field before saving. Add validation using the existing Form Request pattern in the codebase.” The first prompt invites drift from established patterns. The second anchors the output to what actually exists.

Two additional rules worth internalizing:

Validate against the actual codebase. AI will sometimes suggest a perfectly reasonable pattern that isn’t the one your project uses. Consistency matters more than cleverness — match existing conventions.

AI-generated code is your code in review. Be prepared to explain every line in a PR review. Flag AI-assisted sections in the PR description for non-trivial changes, so reviewers know to look more closely. “Copilot wrote it” is not an explanation.

Engineer III: AI for Stress-Testing, Not Decision-Making

Senior engineers have a different problem: they have enough context to use AI effectively for large tasks, which makes it tempting to hand off decisions that shouldn’t be handed off.

The right use at this level is as a challenger and auditor, not a decision-maker:

• Stress-test architectural choices: “What are the downsides of this approach at 10x traffic?”
• Audit cross-cutting consistency: “Are all controllers following the same error handling pattern?”
• Use as a first-pass reviewer on your own PRs before submitting — ask it to find edge cases, security gaps, missing tests.

Senior engineers also carry a mentoring responsibility for AI-assisted code from junior engineers. The failure modes to watch for in PR review: unexplained patterns, hallucinated methods that don’t exist in the codebase, missing tests on AI-generated logic, and conventions that don’t match the project. These are teaching moments, not just corrections.

The other obligation at this level: document the pattern when AI consistently gets something wrong. If there’s a class of mistake that keeps appearing — wrong validation pattern, incorrect assumption about the DI container, misused repository method — capture it in the project rules so it can be referenced in future sessions and doesn’t recur.

What This Stack Actually Solves

Tiered guidelines don’t eliminate risk from AI tools. A determined engineer can accept bad output at any experience level. What the tiers do is make the most common failure modes visible and give engineers a concrete thing to check against rather than a vague instruction to “be careful.”

The test that matters isn’t whether the AI produced good code. It’s whether the engineer can defend every line in review. If they can, the AI was a tool. If they can’t, it was a crutch.