Do AI coding agents need to be trained or fine-tuned on our codebase?
No. They work by reading your existing code, docs, tasks, and logs at run time — not by retraining. That's why getting access set up matters far more than any model tuning.
AI coding agents
AI coding agents are brilliant at some work and dangerous at other work. Give them the periphery, keep humans on the core — here's where they earn their place, and where they don't.
An AI coding agent can find the root cause of a bug in code no one has touched in a year — and, the same afternoon, confidently ship one that takes down checkout, if you let it near the core. The gap between those two moments is the same at every scale. For a solo founder it's forgiving; inside a company it's the whole game.
For a founder, most of this is already settled. Over the past year I've watched people with no serious engineering background build and grow real products themselves — a CRM for an offline school, a tool for business analysts, marketing automation for their own needs. The entry cost of building has collapsed; you can wire up metric collection from Jira and GitLab in an evening.
The pitfalls haven't gone anywhere — agents lose context, generate strange code, and some projects slide into chaos. That's solvable, and it's a lot of what I do; I wrote about the rescue path separately. That's the founder's version. The harder, less-charted problem is one scale up, inside a company — and that's where this piece goes.
At enterprise scale the agent is just as capable — the hard part is being allowed to use it. AI is already a standard tool in startups; inside a company, adoption stalls for weeks on approvals: security reviews, which data can reach the model, who owns the platform, how agents are governed.
The insight that unlocks it: nothing has to leave the building. You can run an OpenAI-compatible API entirely inside your own perimeter — an open-source model like Qwen served through LiteLLM and vLLM, reachable only over the corporate VPN, with an agent like Opencode or Hermes wired into the IDE and MCP servers linking it to Jira, GitLab, Confluence, and the rest of your internal tools. It runs on a developer's own credentials, touches only what that developer already can, and logs every action for audit. Security stops being the blocker. Standing the full stack up is a topic of its own, but it's no longer the barrier it was a year ago.

Once it's in — founder's laptop or corporate VPN — the question is the same: what do you actually give it?
Connected to your code, docs, tasks, tests, logs, and metrics — whether it's Cursor, Claude Code, or a self-hosted internal agent — it starts to understand your project. Here's where it earns its place.
End-to-end development of anything that matters. Money, blockchains, high-load systems, core architecture — anywhere a mistake is easy to make and expensive to reverse. In a startup, handing a whole feature to the agent already partly works; in production, with real traffic and real money on the line, it isn't a good idea yet. Does it speed things up? Yes. Does it replace a senior developer? No.
The pattern is simple. The agent covers the periphery around development: routine work, supporting tasks, navigating unfamiliar code, artifacts — everything with high volume but a relatively low cost of error. The core, where the cost of error is measured in money and users, stays with humans.

Engineers used to spend hours searching for information and grinding through routine. Now the main job is making the right engineering decision.
No. They work by reading your existing code, docs, tasks, and logs at run time — not by retraining. That's why getting access set up matters far more than any model tuning.
Startups usually start on a cloud service; regulated or security-sensitive companies increasingly self-host an open-source model so data never leaves their perimeter. The trade-off is control and privacy versus the effort of running the stack yourself.
Access. A chatbot answers from general knowledge; an agent connected to your code, docs, tasks, and logs acts inside your actual project — which is exactly why the line between what it should and shouldn't touch matters.
Yes — the limit isn't building anymore, it's knowing what to build and keeping the codebase maintainable as it grows. Founders regularly ship real products this way; the failure mode is neglected structure, not missing code.