Personal essay · June 6, 2026

The detour that imposed itself

I started writing this reflection on May 14, 2026. At first, I wanted to write a fairly conventional article about market segmentation, AI budgets, credits, models, vendors, the companies that will pull ahead, and the ones that will have to catch up.

Then I reread the draft, and something bothered me.

The article was interesting. It said things I still believe are true. But suddenly, I no longer fully recognized myself in it. I heard myself speaking like someone explaining to others what they should understand, how they should prepare, how they should organize their teams, documentation, budgets, and practices.

And there it was: discomfort. I no longer want to be that person.

I do not want to keep acting like the mother-in-law of the corporate world. Saying, "you should do this, you should have understood that, you are going to hit a wall." There may be truth in some of those observations, but that is not the place where I want to stand.

So I will take a detour. Maybe even the real detour.

I am retiring. I am leaving the race.

I am not leaving because AI no longer interests me. It is rather the opposite. I am leaving after having lived, at the end of my career, one of the most fascinating intellectual experiences of my professional life. But I am also leaving because that experience made something very visible that I can no longer ignore: I no longer want to organize my life around performance, velocity, optimization, and production.

The phase of abundance carried me

Since 2025, developers have lived through a very unusual period. Models followed one another quickly. IDEs filled up with agents, copilots, composition modes, contextual chats, and sometimes very generous experiments. More than once, it felt as if we had access, almost for free or almost without limit, to capabilities that would have seemed impossible not long before.

I do not want to reduce that period to a simple business strategy. It was a conquest phase, of course. The major providers had every reason to habituate developers, to integrate the tools into IDEs, to create reflexes, to make AI part of everyday work.

But on my side, I experienced it with wonder.

When I adopted agent mode in May 2025 and started Ezkey as a personal laboratory, I felt as if I were resetting my entire practice. Ezkey became my clean room. A synthesis project. A place where I could revisit the foundations, test good practices, do things properly, return to analysis, design, architecture, testing, and living documentation.

There was also something more intimate in that project. I could make it entirely mine. I could experiment, make mistakes, start again, correct, simplify, change my mind, revisit a decision, rebuild a layer I had misunderstood. The project was promised to no one. It had no client waiting for delivery, no committee to convince, no time budget to defend. It could become exactly what I wanted it to become, at the pace at which I managed to understand it, including never really becoming anything in the eyes of the market.

I am a backend developer. I work a lot by instinct. I am sometimes messy. I have trouble naming things. I have trouble staying focused. I make mistakes. I believe I have good reflexes and some capacity for introspection, but method has not always come naturally to me.

AI compensated for exactly the gaps it needed to. It helped me structure, rephrase, review, document, test, and challenge my decisions. It made a return to fundamentals profitable, where I had long kept part of those fundamentals in my head. I evolved with it. The models became better, and I also became better at collaborating with them.

That period fed several of the articles I have written. The return to foundations. Intent. Context. Spec-first. Documentation that stops being a moral debt and becomes a living tool. I did not merely observe all of that. I lived it in a project that gave me energy.

The recovered malleability of software

That energy did not come only from the novelty of the models. It also came from a freedom I had almost forgotten.

Over the years, I had come to accept an obvious fact of the profession: you cannot revisit everything. Time is limited. Ideas must be prioritized. Teams must align. Budgets exist. Systems that have already been tested, are already in production, and already depend on other systems do not move like pieces on a table.

A former director once told me, with very accurate humor: "Marc, you have plenty of good ideas. If you want to work another forty hours to implement them, you can!" He was right. Behind every good idea, there is risk, time, testing, possible regressions, and trade-offs. Even when the idea is good, it is not automatically the priority.

After living that way long enough, you internalize the constraint. You learn to censor some paths before even formulating them. You carry a small background tension, like a muscle pain so old that you almost stop noticing it. You know that sometimes you should realign, refactor, document, extract, test better, introduce a message queue, strengthen a boundary between components, revisit an architecture. But you also know that the business is waiting for something else, that the branch may stay open too long, and that energy is not infinite. So for me, no more features rotting on branches for years.

