I'm not writing this as a working developer.

I spent a long time in the world of code, then crossed to the other side of the fence, into Product Management. I still work with developers, I see their constraints, their tools, the calls they have to make, their tiredness too. And even though development is no longer my main job, I can't stop wondering how software work is going to change with AI.

So this isn't a settled truth. It's the view of a curious observer, slightly worried, who knew code well enough to pick up certain weak signals, and who now watches software being produced from the product side. After all, a Product Manager who stops being curious about how products get built has probably stopped doing the job properly.

For a while now I've been playing with development assistants. I've generated scripts, moved small projects forward, then worked more seriously on an application. What I've seen is both impressive and unsettling: AI can produce an enormous amount, very fast. In a few days you can get something that looks like a real application.

But over that same stretch, I also spent a considerable amount of energy correcting it.

Not just on details. On fundamentals. Files that grow too big. Missing tests. Business logic sitting in the APIs. Architecture choices far too heavy for what was actually needed. Solutions that work now but could become fragile later. The strangest part is that when I explicitly ask for something different, it knows how to do it. It knows how to write tests. It knows how to separate the domain from the plumbing. It knows how to offer a simpler solution. It knows how to recognise that a better option exists.

It knows. It just doesn't always do it on its own.

And that's where this gets interesting.

AI didn't invent software's bad habits

Let's be fair from the start: AI didn't invent technical debt. It didn't invent over-engineering. It didn't invent contradictory architectures, forgotten tests, implicit decisions, badly framed products or the rewrite everyone keeps postponing.

All of that was already there.

Some developers already knew how to build a cathedral to hang a shelf. Some teams already knew how to drive slowly into a wall. Some companies were already perfectly capable of confusing delivery speed with real value. Software's problem was never only about writing code. It has always been about producing something that holds together, that can be understood, maintained, extended, and that serves a real use.

So AI isn't creating an entirely new problem. It's changing its scale.

It speeds up what was already going too fast. It makes what was already poorly understood less visible. It lets you stack up, far quicker, decisions nobody really made. It gives a kind of surface maturity to systems that haven't yet been through the normal stages of maturing.

The danger isn't that AI writes code. The danger is that it lets people produce systems maintained like prototypes, by people who haven't always built up the experience to know where those systems will break.

The illusion of maturity

Vibe coding gives you a heady feeling: you ask, the code appears, the application moves forward. What used to take days, sometimes weeks, now takes a few hours. The psychological effect is very strong. You see screens. You click. It responds. There's a database. An API is running. Features show up.

The product looks like it's maturing.

But what's really maturing, sometimes, is mostly the surface.

An application can run without being understood. It can get through a few happy paths without being robust. It can survive a demo without being ready for production. It can hold hundreds of technical choices nobody can explain, because they were generated, accepted, patched, then forgotten.

Before AI, part of that fragility already existed. But it usually had a natural limit: slowness. Producing code cost time. That slowness sometimes forced conversations, trade-offs, reviews, moments where you had to understand what you were doing before going any further.

With AI, that limit disappears.

You can move far faster than your own understanding. That's useful for exploring. It's dangerous the moment you start confusing exploring with producing.

An error that lands too late no longer teaches

A large part of technical experience is built through error.

Not just any error, of course. You can suffer for a long time and learn nothing. Pain on its own teaches nothing. But in development, deep learning often comes from a very concrete loop: you try, you get it wrong, you dig, you understand, you fix, and you keep something from the fix.

Sometimes you're stuck for half an hour. Sometimes a day. Sometimes you don't find it that day, you come back the next morning, and it's exactly that detour that turns into experience. You learn to recognise weak signals in code. You learn that a solution that comes too easily usually hides a cost. You learn that a bug isn't just an obstacle, but a piece of the system pushing back and asking to be understood.

AI can break that loop.

When a problem shows up, you can just say: sort it out, find me a solution. It will find something. Maybe a good solution. Maybe a horrible but working one. Either way, if you don't take the time to understand, you move forward without learning.

The risk isn't only that the error gets delayed. It's that it lands at a scale where it can no longer be analysed. The system has grown. The layers have stacked up. The decisions are implicit. The tests, where they exist, may be validating a wrong reading of the need. And when the whole thing falls over, nobody really knows why.

