Encoding Team Standards

The Consistency Problem

When AI-assisted development depends on who is prompting, seniors become bottlenecks, not because they write the code, but because they are the only ones who know what to ask for.

I have observed this pattern repeatedly. A senior engineer, when asking the AI to generate a new service, instinctively specifies: follow our functional style, use the existing error-handling middleware, place it in lib/services/, make types explicit, use our logging utility rather than console.log. When asking the AI to refactor, she specifies: preserve the public contract, avoid premature abstraction, keep functions small and single-purpose. When asking it to check security, she knows to specify: check for SQL injection, verify authorization on every endpoint, ensure secrets are not hardcoded.

A less experienced developer, faced with the same tasks, asks the AI to “create a notification service” or “clean up this code” or “check if this is secure.” Same codebase. Same AI. Completely different quality gates, across every interaction, not just review.

This is not the junior developer's fault; they have not yet developed the instincts. But the inconsistency is expensive. AI-generated code drifts from team conventions when one developer prompts and aligns when another does. Refactoring quality varies by who requests it. Security checks catch different things depending on who frames the question. Technical debt accumulates unevenly.

The instinct is to treat this as a skills problem: train the juniors, write better documentation, do more pairing. These all help, but they are slow and they do not scale. The knowledge exists on the team; it simply has no vehicle for consistent distribution. What is needed is a way to take what the senior applies instinctively and make it available to everyone, not as advice to remember, but as instructions that execute.

This is a systems problem, not a skills problem. And it requires a systems solution.

The earlier techniques in this series address what the AI knows. Knowledge Priming gives the AI the project's conventions. Design-First collaboration builds alignment on architecture. Context Anchoring makes that alignment durable across sessions. This article is about something different: making the AI apply the team's judgment, consistently, regardless of who is prompting, across every meaningful interaction.

Executable Governance

Teams have always tried to codify their standards. The challenge has always been the gap between documentation and practice. A checklist on a wiki depends on someone reading it, remembering it, and applying it consistently under time pressure. In my experience, that gap is where most codification efforts quietly fail.

AI instructions change this dynamic in an interesting way. A team standard encoded as an AI instruction does not depend on someone remembering to apply it. The instruction is the application. When a developer generates code using an instruction that embeds the team's architectural patterns, or runs a security check that encodes the team's threat model, the standards are applied as a side effect of the workflow, not as a separate step that requires discipline. The governance is the workflow.

I find it useful to think of this as two moves:

From tacit to explicit. The first move is the familiar one: taking what the senior knows instinctively and writing it down. The difference is that the target format is not a wiki page or a checklist, but a structured instruction set that an AI can execute. The act of writing it surfaces assumptions that were never articulated. What exactly makes a security issue critical versus merely important? These distinctions, often intuitive for the senior, must become precise for the AI.

From documentation to execution. The second move is the one that matters. Linting rules are versioned config files, not personal preferences. CI/CD pipelines are executable definitions, not wiki pages describing deployment steps. AI instructions belong in the same category: configuration that executes, not documentation that informs. When these instructions live in the repository, reviewed through pull requests, shared by default, they have the same status as any other piece of team infrastructure. The developer does not need to carry the team's full set of standards in their head. They invoke an instruction. The team's judgment is applied consistently — not because the developer memorized it, but because the infrastructure encodes it.

What This Looks Like

A well-structured executable instruction has a recognizable anatomy: four elements, each doing distinct work. This anatomy applies regardless of the instruction's purpose.

• Role definition. Not because the AI needs a persona, but because the role sets the expertise level and perspective. “Role: senior engineer implementing a new service following the team's architectural patterns” establishes a different baseline than a generic prompt. The role is the lens through which every subsequent instruction is applied.
• Context requirements. What the instruction needs before it can operate: the relevant code, access to the project's architectural context, any applicable constraints. This makes dependencies explicit rather than hoping the developer remembers to provide them.
• Categorized standards. The categories matter more than the individual items. For a generation instruction, the categories might be: architectural compliance (must follow), convention adherence (should follow), and style preferences (nice to have). For a security instruction: critical vulnerabilities (blockers), important concerns (must address before merge), and advisories (track and evaluate). For a review instruction: breaking issues, important findings, and suggestions. This priority structure encodes the team's judgment, not just their knowledge. It tells the AI, and through the AI, the developer, what matters most.
• Output format. A structured response with a summary, categorized findings, and clear next steps. The format ensures that output from the instruction is comparable across runs and across developers, a property that matters once multiple people are using the same instructions regularly. For generation instructions, this shapes the completeness and structure of the code produced — not a findings report, but the conventions of the output itself.

The principle applies across the full range of AI interactions. For example:

• Generation: encodes how the team builds new code (architecture patterns, naming, error-handling, testing expectations) so output aligns from the first pass.
• Refactoring: encodes how the team improves existing code (preserve contracts, avoid premature abstraction, propose incremental change).
• Security: encodes the team's threat model (what to check and how to grade severity) so checks are team-specific rather than generic.
• Review: encodes what the team checks in review (architecture alignment, error handling, type safety, conventions) with a consistent severity structure.

Keep instructions small and single-purpose. Smaller instructions maintain focus, are easier to maintain, and compose flexibly.

Surfacing the tacit knowledge.

