As my friend Patrick likes to say, a superpower of agentic AI is its patience. You can ask it inane question after inane question and it will keep answering, pleasantly and helpfully. You can give it all the tedious tasks you hate to do, and it will do them. It’s not just like having a very knowledgeable intern on hand all the time — even the intern would lose patience with you eventually. Claude will not. Even better, Claude can’t really lose concentration or interest, whereas at some point even the most motivated team member will start phoning it in.

And this patience means you can ask Claude to do a whole range of work that you would never consider asking one of your team to do. One of my new favourites is the explainer.

I first got the idea for this while working on a fun little project for my nephew Henry. Longer ago than I care to remember, back when I was still a teenager, I wrote a simple game to help you learn to type. It never went anywhere commercially, but it was very big with my four hyper-competitive younger siblings, and they have fond memories of playing it to this day. To the point that when I recently caught up with my brother — Henry’s dad — he spent some time reminiscing about how good he was at it.

The original is lost to the mists of time, but I wondered if Claude would be able to recreate it for me. This was still early on in my Claude journey, and by now you’ll be familiar with versions of this story: not only could it recreate it, it did a fabulous job in about 5 minutes. (Version One took me substantially longer to handcraft.) That then got me reminiscing, about my journey into writing software. I was probably a little younger than Henry when I started out, and I got hooked on books like these, painstakingly typing programs into our first home computer and praying that I hadn’t made any typos. I wondered: how could I help Henry learn about how the game Claude and I (but mostly Claude) had put together?

“Please write me a short webpage that explains how this game works, aimed at a reasonably computer-literate 10-year-old who has experience using Scratch”

A few short minutes later, and the explainer was ready to go. Not only had Claude done a decent job of pitching the content, it had done a whole bunch of stuff that I hadn’t even asked it to:

  • Embedding the game in the explainer, so you can play it before you learn how it works
  • Calling out little info boxes for key concepts
  • Adding a “Things to try yourself” section at the end, turning a piece of reading material into something a kid can actually tinker with

It wasn’t perfect — the level was a little high, and in hindsight I wish I’d asked it to do something more interactive — but it did an amazing job off a single prompt. You can see the explainer, the game, and all the incredibly helpful bonuses that Claude added without me asking here.

I’ve since started working on a side project with Claude — something new that I’m not quite ready to share more about, but my first project where I’m letting Claude do almost all the coding. I’m still giving directions and keeping an eye on its work, but unlike my work on Serve The Team, where I wrote most of the original codebase and can easily interpret changes, this is all brand new. I rapidly got to the point where I started to lose track, and that made me nervous. I want Claude to do the work, but I don’t want to lose touch. What to do?

Yes, the explainer returns! I asked Claude to produce a set of documentation that covered the high level design of the project, pitched at someone who had Software Engineering knowledge but who is not an active engineer. And then I asked it to keep it updated whenever we changed anything significant. And, once again, it’s done an excellent job. I feel better informed; I can ask more sensible questions about design and implementation decisions; I have confidence that I can continue to steer the project in the way I want to.

What it lacks in perfection it more than makes up for in speed and patience — and it helps make me more effective too.

I don’t think this will be the last explainer I get Claude to write. In fact, I think it’s likely to be a pattern I return to again and again, and not just for code. A few other places I think it could land well:

  • Onboarding to something you’ve inherited. Point Claude at a Notion space, a shared drive, or a tangle of old project docs, and ask it to write the “getting started” guide for someone joining the team next week. You become the editor instead of the author.
  • A primer on a domain you’re new to. Just been moved into a regulated area, a new department, or an acquired team? “Explain revenue recognition / SOC 2 / insurance subrogation to someone with strong general business knowledge but no prior exposure.” Pitch level controlled, no judgement, infinitely patient.
  • The same project, explained three ways — for the CFO (what it costs and saves), for the engineering lead (technical risks), for the customer (what changes for them). Same source material, three audiences. The kind of thing a small team could never previously afford to do, now almost free.
  • A “where we left off” doc for future you. Coming back to a project after a couple of weeks away? Have Claude write the catch-up brief so you don’t lose a morning re-reading old threads.

The explainer format’s power comes not just from its ability to help you learn quickly, but also from its durability and navigability. Unlike a chat with Claude Code in a terminal or with Claude itself in the app, the explainer outputs are easy to store, to share, and to add structure to. It’s not just that it helps you learn once — it acts as a reference you can come back to again and again.

Patrick was right about the patience. What I didn’t expect was that the same patience would produce something so durable: a one-off answer that quietly turns into a reference. Try it yourself, and see what you end up keeping.