84.5% of Engineering Teams Say They Beat Their Competitors at AI Agents. 92.3% Tried to Rebuild Software They Used to Buy, and 25.6% Say It Worked.
Temporal published its 2026 State of Development Report on August 25. It surveyed 554 engineers and engineering leaders in the US and UK, and the headline finding is that daily AI agent use went from 47.3% a year ago to 80.8% now, a relative jump of 70.8%.
That is not the interesting number. Two others are.
The first: 84.5% of respondents believe their company is better than its peers at using AI agents. As the report itself dryly notes, a great majority of teams placing themselves in the 85th percentile is statistically unlikely.
The second: 92.3% have tried to build something internally that they would previously have bought software for. Only 25.6% say they succeeded and that it had a big impact.
Those two findings sit next to each other in the same dataset, and read together they describe the build-versus-buy decision most solo operators are making right now, badly.
The 92.3% is the number that will get quoted
Temporal calls this the "SaaSpocalypse," and 92.3% is a genuinely striking figure. Nine out of ten engineering teams have at least attempted to replace a paid tool with something they built.
But attempt rate is not success rate, and the gap here is enormous. A quarter of respondents report a rebuild that worked and mattered. The rest tried, and either did not finish, finished something that did not move the needle, or are still in the middle of it. Among the self-described unsuccessful cohort, respondents were 2.9x more likely to say they did not try or it did not work.
I have run this experiment on myself more than once and my personal hit rate is roughly in line with the survey, which is the part that made me stop and actually think about it. The rebuilds that worked were small, single-purpose, and replaced something I was overpaying for relative to how little of it I used. The ones that failed were the ones where I mistook "I can generate the happy path in an afternoon" for "I can own this."
That distinction is the whole game, and agents have made it much harder to see, because the happy path now genuinely does take an afternoon.
What the report says about where the time actually goes
The blockers section is the most useful part of the whole document, and it lines up with the failure mode above.
The top three limits on doing more with agents are tracking state (35.7%), debugging, and managing costs. Not code generation. Not model quality. State and debugging: the two things that are cheap in a prototype and expensive in a system you have to keep running.
Meanwhile 41.1% of respondents encounter issues with agents daily or more, and 16.4% encounter them hourly or more. Set that against 85.5% saying they trust agent outputs at least somewhat, and 91.1% saying agents improved or revolutionized their productivity. People are simultaneously very happy with agents and hitting problems with them multiple times a day, which is not a contradiction so much as a description of what using a powerful, unreliable tool feels like.
On cost, 79.8% say token and compute cost is a meaningful factor in their decisions. For a solo operator that number should be higher than it is for a 500-person company, not lower.
And the finding I keep coming back to: the self-identified successful cohort is only 1.2x faster than everyone else. They are not winning on speed. Report respondents told Temporal their real bottleneck is time to think. AI speeds everyone up about equally; some people just make better decisions with the time.
The overconfidence number is not a joke
84.5% believing they are above average would be funny if it were not load-bearing for the build-versus-buy decision.
The report notes this is partly driven by leadership: executives were 35.1% more likely than their own engineers to describe the organization as very successful with agents. So the gap is not evenly distributed. The person deciding whether to build or buy is systematically more optimistic than the person who will have to maintain the result.
If you are a solo operator, you are both of those people. You get the executive's optimism and the engineer's maintenance burden in the same head, with nobody to arbitrate between them. That is worse, not better.
What I would actually do with this
Concrete rule, and I am going to hold myself to it: before rebuilding a paid tool, write down what the subscription costs per year, and what you think the build costs in hours. Then multiply your hour estimate by four and compare again.
Four is not arbitrary. It is roughly the correction implied by a 92.3% attempt rate against a 25.6% success rate, and it is close to what my own failed rebuilds cost me relative to my estimate. If the tool costs 200 a year and you think it is a weekend, the corrected build is a month of weekends, and you should just pay for the tool. If the tool costs 4,000 a year and you use one feature of it, the math survives the correction and you should build.
Second rule: only rebuild things where you can name the specific feature you use. "I use maybe 10% of this product" is the single best predictor of a rebuild that works, because it means you are not actually rebuilding the product, you are building the 10%. Every rebuild I have regretted started with "how hard can the whole thing be."
Where this report could be wrong, and it could
I want to be direct about the problems with this data, because they are not small.
Temporal sells agent orchestration. The report is a marketing asset, and it contains lines like "successful teams are 1.9x more likely to use Temporal." The findings that flatter the product should be discounted accordingly. That does not invalidate the survey, but it means the framing of who counts as successful is not neutral.
"Successful" is also self-reported, which the report discloses. Given that 84.5% think they are above average, the successful cohort is partly just the more confident cohort. Some of the differences between the groups may be differences in self-perception rather than outcomes.
The sample is not solo operators. The largest company-size bucket is 251 to 1,000 employees at 29.2%, with 33.4% from companies of 1,001+ and 14.6% from companies of 5,001+. Two-thirds are US-based. Applying findings from mid-sized company engineers to a one-person business requires a translation step that I am doing informally and could be doing wrong.
The fieldwork also ran April 29 to May 25, 2026, and was published in late August. In agent tooling, three months is a long time.
The honest take
The genuinely useful thing in this report is not the adoption curve, which everyone already believed. It is the shape of the failure: teams are not blocked on generating code, they are blocked on state, debugging, and cost, and they are making build-versus-buy calls while systematically overrating themselves.
The adoption number will be in every newsletter this week. The 25.6% will not be, because a one-in-four success rate is a worse headline than a nine-in-ten attempt rate. Quote the second one at yourself the next time you are about to cancel a subscription and open an empty repo.
Author
Lukas
@lukcombinator