AI made that tension visible. In a personal project like Ezkey, with context well maintained, solid tests, and total freedom, I recovered something I had practically forgotten: software is malleable. Not for free. Not magically. Building the wrong thing is still expensive. A system can become spaghetti, fragile, conceptually misaligned. But when the context is explicit and validations exist, the possibility of revisiting, realigning, restructuring, and improving becomes much more concrete again.

That moment was a grace. Before budgeting came back to put meters everywhere, I had access to a window where the immensity of what was possible appeared again. Not as a commercial promise, but as a practitioner's sensation: I could finally try to do things the way I often thought they should have been done.

The return of collective reality

I wanted to carry that personal window into work.

In the fall, a greenfield project appeared. It was described as AI-first. I was ready. Or at least I thought I was.

I had recent, intense, concrete experience. I had seen what happens when vision documents, PRDs, user stories, preliminary analyses, and technical decisions live at the heart of the repository. I had seen how a living documentary corpus could become a working partner for AI.

So I tried to do the same thing. Extract what existed from Jira, Confluence, and elsewhere. Transform fragments into product vision, structured documents, early user stories, and analysis usable by a team and by agents. In my mind, this was not documentation for documentation's sake. It was about creating the conditions for real AI-first work to begin.

And then reality hit me.

Not everyone was in the same place. Many people were still at the level of occasional use: a prompt here, a bit of help there, a small local gain. That is already something, and I do not want to look down on it. But it was not the same thing as a project approach built around a living documentary corpus, an explicit method, and structured collaboration with agents.

The project quickly returned to a more conventional dynamic. Ideas, fragments, grocery lists, desires to connect tools, discussions about MCPs, integrations, possible shortcuts. But little truly stabilized material. Little formalized analysis. Little sustained design. Little product vision written in a way that could really guide the work.

I say this carefully, because I know I also made mistakes. I made choices that were not good. For example, I pushed a frontend stack direction that did not turn out to be appropriate. I lost credibility on that, and I have to own it.

But on the methodological substance, I knew something important was at stake. I could see the distance between what I had lived in Ezkey and what I was able to make live in a team context. That distance destabilized me deeply and triggered a profound reassessment.

The moment I no longer wanted to start again

There is an inner scene that stayed with me.

In Ezkey, I had just finished a demanding body of work around cryptography, key rotation, re-encryption batches, visual representation, tests, and design choices. It had required a lot of attention, but it had also given me great satisfaction. I felt I had done something elegant, coherent, and clean.

Then, at work, a conceptually similar piece of work appeared. Same family of problems. Same need for rigor. Same kind of mountain to climb.

And instead of feeling momentum, I felt weight.

I caught myself thinking: no. I have just walked that path. I have just lived that intensity. I do not want to restart immediately in a context where I do not have the same control, the same collective engagement, the same freedom, or the same joy.

It was not laziness. It was not only fatigue. It was more the very clear feeling that I had gone around the square. I had seen the path. I knew it was interesting. I also knew it would be long, demanding, conflictual, sometimes thankless. And I no longer wanted to redo it under the usual conditions of the corporate world.

Frustration became anger. Real anger. Not productive anger. Anger that gnaws, makes you less lucid, less available. It followed me for a long time. It forced me to look at something I might have preferred to avoid: this was no longer only a disagreement about method. It was a disengagement.

I had announced my retirement in April. I will leave at the end of August 2026. Between the two, I live in a strange period of duality. I am still here, but already elsewhere. I still understand the issues, sometimes very well. But they are no longer going to be the center of my life.

The background still holds

This is where I return to the article's original subject.

I still believe we are entering a period where AI will strongly segment companies. Some organizations will adopt it ambitiously, methodically, and deeply. Others will use it cautiously, in a compromise between real gains and organizational inertia. Others will remain limited by their estate, culture, security, compliance, or constraints of their own.

I also believe the budget question is arriving quickly. GitHub Copilot's move toward AI credits and usage-based billing in early June 2026 is only one signal among others, but it shows something: the period when AI felt like an almost natural abundance is giving way to a more accounting-driven reality.

A few days later, another signal appeared: Fable 5 arrived, and access to the model was suspended almost immediately following a US government directive. I do not want to build an entire thesis on an event that is still fresh, but the symbol is strong. A capability can disappear not only for reasons of price, load, or commercial strategy, but also for regulatory, political, or geopolitical reasons.

