Vibe Coding frente a Agentic Engineering: lo que argumenta el nuevo documento de Google sobre SDLC

De un eslogan a un informe técnico

A principios de 2025, Andrej Karpathy esbozó un estilo de programación en el que uno se entrega por completo a las sensaciones, sigue la curva exponencial y deja de preocuparse por la existencia del código. El ciclo consistía en generar una solicitud, aceptarla, ejecutarla y, en caso de error, devolver el mensaje de error. La denominación se difundió de inmediato, aunque la gente ya trabajaba de esa manera; simplemente le faltaba un nombre.

Unos dieciséis meses después, Google publicó un informe técnico de 50 páginas titulado “El nuevo SDLC con Vibe Coding”, escrito por Addy Osmani, Shubham Saboo y Sokratis Kartakis. Es denso y está bien estructurado, y su mensaje es contundente: el Vibe Coding era adecuado para prototipos, pero poco a poco está dañando los sistemas de producción, y muchos equipos no se dan cuenta porque el daño se acumula gradualmente. Las secciones siguientes abordan el argumento del informe, su línea divisoria clara y sus implicaciones para quienes desarrollen con agentes de IA en 2026.

Por qué funcionó el Vibe Coding y dónde termina

El Vibe Coding se popularizó porque redujo las barreras para crear. Los prototipos se elaboraban en minutos, los no ingenieros podían armar herramientas funcionales, y el tiempo necesario para pasar de una idea a código ejecutable pasó de días a horas. Eso es valioso, y descartarlo sería snobismo técnico. Sin embargo, la barrera inferior nunca fue el problema; el problema es el techo.

Una vez que los agentes mejoraron, los equipos comenzaron a aplicar ese mismo hábito informal de pedir y aceptar soluciones de forma rápida en el trabajo en producción, incluyendo APIs de pago, lógica de autenticación, pipelines de datos y herramientas de salud. El resultado parece ordenado y generalmente pasa las pruebas básicas, por lo que se pone en producción. Unas semanas o meses después, algo falla de una manera que resulta costosa y difícil de rastrear.

La causa es estructural. El código rápido se creó para hacer que algo funcione de inmediato, no para cumplir con los requisitos de corrección propios de la producción, y son objetivos diferentes. Mezclarlos es la raíz de los problemas actuales. El documento técnico intenta proporcionar a los equipos el vocabulario y el marco necesarios para evitar esa mezcla.

Un espectro con un factor de división

El artículo presenta un espectro que va desde la codificación de la atmósfera en un extremo hasta la ingeniería agente en el otro. La mayoría de los profesionales se encuentran en algún punto intermedio y no pueden indicar con exactitud dónde, lo cual en sí mismo forma parte del problema.

Ese espectro abarca tres dimensiones: cómo se especifica la intención, cuán rigurosa es la verificación y el perfil de riesgo. Hay un factor que separa los extremos, y no es el modelo que se utilice, lo ingeniosos que sean los prompts ni la herramienta elegida. Se trata de cómo se verifican los resultados.

Se necesitan dos tipos de verificación. Las pruebas determinísticas buscan saber si una función devuelve la salida correcta para una entrada dada. Las evaluaciones de trayectoria determinan si el agente siguió la secuencia correcta de pasos de razonamiento para llegar allí. Sin ambas, se está programando de forma intuitiva, por más elaborada que parezca la configuración. Un resultado pulido y fluido que omite la verificación no es un éxito; es un fallo aún más peligroso que aquel que muestra un error, ya que permanece oculto hasta la fase de producción. Esa es la línea divisoria, y explica por qué muchos equipos con flujos de trabajo de agencias sofisticados siguen programando de forma intuitiva desde el punto de vista técnico.

El modelo no es la variable principal

Probablemente este sea el cambio técnico más importante en el artículo, y muchos desarrolladores lo interpretan mal. Cuando un agente se comporta de forma incorrecta, la reacción habitual es culpar al modelo por ser demasiado débil, demasiado lento o demasiado propenso a las alucinaciones, y asumir que un modelo mejor es la solución. Ese razonamiento está casi siempre equivocado.

El modelo es solo una parte. El resto, es decir, los prompts, las herramientas, las políticas de contexto, los entornos de ejecución aislados, los subagentes y la capacidad de observabilidad, constituyen el soporte necesario, y el comportamiento de un agente se debe mucho más a ese soporte que al modelo en sí. Dos puntos de datos del artículo respaldan esta idea. En Terminal Bench 2.0, un equipo logró elevar a un agente de programación del puesto 30 al 5 simplemente modificando el soporte. En otro estudio de LangChain, las modificaciones en el prompt del sistema, las herramientas y el middleware, manteniendo el modelo sin cambios, añadieron 13.7 puntos al resultado de referencia de dicho agente de programación.

