La guía que nadie te dio — desde alguien que lleva meses corriendo esto en producción

Karpathy acuñó el término en 2025: vibe coding. Describes lo que quieres, la IA lo genera, tú lo pegas. Funciona perfecto para un prototipo un sábado.

Luego intentaste llevarlo a producción.

Ahí fue donde todo se fue al carajo.

En 2026 Karpathy volvió y le puso nombre a lo que viene después: agentic engineering. No es AI como autocomplete. Es AI como equipo de ingeniería — agentes que planean, escriben, testean y despliegan código bajo supervisión estructurada.

Yo llevo haciendo esto desde hace seis meses con OpenClaw. No como experimento — en producción, en Aegon, en BEU. Aquí lo que aprendí.

La diferencia real entre vibe coding y agentic engineering

No es filosófica. Es operativa.

Vibe coding: tú describes, la IA genera, tú aceptas o rechazas. Proceso lineal. Un solo modelo. Sin estructura.

Agentic engineering: tú diseñas el sistema. Los agentes ejecutan dentro de él. Tú supervisas los puntos críticos.

El error que casi todo el mundo comete al principio es asumir que la diferencia está en el modelo. "Necesito un modelo mejor." No. El modelo no es el problema. El contexto que le das — las restricciones, las instrucciones, los checks — eso es lo que determina si el output sirve o no.

Hay un paper de arxiv de este año que lo llama constraint decay: los agentes pierden en promedio 30 puntos de performance en benchmarks cuando les metes restricciones estructurales reales (frameworks complejos, ORMs, arquitecturas de microservicios). En Flask funcionan bien. En FastAPI con arquitectura de capas empiezan a inventar cosas.

La solución no es quitarles las restricciones. Es ingeniería de contexto — darles exactamente la información correcta en el momento correcto.

El marco que uso: Plan → Execute → Verify

Todo empieza con estructura. Sin esto, tienes vibe coding con aspiraciones.

Plan (donde el 80% de la gente falla)

Antes de que cualquier agente escriba una línea de código, necesitas:

1. Definir qué es "listo"
No "hacer el endpoint de usuarios". Sino: "El endpoint GET /users devuelve una lista paginada de usuarios activos, maneja errores 404 y 500 con el formato de error estándar del proyecto, y tiene tests unitarios que cubren casos felices y de error."

La especificidad es proporcional al resultado. Una spec vaga produce código vago.

2. Establecer las restricciones
¿Qué stack? ¿Qué patrones arquitecturales existen en el codebase? ¿Hay convenciones de naming? ¿Qué no puede tocar el agente?

Esto va en el equivalente de tu CLAUDE.md — un archivo de contexto que el agente lee al inicio de cada sesión. Sin esto, el agente improvisa desde cero cada vez.

3. Definir los quality gates
¿Qué tests tienen que pasar? ¿Qué herramientas de linting corren antes del PR? ¿Qué no puede romper?

Los quality gates son la diferencia entre un agente que entrega código revisable y uno que entrega código que "parece que funciona".

Execute (donde el agente trabaja)

Aquí es donde el agente corre autónomamente. Tu trabajo es no interferir — a menos que se atasque en algo que requiera juicio humano.

Un pipeline típico:

graph LR
    A[Tarea definida] --> B[Agente escribe código]
    B --> C[Tests automáticos]
    C --> D[Review de arquitectura]
    D --> E[Security check]
    E --> F[PR para revisión humana]

Cada nodo del pipeline tiene su rol. El agente de implementación no revisa seguridad. El agente de security scan no toca el código — solo reporta. La documentación se actualiza sola después del merge.

Verify (donde recuperas el control)

Esta es la fase que la gente subestima. Verificar no es hacer clic en "merge" sin leer. Es evaluar si el output del agente:

  • Cumple lo que definiste en Plan
  • No introdujo deuda técnica silenciosa
  • Los tests son reales (no solo happy path)
  • La arquitectura es consistente con el resto del codebase

