Is AI teaching you to code or just to survive code review?

I remember when I first started to code. Every bug felt like a battle. Every error I managed to fix on Stack Overflow felt like I earned a tiny PhD. But that is an experience fewer and fewer juniors have today, because now, when you get stuck, you don’t spend an hour digging through documentation. You just open an AI chatbot and ask it.

There is one thing seniors on the team can’t fully understand: what it’s like to learn to code with AI whispering answers in your ear from the very beginning. AI came along when they were already well into their careers. They had years of wrestling with documentation, Stack Overflow and colleagues who knew too much but shared too little. By the time Copilot arrived, they had already developed their own instinct. They knew when AI got it wrong. They knew when a solution was elegant and when it was just good enough to pass review.

Learning in a different way

As a junior today, your onboarding looks something like this: you open a ticket, open a chatbot, and start talking to the bot as if it were a senior with infinite patience who is never in a meeting. And there is something genuinely good about that: the barrier to asking questions has almost disappeared, you can iterate faster, and the boilerplate that used to steal an hour of your time now only takes a minute.

A little while ago, I was working on some new features. Copilot generated the boilerplate for parsing Excel files in seconds. The delivery speed was incredible. But when something broke in an edge case, I realised a slightly terrifying truth: I did not fully understand the code I had just “written.” And that is where it gets tricky.

There is a fine line between speeding up learning and skipping learning altogether. As a junior, that line is hard to see until you’ve already crossed it.

The filter we never got to develop

A senior who built their skills before AI entered the picture has a filter. When Copilot generates a solution, they weigh it against their years of experience. They recognise antipatterns. They can sense when something smells like a memory leak. They know which part of the code not to touch because it is that weird microservice from 2018 that nobody understands. As juniors, we don’t have that filter. We only have the output and the trust that the output is good because, well, it works, doesn’t it?

But what happens when it doesn’t? What happens when AI, eager to please, generates code with a memory leak that takes down search on a Sunday evening, when traffic is at its highest? Or when it introduces a subtle security vulnerability into the billing system because it used an outdated library from its training data? That’s where playing with the Tab key ends and real engineering begins. If I don’t understand why the bot chose that particular approach, I’m not a developer solving a problem; I am a potential liability in production.

AI isn’t the problem; context is the problem

Programming knowledge used to be built vertically. You had to understand data structures, memory and network protocols under the hood just to be able to ship a working feature. You knew why your code behaved the way it did.

Today, we are creating a generation with horizontal knowledge. We write prompts, AI generates opaque pieces of code, and we wire them together and test them until the application magically starts working. Knowledge is no longer built from the ground up, it is patched on top. The difference between knowing how something works and knowing how to make something work is, in reality, the difference between a software engineer and an assembly-line operator.

ChatGPT knows syntax. It doesn’t know the history of the repository. It doesn’t know why a particular architectural decision was made, or what happened the last time someone tried to change it. That knowledge lives in the heads of seniors and is passed on through coffee chats, through code review comments, through those “stupid” questions that we have stopped asking because it’s easier to ask the bot. We would rather spend hours ping-ponging with a chatbot than ping a colleague on Teams because we don’t want to look incompetent.

I once spent three hours talking to Claude, trying to understand why one of our endpoints was returning the wrong data under certain conditions. In the end, I asked a senior. He solved it in ten minutes because he knew that we’d already had that edge case the year before, and that the fix was a single line in the configuration. The bot couldn’t have known that. I didn’t even know what to ask.

But it is precisely through such “stupid” questions that juniors absorb domain knowledge, architectural decisions and business logic. When we shut seniors out of that process and leave only the bot in the loop, we lose the most important kind of knowledge transfer: the human one.

A super-developer on the outside, a fraud on the inside

You’re looking at the Merge Request you submitted. Five hundred lines, all clean, approved by the tech lead with: “Great job, shipped fast.” And your stomach tightens because you know how it came together. You didn’t solve the problem. You prompted your way through it.

Being a junior has always meant wrestling with impostor syndrome. But today, that feeling is on steroids. That gap between what your code does and what your brain actually understands slowly erodes engineering curiosity and creates a kind of pressure that is hard to describe. Seniors bridged that gap slowly, fully aware of where the holes were. We are trying to bridge it without that awareness.

And the data back this up. Stack Overflow’s 2025 Developer Survey (https://survey.stackoverflow.co/2025/), based on a sample of more than 49,000 developers, shows that 20% of developers are becoming less confident in their own problem-solving skills, while 16% explicitly say they no longer understand how or why their code works at all. 45% of us lose more time debugging AI output than we would have spent writing the code ourselves from scratch. We are faster than ever at generating lines of code. But we are incredibly slow at understanding what we have just created.

There is no Copilot in the interview room

This is where we get to the most painful part. Tech leads have already figured out “AI-proxy” developers.

There is no Copilot in a technical interview. There is no ChatGPT in the next tab. You get a whiteboard and a task. If you built your GitHub portfolio entirely on prompts, without understanding memory management, the event loop or database structure, you’ll get stuck on the very first question. Patchwork knowledge cracks under pressure. Interviewers are not looking for code that works. They are looking for an engineer who understands the domain, who can think out loud and who knows how to optimise a solution. AI teaches you what to write. It doesn’t teach you why.

What this means for us

There is no going back, and there shouldn’t be. AI isn’t going anywhere, and anyone who doesn’t use it will be left behind. But juniors who are growing up with it need to be aware of one thing: delivery speed is not the same as growth. After a year, you can look like an experienced developer while still missing the fundamentals. For seniors, AI was a tool added on top of a solid foundation. For us, AI arrived as a teacher, and that is a fundamental difference.

Close the chatbot. Write something yourself, even if it’s ugly and slow. Ask the senior that question you think is stupid. Sit with the code that you don’t understand and stay with it until you understand it, not until you force it to work. AI should be your assistant, not your brain. When Copilot gives you a solution that works, don’t copy and paste it straight away. Slow down. Read it line by line. Ask why that particular approach was chosen. And every now and then, close the chatbot and ask a senior. Not because the bot is stupid, but because it has no sense of what it doesn’t know.

Being a junior 2.0 doesn’t mean being the fastest prompt engineer. It means using the most powerful tools we’ve ever had without letting them think for you. Otherwise, we’re not developers; we’re just very slow compilers.