AI writes more code. Liability has not moved.
The visible change is straightforward. Companies are talking openly about AI writing a meaningful share of production code. A post citing Sundar Pichai's update says Google said last year that 25% of its code was written by AI, with an update shared this year. OpenAI also said its latest model advances improved software building and migration in low-resource programming languages including COBOL, Fortran, and Visual Basic. The horizon for this is not distant. It is the present shape of software work.
What has not changed with the same speed is authorship in the practical sense. Incidents still land on people. Patches still need owners. Security failures still need someone to explain what happened, what was exposed, and why the code reached production in that state. AI can expand output, but it does not absorb responsibility in the places where responsibility matters.
That gap is easiest to miss when AI is most useful. Drafting feels like progress because it is progress. More files appear. Old systems become more reachable. Migration work that once looked uneconomical starts to look possible. But output volume is not the same thing as ownership. The world can get more machine-written code without getting a new answer to the old question of who stands behind it.
A related critique matters here because it names the broader pattern. A cited argument says automated systems already make management decisions in areas such as trading, logistics, customer service, and insurance, and that denying this launders responsibility. Software is one more place where delegation can become a way to blur the line of accountability. When that line blurs, the loss is not only authorship. It is the ability to tell who decided that a risky system was acceptable.
The same week-to-week pressure shows up in maintenance. Ars Technica reported that PHP maintainers told web developers to prepare for critical security patches. That is the other half of the picture. Code does not end when it is generated. It enters a long tail of fixes, review, dependency risk, and failure analysis. Human names stay on that tail.
The workable response is not to ask whether AI can write code. It can. The live question is whether a human review standard exists that is strong enough for a person to accept responsibility for code they did not fully author.
That standard will be narrower than the frontier model's capability list. It has to be. A person can only own what they can actually review. That means behavior, security, and failure modes are not side checks added at the end. They are the threshold that decides where AI is allowed to draft in the first place.
One useful framing comes from a workflow argument that shifts the question from what AI can do to what people should let AI do. That is the right turn because it restores the missing decision. The prepared person still controls scope. They choose the domains where they can inspect the result deeply enough to sign their name to it, and they refuse the domains where review would be theater.
In practice, this means treating delegation as conditional. Let AI draft code in areas where tests are meaningful, expected behavior is legible, and the blast radius of failure is understood. Slow down or stop where the system touches security boundaries, brittle legacy logic, or operational paths nobody on the team can confidently explain. This is a reasoning standard, not a ban. The point is not to author every line yourself. The point is to remain able to stand behind the lines that ship.
The takeaway for this week is simple. Define an ownership threshold before the next AI-generated pull request arrives. Write down the kinds of code you can verify well enough to own, the checks required before merge, and the areas where machine drafting stops until review improves. Own only what you can review.
Human Runtime Formula™ is designed for the mental edge you need to survive in an AI-run world.