Los archivos de reglas, las herramientas, los entornos de pruebas aisladas, la lógica de orquestación, las medidas de control y la capacidad de observación forman parte del conjunto de componentes necesario, y su desarrollo recae íntegramente en el equipo. El proveedor suministra el motor, mientras que el equipo construye el entorno de trabajo alrededor de él. Hablando con sinceridad, la mayoría de los fallos de los agentes se deben a problemas de configuración: una herramienta que falta, una regla poco clara, una medida de control ausente, o una ventana de contexto abarrotada de ruido. La culpa recae en el modelo, ya que es la capa visible, mientras que el defecto real se encuentra en el conjunto de componentes. Buscar actualizaciones del modelo y descuidar ese conjunto de componentes es como instalar un motor más rápido en un coche sin frenos.

La ingeniería de contexto reemplaza a la ingeniería de prompts

La ingeniería de prompts como disciplina independiente ha desaparecido en gran medida, y la ingeniería de contexto ha ocupado su lugar. Esto implica proporcionar a los agentes información detallada y organizada sobre la base de código, la arquitectura, las convenciones y la intención con la que trabajan. El artículo enumera seis tipos de contexto que necesita cada agente: instrucciones, conocimiento, memoria, ejemplos, herramientas y límites. Cada uno puede ser estático, presente en cada interacción, o dinámico, proporcionado según sea necesario.

El contexto estático es muy costoso, ya que cada token se transmite con cada llamada al modelo, independientemente de si es relevante o no. El exceso de tokens genera desperdicio, debilita la señal y puede afectar el rendimiento al ocultar reglas clave entre el ruido. El contexto dinámico es más económico, ya que proviene de pipelines RAG, desencadenantes de coincidencia de tareas o resultados de herramientas en el momento en que se necesitan. Elegir qué se incluye y dónde se coloca es un compromiso fundamental en ingeniería y no una simple nota de configuración; por lo tanto, merece versionado, revisión y la misma atención que otras decisiones de diseño.

El mejor patrón aquí son las Habilidades del Agente: paquetes estructurados y portátiles de conocimiento procedural que se cargan únicamente cuando una tarea los requiere. En lugar de saturar el prompt del sistema con conocimientos especializados, las habilidades permiten que el agente siga siendo un generalista ligero que se convierte en especialista cuando se le solicita. Un AGENTS.md que maneje bien esta distinción podría verse así:

# Project: PaymentService API

## Architecture
- REST API, Node.js, PostgreSQL
- Never modify /src/core/billing without explicit approval

## Agent Skills (load on demand)
- skill:stripe-integration → load when task involves payments
- skill:database-migrations → load when task involves schema changes

## Hard Constraints
- No hardcoded credentials
- All new endpoints require integration tests before merge

La sintaxis exacta importa menos que la idea de la intención codificada como restricción. El agente aprende qué es, qué puede tocar, qué desencadena un comportamiento especializado y qué está prohibido sin autorización, y todo eso no necesita estar en cada ventana de contexto. Esa es la diferencia entre un agente que mantiene su fiabilidad en cientos de tareas y uno que deja de funcionar después de las primeras docenas.

La trampa del 80%

Los agentes pueden escribir rápidamente alrededor del 80% del código de una función. Esa parte suele parecer limpia, supera una revisión superficial y se lanza sin problemas, y así es como se cierra la trampa. El último 20% es donde los sistemas fallan: casos límite, reglas de negocio que solo están en la mente de las personas y no en documentos, puntos de integración entre servicios desarrollados años atrás por equipos separados, y requisitos de precisión que solo se manifiestan bajo carga real o comportamiento real de los usuarios.

La naturaleza de los errores de la IA también ha cambiado. Las herramientas de programación antiguas generaban errores de sintaxis evidentes que se detectaban fácilmente durante las revisiones. Los agentes actuales cometen errores conceptuales: suposiciones erróneas sobre las reglas de negocio, casos límite plausibles pero ignorados, y decisiones arquitectónicas que generan deudas ocultas de mantenimiento a largo plazo. El código parece correcto y puede superar el conjunto de pruebas, pero la falla es estructural, se produce con retraso y, por lo general, es mucho más costosa de reparar que de prevenir.

Por esta razón, la evaluación de la trayectoria, es decir, la inspección del camino de razonamiento del agente junto con su salida, no puede omitirse en los sistemas agentes en producción. La evaluación de la salida verifica si la función devolvió el resultado correcto. La evaluación de la trayectoria verifica si el agente comprendió el problema antes de escribir algo. Cada uno de estos aspectos es importante, y centrarse únicamente en la salida permite que el 20% final pase sin problemas. Los desarrolladores que lo hacen mejor no aceleran el proceso aceptando todo; ganan velocidad al aplicar su propio juicio donde el juicio de la IA es estructuralmente más débil: requisitos poco claros, compromisos arquitectónicos y la corrección en los límites del sistema.

