Have your AI teach you a legacy system like a university professor
Not a summary of the code. A course, with lectures, graphs from the real traffic, equations and slides, written to take an engineer from novice to expert in a few hours.
Every company has one: the component everything depends on that nobody fully understands any more. The people who built it have moved on. The design docs describe a version from three years ago. The code is correct in the way that only code that has survived production for years is correct, which is to say full of decisions nobody wrote down.
One of the people using Cockpit recently had to learn one of these properly, from scratch. The usual path is a few weeks of reading code, asking whoever is left who remembers it, and slowly building a picture in your head that you can't hand to anyone else.
They tried something different. They asked a coding agent to teach it to them like a university professor would.
The prompt
The request was short: write a lecture-style document, with graphs and data analysis, that takes an engineer from novice to expert on this component. Then make slides to help understand it better.
Three parts of that sentence do most of the work.
"Lecture-style." Ask an agent to "explain this code" and you get a tour of the files: this module does this, that function calls that. Ask for a lecture and you get a curriculum. It starts with the problem the system exists to solve, builds the vocabulary you need before using it, introduces the simple version of each idea before the real one, and only then walks into the code. That's the order a good teacher would choose, and it's rarely the order the code happens to be in.
"Novice to expert." This sets the depth. The agent can't stop at an overview, because an expert needs the edge cases, the failure modes and the reasons behind the odd decisions. And it can't skip the basics, because a novice needs them. The result reads like a course: easy at the start, demanding by the end.
"Graphs and data analysis." This turned out to matter most.
The agent did the data work itself
A professor doesn't only describe a system, they show you how it behaves. So the agent went and looked.
The component is powered by millions of rows of data and serves real traffic. To put graphs in the course, the agent had to analyse both: query the data, crunch the traffic, and plot what it found. Those graphs are where the understanding comes from. You can read a function that handles an edge case; seeing how often that edge case actually happens tells you whether it matters.
The maths came along with it. Where the component computes something, the course derives it step by step, the way a lecture would, rather than gesturing at "the model".
What came out of a few hours:
- about 18,400 words of lectures
- 36 figures, most of them built from the real data
- 342 equations
- a 114-slide deck to go with it
A second course on another legacy component, done the same way, came to 39 figures and 85 slides.
Making it teach the way you learn
The first draft was correct but not yet easy to follow, because it wasn't written for its one reader.
It took a few rounds to adapt the style to the way they process information: how much intuition before the formalism, when to show a graph rather than describe it, how long a section can run before it needs a concrete example. A human professor can't do that for a lecture hall of two hundred people. An AI tutor can rewrite the whole course for an audience of one.
The slides helped more than expected. Reading 18,000 words builds understanding; going through the same material as slides is how it sticks, and it's the version you can show the rest of the team.
Treat it like a course from a brilliant new hire
A course written this way is only as good as its checking. Read it the way you'd read a document from a very fast, very confident new colleague: rerun a few of the queries behind the graphs yourself, check the claims that surprise you against the code, and ask someone who knows the system to read the lecture on the part they know best. The graphs make this easier than with prose alone, because a wrong number tends to show up as a curve that doesn't look like your traffic.
Why this works now
Two years ago this would have produced a confident, plausible essay about a system the model had never seen. What changed is that coding agents now work where the system lives. They read the real repository, run the real queries and plot the real traffic, with the same access the engineer has. The professor isn't recalling the subject from training; it's doing the research for the course before it writes it.
The other thing that changed is how much of this one person can run at once. The course was one of about fifty sessions running that week, next to a prototype, a program charter, a research paper and the usual operational work. Most of the time the person wasn't writing anything. They were deciding what each session should do next, reading what came back and sending it back with notes.
That's what we mean by scaling yourself with AI: one person directing fifty pieces of work, each one done at the depth they'd want if they had the time to do it themselves. It's also why we build Cockpit, a Mac app that puts all those sessions on one board and shows which ones are waiting on you. At the end of that week it estimated the output would have taken about 167 days by hand. Treat that number with the same scepticism as the course; the method behind it is deliberately simple, and open in the app.
Try it
Pick the component everyone in your company is slightly afraid of. Give your agent access to the code and the data, and ask for this:
Write a lecture-style document, with graphs and data analysis from the real data, that takes an engineer from novice to expert on this component. Derive the maths. Then make slides to help understand it better.
Then read the first lecture, and tell it how you'd like to be taught.