AI coding assistants have gone from curiosity to daily habit for most of the team over the past few months. After a full quarter of real usage across several client and internal projects, we wanted an honest accounting of where they've actually changed how we work, rather than repeating the general industry narrative back at ourselves.
Where the speedup is real
Boilerplate-heavy work, test scaffolding, repetitive CRUD endpoints, type definitions generated from existing data shapes, has genuinely sped up, often by a large margin. One developer tracked their own time on a week of routine API endpoint work and estimated roughly a third less time spent on the mechanical parts of the task, writing the request validation, the error responses, the basic test cases, freeing up more time for the actual business logic decisions that the assistant can't make for you.
- Suggestions on unfamiliar library APIs save real time looking things up, though they're wrong often enough, an outdated method signature, a parameter that doesn't exist in the version we're actually using, that nobody on the team treats them as authoritative without verifying against the actual docs.
- Writing test cases for edge conditions we might not have thought to cover ourselves has been a quiet but consistent win; the assistant is decent at generating a first pass of boundary cases even when the happy-path logic is entirely custom.
Where it hasn't moved the needle
Code review load hasn't dropped, if anything, reviewers report reading AI-suggested code more carefully than hand-written code from a trusted teammate, since the failure modes are different. A human teammate's mistakes tend to be logical, they misunderstood a requirement. An assistant's mistakes tend to be plausible-looking but subtly wrong, correct syntax wrapped around an incorrect assumption about how a library or API behaves. That difference means reviewers can't pattern-match on "this looks like code so-and-so would write" the way they do with human contributions, and have to actually trace the logic every time.
- Architectural decisions, how a feature should be structured, what the data model should look like, are still entirely a human judgment call, and we haven't found the current generation of tools useful for that layer of thinking beyond acting as a sounding board.
- Debugging genuinely novel bugs, the kind that come from an unusual interaction between two systems rather than a typo or a missing null check, is still slower with an assistant in the loop than without one, mostly because it confidently suggests fixes for the wrong root cause often enough that it costs more time than it saves.
The learning curve effect
The clearest and most consistent win has been on the learning curve for less familiar frameworks and languages. Junior developers on the team report feeling less stuck when an assistant can suggest a plausible next step, even an imperfect one, rather than staring at a blank file or spending twenty minutes searching documentation for the right method name. One junior developer picking up a Rust side task for the first time described the experience as having "a slightly unreliable senior dev looking over my shoulder," which is about as accurate a description as we've heard.
There's a real risk buried in that convenience, though. A couple of code reviews this quarter caught junior developers accepting a suggestion they couldn't fully explain when asked about it directly. We've started treating "can you explain why this works" as a standard review question specifically for AI-assisted pull requests from newer team members, not to be punitive, but because understanding the code you ship is still the actual job, and it's an easy habit to lose when a plausible answer is one tab-complete away.
Process changes we've actually made
We haven't relaxed anything about our review process; if anything, it's gotten slightly more deliberate. A few concrete changes stuck:
- We ask contributors to flag in the pull request description which parts of a change were substantially AI-suggested, not to shame anyone, but so reviewers know where to apply extra scrutiny.
- We've stopped treating assistant suggestions as a source of truth for anything touching authentication, payments, or data deletion logic; those categories get written and reviewed the old way, full stop.
- Licensing and provenance questions came up twice this quarter around suggested code that resembled snippets from public repositories closely enough to raise an eyebrow. We don't have a perfect policy yet, but we now ask developers to treat any suggestion that looks like it could be a verbatim lift from a specific open-source project with the same scrutiny as a direct copy-paste, and check accordingly.
Where this leaves us
The tools are useful enough now that we don't expect the team to go back to writing everything unassisted, the productivity gains on boilerplate and unfamiliar-API lookups are too consistent to ignore. They're not yet a substitute for understanding the code you ship, and our review process has adjusted to that reality rather than relaxed around it. If anything, a quarter of real usage has made us more precise about which categories of work we trust to an assistant and which ones stay fully human, rather than less careful across the board.
Measuring it, imperfectly
We tried, with mixed success, to put actual numbers on the productivity claim rather than relying on team sentiment alone. Pull request cycle time, from opened to merged, dropped modestly across the quarter, but attributing that cleanly to AI assistance versus a dozen other variables, a smaller backlog that quarter, a couple of process tweaks unrelated to tooling, proved harder than we expected. The more reliable signal came from developers' own time logs on comparable, previously-estimated tasks, which is where the boilerplate-heavy speedup showed up most consistently and credibly.
- Bug rates in AI-assisted pull requests versus fully hand-written ones showed no statistically meaningful difference across the sample size we had, which surprised a few skeptics on the team who expected AI-suggested code to introduce more defects than it prevented.
- Time-to-first-review, how long a pull request sat before a human looked at it, didn't change, which reinforced our earlier point that the review bottleneck was never about writing speed in the first place.
Team sentiment, section by section
Feedback wasn't uniform across roles. Backend developers working mostly in well-trodden, conventional patterns, REST endpoints, standard database queries, reported the highest satisfaction, since that's exactly the kind of code an assistant trained on a huge volume of similar examples predicts well. Frontend developers working on more bespoke, design-driven UI reported a lower hit rate on useful suggestions, since there's less common precedent for a highly specific visual interaction pattern than for a CRUD endpoint. That split matches what we'd expect given how these tools are trained, but it's worth stating plainly rather than letting a single team-wide satisfaction number paper over the difference.
What we'd tell a team just starting out
Start with the boring, high-volume work, tests, types, repetitive endpoints, since that's where the payoff is clearest and the risk of a subtly wrong suggestion is lowest and easiest to catch in review. Treat anything touching security or novel architecture as fully human territory from day one rather than discovering the boundary through an incident. And build the "explain why this works" review habit early, before junior developers on the team form the opposite habit of accepting plausible-looking suggestions without fully tracing them, since that's a much harder habit to unlearn than it is to never form in the first place.
A note on tool selection
We didn't standardize on a single assistant across the whole team this quarter, partly by accident and partly because different developers had different existing preferences going in. In hindsight, that inconsistency made it harder to draw clean conclusions, since tool quality varies enough between products that some of what looked like individual variation in reported usefulness was really a difference in which specific tool a given developer happened to be using. We're planning to standardize on one primary tool next quarter specifically to make future internal measurement cleaner, while still allowing individual exceptions where a developer has a strong, demonstrated reason to prefer an alternative.
A parting caveat on generalizing this
It's worth being honest that a single quarter, on a handful of projects, at one company, is a thin basis for sweeping conclusions, and we're treating this writeup as an honest snapshot rather than a definitive verdict on AI pair programming generally. Tool capability is moving quickly enough that some of what we found frustrating this quarter may simply be solved in the next model update, and some of what worked well may not hold up on a different kind of codebase than the ones we tested it against.