Rukvik Manvar
Our developers use AI coding assistants daily at this point, and the honest answer to “does it make you faster” is: it depends heavily on what you're doing. It's not the uniform 10x speedup some of the marketing around these tools implies, and treating it that way leads to worse code, not faster delivery.
Where it genuinely helps
Boilerplate is the clearest win — form validation logic, standard CRUD endpoints, test scaffolding, converting a data structure from one format to another. This is code we've written a hundred times before in slightly different shapes, and having it generated in seconds instead of typed out by hand is a real, measurable time save with essentially no downside, because we already know exactly what correct looks like and can verify it at a glance.
It's also genuinely good at explaining unfamiliar code — dropping in a legacy function nobody on the current team wrote and asking what it does, or getting a plain-language summary of an error stack trace before diving into the actual debugging. That's a real productivity gain, especially on client codebases we're picking up mid-project rather than building from scratch.
Where it slows us down instead
Anything involving real architectural judgment is where it falls short, and where trusting it uncritically actively costs time. We've seen AI-suggested solutions that work correctly for the test case in front of them but don't account for how a system needs to scale, or that quietly introduce a security gap because the training data reflects common patterns rather than best practice for this specific context. Catching those requires a developer who already understands the problem well enough not to need the suggestion in the first place — which is exactly the skill junior developers are still building.
We've also noticed a real cost in code review time when a team leans on AI-generated code without close review discipline. Code that looks plausible and passes a quick read-through, but carries a subtle bug, is more expensive to catch in review than code a developer clearly struggled with and flagged themselves. The confidence of the output doesn't correlate with its correctness, and treating it like it does is the actual risk, more than the tool itself.
Our internal rule now is simple: AI-assisted for anything routine and verifiable, human-led for anything architectural or security-sensitive, and every AI-suggested chunk of code gets the same review scrutiny as a junior developer's first pull request, regardless of how confident it looks. That's not a knock on the tools — they've genuinely changed how much boilerplate our team writes by hand. It's just a reminder that “faster” and “correct” aren't the same claim, and conflating them is where teams get burned.
What this means for hiring and training
It's also changed how we think about ramping up junior developers on client projects. Handing a junior developer an AI assistant and expecting them to move at a senior developer's pace is a mistake we made early on and walked back — the judgment gap doesn't close just because the typing gets faster. What's worked better is using the assistant to speed up the boring parts of a junior developer's day, freeing up more of their time for the code review conversations and architecture discussions that actually build the judgment they're missing.
We've also had to get more deliberate about client codebases that contain sensitive business logic or data handling. Not every AI coding tool's terms guarantee that code snippets aren't retained or used for further training, and for client work under NDA, that's not a risk we're willing to take casually. We now vet tooling on a per-client basis for exactly this reason before it touches anything sensitive, rather than assuming every tool's default settings are safe by default.
