Context engineering needs a verification step

Context engineering is the work of deciding what an AI coding agent sees before it writes a line: the files, the rules, the prior decisions, the constraints. Get it right and the agent writes code that fits the codebase you already have. Get it wrong and you get confident, plausible code that quietly breaks your conventions.

Almost all of the effort goes into the input side. Better retrieval, tighter prompts, cleaner memory, sharper instructions. That effort stops the moment the agent hands you a file, which is where the risk starts.

Two problems in the gap

More context raises the odds that the output is good. It tells you nothing about whether any particular output is.

The first problem is the tool most teams reach for. An AI code reviewer gives you a different answer every time you ask it the same question. Check a file at 9am and again at noon and you can get two readings of the same code. You can't build a repeatable process on something that won't repeat.

The second is that context lives in prose, and prose drifts. The rule you wrote into your agent's instructions three months ago ("always parameterize queries", "no secrets in source") is a sentence the model may or may not weight on any given run. It stays a suggestion.

Norma closes both.

What Norma does

Norma checks AI-generated code against a fixed set of rules and returns the same verdict for the same code, every time. It runs inside the loop where the code is written, so the finding arrives while the file is still open. And it writes down every check it makes.

Norma is technology-agnostic and detects the stack on its own, with rulesets for JavaScript, TypeScript, Python and PHP, plus specific coverage for React, Node, Vite, FastAPI, SQLAlchemy, Supabase and Adobe Magento. There is also a ruleset for prompts. Norma checks code. It does not write it.

Where it fits in a context-engineered workflow

Take the surfaces you already use to give an agent context, and add a check to each one.

At the point of writing, through MCP. Norma runs as an MCP server that Claude, Claude Code, Cursor, Windsurf, Replit and any MCP client can call directly. The agent that just wrote the code calls live_check on the file it produced and gets findings back before you ever see them. Your context engineering shapes what the agent writes. The MCP check confirms what it actually wrote. The endpoint is https://api.qualityclouds.ai/mcp, OAuth throughout, no API keys.

Two of the six tools change how you think about context. get_rulesets and get_rules_for_ruleset let the agent read the rules it is being held to, which turns your standards from prose buried in a system prompt into structured context the agent can query. The rules become a set it can look up.

Across the whole repository, through the GitHub App. MCP governs the code written by developers who connected it. The GitHub App, live since 27 August 2026, covers everything else. When a pull request opens, it runs a check and posts the findings as a review comment on that pull request. A contractor who never touched your MCP setup, a teammate who has not adopted it yet, an agent nobody told you about: same rules, same verdict. The App asks for one permission, read and write on pull requests, so it can read the pull request and post the comment. It comments. It has no access to repository contents, so it cannot push code or merge anything.

In the editor, through the VS Code extension. "Norma: AI Code Governance" runs Livecheck on the file you are editing and puts findings in the Problems panel, next to the rest of your tooling. It also runs on Cursor and VSCodium. If your verification belongs in CI instead, there is a GitHub Action.

The record

Here is the question a context-engineered workflow cannot answer on its own. Six months from now, when someone asks whether the code an agent shipped was checked, what do you show them?

Norma's audit record stores every call and every finding, including which client made the request. Who checked what, when, and what was done about it. The register_applied_actions tool writes the outcome of a task back into that trail, so the record covers what the agent changed and how it resolved, not only that a scan ran.

If you are investing in context engineering because you are shipping real volumes of AI-generated code, the audit trail is what lets you prove the governance happened.

Two scores, and which one blocks

Norma gives you a Production-Ready Score for a repository. It is diagnostic. It shows you what is failing across the codebase, and it never blocks anything by itself.

Blocking is a separate mechanism. Quality Gates are the pass/fail conditions you set for what is allowed through, and gates are the only thing that stops code. You set the bar. Norma enforces it the same way every time.

Start where your agents already are

If you work inside an MCP-native client, the fastest path is to add Norma as a connector and call it from the agent you already use. It is listed in the Claude connectors directory and on Smithery. For repository-wide coverage, install the GitHub App.

The free tier is permanent, not a trial. Onboarding includes a read-only demo repository that does not spend your quota, so you can see what a check returns before pointing Norma at your own code.

Good context engineering makes an agent more likely to write the right code. Norma tells you whether it did, the same way every time, on the record.

Common questions about context engineering

What is context engineering?

Context engineering is the practice of deciding what an AI coding agent can see before it generates code: the files it retrieves, the coding standards it is given, the prior decisions it needs, the constraints it must respect. The goal is an agent whose output fits the codebase it is working in rather than a generic solution.

How is context engineering different from prompt engineering?

Prompt engineering is about the wording of the instruction. Context engineering is about everything else in the window when the model reads that instruction: retrieved files, project rules, memory, tool definitions, past decisions. On a real codebase the context usually decides the output more than the phrasing does, because the agent needs to know your conventions before it can follow them.

Does better context guarantee the AI-generated code is correct?

No. More context raises the odds that the output is good across many runs. It tells you nothing about any particular file. Verification is a separate step: you need a check that runs after the agent writes the code and gives the same verdict for the same input, every time.

Can an AI coding agent check its own output?

An agent can run a check, as long as the check does not depend on the agent's own judgment. Asking a model to review the code it just wrote gives you a different answer every time you ask, because it shares the blind spots of the run that produced the code. A deterministic check called as a tool works because the rules are fixed: Norma runs as an MCP server, so the agent calls live_check on the file it just produced and gets findings back before the code reaches you.

How do you prove AI-generated code was checked?

You need a record written at the time of the check, not reconstructed afterwards. Norma's audit record stores every call and every finding, including which client made the request, and the register_applied_actions tool writes back what was done about each finding. That answers who checked what, when, and how it was resolved, which is the question an auditor asks six months later.

See the product at qualityclouds.ai/norma, or sign up at norma.qualityclouds.com.