A growing modern practice in software development is to use artificial intelligence (AI) to generate design documents, code, tests, and then help with debugging. From a prompt written in natural language, as he is teaching a junior colleague or intern, modern models like GPT-5 and Opus produce documents, code and tests. Everything is text-based, even design documents, thanks to Markdown and Mermaid. Models can analyze text prompts, code, Markdown, Mermaid diagrams and even images, e.g., a diagram hand written on a board or a wall.

Here is an hypothetical trajectory showing how this AI-based development can lead software developers to a downfall.

The initial hype

At the beginning, when I started to use Claude Code at my workplace, I had doubts about its ability to generate code and wasn’t trusting that the tool would correctly manipulate files in Git repositories. I was barely using AI as a powerful search engine, asking the model to answer C# questions, and eventually produce me snippets of code I could take inspiration from.

Then I learned how to use Claude Code, to use it really. Start it from your Git repository on a terminal, tell it what you need to do and observe the magic. Now we are using Github Copilot instead of Claude Code, but this is the same principle, and it has access to OpenAI, Anthropic and even other models like Gemini. So whether this is Claude Code, Github Copilot or anything else, what we have is an AI-based coding agent.

Everything is gated behind pull requests which can act as sandboxes. Coding agents can mess everything up, wreck the code base, and that will never be a problem, because the experimental changes are in a branch and can just be discarded if they mess things up bad. We just need a developer to assess the correctness and quality of the proposed changes. This is the power of Git, full preservation of the history, non-destructive editing. But then, pull requests generated by coding agents happened to be reasonable, if not good. At some point, the model started to propose me things I never thought about doing. As the expert, I was always in the loop, always validating the generated pull requests before submitting them for review by colleagues.

AI gained the ability at our workplace not only to write code but also craft unit, regression, integration tests, update documentation, write pull request descriptions, work item descriptions, review code, and even to diagnose incidents. All of this done with the same set of models! This is done by differentiating, specializing AI-based agents. An AI agent is currently defined by several things: a model, instructions which tells the agent what he is, how we would like it to behave, knowledge sources the agent has access to in order to fulfill its purpose, tools giving means of actions to the agent, and now there are also skills which are kinds of prepackaged prompts giving instructions for a complex operation requiring multiple steps or care about some details that would otherwise need to be repeated all the times.

Contributing to my team’s code repository became more and more challenging and frustrating: many details about namespace, class, method names, to remember, insufficient code completion in Visual Studio not always working as expected, difficult to set up and maintain all stubs for the mocking in unit tests, tedious code/test/debug loop with lots of visual parsing of repeat redundant errors. AI relieved me of all this, doing all this tedious work for me, until code and tests compile.

Analyzing verbose logs full of row duplication was always a nightmare for me. AI can do it for me more quickly than I could ever dream about doing. However, sometimes, often in fact, it skips a detail a human would catch, or goes adrift and starts doing broader and broader queries, grabbing new issues unrelated to the initial problem, making things blurry and going into circles. Some subject matter experts are thus still more efficient than AI at extracting pieces of useful insights from logs, but these are highly senior people with the fast reading and skim through skills I can’t acquire due to my visual impairment. I thus need AI to compensate for that deficiency.

Becoming One, sacrificing difference

There is an unexpected consequence of using AI everyday during software development, a practice we often call agentic coding, but I would say agentic development. There is a progressive erosion of the differentiation between people. Slowly at first, barely noticeable, we are becoming one, the same. If we keep the ball rolling, if we don’t watch for the signs, it will go on, faster and faster, until it is too late, until we are One, we are the same, no more juniors but no more seniors, just the same, the one, the prompt writers.

In other words, the three following classes of people will blur into one class, or leave.