So you patch.

You don't understand any better. You just add one more plaster to an architecture you never really lived in.

The heart of the problem: the first rung disappears

This is probably what worries me most.

The question isn't only whether AI is going to replace junior developers. That question matters, but it hides a deeper one: what happens if AI replaces the tasks that used to make juniors?

In a lot of teams, learning happened in steps. There was a lead, experienced developers, mid-level profiles, then juniors. Nobody handed a junior the full architecture of a critical product on day one. You gave them small tasks. A contained bug. A simple endpoint. A script. A fix. A test. A modest refactor.

Those tasks weren't just work to get done. They were the first rungs of the ladder.

They let you get it wrong without putting the whole system at risk. They taught you to read existing code, to understand a ticket, to ask for help, to have your work reviewed, to discover that a local change can have effects elsewhere. They let you work your way into the craft gradually.

And those are precisely the tasks AI automates best.

Boilerplate, small scripts, simple fixes, standard tests, obvious integrations: all of it can be generated very fast. From the point of view of immediate productivity, that's excellent news. From the point of view of training people, it's far more ambiguous.

If the first rungs disappear, how does anyone become senior?

You could answer that juniors will learn differently, with AI as a Socratic tutor. That's possible. AI used well can help explain, compare, make you put things into words, generate exercises, simulate a code review. But that possibility takes discipline, curiosity and a frame. It also takes a company willing to pay for learning time.

And that's where the economics turn brutal.

If a senior boosted by AI produces ten times more, how many companies will still accept a junior going ten times slower because they need to learn? How many will accept someone spending a day on a problem AI can route around in minutes? How many will protect the slowness that training requires, while the market pushes for ever faster delivery?

The risk is breaking the cycle that reproduces the craft.

Software companies don't just need code. They need people able to diagnose, simplify, maintain, secure, decide and invent. And those people don't emerge from simply steering an assistant. They're built over years of practice, errors, reviews, hard decisions and feedback from the real world.

If AI boosts existing seniors but weakens how juniors are trained, it doesn't only threaten a few entry-level jobs. It threatens the future ability of software companies to produce good software.

Who will invent the next good practices?

We often talk about good practices as if they were a stable stock. Document them, drop them into directive files for the AI, then ask the assistants to apply them.

But good practices aren't fixed.

They appear when the ground shifts. The classic design patterns answered a certain software world. Then the cloud, distributed systems, asynchronous work, microservices and event-driven architectures brought out other problems. New ways of thinking had to be invented: idempotency, retries, circuit breakers, sagas, observability, distributed resilience.

Those practices didn't appear because someone simply asked a tool for them. They came out of real systems, outages, incidents, painful migrations, operational constraints, uncomfortable compromises.

AI will probably help formulate the next patterns. It can compare solutions, spot recurring shapes, document emerging practices. But can it invent them on its own, before the ground has made them necessary and understandable?

I'm not sure.

To invent a good practice, knowing the old ones isn't enough. You have to feel why they no longer hold. You have to have been exposed to the resistance of the real world. You have to know when a pattern is an elegant answer and when it's just needless complexity.

Simplicity itself is a senior skill.

An AI can offer a solution that's far too complex, then immediately agree that a simpler one is better once you point it out. But someone still has to see it. Someone still has to say: this problem doesn't deserve that architecture. Someone still has to prefer the less brilliant solution that fits better.

Produce more — to what end?

Generation speed isn't delivery speed.

A team can wake up to dozens of pull requests created overnight by AI. But who reads them? Who checks the impact? Who understands the choices? Who tests the awkward edge cases? Who decides what should actually go to production? Who makes sure the user can absorb that much complexity?

Producing more code isn't necessarily producing more value.

The competitive pull is obvious. If a competitor ships a feature in three days, how do you justify a team taking three months? If a generated mockup can quickly turn into production code, who will have the nerve to say: stop, this isn't clean enough yet?

But software isn't only a race for volume. A product quickly becomes impossible to make sense of, for its users as much as for its teams, if you add features quicker than you understand how they're used. Complexity isn't only measured in code. It's also measured in adoption, support, documentation, the coherence of the experience, and the organisation's ability to explain what it's building.

So AI moves the bottlenecks.

