SENAR brings quality gates to AI-assisted development: how specs and metrics cut down on errors

Habr has published the fourth article in a series on SENAR, an open methodology for software development with AI agents. Andrey Yumashev describes how formal entry and exit "gates" should replace the personal discipline of whoever writes the task, and reduce the number of bugs that only surface after a task is closed.

How SENAR works

The author calls SENAR an engineering methodology for working with AI agents in development. It grew out of practice rather than theory: according to Yumashev, more than thirty projects have run under this regime over the past year and a half, with the agent increasingly writing the code while humans handled task definition, acceptance, and failure analysis.

The article's core argument is simple: an agent does not retain context between runs, follows the wording literally, and readily optimizes locally if a task is described carelessly. Within a single task, SENAR relies on several mandatory elements:

• a formal task goal framed in product terms
• verifiable acceptance criteria
• a separate block of negative scenarios
• change boundaries and architectural context
• signal metrics for process quality

The author stresses that this is not an attempt to replace tests, linters, or code review. The logic is different: regular checks look at the code, while the gates look at the task itself before work starts and at the quality of its acceptance after it finishes. In TAUSIK, the practical implementation, these steps are built directly into the tool, so you can't skip them without bypassing the system itself. In the author's view, this is exactly what protects a team from "Friday" fatigue, when the smallest tasks are the ones most likely to slip into production with a defect.

What the gates check

On the way in, SENAR uses the QG-0 gate. It won't let a task start until it has a minimal spec: a goal, acceptance criteria, negative scenarios, change boundaries, and a link to the architectural context.

Yumashev specifically pushes back on the popular idea that small tasks can be handed to an agent "in one line." In his observation, those are exactly the tasks that break in production most often, because the person writing them keeps important details in their head but never records them on the task card.

"It wasn't the agent that skipped a step — it was me."

On the way out, QG-2 kicks in: a gate that blocks a task from closing until the result has been checked against what was promised at entry. The author highlights three mandatory checks: confirming every acceptance criterion with a test, a manual check, or an artifact; logging every manual fix made after the agent's work; and updating the project memory if the task uncovered a new edge case or infrastructure quirk.

The point isn't bureaucracy. It's to keep the agent from repeating the same mistakes on the next task because a human quietly patched things.

Metrics and limits

A separate section of the article covers the metrics SENAR uses as signals of process health. FPSR shows the share of tasks solved on the first attempt; MIR shows how often a manual fix was needed after the agent; DER measures dead ends and lost time; ERR reflects tasks that had to be fixed after they were closed.

According to the author's work log, on backend tasks in a familiar domain FPSR rose from roughly 40% to 75–80%, MIR on the Sortule project dropped from 20% to 5–7%, and ERR fell from about 15% to 6%.

Yumashev is also candid about the methodology's limits. The gates don't help much where results are hard to formalize: tasks involving the "feel" of an interface, the tone of a text, or product intuition. Nor do they help with external services when third-party documentation contradicts the API's actual behavior.

In such cases, a formal process can hold a task's structure together, but it doesn't replace domain knowledge, manual hypothesis testing, or upfront research into the integration.

What this means

SENAR is taking shape not as a set of tips but as a strict operational loop for AI development: without a proper spec, the agent doesn't start; without confirmed acceptance, the task doesn't close.

For teams already handing part of their code to agents, this is a strong signal: the main risk now lies not only in the model but also in the quality of task definition, project memory, and process discipline.