Why aren't AI coding tools improving engineering productivity?
AI coding tools usually aren't the problem. Adoption stalls when the tools land in workflows, repositories, and policies that nobody changed to use them. Stalled adoption looks like seats that are assigned but unused, or used heavily without changing how fast work ships. Tool adoption is not the same as value delivered.
Leaders describe it as "usage is uneven," "the pilot worked but it's still a pilot," or "we're busy and nothing ships faster." It shows up as a flattening line in a dashboard, a renewal conversation with no evidence in it, and a Slack thread where the same three people answer everyone's questions. Below, we show how to read the stall in your own data, match it to a root cause, and restart in 30 days.
Which usage patterns signal that AI coding tool adoption has stalled?
Six usage patterns signal a stall. They come from practitioner experience rather than measured studies, so read the pattern before you pick a fix. GitHub Copilot's usage metrics, Claude Code's OpenTelemetry export, and Cursor's analytics dashboard can all show them.
Pattern in your data | What it usually means | First fix to try |
|---|---|---|
A spike in the first weeks, then a steady decline | Engineers tried it, hit a bad result, and stopped | Coached practice on real tickets, not self-serve trials |
A few power users drive most activity | Skills are not spreading; adoption depends on a few people | Pair power users with teams and turn them into internal coaches |
Mostly autocomplete, little chat or agent use | Engineers use AI for typing, not for planning, testing, or refactoring | Teach a spec-first workflow that uses the agent for larger tasks |
High activity, flat delivery metrics | The bottleneck is elsewhere, often review or unclear requirements | Map the value stream and fix the real constraint |
Near-zero usage in certain repos or teams | Legacy, regulated, or undocumented codebases; unclear policy | Prepare repos with context files; clarify what is allowed |
Engineers using personal or unapproved AI tools | Approved tooling or policy does not fit how they work | Close the gap between policy and practice; approve what works safely |
In Atlassian's 2026 State of Developer Experience report, a recent survey of 1,155 developers and 405 engineering leaders, only 17% said their organization has a clearly communicated, actively implemented AI strategy across the software lifecycle, and 49% spend four or more hours a week reviewing AI output and correcting prompts. InfoQ's coverage adds that the share of developers saving ten or more hours a week fell from 68% to 26% in a year, even as 95% reported their organization actively uses AI.
What are the root causes when AI coding tools aren't producing results?
There are five common root causes, and most organizations have more than one.
Workflow mismatch. Tickets lack acceptance criteria, specs do not exist, and code review assumes small hand-written diffs, so engineers revert to old habits.
No real enablement. Engineers got access and a link to the docs. Nobody coached them through the first bad output, which is where careful engineers quietly stop.
No measurement. With no baseline, nobody can show improvement, and the renewal becomes a debate. Counting usage does not fix it: in the Atlassian survey, 41% of developers said they use AI more than necessary because they feel expected to.
Security and policy fear. Engineers unsure what they may expose do nothing, and security teams without a clear policy default to no. The opposite failure stalls adoption too: if the permission model interrupts every step, engineers stop delegating and start supervising. Liatrio Labs' Radar calls this permission friction and notes it rests on one developer's reported experience, so test it in your own pilot.
Codebases that are not AI-ready. Missing documentation, inconsistent conventions, and no context files mean the tool starts every session blind, and trust drops with output quality.
How do you diagnose which cause is stalling your AI rollout?
Run a two-to-four-week diagnostic that combines usage data, delivery data, and conversations with engineers.
Pull usage by team and repository, not org totals, which hide the pattern.
Overlay cycle time, review time, and backlog throughput for the same teams.
Interview power users, occasional users, and non-users about what they tried, what broke, and what they are unsure is allowed.
Ask security and compliance which questions are still open.
Score repository readiness: documentation, conventions, test coverage, and context files.
Map the value stream from idea to production and see where work waits.
Step six is the one teams might skip, and it explains "high activity, flat delivery." If authoring got faster and the review queue didn't move, coaching will not show up in delivery. InfoQ's write-up of the Atlassian survey reports that 65% of developers spend time correcting AI output that missed the original intent.
How do you fix AI coding tools that aren't producing outcomes?
Match the fix to the root cause. More licenses, a different tool, or another reminder email rarely restarts adoption on its own.
Root cause | Fix | Who owns it |
|---|---|---|
Workflow mismatch | Introduce a spec-first workflow; update ticket and pull request standards for AI-assisted work | Engineering leadership and tech leads |
No enablement | Cohort-based, coached practice on real backlog items; build internal coaches | Platform or developer experience, with an enablement partner |
No measurement | Capture a baseline now; track delivery and fluency, not seat activity | Engineering operations |
Security and policy fear | Publish a short, approved AI usage policy; define agent permissions and data rules | Security, with engineering |
Codebase not AI-ready | Add context files, conventions, and documentation; start with the most active repos | Tech leads per repo |
What should engineering leaders do in the next 30 days?
Here is the plan we would hand an engineering leader on Monday morning. It is deliberately small.
Week 1: Look.
Break usage data down by team and repository.
Name a single owner for the restart.
Week 2: Baseline and unblock.
Capture a delivery baseline for the teams you want to restart.
Close the top three open security questions in writing.
Week 3: Prepare.
Add context files and conventions to two or three high-traffic repositories.
Pick one team to restart, ideally one with a real backlog item waiting.
Week 4: Run and measure.
Run one coached cohort or pairing sprint on real backlog work.
Measure the result against the baseline and write down what you would change.
If you would rather not do this alone, Forge is Liatrio's coached, four-week program for the run-and-measure step: cohorts of 8 to 12 engineers spend two weeks on a reference codebase and two weeks on your real backlog.
FAQ
Why is our GitHub Copilot or Claude Code usage so low?
Low usage usually comes from one or more of five causes: workflows that weren't updated for AI-assisted work, no coached enablement, no baseline measurement, unclear security policy, or codebases without documentation and context files. Breaking usage data down by team and repository shows which cause applies.
How do we get engineers to use AI coding assistants every day?
Show engineers a working AI workflow on a codebase like theirs, coach them through real tickets, prepare repositories with context files, and publish a clear usage policy. Daily use follows early wins on real work, not mandates.
How do we prove ROI on AI coding tools that are already deployed?
Capture a delivery baseline now, even mid-rollout. Compare teams over time on cycle time, review time, backlog throughput, and change failure rate, alongside before-and-after AI fluency. Measure accepted outcomes, not seat counts or dashboard activity.
How long does it take to restart a stalled AI coding tool rollout?
A focused diagnostic takes two to four weeks. A coached cohort can then show measurable change on real backlog work within about four weeks, and that cohort becomes the template for the next teams.
Find where your AI rollout is actually stuck
If your dashboards show early spikes, power-user concentration, or busy usage with flat delivery, the fix starts with finding the real constraint. Liatrio offers a complimentary value stream mapping session to show where work waits. Claim a free VSM session.
