Stack Overflow Developer Survey 2026: AI Agent Trust

The survey results landed on 6 October 2026 and the headline figure is adoption: 83% of respondents use at least one AI tool at work. I read the second number first, because it decides what a team should do on Monday. Nearly half say they trust AI output when they can verify it, and only 6.6% trust it for important decisions.

This post reads the press release and the survey's own AI data page line by line, quotes only figures that appear on them, and states each question's sample where the page gives one. It then asks the practical question the survey cannot answer: what review policy follows from conditional trust. The policy section is my interpretation, labelled as such, with CODEOWNERS and branch protection config you can paste.

What the survey measured, and what it cannot tell you

Stack Overflow's methodology page reports a fielding window of 23 June to 5 August 2026, with 39,266 rows in the extract of which 30,903 were valid responses from 169 countries. The survey was promoted through stackoverflow.com, stackoverflow.blog and an email list of community members who opted in to research. The page does not mention weighting.

That recruitment matters for every number below. People who answer a Stack Overflow survey are people who already read Stack Overflow, so this is a large sample of an engaged developer community, not a random sample of all developers. The survey home page also says sample sizes vary by question, from about 11,500 to 21,100 respondents, and that some results cover only subgroups such as daily AI users or people with 16 or more years of experience.

Everything in the AI section is self-reported: what people say they use, trust and do. I treat it as evidence about stated behaviour and sentiment, never as a measurement of how reliable agents are or how carefully code is actually reviewed. One more caution from reading both pages together: the press release and the AI data page round or define a few figures differently, so wherever they disagree I use the data page, which states the question and the n.

Agents at 26.2%: AI is common, agent workflows are still the minority

The work-use question asked whether respondents currently use AI tools or agents in their role (n = 17,464, multiple answers allowed). Coding assistants and coding agents lead, while automated agent workflows sit at roughly a quarter. The daily column comes from a separate frequency question (n = 14,478) and shows how often people who use each type do so.

Two readings are tempting and both overreach. The first is that agents are marginal; but 63.1% of the people who use them do so daily, so the quarter who use them lean on them hard. The second is that 26.2% is the real agent population; the label bundles agents with automated workflows, and the question does not say how much autonomy the agent had.

The survey also reports that 55% of daily AI users spend at least two hours a day with AI tools (n = 10,926), and 30.9% spend four or more. If a quarter of developers run agent workflows and many spend hours a day in AI tools, the code arriving at review is no longer a rare event. That is the context for the trust numbers.

Trust is conditional: 48.0% trust what they can verify

The trust question asked how much developers trust AI output as part of their workflow (n = 14,304). 48.0% chose trust when it is easy to verify. 16.3% trust it for many tasks but not important decisions, another 16.3% for low-risk tasks only, 12.3% do not trust it for most tasks, and 6.6% trust it for many tasks including important decisions.

The structure of the answer is the finding. The largest group is not defined by how good the model is but by how cheap the check is. The survey page adds that only 4% of early-career respondents with one to five years of experience trust AI for important decisions. Stack Overflow's press release adds that 78.7% say source attribution matters when judging AI-generated code or technical answers, and quotes its chief executive saying trust is earned through transparency, source attribution and rich technical context.

A second question asked what developers usually do with an AI answer before using it (n = 13,162, multiple answers allowed). The top answers describe verification, not acceptance:

• Run it locally: 76.5%
• Compare it against codebase context: 63.9%
• Inspect tests or security implications: 53.0%
• Use it as-is: 9.6%

Read together, 48.0% trust verifiable output and 76.5% say they run the code. Those are consistent with each other, and consistent with a profession that has adopted AI by building a verification habit around it. They are also two self-reports, so they tell you what developers believe about their own discipline.

Where developers hand work to AI, and where they will not

The workflow question asked which parts of the job respondents currently use AI for (n = 12,547). The two columns below are the ends of the distribution: the share already using it and the share who neither use it nor plan to. The page has more columns, for expected future use and tasks not in the respondent's workflow, which overlap with these and are left out here.

The ordering follows blast radius. Work whose output you can run in seconds, such as familiar code, debugging and tests, has the highest use. Work that changes shared or live systems has the lowest, and deploying or operating production is the only row where the do-not-plan share, 36.0%, is larger than the already-using share, 19.9%. Developers appear to be applying the verifiability rule from the trust question to their own task list.

Usefulness ratings point the same way (n = 12,734, useful plus very useful): implementation 74.6%, debugging or refactoring 72.6%, review 64.5%, communication 35.0%. The satisfaction question (n = 12,125) has one number worth pausing on: implementation improved satisfaction for 60.1% but decreased it for 19.9%, the highest decrease among the listed activities. The press release states 66% for debugging or refactoring, which differs from the 72.6% usefulness figure on the data page and is closer to its 66.1% satisfaction figure, so check which question a quoted number comes from.

The policy gap: 24.0% report approved tools and guidance

On organisational use (n = 13,167), 29.7% say AI is optional and up to individuals, 24.0% say approved tools and guidance are provided, 15.9% say it is encouraged but varies, 11.5% say it is expected for certain work and 10.2% say it is measured in performance evaluation. 6.1% say it is not used at work.

On how organisations vet tools (n = 12,637), 32.8% report a few approved tools or models, 18.6% mostly one, and 17.3% say different teams choose their own. Another 12.5% say their organisation is trying multiple tools before deciding. On who controls AI memory (n = 12,825), 53.6% say just me and 14.7% say the organisation centrally.

