Junior Engineer at Criteo Describes How He Is Building Senior Skills While Working With AI Agents

A junior software engineer at Criteo says AI coding agents can write code, but they cannot make you a senior engineer. In a first-person essay, he describes four habits he used to keep learning while working with agents: curiosity, emulation, autonomy and collaboration.

The writer says the job is changing, not disappearing. At Criteo, he says, engineers are still hired and valued, and they are asked to use AI agents to be as productive as possible. The message always comes with a warning: keep a firm hand on the wheel and don't stop knowing what you're doing.

That is a tricky spot for someone fresh out of school. He says it is tempting to let an agent do the work and also do the learning for you. School taught him that you get better by coding, and now he is told not to code directly if he can help it. His real fear, he writes, is not that engineers vanish. It is that seniors vanish, and everyone stays a junior who can only review one agent's work with the help of another.

He started with two questions: what has AI changed in the job, and what is a senior, really? For the first, he listened to talk online and at work. Many people say reviewing code now matters more than writing it, and that learning syntax is becoming obsolete. Companies also want engineers to watch token use, meaning the units of text an AI model processes, which drive its cost.

For the second, he watched the seniors on his own team. In his words, they can defend code they have shipped, argue a design choice, tell when an agent is going the wrong way, know when to delegate and when to do it themselves, and take time to teach others. He used this to draw a map of where he needed to grow. His first milestone was a nomination for promotion by the end of the year.

He began by writing a skill.md, a markdown file of instructions fed to the AI model so it would act like a mentor. He soon noticed the gap was in him, not in the agent. So the essay focuses on the skills he had to build himself.

The first is curiosity. He told his agent to ask him Socratic questions, a kind of pop quiz after each decision or code change. By his account the questions were relevant only about half the time. Still, they pushed him to look closely at the plan or code. He says to keep asking the agent "but why": ask it to explain decisions you don't follow, to cite sources, and to justify suggestions that feel off. Making an agent explain a flawed solution out loud, he says, is often how it catches its own mistake.

This costs tokens, and he admits it. But he says it is more efficient overall. Code he understands before shipping works in production more often, and when it doesn't, he can fix it himself instead of going back and forth with the agent.

The second skill is emulation, which he links to reviewing. If you work with an agent a lot, he says, you will spend most of your time reviewing its output. Your training material for that is every comment a senior has left on your code. If you keep getting notes on naming, check every name in the agent's code. Over time you learn the practices specific to your company and team.

His team owns a product catalog. When he added a new entity type, seniors often said it looked a lot like an existing one. He began using the existing entity as a template, and he saw that reviewers scrutinized every deviation from it. The pattern was to justify any deviation and reuse whatever you can. He wrote that pattern into his skill file, and he suggests pointing AI at your git history or team chat to surface your team's review patterns.

The third skill is autonomy, and here his advice is a little old-fashioned. Every so often, he pretends he is back in a school exam where AI counts as cheating. Seniors learned by making design choices without agents and living with the results, he says. An agent beside you all the time can stop you from learning that way.

His skill file already stops the agent from editing files, running migrations or committing code until he confirms a plan. Read-only work, like searching and explaining, is allowed. But he found himself saying "go ahead" the moment it asked. So now, rarely and on purpose, he makes the change himself. He suggests a minor tweak to a feature you have already shipped a large part of.

He says this pays off in four ways. It keeps your grip on architecture, because working by hand shows you where a design is wrong. It builds understanding of how code actually works, so you can answer questions without going to look. It helps with token efficiency, since knowing where things live saves the cost of searching for files, and some jobs, like renaming a variable across a codebase in an IDE, are faster by hand. And it builds confidence that is earned, not borrowed from the tool.

The fourth skill is collaboration. No matter how capable AI gets, he writes, nothing replaces mentorship from a real senior. His skill file nudges him to ask a senior when a decision is a judgment call, and it can draft the Slack message. He found that copying the message led to copying the answer too. His advice is to write your own message with your own questions. You can send a draft to the AI to correct your understanding first, but don't be afraid of mistakes. Pointing them out is what seniors are there for.

He also writes that he is not the right person to say how seniors should mentor juniors in an agentic world, and that he would like to read about it.

As for results, he started by opening his skill file every time he used an agent. Now he opens it about once a day. He says writing the file was really a way of writing down how a junior should behave, and as he built the skills, he needed the agent less. He also says the experiments helped him get the promotion nomination earlier than planned.

He is clear that these four skills are not the full list. Scoping and estimating work, handling a 2 am incident, knowing what not to build, and mentoring juniors are all senior skills he hopes to build later. He closes by saying juniors have to take room to learn, mentors have to give it, and leadership has to allow it. Agents can't make that space, he writes. People have to.