Why AI Coding Pilots Stall Before Production

An AI coding agent can write and test code, but a demo does not establish readiness for client work. A pilot needs measured value, acceptable quality, and safe access limits. Business-AI surveys warn about adoption difficulties; they do not directly measure the failure rate of coding-agent projects.

Evaluate model quality and organisational readiness

A Zapier survey of more than 800 senior leaders found 84% of companies had at least one AI pilot that had not reached production. That is a company-level measure, not the share of all pilots that failed.

Project NANDA's business-AI report reported roughly 95% of organisations had not seen measurable financial returns from generative AI. No financial return does not establish whether a system shipped, or whether most coding-agent pilots failed. The populations and measures differ.

Gartner's June 2025 forecast predicted over 40% of agentic-AI projects would be cancelled by the end of 2027 due to costs, unclear value, or inadequate risk controls. This is a forecast, not an observed cancellation rate.

My practical inference: evaluate model quality alongside cost, workflow, security, and business value. Organisational barriers do not demonstrate that agent-generated code is already good enough.

The governance gap, in numbers

Picture a new contractor walking into your office with no badge, no signed contract, and a key to every room. That analogy illustrates uncontrolled access; it does not describe every deployment. Gravitee's State of AI Agent Security Report 2026, based on a survey of 750 senior technology leaders in the UK and US fielded in April 2026, found that only about 19.7% of organizations say all of their production AI agents are fully secured and governed before going live.

Roughly 48% of production agents run unsecured. Only 7.2% of organizations have a named individual with formal accountability for what an agent does. These are respondents’ reports about AI agents generally, not a coding-agent-specific rate or a census of all companies.

Many respondents did not report complete governance for all their agents. This is a reason to check readiness, not proof of a causal link to a separate pilot survey.

Why this hits SMEs harder

Smaller firms often have fewer people to manage access, review code, and monitor security events. The required controls still depend on the data, permitted actions, client contract, and applicable rules.

Not every company needs a SIEM at the outset. It needs reviewable records, accountable people, and a response process. Large companies also need to test integrations rather than assume existing systems make deployment a configuration task.

A consultant can turn those requirements into access limits and test evidence. Managing the engagement itself remains a separate discipline.

What to put in place before an agent touches a repo

Adapt these six checks to the project risk:

1. Named-identity mapping. Link each agent session to a user account or named person responsible. Corporate single sign-on (SSO) can help where it is already available. "The agent did it" isn't an audit answer; "this agent, under this person's session, at this timestamp" is.
2. Secret-scanning gate on every agent pull request. Agents may copy exposed API keys and credentials into proposed changes. Run the scan before merge.
3. Sandboxed execution. The agent runs and tests code somewhere that isn't production, with network egress restricted to what the task needs.
4. RBAC and least privilege. The narrowest set of repos, branches, and tool permissions the task requires, never a standing credential with the reach of a senior engineer.
5. Reviewed audit logs. Record tool calls, file changes, and commands; assign a reviewer and alert owner. Connect to SIEM where appropriate.
6. A data-residency decision, in writing, reviewed when providers or contracts change. Where does the model provider process the code, and does that satisfy the client contract or the regulator you answer to?

These checks extend the access-control discipline an SME should apply to a new contractor or SaaS vendor — applied to software that can act on its own.

Laid out as a path from pilot to production, the gates look like this:

A pilot that jumps straight from "the agent wrote working code" to "ship it" is skipping every gate in that diagram at once.

Where to pilot it

Pick the pilot's target like any controlled experiment: bounded, reversible, low blast radius. An internal tool, a documentation site, a test-suite backlog, a low-traffic microservice — somewhere a bad merge costs an afternoon, not a client relationship.

Don't pilot on the core production repo or near a client's codebase until the relevant risk controls are proven on something smaller. The pilot must test code quality, review costs, and whether access controls hold under real use. A vendor demo does not settle those questions.

How to measure a pilot honestly

Measure value and controls together. Does working time fall after review and rework costs? Does the code pass tests, remain secure, and support maintenance? Can the accountable person show what the agent did and what data it processed?

Set acceptance limits before starting: task types, minimum quality, budget, and failures that require stopping. Improve or stop a pilot that misses the limits rather than forcing a launch.

What evidence do you need before expanding use?

Start with bounded work and assess the evidence before expanding access. Governance, code quality, and business value need to develop together.

Ask vendors to show successful and failed tasks, access records, total costs, and rollback procedures. Preparation time depends on the systems and contracts; six checks do not guarantee readiness in a few weeks.