A strange-looking condition in a 2015 module, “fixed” by an agent. All tests green, static analysis clean, and the condition was a business rule with history. My review caught it. Barely.
That came out of an experiment I ran this month: a coding agent on one legacy PHP module, since agents can do multi-file changes now and every old codebase suddenly looks like a target.
The setup matters more than the model. I did not ask “modernize this”. I gave a narrow migration goal on one bounded module: replace a deprecated API, add proper namespaces, keep behavior. The same shape of task I would give to Rector. The difference is that the agent also handles the irregular cases Rector cannot express, the places where people wrote creative code in 2015.
The fences: the module has tests, the tests must pass, static analysis must stay clean, and I read the diff line by line before merge. Without the fences this is gambling with extra steps.
Result, honestly. Around eighty percent of the edits were mechanical and correct, and they would have cost me a boring day. Two changes passed every check and were still wrong, the condition above was one of them. The tests did not cover that branch.
The agent is a very fast junior with no fear and no memory of why the code is weird. Excellent for mechanical migrations. Dangerous exactly where the code encodes decisions instead of mechanics.
So we wrote down ban zones: authentication, anything touching money, database schema changes. Those diffs are written by a human who will own them at 2 a.m. Everything else: narrow goal, fences, review. Same rules as Rector, plus more suspicion.
I nearly approved that condition. It looked like a cleanup, and I wanted the boring day back.