So a developer is more likely to be told to use AI than to be told how to verify it. This survey has no question about review policy, and I will not infer one. What it does show is that trust is being set by individuals, one verification habit at a time, in a population where only a minority report organisational guidance. A team that wants consistency has to write the policy down itself.

The failure mode: treating self-reported trust as a safety control

The trap is reading 76.5% run it locally as a control. It is a statement of habit from people who chose to answer a survey, and habits fail exactly when volume rises. A reviewer facing the tenth agent pull request of the day does not run all ten locally. If your safety depends on each reviewer remembering to verify, your real policy is the 9.6% who use output as-is, applied under time pressure.

The second trap is the word easy in trust when easy to verify. The survey does not define it, and it is relative to the verifier. A migration that passes type checks is not easy to verify if the risk is data loss. Ease of checking is a property of your test suite, your types and your environments, which you can improve, and not a property of the model.

There is a cost, and I would rather state it than hide it. Required checks with an up-to-date branch rule add latency and force rebases when several agent pull requests are open at once, and a CODEOWNERS rule on a busy path makes a small team the bottleneck. That is the trade: slower merges on the paths where a wrong merge is expensive, in exchange for a policy that does not depend on anyone's attention that day.

Turning verifiable into a merge policy

The table maps the survey's trust tiers to a merge policy. The tiers and shares come from the survey (n = 14,304); the policy column is my own mapping, not Stack Overflow's, and you should adjust it to your own risk. The principle is that the survey's own dividing line, whether the output can be verified, becomes the merge rule.

Ownership first. A CODEOWNERS file turns which paths are important into something the platform enforces. GitHub's documentation says the last matching pattern takes precedence, that owners for one pattern must be on a single line, and that approval from any one listed owner satisfies the requirement.

# .github/CODEOWNERS
# Last matching pattern wins, so the broad rule goes first and the narrow
# rules after it. Owners for one pattern must share one line: split across
# lines, only the last owner is kept.
*                      @acme/maintainers
/infra/                @acme/platform
/.github/              @acme/platform
/migrations/           @acme/data-owners @acme/platform
/src/billing/          @acme/payments

# Protect the ownership file itself, or an agent can edit its own reviewers.
/.github/CODEOWNERS    @acme/platform

Then make GitHub enforce it. This call sets branch protection on main through the REST endpoint, whose body requires required_status_checks, enforce_admins, required_pull_request_reviews and restrictions:

# Branch protection for main. gh sends the JSON body from stdin.
# strict=true forces the branch to be up to date before merge: safer, but
# every merged agent PR makes the other open ones stale, so expect rebases.
gh api -X PUT repos/acme/shop/branches/main/protection --input - <<'JSON'
{
  "required_status_checks": { "strict": true, "contexts": ["verify"] },
  "enforce_admins": true,
  "required_pull_request_reviews": {
    "dismiss_stale_reviews": true,
    "require_code_owner_reviews": true,
    "required_approving_review_count": 1
  },
  "restrictions": null,
  "required_conversation_resolution": true
}
JSON

The status check must exist, or the rule gates nothing. This workflow is the smallest honest version: the job is named verify, matching the context above, and runs typecheck and tests on every pull request to main. Replace the commands with your own; the point is that verification is a failing check, not a habit.

# .github/workflows/verify.yml
# The job name "verify" is the status-check context the protection rule
# requires. Rename one and the other silently stops matching.
name: verify
on:
  pull_request:
    branches: [main]
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npx tsc --noEmit
      - run: npm test

What to do on Monday

Five steps, in order, each small enough for a team that has never written an AI policy.

1. Write down which paths are important: infrastructure, migrations, billing, authentication, CI config. Put them in CODEOWNERS and protect the CODEOWNERS file itself.
2. Turn on Require review from Code Owners and Require status checks to pass before merging for main, with a check that actually runs your tests and typecheck.
3. Decide which path classes can merge on green checks alone. The honest criterion is the survey's: only where a failure would be caught by an automated check you trust.
4. Ask agents to mark their commits, for example with a Co-Authored-By trailer, so you can later see how much of main is agent-authored and which of it skipped review.
5. Rerun the audit monthly and compare it with how your team says it reviews, because the survey shows how widely stated habit and enforced policy can differ.

# 1. How much of the last 30 days of main is agent-authored? This only works
#    if your agents add a Co-Authored-By trailer, so it measures the
#    convention, not the truth. Treat a low number as a floor.
git log origin/main --since="30 days ago" --oneline | wc -l
git log origin/main --since="30 days ago" \
  --grep="Co-Authored-By: Claude" --oneline | wc -l

# 2. Which of the last 50 merged PRs touched infra/ with zero reviews?
#    "reviews" and "files" are real gh pr list JSON fields.
gh pr list --state merged --limit 50 --json number,title,reviews,files \
  --jq '.[] | select((.reviews | length) == 0)
        | select(any(.files[]; .path | startswith("infra/")))
        | "#\(.number) \(.title)"'

# 3. Does the required check actually exist on main? An absent context
#    means the rule gates nothing.
gh api repos/acme/shop/branches/main/protection/required_status_checks \
  --jq '.contexts'

The three commands below cover steps 3 to 5 once the rule is on. The first measures only your convention, the second looks for merged pull requests that touched infra with no reviews, and the third confirms the required check is really attached to main.

The survey's most useful result is not that 26.2% use agents but that developers set their own trust by how cheaply they can check the output. Make that explicit: a path is safe to automate when a check you control can fail the merge, and everything else needs an owner. Quote the survey's numbers with their question, sample and limits, and let your own audit supply the rest.