Who owns the code? Beyond Vibe Coding held up against 2026
Beyond Vibe Coding names three ideas on AI-assisted engineering that a regulated enterprise should standardize around.
In 2026, regulated engineering organizations have largely worked out permissioning for AI coding tools and developers are using them daily. The real question becomes what to standardize around their usage. It’s time for your bank or insurer to stop debating permissions and start standardizing AI-assisted engineering. Let’s standardize on vibe coding being confined to the sandbox, the merging engineer owning the change, tests and security scans being the contract, and provenance being recorded for every change. Let’s stop measuring adoption by the volume of code generated by tools.
From my perspective.. ten years working with large financial institutions and Fortune 500 companies, now as a principal cloud architect.. the clearest articulation of the split we should standardize around comes from Addy Osmani’s Beyond Vibe Coding (O’Reilly, 2025). Three ideas in particular hold up against what teams are actually doing in 2026, and each points to a standard we should adopt.
Vibe coding stays in the sandbox
Osmani makes a clear distinction between vibe coding and AI-assisted engineering. Vibe coding is about high-level prompting and accepting the output without deep review.. which he argues is fine for prototypes or learning. But AI-assisted engineering is about using those same tools as part of a normal engineering process, with review, tests, and a human ultimately accountable.
I’d argue that distinction has evolved from a description to a policy line, and in a regulated shop, the line is production. I’d recommend documenting where vibe coding is welcome (sandboxes, prototypes, spikes) and defining a single route into production where a demo-working prototype has to go through the same checks as any other change.
The hard 30%
The second idea is Osmani’s 70% problem.. AI gets you to 70% fast, but the last 30% (edge cases, integrating the new module with the rest of the system) is still hard. Security is in the last 30%. Veracode’s 2025 test of AI-generated code found that models picked the insecure option 45% of the time, and larger/newer models didn’t do any better than older ones.
So I’m concluding that tests (and security scanning) on every AI-assisted change are a contract. Write tests before code where possible. And stop counting generated code or PR volume as productivity.. the hard 30% is invisible in both.
You merge it, you own it
The third idea is the developer as reviewer/orchestrator. The book talks about the engineer directing the tools, reviewing their output, and deciding what gets shipped (Osmani’s shorthand elsewhere for this is “copilots, not autopilots”). I think this maps to a rule regulated enterprises already have: the merger owns the change, “the AI wrote it” is never acceptable in an incident review or audit. So review capacity becomes the bottleneck. I’d standardize small diffs and a failing test that existed before implementation.
Provenance also goes in the change record.. which tool was involved, which human edits/approvals happened before merge. This isn’t just for audit: the US Copyright Office said in early 2025 that prompts alone don’t confer authorship of AI output, protection hinges on the human-determined expressive elements. So ownership tracks to demonstrable human contribution, and the change record is where that’s evidenced.
The objection: the models will catch up
The strongest objection is obvious.. tools improve so quickly, a 2025 book is skating to where the puck was.. next year’s models may close the last 30% on their own. But even if generation improves, the accountability and audit requirements in regulated industries don’t shrink. Standardizing how you review and record pays dividends regardless of how good the models get.
One risk to watch is junior hiring. If you cut it because AI does the first 70%, you borrow against the future owners of the last 30%. Osmani makes the point that AI benefits experienced devs more than beginners.. so juniors need deliberate space to develop the judgment the hard part demands.
What I’d tell a CIO
So I’d advise a CIO to standardize four things: a sandbox/production line, merge-owner accountability, tests + security scans as the contract for every AI-assisted change, and provenance in the change record. Stop doing two things: adoption metrics on code volume, and rubber-stamp review of large AI-generated diffs. And keep hiring/growing juniors.. they’ll review the last 30% when today’s seniors move on.