I've been championing Claude and AI tooling adoption at Amiqus for a while now. We're a small engineering team, which means every efficiency gain matters — but also that every distraction costs more than it would at a larger org. Here's what I've learned about making AI adoption actually work.
Start with where time actually goes
The first mistake most teams make is picking a tool and then looking for problems to solve with it. That's backwards. Start by mapping where engineering time goes — not where you think it goes, but where it actually goes. Track a week, honestly.
At most small teams I've worked with, the answer is roughly: a third on building, a third on reviewing and communicating, and a third on everything else (debugging, context switching, meetings, writing docs nobody reads). AI tooling is most powerful in that middle and last third — the work that's important but not the core of what engineers were hired to do.
Pick one workflow and go deep
Resist the urge to adopt five tools at once. The compounding cost of context switching between new tools, and the cognitive load of deciding which tool to use for what, will erase any efficiency gains before you've even measured them.
Pick the single highest-value workflow and go deep on it. For most teams, that's either code review assistance, documentation generation, or internal knowledge retrieval. Do that one thing well for six weeks before expanding.
At Amiqus, we started with code-adjacent writing — pull request descriptions, internal documentation, meeting summaries. Low risk, immediate value, and it gave the team time to build intuition about what AI is good at before using it on higher-stakes work.
The team has to trust it before they'll use it
This is the most underestimated challenge. You can mandate tools all you like — engineers will use them performatively and then ignore them if they don't genuinely believe they help.
Trust comes from early wins that engineers experience themselves, not from you telling them the tool is great. Set up a low-friction way for people to try it on real work they care about. Share examples of where it helped you. Be honest when it doesn't help.
The engineers who become advocates are the ones who had an experience where the tool saved them an hour. Create the conditions for that experience to happen and then get out of the way.
Governance that doesn't slow you down
Small teams don't need a full AI governance framework — that's overkill. But you do need to answer three questions before you roll anything out:
What goes into the model? Understand what data your team is sending to external APIs. Most LLM providers have reasonable data processing agreements, but you need to know what's in scope. Code, internal docs, customer data — treat each category differently.
Who reviews the output? AI-generated code, documentation, and summaries should have a human in the loop for anything customer-facing or security-relevant. Build that expectation in from the start, not as an afterthought.
How do you know if it's working? Set a simple metric. Time saved per week, PR cycle time, documentation coverage. You don't need a perfect measurement — you need a signal that tells you whether to invest more or change approach.
What I'd do differently
If I were starting from scratch, I'd involve the team in tool selection rather than arriving with a decision made. The engineers who have a say in which tools they use are the ones who actually use them. I'd also budget more time for experimentation upfront — the first few weeks of AI adoption are inevitably slower than the weeks that follow, and it's worth planning for that.
The teams that get the most from AI tooling aren't the ones who adopt the most tools — they're the ones who build the best habits around a small number of well-chosen ones.