85.5% of Engineers Trust Their Agents. Half of Them Hit Problems Every Day

Surya Pratap
By Surya Pratap

August 26, 2026

11 min read

AI & Technology
Two sets of answers from the same survey of 550+ engineers set against each other — 85.5% trusting agent output, 91.1% reporting improved productivity and 80.8% daily use on one side, against 41.1% hitting problems daily, 9.0% continuously and 51.3% shipping to production in hours or less on the otherThe same people, two answersHover to explore
Neither column is wrong. They were given by the same respondents in the same survey, which is what makes the distance between them worth reading.

Temporal published its 2026 State of Development Report: AI Agents this week, and the number doing the rounds is the adoption one: 80.8% of engineers now use agents daily or more often, up from 47.3% a year earlier — a 70.8% relative jump.

That number is real and it is not very interesting. Adoption curves go up; this one went up steeply. If you were waiting for confirmation that agents have gone mainstream in engineering, here it is, and you can stop waiting.

The interesting numbers are two pages further in, and they do not sit comfortably beside each other.

1. What the survey actually measured

Before the findings, the shape of the thing, because it decides how much weight any of it can carry.

Methodology, as published

Temporal, 2026 State of Development Report: AI Agents

  • 550+ respondents — software engineers, architects, infrastructure contributors and engineering leaders.
  • Fieldwork 29 April – 25 May 2026, published late August. The data is roughly three months old at publication.
  • Two-thirds US, one-third UK and EMEA.
  • Company size from under 50 to over 5,000 employees, with the largest single group — 29.2% — at companies of 251–1,000.

That is a respectable sample for a practitioner survey and a narrow one for a claim about "engineers." It skews mid-size and Anglophone, and it is self-selected: people who answer a survey about AI agents are people with opinions about AI agents.

2. The two answers that do not agree

Here is the pair.

85.5% of respondents say they trust agent output, at least somewhat. 91.1% say agents have improved or revolutionised their productivity.

And: 41.1% encounter problems with agents daily. A further 9.0% encounter them continuously.

Just over half the sample is hitting problems every single day, and roughly six in seven trust the output anyway.

Both figures came from the same people in the same instrument. Neither is a lie. But held together they describe something specific, and it is not "agents work well."

They describe a calibration gap: confidence that has moved faster than the evidence supporting it. That is a normal and well-documented thing for humans to do with tools that are impressive most of the time and wrong unpredictably — and it is precisely the condition under which people stop checking.

Why 'at least somewhat' is doing a lot of work

The trust figure is a soft one — the question allows anything above indifference to count. That is a legitimate way to ask it, and it means 85.5% should be read as "most engineers are not hostile to agent output," not as "most engineers would ship it unreviewed." The failure figure, by contrast, is a hard behavioural count of how often something went wrong. Comparing a soft measure to a hard one is exactly why the two can both be true; it is also why the softer one deserves less weight than the headline gives it.

3. A median of 5, a mean of 10.7

One more number worth stopping on: respondents run a median of 5 agents and a mean of 10.7.

When the mean is more than double the median, the distribution has a long right tail. A minority is running a great many agents and pulling the average up, while the typical engineer runs a handful.

That matters for how you read everything else in the report, because those two populations are not having the same experience. The person running thirty agents has industrialised something. The person running five is using agents the way one uses an IDE feature. Aggregate satisfaction figures average across both, and the resulting number describes nobody.

If you are trying to work out whether your team is behind, the median is the relevant statistic and it is five.

4. Shipping faster than you can check

51.3% of respondents say they get from prototype to production in hours or faster. 26.9% say minutes or faster.

Put that against 41.1% hitting problems daily and the shape of the risk becomes clear. The constraint that used to sit between "this works on my machine" and "this is live" was time — time in which someone read the diff, ran the suite, thought about the edge case. Agents compressed that window to minutes for a quarter of respondents.

Compression is only a problem if verification did not compress with it. Mostly it did not: writing code got dramatically cheaper, and confirming that code is correct got a little cheaper. The gap between those two rates is where the daily problems live.