For a company starting to organize its velocity around one specific frontier model, that is a brutal reminder: the dependency is not only economic. It is also institutional. Over the long run, this will probably add pressure in favor of open models, cheaper models, solutions adapted to more modest hardware, and a diversity of providers capable of balancing the market.

Companies will probably have to learn to measure, arbitrate, and optimize. Which model for which task? Which budget for which result? What share of velocity comes from internal talent, and what share comes from a capability billed by a handful of major providers? How much does a poorly framed loop cost? What is a good specification worth? Where should you pay for a stronger model, and where should you improve the method instead?

All of that is real. All of that matters. All of that will occupy many people.

But I can no longer write as if I were still at the center of that battle.

Context becomes the product

From my campsite, deep in the woods, I also see another vocabulary taking shape. People are talking less only about prompts, and more about context, harnesses, product context. The model still matters, of course. But improvement will not come only from the next model, as if all we were doing was increasing the clock speed of a CPU. It will also come from everything around the model: memory, tools, validations, feedback loops, and the selection of the right context at the right moment.

The hardware analogy speaks to me. The model is a kind of processor. The harness is the rest of the machine: the OS, the motherboard, the buses, the peripherals, the execution rules, the mechanisms that allow the processor to do reliable work instead of spinning in the void. Context engineering is then an essential part of that architecture: deciding what the model should see, what it should forget, what it should retrieve, and what must remain stable.

And one term seems especially revealing to me: product context engineering. In French, I would naturally call it gestion du contexte produit. It is close to what I have been calling intent. Not exactly the same word, not necessarily the same framing, but the same direction: lifting the discourse above the task, above the prompt, even above one-off analysis, in order to give the model a product vision, a compass, values, market constraints, and an understanding of what we are truly trying to build.

That is also why the old role prompt feels less central to me. Saying "you are a React expert" may have helped at one point. But recent models understand the subtleties of free-form text better. They gain more when we take the time to explain in full sentences what we want to accomplish, why it matters, what kind of product we are trying to bring to life, and which values should guide trade-offs. Once again, everything points toward an elevation of the discourse.

Blocks and builders

That elevation does not mean software engineering disappears. On the contrary. There will always be people who build the basic blocks. Like LEGO bricks, those blocks need precise characteristics: resistance, stability, performance, security, compatibility, predictable behavior under certain constraints. Libraries, runtimes, critical systems, and infrastructure layers will continue to require deep engineering, with or without AI.

But a large part of application development will probably move toward another role: the builder. The builder does not merely stack code. The builder chooses the right blocks, understands their properties, formulates the intent, builds the product context, establishes the vision, names the market constraints, and then works with AI to assemble something that solves a real-world problem.

This distinction matters to me because it dissolves a false debate. We do not stop being software engineers. We do not simply become prompt writers. Depending on the context, we become block designers, application builders, or guardians of product context. And it is probably that combination that will redefine part of the profession.

Code as an intermediate artifact

There is another, quieter shift that seems just as important to me: our relationship to generated code itself.

An analogy often comes back to me. When compilers generate assembly code, it is always possible to inspect what was produced. For a while, some people did. Then, in most cases, they stopped doing it systematically. Not because assembly no longer mattered, but because trust moved elsewhere. What matters is that the program exhibits the right behavior, respects the expected constraints, produces measurable results, and that the compiler is reliable enough that we do not need to inspect every instruction.

I do not want to push the analogy too far. AI-generated code remains source code, and therefore an artifact humans can maintain, review, and remain responsible for. But the pace changes the problem. If code is produced not over days, but in minutes or seconds, we cannot reasonably imagine humans reading every line systematically with the same level of attention as before. Code review does not disappear, but it has to change in nature.

The game therefore rises at both ends. Upstream, we have to formulate intent, product context, constraints, values, and invariants better. Downstream, we have to validate behavior better. Tests are no longer only a good quality practice. They become the trust interface between human intent and AI-accelerated production.

This is where behavior-driven development, in one form or another, regains a lot of value. Describe expected behaviors, scenarios, boundaries, contracts, observable effects. Around that, keep test-driven discipline when it helps: unit tests, integration tests, regression tests, automated validations, deterministic guardrails. We will not always reread all the code the way we would reread every assembly instruction. We will have to prove that the system does what it should do, under the conditions that matter.

