I have spent a lot of my career on the back end of other people's code. The change that passed every test and still took the service down. The line that read perfectly and meant something slightly different from what everyone assumed. So when people tell me AI has solved software, I notice that it has solved the part that was never really the problem. Writing the code was rarely where things went wrong. Understanding it was.
The tools have inverted the economics of software without anyone announcing that they changed the risk along with it. Producing code is now fast and close to free. A large and growing share of what ships was drafted by a model. And the model is good. It writes code that compiles, passes the obvious tests, and reads as though a competent engineer wrote it. Which is the problem, because none of those is a security property.
Compiling is not a security property
Code can run, pass its tests, and read cleanly, and still be unsafe. A secret hard-coded where it was convenient. A permission left wider than it needs to be. A dependency pulled in because it had the right name, carrying whatever came with it. Logic that is plausible and wrong in the one case that decides whether you have an incident.
The model is not reasoning about any of that. It produces the most likely code given everything it has seen, which is to say code that looks like correct code. Looking like correct code and being safe are different properties, measured with different instruments. It is the same gap I wrote about with prose, where confidence is a property of the writing and correctness is a property of the world. With code the gap is sharper, because code does not only assert something. It runs.
The reviewer was a control, and we quietly removed it
Here is the part nobody put in a diagram. When a human wrote each line, review was already happening. It happened in the author's head, continuously, as they typed. They had to understand the system in order to change it, and that understanding was a security control, an unnamed one, running for free on every line.
AI removes the author as reviewer. The code now arrives without anyone having had to understand it first. The only review left is whatever explicit review you do afterwards, and the volume has gone up while the number of people who can tell secure from merely plausible has not. The difference is unreviewed code in production, which is another way of saying attack surface.
You might think the newest models close that loop themselves. They do more than write now. Fable 5, released this June, would run its own tests, catch its own mistakes, and review merge requests. But when Endor Labs ran it through two hundred real vulnerability-fixing tasks, it landed mid-table, and 38 of them were flagged as memorised rather than reasoned, in one case citing a CVE that appeared nowhere in the task. It looked like security review. It was recall in the shape of one. A later version may well score better, and that is fine, because the point does not rest on the score. A model checking its own work is the author marking their own homework, not an independent reviewer.
You own the intent, not the implementation
The industry is not wrong to push engineers towards these tools. Writing more code with AI is where the work is going, and bragging about how much of the codebase a model produced is fine as far as it goes. The number that matters is not how much the model wrote. It is how much of it someone understands.
Because here is the gap. You know what you asked the code to do. You usually do not know how the model chose to do it, and the how is where the consequences live. The intent is yours. The implementation is the model's, made in whatever way it found, and that way touches other things: an assumption it quietly broke, a dependency it reached for, a choice that is fine today and a problem the next time that part of the system changes. You signed off on the outcome. You never saw the implementation, so you never signed off on that.
This is what vibe coding really is. Not that the code is wrong, but that nobody can say how it works or what it affects. For a demo, or to find out whether something is doable, that is fine. In enterprise production it is a black box with your name on it, running well on the day it ships and impossible to reason about the day it matters. The responsibility is not to avoid the tools. It is to understand what they produced well enough to stand behind it, because 'the AI wrote it' is not an answer to 'what else does this touch, and what breaks when it changes.'
Build for review, not for output
The writing got cheap. The reading did not.
The fix is not to stop using the tools. It is to move your attention to the step that is now the scarce one. Producing code is solved. Judging it is the security control, and judging is the part no tool has taken off your hands.
So resource the review, not the generation. Point it at the surfaces where a flaw actually lands: secrets, permissions, dependencies, trust boundaries, and the unhappy path nobody tested. Keep a human accountable for what ships, because a model cannot be accountable for anything. Know which changes were machine-written, so you can weight the scrutiny towards them. Use the tools to help you review, not only to produce, because review is the half of the work that now needs the leverage.
None of this is new security thinking. It is the oldest security thinking there is, applied to a pipeline that just removed the person who used to do it without being asked.
The test
Take the last change an AI wrote that you shipped. Name who read it for security, and what they checked it against. Not whether continuous integration went green. Not whether it looked fine in the diff. The actual review, and the standard it was held to.
If you can name both, you have a control. If you cannot, you do not have AI-assisted development. You have unreviewed code with a very confident author, shipped on the assumption that looking right and being right are the same thing. They were never the same thing. The tooling only made it cheaper to confuse them.