A learning path is only personal if it knows what to skip

I build Pravaha, an AI coach for engineering teams. The idea behind it is that learning at work should be shaped around the engineer, not handed out as a catalogue.

Coaching someone starts with a plainer question than how they learn. It is what they should learn next. Two weeks ago we shipped our answer to every customer: a learning path for each engineer, built from their goal and what they already know. As I write this, 42 engineers have built one.

The organisation knows the destination. The engineer knows the starting point.

You can probably say where you want your team to be in a year. More engineers who can ship AI features. More people who can own a system end to end rather than a ticket inside it. Those are destinations, and they are the easy half.

Pravaha is onboarded by organisations, not individuals, so we already ask for that half when a customer joins: what the company wants its engineers able to do, and for larger customers, what each department wants.

The hard half is the engineer. Take two people on your team with the same goal. One has written JavaScript for five years. The other joined from college in June. A plan that treats them the same wastes the first one’s month and loses the second one in the first week.

What we held the path to:

• It has to move. What an engineer wanted six months ago is not what they want now, and their team may have changed stack under them.
• Experience changes the route, not just the pace. Five years of JavaScript does not make Python unnecessary. It changes why they are learning it.
• It starts from what they know, and how sure they are of it. Someone who has used Docker once and someone who deploys with it every day should not get the same answer.

I am a big fan of roadmap.sh. It is the best public version of this idea, and it maps a whole field. That is exactly why it is too much here. An engineer inside a company needs the slice of the field their company cares about, minus what they already know, with a reason for every step.

Same destination, a different path

Here is an engineer building theirs.

The goal comes first because it decides which part of the map matters. After that the conversation asks only what moves a step on or off the path: the engineer’s main language, which side of a choice they are on, the tools they use every day. By the time it closes, the path is already drawn.

Here is what that produces for two engineers on the same team, both aiming at AI Engineer: one with five years of JavaScript, one who joined from college in June.

Five years of JavaScript. HTML, CSS and JavaScript, React, Git and web fundamentals are credited, each with the reason. The path runs Python, vector databases, API services, RAG applications, then AI agents, and ends on a choice between two agent frameworks. How LLMs work and fine-tuning sit beside it, marked as things to learn outside Pravaha for now. None of it repeats what they already know.

Joined from college in June. Nothing is credited. The path starts at web fundamentals and Git, and the same AI programmes sit at the end of it, a good deal further away.

Every step also carries one line saying why it is there for this engineer. That line matters more than I expected. Our Python programme describes itself as being for junior developers. Shown that on its own, the five-year engineer reads it as the wrong programme. With “new language, not new to programming” beside it, it reads as the obvious next step.

The map is drawn once. Each engineer’s path is laid over it.

When an organisation joins, we collect its goals and what it wants its engineers trained on. An agent turns that into a map for each role we find: which programmes lead to which, where the team has to pick one of two, and which topics have no programme yet and have to be learned elsewhere.

Each engineer’s path is laid over that map, never generated in its place. The model decides which goal applies, which steps the engineer’s experience already covers, and what the one line reason says. It does not add programmes, draw connections or reorder anything.

Credits are the riskiest thing the model does. “You already know React” is an inference from a conversation. So when it is unsure, it leaves the step on the path and lets the engineer say otherwise. A step credited by mistake is a gap nobody notices. A step left on by mistake costs one sentence to remove.

A path the engineer can argue with

No plan survives six months of a real job, so the path is never finished. Every engineer has an Adjust path button that opens a conversation with the coach. It is the only place the path changes after onboarding, and what the engineer says there is final.

That last part is deliberate. An engineer who corrects the plan once and sees the correction quietly reverted stops correcting it, and a plan nobody corrects drifts away from the person it is for.

What the first 42 paths say

We rolled it out to every customer two weeks ago. At the largest, around 350 engineers, people started setting goals in the first few days. As I write this, 42 engineers have a path.

The goals they pick most are AI Engineer and Software Architect. The first I expected. The second is engineers asking what it takes to own the design of a system rather than a feature inside one, and most teams never give them a way to ask that.

The number I am watching next is where enrolments come from. An engineer who keeps leaving the path to pick programmes from the catalogue is telling us the map or the credits are wrong. I will update this post after a month with what that shows.

An organisation can write down where it wants its engineers to go. Only the engineer knows where they are starting, and a plan that never asks them is someone else’s plan.