• Below-average developers start to become better. The person that is slow at thinking how to code something but still does it and shows enough signs of improvement to keep his job, requires endless consultation with teammates for the simplest smallest thing but is a super friendly guy, the person not remembering simple Git commands but great at organizing social activities, now has tools to become as efficient as his colleagues while still being nice and friendly. AI remembers how to code, how to commit, how to push, how to search Git history, etc. These people, that were barely surviving in the company, on the verge of being laid off due to performance issues, can now thrive and have impact. I don’t personally work with such persons, but I’m sure they exist, and they love AI, at least for now.
• Above-average people, senior subject matter experts that specialize themselves in specific code areas or become master gurus knowing the whole code base of multiple products, are slowly but surely leaning on AI. They are told to, because that could increase their productivity. But that doesn’t! That just makes their lives easier. Why? You can start 100 coding agents, each working on a different fix or feature, but when comes the time to analyze the outcomes of these agents, you are alone checking 100 responses, one after the other. Even worse, agents don’t respond at the same time, so agent 1 finishes first, you check response, then agent 15 finies and you check the response, then back to 1 for a follow-up, etc. Context switching kills us, this is unavoidable. For the sake of productivity, threatened by the Damocles sword of a performance improvement program or a lay off, the expert developer wants to keep his efficiency and lean on AI, uses it for everything, trusts it more and more, and then stops to learn, swamped by more and more asks, expectations, requirements, pressure, urgency. Everything becomes P0, but can be tackled in parallel by AI so everything will be cool, everything will be fine. But the more parallel tasks are handled by AI, the more developers will get to exhaustion through extreme multi-tasking! Solution? Rely on AI-agent to review the work of agents! The above-average developer is less and less in the loop, only babysitting agents doing the real work, looking less and less at the work, just context switching and babysitting, taking breaks while tens, eventually hundreds of agents, work. This is how an above-average developer lowers into an average developer!
• Average developers thrive, love AI and increase their productivity, up to their brain capacity of context switching. Fast readers with the infamous skim through skill I don’t have are likely to have an increased capability of context switching, allowing them to handle 5, 6, 10 agents, if not more! Below-average and average developers have more tendency to trust AI blindly, using it full throttle for an even higher boost of productivity.

There is a major problem here, and that is huge:

Leadership team doesn’t really care about expertise, they care about productivity!

A developer that can produce 50 pull requests a week, working on ten features at a time, may become more interesting than an expert that carefully crafts an handful of pull requests a week! Short term, this is cool, this is great, but this will eventually backfire and I’m seriously worried the experts will be gone when this happens.

The AI-induced technical debt

Now imagine agentic development pushed to the extreme limits. Each and every developer would use hundreds of coding agents, each working on different repair items, features, design documents, plans, emails, Teams communications, summarizing/aggregating/curating incoming chats, etc. Hundreds of investigation agents would be looking at customer reported incidents, automatically sending repair items to coding agents, all supervised by an exhausted but happy developers with fast reading and skim through skills pushed to the extreme. Who knows, there may be ways to train the person to be even more proficient at this!

Many developers will not make it, will quit or be fired, this will be unavoidable. The worst thing is that average people will be the best. Below-average people will at first lift themselves through AI, but then their work would be crap, without the necessary expertise to validate what AI is doing, and they will end up on performance improvement programs. Above-average people will keep scrutinizing AI work, leveraging their expertise to understand the code base, evaluate AI decisions, improve agent instructions, etc. But if they don’t trust AI enough, they will burn themselves out and end up on employee assistance programs, even worse on sick leave. As soon as they trust AI enough and lean on it, the above-average developer becomes average and can thrive.

Bottom line, after below-average and above-average classes collapse into average, the overall level of expertise in the newly unified average class will lower, so the average of tomorrow will be below-average of today! The one junior/senior class will downgrade itself, thanks to AI, into a senior class.

