Agentic Coding in a Production Monorepo: The Harness Matters More Than the Model
How I actually use coding agents like Claude Code and Codex day to day - and why guardrails, not prompts, are what make them safe in a real codebase.
This portfolio's repository has more coding-agent configurations in it than human contributors. That's the result of a year of treating agentic coding tools as part of the toolchain instead of a novelty, and working out what it actually takes to let them touch a codebase you're responsible for.
Here's where I've landed.
The mental model: a junior engineer with infinite stamina
Autocomplete is the wrong mental model for a coding agent, and so is search. What works for me: a junior engineer with unlimited energy, a decent memory of every API ever written, and zero institutional knowledge of your system.
You wouldn't let a new hire push to main on day one. You also wouldn't waste them on nothing but boilerplate. The whole game is building the environment where their output is verifiable.
The harness matters more than the model
The single biggest lesson: the quality of agent output tracks the quality of your guardrails, not your prompts.
My monorepo is TypeScript end to end, with tRPC routers, Drizzle schemas, and a lot of React. The agent operates inside the same fences the humans do.
Type-checking is the first line of defense. A strict tsconfig catches a huge class of agent mistakes before a human ever reads the diff, and end-to-end type safety through tRPC means an agent can't quietly change an API contract without the compiler complaining somewhere.
Dangerous operations stay gated. Database migrations are the classic example: schema changes need senior review no matter who (or what) wrote them. CI enforces that, and the agent doesn't get a special lane.
PR pre-flight checks run on everything. Lint, tests, build, dependency checks. Agent-authored code goes through the exact same pipeline as human-authored code. No exceptions, because exceptions are where incidents come from.
If your repo already has good bones (types, tests, CI) agents slot in shockingly well. If it doesn't, they'll happily generate plausible-looking code that fails in ways you won't notice until production. The agent amplifies whatever engineering culture already exists.
What I actually delegate
Where agents earn their keep for me:
- Mechanical refactors with a verifiable endpoint: renames across a large surface, migrating a pattern, converting components to a new API. The type-checker proves completion.
- First drafts of well-specified features, when I can describe the behavior and point at an existing pattern in the codebase to imitate.
- Test scaffolding, because agents are tireless about the edge cases humans get bored writing.
- Codebase archaeology. "Where is this actually used, and what breaks if I change it?" is something an agent answers faster than grep-and-guess.
Where I don't: anything architecturally load-bearing, anything security-sensitive, and anything where the requirements live in my head instead of in writing. Writing the requirement down first isn't overhead. It's the same discipline that makes delegating to a human work.
Context is the real bottleneck
The frustrating failures are rarely capability. They're context: the agent didn't know about the internal convention, the deprecated module, the reason that weird workaround exists.
Two things help. The first is a CLAUDE.md or agent-instructions file in the repo, covering conventions, commands, and footguns, which every agent that lands in the repo reads first. It's onboarding documentation, and as with humans, writing it once pays off every session after.
The second is MCP (Model Context Protocol) servers for the systems the agent can't see: issue trackers, databases, deployment platforms. The agent queries them instead of me pasting context into a prompt. This is the piece I expect to matter most over the next few years. The tools are converging, but the context plumbing is where teams will differentiate.
The automation layer around the code
Not everything is code generation. The other half of "agentic" for me is workflow automation. I run n8n self-hosted, which fits naturally into a homelab that already runs Coolify, and it covers the glue: notifications routed by rules, scheduled jobs, webhooks between services that would otherwise need a cron job and a prayer.
The dividing line I use: if it needs judgment, it goes through an agent I review. If it's deterministic, it goes in n8n and I stop thinking about it.
Honest verdict
Agentic coding hasn't replaced anything I'd call engineering. It has replaced a lot of what I'd call typing.
The engineers getting the most out of these tools aren't the ones writing the cleverest prompts. They're the ones with the cleanest repos: typed, tested, documented, CI-gated. That was always good engineering. It just pays double now.