A message pops up. Bug report, one of the products I work on.
I’ve been deep in a different codebase for two days. Different languages. Different conventions. Different mental models entirely.
For a second, I stare at the project name and feel nothing. No context loads.
If you’ve worked across multiple projects at the same time, you know this moment.
The Setup
At Gurzu, engineers work across several products simultaneously. Rails backends, a Phoenix/Elixir API, React and Next.js frontends. Each has its own conventions baked in. Its own recent decisions. Its own unfinished threads from the last time you were in it.
Switching is constant. Sometimes mid-day. Sometimes mid-thought.
Each project is also at a different stage, active feature work, stabilization, a quick patch before a release. You don’t just swap the codebase. You swap the entire context around it.
What Actually Makes It Hard
The obvious answer: there’s a lot to keep track of. The real answer is more specific.
Losing your place. Step away from a project for a few days. When you come back, the thread is just gone. You know you were in the middle of something. You can feel the shape of it. But the context has evaporated. Twenty minutes spent just trying to remember what “done” looks like for the thing you were building.
The gear shift. My home language is Elixir. Pattern matching, pipelines, immutable data - muscle memory. Open a Rails codebase right after, and the brain doesn’t immediately follow. You start writing something that looks right, and only realize mid-way through that you’re thinking in the wrong paradigm. Like reaching for a light switch in someone else’s house.
Working across Rails codebases also means dealing with very different architectural decisions, from application structure to database design. For example, horizontal sharding in Rails introduces an entirely different set of considerations when working with large-scale applications
Convention mismatch. Every codebase has its own unwritten rules, how things are named, where logic lives, how errors are handled. Spend long enough in one and those rules feel like gravity. jump to another and you write something that looks perfectly reasonable, but violates local conventions in subtle ways that only surface in review.
The Mindset Shift
For a long time, I treated context switching as a problem to minimize.
The more useful reframe: some of this is just the job.
When you work across multiple products, you’re not one developer working on one thing. You’re closer to several developers sharing one brain. The goal isn’t to eliminate the switching. It’s to get better at the transition, faster re-entry, lower cost per switch, less time lost to disorientation.
What Helps
Reading the recent history, When re-entering a project, start by reading, not the whole codebase, but recent commits, open PRs, your own last changes. Let the code remind you where you were rather than trying to reconstruct it from memory. It takes five minutes. It works.
Using AI-augmented engineering practices to get caught up fast. This one has genuinely changed how I work.
When you come back to a codebase after time away, you can ask the agent questions you’d be embarrassed to ask a teammate. What does this module actually do? Why is this structured this way? What are the conventions around error handling here?
Agentic coding loops are particularly useful here because they let AI work through the codebase iteratively rather than simply generating isolated snippets.
It reads the code and explains it. No judgment, no context needed. You get a working mental model of the area you’re about to touch, understand decisions you weren’t around for, and surface things you’d forgotten. It’s not about replacing the thinking. It’s about not spending mental energy on retrieval when that energy is needed for the actual work.
Without a system
- 30+ min to re-orient after switching
- Thrashing between language paradigms
- Convention errors caught in review
- Reconstructing context from memory
With a system
- ~5 min re-entry ritual
- Intentional context handoff
- Caught before you write
- Let the codebase tell you
The Bigger Point
Context switching doesn’t stop being hard.
But the blank-brain moment at the start of a switch does get shorter. You learn to let go of one context before picking up another, treating it as an intentional handoff rather than a forced interruption.
The disorientation is still there. It just lasts seconds instead of minutes now.
That’s probably as good as it gets. And honestly, it’s enough.
