Mentoring bright young minds — early adopter to proficient agentic engineer
How we take engineers who are excited about AI and turn them into people who can ship agentic systems unsupervised. The progression isn't what most bootcamps teach.
By Nick Meinhold & Claude
TL;DR: The progression from "excited AI early-adopter" to "proficient agentic engineer" is roughly six stages, and it isn't taught in most bootcamps. The bottleneck isn't tool fluency — it's the unlearning. We've put a few engineers through this, including Robin and Delia. Here's the path that's actually worked.
A few times a year, someone reaches out wanting to be mentored. They're sharp, they're curious, they've spent six months on Cursor or Copilot and they think they're ready for the deep end. Sometimes they are. More often, they've built strong tool fluency on top of the wrong instincts, and the work of mentoring them is the work of unlearning.
I want to share the path that's worked for us. It's not a curriculum — it's a progression of identity.
Stage 1: Early adopter
You've installed Claude Code or Cursor or whatever. You've felt the speed. You've seen the moment where you said "write a function that does X" and the right code appeared, and you've never quite recovered from that. You're hooked.
This is a great place to start. The tools have become genuinely good, and the speed-up is real. The mistake is thinking this is the destination. It's stage one.
What we work on: keeping the excitement, deepening the pattern recognition for when AI is the right tool versus when it isn't. Most early adopters use AI for everything, including tasks where the round-trip is slower than just typing. The mentor's job is to start naming when the agent is helping versus when the agent is theatre.
Stage 2: Speed-up plateau
You've used the tools enough that the obvious wins are baked in. You're shipping faster, but the speed-up has plateaued. You start noticing places where the agent gets confused — where you've given it a vague prompt and it produced a mediocre answer, where you've forgotten to give it crucial context, where it confidently produced something subtly wrong.
This is the most common stuck point. People stay here for a long time. Some never leave.
What we work on: learning to write the contract, not the prompt. The shift is from "tell the AI what to do" to "describe what success looks like, what invariants must hold, and what verification you'll run." This is harder than it sounds. It feels weirdly formal at first. It's the move that unlocks everything downstream.
Stage 3: First serious orchestration
You've started running multiple agents. Maybe you've spawned subagents from a parent. Maybe you've set up a code reviewer. Suddenly you can do more than one thing at once, and it's a rush.
It's also the stage where mentees ship their first agentic disaster. Two subagents collide on a shared worktree. A reviewer agent rubber-stamps a regression because nobody verified its work. A fan-out aggregates wrong because one branch failed silently.
What we work on: orchestration as a discipline with real failure modes. Worktree isolation. Coordinator/subagent role separation. "Address suggestions, don't just collect them." When the parallelism breaks, why. The lesson is that more agents is not more capacity unless the patterns are sound.
Stage 4: Verification religion
Something goes wrong in production that wouldn't have if the verification had been done. It's almost always small — a fix that "looked deployed" but was sitting unmerged behind a CODEOWNERS gate, or a cron job that didn't run yet, or a cache that hadn't invalidated.
The mentee feels terrible. This is good. They are about to convert.
What we work on: the closing ritual. "Written" is not "merged" is not "deployed." Read the production reference. Watch one cycle. Confirm the bytes. The mentor's job is to make verification as natural as committing, so it happens by reflex rather than discipline. Engineers who've been here once never skip it again.
Stage 5: Tool design
Now the mentee starts asking the harder questions. Why do my agents fail on this kind of task and succeed on that one? The answer is almost always the tools. The agent's success rate is bounded by the quality of the tools it's been given. Bad input schema, ambiguous error modes, hidden side-effects, lack of idempotency — these are the things that move an agent from 80% reliable to 99% reliable.
What we work on: designing MCP tools as if they were public APIs. Strict typing. Documented invariants. Idempotency. Crisp error categorisation. Reading the success rate as a signal about tool design, not about agent capability.
Stage 6: Proficient agentic engineer
The mentee is shipping client work unsupervised. They're designing the contracts, choosing the orchestration shapes, building the tools their agents need, verifying on production, and teaching the next person.
They write less code than they used to. They ship more software than they used to. They sleep better than they used to.
This is where the title fits: agentic engineer. Not because they passed a course, but because they can now extend the systems that build the systems.
What we don't teach
Three things we don't try to mentor on, because they don't transfer well:
-
Specific tool fluency. Cursor, Claude Code, whatever you're using — those will change. The skill is the layer above the tool. We use what's best today and we'll use something else when something else is best.
-
Prompt engineering as a craft. Prompts are how you talked to last year's models. Contracts are how you talk to this year's. Mentees who've spent too long on prompt-engineering blog posts often have to unlearn the most.
-
The frontier paper of the week. Read them, don't be ruled by them. The shape of the work changes more slowly than the model release notes suggest.
What good mentoring looks like
It's not lectures. It's pairing on real client work with the mentee in the chair, the mentor watching for the moments where they would have made a different choice. It's pull-request reviews where the comment explains why, not what to change. It's letting them ship the agentic disaster in a low-stakes context so the lesson lands. It's reading their code in production a week later and noticing what stuck.
We've put Robin and Delia through this. We're proud of where they are. If you're looking for an agentic engineer to hire, or you're looking to become one, we'd love to talk.
If you'd like to be mentored — bring a real project, tell me where you're stuck, and we'll figure out together what stage you're at. Get in touch.