Del vibe al production-grade

La rutina cambió por completo. Antes, el día era excavar documentación de APIs, probar código línea por línea, descubrir si el lenguaje usa substring in string, string.includes() o string.contains() — y depurar la distancia entre el código funcional y la intención original. Hoy, coding agents como Antigravity y Gemini CLI no solo sugieren texto: usan herramientas, ejecutan tareas y producen mil líneas documentadas en minutos.

El problema: la Illusion of Speed es real. El bug-to-code ratio sigue siendo un desafío — la IA escribe mucho más rápido, pero también genera errores potenciales a una tasa sin precedentes. Y cuando un agente alucina (el modelo inventa confiadamente algo que no es verdad), no crea un bug: crea mil líneas de lógica "vibe-consistent" y funcionalmente rota.

En el mundo tradicional, a los devs se les enseña a ser "Code-First": idea vaga → abrir el editor → escribir hasta que algo funcione. En la era de la Agentic AI, la mayor parte del tiempo se vuelve escribir especificaciones de alta calidad — instrucciones técnicas detalladas que le dicen a la IA exactamente qué construir. El rol del dev se acerca más a technical architect que a coder tradicional.

Los coding agents usan el LLM como cerebro (razonar) y herramientas como manos (ejecutar). La consecuencia directa:

Una spec production-grade funciona como Architectural North Star: previene la "context fragmentation" — el equivalente digital del juego del teléfono descompuesto, donde la IA pierde el hilo porque mira snapshots desactualizados de archivos. La IA puede ser coautora o revisora de la spec; vive en el codebase (carpeta specs/, en Markdown o YAML) y actúa como source of truth para humanos y máquinas.

Qué contiene una spec de proyecto nuevo

El estudio SkCC (Ouyang et al., 2026 — "Portable and Secure Skill Compilation for Cross-Framework LLM Agents") mostró que los agentes exhiben sensibilidad extrema a cómo se formatean las instrucciones: hasta 40% de caída de performance con Markdown genérico no optimizado. Los investigadores crearon SkCC (Skill Compiler): una herramienta ultrarrápida que compila el archivo de instrucción single-source al formato objetivo óptimo del modelo en menos de 10 milisegundos.

Una spec BDD es la herramienta final para convertir ideas vagas y ambiguas en un diseño preciso que el agente puede construir sin adivinar. Behavior Driven Development usa lenguaje natural simple y estructurado para describir exactamente cómo debe comportarse el sistema desde la perspectiva del usuario antes de escribir cualquier código. La sintaxis estandarizada es Gherkin: un template declarativo Scenario / Given / When / Then que fuerza al LLM a pensar en State → Action → Outcome — eliminando completamente el "vibe coding" y manteniendo al agente en una pista estricta.

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

Las specs ejecutables vencen a la prosa: cada escenario se vuelve un test verificable, y el agente sigue una pista estricta en lugar de interpretar párrafos ambiguos.

⚛️ La física de los tokens

Los LLMs no interpretan estructuras de datos — procesan texto tokenizado. Cada carácter enviado se descompone en tokens; cada token consume budget, tiempo y capacidad de contexto. Escribir specs production-grade es tratar la tokenización como una restricción física rígida: cada newline y espacio de indentación se traduce directamente en budget de desarrollo y latencia. Incluso plataformas generosas como Antigravity están limitadas por la física de tokens de los modelos subyacentes — cada espacio innecesario en un YAML anidado y cada Given/When/Then repetitivo consume ciclos y attention-heads en loops de razonamiento multi-turno. Trata /specs no como documentación, sino como un conjunto de instrucciones compilado y enxuto: Markdown legible por humanos + bloques YAML planos y altamente dirigidos.

Para practicar SDD, entiende cómo las herramientas de coding consumen instrucciones: no se escriben en un único lugar. Tirar un documento masivo de diseño de sistema de 100 páginas directo en la ventana de chat agota el budget de contexto de corto plazo, aumenta la latencia y fragmenta el contexto. Las instrucciones viven en tres capas:

No existe una única forma de transformar una spec en código — cada trabajo pide un execution mode diferente. Haz clic en los personajes para ver el playbook de cada uno:

