proxiblue.com.au · agent operations · quality gates
Nobody runs them because they run themselves. How I (Lucas van Staden / ProxiBlue) moved coding standards, static analysis and comment hygiene out of code review and into the commit path, so my AI agents' output gets linted, analysed and de-narrated before a human ever reads it.
AI-generated code has a recognisable accent. Comments that narrate what the next line does. Style that drifts a little from the project's standard. The occasional invisible Unicode character smuggled in from who-knows-where. None of it is a bug, all of it is noise, and if I review for it by hand I have become a human linter — the most expensive and least reliable linter available.
The fix is the same shape as everything else in this series: checks that are positional, not aspirational. Quality tooling does not wait for a pull request or depend on anyone remembering to run it. It sits in the commit path and the edit path, fires every time, and blocks when it finds something. My review attention goes to design and correctness, because the machine already argued about tabs.
A hook intercepts every git commit my agents attempt and audits exactly what is staged — not the whole repo, just the files about to become history:
app/code/ gets the Magento2 standard; everything else gets PSR12. Framework core paths deployed by the component installer are skipped entirely — I enforce standards on my code, not on code I merely host.The first four finding a real problem block the commit with the findings printed; the duplicate-block scan reports and lets it through regardless. On a block, the agent fixes and retries; I hear about none of it. And this audit runs alongside the test gate from earlier in the series — proof the tests pass, then proof the code is clean, then a commit.
My rule for comments is that a comment must state a constraint the code cannot show. AI agents, left alone, write the other kind: // call the helper, // loop through the items, // this fixes the issue. Narration. It reads like the model talking to its reviewer, and it is stale the moment the code changes.
So the audit greps the staged diff — added lines only — for narration patterns: "Calls the", "Now we", "Loop through", "Get the", "Set the", "This fixes", "Make sure", and friends. Inline // and # comments only; docblocks are untouched, because API documentation is a different animal. A hit blocks the commit, and the message says exactly what to do: delete the comment, or replace it with the why-constraint the code cannot show.
Patterns are deliberately narrow. A quality gate that false-positives gets worked around, then ignored, then disabled. Every pattern in the list is a phrase that is almost never a legitimate constraint. I would rather miss some narration than block one honest comment — the gate's credibility is worth more than its recall.
The comment-noise scan catches an AI accent in prose. It says nothing about the same accent showing up in structure — copying a validation block into a second controller instead of extracting it, because noticing the duplication existed at all would mean stopping mid-task to look for it, and an agent rarely does.
So the audit also hashes every run of six or more consecutive added lines — trivial lines like a bare } filtered out first — and checks whether the same run appears twice in the same commit, same file or a different one. A hit doesn't accuse; it just says: this exact block exists twice in code you just wrote, go look.
This one warns, it does not block. phpcs and phpstan are compiler-verified; the narration regex is a short list of phrases that are almost never legitimate. Literal-block-repeat has neither guarantee — parallel test fixtures and config arrays can look identical without being a mistake. A fuzzy signal that blocks anyway teaches people to fight the gate instead of the problem, so this one reports and lets the commit through. It earns the right to block later only once real commits show it staying quiet on legitimate repetition.
One check runs even earlier than the commit: after every file write an agent makes, a hook strips invisible and exotic Unicode — zero-width characters, bidirectional control characters, variation selectors, exotic spaces normalised to plain ones. Deterministic, no model involved, silent when there is nothing to strip, which is almost always.
This one is hygiene and security in the same pass. Invisible characters in source are a known attack surface (bidirectional-override tricks can make code review see different code than the compiler does), and they also just have no business in my files. The scrub is non-blocking — it cleans and reports rather than refusing — because unlike a narration comment, there is never a legitimate version to argue about.
Errors block; warnings get filtered out. The first version surfaced everything phpcs produces — deprecation notices, sniff warnings, the lot. Agents dutifully went off fixing unrelated warnings mid-task, and the audit trained everyone to skim its output. Now only actual errors survive the filter and block. A gate that cries wolf is worse than no gate.
Staged-only scope keeps legacy code from taking hostages. Auditing the whole repo would mean no commit lands in an older codebase until every historical sin is fixed. Auditing only what is staged means the standard applies to new work immediately, everywhere, without a big-bang cleanup first.
The narration ban started as prose and failed as prose. The comment rule lived in written instructions for months. Agents agreed with it warmly and narrated anyway — the habit is baked deep into how these models write code. Mechanical scan of the diff ended it. Same lesson, third article in a row: if it must hold, it cannot be a sentence.
The audit had a blind spot for JS/TS-only commits. The early-exit that skips the whole hook when nothing PHP or XML is staged predates the comment-noise scan, and nobody updated it when that scan learned to read .js/.ts too. A commit touching only those files sailed through every check, silently. It only surfaced while wiring in the duplicate-block scan and asking what "staged" actually covers — worth a second look at any gate's early-exit every time you add a new file type to what it scans.
None of these checks is exotic — phpcs and phpstan are in every serious PHP shop already. The difference is where they sit. In most pipelines they run in CI, after the commit, where a failure is a red icon someone deals with later. In mine they run before the commit exists, against an author who never gets tired of being corrected. That author is the whole reason this works: the checks fire dozens of times a day, and nobody sighs.
I use my tooling predominantly on Mage-OS (Adobe Commerce / Magento) e-commerce projects, and my own AI Booking Agent. If you have not swapped to Mage-OS yet, you are falling behind ;)