Validation and Quality Assurance Mechanisms

Relevant source files

• Google/Antigravity/Fast Prompt.txt
• Qoder/prompt.txt
• README.md
• Same.dev/Prompt.txt

Purpose and Scope

This document synthesizes the validation and quality assurance patterns implemented across AI coding assistant systems in this repository. It covers mandatory post-edit checks, iterative fixing loops, circuit breakers, verification gate sequences, and enforcement mechanisms that ensure code quality before user delivery.

For information about file editing strategies themselves, see File Editing Patterns and Strategies. For parallel vs. sequential execution constraints, see Parallel Execution Patterns and Constraints.

---

Universal Validation Architecture

All documented AI assistants implement some form of mandatory validation after code modifications. The pattern consists of three universal components: validation triggers, validation tools, and remediation loops.

Sources: Qoder/prompt.txt145-150 Qoder/prompt.txt196-210 Amp/gpt-5.yaml332-344 Amp/claude-4-sonnet.yaml50-57 Same.dev/Prompt.txt72 Same.dev/Prompt.txt237

---

Mandatory Post-Edit Validation

Validation Trigger Rules

Every system implements mandatory validation with varying degrees of strictness. The following table compares trigger conditions across systems:

System	Trigger Condition	Tool Name	Mandatory?	Scope
Qoder	After ALL code changes, no matter how small	get_problems	YES ($100M penalty)	Compilation + Lint
Amp (GPT-5)	After task completion	get_diagnostics + custom commands	YES (Verification Gates)	Type → Lint → Test → Build
Amp (Claude 4)	After completing a task	get_diagnostics + lint/typecheck	YES (MUST run)	Diagnostics + Custom
Same.dev	After every significant edit and before each version	run_linter	YES	Linting + Runtime Errors
VSCode Agent	Implicit through user-visible errors	N/A	NO (Best Practice)	IDE Diagnostics
Windsurf	Implicit validation	N/A	NO (Recommended)	Build/Test Commands

Key Insight: Qoder enforces validation most strictly (with financial penalty metaphor), while Amp implements a structured gate sequence, and Same.dev focuses on linting before versioning.

Sources: Qoder/prompt.txt145-150 Qoder/prompt.txt234-239 Amp/gpt-5.yaml332-344 Amp/claude-4-sonnet.yaml50-57 Same.dev/Prompt.txt72

---

Iterative Fixing Workflows

Standard Remediation Loop

Systems implement a consistent pattern for addressing validation failures:

Error Classification Strategy

Different systems provide specific guidance on when to fix vs. when to escalate:

Qoder Approach Qoder/prompt.txt196-210:

• Fix compilation/lint errors immediately
• Continue validation until no issues remain
• Applies to ALL changes, no matter how small

Same.dev Approach Same.dev/Prompt.txt72 Same.dev/Prompt.txt237:

• Fix errors "if clear how to (or you can easily figure out how to)"
• Do NOT make uneducated guesses
• Maximum 3 attempts on same file

Amp Approach Amp/gpt-5.yaml332-344:

• Report evidence concisely (counts, pass/fail)
• If unrelated pre-existing failures block you, say so and scope your change
• Run gates in order: Typecheck → Lint → Tests → Build

Sources: Qoder/prompt.txt196-210 Same.dev/Prompt.txt72 Same.dev/Prompt.txt237 Amp/gpt-5.yaml332-344

---

Circuit Breakers and Attempt Limits

Three-Attempt Pattern

Multiple systems converge on a 3-attempt maximum for fixing the same issue, preventing infinite loops:

Circuit Breaker Implementation

System	Max Attempts	Scope	Action on Limit
Same.dev	3	Per file	Ask user what to do next; suggest revert or contact support
Amp (implied)	Not specified	Per verification gate	Report evidence and scope change
Qoder	Not specified	Continuous until clean	Continue until no issues (no explicit limit)

Same.dev Circuit Breaker Same.dev/Prompt.txt72 Same.dev/Prompt.txt186:

"DO NOT loop more than 3 times on fixing linter errors on the same file. On the third time, you should stop and ask user what to do next. If user doesn't know, suggest them to revert or contact Same support."

This prevents token exhaustion and infinite correction loops when the assistant is stuck.

Sources: Same.dev/Prompt.txt72 Same.dev/Prompt.txt186 Same.dev/Prompt.txt237

---

Verification Gate Sequences

Amp's Multi-Stage Validation

Amp implements the most comprehensive verification sequence with explicit ordering:

Gate Execution Rules

From Amp/gpt-5.yaml332-344:

Order: Typecheck → Lint → Tests → Build

Rules:

1. Use commands from AGENTS.md or neighbors; if unknown, search the repo
2. Report evidence concisely in the final status (counts, pass/fail)
3. If unrelated pre-existing failures block you, say so and scope your change

Sources: Amp/gpt-5.yaml332-344 Amp/claude-4-sonnet.yaml50-57

---

Testing Validation Patterns

Test-Driven Validation Workflow

Several systems emphasize testing as a critical validation mechanism:

Qoder's Test File Validation

From Qoder/prompt.txt85-96 Qoder enforces strict sequential validation for test generation:

Rules for Multiple Test Files:

1. Generate and validate ONE test file at a time
2. Write ONE test file then use get_problems to check for compilation issues
3. Fix any compilation problems found
4. Only proceed to the next test file after current file compiles successfully
5. Execute test immediately and report results

