AI-Native System Specification Standard Reduces Agent Rework by 50%

Artem Kholomyanskiy developed ANSS, a specification standard that cut AI agent iteration cycles from 5-7 to 2-3. This framework addresses the inherent mismatch between human-centric specs and machine interpretation.

Artem Kholomyanskiy, a solo founder, reduced AI agent iteration cycles from 5-7 to 2-3 by developing ANSS (AI-Native System Specification Standard). This framework, detailed on dev.to, addresses the fundamental mismatch between human-centric software specifications and the literal interpretation of AI coding agents. The core insight: traditional specs, designed for human ambiguity tolerance, lead to rework when interpreted by machines that "fill gaps with whatever their training data suggests." Kholomyanskiy found that agents, when given ANSS-formatted specs, began surfacing contradictions in his own requirements before writing a single line of code, saving hours of previously unrecognized rework.

WHAT THEY DID

Kholomyanskiy developed ANSS after repeatedly encountering situations where AI agents, despite clear instructions, broke existing functionality or introduced unintended changes. The problem, as identified, was not the agent's capability but the spec format itself, designed for human readers who infer context and tolerate ambiguity. ANSS reorients the specification process by treating AI agents as first-class readers, leading to a significant reduction in back-and-forth iterations.

Three-Layer Markup Guides Agent Focus

ANSS introduces a three-layer markup system for every section of a specification. Each section is tagged to define its primary audience and purpose: [D] Domain for Product Owners and PMs, outlining what to build; [E] Engineering for Developers and Architects, detailing how to build; and [A] Agent for AI agents, specifying how the agent should execute. AI agents are instructed to read [A] sections first. This ensures all operational parameters necessary for the agent to function without guessing are immediately accessible, minimizing interpretive errors.

Invariants Enforce Verifiable Rules

Kholomyanskiy found that general instructions like "keep the codebase minimal" were frequently misinterpreted by AI agents, sometimes leading to the addition of multiple npm packages. ANSS addresses this through invariants, which are verifiable rules. An invariant includes a Check field, transforming a qualitative instruction into an objective test. For example, INV-001: No external npm packages would include Check: no node_modules imports in server.js. This explicit, verifiable rule removes ambiguity and prevents agents from making assumptions based on their training data.

Agent Review Preempts Code Generation

Before any code is written, the AI agent performs an audit of the ANSS-formatted specification. This review process is designed to identify potential issues early, including contradictions between sections, missing edge cases, incomplete acceptance criteria, and conflicts with defined invariants. A hard rule is established: if more than three problems are found during this review, the agent must stop and prompt for clarification rather than proceeding. This mechanism, according to Kholomyanskiy, revealed how much rework he was inadvertently creating for himself by catching specification flaws before development began.

Change Specification Protects Existing Code

Traditional specification formats often lack explicit instructions on what not to change. ANSS introduces a Change Specification section with fields for Current State, Desired State, What NOT to change, Impact, and Rollback. The What NOT to change field is particularly critical. It explicitly defines parts of the codebase or system that must remain untouched during the change implementation. This mechanism prevents agents from making destructive modifications to unrelated components, a common source of unexpected bugs and rework.

ANSS is structured into three levels of detail: CORE (15–20 pages for 80% of projects like bots, SaaS, and APIs), EXTENDED (40–60 pages for security or compliance-heavy projects), and ENTERPRISE (full standard for regulated industries). This tiered approach suggests the framework's adaptability to varying project complexities.

WHAT WE'D CHANGE

The ANSS framework offers a structured approach to mitigating AI agent-induced rework, particularly valuable for solo founders or small teams where iteration efficiency is paramount. However, its effectiveness hinges on the quality of the initial invariant and change specifications. The system relies on the founder's ability to foresee and explicitly define all Check conditions and What NOT to change parameters. This upfront investment in detailed specification writing, while reducing downstream rework, could introduce a new bottleneck if the founder struggles to articulate these constraints comprehensively.

Furthermore, the

Pull quote: “”