Written by Mirko Budimir — May 2026
AI ships code faster, and it amplifies bugs just as fast. Most teams answer that with a rules file the assistant follows about 80% of the time — and the other 20% is where the production incidents live: a disabled test, a swallowed error, a skipped auth check. The answer is not a better model. It is the difference between discipline that is suggested and discipline that is enforced.
Spec first. Tests second. AI-generated code third.
Specification first
Intent is written before any code exists — authored and reviewed by people.
Tests second
The specification becomes executable checks before generation starts. AI never writes a change and its tests at the same time.
AI-generated code third
The model does more of the typing, inside the constraints the spec and the tests already set.
Adversarial review
Senior engineers review the output as an untrusted contribution. Nothing merges without explicit approval.
Every step leaves a trace: which spec drove the change, which tests gate it, who approved it. When an auditor — or a client — asks how a piece of code came to exist, the answer is a record, not a recollection.
How it is enforced
Deterministic gates and linters
- —37 pattern rules catch hardcoded secrets, SQL injection and — through the slopwatch pack — the AI shortcuts that pass for completion: disabled tests, empty catch blocks, worthless assertions
- —The hooks always run. They cannot be overridden.
Adversarial review — six specialist reviewers
- —Six isolated reviewers cover compliance, tests, architecture, silent failures, organisational context and gaps in the plan
- —Each is incentivised to find problems rather than to approve
- —Findings come back structured: severity, confidence, the rule cited, the file and the line
Evidence gates — no “done” without proof
- —A claim of completion has to cite fresh build output, test counts and exit codes produced after the last edit
- —Spec-drift detection compares what was built against what was approved; unapproved scope is flagged critical
Humans decide — an approval gate you can't skip
- —The full plan prints and the pipeline stops for human approval before any code is generated
- —The review ceremony scales with blast radius — a small fix is reviewed lightly, a change to authentication gets the full apparatus
Not tied to one assistant
MTK runs as a Claude Code plugin for full enforcement, but it takes in the Cursor, Copilot or Windsurf rules you already have rather than discarding them, and exports native configuration for Cursor, GitHub Copilot, Windsurf, Gemini and Cline.
It is MIT-licensed and language-agnostic, with pluggable stacks for .NET, Python and TypeScript. The guardrails ship with an offline benchmark suite, currently passing 30 of 30.
AI does the work. We stay accountable for the result.
What it changes is velocity without the quiet drift in quality that usually comes with it. New engineers get productive from a codified way of working rather than from tribal knowledge. And an engagement run under MTK produces code that is auditable, extensible and ownable — whether a person or a model did the typing.
The principle is simple enough: everywhere AI enters the workflow, the next step is a control — review, tests, audit trails. It is the same habit we have kept since our first ML models went to production in 2017.
MTK is one of three tools that came out of this work, alongside Warp, our open-source job-processing framework for .NET, and Beacon, a semantic monitoring and alerting layer. All three encode the same idea: AI inside the discipline, never instead of it.