The most interesting part of creating these instructions is the extraction process. It amounts to an interview with the team's senior engineers, structured around pointed questions that span the full development workflow: What architectural decisions should never be left to individual judgment? Which conventions are corrected most often in generated code? Which security checks are applied instinctively? What triggers an immediate rejection in review? What separates a clean refactoring from an over-engineered one?

The answers map directly to instruction structures. Non-negotiable architectural patterns become generation constraints. Frequent corrections become convention checks. Security instincts become threat-model items. Review rejections become critical checks. Recurring mistakes become anti-patterns to flag. The interviews essentially write the instructions; the act of creation is the act of organizing tacit knowledge into explicit, prioritized checks.

I have found that this process has value even beyond the resulting instructions. On one project, the extraction conversation revealed that two senior engineers had quietly different thresholds for what counted as a “critical” security concern versus an “important” one, a disagreement that had never surfaced because each reviewed different pull requests. The act of writing a shared instruction forced the distinction to be made explicit. Once a less experienced developer on the team began using the resulting instructions, the effect was immediate: their first review flagged a missing authorization check on a newly added endpoint, exactly the kind of issue that had previously only been caught when a senior happened to be the reviewer. The instructions did not make the developer more experienced. They made their inexperience less costly.

Where Standards Meet the Workflow

These instructions are not a single-purpose tool. They apply at different points in the development workflow, and the point of application shapes their value.

At generation-time, when a developer asks the AI to create a new service, implement a feature, or write tests, a generation instruction ensures the output follows team conventions from the start. This is where encoded standards have the most leverage: they prevent misalignment rather than catching it after the fact.

During development, a refactoring instruction keeps improvements aligned with team norms, and a security instruction applies the team's threat model rather than a generic checklist. The standards are present throughout the development process, not bolted on at the end.

At review-time, when a developer finishes a piece of work (whether AI-generated or manually written), a review instruction applies the team's quality gate. But review-time is the last opportunity to catch misalignment — the earlier in the workflow standards are applied, the fewer issues that reach it.

Optionally in CI, some teams extend these instructions into their continuous integration pipeline as an automated consistency check. CI-level instructions must be fast enough not to slow the pipeline, predictable enough to avoid noisy false positives, and maintained with the same discipline as any other CI gate.

Standards as Shared Infrastructure

A prompt on an individual machine is a personal productivity hack. The same prompt in the team's repository is infrastructure. The distinction is the difference between a personal preference and a team practice.

When it lives in the repository, it inherits the properties of any versioned artifact: changes tracked, standards owned collectively, every developer working from the same version. Different tools implement this differently — custom commands, skills, rules files, project instructions — but the underlying property is the same: a versioned, shared artifact that the AI executes consistently.

This is how the team comes together to make the standards better. A developer who notices that the generation instruction does not specify the team's new error-handling pattern submits a PR to update it. A security incident reveals a gap in the security instruction; the fix is a commit, reviewed and merged like any other infrastructure change. The standards are not static rules handed down by a senior and frozen in place. They are living artifacts that the whole team maintains, sharpened by practice, and improved through the same pull request workflow the team already uses for code.

In an earlier article, I described the key shift in context management as treating context as infrastructure rather than habit. The same principle extends here: the priming document tells the AI how the project works; the executable instruction tells the AI how the team works.

There is a real risk that these instructions become another documentation graveyard, created with enthusiasm and abandoned within months. Repository placement and pull request review mitigate this. An instruction that lives in the repo is visible. It appears in diffs. It can be referenced in pull request templates. When it drifts from actual practice, the drift is visible in the same way that a stale test is visible, not because someone audits it, but because it is encountered in the normal course of work. The closer the artifact is to the workflow, the more likely it is to be maintained.

Calibration

This approach is most valuable when a team is large enough that consistency cannot be maintained through conversation alone. A useful heuristic: if AI-assisted output visibly varies in quality depending on who is prompting, or if generation and review work is routing through a handful of people because they are the only ones who know how to prompt effectively, the inconsistency is the signal. Teams of five may not need this. Teams of fifteen almost certainly do.

The costs are real. Creating good instructions requires effort — the extraction interviews, the drafting, the iteration. Overly prescriptive instructions become brittle; they produce false positives on edge cases or fight against legitimate variations in approach. There is a maintenance burden as standards evolve. And there is a risk of over-engineering: not every interaction with AI needs a dedicated instruction.

The right starting point, in my experience, is one instruction. A generation or review instruction is usually the highest-value choice; it addresses the most common workflow, the widest quality gap, and the most visible inconsistency. Additional instructions should follow adoption, not precede it.

Conclusion

This is, at its core, a shift from judgment that lives in people's heads to judgment that executes as shared infrastructure. The senior engineer's instincts (the patterns she checks, the conventions she enforces, the risks she flags) do not have to remain personal and unscalable. They can be extracted, encoded into versioned instructions, and applied consistently across every developer and every interaction with AI.

The mechanism is not new. Teams already do this with linting rules, CI pipelines, and infrastructure-as-code. What changes with AI is the scope of what can be encoded. Linting catches syntax and style. Executable team standards can encode architectural judgment, security awareness, refactoring philosophy, and review rigor, the kind of knowledge that previously transferred only through pairing, mentorship, and years of shared experience.

The most interesting property of these standards is that they are team-owned. They live in the repository. They evolve through pull requests. They improve when practice reveals gaps. Every instruction that misses something is an instruction waiting to be updated, and the update is a commit that the whole team reviews. The standards are not just the output of team knowledge; they are the mechanism through which team knowledge gets codified, shared, and refined.