Only 33% of Developers Trust AI Answers: How to Teach an Agent to Work from a Specification

"We'll roll out AI, and in six months half the team won't be needed." The author of a Habr write-up hears this attitude from managers far too often. They imagine that an agent gets a task in a single prompt, writes the code, tests it itself, and ships it, leaving humans to click Merge.

Reality is different. Say you ask an agent to speed up refund processing in an online store. It removes a "redundant" repeat read from the database, the tests are green, but under parallel requests a customer receives more money than they paid: that read protected a business rule, and nobody told the agent about it.

That is why, in the Stack Overflow 2025 survey, only 33% of developers trust AI answers. The author proposes a solution: work from specifications (SDD, spec-driven development). First you describe what the code must do, then you write the code and verify it against that description.

For this, he uses the OpenSpec framework.

Why the demo lies

In a demo, an agent builds a CRUD app or speeds up a SQL query in five minutes. A task like that has no history, and it's clear what a correct result looks like. A live system has integrations and rules that are written down nowhere: the agent doesn't know which client reads a given field. It fills in the missing pieces itself, and the code comes out plausible but not necessarily correct.

The Stack Overflow 2025 numbers confirm this. 84% of developers use or plan to use AI, but 33% trust the accuracy of its answers and 46% do not. The most common complaint, at 66%, is about solutions that are almost right, but not quite, and 45% say debugging generated code takes longer. The authors of the DORA 2025 report call AI an amplifier: in strong teams it amplifies strengths, in weak ones, problems.

Here is a simple test for a manager: before planning layoffs, take one of your own real tasks and run it through with AI from start to finish — design the feature, write the requirements, get the code, verify it, and take it to production. After a couple of days it becomes clear that AI speeds up the work, but a human still has to decide whether it was done correctly.

Specifications instead of one-line tickets

An agent will guess its way through a one-line ticket, but with a full specification that includes constraints and edge cases, it works within defined bounds. GitHub Spec Kit, which was released as open source in September 2025, takes a similar approach. Its lead maintainer, Manfred Rim, compared the agent to a very capable and fast intern who needs a clear spec and a mentor.

OpenSpec is a lightweight framework: specifications live in the repository next to the code, in plain Markdown. It supports more than 30 tools, including Claude Code, Cursor, and GitHub Copilot. The openspec/ folder has three parts: specs/ describes how the system works now, changes/ stores proposed changes (proposal, design, tasks, and requirement deltas), and config.yaml carries project context that is fed to the agent when it creates artifacts.

Requirements are written with the keywords SHALL/MUST and GIVEN/WHEN/THEN scenarios. For example, for a partial refund: the sum of all refunds on an order MUST NOT exceed the amount paid, and a repeated request with the same idempotency key does not create a second refund. The cycle consists of three commands: /opsx:propose creates a plan, which is reviewed before any code is written; /opsx:apply implements the tasks; /opsx:archive merges the deltas into the main specifications. The next task then starts with an up-to-date picture of the system.

Context, invariants, and skills

Every time, the agent arrives in the project like a new hire on day one, so it pays to keep a description of the system next to the code: product boundaries, business processes, CI/CD pipelines, a glossary, and invariants, meaning rules that must not be broken in any refactoring. Invariants are the most commonly underestimated item — hence the refund story. A glossary solves a similar problem: the analyst writes "cancellation," while the code has Refund, Reversal, and Cancellation, and without a dictionary the agent will pick at random. The author suggests including context updates in the Definition of Done, on par with tests.

Skills are reusable instructions such as "how we write a migration" or "how we review a PR." The review-against-spec skill checks every scenario in the delta against the code and tests, verifies that invariants have not been weakened, and produces a list of discrepancies without making any edits of its own. Asked to "take a look and see if everything is fine," an agent usually answers that everything is fine, while a checklist forces it to search. The final word in a review stays with a human.

People and the bug loop

Specifications do not replace expertise: a junior sees code that compiles and passes tests, while an experienced developer sees a race condition or a violated invariant in it. A warning sign is the pass-through employee who forwards a ticket to the agent and sends the result to review without reading it. Then the entire burden of verification falls on the lead, who becomes a bottleneck. During the rollout you need a mentor with SDD experience: they set up the rules and skills and teach the team to write specifications and review AI code. The author compares the role to a scrum master: it is temporary, but without it the methodology dissolves into "well, we have Cursor."

The author also warns against the "one person, four roles" anti-pattern: business analyst, systems analyst, developer, and tester in one person. Each role checks the others, and without training and outside review those checks disappear. And AI will implement a weak specification as fast as a good one.

Without a process, a team rewrites chunks of the system with every production bug and breeds new bugs. The way out is to work out, after every error, what the agent was missing: context, a rule, or a check in a skill. The missing piece is written down and put through review like an ordinary PR. If you fix only the code, the agent will repeat the same mistake in the next feature.