Aleks Volochnev
February 06, 2026
10 min read
February 06, 2026
10 min read
Share
Cut code review time & bugs by 50%
Most installed AI app on GitHub and GitLab
Free 14-day trial
A decade ago I led a DevOps transformation in a German company: clouds, containers, a lot of automation. I thought tooling would be the hardest part of the transition: little did I know. Neither Kubernetes configs nor CI/CD pipelines were the hard part, getting people to believe in the change and accept new processes were. We cut time-to-market from months to weeks and saved millions by moving from manual to automated testing, but only after winning hearts and minds.
AI adoption is the same story, different decade.
Every week, I talk to teams who bought Google or Claude subscriptions expecting magic. What they got was a glitchy autocomplete and a lot of confusing results. The gap between "we have AI tools" and "we ship better software faster because of AI" is wider than vendors want you to believe.
I've collected the pitfalls people forget to consider or completely misunderstand when adopting AI-assisted development. If you're planning to make the jump or have tried and weren't excited with the results, this is for you.
There's no magic button: every process change requires understanding and planning. Consider this a playbook born from many failures (and some tears).
You can buy a Formula 1 racing car, but putting your Uber driver behind the wheel without track training won't get you to the office, more likely, to the hospital.
The problem: Using AI looks simple. Just chat with the bot until it’s done, right? This simplicity is very deceptive! Prompting is a skill and bad prompts produce bad output, no matter how expensive your fancy Opus 4.5 is. Knowing how to use AI (and when not to use it at all) is expertise that takes time to develop. Without it, you're paying for a car nobody knows how to drive.
Quick diagnostic: Ask your engineers: "What's the system prompt? Context poisoning?" If you get blank stares, you have a skill gap. Understanding context engineering is the key to getting real value from AI tools and most developers haven't been taught it. There are still plenty of people who do not understand the difference between an agent and the LLM model it uses under the hood!
What helps
Start with a brief skill assessment. Who's already using AI tools effectively? These people will be invaluable in this journey!
Dedicate actual learning time and host or run a course. "Figure it out on your own," isn't a training program.
Let early adopters lead. Peer recommendations beat external trainers every time. Internal lunch-and-learns work better than vendor webinars (and cost less!)
Team up early adopters with AI novices. Pair programming sessions where experienced users tackle real problems on your own project - nothing can beat that.
"Yesterday we bought XYZ for everyone. Use it, you ungrateful creatures."
The problem: Management picks a tool based on marketing demos, mandates it overnight. No evaluation against the team's actual workflow. Developers feel unheard. The tool might not fit the stack, the workflow, or individual preferences. Resistance grows among the team and now the pushback is about autonomy, not the tool itself. In these cases, adoption fails, the budget gets wasted, the team is annoyed.
To make matters worse, the landscape is indeed confusing. There are full AI-native IDEs (Cursor, Windsurf), extensions for existing IDEs (Roo Code, GitHub Copilot, Cline), provider-locked versus provider-agnostic options, subscription-based versus consumption-based, chat interfaces versus inline completion versus agentic workflows. No single "best" choice exists. If you want me to tell you "just use X and Y" - my apologies but I won’t do that. I'm not here to sell you some agents. It's a decision you need to make together with your team.
Quick diagnostic: Run an anonymous poll: are developers satisfied with AI tooling? Did they have a voice in AI tool selection? "Enterprise decided for us" doesn't drive adoption.
What helps
Ask what your team is already using. Some certainly are already deep into AI adoption either for your projects or their hobby projects.
Run lightning demos where team members show different tools for 5 minutes each.
Invest time in tool selection. Make sure to show and demo options and let the team have a real voice.
Accept that the "best" solution depends on stack, workflow, budget, and personal preference.
AI is like an overly confident intern: sounds right, might be deadly wrong.
The problem: AI-generated code often looks correct and passes superficial reviews. Our own data shows AI-generated code has 1.7x more bugs than human-written code. Subtle issues like security holes, performance problems, and edge cases can be there and will be there, but verifying someone else's code is cognitively hard, and the more code AI produces, the worse this gets. So, people tend to skip verification completely or do it too shallowly. "It looks very solid, so it's probably fine" becomes the default, and many programmers tend to push to upstream without proper validation. I explain it in detail in my recent post about how it's harder to read code than to write it.
The story with bugs: The earlier you catch them, the cheaper they are to fix. Something comes up while already working on a ticket? A developer is already on the task, with (hopefully) a clear understanding of the requirements, the context, and more. Here, it's a minute to make it right. Let this get through to the pull request, or even worse, to production, and fixing can cost you hours or days of debugging, not to mention unhappy customers. Try to catch potential issues before they reach a formal pull request review, since it's cheaper and faster. Pre-commit review is also a highly underestimated part of modern AI-assisted development and many devs don't realize how much it would save their teams. Subscribe, since I'll talk much more about it in future posts!
Quick diagnostic: Blind trust shows up in one of two ways. Look at your incident reports and your PR metrics side by side. More production bugs recently while AI usage went up? That's blind trust sneaking through. Alternatively, if production is stable but your average "reviewer requested changes" shot through the roof and time-to-merge doubled, congrats, your reviewers are catching the AI-generated mess (but they're drowning in it).
What helps
Devs can't just "write and push" anymore. Whatever AI wrote is to be thoroughly reviewed - as early as possible.
Treat pre-commit review as standard practice and incorporate it into the training program and the overall working culture.
Run automated checks, but not just with linters. Let AI review what another AI wrote. We have a great tool with a generous free plan!
Build a culture of healthy skepticism (not paranoia). The goal isn't to distrust AI, it's to verify before you trust.
More cars on the highway, and everyone's trying to exit through the same single-lane ramp.
The problem: Individual developer velocity goes up when you adopt AI coding tools. But that also means PRs pile up waiting for review. Reviewers, then, become the constraint. AI makes it easy to write more code and larger PRs mean harder reviews. The harder reviews, in order, mean either a slower shipping pace or production incidents, or both.
Quick diagnostic: Check your PR metrics: has average time-to-review increased in the last 3 months while code volume doubled? That's a bottleneck. Or did time-to-review stay the same despite more code? That might be even worse, because fast shallow reviews lead to production incidents. You want fast and thorough.
What helps
Automated first-pass AI reviews with immediate feedback.
Fast feedback means the code author still has context; slow human review hours or days later means they've already forgotten half the details.
Authors address automated feedback before a dedicated human reviewer even sees the PR.
Human reviewers focus on architecture, logic, and business context, as well as other things that require judgment.
Faster feedback loops lead to faster merges.
NOTE: AI reviews save significant time and speed up delivery, but they can't and won't replace proper human reviews!
AI without context is like a creative contractor without blueprints. It definitely will build something... Most likely not what you needed.
The problem: AI tools are only as good as the context they receive. Human developers recover missing context naturally. They get it from things like Slack huddles, coffee machine conversations, and hallway chats. AI can't do that, but instead, it will confidently "invent" the missing parts, and you don't want that.
Disconnected tools mean lost context at every handoff. Tribal knowledge (the stuff everyone knows but nobody wrote down) never makes it into an AI’s context.
Quick diagnostic: Open your last five issues. Do they have acceptance criteria and clear problem statements, or just "fix the bug" and a link that expired three months ago? Check your documentation: when's the last time anyone updated the architecture docs? If the README still mentions the framework you migrated away from two years ago, AI tools are navigating using 17th century maps.
What helps
Well-written issues with acceptance criteria help make good prompts.
Linked issues in PRs, so context flows through to the AI is also key. Then, AI reviews can validate not only code but also that the code meets requirements and acceptance criteria
Codebase documentation that AI can actually access and reference.
Team knowledge captured in an accessible form, not just in people's heads.
"Someone's getting fired after this transition."
The problem: Fear and resistance, sometimes explicit, often passive. Junior devs worry about job security and tend to over-rely on AI. Senior devs feel their expertise is devalued and often resist (a common comment you’ll find here is, "I'm faster without it"). AI won't replace developers, but developers are scared management still thinks it will and you won't get great results until your team sincerely supports the change, instead of quietly resisting it.
Frederick the Great said soldiers should fear their officers more than the enemy. That might work well for 18th-century infantry charges, but it's a terrible model for modern software teams. Fear kills experimentation, hides problems, and drives your best people to update their LinkedIn. You're not running a Prussian army, so don't manage like you are.
Quick diagnostic: The best approach is to lead bottom-up. Let the team own the initiative, run experiments (some will fail, that's fine), and iterate until you hit something that works. If you hire smart people, there is no need to dictate to them and, if you don't, AI won't help you.
What helps
Clearly frame AI as an amplifier, not a replacement.
Let early adopters demonstrate value to peers. It's more credible than management saying, "just trust us."
Celebrate what humans do better: judgment, creativity, and understanding are good examples. They are also what the business actually needs.
Involve the team in tool selection and workflow design.
Skeptics often have valid concerns worth addressing. Listen to them.
These challenges don't exist in isolation. Training gaps lead to blind trust. Top-down mandates create people problems, making the team resist change. Context starvation makes review bottlenecks worse.
Start where it hurts most. For most teams, that's either the skill gap, the blind trust problem (bugs slipping through) or the review bottleneck (PRs piling up).
Each of these challenges deserves deeper treatment. We'll dig into pre-commit and pull request review automation strategies and change management in future posts. For now, the key insight is the same one I learned a decade ago: the tools are actually the easy part. The habits, the culture, the workflows - that's where transformations actually happen.
Got thoughts on this? Tell me! Have your own AI adoption stories, shiny wins, or spectacular failures? Hit me up! I read and respond to everything. Best insights come from readers who push back or share their own disasters.
Want to see automated code review in action? Check out how different projects like Langflow and Clerk use CodeRabbit to catch issues before they reach human reviewers.