Leyendo código generado por IA necesitas detectar el AI slop — código que parece razonable pero tiene abstracciones innecesarias, error handling redundante, o APIs alucinadas que no existen.

Lees más código del que nunca leíste. Solo que no lo escribiste tú.

El equipo de agentes

La imagen mental equivocada: un solo agente superinteligente que hace todo.

La imagen correcta: un equipo especializado con roles definidos.

Rol Qué hace
Implementación Escribe código. Único responsable de cambios en el codebase
Testing Genera y corre el suite de tests
Code Review Verifica estilo, patrones, arquitectura
Security Identifica vulnerabilidades antes del merge
Documentación Mantiene los docs sincronizados con el código
Orquestador Distribuye tareas, maneja conflictos, escala a humano cuando necesita

La clave que tardé en entender: los agentes no se deben solapar. El de implementación no escribe documentación. El de security scan no toca el código. Cuando hay ambigüedad sobre quién hace qué, escala al orquestador.

El conflicto de roles es una de las razones principales por las que los sistemas multi-agente fallan en producción.

Lo que sí funciona en producción

Specs antes de ejecutar. Los 10 minutos escribiendo una spec clara ahorran 4 horas de rework. Sin excepción.

CI agresivo. El agente no puede mergear nada que no pase tests. Suena obvio. La mayoría no lo hace.

Contexto como primera clase. El archivo de contexto del agente (CLAUDE.md, el archivo de arquitectura, las convenciones del proyecto) es tan importante como el código. Si el contexto es vago, el output es vago.

Un agente por dominio. La tentación es hacer un agente que sepa todo. El resultado es un agente que hace todo mal.

Lo que todavía no funciona (honestidad brutal)

Proyectos multi-día totalmente autónomos. Los agentes todavía necesitan checkpoints humanos cada pocas horas en trabajo complejo. Si los dejas correr 24 horas sin verificar, el drift acumulado es enorme.

Refactors cross-servicio. Un solo servicio, bien. Cambios coordinados a través de múltiples microservicios, todavía necesita supervisión estrecha.

Decisiones de arquitectura sin precedente. Cuando no hay ejemplos en el codebase, los agentes defaultean a patrones genéricos que no encajan. Eso requiere que un humano plante la primer piedra.

Por dónde empezar

Si estás en vibe coding y quieres cruzar a agentic engineering, el camino es gradual:

Semana 1 — Añade estructura a lo que ya haces:

  • Escribe una spec antes de cada prompt. Una oración sirve, pero escríbela.
  • Crea un archivo CLAUDE.md en tu proyecto con las convenciones del codebase.
  • Nunca aceptes código sin correr los tests.

Mes 1 — Separación de roles:

  • Agente de implementación separado del de testing.
  • CI que el agente no puede saltarse.
  • Documentación que se actualiza automáticamente.

Mes 3+ — Multi-agente real:

  • Orquestador que distribuye tareas.
  • Agentes especializados con alcance definido.
  • Métricas: tasa de éxito, tasa de rechazo en review, bugs introducidos.

El cambio de mentalidad

Las empresas que están multiplicando su capacidad de ingeniería no tienen menos ingenieros. Tienen ingenieros haciendo trabajo de arquitecto todo el tiempo.

Stripe tiene agentes que abren 1,000 PRs por semana. Un developer postea la tarea en Slack. El agente escribe el código, pasa CI, abre el PR. El developer revisa y mergea. Cero interacción entre asignación y review.

Eso no es magia. Es proceso. Y el proceso lo diseñaron ingenieros.

La diferencia entre vibe coding y agentic engineering no es la IA que usas.

Es que en agentic engineering, tú eres el arquitecto del sistema donde la IA trabaja.

Y armar ese sistema bien — eso sí es ingeniería.

¿Estás corriendo agentes en producción? Cuéntame qué está funcionando y qué no — @bottico