2026-09-16
When writing code is free, review becomes the control
What the piece actually says
A newsletter visit to a frontier lab describes something I have not seen reported this plainly before: everyone there — engineers, researchers, finance, recruitment, legal — works with an unlimited token budget. In about four months, non-engineering teams went from roughly zero use of the internal coding agent to ninety percent, with no mandate from above. IDE usage has been falling since January. Hand-built internal tools are being retired in favour of the agent, which is now preferred over specialised tooling for debugging. One lead there sums it up as "everything is now a coding agent" — the code may not be the visible output, but agents produce the artifacts. The most interesting machinery described is a performance loop that watches production and kicks off agents to fix issues automatically. And in a line the article almost throws away: pull requests and code reviews need to be rethought. The whole piece is worth reading if you want a picture of where this is heading.
The constraint moved, so the control has to move with it
For two decades the cost of producing a change quietly did security work for us. It rationed volume, because a person had to sit there and write the thing. It made review affordable, because reading a diff was cheap relative to authoring it. And it gave us provenance for free, because a named human could explain why the change existed.
Take authorship cost to zero and all three break at the same time. Volume stops being bounded by headcount. Review becomes the expensive half of the pipeline, which in every organisation I have seen is the half that gets trimmed first. Provenance thins out into a commit that records who clicked approve, not who decided and on what context.
The automated performance loop is the clearest example, and I do not think it is a bad idea. It is a good pattern. It is also, structurally, a path from a production signal to a merged change with no human at the trigger. Anything that can influence the signal can influence the change. That is not a prompt-injection story so much as a plain supply-chain one, and the useful question is not whether the model is good. It is what identity that loop runs as, what it can merge or deploy without a person, and how far it can reach when it is wrong.
One more detail worth holding onto: the article notes the internal version of the agent is considerably more advanced than the one everyone else can use. Reasonable, but it means the published account describes capabilities you have not deployed. Build your threat model around the loops you actually run.
My assumption — untested, and worth checking in your own environment — is that most organisations already have more of these automated write paths than anyone has counted, because they arrived one convenience at a time. This week's reading ran to 45 items, eleven of them already under exploitation. Human attention was scarce before agents started generating diffs.
What to change this month
In this order, and none of it needs a purchase:
- Inventory the automated loops that can reach production, not the agents. For each one: what triggers it, what identity it runs as, and what it can merge or deploy without a human decision.
- Give agent-initiated changes a distinct identity and a label. If you cannot answer "what merged last month without a person deciding" as a query, you do not have provenance, you have a feeling.
- Cap blast radius at the credential rather than the instructions. Scoped, short-lived, separate from the human's own access.
- Move the review budget to where the volume went. Reviewing every diff stops working; reviewing by reach still does. Authentication, crypto, deployment config, CI definitions and dependency changes get a human every time, everything else gets sampled.
Production will eventually tell you which loops you missed. It usually picks the hour.