Building an internal coding agent starts by giving it read access to the repository, its documentation, and its test suite, then defining tools for the actions it needs, such as running the test suite, executing a linter, searching the codebase, and creating a branch or pull request, rather than granting unrestricted shell access. The agent should work inside a sandboxed environment with the repository checked out, network access restricted to what the build actually requires, and every code change routed through your normal pull request and review process rather than committed directly to a protected branch. Grounding the agent in your specific conventions, through a project instructions file describing coding standards, architecture patterns and areas to avoid, meaningfully improves the quality of what it produces compared to a generic coding assistant. Frameworks like the Claude Agent SDK, which powers Claude Code, are purpose-built for this kind of file-editing, test-running, multi-step coding loop and can be extended with MCP servers for your issue tracker or CI system. Start with a narrow task category, such as fixing failing tests or writing boilerplate, before expanding scope as reliability is proven. Nanobase AI builds these internal coding agents integrated with a client's existing repositories, CI pipeline and review workflow.
Design the tool catalog by risk tier, not by convenience
The single decision that determines whether an internal coding agent is safe or reckless is how its tools are scoped, and the common shortcut of granting broad shell access because it is faster to set up is exactly the wrong instinct for a system that will run against a real, shared codebase. Every action the agent can take should map to an explicit, named tool with a defined risk level, not an open-ended shell command it constructs itself.
| Tool category | Example | Risk level | Access pattern |
|---|---|---|---|
| Read and search | Read a file, search the codebase, view git blame | Low | Always available |
| Analysis | Run the linter, run static analysis | Low | Always available |
| Verification | Run the test suite | Medium | Available, results logged |
| Modification | Edit a file, create a branch | Medium | Sandboxed working copy only |
| Publication | Open a pull request | Medium-high | Routed through normal review, never direct commit |
| Direct commit to protected branches | Push to main | Blocked | Not exposed as a tool at all |
Grounding in your conventions matters more than model choice
A generic coding assistant with no context on your specific conventions produces code that is technically functional but stylistically and architecturally inconsistent with the rest of the codebase, which then costs reviewer time to fix regardless of how capable the underlying model is. Providing a project instructions file describing coding standards, architecture patterns, testing expectations, and areas of the codebase to avoid touching without explicit reason improves output quality more reliably than upgrading to a stronger model without that context. Grounding is the highest-leverage, lowest-cost investment in coding agent quality, and it is also the piece most teams skip when racing to a first demo.
The sandbox is not optional
Every coding agent should operate against an isolated checkout of the repository, with network access restricted to only what the build and test process actually requires, so a hallucinated or malicious command cannot reach production infrastructure, exfiltrate credentials, or affect other work in progress. Every code change the agent produces should flow through the same pull request and review process a human engineer's change would go through, never committed directly to a protected branch, which keeps a human reviewer as the last checkpoint before anything the agent writes reaches shared code.
A phased scope expansion
Reviewer trust builds gradually, and expanding a coding agent's scope faster than that trust develops just shifts correction work onto the review queue.
- Start with a narrow task category with low blast radius and a clear success check, such as fixing failing tests or writing boilerplate and documentation.
- Measure the review burden: how much reviewer time each agent-generated pull request actually saves versus costs in correction.
- Expand to a second task category, such as small, well-scoped feature additions, only once the first category shows a consistently low correction rate.
- Reserve larger, architecturally significant changes for human engineers, or for an agent working under much closer supervision, well after narrower categories are proven.
Repository context: retrieval versus full checkout
Coding agents need enough context about the codebase to act correctly, and there are two broad approaches to providing it: giving the agent a full local checkout it can search and read directly, or building a retrieval layer that surfaces only the most relevant files and symbols for a given task. A full checkout is simpler to set up and works well for repositories of a size the agent's context and search tools can handle comfortably. A retrieval layer becomes more valuable as the codebase grows large enough that loading broad context on every task would be slow or expensive, at the cost of needing to maintain an indexing pipeline that stays current with the codebase.
Frequently asked questions
Should a coding agent have direct commit access to the main branch?
No. Every change should go through the same pull request and review process as a human contributor's change, with no exception for agent-authored code, so a person always reviews before anything reaches a protected branch.
Does the agent need access to production credentials or infrastructure?
No, and it generally should not have any. A coding agent's sandbox should be restricted to the repository checkout, the test and build tooling it needs, and network access scoped to only what running tests actually requires, with no path to production systems.
How much does grounding in project conventions actually improve output?
It varies by codebase, but teams consistently report that a well-written project instructions file describing conventions and architecture reduces the correction burden on agent-generated code more than switching to a more expensive model without that context.
Can a coding agent run our full CI pipeline itself?
It can trigger and read the results of your existing CI pipeline as a tool, which is generally safer and more consistent than having the agent attempt to replicate CI steps independently, since it reuses the same checks a human contributor's pull request would go through.
How Nanobase AI helps
Nanobase AI, a Silicon Valley enterprise AI engineering company, builds internal coding agents integrated with a client's existing repositories, CI pipeline and review workflow, scoping the tool catalog and sandbox deliberately rather than granting broad access for convenience. This work often extends into MCP servers connecting the agent to an issue tracker or CI system, and the scope-expansion approach mirrors the phased rollout used for back-office automation agents.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.