Forever Junior: The Skills AI Can’t Develop For You

It’s an agentic world.Software engineering is going through an AI revolution we’re all still trying to understand. For years, we’ve been told software engineers are six months from extinction. Some still believe the job is disappearing. Others say it’s simply changing.My experience says it’s the latter.My fear with AII’ve seen a real shift in priorities for engineers, but the job itself is very much still needed. At Criteo, engineers are still hired, still valued — and increasingly asked to lean on AI agents to boost productivity as much as possible. But every one of those messages comes with the same addendum: keep a firm hand on the wheel. Use the tool, but don’t stop knowing what you’re doing.As a Junior fresh out of school, “still learning what I’m doing” isn’t a caveat — it’s the job description. So it’s tempting, and a little dangerous, to let an agent not just do the work, but learn it in my place. It knows much more than I do, after all!We were taught in school that the way to get better at this job is to just code. Now we’re told not to code directly if we can help it. So — how are we supposed to learn? That’s the extinction I’m actually afraid of: not Software Engineers disappearing, but Seniors disappearing — as we all become forever Juniors, only ever qualified to review one agent’s work with the help of another.So what was I supposed to do about it?I started by researching two questions:What has AI actually changed in my job description?What’s a Senior, concretely?To answer the former question I just had to listen to discourse online and at work. Many are saying that reviewing code is now more important than producing it. The consensus seems to be that learning coding syntax and languages is obsolete. And of course companies want us to focus on things like token management to optimize costs.For the latter question, I observed Seniors at work, specifically in my team, and picked up some keys to what Seniorhood meant. On my team, the Seniors are the ones who can defend code they’ve shipped, argue a design choice instead of just having one, tell when an agent is heading the wrong way, know when to delegate and when to just do it themselves — and take the time to teach the rest of us.With these guidelines, I made a map of where I needed to grow with my first milestone being to get nominated for a promotion by the end of the year. As I follow this map, I hope to reach Seniorhood one day.The next question was how. Clearly, I needed to develop skills.I started, like a lot of engineers did, writing a skill.md: instructions and patterns fed to a model so it would behave more like a mentor teaching me about Senior behaviors. It’s useful, sure. But somewhere in that process I noticed the real gap wasn’t in my agent’s behavior — it was in mine. So the focus of this article isn’t really about the skills I wrote. It’s about the ones I had to develop in myself to keep up with the ones I was developing with the agent. The ones that I believe will actually allow me to evolve from Junior to Senior.QuestioningI started by instructing my agent to ask me Socratic questions to test my understanding of the plan or the code itself. A little pop-quiz at the end of each decision or code change. In practice, the questions were relevant only half of the time and they were mostly useful to prompt me to look closely at the plan or code and talk with the agent to make sure I understood it.# Understanding checks and delegated work - After implemented work, prompt understanding—rotate style: e.g. explain in their own words, predict what breaks if X changes, walk through one failure mode, defend a trade-off in one sentence. Gently correct and re-check if needed. - Subagents or delegated tasks must follow the same rules: no unconfirmed mutations and no unconfirmed mutating verify (subject to the same-task verify rule after approved implementation).Code language: Markdown (markdown)That’s when I noticed I was building a human skill of my own. One every five-year-old already has mastered as they ask “but why,” on repeat, until someone caves.Curiosity.The best trick an LLM has is that it speaks your language back to you — so use it. Ask your agent to explain a decision you don’t follow. Ask it to cite a source when it name-drops something unfamiliar. Ask it to justify a suggestion that just feels off. That last one is the real trick: making an agent explain a flawed solution out loud is often how it catches its own mistake — and how you catch it too.A Senior can defend code they’ve shipped to production. They can argue their design choices. They can tell when an agent is going the wrong way and redirect. Question your agent enough, and you’re rehearsing exactly that.Yes — this costs tokens. Fair. But I’ve found it’s more efficient overall to slow down here, because code I actually understand before I ship it works in production far more often. And when it doesn’t, I can fix it myself instead of round-tripping with the agent again. I’d rather use AI a little less often, and get properly curious every time I do, than push code that’s only half-understood and pay for it later.ReviewingIf you’re coding with an agent as much as possible, you’re going to spend most of your time reviewing its work instead. Reviewing is its own skill — arguably the one you’ll need most to actually reach Seniorhood — especially in this AI landscape. The good news is, you’re already sitting on a training set for it: every comment a Senior has ever left on your code.Pay attention to the patterns. Constantly getting notes on naming? Your team clearly cares about naming conventions — check every name in your agent’s code twice. Do it enough, and you start to notice the practices that are specific to your industry, your company, even your team. And with that you can practice emulation.# Similarity to existing code and reusability For each substantive task: 1.

Every time I added a new entity type in it, Seniors would say some version of “this looks a lot like this one we already have.” So I started using that existing entity as a template — and when I pushed code for review, I watched reviewers scrutinize every deviation from the template entity. The pattern was unmistakable: justify any deviation, reuse whatever you can. Once I saw it, I could apply it myself, reviewing my agent’s output before a colleague ever had to.I took it a step further and wrote the pattern into my skill — the markdown-file kind, this time, fed straight to the agent. Now it has the pattern in mind before I even open the review. You can push this further too: point AI at your own git history or team chat and have it surface the reviewing patterns for you.Funny enough, that’s the two meanings meeting in the middle: I built a skill so I could get better at a skill. The file makes the agent’s first draft look more like my team’s code; reviewing that draft anyway, over and over, is what slowly turns me into a better reviewer. In the end, hopefully, I won’t be a Junior with a good skill file. I’ll be the Senior who wrote the comments that went into it.HandwritingI’m sorry to report that the thing that’s helped me most is pretending, occasionally, that I’m back in a school exam where use of tools like AI is “cheating”. This is how you build the skill Seniors already have in spades: autonomy.Seniors did this job without agents for years. They can argue a design choice because they’ve had to make those choices themselves, and live with them. They can tell when an agent is heading the wrong way because they used to code without one. Having an agent sitting next to you at all times can keep you from this “learning to swim by being dropped in water” method.