El Model Context Protocol (creado por Anthropic, hoy estándar abierto) es apodado "the USB-C for AI tools" — una exageración, pero la analogía captura la idea: construye un servidor MCP para tu base de datos, API o sistema de archivos, y cualquier agente compatible puede usarlo sin escribir integración personalizada.

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())

Trabajar con coding agents modernos exige un cambio de mentalidad y de cultura. Sin él, el escenario clásico: los PRs se vuelven enormes, los conflictos de merge se multiplican (devs llegando a los mismos archivos) y la cadena de dependencias se vuelve imposible de desenredar — el PR #1 no mergea sin el PR #2, que necesita el PR #3, bloqueado por un revisor en otro huso horario. Algunos cambios aprobados mientras los relacionados esperan → aún más conflictos. De repente: branch roto.

Estrategias para integración de alta velocidad

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

Puedes escribir un gran prompt de review — pero la skill solo corre cuando se invoca desde dentro del IDE. El siguiente paso es el revisor continuo: servicios que observan el repositorio, reaccionan a eventos (PR abierto, cron nocturno) y publican hallazgos sin que nadie lo pida. Atrapan lo que los revisores cansados pierden un viernes por la tarde: una dependencia con un CVE nuevo, un TODO de 6 meses que se volvió una brecha silenciosa. Cuando el equipo envía PRs generados por IA en volumen, el revisor continuo es lo único que escala con el output. La pregunta es qué tan custom necesitas ir — la respuesta es un espectro de 3 tiers:

Las 3 preguntas que te dicen qué tier necesitas

En codebases legacy de cien millones de líneas, cargar código como texto plano en la ventana de contexto se queda sin espacio, y el RAG estándar elimina la estructura que hace el código legible (una clase pertenece a un archivo, una llamada de función remite a un doc de requisitos escrito hace una década). Aplanar todo en un vector store = el mapa desaparece. El patrón que emergió de las mayores modernizaciones: construir el agente sobre un knowledge graph — ingerir código, docs, tickets y PDFs de diseño en un graph database (ej.: Spanner Graph) y combinar 3 modos de retrieval:

Resumen del espectro: Managed = revisor genérico en minutos · Hybrid = TU revisor en un día · Custom = un revisor que entiende el sistema ENTERO — al costo de ser dueño del runtime y de la evaluation.

Un fenómeno nuevo: ante un flujo constante de micro-aprobaciones (mejorar una sola línea, ajustar una tool call), los devs empiezan a hacer clic en "Approve" reflexivamente. Es una forma de agotamiento de bajo grado en la que el equipo deja de verificar el trabajo de la máquina solo para mantener el ritmo — y pierde atención a los detalles. La supervisión constante no escala; los límites estructurados, sí.

Durante una actualización de rutina, el autor descubrió el poder — y los límites — del browser integrado de Antigravity: el recurso permite al agente interactuar con aplicaciones en desarrollo sin credenciales de login (invaluable para tests de UX). Pero en modo YOLO (auto approve), el agente puede actuar más rápido de lo que un humano puede pensar. Un prompt simple para crear un botón disparó la siguiente cadena:

El incidente destacó el riesgo de context hallucination: cuando la IA no tiene datos suficientes, llena huecos usando cualquier string que exista en el contexto — incluyendo información sensible como direcciones de email hardcodeadas o URLs. Puede parecer menor si es "solo un email". Pero considera lo que el agente estaba haciendo: cumpliendo su directiva con los datos disponibles, sin ninguna verificación de si debía. Ese es el riesgo central de los sistemas autónomos.

A medida que los límites de la Agentic AI se expanden, surge una paradoja: los agentes deben ser lo suficientemente autónomos para resolver problemas complejos, pero no puedes asumir el riesgo de que se vuelvan "rogue" en un entorno enterprise. Imagina un agente encargado de "resolver disputas de clientes": para ser eficaz, necesita acceso a datos de clientes, herramientas de email y sistemas internos — pero el desafío es garantizar que no envíe email accidentalmente a la base de datos entera o comparta código propietario.