Modos conductor y orquestador

El artículo describe dos modos de operación, y pasar de uno a otro podría ser el cambio profesional más significativo desde el punto de vista práctico en la ingeniería de software actual. En el modo conductor, el desarrollador trabaja en tiempo real dentro del IDE, observando cómo se genera el código, realizando correcciones y manteniendo un control detallado de cada cambio. Esto preserva la intuición y la comprensión para las que se forma a los ingenieros. El costo es la velocidad de procesamiento, ya que dirigir personalmente cada interacción limita los beneficios de la IA.

El modo orquestador se encuentra en un nivel superior. Los desarrolladores establecen objetivos, los transfieren a los agentes y revisan los resultados obtenidos, sin necesidad de observar cómo se genera el código línea por línea. Los agentes trabajan en paralelo dentro de entornos de pruebas en segundo plano, a veces durante horas, y devuelven solicitudes de integración. El desarrollador revisa periódicamente, evalúa los resultados y redirige las acciones según sea necesario.

El modo conductor es en tiempo real, interactivo y con un único agente. El modo orquestador es asíncrono, con agentes en paralelo y una solicitud de pull como resultado. La mayoría de los desarrolladores están capacitados como conductores, por lo que pasar al modo orquestador implica un cambio significativo en su rol.

Las habilidades requeridas también difieren. Los conductores dependen de un profundo conocimiento del lenguaje y la sintaxis, de una capacidad rápida para depurar, de una comprensión del código base y de la interpretación en tiempo real de los errores. Los orquestadores necesitan especificaciones precisas, descomposición de tareas, evaluación rápida de resultados y diseño de sistemas, lo que implica definir las restricciones, las pruebas y los ciclos de retroalimentación que mantienen a los agentes fiables sin una supervisión constante. Muchos desarrolladores senior son conductores experimentados, y orquestar les resulta incómodo porque se siente como renunciar al control. A veces así es, por lo que es necesario aprovechar la infraestructura, evaluar la cobertura y contar con ingeniería de contexto antes de expandir la orquestación. Delegar sin establecer mecanismos de verificación no es ingeniería; es simplemente programación a gran escala sin rigor.

Una pregunta de economía

El artículo aborda el debate entre el codificado de ambiente y la ingeniería agente como una cuestión de costos, no de métodos. El codificado de ambiente casi no tiene costo inicial: no requiere disciplina en la especificación, ni infraestructura de evaluación, ni diseño de herramientas, ni mantenimiento de AGENTS.md. Sin embargo, genera rápidamente deudas operativas ocultas debido al desperdicio de tokens en contextos no estructurados, a un aumento en los errores derivados de salidas no verificadas, y al tiempo perdido por los desarrolladores a causa de fallos que las evaluaciones automatizadas deberían detectar.

La ingeniería agente exige una inversión real y temprana en rigor en las especificaciones, infraestructura de evaluación, diseño de herramientas y arquitectura de contexto. Después de eso, el costo marginal por función disminuye drásticamente, ya que cada nueva capacidad del agente reutiliza las mismas herramientas, el mismo conjunto de evaluaciones y la misma arquitectura de contexto.

Para un desarrollador que trabaja en un prototipo o un proyecto paralelo, el código generado de forma intuitiva claramente gana en términos de costos. No hay sistema de producción que necesite protección, y la deuda técnica nunca alcanza un nivel peligroso. Los equipos llegan al punto de no retorno antes de lo esperado. Cinco ingenieros que desarrollan código de forma intuitiva durante tres meses pueden terminar con un tercio de su capacidad ocupada en depuración y re trabajo, algo que la verificación sistemática habría evitado. La infraestructura basada en agentes se paga a sí misma, siempre y cuando se implemente antes de que la deuda técnica supere su punto crítico.

Qué aborda el artículo y qué no

El documento no es una presentación de producto. Es un documento marco, y uno más práctico que la mayoría porque sus afirmaciones principales pueden verificarse. El efecto de arnés es real y medible, como demuestran los puntos de referencia citados. El problema del 80% es real y se vuelve más acuciante a medida que los agentes asumen tareas más difíciles. Además, el cambio de conductor a orquestador ya está ocurriendo en todas las organizaciones de ingeniería serias a gran escala.

Lo que se deja sin resolver, aparentemente a propósito, es dónde debería situarse un equipo específico en ese espectro. Esto depende de factores como las implicaciones, el tamaño del equipo, la presión por los plazos y la madurez técnica, de maneras que ningún marco puede dictar. El documento proporciona vocabulario y un modelo mental, pero la decisión final queda en manos de las personas, lo cual probablemente sea la postura más honesta posible.

La estructura escala, pero las vibraciones no. Los desarrolladores que lo comprenden ahora construyen sobre bases muy diferentes a las de aquellos que lo aprenderán a un costo elevado en producción.