Artificial intelligence hasn’t just learned to write code. It has begun to shift the center of gravity of an entire profession. The developer is no longer just the one who produces. He or she is becoming the one who sets the framework, supervises, questions—and takes responsibility for what the machine executes too quickly.
Not long ago, the code assistant was just an advanced autocomplete feature. A suggested function, a corrected syntax, a few lines saved in an already fragmented day. The developer stayed at the keyboard, immersed in the code, with that almost physical familiarity that comes from years spent writing, testing, breaking, and rewriting.
Those days already seem like a distant memory.
With agents integrated into development environments, followed by AI capable of acting directly from the terminal, assistance has evolved into delegation. The machine no longer just suggests a single line of code: it reads an entire database, opens files, cross-references tickets, consults logs, interprets errors, writes tests, and prepares a fix. The developer’s role has thus shifted. It no longer consists of producing each individual building block, but rather of understanding whether the whole system holds together.
This shift is more profound than it seems. Because code isn’t just a tool—it’s the company’s operational memory. A rough line isn’t always immediately apparent; it can lie in wait in a production pipeline, a dependency, or a forgotten edge case. The faster AI produces code, the more proofreading becomes a profession in its own right.
The End of the Keyboard as the Center of the Job
In this new organizational structure, a developer’s day resembles a control room more than a series of lines of code. Automatically summarized meetings, condensed Slack conversations, Jira tickets generated from multiple sources, documentation tailored to the recipient, and initial code reviews handled by AI: daily life is now structured around tasks that were once considered secondary.
This isn’t necessarily a loss. Much of technical work has never been purely technical. Understanding a client’s needs, balancing various constraints, deciding what deserves to be automated, and rejecting a poorly formulated request—these are tasks in which human judgment remains crucial.
But this rise in altitude creates a more subtle risk. If you stop writing for too long, you can lose your touch. Yet development isn’t just about technical execution. It’s a way of thinking: breaking down a problem, anticipating an exception, sensing that a function is missing, or realizing that extensive testing isn’t covering the right case.
The danger, then, isn’t that AI is writing code. The danger is that developers will no longer understand why the code works.
The Detail
A context window of one million tokens can now process the equivalent of a very large corpus or an entire codebase of tens of thousands of lines. This change transforms how the system is used: AI no longer acts solely on an isolated snippet but can reason about the architecture, dependencies, and inconsistencies scattered throughout a project.
Three agents, not ten
When a tool delivers results quickly, the natural temptation is to launch several of them at once. Ten agents on ten tasks. Ten parallel workflows. Ten promises of productivity. In reality, the human brain doesn’t work that way. It switches contexts, reconstructs a line of reasoning, forgets a detail, and goes back to review.
The new skill, therefore, isn’t just about “prompting.” It involves orchestrating without losing focus. Limiting the number of tasks handled simultaneously, documenting work rules, keeping track of errors, enforcing writing guidelines, and connecting AI to the right tools: this is what distinguishes a brilliant demonstration of automation from a truly reliable system in production.
The Developer 2.0 isn’t the one who uses the most AI. It’s the one who knows how much to trust it.
A very concrete form of autonomy
Behind the issue of efficiency lies another concern: dependency. When models are running on foreign providers’ infrastructure, critical environments rely on third-party providers, and daily workflows depend on external access, the issue is no longer merely technical. It becomes strategic.
A company that entrusts its development workflow, tickets, logs, errors, prototypes, and documentation to AI agents must understand what it is exposing, what it is retaining, and what it can replace. The productivity gains are only worthwhile if they do not create new vulnerabilities.
This is where the parallel with the luxury sector becomes interesting. A luxury brand never delegates its craftsmanship without safeguards. It may incorporate machinery, modernize a workshop, or optimize a process. But it retains control over its signature style, quality, and final inspection. Software development follows a similar logic: AI can speed things up, but it must not obscure accountability.
Tomorrow, a good developer may no longer be judged by the number of lines of code they produce. Instead, they’ll be judged by their ability to design a framework, detect subtle errors, maintain a clean architecture, document decisions, and protect the production pipeline from taking the easy way out.
Machines know how to write. They can even write a lot. The question remains: who in the company will still know how to read?
Cette publication est également disponible en :
