51 páginas, 32 notas finales y una frase de cierre que se ha hecho viral: «la generación está resuelta». El documento acierta en el diagnóstico, y falla justo en lo que predica. Aquí va la reseña completa, con lápiz rojo sobre cada número.
En junio de 2026 Google publicó The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering, un whitepaper de 51 páginas firmado por Addy Osmani —Director en Google Cloud AI—, Shubham Saboo y Sokratis Kartakis. El documento está fechado en mayo, pero se hizo público la semana del 15 de junio como material del Día 1 del curso gratuito 5-Day AI Agents Intensive de Kaggle. La edición previa de ese curso reunió a más de un millón y medio de alumnos, así que hablamos de un documento con una distribución que ya quisieran muchos papers.
No es un producto ni un repositorio: es un documento de marco. Y su tesis cabe en la última línea del cuerpo del texto, antes de las notas:
«Generation is solved. Verification, judgment, and direction are the new craft.»
(La generación está resuelta. La verificación, el juicio y la dirección son el nuevo oficio.)
Lo he leído entero y lo he desmontado en capas, porque tienen valores de reutilización muy distintos y mezclarlas es el error de lectura más caro. Adelanto el veredicto: el marco conceptual es de lo mejor que se ha escrito sobre esto y el aparato estadístico se cae a la primera pregunta. La ironía es difícil de ignorar: un documento que proclama la verificación como la nueva disciplina no aplica ese estándar a sus propios números.
Capa 1 — El marco conceptual
Aquí está el valor real, y el coste de adopción es cero.
El espectro: la verificación como única variable
El movimiento central del documento es negarse al binario. Vibe coding e ingeniería agéntica no son dos tribus: son los dos extremos de un mismo espectro. Y lo que fija tu posición en él no es la herramienta —puede ser idéntica en ambos extremos— sino cuánta estructura, verificación y juicio humano rodean la salida del modelo.
El mismo desarrollador, con el mismo agente y el mismo modelo, puede estar en los dos extremos en la misma tarde. Lo que cambia es el andamiaje. El texto lo deja explícito: sin tests y evals, la práctica sigue siendo vibe coding por sofisticados que sean tus prompts.
Es una distinción limpia y no trivial, y no es original del documento: una taxonomía académica independiente —Sapkota, Roumeliotis y Karkee, mayo de 2025— dibujó prácticamente el mismo mapa un año antes. Que dos trabajos sin relación converjan es, en sí mismo, una señal de que la distinción captura algo real.
Agente = Modelo + Harness
Esta es la aportación con más capacidad operativa del documento, y la que yo me llevaría a una reunión mañana.
La intuición dominante —el modelo es el sistema— es falsa, y lleva a invertir en el sitio equivocado. El modelo es una entrada. Todo lo demás es el harness: ficheros de instrucciones (AGENTS.md, CLAUDE.md, GEMINI.md), herramientas y servidores MCP, sandboxes, lógica de orquestación, hooks deterministas y observabilidad. El reparto que propone el documento es de aproximadamente 10% modelo / 90% harness.
El corolario es la frase más útil del texto para cualquiera que dirija un equipo: la mayoría de los fallos de un agente, examinados con honestidad, son fallos de configuración. Una herramienta que no está, una regla vaga, un guardrail ausente, una ventana de contexto llena de ruido.
Y aquí sí hay un recibo. LangChain publicó en febrero de 2026 un experimento donde tocaron solo el harness, manteniendo el modelo fijo (gpt-5.2-codex): en Terminal-Bench 2.0 pasaron del 52,8% al 66,5%, trece puntos y siete décimas, y de quedarse justo fuera del Top 30 a entrar en el Top 5. Es una sola medición, en un solo benchmark, con un solo agente. Pero es una medición de verdad, con su metodología encima de la mesa.
Contexto estático frente a contexto dinámico
El documento enumera seis tipos de contexto —instrucciones, conocimiento, memoria, ejemplos, herramientas y guardrails— y traza una frontera que en la práctica es la decisión arquitectónica más consecuente del diseño de un agente: qué va en contexto estático (siempre cargado, pagando tokens en cada interacción) y qué va en contexto dinámico (bajo demanda, pagando solo cuando hace falta).
La petición concreta es que esa frontera se trate como configuración de primera clase: revisada en pull request y versionada como código. El patrón que hace escalar el contexto dinámico son las skills con divulgación progresiva —el agente ve metadatos ligeros al arrancar, carga instrucciones completas cuando la tarea encaja y trae material pesado solo si de verdad lo necesita—. El documento atribuye su adopción rápida a que resuelven cuatro problemas a la vez: degradación de contexto por prompts sobrecargados, ausencia de memoria procedimental en los LLM, sobrecarga operativa de las arquitecturas multi-agente y necesidad de portabilidad entre herramientas.
El modelo fábrica
La síntesis de todo lo anterior: el entregable primario del desarrollador deja de ser el código y pasa a ser el sistema que produce código. Especificaciones y contexto, agentes que los traducen a implementación, tests y puertas de calidad, bucles de realimentación que devuelven los fallos al agente, guardrails que acotan el comportamiento. El jefe de una fábrica no monta cada pieza: diseña la línea y responde del control de calidad.
Veredicto de la capa: ADOPT. Vocabulario compartido, criterios defendibles ante interlocutores no técnicos, cero dependencia de nadie.
Capa 2 — El SDLC, fase a fase
El documento conserva las seis fases clásicas y redistribuye el tiempo dentro de ellas. La observación clave es que la compresión es dramática pero desigual: la implementación pasa de semanas a horas mientras requisitos, arquitectura y verificación siguen a ritmo humano. El resultado no es un SDLC más rápido; es un flujo distinto, con las fronteras entre fases borrosas.
Dos ideas que me parecen especialmente rescatables de este capítulo.
Los dos modos de operación. El conductor dirige en tiempo real dentro del IDE —lógica compleja, depuración difícil, bases de código desconocidas— y su habilidad dominante es la comprensión fina del cambio; su riesgo es convertirse él mismo en el cuello de botella. El orquestador delega de forma asíncrona sobre varios agentes —bugs conocidos, features sobre patrones establecidos, migraciones, generación de tests— y su habilidad dominante es especificar, descomponer y evaluar; su riesgo es perder comprensión si la revisión se relaja. No son perfiles distintos: son dos marchas del mismo desarrollador.
El problema del 80%. Los agentes generan rápido cerca del 80% del código de una feature, y el 20% restante —casos límite, manejo de errores, puntos de integración, requisitos sutiles de corrección— exige conocimiento contextual profundo. Lo importante no es el reparto, es que la naturaleza del error ha cambiado: de fallos de sintaxis a fallos conceptuales (supuestos erróneos sobre lógica de negocio, no pedir aclaración ante una ambigüedad, decisiones arquitectónicas que dejan deuda). Y esos son más difíciles de detectar precisamente porque el código parece correcto y pasa los tests básicos.
Capa 3 — La economía
Para cualquiera que responda de entregas, este es el capítulo más accionable. Y también el peor sostenido.
El argumento reformula el espectro como una estructura de costes. El vibe coding es CapEx bajo, OpEx alto: barrera de entrada nula, y después quema de tokens en bucles de «vuelve a arreglarlo», impuesto de mantenimiento sobre código estructuralmente inconsistente y remediación de seguridad a posteriori. La ingeniería agéntica invierte la ecuación —CapEx alto, OpEx bajo—: pagas por adelantado en specs, tests y diseño de contexto, y el coste marginal por feature se desploma. Hay un punto de cruce.
Dos palancas concretas que sobreviven al escrutinio: la ingeniería de contexto como estrategia financiera (pasar un repositorio de 100.000 tokens en cada prompt no escala; un payload denso eleva el acierto a la primera y evita bucles caros) y el routing inteligente de modelos (modelos frontera para requisitos, arquitectura e implementación inicial; modelos pequeños y baratos para generar tests, revisar y vigilar CI/CD).
Lo que no sobrevive es la cifra. El documento afirma que, pasado el punto de cruce, el vibe coding cuesta entre 3 y 10 veces más por feature. Busqué la medición detrás. No existe: todo lo que hay son posts de consultoras que venden servicios de remediación, sin metodología y sin datos. Es una figura ilustrativa que se ha convertido en número por el camino. Útil como modelo mental, inaceptable en una propuesta comercial.
Veredicto de la capa: ADOPT el modelo, WATCH la cifra.
Capa 4 — El aparato empírico, con lápiz rojo
Aquí es donde el documento se cae, y donde este artículo se pone incómodo. Pasé cada estadística de cabecera por su fuente primaria. Esto es lo que quedó.
| Afirmación del documento | Qué encontré al trazarla |
|---|---|
| 85% de desarrolladores usa agentes de codificación | Reformular. El 85% real es de JetBrains, State of Developer Ecosystem 2025 (24.534 desarrolladores, 194 países) y dice «herramientas de IA», no agentes. La cifra de JetBrains más cercana a agentes es el 62% |
| 51% de uso diario | Aguanta con matiz. Stack Overflow 2025 (49.009 respuestas, 177 países) publica 47,1% de uso diario en el total y 50,6% entre profesionales. El 51% es ese 50,6% redondeado |
| Adopción del 90% | Aguanta. DORA 2025, casi 5.000 profesionales: el 90% usa IA en el trabajo, +14 puntos interanuales. Ojo: uso de IA en el trabajo, no penetración en el ciclo de desarrollo |
| 41% del código nuevo generado por IA | Sin primaria. No hay fuente localizable; es una cifra que circula citándose a sí misma. Lo que sí es atribuible: Google ~25% (Pichai, 2024), Microsoft 20-30% (Nadella, 2025) |
| Mejoras de productividad del 25-39% | Mal leída. Sale del experimento de campo con Copilot (MIT/Princeton/UPenn, 4.867 desarrolladores). El resultado central es 26,08% más tareas completadas; el 27-39% aplica solo a los desarrolladores junior, y los senior sacan 7-16%. El propio paper avisa de que esa heterogeneidad no es significativa a niveles convencionales |
| Proyección Deloitte 30-35% | Aguanta como lo que es: una expectativa, no una medición |
| METR: expertos un 19% más lentos | Real. Julio de 2025, ensayo aleatorizado, 16 mantenedores expertos, 246 issues, repos maduros y herramientas de principios de 2025 |
| Top 30 → Top 5 y +13,7 puntos por ajuste de harness | Contado dos veces. Se presentan como dos resultados de dos equipos. Es un experimento: LangChain, febrero de 2026, mismo modelo fijo |
| Coste 3-10x pasado el punto de cruce | Ilustrativo. Ninguna medición asociada |
| Reparto 10/90 | Heurística con autor, no dato. Sin cita en el propio documento |
Dos cosas que me parecen más graves que cualquiera de las filas anteriores.
La primera: el documento cita el estudio de METR —expertos un 19% más lentos— y nunca lo reconcilia con su propia cifra de 25-39% de mejora. Son dos afirmaciones incompatibles en el mismo texto, separadas por unas páginas. Y el matiz que faltaba es delicioso: METR cambió el diseño del experimento en febrero de 2026 porque ya no consigue grupo de control. Entre el 30% y el 50% de los desarrolladores evitaban enviar tareas cuando les tocaba trabajar sin IA. El experimento no se rompió por los datos: se rompió porque la gente se niega a volver atrás.
La segunda: el documento sostiene que la generación está resuelta, menciona la remediación de seguridad y el slopsquatting en notas al pie, y nunca reconcilia la evidencia sobre vulnerabilidades en código generado con esa tesis. Si el 20% difícil incluye «huecos sutiles de corrección que pasan los tests», la generación no está resuelta: está desplazada.
Veredicto de la capa: WATCH. No cites ninguna de estas cifras en una propuesta, una RFP ni un material comercial sin sustituirla por su primaria. Donde no hay primaria —41%, 3-10x—, simplemente no la uses.
Capa 5 — Acoplamiento y filtros de soberanía
Aquí hay que separar con precisión, porque el perfil de riesgo es opuesto según la capa.
- Marco conceptual y recomendaciones de gobernanza: acoplamiento cero. Reutilizables sin restricción, agnósticos de proveedor, aplicables tal cual sobre cualquier stack.
- Estándares de interoperabilidad: acoplamiento bajo. El documento recomienda explícitamente adoptar MCP y A2A para conservar la opción de mezclar proveedores. Ojo con un detalle que casi todo el mundo mezcla: MCP fue donado por Anthropic a la Agentic AI Foundation (bajo Linux Foundation) en diciembre de 2025, mientras que A2A es un proyecto independiente de la Linux Foundation desde junio de 2025. Ambas abiertas, gobernanzas distintas. Y
AGENTS.mdtambién está tutelada por la AAIF, con más de 60.000 proyectos usándola. - Implementación de referencia: acoplamiento alto en el tramo de despliegue.
google/agents-cliinstala siete skills en tu asistente de código —workflow, código ADK, scaffolding, evals, despliegue, publicación y observabilidad— y funciona también en solitario. En local basta una clave de AI Studio para scaffold, run y eval; el despliegue y las funciones cloud requieren Google Cloud. El ADK es Apache 2.0 y containerizable en infraestructura propia, lo cual es más de lo que ofrece casi nadie. - Cadena de despliegue gestionada: aquí está la frontera. Agent Runtime —componente de Gemini Enterprise Agent Platform, la marca que sustituyó a Vertex AI en Cloud Next ’26— es un servicio gestionado sin equivalente auto-alojado. Matiz importante para no exagerar: puedes empaquetar tu agente ADK y correrlo en GKE, Cloud Run o cualquier runtime de contenedores. La dependencia dura no está en ejecutar el agente, está en las piezas gestionadas adyacentes —sesiones, memoria— y en el camino que el documento presenta como natural: prototipo local que «se gradúa» a Agent Runtime, es decir, plataforma justo en el punto de producción.
Para entornos regulados, on-premise o con requisitos de residencia de datos, la recomendación es la de siempre: quédate con los patrones —las fases del ciclo, los evalsets con puntuación de trayectoria, la observabilidad desde el primer día, los permisos con alcance por agente— y reimpleméntalos sobre orquestación propia. El valor está en las ideas; el código de referencia solo es adoptable donde el acoplamiento a nube estadounidense es aceptable.
La letra pequeña
Aparte de las cifras, tres cosas que conviene saber antes de citar el documento.
El documento envejece a distintas velocidades. Los autores lo reconocen con una honestidad poco habitual: la fotografía fase a fase refleja mediados de 2026 y las fronteras pueden verse distintas en doce meses. Retén el marco, no el diagrama. Un ejemplo concreto: Terminal-Bench 2.0, el benchmark del resultado de LangChain, ya va por la 2.1 y hay una versión 3 en circulación.
La neutralidad de proveedor es parcial. El texto nombra herramientas de terceros con generosidad —Copilot, Cursor, Windsurf, Claude Code, Jules—, pero la única ruta de implementación concreta que ofrece es ADK + Agents CLI + Agent Runtime sobre infraestructura de Google. El sesgo institucional está declarado, no oculto. Pero está.
Cuidado con la cronología de segunda mano. Al trazar las fechas del concepto me encontré con que la cobertura secundaria las repite mal con frecuencia. Para el registro: Karpathy acuñó «vibe coding» el 2 de febrero de 2025, y la formulación de «agentic engineering» es de su retrospectiva del 4 de febrero de 2026, el aniversario del término original, no de abril. Si vas a construir una línea temporal, ve a los posts originales.
Veredicto por capa
| Capa | Veredicto | Acción |
|---|---|---|
| Marco conceptual (espectro, harness, fábrica, conductor/orquestador) | ADOPT | Incorporar el vocabulario a documentación interna y conversaciones con cliente |
| Recomendaciones de gobernanza (evals como puerta, harness versionado, revisión adaptada) | ADOPT | Empezar por la política escrita de prototipo frente a producción |
| Ingeniería de contexto estático/dinámico | PILOT | Medir tokens por tarea antes y después sobre un repositorio piloto |
| Aparato cuantitativo (85/51/41%, 25-39%, 10/90, 3-10x) | WATCH | No citar sin sustituir por la primaria. Donde no hay primaria, no usar |
| Implementación de referencia (Agents CLI + ADK) | PILOT | El patrón de siete skills y los evalsets con puntuación de trayectoria valen la evaluación |
| Cadena de despliegue gestionada (Agent Runtime) | DROP | Para cuentas con soberanía, aislamiento o residencia de datos. Sin equivalente auto-alojado |
Qué haría yo el lunes
Cuatro cosas, en orden de retorno inmediato.
- Escribir la política de modo de trabajo. Qué proyectos, ramas y entornos admiten vibe coding y cuáles exigen ingeniería agéntica. El documento avisa de que los equipos que dejan esa frontera difusa producen prototipos que llegan a producción por accidente. Es la recomendación con mejor relación esfuerzo/impacto de todo el texto.
- Tratar el harness como código.
AGENTS.md, prompts de sistema, suites de evals y librerías de skills: revisados en pull request, versionados con el proyecto, con propietario nombrado. Sin esa disciplina el harness deriva y el comportamiento del agente deja de ser reproducible entre miembros del equipo. - Cambiar la puerta de calidad de demo a evals. Cobertura de evals con rúbricas explícitas —éxito de tarea, calidad de uso de herramientas, cumplimiento de trayectoria, alucinación— como precondición para que un agente entre en un flujo compartido. Igual que la cobertura de tests condiciona el despliegue de un servicio.
- Rediseñar el checklist de revisión de código. Ajustado a los modos de fallo del código generado: dependencias alucinadas, manejo de errores insuficiente, huecos sutiles de corrección que superan los tests básicos.
Lo que me llevo
Este es un documento de marco con guarnición estadística. El marco está construido para durar; las cifras son la parte que hay que trazar a la primaria antes de usarlas donde alguien pueda auditarlas. Una hora de lectura y un lápiz rojo.
Y el diagnóstico central es correcto, que es lo que importa: el cuello de botella se ha desplazado de escribir a especificar y verificar. Lo que el documento no hace es aplicarse a sí mismo el estándar que predica. Las dos cosas son información útil, y la segunda quizá más que la primera: si el texto de referencia del sector sobre por qué la verificación es el nuevo oficio no verifica sus propios números, la conclusión no es que el marco sea malo. Es que la disciplina que propone todavía no es un hábito ni siquiera entre quienes la escriben.
Ideas por encima de código; evidencia por encima de humo.
Fuentes
- Osmani, A., Saboo, S. y Kartakis, S. (mayo 2026). The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering — Google, 51 pp. (documento primario)
- Osmani, A. (16 jun 2026). The New Software Lifecycle — ensayo compañero, republicado en O’Reilly Radar el 15 de julio de 2026
- Sumi, A. (26 jul 2026). The new SDLC: what the Google paper actually says — verificación independiente de las cifras
- LangChain (17 feb 2026). Improving Deep Agents with harness engineering — Terminal-Bench 2.0, 52,8% → 66,5% con modelo fijo
- METR (10 jul 2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity y actualización del 24 feb 2026
- Stack Overflow Developer Survey 2025 (49.009 respuestas) · Google Cloud DORA 2025 (casi 5.000) · JetBrains State of Developer Ecosystem 2025 (24.534)
- Peng, Kalliamvakou, Cihon y Demirer. The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers
- Sapkota, R., Roumeliotis, K. y Karkee, M. (26 may 2025). Vibe Coding vs. Agentic Coding — arXiv:2505.19443
- Google. Agents CLI · Agent Development Kit · Gemini Enterprise Agent Platform
- Model Context Protocol se une a la Agentic AI Foundation · Google dona A2A a la Linux Foundation · AGENTS.md
- Karpathy, A. — «vibe coding», 2 feb 2025 y «agentic engineering», feb 2026
Deja una respuesta