TL;DR: We didn't set out to run an experiment — AI agents just kept eating more of our sprint over six months until they were writing roughly half our code. Velocity went up. So did a specific, predictable category of bugs: confident-looking code that was subtly wrong in ways our old review process wasn't built to catch. The fix wasn't "use AI less." It was rebuilding how we review, not whether we accept AI-written code.
The number that started this post
Industry-wide, GitHub's own research puts AI-assisted code at roughly 46% of what active Copilot users ship, and Google and Microsoft have both put their internal AI-generated code share in the 20-30% range on earnings calls. Our number landed higher than that once we moved from autocomplete-style suggestions to actual agentic workflows — tools that plan a task, write across multiple files, run tests, and open a PR with minimal hand-holding.
Six months in, that's close to half of merged lines on a typical sprint. This post is what we learned getting there, written the way I wish someone had written it for us before we started.
What genuinely got better
Being fair first, because most "we tried AI agents" posts on here skew either breathless or bitter, and neither is useful to you.
- Boilerplate and scaffolding basically disappeared as a time cost. New CRUD endpoints, test fixtures, migration files, repetitive config — the stuff nobody wants to write anyway got handled in minutes instead of an afternoon.
- First-draft test coverage went up, not down. Agents are relentless about writing the unhappy-path test you'd skip when you're tired. Coverage numbers improved even before we changed anything else.
- Onboarding a new engineer to an unfamiliar part of the codebase got faster, because they could ask an agent to explain and then verify the explanation against the actual code, instead of cornering a senior dev.
- Time-to-first-PR on small, well-scoped tickets dropped noticeably. Nothing dramatic on complex work, but on the "add this field and thread it through" tickets, it was a real, repeatable speedup.
None of this is controversial anymore. If your team isn't seeing at least some of this, the gap is usually task selection or prompting discipline, not the tools.
What actually broke, and it wasn't what we expected
We braced for the agent to write bad code. That's not really what happened. What happened was worse to catch, because it looked right.
1. Code that passed review because it read fluently, not because it was correct.
AI-generated code has a specific texture — clean naming, consistent style, plausible-looking logic — that triggers the same "this looks fine" pattern-match reviewers use for competent human code. We started seeing subtly wrong edge-case handling slip through specifically because it didn't trigger the usual "something looks off here" instinct. GitClear's analysis of over 200 million lines of code found code churn (changes reverted or rewritten within two weeks) climbing sharply alongside AI adoption industry-wide, and that matched what we saw internally almost exactly.
2. A quiet decline in refactoring.
When an agent can regenerate a working version of something in minutes, the incentive to actually clean up the underlying structure drops. We caught ourselves accumulating duplicated logic across files that a human, writing it by hand, would have naturally consolidated into one function out of sheer annoyance. The agent doesn't get annoyed.
3. Security review became a real, not theoretical, line item.
This is the one I'd flag hardest to anyone reading this before scaling agent use. Independent analysis of AI-coauthored pull requests has found meaningfully elevated vulnerability rates compared to human-only PRs, and we don't think our team is a special case — we think most teams haven't looked closely enough yet to notice. We now treat "did an agent touch this file" as a routine flag in our security review, the same way we'd flag a file touching auth or payments.
4. Debugging shifted from "why is this broken" to "why did it do this."
When a human writes bad code, you can usually trace their reasoning. When an agent produces something wrong, the reasoning it reports and the reasoning that actually produced the output aren't always the same thing. That's a genuinely different debugging skill than most of us were trained on, and it took real time to build.
What we changed, concretely
- PRs get labeled by how much of the diff is agent-generated, not as a gotcha, but because it changes what kind of review the PR needs.
- Anything touching auth, payments, or external data boundaries gets a second human reviewer if an agent wrote a meaningful share of it — no exceptions, regardless of how confident the code looks.
- We stopped measuring "lines shipped per week" as a success metric. It was quietly rewarding accepting more agent output with less scrutiny, which is exactly the wrong incentive.
- Refactoring got a protected time slot instead of being opportunistic, because opportunistic refactoring mostly stopped happening on its own.
Where this leaves us
We're not walking any of it back. The productivity case is real and we're not interested in performative AI-skepticism for its own sake. But "AI writes our code now" turned out to be the easy part. The actual work was rebuilding review, security screening, and code-health habits around a contributor that writes fast, writes confidently, and doesn't get tired or embarrassed — which, it turns out, were exactly the human traits our old review process was quietly relying on.
I run engineering at 6senseHQ, where this is now just how we build for clients — agent-assisted, human-owned, reviewed like it matters, because it does.
FAQ
Does using AI coding agents actually make delivery faster?
Yes, on well-scoped, boilerplate-heavy work, meaningfully so. On complex or ambiguous work the gain shrinks and sometimes disappears, because the bottleneck shifts to review and verification instead of typing.
Is AI-generated code less secure by default?
Independent research on AI-coauthored pull requests points to higher vulnerability rates than human-only PRs, though the gap narrows significantly with deliberate review practices tailored to agent output specifically.
What's the single highest-leverage process change for a team adopting AI agents?
Stop reviewing agent-written code the same way you review human-written code. The failure modes are different, and a review process tuned to catch human mistakes will systematically miss the ones agents make.
If you're vetting a dev team on their AI-assisted practices, ask them what broke — not what got faster. Anyone can tell you about the speed gains. The teams worth hiring can tell you specifically what they changed in review because of what went wrong.
Top comments (1)
"Clean naming, consistent style, plausible logic triggers the same 'this looks fine' pattern-match reviewers use for competent human code." That's the sharpest description I've seen of the exact trap, and it's the one I spend most of my time defending against as a non-engineer who builds with AI. Broken code I can catch — it errors. The fluent-but-wrong version sails past me precisely because it looks like the competent code I was hoping for.
Your fix being "rebuild how we review, not whether we accept" is the part I wish more people led with. I landed on the low-budget version of your agent-percentage labels: any change to auth, or anything that touches real patient-facing behavior in my tools, doesn't get to close on "it looks right" — it has to close on a check that ran and passed. The reviewer's "this looks fine" and the system's "this actually works" come from different places, and AI-written code is exactly where those two quietly diverge.
"Ask them what broke, not what got faster" is going in my notebook as both a hiring filter and a self-audit. Fluency is what got faster; the whole discipline is refusing to let fluency stand in for correctness. Great retrospective — the kind that's honest about the wins and still names the wreckage.