I kept losing the first 5-10 minutes of every AI coding session to the same problem. Claude Code knows nothing about my project when it starts up. Every time, I'd re-explain the architecture, paste in the conventions, remind it what we were working on. I got faster at the catching-up part, but faster still isn't free - and it compounds across every project and every session.
At some point I stopped trying to optimise the catch-up and started asking whether I could eliminate it. My last post was about getting better at communicating with Claude. This one's about the stuff I've built around it - the infrastructure that means I rarely need to catch it up at all.
Four patterns, roughly in the order I stumbled upon them.
Starting from zero, every time
Every AI coding session starts cold. The AI has no memory of your project, your conventions, your priorities, or any of the decisions you've already made. You either spend time bootstrapping it or accept worse output from a tool operating blind.
Most people solve this by getting better at the bootstrapping - writing longer initial prompts, pasting in more code, attaching more files. That works up to a point, but the cost is paid every session, across every project. It doesn't scale.
The alternative: build persistent context into your project infrastructure so the AI starts warm every time.
CLAUDE.md as Living Specification
Claude Code supports a CLAUDE.md file in a project's root - think of it as a README that the AI reads automatically at the start of every session. The key word is "living." It evolves with the project.
Seen Memento (2000)? Think that, but for AI agents.
My own, early version of this (before adopting the actual best practice, oops) was a bare-bones Context.md I'd generate reactively when approaching context limits. A dump of "what happened so far" created under time pressure, right before I lost it all. Not the most strategic approach.
The current, improved form is a 150-200 line document covering project purpose, architecture overview, tech stack, coding conventions, environment setup, current priorities, known issues, and security considerations. Everything a new team member would need to be productive on day one - because that's exactly what an AI session is. A new team member showing up every single time.
Writing a CLAUDE.md for an AI agent is also writing it for your future self. The exercise of making your project's context machine-readable forces you to make it human-readable too. I've started maintaining these for almost every project whether or not I'm using AI tools on it, because the document is useful as living project documentation regardless.
Every project benefits from a file that answers: what does this do, how is it structured, what are the conventions, what are we working on right now, and what should I be careful about? That those same answers happen to eliminate the AI cold start is a bonus.
The Ideation-Execution Pipeline
I used to explore a problem and build the solution in the same Claude Code session. Design a feature, then immediately start implementing. It felt efficient - all the context was right there in the conversation.
It produced mediocre results. The exploratory back-and-forth - trade-offs, tangents, "what about..." questions - would pollute the execution context. And the (self-imposed) pressure to start building would cut the thinking phase short. I'd end up with code that reflected half-formed decisions because I hadn't finished making them.
The workflow I've landed on separates thinking from building entirely. I explore the problem space in Claude.ai - discuss approaches, poke at edge cases, evaluate trade-offs. That conversation produces a structured implementation plan (see my previous post again, around who the output is for). I review the plan, with the framing that this plan is the contract for the project. Then I feed it to Claude Code, which builds it.
The most concrete example: building my MCP server from scratch. The entire design - architecture, API surface, authentication model, deployment strategy - was worked out in Claude.ai over a couple of sessions. I deliberately structured the implementation plan for Claude Code consumption: atomic tasks, file paths, success criteria. Claude Code then built the server to deployed production in roughly two days. The thinking took longer than the building, and that's the point.
There's a broader principle here about separating the what from the how. When I design in one tool and build in another, the design gets more rigorous because I know it needs to stand on its own. I can't hand-wave past the hard decisions because there's no one to hand-wave at - the plan needs to be explicit enough for a fresh session to execute without further clarification.
Ambient AI Infrastructure
Before I built my MCP server, the friction of catching an AI up on my current state meant I'd only bother when the conversation specifically required it. Planning my week? I'd manually list my priorities. Reviewing progress? I'd paste in my todo list. It worked, but the overhead meant I only provided that context when I knew I needed it - which meant I was always deciding upfront what was relevant, and sometimes getting it wrong.
MCP - Model Context Protocol - lets any Claude interface (Claude.ai, Claude Code, Claude mobile, the API) access external data sources through a standardised protocol. I built a personal MCP server in Go that exposes my productivity data: todos, milestones, weekly focus areas, reading list. Any Claude conversation can now pull that data without me providing it.
The practical result: I can open a Claude conversation and ask "what should I focus on today?" and it has access to my current priorities, active milestones, and recent activity. No pasting, no context-setting, no setup. The AI just... knows. Or at least it has the tools to find out.
What surprised me was how ambient context changes conversations you wouldn't expect it to. A technical discussion where Claude notices a relevant milestone. A content planning session where it references my actual reading list rather than asking me to list what I've been reading. Context I wouldn't have thought to provide ends up being useful because it's just there.
Thinking beyond my use case to what a team-scale version of this might look like. One developer building a personal MCP server is a convenience. A team building shared MCP servers for their codebase, their CI/CD pipeline, their project management tools - that's every AI interaction across the organisation starting fully contextualised. The cold start problem stops being an individual friction and starts being a solved infrastructure concern.
Parallel Session Orchestration
Once you trust the tool enough to operate autonomously between checkpoints, a natural next step: running multiple sessions in parallel on independent workstreams. One session on infrastructure, another on content, another on research.
This works when the workstreams are actually independent with clear boundaries. Each session has its own CLAUDE.md context and implementation plan. I've run infrastructure work for creative coding projects, alongside content review, alongside research synthesis, and the throughput increase is real. A question that's doing the rounds lately feels relevant here - am I the bottleneck in this process? What an upsetting thought.
Where it falls apart is interdependent tasks - when one session's output affects another's input, the orchestration overhead outweighs any benefit. I've learned this the hard way a couple of times, and now I'm more deliberate about scoping sessions to work that's actually independent.
The trust calibration matters. Too much oversight kills the speed. Too little risks quality drift, especially in languages or domains where you're still building expertise (Go, in my case - I can write it with AI assistance but I'm not yet fluent enough to catch every non-idiomatic pattern on a quick review). I've landed on checkpoint reviews at meaningful boundaries - not every line, but every feature or phase completion.
What I Still Get Wrong
My CLAUDE.md files are strong on architecture and conventions but light on testing expectations. Claude Code is perfectly capable of writing and running tests as part of its execution loop - I just haven't consistently built that into my workflow. The infrastructure supports it; my habits haven't caught up. Classic dev.
The auto-edit workflow optimises for speed, and the checkpoint reviews catch functional issues, but I don't have a systematic process for reviewing the quality of AI-generated code over time. Idiom, maintainability, patterns. This matters especially in Go, where I'm relying on the AI for language fluency I haven't fully developed yet. I've started building review checklists for this, but it's not yet habitual.
And AI sessions are ephemeral. Insights about what worked and what didn't are lost unless deliberately captured. I'm building systems for this - the retro exercise that this post and the last one are based on was a start - but session learning capture is probably the weakest link in my current setup.
Where This Leaves Me
Context documents, implementation plan workflows, review checkpoints, an MCP server that took longer to design than to build. None of this is inherently exciting. But it's what I've found that makes these tools actually useful.
If you're evaluating AI coding tools for your team, the tool's capabilities matter less than your readiness to build the infrastructure around it. A well-contextualised session with a mediocre AI can produce better results than a zero-context session with an excellent one. I've been on both sides of that enough times to be confident about it.
The biggest question for me now is what the next layer of this infrastructure looks like - I've got ideas, but that's a future post.
Top comments (0)