Is Agentic AI Ruining How We Code? What Our Engineers Learned About Ownership and Skill

Third article in a three-part series drawn from our internal study of how engineers work with agentic AI. Seven developers, interviewed over two weeks in August 2026.

When AI first emerged, the discourse about developers becoming obsolete was profound. The "chat box" AI was capable, but grabbing the developer's career still felt out of reach — it sat outside the work, waiting to be asked. Agentic AI changes the shape of that, because the capability is no longer inside the box. It lives inside the codebase, running multiple iterations on its own.

Historically, professional obsolescence through emerging technology is not a new phenomenon. Every production technology that arrives in a skilled trade sets off the same round of argument, and the people defending the old practice are rarely defending it out of nostalgia. They are usually pointing at something the new method does not reproduce. Not the output, which it typically handles well, but what performing the old practice did to the person performing it.

The first two articles in this series described how agentic AI behaves inside a workflow: how developers steer it, and how they decide what it is allowed to do. This one is about what our participants say is happening to them.

The shape of agency

Software engineering has never been only about writing code. At its core, it is about solving problems, while code is simply the form those solutions take. Our participants described their work as shifting more toward decision making and problem solving as execution is increasingly delegated. Their attention is moving toward understanding the product, the broader problem, and the relationship with the client. If a developer’s sense of agency came mainly from typing the code, then delegating that task would clearly feel like a loss. But our participants did not see their role that way.

Our participants described this differently. Even when they felt they had lost some technical skills, they did not feel less ownership over the work. What differed was how they explained why the work still felt like theirs. These explanations can be grouped into four positions along a continuum, depending on how closely each one is connected to the code itself.

Review. Ownership rests on inspection. The code is yours once enough of it has been personally scrutinised.

Comprehension. The artefact is still read, but no longer gated line by line. Ownership rests on being able to answer for the system, such as debugging it quickly, explaining it, connecting it to what the client needs.

Decision. Review is decoupled from the editing surface. What is owned is the set of decisions that shaped the implementation, rather than the implementation.

Accountability. The code is not read directly at all. Ownership rests on the name attached to the commit and the obligation to answer for whatever ships under it.

In our data these grounds sort with the working environment. Participants working inside an IDE ground ownership in what they did to the code: inspecting it, understanding it. Participants working from the command line ground it in authorship of decisions and in responsibility after the code shipped.

The obvious reading of that is not one we can support. It is tempting to say the tool changes how a developer relates to their work, but our data cannot establish direction. It is equally possible that developers who already located ownership in decisions were the ones comfortable moving to a terminal. We record the co-variation and keep it as a proposition rather than a finding. Testing it would mean following developers through a tooling migration, or comparing teams whose inspection environments differ while the work stays the same.

What does not vary is the part underneath all four positions. Not one participant suggested that responsibility moves with authorship. One compared the agent to a car: a tool that gets you there faster, and one you still need a licence to operate. Another, who acknowledged not reading every line, was explicit that if something goes wrong it is him who gets pointed at. The mistake cannot be pointed at the tool.

Ownership has therefore migrated without diminishing. What is owned is no longer a body of text the developer produced. It is a working system that someone will eventually have to answer for, and the answering is the part that cannot be handed over.

Reading maintains what writing built

Several participants decline the skill-erosion premise outright. One argues that a decision cannot be made without first understanding what was proposed, so the ability to read code cannot quietly decline. Another argues that reading sustains the skill directly: syntax remains available as long as code continues to be read, even when far less of it is written by hand.

Both treat manual typing as a practice they can safely drop. Neither dismisses the value of having learned to code manually. The claim is narrower and more defensible than it first sounds: maintaining an established skill requires active review rather than constant writing.

The harder question is whether reading is engaged enough to count. Shen and Tamkin ran a randomised controlled trial on learning an unfamiliar library and found that AI-assisted participants showed reduced gains in conceptual understanding, code reading, and debugging. Their finding identifies cognitive engagement as the variable that matters: aggressive AI integration impairs professional development when that engagement drops.

Our participants' position is consistent with that. They also point to what organisations may need to preserve: opportunities for developers to remain actively engaged with the code they review. However, neither their study nor ours shows whether reviewing AI-generated code during real production work provides the same kind of engagement, especially when the time saved by AI is simply replaced by tighter deadlines. Reading code under pressure may be very different from reading code with the goal of learning.

So is it ruining anything?

This historical pattern is important because it shows two sides of the same issue. Workers who feared being replaced were often wrong about losing their jobs completely, but they were right about the deeper change. When the way something is produced changes, it also changes how people learn to do that work. The profession may continue to exist, but the traditional path for entering it often changes or disappears.

Our participants are making a similar argument in a new context. They have delegated much of the writing while continuing to read and review the code, and they believe that this is enough to maintain their skills. That may be true. But every participant in this study learned to program before agentic AI became part of their work. Their experience tells us more about maintaining an existing skill than about developing that skill from the beginning. Their views on junior developers are therefore predictions about a group they have not yet had much experience supervising in this new environment.

Ownership may be changing, but responsibility still remains with the developer. This conclusion also depends on how we define software engineering. If the job is mainly about producing code, then giving that task to an agent clearly removes part of the developer’s role. But if software engineering is mainly about solving problems—understanding what needs to be built, deciding how it should work, and taking responsibility for the outcome—then what has been delegated is the act of writing the code, not the engineering itself.