Agentic Coding Tools in Production: What I've Learned Shipping With Them

I'm Tom Lang — I've built and scaled engineering organizations for three decades, from startups to 250-plus engineers and through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

The hype around agentic coding suggests you can just tell an AI to "build a billing system" and go to lunch. The reality of running these tools in production is the whole point of this post: if you don't constrain them, agentic tools will generate massive, perfectly formatted, subtly broken technical debt faster than your team can possibly review it.

I covered where AI earns its place across the delivery lifecycle in the companion piece; this is the deep dive on the build stage specifically — how I actually run engineering teams on agentic tools without blowing up the codebase, from a year of shipping with them.

Two wins and one expensive letdown

Let me be concrete, because the honest picture is neither "magic" nor "useless."

Win — the boilerplate bulldozer. I needed to migrate a large React codebase to strict TypeScript. An agent systematically opened 50 files, inferred the correct prop interfaces by reading how each component was actually used, and applied the types flawlessly. It saved a week of mind-numbing manual typing. This is agentic coding at its best: mechanical, high-volume, verifiable work.

Win — test-suite scaffolding. I handed an agent a complex data-transformation utility and told it to write tests for every edge case, including nulls and malformed arrays. It found three edge cases the human author had missed and wrote the assertions in ten seconds. On pure, isolated functions, this is nearly free value.

The letdown — context hallucination. Then I asked an agent to implement a multi-step Stripe subscription-upgrade flow. It hallucinated an API parameter that didn't exist in the current version of Stripe, silently swallowed a webhook error, and created a race condition in our database. Here's the dangerous part: it looked perfectly logical on the screen. It took a senior developer two days to untangle. That's the whole risk in one story — the failure wasn't ugly or obvious; it was confident, plausible, and wrong, in exactly the kind of stateful, third-party-integrated code where wrong is expensive.

The production guardrails

When agents triple the volume of code your team produces, your traditional code-review process breaks. You cannot just read diffs anymore — there are too many, and they all look fine. So the guardrails have to change. (The team-culture side of this — skill atrophy and adoption theater — lives in adopting AI without rotting your engineers; what follows is the agent-specific half.)

Zero architectural autonomy. An agent is never allowed to invent a new pattern. If we use Redux for state, the agent is strictly prompted to use Redux. If it imports a new state-management library because "it thought it was better," the PR is rejected on sight. Consistency is worth more than any individual clever choice.

The "never touch" list. Agents are banned from touching core authentication logic, cryptographic functions, financial calculations, or raw database migrations — unless a human is pair-programming with them line by line. The blast radius of a hallucination in those areas is catastrophic, and the Stripe story above is exactly why. (Same human-in-the-loop line I draw on governance for anything that touches money or identity.)

The "why" review. Reviewers no longer look for syntax errors — the AI rarely makes them. They look for logical drift. The human's job is now to ask: How does this fail under load? Does it handle the null state? Did the agent quietly delete a load-bearing edge case because it didn't understand the context? That's a harder, more senior kind of review than scanning for typos, and your process has to make room for it.

The golden rule of AI code. If an AI writes the feature, the AI must write the automated tests for that feature before a human reviews it — and the human reviews the tests first. If the tests are shallow, the code is rejected before anyone even reads it. Shallow tests are a reliable tell that the agent didn't actually understand the problem.

The tooling playbook: which agent for which job

After testing essentially every AI editor and extension on the market, my definitive stance is this: no single AI tool solves every engineering bottleneck. The landscape splits into two philosophies — the integrated "magic" IDEs that keep a seamless global context (and can behave like a black box), and the modular approach where you configure each agent's behavior precisely. A mature team builds a modular stack, matching the tool to the task. Here's how I actually deploy them.

The production standard: VS Code + a configurable multi-agent setup (Roo Code / Zoo Code). For day-to-day feature development, this is my gold standard, because it solves what I call context collapse. When you force a single global agent to be your cloud architect, front-end designer, and database administrator all at once, its context window degrades into chaos — it starts hallucinating CSS classes into SQL queries, or bypassing security middleware because a React component confused it. The fix is role-based agentic engineering: I spin up a Postgres DBA agent with a strict prompt ("you only write database migrations, you never touch the front end, you optimize for read-heavy indexing"), then switch to a React agent ("consume the endpoint the DBA just built, adhere strictly to our internal component library"). Each agent has a narrow, clean context — and I stay visually in the loop before anything is committed, with the freedom to switch models per task.

The terminal heavy-lifter: Claude Code. Because it's a command-line agent with native OS access rather than an editor extension, it excels at autonomous, loop-driven work. My favorite use is the "grind it out" test fixer: point it at a failing suite and tell it to run the tests, read the stack trace, fix the code, and rerun until everything passes — it'll iterate in the terminal for ten minutes while I do something else. It's also excellent for CI/CD debugging: build scripts, Docker errors, dependency conflicts, right there in the shell.

The 0-to-1 accelerators: Cursor and Windsurf. Do I ever recommend the AI-first IDE forks? Yes — with clear stage-gates. For a solo developer, a pre-seed startup, or 0-to-1 prototyping where raw speed matters more than architectural guardrails, their deep out-of-the-box integration is a genuinely magical way to build an MVP from scratch. But you outgrow them in scale production: once you have ten-plus engineers, that same "black box" refactoring becomes a liability — it makes stealth changes across a dozen files, generates massive PRs that overwhelm reviewers, and locks your whole team into a proprietary editor.

The executive rule of thumb: use Cursor or Windsurf to build the prototype, VS Code with a role-based multi-agent setup to architect the production platform with guardrails, and Claude Code in the terminal to crush tedious build and test failures.

The honest goal

Agentic coding tools are a real force multiplier — the boilerplate bulldozer and the test scaffolder are pure gain. But they multiply whatever you point them at, including your mistakes, and the Stripe race condition is what happens when you forget that. The value isn't in the tool; it's in the constraints you put around it: no architectural autonomy, a hard "never touch" list, review that hunts for logical drift, and tests written before the code is read. Constrain them well and your team ships dramatically faster. Constrain them poorly and you get perfectly formatted debt at machine speed.

If you're rolling agentic tools out across an engineering team and want the speed without the two-day untangling sessions, that's exactly the kind of thing I help teams set up. Book a call and we'll build the guardrails before you scale the volume.