Your developers got faster. Your team didn't.
Most deep-tech R&D groups that rolled out AI coding tools see the same pattern. Individuals finish tickets faster. Diffs appear sooner. Personal velocity looks healthier than a year ago.
What often does not move is the team's delivery rate. Work still queues for review. Integration still surprises people. Tests still catch what a model guessed wrong. Quiet rework still follows a confident but incorrect change.
That is not a failure of prompting. It is a systems problem. Authoring got cheaper. Verification, integration, and merge capacity did not scale with it. Until those catch up, personal speed does not turn into team throughput.
A2X works with Israeli deep-tech R&D teams—algorithmic code, computer vision, embedded and physical-systems software—on the methods that make AI stick. This guide is the longer argument behind that claim. For how an engagement is shaped, see the home page.
Why verification becomes the bottleneck
AI coding tools raise the volume and size of change. More pull requests. Larger diffs. Less shared context about how a change was produced. Human review capacity does not grow at the same rate.
When that happens, teams usually land in one of three places:
Review depth falls. The queue clears by lowering the bar—rubber stamps, thin comments, large diffs approved in a single pass. Throughput looks fine for a quarter. Defects show up later.
Review depth holds. Reviewers keep their standards and the queue backs up. Cycle time stays flat. Engineers spend their new capacity waiting. Individual output rose; nothing reached production faster.
Verification is redesigned. Specs and risk tiers come before large diffs. Automation absorbs mechanical checks. Humans spend judgment where it matters. This is the only branch where organizational throughput can rise without buying it with a lower quality bar.
Cheap authoring without a matching verification design produces a busier dashboard and a flat release calendar.
What public evidence suggests
Public research and telemetry from 2025–2026 point in the same direction. Treat these as pattern recognition, then measure your own systems.
Faros AI telemetry. In July 2025, Faros reported that across more than 10,000 developers on 1,255 teams, tasks and pull requests per developer rose sharply while PR review time and PR size also rose—and company-level throughput showed no significant correlation with AI adoption (The AI Productivity Paradox, Faros AI, 2025). In April 2026, Faros's follow-up across 22,000 developers and more than 4,000 teams (The AI Engineering Report 2026: The Acceleration Whiplash) reported higher bugs per developer, a much higher ratio of incidents to merged pull requests, much longer median time in review, and a rise in pull requests merged with no review at all.
DORA's framing. DORA's 2026 ROI of AI-assisted Software Development report names two mechanisms leaders keep misreading: a J-curve, where delivery performance can dip before complementary investments pay off, and a verification tax—the review and validation cost that cheap authoring shifts onto humans. As individuals generate code faster, downstream testing and change approvals become bottlenecks unless they are actively scaled.
METR's randomized trial. METR's early-2025 study of experienced open-source developers working on their own repositories found that when AI tools were allowed, developers took about 19% longer to complete issues than without AI. Before the study they expected to be faster; afterward many still believed they had been faster (METR, July 2025). The useful takeaway for leaders is narrower than the headline: perceived speed and measured speed can diverge, so self-report alone is a weak dashboard.
If pull requests per developer are up while deployments, cycle time, or change-failure trends are flat or worse, you have a verification problem, not a prompting problem.
Why deep-tech feels this harder
Generic web and SaaS workflows often have cheap oracles: a green CI, a snapshot test, a staging click-through. Algorithm, computer-vision, and embedded teams usually do not.
Harder oracles. Correctness may mean numerical tolerance, statistical behavior on a golden dataset, or equivalence to a research prototype—not a binary unit test. A model that looks right in a diff can still be wrong in the regime that matters.
Hardware in the loop. Firmware and physical-systems software need benches, sensors, and timing that do not scale with chat. AI can draft drivers quickly; proving them on hardware still takes calendar time and scarce setups.
Longer feedback loops. CV pipelines, simulation, and long-running experiments stretch the distance between "code written" and "behavior trusted." When AI multiplies draft volume into that loop, the queue grows where humans and labs were already scarce.
Implicit requirements. Deep-tech codebases carry conventions, numerical libraries, and safety margins a generic assistant does not know. Plausible code that violates those norms is expensive to catch late.
That is why tool training alone rarely moves team throughput here. The bottleneck was never typing speed. It was how the team specifies intent and proves correctness.
For how checkable specs help, see Spec-driven development for algorithm, CV and embedded teams.
What changes when the method catches up
The fix is not a better prompt library. It is a persistent method on both sides of the work.
On the human side: how specs are written before large diffs exist; how review is tiered by risk; which habits survive a busy week; what "done" means when AI drafted half the change.
On the systems side: where automation and autonomy belong so verification does not depend on heroics—baseline checks before human eyes, tests that encode tolerances and golden outputs, merge policies that keep review capacity honest.
Then the method is tuned against how the team already ships. If they already run a form of spec-driven development, that becomes the backbone. If they prefer another process, the method is built around that preference instead of a packaged playbook.
The goal is a way of working that still works when AI is in the loop every day—not a workshop that fades after the slides close.
What not to do
Tool training alone. Teaching Cursor, Copilot, or Claude Code features raises individual fluency. It does not redesign review, tests, or integration. Training can sit inside a transformation; it is not the transformation.
Measuring acceptance rate as success. Suggestion-accept rates and AI-authored line counts can rise while quality falls. Prefer cycle time to production, review latency relative to change size, change-failure or escaped-defect trends, and rework—against a baseline you actually measured.
Imposing a foreign process. Deep-tech teams already have a stack, a review culture, and often a preferred way to write specs. Fit the method to the work.
Scaling authoring before verification. Doubling PR volume into an unchanged review and test design buys a dashboard, not a gain.
Skipping the baseline. A number without a pre-AI (or pre-expansion) baseline is a story. If you do not have one, say so and start measuring now.
Talk it through
If this pattern matches what you see—individuals faster, team flat, review and verification under load—the next step is a conversation, not another tool pilot.
Book a call and we will talk through where AI is already helping, where verification is stuck, and whether an A2X engagement is the right shape. Engagements start with a short diagnostic as phase one of the work, then implementation with the team. Fit comes first.
Also worth reading: Spec-driven development for algorithm, CV and embedded teams.