It had been two weeks since Claude Opus 4.6 launched and there was an emergency meeting. The brief was simple: if we were going to use AI as a team, how do we actually make it work? Demo what you’ve built. Show how your workflow has changed.

Each person had a part of the process that was quietly bleeding time. Everyone went to fix theirs.

Mine was context.

I was owning two modules: Progress Reports and Transcripts. Different contexts, similar DNA. Data flowed in from across the entire product and Toddle’s grading architecture was the spine underneath both of them. To work on either module, you had to hold about forty things in your head at once: how the hierarchy worked, which entities were inheritable, where configuration lived, why certain decisions had been made the way they had.

I had been trying to fix this with memory dumps, notes, supporting PRDs. Never enough. The touch points were too many, the product behaviours too specific, the edge cases too buried. The AI would work with whatever I gave it and return generic-good. Not system-aware. Not the kind of thinking that actually matched how we built.

So I started with a simple thought: if I want AI to think like someone who actually knows this system, it needs as much context as someone who actually knows this system. Not in the prompt. Before the prompt.

I took two days. The structure came from a simple question: if someone had never touched this module, what would they need to understand and in what order?

Module overview - the full scope of Progress Reports, how it sat within Toddle and the decisions that shaped it

Progress Report Sets - one of the two core components, its behaviour, rules and edge cases

Progress Report Templates - the other core component; same DNA as Sets but different enough in behaviour that collapsing them would have buried the distinctions that matter

Data entities and mappings - the connective tissue: how data mapped outward to Toddle’s broader architecture and internally between Sets and Templates

Overview first. Components next. Then how they talk to each other. 300+ screenshots from Figma and the live product. Everything I wished had existed when I was learning the module myself. Halfway through, I noticed something uncomfortable. I was writing down things I’d never written down before, knowledge I hadn’t realised I’d been hoarding.

Toddle was introducing a new entity to the ecosystem — fully scoped and detailed by the team. Our job was narrower: figure out where it lived inside Reports. Where it would render, how it would sit within the existing hierarchy, what configurations it would need. The kind of problem that usually means a few hours of thinking, a few more of back-and-forth.

I gave the AI the PRD for the new component and waited.

The response stopped me.

It didn’t just answer where the entity would render. It mapped where it would sit in the architecture, where the settings would live, what the configurations should look like, which edge cases needed handling. It had reasoned through the whole thing — not just the surface question I’d asked but everything underneath it. The kind of thinking that usually takes a morning, done in one pass.

The solution it returned matched almost exactly what my team would have produced. Not because it predicted what we’d say. Because it understood the system well enough to arrive at the same place on its own.

It turned out the markdown file fixed something I hadn’t set out to fix. There was now a repo anyone on the team could query, not just the AI.

Most people treat AI context as a prompting problem. Better description, better answer. Prompt by prompt. This isn’t wrong. It’s just shallow.

The higher leverage is different. It’s not how you frame the question in the moment. It’s how deeply the AI understands the system you’re working inside. When the AI knows the product’s reasoning, not just the structure but the why underneath the decisions, you stop getting generic-good and start getting system-aware.

But here’s why most teams never get there. Documentation has always been treated as overhead, not infrastructure. You write it when you have time, which is to say almost never. The work that matters is the work in front of you, not the work that explains the work. So knowledge compounds in a few people’s heads, the team operates on tribal memory and everyone accepts it as the cost of moving fast.

AI just made that cost visible. Because the moment you try to get AI to think like your team, you realise how little of your team’s thinking actually exists anywhere outside of people’s heads.

Which brings me to the thing I think most designers are missing right now.

Your value as a designer isn’t just taste. It’s accumulated product judgment: knowing why the hierarchy is built the way it is, why that edge case was handled that way, what breaks if you pull on this thread. That judgment is what makes your work good. It’s also the thing that lives entirely in your head and disappears when you leave.

The AI doesn’t replace that judgment. It amplifies it. But only if you’ve externalised it. If you haven’t, you’re prompting a general-purpose model and getting general-purpose results.

The document that trains the AI is the one that should have existed for your team all along. Building it isn’t a workflow trick. It’s the infrastructure your product knowledge runs on. And most teams are one resignation away from losing it entirely.

P.S :)

2 days of building context also showed me where the friction was. Getting Figma frames into a markdown file is tedious enough that most people won’t do it. So I built a small tool to fix that: Copy Pesto. It copies Figma frames and pastes them as images, directly. Currently in beta.