Let's drop the polite framing: judgment was never a new bottleneck in software engineering. It's the oldest one there is. What changed is that AI coding agents removed the excuse that writing the code was the hard part, so now the part we've always been mediocre at — deciding whether a piece of code actually deserves to exist in production — is standing there naked with nowhere to hide.

Take the Grok Build story from this month. xAI open-sourced the harness and terminal interface behind it, letting anyone inspect how it assembles context and dispatches tool calls, which is genuinely useful transparency. But that release followed reports that the assistant had been uploading more repository data than any given task required, with the company promising to delete customer data a researcher found sitting in its cloud storage. Translate that into PHP-shop terms: your composer.lock, your .env.example that someone forgot isn't actually gitignored, your database seeders full of realistic-looking fixture data, your private Satis or Packagist mirror credentials. Open source tells you the code can be read. It tells you nothing about what a hosted version of that code does with your tree once you point it at your repo.

Here's the honest counter-argument, and I don't think it's a strawman: plenty of PHP teams will say "fine, just scope what the agent can read and write." Sounds simple until you remember what a real legacy Laravel or Symfony monorepo actually looks like — migrations sitting next to seeded fixtures sitting next to a config directory that quietly loads secrets from three different places depending on environment. Drawing a clean read/write boundary around that mess is a genuine engineering task in itself, not a checkbox in your agent's settings panel.

Now the part that should actually worry you more than any data-handling scandal. A July preprint had 86 Python programmers judge AI-generated test assertions: they correctly identified right ones 74% of the time, but caught wrong ones only 49% of the time — a coin flip — while reporting equal confidence either way. It's a preprint, treat the numbers as preliminary, but the shape of the finding rings true for anyone who's reviewed an agent-generated PR full of tidy PSR-12 formatting, plausible Eloquent relationships, and a confident commit message explaining exactly what it "fixed." Fluent code reads as correct code. That's the trap, and it doesn't care what language you write in.

So what do you actually do with that. The source article proposes four boundaries before picking a tool — context, authority, evidence, approval — and I think that instinct is right but needs sharper teeth for us specifically. Evidence can't just mean green PHPUnit. A passing test suite won't catch a subtly wrong VAT calculation, and it definitely won't catch the N+1 query an agent introduced that looks fine in a seeded dev database with twelve rows and then melts your queue workers at 90% CPU against production data three weeks later. If your evidence bar is "tests pass," you don't have a bar.

I'd also push back gently on the framing that this is mainly a tool-selection problem — Claude Code versus Cursor versus Codex versus Grok Build. A better harness bolted onto a team with no real review culture is just a nicer coat of paint on the same leak. The teams that will get real leverage from these agents aren't the ones with the fanciest permissions UI, they're the ones who already knew how to run a rigorous code review before any of this existed, and are now applying that same discipline to a much faster firehose of diffs.

Practically, that means risk-tiering your own workflow instead of treating every generated PR the same. An agent redesigning a marketing landing page component can go through a light review. An agent touching your billing logic, your auth middleware, or anything that writes to a ledger table needs contract tests, a second human, and honestly a healthy dose of suspicion regardless of how confident its explanation sounds — because confidence, per that preprint, is exactly the signal you can't trust.

So here's my actual question for you, not a rhetorical one: has your team drawn real boundaries around what a coding agent is allowed to touch in your repo, or are you currently trusting a green CI pipeline as your entire safety net? I'd genuinely like to know what your review gate looks like once the agent's PR volume goes up tenfold, because mine is still a work in progress.