Agentic Coding in a Consultancy: What Works and What Doesn't

Everyone's writing about AI coding agents right now, and almost all of it comes from the same place: a product company that's lived in one codebase for years. Good for them. That's not really our situation.

In a given month, one of our engineers might be elbow-deep in a ten-year-old monolith on one project, spinning up something from scratch on another, and trying to make sense of somebody else's half-documented microservices setup on a third. We've been using Claude Code across all of that for a while now, and honestly the biggest lesson has been kind of unglamorous:

How well this stuff works has way more to do with the codebase than the tool.

Same agent, same team, wildly different experience depending on what it's pointed at. Here's what we've actually seen — the good and the annoying parts.

(A note: nothing here maps to a specific client. Details are anonymized and sometimes blended across projects, because we can't talk about client work directly.)

Where it's genuinely been useful

Getting oriented in a codebase we didn't write. This is probably the single biggest thing for us, and it's the one product-company blogs never mention because they don't need it — they already know their code. When we inherit something, instead of a few days of grepping around and pinging whoever's still available, someone just asks the agent to walk the auth flow, or trace a request end to end, or point out what depends on what. Turns days into hours. New people on a project benefit the most.

Boring, well-defined work. Scaffolding, API clients, migration scripts, test setup — the stuff where the spec is clear and there isn't much room to go wrong. This is where it's been an actual, measurable time saver, especially on fixed-bid work where those hours used to just get eaten.

Making legacy code safe to touch. A lot of our work is modernizing something old, and the classic problem is that the person who understood it left in 2018 and there are no tests. What's worked for us is flipping the order: before changing anything, get the agent to generate documentation, map dependencies, write characterization tests — pin down what the thing actually does now. Then modernize.

We learned this the hard way. Early on we let an agent loose on legacy code with no tests and it "finished" tasks that quietly broke stuff nobody had written down anywhere. Turns out agents need feedback loops just as much as people do — no tests, no linter, no CI, and you're flying blind either way.

Not dreading the stack switch. Consultants jump languages a lot. A senior engineer who's sharp in Kotlin but a bit rusty in Python used to eat a real productivity hit switching between projects. That's mostly gone now — the judgment still has to be yours, but the syntax fumbling doesn't slow you down the way it used to.

Leaving the agent's context behind as part of the handover. Small thing, but we've started treating the CLAUDE.md file we build up during a project as part of what we hand the client — not just the code, but the accumulated "here's how this thing works and here's how to talk to an agent about it." Cheap to do, and it seems to actually matter.

Where it hasn't

Anything ambiguous. Agents will confidently build the wrong thing just as fast as they'd build the right one — faster, actually, since there's no hesitation. Client requirements are frequently half-implicit or a little political, and that doesn't magically resolve because you're delegating to an agent instead of a junior. If anything, figuring out what someone actually meant has gotten more important, not less.

Estimating anything. We thought this would get easier. It got worse. Some tasks that used to take three days now take three hours, which is great. Other tasks that look identical on paper still take three days because the agent gets stuck in a loop and someone has to go untangle it. Averaged out we're probably faster, but "probably faster on average" doesn't help much when you quoted a fixed-bid project based on the good days. We're still figuring out how to price around this.

Review, mostly. The work didn't go away, it just moved. Someone can now produce a lot of code that looks fine at a glance, and actually checking it carefully takes real effort from a senior person. For a while our throughput barely improved even though generation got way faster, because review quietly became the bottleneck. What's helped: keeping PRs small on purpose, having the agent write PR descriptions that explain the why, and an actual checklist for reviewing agent-written code instead of assuming it's fine because it compiles.

Client trust, sometimes literally can't. Some clients are not okay with an AI tool reading their codebase, full stop, and some contracts rule it out. Nobody writing from inside a product company has to think about this, but it comes up on real projects, and now it's a day-one question for us: are we even allowed to use this here?

The junior engineer problem, which we don't have a clean answer to. If a junior can lean on an agent for everything, what happens to how they actually learn? For a consultancy that sells expertise, this isn't a hypothetical. Right now our stance is: agents can produce the code, but you'd better be able to explain every line of it if asked. Whether that's actually enough, ask us again in a couple of years.

Where we've landed, for now

We don't know yet whether clients will eventually want to buy outcomes instead of engineer-hours, or what that does to how this kind of work gets scoped and priced. We don't know where the review bottleneck settles once everyone adjusts. We don't know if "juniors must be able to explain their code" is a good enough guardrail or just something that felt reassuring at the time.

What we've noticed, though, is that the teams getting the most out of Claude Code aren't the ones asking "how much can the agent write." They're asking "what would make this codebase — the tests, the docs, the conventions — a place where an agent doesn't get lost." Which, if you think about it, is the same question as what makes it a place where a person doesn't get lost either. The agent just made it more obvious that the answer mattered.

Header and article images generated with Google Gemini.