I'm not writing this as a developer currently at the keyboard.

I spent years working in code, then moved to the other side of the fence, into Product Management. I still work with developers every day — I see their constraints, their tools, their trade-offs, and their fatigue too. And even though development is no longer my main craft, I can't help wondering how software jobs are going to change with AI.

So this isn't meant as a final truth. It's the view of a curious, slightly worried observer, someone who knew code well enough to still notice faint signals, and who now watches software production from the product side. After all, a Product Manager who stops being curious about how products get built has probably stopped doing their job properly.

For a while now I've been experimenting with coding assistants. I've generated scripts, pushed small projects forward, then worked more seriously on a real application. And the finding is both impressive and unsettling: AI can produce enormously, very fast. In a matter of days, you can end up with something that looks like a real application.

But through all of it, I also spent a considerable amount of energy fixing it.

Not just details. Fundamentals. Files that grow too large. Missing tests. Business logic sitting in the API layer. Architectural choices too complicated for the actual need. Solutions that work today but could turn fragile tomorrow. The strangest part is that when I explicitly ask it to do otherwise, it knows how. It knows how to write tests. It knows how to separate the domain from the plumbing. It knows how to propose something simpler. It knows how to recognize that a better option exists.

It knows. But it doesn't do it on its own.

And that's where things get 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, poorly scoped products, or rewrites pushed off for too long.

All of that already existed.

Some developers already knew how to build a cathedral to hold up a shelf. Some teams were already walking slowly into a wall. Some companies already confused delivery speed with actual value. Software's problem was never just about writing code. It was always about producing something that holds together, that can be understood, maintained, evolved, and that serves a real use.

AI doesn't create an entirely new problem. It changes the scale of the old one.

It accelerates what was already going too fast. It makes what was already poorly understood even less visible. It lets people stack decisions faster than anyone actually made them. It gives a false sense of maturity to systems that haven't gone 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, built by people who haven't yet gained the experience to know where those systems will break.

The illusion of maturity

Vibe coding gives you an intoxicating feeling: you ask, code appears, the app moves forward. What used to take days, sometimes weeks, now takes a few hours. The psychological effect is powerful. You see screens. You click. It responds. A database exists. An API runs. Features show up.

The product seems to be maturing.

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

An application can work without being truly understood. It can pass a few happy-path scenarios 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 this fragility already existed. But it 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 further.

With AI, that limit disappears.

You can go much faster than your own understanding. That's useful for exploring. It's dangerous the moment you start confusing exploration with production.

When the error arrives too late, it stops teaching

A large part of technical experience is built through error.

Not just any error, of course. You can suffer for a long time without learning anything. Pain alone doesn't teach. But in development, deep learning often comes from a very concrete loop: you try, you fail, you search, you understand, you fix, and you keep something from that fix.

Sometimes you're stuck for half an hour. Sometimes a whole day. Sometimes you don't find the answer that same day, you come back to it tomorrow, and it's precisely that detour that builds experience. You learn to recognize faint signals in the code. You learn that an overly easy solution often hides a cost. You learn that a bug isn't just an obstacle, but a piece of the system pushing back, asking to be understood.

AI can break that loop.

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

The risk isn't just that the error gets delayed. It's that it arrives at a scale where it's no longer analyzable. The system has grown. Layers have piled up. Decisions are implicit. The tests, when they exist, may validate a flawed understanding of the need. And when everything collapses, nobody really knows why anymore.

So you patch it.

You don't understand it any better. You just slap one more patch onto an architecture you never really inhabited.

The core of the problem: the disappearing first rung

This is probably what worries me most.

The question isn't just whether AI will replace junior developers. That question matters, but it hides a deeper one: what happens if AI replaces the tasks that used to train juniors in the first place?

In many teams, learning happened by gradation. There was a lead, experienced developers, mid-level profiles, then juniors. You didn't hand a junior the full architecture of a critical product right away. You gave them small tasks. A limited 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 people fail without putting the whole system at risk. They let people learn to read existing code, understand a ticket, ask for help, receive a review, discover that a local change can have effects elsewhere. They let people enter the craft gradually.

And these are exactly the tasks AI automates best.

Boilerplate, small scripts, simple fixes, standard tests, obvious integrations: all of that can be generated very quickly. From an immediate productivity standpoint, that's excellent news. From a training standpoint, it's a lot more ambiguous.

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

One answer is that juniors will learn differently, with AI as a Socratic tutor. That's possible. Used well, AI can help explain, compare, prompt people to verbalize their reasoning, generate exercises, simulate a code review. But that possibility requires discipline, curiosity, and a framework. It also requires companies to accept paying for learning time.

And that's where the economic question turns brutal.

If a senior augmented by AI produces ten times more, how many companies will still accept a junior going ten times slower because they're learning? How many will accept someone spending a whole day on a problem AI could bypass in a few minutes? How many will preserve the slowness that training requires, when the market keeps pushing for faster delivery?

The risk is breaking the cycle that reproduces the profession.

Software companies don't just need code. They need people capable of diagnosing, simplifying, maintaining, securing, arbitrating, and inventing. Those people aren't born from simply steering an assistant. They're built over years of practice, mistakes, reviews, hard decisions, and feedback from reality.

If AI boosts existing seniors while weakening junior training, it doesn't just threaten a few entry-level jobs. It threatens software companies' future ability to produce quality software.

