What happened
Aliyun’s 2026 Agent Developer Survey describes responses from 1,906 people, including enterprise technical decision-makers, architects, engineers, and product managers. The report says the respondents were gathered through in-person developer salons in Beijing, Shenzhen, Guangzhou, Shanghai, Hangzhou, and other cities. It compares some answers with the previous year, but the supplied material does not provide a full sampling methodology or detailed year-on-year figures for every question.
The report says 46% of respondents’ companies had completed or were developing agents, up from 36% the previous year. At the same time, only 18% said agents had reached production. The report presents single-agent, multi-agent, and human-in-the-loop approaches as coexisting: 40% primarily used a single-agent architecture, 42% were beginning to introduce multi-agent systems as their main architecture, and 15% treated human confirmation at key steps as a principal design choice.
Coding is described as the most established paid application area. Fifty-seven percent of companies reportedly procured coding tools such as Claude Code, Codex, Cursor, or Qoder; 78% used general agent frameworks, and nearly four in ten used both coding agents and general frameworks. The report says vendor adoption remains fragmented and argues that transferable engineering abstractions may be more useful than committing to one vendor. It also names employee productivity and data analysis among common deployment scenarios, while saying fewer than 40% had brought agents into core business processes.
The report identifies several engineering needs. Ninety percent of companies reportedly had a clear need for context and memory management; 63% said multi-model routing and cost governance were capabilities they most needed to improve. For evaluation, 55% relied on manual spot checks, while fewer than 8% automatically evaluated execution trajectories. Around one in ten respondents reported agent task success of 90% or higher; about 55% reported 70% or higher, and 16% had not quantified success rates. The report also says 37% had either adopted or were following MCP, while 9% had completed private enterprise deployment.
What the archive adds
This is a new fact in a familiar thread, not a direct restatement. A prior Field Note on developer surveys covered reports of AI answers that were “almost right,” while Atlassian’s developer-experience survey described faster coding alongside persistent friction. Aliyun’s survey adds figures specifically about agent production, success measurement, and engineering needs.
Trend signal
The findings support AI-native organizations move toward review and orchestration: respondents report reliance on manual spot checks, limited automated trajectory evaluation, and incomplete measurement of success. The survey does not establish that review practices cause production outcomes, but it reinforces the practical distinction between generating output and verifying whether an agent completed work reliably.
Why now
The survey compares development with production deployment and reports that development activity has risen from the prior year while production remains a minority outcome. This makes evaluation and operational readiness timely concerns for teams moving beyond pilots, although the report does not date the fieldwork in the supplied text.
Why it matters
For builders, the headline is not that one architecture has won. The survey describes single-agent, multi-agent, and human-in-the-loop approaches operating in parallel, alongside a fragmented tooling landscape. That argues for designing measurable workflows that can evolve, rather than treating a particular framework or agent pattern as a settled standard.
The reported evaluation gap is especially relevant. Manual spot checks may help teams catch visible failures, but they do not by themselves provide a repeatable way to compare versions or establish whether changes improve task completion. Logging trajectories, defining task-level success criteria, and maintaining a representative evaluation set give teams a basis for iteration. The reported demand for context and memory controls, model routing, and cost governance also suggests that deployment work extends beyond prompts and model selection into system operations.
These are self-reported survey results from a particular respondent pool. They should guide questions to ask inside a team, not be treated as universal adoption benchmarks or causal proof that a given practice raises success rates.
Limits and uncertainty
The report is published by Aliyun and describes survey respondents recruited through developer salons; the supplied material does not establish that the sample represents developers or companies globally. It does not include enough methodological detail here to assess response weighting, question wording, or uncertainty around the percentages. Categories such as “production,” “success rate,” and “adopting” MCP may have been interpreted differently by respondents. The report also presents associations between evaluation and reported success, but does not prove that evaluation caused higher success. Its claims are best read as directional signals from this sample, not definitive market measurements.
Skill to build now
This week, define one agent task’s success contract: the observable result, required checks, and conditions for human review. Save the inputs, tool actions, and outputs for a small set of representative runs, then use the same cases to compare the current version with any change. This turns vague impressions from spot checks into evidence a team can inspect and discuss.
Reader takeaway
Aliyun’s survey suggests that agent experimentation is more common than production deployment, and that many teams still lack systematic ways to measure task success. Treat the percentages as a snapshot, but use the underlying questions directly: can your team verify completed work, track failures, and see the cost of the workflow?