There’s a moment in every team’s adoption of agentic coding where the tooling stops being the interesting part. The models are good. The integrations work. And yet the thing that determines whether your team comes out the other side faster, or just busier, has almost nothing to do with the agent itself. It has to do with how you lead people through the change.
Around December 2025, our team of five took on a challenge that would have been daunting in any era: rewriting our legacy JSP-and-JavaScript UI into a modern, component-driven Angular application. And this wasn’t a thin prototype we were porting. The legacy UI had eighteen months of feature additions packed into its belly, all of which had to find a home in the new Angular world. To make it more interesting, I was leading that effort with very little UI development experience of my own.
And the UI rewrite was only half of it. As a pilot for the whole team, we were simultaneously bringing agentic coding into our backend work too, since my role demanded I operate as a full-stack developer rather than stay in one lane. Agentic coding wasn’t a nice-to-have for us. It was the thing that made all of this plausible at all. What follows is what actually mattered over those months, not the marketing version, but the parts that were genuinely hard and genuinely worth it.
The velocity is real, and that’s the easy part to believe
Let’s get the obvious thing out of the way: agentic coding increases your team’s velocity. This isn’t a maybe. When an engineer can hand off a well-scoped change, a test harness, a refactor across thirty files, a first pass at coding up a UI screen from a mockup, and get back something that’s eighty percent of the way there in minutes instead of hours, the throughput of the whole team shifts.
But I’d caution anyone reading this not to treat velocity as the headline. It’s the most quotable benefit and the least interesting one. Velocity is what you get if everything else goes right. The rest of this post is about everything else.
Small teams need the right guidance, not more of it
Big organizations adopting agentic coding can throw a transformation office at the problem, run pilots, publish playbooks, and absorb the false starts across hundreds of engineers. We can’t, and honestly, we shouldn’t want to. A small team’s advantage is that the distance between “we should try this” and “everyone is doing it” is short.
The flip side is that there’s nowhere to hide a bad pattern. If one person adopts a sloppy workflow, it’s a meaningful fraction of the team. On a five-person team, that one person is twenty percent of your engineering, so a single bad habit isn’t a rounding error, it’s a fifth of how the team works. So the guidance has to be right, not voluminous. What worked for us was a handful of clear, opinionated defaults, where the agent fits in the workflow, what it’s trusted to do unsupervised and what always needs a human in the loop, how we review its output, rather than a thick document nobody reads.
We kept it flexible but standardized. The toolset itself was deliberately mixed: we ran Antigravity, Claude, and Codex side by side, choosing among them for cost and convenience depending on the task. What we didn’t leave flexible was the process around the code. Some of the most basic disciplines, the need for unit tests and the rule that tests have to pass before anything gets pushed, simply hadn’t existed in the legacy UI. So rather than relying on each engineer (or each agent) to remember, we instituted it as a team rule and implemented it directly in the repo, so it enforced itself seamlessly no matter which agent happened to be working on the code base. The agents could vary; the guardrails could not.
The jitters are real, and they’re different for everyone
This is the part I underestimated most. I expected resistance to look like skepticism about quality. Sometimes it did. But more often, the friction was quieter and more personal.
The engineers who’d spent years becoming excellent solo contributors had the hardest adjustment, and not for the reason you’d think. They weren’t worried about being replaced. They were suddenly being asked to do something they’d never had to do: manage. Directing an agent is a delegation skill. You have to decompose a problem, hand off a piece of it, evaluate what comes back, and redirect when it goes sideways, all the things a tech lead does with junior engineers, except now every individual contributor is doing it all day. For someone who got good at the craft precisely because they could just do the thing themselves, that’s a real shift in identity, not just in tooling.
Naming this out loud helped. Once people understood that the awkwardness they felt was the awkwardness of learning to lead, not a sign they were bad at the new tools, the tension eased and people adopted reasonably fast.
Prompting is everything, which means articulation is everything
Here’s the uncomfortable truth that surfaced once people got past the jitters: the quality of what you get back is almost entirely a function of how clearly you can say what you want.
Agentic coding is a brutal mirror for fuzzy thinking. If you can’t articulate the constraint, the edge case, the definition of done, the agent will happily produce something confident and wrong. The engineers who thrived weren’t the ones with the deepest algorithmic knowledge. They were the ones who could write down what they actually meant, scope a task precisely, state the assumptions, describe the shape of the answer they wanted.
This turned out to be a teachable skill, and a transferable one. Getting better at prompting made people better at writing tickets, better at code review comments, better at design docs. Articulation isn’t a side effect of this transformation. It’s the core competency it demands.
Process problems don’t disappear. They get amplified.
The last point is the one I’d attach a warning label to. Increased velocity does not fix a broken process. It accelerates it.
If your review process was a bottleneck before, it’s now a worse bottleneck, because there’s more code arriving faster. If your testing was thin, you now ship thin coverage at higher speed. If ownership of a service was ambiguous, that ambiguity now produces conflicting changes twice as often. Every soft spot in how the team works gets pushed harder.
This needs deliberate attention, not optimism. As we sped up, we had to consciously tighten the things around the code, clearer ownership boundaries, review that scaled with volume, guardrails on the paths where a mistake is expensive. The agent made writing code cheap. That made everything else about engineering relatively more important, not less.
A concrete example from our own rewrite: we had never been disciplined about completing the design cycle for the next release’s items before the development cycle started. When dev was the slow part, you could get away with design trailing alongside it. Once the dev cycle compressed, that habit became the bottleneck, the team would race ahead and then stall waiting on screens that hadn’t been thought through yet. This had to change. Thanks to tools like Claude Code initially, and eventually Claude Design, we’ve been able to fold this piece of the process in with far more ease than I expected, and line up our release trains nicely instead of letting design and development fall out of step.
Where we landed
The transformation worked, but not because we adopted the tools. It worked because we treated it as a change in how people work and lead, with the tooling as the occasion rather than the substance. Velocity was the promise. Clear guidance, honest acknowledgment of the personal adjustment, real investment in articulation, and a hard look at our own process, that was the actual work.
If you’re leading a team into this, that’s the part I’d tell you to plan for. The agent will be ready before your team is, and getting your team ready is the whole job.
One last thing, and maybe the most important: we don’t think of this as finished. The AI landscape is still maturing fast, the tools we lean on today may not be the ones we lean on in six months, and the practices that work for us now will keep shifting underneath us. So we treat the whole thing as an ongoing experiment, constantly learning, re-evaluating what’s working, and staying willing to change our minds. My advice to anyone starting this journey is to do the same. Don’t look for a finished playbook to copy, because there isn’t one yet. Build the habit of learning and adapting, and let that, rather than any particular tool, be the thing you commit to.