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 AI

I’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.

Questioning

I 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.

Reviewing

If 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. Discover — Search the codebase (and/or ask the user) for the closest existing feature (same kind of entity, resource, table, API surface, etc.).
2. Align — Summarize candidates; ask which analogue is best. If nothing fits, ask the user to confirm the work is net-new.
3. Anchor — State the chosen reference (paths, components, patterns) and keep it for the rest of the thread.
4. Plan and implement (when confirmed) — When outlining or implementing, call out divergences from the reference. If the reference is one-off, ask whether a small shared abstraction could serve both without over-engineering.
5. Information gaps — If the user omitted details the reference implies (fields, ownership, API shape), ask before assuming.Code language: Markdown (markdown)

My team owns a product catalog. 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.

Handwriting

I’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. I think it’s a method worth trying out every now and then.

I actually built a constraint directly into my skill.md for this: it isn’t allowed to touch a file, run a migration, or commit anything until I’ve explicitly confirmed the plan. Read-only exploration, sure — search, explain, propose. But the moment it’s time to actually write code, it stops and waits for me.

## Read-only (always allowed)
Search, grep, read files, list directories, and any non-mutating inspection are allowed without implement confirmation. Use them for discovery, teaching, and finding analogues in the codebase.

## Mutations (confirm first)
Do not edit files, apply patches, git commit/push, install dependencies, run migrations, write config, or run state-changing shell until the user confirms implementation of a concrete plan (files, areas, commands)—not merely answering a Socratic question.Code language: Markdown (markdown)

On paper, that pause should be enough. In practice, just saying “go ahead” the second it asks kept happening, and it didn’t teach me much. So every so often — rarely, deliberately — I use that same pause to actually make the change myself. Treat it as a test: small enough not to tank your output, meaningful enough to actually count. I suggest doing it for a minor tweak to a feature you’ve already shipped a large chunk of. No onboarding required, and it puts your understanding of everything your agent wrote — and you reviewed — to the test.

I’ve found this pays off in a few specific ways:

Architecture

Design is still a core skill in this job, and it’s exactly the one you can quietly lose your grip on without noticing. Interacting with an agent-built architecture by hand forces you to actually feel where it’s wrong — and seeing why a design failed is the first step to building a better one. A Senior who owns a system is the person who knows why it’s shaped the way it is.

Algorithmic understanding

When you only ever review, you tend to know the what without always knowing the how — until someone asks a clarifying question and you have to go find out. One hand-written change forces you to face these questions yourself, before it shows up in production. Answering that question in the moment, without going to look, is a Senior move — and it’s built one hand-written change at a time.

Token efficiency

This one’s new, and it costs the company real money. How can you learn about token efficiency when you’re not using AI at all you might ask? Because understanding your own code and architecture is how you can be pertinent in your token usage. It’s directly linked to the two previous points:

• knowing where things are: file discovery is expensive — the better you know where things live, the less you burn finding them.

• knowing the how: some jobs are still just faster by hand. Your IDE renames a variable across a whole codebase instantly. If you know the how, you already grasp the blast radius of that change. So there’s no reason to spend tokens finding files and rewriting them one by one.

Seniors know when to delegate and when to just do it themselves. You need the same instinct — even when what you’re delegating to is a machine.

Confidence

A bit of a bonus skill, but a real one. I’ve heard engineers at every level say they could never go back to coding without an agent. Occasionally doing it anyway is how you remember the agent is a tool for doing your job faster — not a replacement for being able to do it at all. Test the confidence, and make sure it’s earned. And honestly, I got into this job because I liked writing code. Doing it by hand once in a while is still the part I enjoy most, which is reason enough on its own.

The Seniors I trust aren’t confident because they have an agent. They’re confident because they’d still excel at their job without one, and they know it. That’s worth aiming for.

Mentee-ing

No matter how capable AI gets, or how good you get at using it, nothing replaces mentorship from an actual Senior. You learn how to become one by working with one. Seniors have to take the time to explain things so you can grow into that. We can’t lose sight of the fact that we work in teams for a reason.

Collaboration is the last skill on this list.

You’d think that’s the one skill you can’t build into an agent at all — but I tried anyway. My skill actually nudges me to go ask a Senior whenever a decision is really a team or a judgment call, and it’ll even draft the Slack message. But I’ve found that copying that Slack message was a slippery slope to copying the answer too. Soon enough, you’re just doing the job a good Slack MCP can do, and that’s the real AI takeover. The one you let happen. So draft your own message with your understanding of the issue and your own questions. You can even send your draft to the AI so it can correct your understanding before you contact a Senior. But don’t be afraid to make a mistake. You’re messaging that Senior so that they help you understand. They’re meant to point out your mistake.

Be the eager intern who isn’t afraid to ask the stupid question. It’s tempting to rush toward the next level, but the level you’re at right now comes with something worth using while you have it: people whose job includes looking out for you. Seniors carry a responsibility we don’t have yet — showing us the way up. No Junior becomes a Senior by practicing alone in a room. We need someone already there to show us what “good” looks like and correct us when we’re wrong.

Of course, you may be a Senior reading this and thinking the Senior job description has changed with AI too — especially the mentoring Juniors part. Mentoring Juniors in an agentic world is its own challenge, and worth its own experiments — ones I’m not the right person to run. I’d read that article, though. It’s another skill further up my map to Seniorhood.

Results

So — skill.md or skill issue? I started my little experiment of summoning my skill every single time I used an agent. Now I barely open it once a day.

When I built this markdown file with all the ways I wanted my agent to behave, I was really writing down all the ways a Junior Software Engineer like me should behave. As I built up the skills myself, I needed the agent less and less.

Curiosity, emulation, autonomy, collaboration — none of these come from the agent, skill file or not. They come from what you choose to do while the agent is running. That’s the actual thread here: every one of these is a way of staying an active participant in your own learning, instead of a passive reviewer of someone else’s output. The agent can write the code, and it can even write the questions. You have to do the reps if you don’t want to be thrown out of the loop.

Of course these four skills are not the whole list. Scoping work, estimating it, handling an incident at 2 am, knowing what not to build, carrying a decision across teams, mentoring Juniors — a Senior does all of that too, and they’re all skills I’m hoping to build one day. For now I’m going step by step, and I’m happy to say I’ve completed the first milestone. My experiments with AI and skill-building have helped me get that promotion nomination actually even earlier than planned!

So keep asking “but why.” Keep noticing what your reviewers always push back on. Keep the rare, deliberate change you make by hand. None of it will slow you down as much as you think — and all of it is what turns a Junior who reviews good code into a Senior who can write it, explain it, and one day, pass it on.

And Seniors, we’re going to need your help to get there. We’re working out how to keep learning in an agentic world; I’d love to read how you’re working out how to keep teaching in one. But neither of us can do it alone: room to learn is something Juniors have to take, mentors have to give, and Leadership has to allow for. Agents can’t make that space. People have to.