Who will invent the next best practices?

We often talk about best practices as if they were a stable stock. As if it were enough to document them, put them in guideline files for AI, and then ask assistants to apply them.

But best practices aren't fixed.

They emerge when the ground shifts. Classic design patterns answered a certain kind of software world. Then the cloud, distributed systems, async, microservices, event-driven architectures brought new problems to the surface. New ways of thinking had to be invented: idempotence, retries, circuit breakers, sagas, observability, distributed resilience.

Those practices didn't appear because someone simply asked a tool for them. They were born from real systems, outages, incidents, painful migrations, operational constraints, difficult trade-offs.

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

I'm not sure.

Inventing a good practice takes more than knowing the old ones. You have to sense why they're no longer enough. 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 unnecessary complexity.

Simplicity itself is a senior skill.

An AI can propose an overly complex solution, then immediately recognize that a simpler one is better if you point it out. But someone still has to see it. Someone still has to say: this problem doesn't deserve this architecture. Someone still has to prefer a less brilliant but more fitting solution.

Producing more, for what?

Generation speed isn't delivery speed.

A team can end up with dozens of pull requests created overnight by AI. But who reviews them? Who checks the impact? Who understands the choices? Who tests the twisted edge cases? Who decides what actually deserves to ship? Who makes sure users can absorb that much complexity?

Producing more code isn't necessarily producing more value.

There's an obvious competitive pull. 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's going to have the nerve to say: let's stop, this isn't clean enough yet?

But software isn't only a race for quantity. A product quickly becomes unreadable, both for its users and its teams, if features get added faster than their usage is understood. Complexity isn't only measured in code. It's also measured in adoption, support, documentation, the coherence of the experience, and an organization's ability to explain what it's building.

AI shifts the bottlenecks.

Code gets faster. But review, security, functional scoping, integration, understanding, and human absorption stay limited. Maybe they even become more critical.

Rebuildability as a quality criterion

In my own recent use of these tools, what reassured me wasn't just having produced an application. It was having imposed anchor points.

I insisted on clear contracts between APIs. I pushed the AI to produce test suites, then the test pyramid, before writing the actual code. I tried to keep a clear separation between business logic and technical plumbing. I didn't go all the way to a full DDD approach, because the project didn't warrant it, but I refused to let business logic scatter across the endpoints.

Why?

Because a system that's truly understood is a system you'd know how to rebuild.

If tomorrow I have to move this application to another technology, I know where the contracts are, where the business rules are, where the tests describing expected behavior are. Nothing is perfect, but the system isn't just a pile of generated code. It has handholds. Reference points. Lines of separation.

That might be a central criterion for AI-assisted development: not just asking "does it work?" but "would I know how to rebuild it?"

If the answer is no, then something is missing.

Deliberately reintroducing difficulty

It's not enough to learn how to develop with AI. Sometimes you also need to learn without it.

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

We accept this idea readily elsewhere. In math, a calculator is useful, but learning without ever doing an operation yourself creates dependence. In sports, you deliberately add constraints, weight, resistance, because that resistance is what builds muscle.

Development will need the same logic.

AI-free dojos. Exercises with a deliberately limited AI. Reviews where you have to explain the code yourself instead of 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 everything down. The goal is to slow down in the right place.

Maybe tomorrow's teams will have to accept a hybrid pace: producing very fast part of the time, but protecting long stretches of time to understand what was produced. A day for continuous improvement. Moments alone with the code. Architecture reviews. ADRs. Slow refactors. Post-mortems on botched generations.

Before AI, this kind of long time was already too often missing. Many developers stayed heads-down, producing without taking enough of a step back to grow their skills. AI can make this worse if it's only used to fill every bit of space freed up with even more production. But it can also become an opportunity if it forces us to better 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 likely need to invent an explicit discipline. Not bureaucracy. A hygiene of understanding.

A few rules already seem useful.

First, never merge code nobody can explain. It's simple, almost blunt, but essential. If a team accepts code it doesn't understand, it accepts a debt of understanding.

Then, plan a small understanding budget per feature: the contract, the tests, the architectural decision, the known limits. Not endless documentation. Just enough for the reasoning to stay humanly transmissible.

Tests also need to stay tied to actual behavior. A generated test can be very clean and still validate a flawed understanding of the need. The loop should be: behavior, tests, code, back to behavior. The more tests genuinely express expected usage, the more the code stays close to actual value.

Teams need to maintain a map of the patterns they've sanctioned. How do we build an API? How do we handle errors? How do we write an async 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, AI's failures need to be analyzed. When it produces an overly complex solution, when it skips tests, when it puts business logic in the wrong place, the fix shouldn't be the only response. The missed signal should be understood, guidelines adjusted, practices enriched.

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

Understanding ten times better

I don't think software development is going to collapse because of AI.

I do think, however, that 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 have even impressed their market for a while. Then they'll discover that speed doesn't replace architecture, that tests are only worth as much as the need they express, that security lives in the twisted edge cases, that legacy systems demand historical understanding, and that seniors aren't made by removing the tasks that used to train juniors.

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

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

If AI lets us produce ten times faster, 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 it takes to build software well.

To go further

Code Centric Quality belongs to those who ship Zero bug: let's stop managing stockpiles of defects