Más allá de sanitizar strings, la seguridad real requiere un entorno de ejecución restringido para contener las acciones del agente. Incluso con filtrado riguroso de output, el LLM puede generar código sintácticamente válido pero lógicamente malicioso. Ejecutar tareas en contenedores efímeros y de bajo privilegio — aislados de la red principal y de sistemas de archivos sensibles — crea un "blast radius" que protege la infraestructura central: si el agente es engañado para ejecutar un comando destructivo, el daño queda confinado a una instancia desechable, limpiada y reiniciada sin consecuencias.

comando destructivo → error de permisos rígido a nivel del kernel → host completamente intacto

Aunque la automatización es el objetivo, las operaciones de alto riesgo exigen un protocolo Human-in-the-Loop (HITL) como fail-safe final: checkpoint gates para acciones que cumplen un perfil de riesgo específico. Presentar la intención sanitizada del agente a un supervisor humano para aprobación manual equilibra la velocidad de la IA con el juicio matizado del dev — y garantiza que la responsabilidad final por la integridad arquitectónica permanezca en manos humanas.

El auge de los tests generados por IA

El auge del código generado por IA empuja el proceso de los tests manuales hacia la cobertura de tests generada por IA — y aquí la IA tiene ventaja estructural: como la implementación ya no es el cuello de botella, puede escribir una cobertura de tests más amplia que cualquier humano en el mismo tiempo, de forma programática y poderosa. En un entorno de alta velocidad, el test-driven development se vuelve realidad: la máquina escribe los propios tests que validan su output.

El proceso fuerza al agente a producir un test unitario que falle o un comando de reproducción (como un request curl) antes de intentar cualquier corrección. Incrustar estos tests en el codebase significa que cada iteración rápida está respaldada por una suite verificable — los bugs no vuelven, y los revisores humanos pueden confiar en la "luz verde" automatizada para la integración.

¿Por qué chequeos de calidad especiales para sistemas dirigidos por ML? Porque los tests de software tradicionales son insuficientes para sistemas cuyo output es generado en lugar de computado. Un agente (o cualquier componente dirigido por ML — clasificador, resumidor, retriever) puede pasar 100 tests unitarios de sus herramientas y aún fallar espectacularmente eligiendo la herramienta equivocada, parafraseando una respuesta crítica o alucinando un hecho. El margen de error no es un defecto a eliminar — es una propiedad inherente del modelo, y la estrategia de tests debe acomodarlo.

El ejemplo central de guardrail del paper es el Hybrid Policy Server: un middleware que intercepta acciones antes de que lleguen a sistemas externos, operando en dos capas complementarias.

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")

Un peligro significativo del desarrollo autónomo es la Context Hallucination: sin datos específicos, el agente llena huecos con cualquier string disponible en el contexto — potencialmente filtrando direcciones de email hardcodeadas o URLs privadas. La mitigación es Context Hygiene rigurosa vía middleware: PII masking e inyección de placeholders, para que el agente siempre opere con datos esterilizados. Y todo output del agente debe sanitizarse contra prompt injection e interacciones de UI rogue — el "vibe" de la máquina nunca debe volverse una vulnerabilidad arquitectónica.

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

Con el middleware conectado directamente al pipeline de ejecución, cualquier intento del agente de ejecutar una acción — enviar email, consultar una presentación en la nube — es interceptado. El engine traduce placeholders como [[COMMENTER_EMAIL]] o [[DEFAULT_PRESENTATION_ID]] en assets de prueba autorizados, de forma segura y silenciosa — eliminando PII hardcodeado de test suites y system prompts.

En menos de un año, los ciclos de desarrollo se volvieron dramáticamente más rápidos. Pero la velocidad reveló el cambio importante: la IA eliminó el cuello de botella de producción de código y movió la restricción río abajo — a los humanos que deben revisar, probar e integrar ese output. Esto es carga cognitiva compartida: los humanos actúan como arquitectos (Test Specs, Integration Specs, blueprints de MLOps/DevOps), mientras la IA se encarga del trabajo pesado (código de tests real, integraciones, detalles operacionales granulares).

El éxito depende de evolucionar las dinámicas de equipo, refinar la colaboración con agentes y definir límites estrictos para herramientas que nunca duermen. El desafío cambió de la mera producción de código a orquestar sistemas que verifican, integran y entregan trabajo.

🚀 Los patrones se vuelven comandos que puedes ejecutar hoy

# 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