This is the same mechanism we wrote about in the review bottleneck: generation scaled, review did not, and the queue moved rather than disappeared. This survey is the first large-sample evidence I have seen that the pattern is now the median experience rather than an early-adopter complaint.

5. The number every SaaS founder should read twice

Buried in the career-sentiment section is the finding with the most direct commercial consequence for anyone reading this:

92.3% of respondents have attempted to recreate software they already pay for.

Attempted. Not succeeded — the survey measures the attempt, and that distinction is the whole story. But nine in ten engineers now reaching for "we could just build this" changes the default posture in every procurement conversation your sales team will have next year.

That they succeeded

What it does not mean
The gap between a working prototype and a maintained internal product is where most of these attempts die, and it is the gap the rebuild-cost problem lives in. An attempt is not a substitution; it is a negotiating position that now feels credible to the person holding it.

Your moat is not the feature

What it does mean
If a competent engineer with agents can approximate your core feature in a weekend, that feature stopped being the reason anyone pays. What survives is what an internal rebuild cannot cheaply reproduce: the data, the integrations, the compliance surface, the accumulated edge cases, the fact that nobody on their team wants to own it at 2am.

For a founder shipping an MVP, the practical read is not "SaaS is dead." It is that the burden of proof moved. You now have to be explicit about why buying beats building, because your buyer has already tried building — and the honest answer is almost never the feature list.

6. Who is telling you this

I want to be direct about the source, because it changes what the report's conclusion is worth.

Temporal sells durable execution — infrastructure for long-running, stateful, retryable workflows. The CEO's framing of the findings is:

The teams pulling ahead are those who trust their systems more, because they've solved for state, cost, and reliability.

State and reliability are the two things Temporal's product exists to provide. That does not make the sentence wrong; it does mean the report's recommendation and the publisher's revenue point in the same direction, and you should discount accordingly. The raw percentages are much more trustworthy than the interpretation laid over them, which is generally true of vendor research.

The second caveat is age. Fieldwork closed 25 May 2026; publication is late August. In most industries a three-month-old survey is current. In this one, three months covers several frontier model releases and at least one shift in how coding agents are used. The adoption number is almost certainly an undercount by now. The reliability numbers could have moved either way, and nobody — including Temporal — knows which.

7. What to actually do with this

Your own failure rate

Measure
The useful version of 41.1% is your number, not theirs. For one week, log every time an agent produced something that had to be undone, corrected, or re-run. Most teams have never counted, and the count is almost always higher than the felt sense — which is the calibration gap, measured locally.

The verification gap, not the generation gap

Close
If you can go prototype-to-production in an hour, the leverage is no longer in generating faster. It is in a check that runs in that hour and can actually stop a release. An evaluation set is the cheapest version of this and most teams still do not have one.

Why buying beats building

Answer
Write the paragraph. If you sell software to engineers, 92.3% of your buyers have tried to rebuild something they pay for. Your answer to "we could build this" should not be improvised on a call.

The one thing I would not do is treat 80.8% as a mandate. Adoption statistics are the most quoted and least actionable numbers in any survey — they tell you what is normal, and normal is not the same as correct. Half of that 80.8% is hitting problems daily.

The honest summary

The headline finding is that agent use among engineers roughly doubled in a year and is now near-universal on a daily basis. Take that as settled.

The finding underneath it is more useful and less comfortable: trust has outrun reliability. 85.5% trust the output while just over half hit problems daily or continuously, and half the sample ships to production in an hour or less. That is not a story about agents being bad. It is a story about a verification layer that did not scale at the same rate as the generation layer, in an environment where nobody has time to notice.

And the number to take to your next board meeting is the one nobody is quoting: 92.3% of engineers have already tried to rebuild something they pay for. They mostly failed. They will try again with better tools, and your answer for why they should not needs to be better than a feature comparison.

Count your own failure rate before you trust anyone else's.

Sources: Temporal Technologies, "Temporal Releases The 2026 State of Development Report: AI Agents" · Temporal Technologies · All percentages, the 550+ sample size and the 29 April – 25 May 2026 fieldwork dates are as reported by Temporal; the interpretation and the caveats are mine.

IdeaToMVP Academy

Want to build with AI — not just read about it?

4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.

Explore the Academy →
Share this post :