The builder will therefore not only be the person who expresses a product vision. The builder will also be the person who knows how to transform that vision into validation criteria. Perhaps that is where part of the new maturity will emerge: less staring at every line as if it had been written by hand, and more building the conditions that make code production reliable, measurable, and correctable.

The x10 mirage

This idea connects to another caution I want to keep. We often hear that AI will let a developer produce five times, ten times, twenty times more. Maybe, in some contexts, on certain types of tasks. But I do not believe that multiplier will simply translate into a profession suddenly ten times more available for quality, internal tools, observability, documentation, and perfect hygiene.

Part of that excess capacity could go toward long-postponed things: better internal tools, cleaner workflows, reduced debt, better-managed dependencies, dead code removed, stronger tests. That would be desirable. But believing that the whole industry will sustainably operate in maximum-quality, maximum-critical-thinking, maximum-production, maximum-rigor mode seems as naive to me as older promises of a leisure society.

We have already been told that productivity gains would free time for knowledge, culture, thought, and a richer life. In practice, humans and markets adapt. Needs rise. Expectations rise. What used to be a luxury becomes a commodity, then a necessity. We work differently, but we do not necessarily feel freer.

I suspect something similar will happen with AI. Teams will find a new equilibrium. Developers will learn to dose formality, analysis, critical thinking, the number of agents, the level of validation, and the acceptable cost. Then they will feel overwhelmed again, simply at another level of abstraction.

That new level is real, and it is demanding. Steering agents, maintaining intent, comparing analyses, arbitrating between several proposals, preserving the conceptual integrity of a product: this is not light work. It is not only writing code faster. It is holding a higher, more abstract, more intentional space in your head. For me, that cognitive effort was more intense than I expected.

Of course there will be lighter tasks, as there always have been: code hygiene, updates, small validations, cleanup, surface review. But the heart of AI-first work demands a quality of attention that will not be available to everyone all the time. Humans will adapt, yes. They will also seek to reduce effort, automate, delegate, and recover breathing room.

Even team size will probably be affected by this dynamic. The more reasoning is carried by a living documentary corpus and by agents capable of cross-checking, the less obvious it is that a large number of misaligned people produces a better result. Some teams will likely become smaller, more concentrated, more aligned around a shared vision with AI. That will be a strength if the alignment is real. It will be a risk if AI only amplifies an echo chamber.

These are fascinating issues. I see them. I find them important. But I no longer want to live them as a daily professional obligation.

I choose the slow path

I will keep developing. But it will no longer be the same thing.

Development will no longer be my central identity, nor the measure of my value, nor the main engine of my days. It will be one aspiration among others. I will garden. Ride my bike. Walk. Cook. Travel maybe, sometimes far, maybe mostly nearby. Enjoy a good meal, a microbrewery, a slow day, a project that advances because it pleases me and not because it must be delivered.

I still want to learn. I still want to understand what is happening with AI. I still want to explore models, agents, methods, architectures, and tools. But at my pace, on my terms, in a relationship no longer governed by performance or by a team frame I have to follow.

A phrase comes to me: slow AI. Slow, but attentive. Run less, look better. Produce less, understand more deeply. Try less to convince, and leave honest traces of what I saw, what I tried, what amazed me, and what wore me down.

Maybe that is the real turn of this article. I can see the budget era of software AI coming. I can see companies entering a period of methodological catch-up, vendor dependency, credit optimization, metrics, governance, and difficult choices.

And at the same time, I am leaving the race.

Partly out of rejection. Partly out of bitterness, even if no one forced me there. Mostly because I have had my share. I lived, at the end of my career, an extraordinary acceleration. I saw what AI can do for a developer willing to question himself. I saw my own gaps become less heavy thanks to a working partner that helped me compensate for them. I also saw the limits of that energy when it has to enter an organization that is not ready at the same moment.

The simple act of writing these lines turns this experience report into a sermon, but it is also an engaging and liberating therapy.

This whole adventure, this waltz with AI, I would rather recognize it for what it is: a passage. A personal turning point in the middle of an industrial turning point.

Conclusion

Français : Version française de cet article

See also: Back to foundations — the developer in the AI era

See also: Giving AI back its wings