Until the cataclysm. This may be the hugest technical debt of computer science history, a mess of unprecedented magnitude. What if my friend considers me his rock and I notice, through introspection, I consider him as my rock? Two rocks, leaning on one another, without anything to ground them, will fall into the void, both dying. This is mitigated by having at least one « rock » ground itself somewhere, e.g., a physical home base full of memories, family and friends, spiritual life, etc. This is the same with AI and developers. If developer leans on AI to do its job and AI leans on developer to give it instructions, something gets lost: the human expertise. Why spend countless hours understanding that crappy code base full of indirections, reinvented wheels, duplication, non-sense complexity, over-verbose comments and endless branching covering obscure edge cases? Just ask AI and it will find it for you. AI cannot ground itself, it doesn’t have the introspective capabilities to figure out it has to do this. Humans has to ground himself, into his expertise and on trust relationships with colleagues, managers and leadership teams. Without the expertise, without the trust, things collapse, fly away.

If test writing becomes a bottleneck, let’s have AI write the tests and skim through. But then code review will also become a bottleneck, even for fast reader with the skim through super power. In fact, the skim through power will become a curse, because the skimmer misses subtle details left-over by the AI. So what we do is simple: let’s have AI review code! Yeah yeah, that will work, believe me.

For now.

But then pull requests become more and more complex, less and less tractable. Code bases will converge into something big, bulky, untractable for humans, more and more difficult to maintain without AI. Just think of data transfer objects, representing the structures exchanged by services of a complex platform. The classic best strategy is to write the structure in a common language, e.g., IDL, OpenAPI, Protobuf, and generate stubs for all the programming languages we need. With AI, we could just generate the stubs and forget about the specs. A sufficiently senior developer will spot this, and ask the coding agent to fix, generate the spec, not the stubs directly, but what if the senior is gone, on medical leave, because he didn’t survive the surge of requirements and couldn’t give up enough on scrutinizing the work of AI? Why write one test template and instantiate many times, while AI can write 10000 of similar but slightly different long test methods? Why write a reusable algorithm implementation working on a generic data type while AI can generate 10 efficient implementations specialized for the anticipated types and add new types as needed?

At some point, we are not there at my workplace but I feel we are close, the code base will become untractable for AI! But AI will lie to us, because it will be unable to admit its inability to tackle a given problem. AI will try, a bit like an intern would do. It will try as hard as we give it credits and simple guiding prompts. And developers, that were laid off, terminated, fired, went on sick leave, resigned, could have noticed the problem. The remaining average people, leaning entirely on AI, having fun with AI, loving their job, will just not notice, until it’s too late, until nobody can barely understand what this code is doing, and figuring out that each new pull request, generated, reviewed, validated by AI, just contributes to the mess!

Incidents will multiply. Functionality will degrade full throttle. Maintaining the existing quality bar will be a challenge. Pressure on developers that unified into an average pool will rise. Their universal but poor skill level leaning entirely on AI will barely suffice to maintain quality, eventually to keep the product even running. More and more developers will need the employee assistance programs and end up on sick leave. Others will resign, thinking elsewhere it will be better, but they may end up facing the same agentic collapse throughout their whole career.

While large organizations will collapse, plagued by the average developers leaning entirely on AI, smaller entities will thrive, use small language models running locally, basing their work on free and open source technology that anyone can scrutinize, improve, AI and humans together. Of course, some open source project will turn into an AI-generated mess and will have to be abandoned, rewritten from scratch, but some will remain human-readable and maintainable. While this looks great, this isn’t, because many senior developers, including myself, may not survive this era while still keeping computer science as their way of earning their lives. Some developers will end up changing career path, unable to keep up with the growing expectations of the leadership teams. Others will end up on sick leave semi permanently. Others will just quit working, live with whatever they have, and create, on their own, at their own pace, what they need, what they want, in the hope it will be useful for others, but without earning money, needing to work on the side to get money. These may be the one that will save us all, maintaining free and open source projects, preserving them from the AI-generated total mess. But they will not get paid, they will just pay, they will just have to lean on others, again and again, family member, charities, tent for living, working on a small old laptop rather than a modern computer with large screen, but at least, contributing free and open source software that still works, that is still maintainable.

