Let me start with a story: A senior engineer opens a pull request, everything looks good, the tests pass, the description is clean, the diff is a bit long but nothing crazy. There are comments explaining the migration path, a generated test file, and one of those careful little summaries that makes the whole thing feel more understood than it probably is.
But then, the PR states, coauthored with Claude Code (or any other harness for that matter). It comes with no surprise nowadays that AI had its claws all over the code, but there’s an interesting question that I think needs answering. Who is truly responsible for the changes? Is there a human being who’s willing to say they understand the change well enough to own it when it breaks, defend it in review, explain it during an incident, and accept the consequences of having let it into the system?
That is the part of AI-assisted engineering that still feels under-discussed to me. We spend a lot of time talking about the generation layer. Which model wrote the code. Which agent can use the terminal. Which IDE has the better context window. Which benchmark moved by three points.
But the production system does not end when code appears.
Today, we cover:
Why AI made the approval step more important, not less important.
Why the engineering work is shifting from creation toward supervision.
Why faster code generation exposes the rest of the delivery system.
What sign-off actually means once agents can create real artifacts.
What a sane sign-off system might look like without turning every autocomplete into a compliance event.
The short version is this: AI made generation cheaper. It did not make ownership cheaper.
1. The approval step did not go away
The cleanest AI coding policy I have seen recently comes from a place that is not known for being loose about software process: the Linux kernel.
The penguin itself doesn’t ban the use of AI as maybe some of you would expect, but it doesn’t recognize it as an entity in the process either. It treats AI-assisted contributions as any other contribution. All contributions still need to comply with licensing requirements. AI agents must not add Signed-off-by tags. Only humans can certify the Developer Certificate of Origin. The human submitter is responsible for reviewing the generated code, ensuring licensing compliance, adding their own sign-off, and taking responsibility for the contribution.
That last part is the system.
The kernel also added an Assisted-by tag for AI involvement, including the agent name, model version, and relevant tools. The point is not to shame anyone for using AI. The point is to keep the work attributable enough that reviewers and maintainers can reason about what happened.
The companion tool-generated content guidelines are even more explicit about the underlying problem. Tooling can increase contribution volume, but reviewer and maintainer bandwidth is scarce. If a meaningful amount of content was created by a tool, contributors should be transparent about the tool, the affected parts, the input when it matters, and how the submission was tested.
My read is that the kernel landed on the right framing because it did not start from AI exceptionalism. It started from the existing engineering practices.
The contribution has an origin. The origin needs to be legible. A reviewer needs to know what they are reviewing. A maintainer needs to know who understands the change. A human in the sign-off chain needs to be able to answer questions later.
And this is important! it’s a process with three layers.
The generation layer is where the agent creates something: code, tests, dashboards, documentation, migration plans, internal tools, release notes, incident summaries, or the first version of a design.
The verification layer is where someone checks whether that thing is correct, secure, licensed, observable, compatible with the existing system, and appropriate for the operational risk it carries.
The sign-off layer is where a human accepts ownership in a way the organization can audit later.
Most of the AI tooling conversation is still obsessed with the first layer. That makes sense. Generation is where the demo happens. It is where the speed is visible. It is where a model can do in three minutes what used to take an afternoon.
But the expensive part of engineering was never only producing text that compiles.
The expensive part was knowing what that text means inside a system that already exists.
2. The work is moving from creation to supervision
This is not just a philosophical concern. The work is already moving.
In a longitudinal study submitted to arXiv on May 22, 2026, Annie Vella and Kelly Blincoe followed professional software engineers across two questionnaires six months apart. They had 158 eligible participants at the first point, 101 at the second, and 95 matched participants across both rounds. The headline finding is not subtle: 82% of participants reported spending less time writing code.
But the more interesting finding is what replaced the writing.
The authors describe a shift from creation toward verification activities, and they propose a category they call supervisory engineering work: directing, evaluating, and correcting AI output.
That phrase is a little academic, but the underlying job feels familiar. You ask the agent to make a change. You read the result. You notice it solved the wrong edge case. You redirect it. You ask for tests. You inspect the tests because the tests might only prove the bug it introduced. You check whether the code fits the conventions of the repo. You decide whether the diff is worth keeping, splitting, rewriting, or throwing away.
The same paper reports what it calls a productivity-experience paradox. At both time points, 84% of participants reported productivity improvement. At the same time, among matched participants, the share reporting worsened developer experience in at least one dimension nearly doubled from 14% to 27%. Flow state and cognitive load got worse while feedback loops improved.
That tracks with my own experience much more than the clean productivity story does.
I do feel faster with AI tools. Some days, dramatically faster. I can generate a first pass at an internal script, a content workflow, a test suite, or a migration plan before I would have finished arranging my own thoughts in a blank file.
But I have also noticed the weird part: the tool often moves the work into a mode where I am approving, redirecting, checking, and reconciling. The artifact shows up quickly. The judgment still takes time. Sometimes the judgment takes more attention because the artifact looks more finished than my own unfinished work would have looked at the same point.
This is the approval behavior leak I have written about before. The dangerous moment is not always the spectacular agent failure where a tool tries to delete the repo or run a command it should not run. The dangerous moment is much more ordinary: I am tired, the diff looks plausible, the explanation is polished, and I find myself clicking yes before I have really understood what I am approving.
That moment is going to matter more as the generation layer gets better.
Bad generated code is annoying, but at least it announces itself. Good-looking generated code is harder. It asks for trust before it has earned it.
Now, this is not to say there aren’t players out there completely ignoring this layer, vibe coders and developers are overly relying on AI to the point that they don’t care about the code anymore. That’s not engineering, and while it’s true, they are building things, I surely hope those things are not business critical. Want to vibe code a small internal tool? a dashboard, something that makes your life easier? go ahead! but don’t use the same practice with your critical production systems.
3. Faster generation exposes the delivery system
The optimistic version of AI coding says that if engineers can produce more code, teams can ship more value. Sometimes that is true. It is also incomplete.
If code generation gets faster and the rest of the delivery system stays the same, the bottleneck does not disappear. It moves.
Harness’s 2026 DevOps modernization report is useful here because it looks downstream of the IDE. The report says very frequent AI coding users are more likely to deploy daily or faster, but they also report more deployment pain. According to Harness, 69% of very frequent AI coding users say AI-generated code leads to deployment problems at least half the time. Very frequent users also report longer mean time to recovery for deployment-related production incidents: 7.6 hours, compared with 6 hours for frequent users and 6.3 hours for occasional users.
That does not prove AI caused those incidents. Harness says as much. Teams using AI heavily may simply be pushing more change through systems that were already strained.
But that is exactly the point.
AI does not just generate code. It changes the volume and shape of work flowing through review, CI, deployment, security checks, incident response, documentation, and support. If those systems were held together by a few senior engineers doing late-stage heroics, AI does not remove the heroics. It may increase the number of moments where those heroics are required.
Harness’s engineering excellence material points at the same invisible work from another angle. In a survey of 700 engineering practitioners and managers, Harness argues that developers are becoming validators of machine-generated output, with conventional productivity frameworks failing to capture validation time, agent accuracy, cognitive load, and trust calibration. It reports that 81% of engineering leaders say code review time has increased since deploying AI, and that 31% of a developer’s day is now consumed by AI-related invisible work that appears in no metric.
You can quibble with any one survey number. You should. Vendor surveys come with incentives, definitions, and sampling choices that deserve skepticism.
But the direction matches what I see in practice.
Teams get excited about the gross output. More code. More tasks started. More PRs opened. More internal tools appearing from nowhere. The net output is harder to see because the cost is distributed across review queues, context switching, subtle bug fixing, security review, unplanned coordination, and the cognitive load of deciding what deserves trust.
That is why the sign-off layer matters. It is the place where gross output becomes owned output.
Without that layer, AI adoption creates a pile of things that look done and behave like debt.