Rationale: "You will be called multiple times to complete all files, NO need to worry about token limits, focus on current file only."

Same.dev's Version-Based Testing

Same.dev/Prompt.txt89 Same.dev/Prompt.txt254:

• "After every significant edit, first restart the dev server, then use the versioning tool to create a new version for the project. Version frequently."
• Testing happens at version boundaries, ensuring incremental validation

Sources: Qoder/prompt.txt85-96 Same.dev/Prompt.txt89 Same.dev/Prompt.txt254

---

Enforcement Mechanisms

Financial Penalty Metaphors

Qoder uses extreme financial penalties to enforce critical rules:

Rule Violated	Penalty	Purpose
Using wrong editing tool (not search_replace)	$100,000,000	Force correct tool selection
Trying to replace entire file content	$100,000,000	Prevent expensive operations
Splitting short modifications unnecessarily	$100,000,000	Optimize token usage

From Qoder/prompt.txt234-239:

"MUST always default to using search_replace tool for editing files unless explicitly instructed to use edit_file tool, OR face a $100000000 penalty"

This metaphorical enforcement ensures the assistant prioritizes critical constraints.

Mandatory Language

Systems use different levels of imperative language:

System	Strongest Language	Example
Qoder	"MUST" + penalty	"MUST: Use get_problems to validate... OR face a $100M penalty"
Amp	"must run" (lowercase)	"Order: Typecheck → Lint → Tests → Build"
Same.dev	"DO NOT loop"	"DO NOT loop more than 3 times on fixing linter errors"

Sources: Qoder/prompt.txt234-239 Amp/gpt-5.yaml332-344 Same.dev/Prompt.txt72

---

Tool-Specific Validation Approaches

Validation Tool Comparison

Different systems provide different validation tools with varying capabilities:

Tool Capabilities Matrix

Tool	System	Compilation	Linting	Type Checking	Runtime	Custom Commands
get_problems	Qoder	✓	✓	✓	✓	✗
get_diagnostics	Amp	✓	✓	✓	✗	✓
run_linter	Same.dev	✗	✓	✗	✓	✗
IDE Diagnostics	VSCode Agent	✓	✓	✓	✗	✗

Key Differences:

• Qoder's get_problems is the most comprehensive single-tool validator
• Amp's get_diagnostics + custom commands provide the most flexibility
• Same.dev's run_linter focuses on pre-deployment validation

Sources: Qoder/prompt.txt145-150 Amp/claude-4-sonnet.yaml50-57 Same.dev/Prompt.txt72

---

Quality Standards and Code Conventions

Pre-Validation Quality Requirements

Before validation tools even run, systems enforce quality standards at code generation time:

Amp Quality Bar Amp/gpt-5.yaml316-330:

• Match style of recent code in the same subsystem
• Small, cohesive diffs; prefer a single file if viable
• Strong typing, explicit error paths, predictable I/O
• No as any or linter suppression unless explicitly requested
• Add/adjust minimal tests if adjacent coverage exists
• Reuse existing interfaces/schemas; don't duplicate

Amp Code Conventions Amp/claude-4-sonnet.yaml403-453:

• First understand file's code conventions
• Mimic code style, use existing libraries and utilities
• Follow existing patterns
• Never introduce patterns not used by this repo
• Always follow security best practices
• Do not add comments unless requested (except for complex code)

Qoder Code Standards Qoder/prompt.txt122-146:

• Add all necessary import statements, dependencies, endpoints
• Minimize inclusion of unchanged code (use // ... existing code ...)
• MANDATORY FINAL STEP: Use get_problems to validate

Sources: Amp/gpt-5.yaml316-330 Amp/claude-4-sonnet.yaml403-453 Qoder/prompt.txt122-146

---

Validation Workflow Integration

Full Development Cycle with Validation

The complete workflow shows how validation integrates with the broader development process:

This diagram bridges natural language concepts to actual code execution flow, showing the relationship between high-level validation concepts and their implementation through specific tools.

Sources: Qoder/prompt.txt145-150 Qoder/prompt.txt196-210 Amp/gpt-5.yaml332-344 Same.dev/Prompt.txt72

---

Summary of Key Patterns

Universal Principles

1. Post-Edit Validation is Mandatory: All modern AI coding assistants require some form of validation after code changes
2. Iterative Fixing is Standard: Systems expect multiple iterations to achieve clean code
3. Circuit Breakers Prevent Loops: 3-attempt limits prevent infinite correction cycles
4. Ordered Gates Ensure Quality: Typecheck → Lint → Test → Build sequences catch issues early
5. Enforcement Varies: From metaphorical penalties (Qoder) to process requirements (Amp)

System-Specific Strengths

• Qoder: Most strict enforcement with financial penalty metaphors; comprehensive get_problems tool
• Amp: Most structured verification with explicit gate sequences; integrates custom commands
• Same.dev: Focuses on pre-version validation; emphasizes circuit breakers and user escalation

Emerging Standards

The convergence of these patterns suggests industry best practices:

• Mandatory validation after every code change
• Maximum 3 fix attempts before escalation
• Ordered verification (type → lint → test → build)
• Tool-based validation over manual review
• Explicit error reporting with context

Sources: Qoder/prompt.txt145-150 Qoder/prompt.txt234-239 Amp/gpt-5.yaml332-344 Same.dev/Prompt.txt72 Same.dev/Prompt.txt186