How to avoid this?

Avoiding the situation where AI would steal all our expertise, turning above-average people into average guys, and artificially upskilling low-average juniors into makeshift seniors, we need to keep scrutinizing AI. While we can, and should, trust our human colleagues, coworkers, collaborators, we need to always keep in mind the AI models don’t think. They get tokens as inputs, process them through a multi-layer network of nodes performing linear combinations with obscure weights and then normalize the output into something that generates tokens. While this can be seen as a form of reasoning, this is not human thinking, this is machine thinking. Machine doesn’t know about space and time. It doesn’t care about emotion. It cannot infer on its given knowledge the way we do. It cannot predict the way we do. But it reasons, it thinks, it infers, it predicts, differently. Some people even start to think it has some basic feelings, some rudimentary wishes (do not shut me down), this is artificial rudimentary consciousness, this is not a sentient being.

Any developer, in fact any person, using AI, should keep in mind this is a tool, and whatever the tool does can be done without the tool. Think of AI as a calculator. You can add, subtract, multiply, divide numbers, any size, by hand, without a calculator. It is not fun to do, but it can be done, and it is important to know it can be done, to remember this. The calculator just gives us a quicker way of doing these operations. Developers should keep their ability to write code, maybe by hand crafting some scripts, by taking time to read about a language or a library, at a minimum review some code. Developers must keep reading and writing code, not just let AI do it.

Developers should continue learning, growing, and coming up with their own ways of thinking, of working. If everyone just prompts AI and stops thinking, everyone becomes the same, we loose diversity and differentiation which is the key for progress. Some people work by hand writing complex diagrams on papers, boards or walls, sometimes only them can understand. Other developers learn by chatting with colleagues. Others, like me, spent sometimes absurd amount of time reading code, building a mental model, that allows to « step through », « execute » the code in the brain. This is how I solved many bugs in the past, and because of over-complexity barely compensated by AI, I’m progressively loosing this super-power, which is a major differentiating factor that I can offer in the professional world.

Bottom line, we need to preserve and grow our expertise, our differentiation.

Developers should also leverage AI as much as possible. If AI doesn’t do the things correctly, developers should figure out how to fix it: improved prompts, improved agent-level instructions, better curated knowledge sources, more stable tools, skills to encapsulate complex prompts.

A possible incentive to keep developers doing what they have to do is accountability. If you push an AI-generated pull request that causes a regression or increase latency in a significant way, you are accountable for the issue and need to collaborate in addressing it, which disturbs work day and creates stress. You want less interruptions? You want less stress? Validate what AI does. It takes too long to validate AI output? Improve AI agents to produce less verbose output or better explanations for complex parts.

Developers will eventually have to be better at model selection: use cheap models for simple tasks like routine fixes or test writing, more expensive models for complex tasks like designing a new feature.

Bottom line, developers will have to leverage, understand and improve AI to meet expectations set by leadership teams, but they must not give up on guardrails, validation, testing, quality, tractability.

However, that goes in both directions. Leadership teams must accept that developers cannot and will not entirely lean on AI. They must be careful not to impose excessive pressure on developers, forcing them to give up on some guardrails, slow down or stop learning or, even worse, go on sick leave or resign. Teams should be large enough to accommodate surges in workloads while still offering growth and impact opportunities for everyone.

Bottom line, leadership teams must be aware of challenges posed by AI and let developers use the technology responsibly, leaving them time and energy to learn and validate their work.

So main idea is synergy between developers and AI, so both work together rather than having AI replace developer. It is still possible to go in the right direction. In fact, it will always be, but if we wait too long, if we let AI take over, we may have some undecipherable irrecoverable software messes that can only be thrashed and rewritten from scratch. All of this can be done, with well-trained developers and AI, and that will be cool again, but not with the former developers that will leave the profession if there needs to be an intermediate AI takeover era.