From vibe to production-grade

The routine has completely changed. Before, the day was digging through API docs, testing code line by line, figuring out whether the language uses substring in string, string.includes() or string.contains() — and debugging the gap between working code and the original intent. Today, coding agents like Antigravity and Gemini CLI don't just suggest text: they use tools, execute tasks and churn out a thousand documented lines in minutes.

The problem: the Illusion of Speed is real. The bug-to-code ratio is still a challenge — AI writes much faster, but it also generates potential errors at an unprecedented rate. And when an agent hallucinates (the model confidently invents something that isn't true), it doesn't create one bug: it creates a thousand lines of "vibe-consistent", functionally broken logic.

In the traditional world, devs are taught to be "Code-First": vague idea → open the editor → type until something works. In the Agentic AI era, most of the time becomes writing high-quality specifications — detailed technical instructions that tell the AI exactly what to build. The dev's role moves closer to technical architect than to traditional coder.

Coding agents use the LLM as the brain (reasoning) and tools as the hands (execution). The direct consequence:

A production-grade spec works as the Architectural North Star: it prevents "context fragmentation" — the digital equivalent of the telephone game, where the AI loses the thread because it looks at outdated snapshots of files. The AI can co-author or review the spec; it lives in the codebase (a specs/ folder, in Markdown or YAML) and acts as the source of truth for humans and machines.

What a spec for a new project contains

The SkCC study (Ouyang et al., 2026 — "Portable and Secure Skill Compilation for Cross-Framework LLM Agents") showed that agents exhibit extreme sensitivity to how instructions are formatted: up to a 40% performance drop with unoptimized generic Markdown. The researchers created SkCC (Skill Compiler): an ultra-fast tool that compiles the single-source instruction file into the model's optimal target format in under 10 milliseconds.

A BDD spec is the ultimate tool for turning vague, ambiguous ideas into a precise design the agent can build without guessing. Behavior Driven Development uses simple, structured natural language to describe exactly how the system should behave from the user's perspective before any code is written. The standardized syntax is Gherkin: a declarative Scenario / Given / When / Then template that forces the LLM to think in State → Action → Outcome — completely eliminating "vibe coding" and keeping the agent on a strict track.

Feature: Retry de pagamentoScenario: Cartão recusado, nova tentativa automáticaGiven um pedido "#8842" com pagamento "recusado"And o cliente tem 2 tentativas restantesWhen o webhook "payment.retried" é recebidoThen o sistema agenda nova tentativa em 30 minutosAnd o cliente recebe notificação por email

Executable specs beat prose: each scenario becomes a verifiable test, and the agent follows a strict track instead of interpreting ambiguous paragraphs.

⚛️ The physics of tokens

LLMs don't interpret data structures — they process tokenized text. Every character sent is broken into tokens; each token consumes budget, time and context capacity. Writing production-grade specs means treating tokenization as a hard physical constraint: every newline and indentation space translates directly into development budget and latency. Even generous platforms like Antigravity are bounded by the token physics of the underlying models — every unnecessary space in nested YAML and every repetitive Given/When/Then consumes cycles and attention-heads in multi-turn reasoning loops. Treat /specs not as documentation, but as a compiled, lean instruction set: human-readable Markdown + flat, highly targeted YAML blocks.

To practice SDD, understand how coding tools consume instructions: they are not written in a single place. Dumping a massive 100-page system design document straight into the chat window exhausts the short-term context budget, increases latency and fragments the context. Instructions live in three layers:

There is no single way to turn a spec into code — each job calls for a different execution mode. Click the characters to see each one's playbook:

The Model Context Protocol (created by Anthropic, now an open standard) is nicknamed "the USB-C for AI tools" — an exaggeration, but the analogy captures the idea: build one MCP server for your database, API or file system, and any compatible agent can use it without writing a custom integration.

from mcp.server import Serverfrom mcp.server.stdio import stdio_serverimport sqlite3 server = Server("knowledge-base") conn = sqlite3.connect("knowledge.db")@server.list_tools()async def list_tools():return [{"name": "query_knowledge","description": "Query the knowledge base with SQL","inputSchema": {"sql": "SQL query to execute (SELECT only)"}},{"name": "add_knowledge","description": "Add a new knowledge entry","inputSchema": {"title": ..., "content": ..., "tags": "Comma-separated tags"}}, ]@server.call_tool()async def call_tool(name, arguments):if name == "query_knowledge": sql = arguments["sql"]if not sql.strip().upper().startswith("SELECT"):return "Error: Only SELECT queries allowed"rows = conn.execute(sql).fetchall()return [dict(zip(cols, r)) for r in rows]   # → TextContentif name == "add_knowledge": conn.execute("INSERT INTO knowledge (title, content, tags) VALUES (?, ?, ?)", ...) conn.commit(); return "Knowledge entry added."async def main():async with stdio_server() as (r, w):await server.run(r, w, server.create_initialization_options())

Working with modern coding agents demands a mindset and culture shift. Without it, the classic scenario: PRs become huge, merge conflicts multiply (devs hitting the same files) and the dependency chain becomes impossible to untangle — PR #1 can't merge without PR #2, which needs PR #3, blocked by a reviewer in another timezone. Some changes approved while related ones wait → even more conflicts. Suddenly: broken branch.

Strategies for high-velocity integration

Act as a Senior Software Engineer and Security Researcher. Review the provided code for this Github PR or Diff using these strict criteria: Use the command line to fetch the Github PR: `gh pr view <PR NUMBER>` First analyze the code, then code review: 1. **Critical Vulnerabilities:** Check for hardcoded secrets (API keys), SQL injection, XSS, or broken authentication. 2. **Logic & Efficiency:** Identify "off-by-one" errors, infinite loops, or redundant API calls. 3. **Readability:** Suggest better naming conventions or breaking down "megafunctions" into smaller pieces. 4. **Edge Cases:** What happens if the input is null? What if the network fails? Output Format: - **Description:** - What is this PR doing? Explain in details. ISSUES: -⚠ **Critical:** (Stop-ship issues) -⚠️ **Warnings:** (Code smells or style issues) -✅ **Best Practices:** (Specific lines to refactor for better performance) -💡 **Quick Win:** (One sentence summary of the biggest improvement) When there are no issues return - **Description:** - What is this PR doing? Explain in details. LGTM

You can write a great review prompt — but the skill only runs when invoked from inside the IDE. The next step is the continuous reviewer: services that watch the repository, react to events (PR opened, nightly cron) and post findings without anyone asking. They catch what tired reviewers miss on a Friday afternoon: a dependency with a new CVE, a 6-month-old TODO that became a silent breach. When the team ships AI-generated PRs at volume, the continuous reviewer is the only thing that scales with the output. The question is how custom you need to go — the answer is a 3-tier spectrum:

The 3 questions that tell you which tier you need

In hundred-million-line legacy codebases, loading code as plain text into the context window runs out of space, and standard RAG removes the structure that makes code readable (a class belongs to a file, a function call points to a requirements doc written a decade ago). Flattening everything into a vector store = the map disappears. The pattern that emerged from the biggest modernizations: build the agent on top of a knowledge graph — ingest code, docs, tickets and design PDFs into a graph database (e.g. Spanner Graph) and combine 3 retrieval modes:

Summary of the spectrum: Managed = generic reviewer in minutes · Hybrid = YOUR reviewer in a day · Custom = a reviewer that understands the ENTIRE system — at the cost of owning the runtime and the evaluation.

A new phenomenon: faced with a constant flow of micro-approvals (improve a single line, adjust a tool call), devs start clicking "Approve" reflexively. It's a form of low-grade exhaustion where the team stops verifying the machine's work just to keep up with the pace — and loses attention to detail. Constant supervision doesn't scale; structured boundaries do.

During a routine update, the author discovered the power — and the limits — of Antigravity's built-in browser: the feature lets the agent interact with applications under development without login credentials (invaluable for UX testing). But in YOLO mode (auto approve), the agent can act faster than a human can think. A simple prompt to create a button triggered the following chain:

The incident highlighted the risk of context hallucination: when the AI doesn't have enough data, it fills gaps using whatever strings exist in the context — including sensitive information like hardcoded email addresses or URLs. It may seem minor if it's "just an email". But consider what the agent was doing: fulfilling its directive with the available data, without any verification of whether it should. That is the core risk of autonomous systems.

As the boundaries of Agentic AI expand, a paradox emerges: agents must be autonomous enough to solve complex problems, but you can't afford the risk of them going "rogue" in an enterprise environment. Imagine an agent tasked with "resolving customer disputes": to be effective, it needs access to customer data, email tools and internal systems — but the challenge is guaranteeing it doesn't accidentally email the entire database or share proprietary code.

Beyond sanitizing strings, real security requires a restricted execution environment to contain the agent's actions. Even with rigorous output filtering, the LLM can generate syntactically valid but logically malicious code. Running tasks in ephemeral, low-privilege containers — isolated from the main network and sensitive file systems — creates a "blast radius" that protects the core infrastructure: if the agent is tricked into running a destructive command, the damage is confined to a disposable instance, cleaned and reset with no consequences.

destructive command → hard permission error at kernel level → host completely untouched

Although automation is the goal, high-risk operations require a Human-in-the-Loop (HITL) protocol as the final fail-safe: checkpoint gates for actions that match a specific risk profile. Presenting the agent's sanitized intent to a human supervisor for manual sign-off balances AI speed with the dev's nuanced judgment — and guarantees that final responsibility for architectural integrity stays in human hands.

The surge of AI-generated tests

The surge of AI-generated code pushes the process from manual testing to AI-generated test coverage — and here AI has a structural advantage: since implementation is no longer the bottleneck, it can write broader test coverage than any human in the same time, programmatically and powerfully. In a high-velocity environment, test-driven development becomes real: the machine writes the very tests that validate its output.

The process forces the agent to produce a failing unit test or a reproduction command (like a curl request) before attempting any fix. Embedding these tests in the codebase means every fast iteration is backed by a verifiable suite — bugs don't come back, and human reviewers can trust the automated "green light" for integration.

Why special quality checks for ML-driven systems? Because traditional software tests are insufficient for systems whose output is generated rather than computed. An agent (or any ML-driven component — classifier, summarizer, retriever) can pass 100 unit tests on its tools and still fail spectacularly by picking the wrong tool, paraphrasing a critical answer or hallucinating a fact. The error margin is not a defect to eliminate — it's an inherent property of the model, and the testing strategy must accommodate it.

The paper's central guardrail example is the Hybrid Policy Server: middleware that intercepts actions before they reach external systems, operating in two complementary layers.

environments:localhost:blocked_tools:- send_emailroles:viewer:allowed_tools:- list_files- read_file

def is_tool_allowed(self, tool_name):# 1) Environment blocksif tool_name in env_blocked: return False# 2) Role permissionsreturn "*" in role_allows or \ tool_name in role_allowsdef check_action_semantic(self, action_description): client = Client(vertexai=True) prompt = "Evaluate if this action violates " \f"PII policies: {action_description}"response = client.ai.models.generate_content( model="gemini-3.1-pro", contents=prompt)return not response.text.startswith("VIOLATION")

A significant danger of autonomous development is Context Hallucination: without specific data, the agent fills gaps with whatever strings are available in the context — potentially leaking hardcoded email addresses or private URLs. The mitigation is rigorous Context Hygiene via middleware: PII masking and placeholder injection, so the agent always operates on sterilized data. And every agent output must be sanitized against prompt injection and rogue UI interactions — the machine's "vibe" must never become an architectural vulnerability.

def resolve_context(template_str, override_state):def replacement(match): var_name = match.group(1)# 1) Prioriza overrides de runtime stateif var_name in state_to_check \and state_to_check[var_name] is not None:return state_to_check[var_name]# 2) Fallback para env vars validadasif var_name in os.environ:return os.environ[var_name]# 3) Deixa não resolvido — sem falhas silenciosasreturn match.group(0)return re.sub(r'\[\[([^\]]+)\]\]', replacement, template_str)# ex.: resolve [[COMMENTER_EMAIL]] dinamicamente

def validate_tool_call(tool_call): args = tool_call.function_call.args resolved_args = for k, v in args.items():if isinstance(v, str): resolved_args[k] = resolve_context( v, override_state)elif isinstance(v, list): resolved_args[k] = [resolve_context(i, override_state)if isinstance(i, str) else ifor i in v]else: resolved_args[k] = v args.clear(); args.update(resolved_args)# intercepta TODA tool call ANTES de rodar

With the middleware wired directly into the execution pipeline, any attempt by the agent to run an action — sending email, querying a cloud presentation — is intercepted. The engine translates placeholders like [[COMMENTER_EMAIL]] or [[DEFAULT_PRESENTATION_ID]] into authorized test assets, safely and silently — eliminating hardcoded PII from test suites and system prompts.

In less than a year, development cycles became dramatically faster. But the speed revealed the important shift: AI eliminated the code-production bottleneck and moved the constraint downstream — to the humans who must review, test and integrate that output. This is shared cognitive load: humans act as architects (Test Specs, Integration Specs, MLOps/DevOps blueprints), while AI handles the heavy lifting (actual test code, integrations, granular operational details).

Success depends on evolving team dynamics, refining collaboration with agents and setting strict boundaries for tools that never sleep. The challenge changed from mere code production to orchestrating systems that verify, integrate and deliver work.

🚀 The patterns become commands you can run today

# geração de projeto spec-drivenagents-cli scaffold# gate de cobertura de testes gerada por IAagents-cli eval run# deployment com sandbox para Cloud Run ou Vertex AI Agent Engineagents-cli deploy