Code gets faster. But review, security, functional framing, integration, understanding and human absorption stay limited. They may even become more critical.

Rebuildability as a quality bar

In my own recent use, what reassured me wasn't only having produced an application. It was having imposed a few anchor points.

I insisted on contracts between APIs. I pushed the AI to produce the test sets, then the test pyramid, before building anything. I tried to keep a clear separation between the business domain and the technical plumbing. I didn't go as far as a full DDD approach, because the project didn't call for it, but I refused to let the business logic simply scatter across the endpoints.

Why?

Because a system that's genuinely understood is a system you could rebuild.

If tomorrow I have to move this application onto another technology, I know where the contracts are, where the business rules are, where the tests that describe the expected behaviour are. Not everything is perfect, but the system isn't just a pile of generated code. It has handholds. Landmarks. Dividing lines.

That may be a central criterion for AI-assisted development: not only asking "does it work?", but "could I rebuild it?"

If the answer is no, something is missing.

Deliberately putting the difficulty back

It isn't enough to learn to build with AI. Sometimes you also have to learn without it.

Not out of nostalgia. Not to defend some heroic vision of the developer who has to suffer to earn the job. But because a skill that never meets difficulty becomes fragile.

We accept this readily enough elsewhere. In maths, a calculator is useful, but learning without ever working through a sum yourself creates a dependency. In sport, you deliberately add constraints, weight, resistance, because it's that resistance that builds muscle.

Development will need the same logic.

Dojos without AI. Exercises with AI deliberately limited. Reviews where you have to explain the code without asking the assistant to do it for you. Moments where you deliberately take the time to read, understand, simplify.

The goal isn't to slow down everywhere. The goal is to slow down in the right place.

Maybe tomorrow's teams will have to take on a hybrid rhythm: produce very fast part of the time, but ring-fence long stretches to understand what has been produced. A day of continuous improvement. Time alone with the code. Architecture reviews. ADRs. Slow refactors. Post-mortems on a generation that went wrong.

Before AI, that long time was already missing far too often. Plenty of developers stayed heads-down, producing without enough distance to get better. AI can make that worse, if it only serves to fill the space it frees up with yet more output. But it can also become an opportunity, if it forces us to separate the time for doing from the time for understanding.

A few simple rules for staying in control

If teams want to use AI without losing their depth, they'll probably have to invent an explicit discipline. Not bureaucracy. A hygiene of understanding.

A few rules already look useful to me.

First, don't merge code nobody can explain. It's simple, almost harsh, but essential. A team that accepts code it doesn't understand is taking on an understanding debt.

Next, plan a small understanding budget per feature: the contract, the tests, the architecture decision, the known limits. Not endless documentation. Just enough for the reasoning to stay transmissible between humans.

You also have to tie tests back to the functional need. A generated test can be very clean and still validate a wrong reading of the need. The loop should be: functional need, tests, code, back to the functional need. The more the tests genuinely express the intended use, the better the chance the code stays close to the value.

You have to keep a map of the patterns the team allows. How do we build an API? How do we handle errors? How do we write an asynchronous job? How do we test an external call? Without that, every generated feature risks inventing its own way of doing things, and the team ends up maintaining several architectures for no reason.

Finally, you have to analyse the AI's failures. When it produces a solution that's too complex, when it forgets the tests, when it puts business logic in the wrong place, we shouldn't only fix it. We should understand the signal we missed, adjust the directives, enrich the practices.

AI can write code. But the team has to stay the owner of the reasoning.

Understand ten times better

I don't believe software development is going under because of AI.

I do believe some teams are going to drown in code they don't understand well enough. They'll have produced fast. They'll have shipped visible things. They may even have impressed their market for a while. Then they'll discover that speed doesn't replace architecture, that tests are only worth something if they express the right need, that security lives in the awkward cases, that legacy demands a historical understanding, and that you don't manufacture seniors by removing the tasks that used to train juniors.

So the real issue isn't refusing AI. That would be absurd. It's too useful, too powerful, too present already.

The real issue is not handing over to it the mechanisms that produce competence.

If AI lets us produce ten times faster, then it should also force us to set aside time to understand ten times better what we produce. Otherwise we won't just have accelerated software development. We'll have accelerated the forgetting of what makes it good.