Using AI and checking its output are compatible habits. In software development, the second can be part of making the first useful.
Stack Overflow’s 2025 Developer Survey captures that tension. Its AI section reports that 84% of respondents to the usage question were using or planning to use AI tools. On the accuracy question, 46% expressed distrust and 33% trust.
Those figures describe survey respondents, not a census of every developer. Stack Overflow’s methodology also notes that recruitment primarily used its own channels, making engaged users more likely to encounter the survey.
The interesting business question is how a team turns a suggestion into software it can stand behind.
A generated solution can be plausible, readable and still wrong for the application. It may assume a different framework version, miss an authorization check or handle the ordinary input while failing an important exception.
The confidence of the explanation is not evidence about those details. Software can be impressively articulate while getting the date wrong.
For a fictional import feature, an AI tool might propose code that reads a spreadsheet and updates customer records. Reviewing it means asking which identifiers it uses, what happens with an unknown customer and whether rerunning the import repeats the changes.
Those are business questions expressed through code. A successful run on a tidy sample file doesn’t establish the answers.
Simon Willison’s distinction between unreviewed vibe coding and responsible AI-assisted programming is helpful here.3 The relevant professional responsibility is understanding the change and verifying its behavior, regardless of how the first draft appeared.
Curious what an AI agent could do for your team? See our AI agent services.
Check the requirement as well as the implementation
A developer needs a clear statement of the intended behavior. If the requirement is ambiguous, a model can produce a polished implementation of the wrong interpretation.
For our sample import, should a blank phone number erase an existing one or leave it unchanged? Should a row with an unrecognized customer create a new record or wait for review?
Neither choice can be settled by syntax. The team needs the business rule, then meaningful checks against it.
Use tests that could expose a mistake. Include repeat imports, malformed rows and partial failure. Inspect the effect on the actual records rather than only whether the function returned without an exception.
Worth reading next: The AI demo answered beautifully. Now try the awkward questions.
Review also covers maintainability. Someone needs to understand the dependencies, the failure path and the reason behind the chosen design. A change that works today but cannot be explained tomorrow leaves the application with an avoidable burden.
If the product itself uses a model, its uncertain outputs need evaluation too. Hamel Husain’s work on evals emphasizes learning from concrete failures and defining what acceptable performance means.2
That is distinct from testing deterministic import logic. A generated summary can preserve the required format while misrepresenting the facts. The checks need to match the kind of behavior being assessed.
I don’t read the survey’s trust gap as a reason to abandon useful tools. Nor would I treat broad adoption as permission to stop reviewing them.
The business should expect a team to own the result. A sensible explanation of what changed, evidence that the important cases work and a person accountable for the release are more valuable than an argument about whether the tool deserves confidence.
AI can contribute to the work. The sign-off still needs to mean something.