A corporate codebase is a collection of multiple repos. A single feature often spans several services — the frontend, a bff behind it, and some legacy service still in the mix somehow. Each repo was built by different people at different times, and the knowledge that ties them together is scattered: across the code itself, across Confluence pages that may or may not still be true, and in the heads of whoever has been here long enough.
That knowledge is what a senior dev spends months building up. An agent starts every session without it, seeing only the repo you point it at. But it can read the same code and the same docs and build the same understanding itself, if you give it the chance to research and write down what it finds.
So I stopped pointing it at one repo. Now I run the agent one level up, from a folder that holds all of them at once.
TLDR; I run the agent from a folder one level up that holds all the repos at once, next to an
AGENTS.mdthat maps how they connect and adocs/folder it writes its research into. Every ticket starts as research, not code: the agent reads across the repos and writes a plan, I review the plan, then a fresh agent implements from it. Wire your systems in as CLI tools, build skills, let it check its own work, and read every diff yourself, because as far as anyone else is concerned you wrote it.
the workspace
So here is what is in that folder:
workspace/
├── AGENTS.md # the map: what each repo is, how they connect
├── docs/ # the agent's notes: research, plans, ticket context
│ └── tickets/
├── .agents/skills/ # reusable how-tos you teach the agent
├── worktrees/ # throwaway copies for parallel work or PR review
├── {repo1}/ # cloned repos below
├── {repo2}/
└── ...note: symlink CLAUDE.md to AGENTS.md if you use Claude Code. I don’t default to Claude Code because different organizations approve different AI tools, and any coding agent can do this.
Everything next to the repos is there to help the agent make sense of them.
AGENTS.md is the map. When a change touches the backend and the frontend, it is what tells the agent the two are related at all, so it stops treating each repo as an island.
docs/ is the agent’s memory. It is plain markdown, so I read and edit it in Obsidian, the same files the agent writes to. More on how I use it next.
The workspace root can be its own git repo, so your AGENTS.md, docs/, and skills are versioned. Just do not .gitignore the cloned repos to tidy it up: search tools respect .gitignore, so an ignored repo goes invisible to the agent.
how I work in it
The agent has no memory between sessions, so the trick is to make it write things down and work off the writing.
I start by asking it to pull the ticket and research the code across the repos, then write up what it found and how it plans to do it. That goes in docs/tickets/. Then I read it, and this is where most of my time goes. Reviewing one document beats going back and forth in chat: I see the whole approach at once, and catch the wrong assumption or the repo it forgot to check. Often the research turns up a real decision to make, or something about the system I did not know.
Some of those docs are not throwaway plans. They are reference pages. Even a change that lives in one repo often sends the agent into another to see how a feature actually works. The first time it works that out, it will write explanation down as a topic page, and after that it reads the page instead of figuring it out again. Same for an internal process, or a third-party library nobody remembers the quirks of.
Once the plan is right, implementation is the easy part. A fresh context window, pointed at the doc:
in {repo} implement X, see {path to the plan}The thinking is already done and written down, so the agent does not rediscover anything. It just builds. Most people get this backwards, rushing the agent into code and then babysitting it. The slow, careful part should be the research and the plan. The code mostly takes care of itself.
give it tools
The agent is only as good as what you let it reach. Wire it into the systems you already use: JIRA, Confluence, Datadog, Sentry… And prefer CLI tools over MCP, because a CLI can be piped and filtered, so the agent pulls a query, cuts it to the lines that matter, and moves on. Any MCP can be wrapped into a CLI with mcp2cli, and each tool comes with a small skill that says how and when to use it.
The move underneath all of this: when the agent does something tedious and repeatable, have it write the steps down as a skill, then generalize it. Worktrees are the example I reach for. Ask it to set up a worktree for one repo, then make it a skill that works for any of them, picks a free port when several run at once, and fills in the .env. Agents are very good at this tedious setup, and a skill means you get it right once. mise is the same for runtimes: tell the agent to use mise exec in AGENTS.md and it runs the right node or ruby version, not whatever is on PATH.
The other half is letting the agent check its own work. Some of it is free: the models already run the linter and typechecker, and they love writing unit tests.
But that only proves the code holds together, not that it does what you wanted. Running the real thing is the part you have to give it. Wrap your API in a CLI that injects the auth header, and the agent can hit the endpoint it just changed and read the response. Give it agent-browser and it renders the page itself instead of guessing from the markup. Same move as before: the first time you work one of these out, make it a skill.
review
This is the step people skip. The code runs and the tests pass, so you ship. But the faster you move, the more bugs you ship too, and review is what sits between the two.
Some of it the agent can do. When a human leaves a comment on your PR, that is a rule worth keeping. Ask the agent to generalize it into a reviewer subagent, and next time it catches the same kind of mistake before a person has to.
The rest is on you. Read the code and make sure you actually understand it, and where you do not, ask the agent to explain it. Not every part needs the same attention. Some you will build on for years, so you want them clean and fully understood (see vibecoding in prod at Anthropic). Others you can skim.
And in an existing codebase the agent sometimes changes things you never asked it to touch. You only catch that by reading the diff yourself.
validate
Automated tests you can hand off, that is the agent’s kind of work. The manual pass you keep.
Have it write the checklist for manual QA, the flows to click through and what each screen should show, then go through it by hand. You know what correct looks like here, and clicking through yourself is where the gap between what you meant and what got built turns up.
parallelize
Most of the time I have more than one agent going. One is building a feature, another is researching the next ticket. They all take time, and none of it needs me sitting there watching.
Worktrees are what make this work on a single repo. Each agent gets its own copy, so two can touch the same repo without stepping on each other. I split the terminal into a few panes, one per agent, usually three.
It fits the corporate day. You have a meeting in ten minutes, so you start the agents and read what they did when you get back. The dead time you used to lose is where the work happens now.
The cost is the switching. Jumping between agents is draining and it quietly lowers the quality of your thinking, so for anything that needs real focus I run one and leave the rest parked.
make it your own
Most places already have a boilerplate. Someone set it up a while back. It tries to cover everything, and now half of it is stale, full of instructions written for an older generation of model. Or it works fine for someone else and just does not fit how you work.
Build your own. You do not have to rip out the shared one or talk anyone into switching, yours can sit next to theirs. As long as it works for you and you stand behind what it produces, that is enough.
you are still responsible
Unless it is a throwaway prototype, the code your agent writes has to be as good as code you write yourself, because as far as anyone else is concerned, you did write it. Whatever the agent ships, you own it.
That is why I am careful with someone else’s skills or a ready-made system. I use them, but I read what is inside first. What you build yourself you understand, you can steer, and when it breaks you know what happened. Take the whole thing off the shelf without looking and you are on the hook for code you never understood. The risk is your own local maximum, doing it your way because it is your way, not because it is better. So it helps to look at how others work from time to time.
The agent will keep doing more of the work. Understanding it, and answering for it, is the part that stays yours.