When AI writes code engineers no longer understand line by line

What if the real shift brought about by AI in software development is not simply that it can write code, but that code gradually stops being something humans need to understand in detail in order to produce high-performing systems?

Two recent publications offer a glimpse of this transition. The first theorises it. The second already seems to show what it could look like in practice.

When code stops being the centre of the job

In June 2026, Zhenfeng Cao published The End of Software Engineering on arXiv, later revised under the title Agentic Software: How AI Agents Are Restructuring the Software Paradigm.

Its thesis is deliberately radical. For decades, software engineers translated a problem into logic, then translated that logic into code. Code was both the product of their work and one of the main expressions of their expertise.

In Cao’s model, that chain may gradually change. The human defines the intent and constraints. The agent plans, writes the necessary code, executes it, tests it and adapts it. The human becomes increasingly involved in assessing the outcome rather than understanding every operation that produced it.

The engineer’s role could therefore gradually shift from code author to intent architect, coordinator and auditor.

Expertise does not necessarily disappear. It moves up one level of abstraction.

A striking scene at OpenAI

In late August, SemiAnalysis published an analysis of Jalapeño, OpenAI’s new inference processor. Part of the article focuses on kernels, the extremely low-level programs used to exploit hardware efficiently.

SemiAnalysis describes some kernels reaching around 3,000 lines and explains that an internal version of Codex is now being used to generate and optimise some of them. The team reports, in particular, that Codex quickly produced a functional and high-performing implementation of an MLA kernel for DeepSeek without direct intervention from the kernel engineering team.

In a discussion published a few days later, SemiAnalysis’ Jordan Nanos described an even more striking scene. As OpenAI engineers scrolled through one of these AI-generated kernels with them, they clearly understood the hardware, the overall architecture and the principles of the system, but no longer seemed able to explain precisely what each line was doing.

According to Nanos, going through the code line by line essentially produced:

“Nope, nope, nope.”

And yet the program worked and performed very well. OpenAI has also reported using GPT-5.6 Sol with Codex to autonomously rewrite and optimise production kernels, with a reported 20% reduction in end-to-end serving costs. At the same time, the company emphasises the development of verification tools capable of checking the correctness of these programs.

The engineer has not disappeared. But their relationship with the technical object may already be changing.

What this shift changes for work

01 / Skills — Being an expert without understanding every line

It would be excessive to conclude that these engineers no longer understand what they are doing. They understand the system at a different level.

Processor architecture, data movement, hardware constraints, expected performance, correctness tests and overall system behaviour remain areas of human expertise. What appears to be changing is where that expertise is exercised.

The engineer may become less of a specialist in the detailed construction of an artefact and more of a specialist in defining what that artefact should accomplish, how it should be structured and how to verify that it behaves correctly.

A developer using a high-level programming language generally does not understand instruction by instruction the assembly ultimately produced by the compiler. The novelty is not that some technical layer escapes direct human inspection, but that layers of work that previously constituted the engineer’s own intellectual activity may gradually move into the AI system itself.

02 / Autonomy — More capability, but less control over execution

With a capable agent, an engineer can produce far more. They can solve problems that were previously too time-consuming or complex, explore more options and supervise several tasks at once. Their capacity to act increases.

But their detailed understanding of how each result is produced may decrease at the same time. It therefore becomes possible to have more capability without necessarily having more control over all the mechanisms producing that capability.

Yet autonomy at work is not simply the ability to obtain results quickly. It also depends on being able to understand one’s activity, influence how it unfolds, mobilise one’s skills and take back control when something unusual happens.

03 / Expertise — When doing and knowing how to do begin to separate

An engineer may become extremely effective with AI while practising less frequently some of the skills that previously enabled that level of performance.

This deserves to be distinguished from simple “deskilling”. Some skills may become less important while others become more important: understanding architecture, defining a problem correctly, identifying relevant constraints, designing evaluations, recognising an abnormal result and knowing when not to trust the system.

What made someone a good engineer yesterday may not be exactly what makes someone a good engineer tomorrow.

For professionals who have built a significant part of their identity around technical mastery, this transition may also affect professional recognition and their sense of competence.

04 / Automation — The risk of gradually moving out of the loop

Human factors research has long described what is known as the out-of-the-loop performance problem. When automation progressively takes over an activity, the operator may lose part of their situational awareness or practical skills. The problem becomes especially visible when they are required to take over after the system fails.

It would be premature to directly transpose findings from aviation or other automated systems to software development. But they raise a central question: what happens when the human responsible for supervising a system becomes less and less involved in the very operations they may need to understand when the automation fails?

As agents become more capable, it becomes less economically rational to manually inspect every line they produce. But as this inspection disappears, it becomes more important to build other ways of preserving sufficient understanding of the system.

05 / Responsibility — Remaining responsible for an outcome you understand less

In a far more agentic system, the relationship between the person producing code and the object for which they are responsible may weaken. The engineer defines the objective. The agent produces. Automated tools test. The engineer ultimately validates the result.

The risk emerges when the organisation continues to assign the same level of responsibility to the human even as their direct control over production decreases.

Responsibility should remain consistent with the information available to the worker, their ability to act and the level of control they genuinely retain.

Not just teaching engineers how to use agents better

If this evolution continues, prevention will probably not consist solely of teaching employees how to prompt or use new tools.

Decide which skills should deliberately continue to be maintained.
Identify situations where detailed human understanding remains essential.
Preserve activities that let professionals practise the skills required to take back control.
Adapt review processes to volumes of code produced at speeds that may exceed human reading capacity.
Build robust testing and evaluation systems so verification does not rely solely on trust in the model.
Keep responsibility aligned with genuine control. A worker should not be held responsible for a system the organisation no longer gives them the practical means to understand or control.

Perhaps not the end of the engineer, but the end of a certain relationship with code

The original title of Cao’s paper announced The End of Software Engineering. That claim is probably too strong. The paper remains a theoretical proposal published on arXiv, and some of its predictions about the future evolution of agentic systems remain speculative.

The OpenAI example also concerns a very specific domain, namely extremely low-level kernels, and obviously cannot be generalised to software development as a whole.

But the convergence between the two observations deserves attention. One describes a future in which code gradually becomes an intermediate artefact produced by agents. The other describes highly skilled engineers already supervising high-performing AI-generated code without necessarily being able to explain every line.

This does not mean that human expertise is becoming unnecessary. It may instead mean that expertise is changing its object.

From an occupational-health perspective, the question may therefore not only be how many engineers AI will replace. It may also be necessary to understand what happens to the work of those who remain when their productive capacity grows much faster than their ability to directly understand everything they produce.

The paradox may be this: being able to build increasingly complex systems while directly understanding less and less of the artefacts that make them work.

What happens to engineering when AI writes code engineers no longer understand line by line?