Vibe coding best practices: cuándo pasar al agentic coding

¿Qué es el vibe coding y en qué se diferencia del agentic coding?

En artículos anteriores explicamos una a una las piezas de un agente de programación: hooks, subagentes, skills, worktrees, auto mode y sandbox. Este artículo las reúne en una sola pregunta: ¿qué hace falta para hacer bien vibe coding y dónde se cae en la trampa? Explicamos cada hábito en pocas líneas y enlazamos el artículo que lo trata a fondo.

El término lo acuñó Andrej Karpathy en X el 2 de febrero de 2025. En su publicación, tal como la cita Wikipedia, describía cómo trabajaba: aceptaba cada cambio con «Accept All», ya no leía los diffs y pegaba los mensajes de error al agente sin comentario alguno. En sus propias palabras, para proyectos de fin de semana de usar y tirar no estaba tan mal. En resumen, vibe coding es pedirle a la IA que escriba código sin leerlo y fijarse solo en el resultado.

La entrada de Simon Willison del 6 de mayo de 2026 traza la línea con claridad. Para él, vibe coding es trabajar sin mirar el código en absoluto: puede que ni siquiera sepas programar; dices lo que quieres y, si funciona, ya está. En una herramienta que solo usas tú y cuyos errores solo te afectan a ti, no hay problema. Pero si haces software para otros, el vibe coding es «grossly irresponsible», porque tus errores los sufren otros. El agentic engineering es el extremo contrario: un ingeniero de software que entiende de seguridad, mantenibilidad, operación y rendimiento y usa estas herramientas. A las herramientas en sí se las llama herramientas de agentic coding: según la definición de Anthropic, un agente que lee código, edita archivos y ejecuta comandos. Así que el agentic coding es la forma de trabajar en la que el agente escribe y ejecuta el código por su cuenta; la diferencia entre vibe coding y agentic engineering está en si lees el resultado y te haces responsable de él.

Las recomendaciones de este artículo también se apoyan en esa línea. En una herramienta para ti, en un prototipo o mientras aprendes algo, el vibe coding no tiene inconveniente. En cambio, el código que usan otros, que guarda datos de usuarios o que gestiona inicios de sesión o pagos no se publica sin leerlo. Los hábitos que siguen acercan el vibe coding a un agentic coding del que alguien se ha hecho responsable.

En español también se suele usar el término en inglés. Si lo que buscas es el nombre general de programar con IA, es programación asistida por IA (AI-assisted coding); el vibe coding es su extremo en el que nadie lee el código. Hay otros dos términos que se confunden a menudo con él. El spec-driven development es casi lo contrario: el agente escribe una spec, un plan y una lista de tareas antes del código. El harness engineering es otro tema: describe la estructura que montas alrededor del modelo.

¿Qué ha cambiado este otoño en las herramientas de programación?

En septiembre y octubre, las cinco herramientas cambiaron en la misma dirección: el agente te pregunta menos, trabaja solo durante más tiempo y más en paralelo. Según las notas de versión:

Fuente: notas de versión de las herramientas, 21 de octubre de 2026. Versiones: Claude Code 2.1.284 y 2.1.286, Codex CLI 0.162.0, Antigravity CLI 1.3.5; la fila de Copilot sale de las versiones de septiembre de VS Code. El 18 de junio de 2026, Google cerró Gemini CLI para los suscriptores de Google AI Pro y Ultra y para los usuarios gratuitos, y lo sustituyó por Antigravity CLI; las empresas y quienes usan una clave de API de pago pueden seguir usando Gemini CLI.

La dirección común está clara: el agente lleva una tarea más lejos sin preguntarte. Las preguntas de aprobación ya se respondían casi siempre que sí sin leerlas; las mediciones de los proveedores sobre esto las contamos en el artículo sobre auto mode y sandbox. El control de verdad tiene que estar en el bucle del agente y funcionar también cuando no estás mirando: un test, un hook, la CI. El cambio verify de Claude Code hace justo eso: antes del commit, hace que el agente ejecute la comprobación que escribiste tú.

¿Qué dicen los estudios sobre las aplicaciones hechas con vibe coding?

En agosto y septiembre se publicaron o actualizaron tres estudios; los tres están en arXiv y son preprints que no han pasado revisión por pares. El más grande es el estudio de Deng, Fan y Meng; su última versión es del 14 de septiembre de 2026. Los investigadores reunieron 9.041 aplicaciones de código abierto hechas con Claude Code y Lovable, auditaron las 200 que estaban publicadas y encontraron 1.186 vulnerabilidades. Primero, unos auditores de IA señalaron las vulnerabilidades candidatas; después, dos autores con conocimientos de seguridad revisaron cada una por separado, y solo contaba como vulnerabilidad si ambos la consideraban explotable.

El resultado: el 91 % de las aplicaciones tenía al menos una vulnerabilidad, y el 65,77 % de las vulnerabilidades era de gravedad crítica o alta. Se concentran en el control de acceso (broken access control), la inyección y la autenticación. El control de acceso es la parte que garantiza que un usuario solo llegue a sus propios datos; si falta, la aplicación funciona igual, así que en una demo no se nota.

Los investigadores también reprodujeron parte de estas vulnerabilidades para ver qué ayuda. Lo que más las redujo fueron dos cosas: un prompt que exige código listo para producción como condición para dar la tarea por terminada, y un harness con controles de seguridad añadidos. Pero ninguna configuración las eliminó todas. Hay otro resultado llamativo: en 90 de las 434 ejecuciones en las que se activó una vulnerabilidad (20,7 %), el agente vio el riesgo por sí mismo y aun así escribió el código inseguro; a menudo dejó un aviso o un comentario en lugar de corregirlo. Que el agente conozca el riesgo no basta; la comprobación tiene que ejecutarse antes de que la tarea termine.

El estudio de Andročec del 21 de agosto de 2026 plantea una pregunta pequeña pero directa. Hizo que el mismo agente, con el mismo modelo, escribiera dos veces y de una sola pasada cada una de las 6 aplicaciones web. La única diferencia entre los dos prompts era una sección de requisitos de seguridad añadida al final del segundo. La versión con requisitos de seguridad tuvo menos hallazgos confirmados en todas las aplicaciones (24 frente a 51), y ninguno era crítico ni alto. Aun así, el hallazgo más grave solo lo detectó la prueba manual. El propio autor advierte: la muestra es pequeña y cada versión se generó una sola vez; los resultados son observaciones, no un efecto estadístico.

El estudio de Kraishan (12 de septiembre de 2026) mira en otra dirección: ¿qué pasa con los pull requests de los agentes después del merge? Comparó 37.623 pull requests de cinco agentes comerciales con los pull requests de personas en los mismos repositorios. El resultado es «vendor-specific rather than uniform»: en los 90 días posteriores al merge, la tasa de reversión de 3 de los cinco agentes no se pudo distinguir estadísticamente de la de las personas; uno se revirtió con menos frecuencia y otro con más. Los patrones sospechosos, como credenciales escritas en el código o eval, aparecieron menos en el código de los agentes que en el de las personas; pero esto es un escaneo de patrones, no vulnerabilidades confirmadas. Los datos van de diciembre de 2024 a julio de 2025; no dicen nada sobre cómo se ordenan las herramientas y los modelos de hoy. Cómo leer una comparación así lo contamos en el artículo sobre SWE-bench.

Los desarrolladores también confían sobre todo en lo que pueden comprobar. En la encuesta 2026 de Stack Overflow, publicada el 6 de octubre (más de 30.000 participantes; no es una muestra aleatoria sino respuestas voluntarias), el 48 % de los participantes dijo que confía en la IA cuando puede validar fácilmente su respuesta. La mayoría de los hábitos de abajo existen para facilitar eso.

¿En qué coinciden las guías de las cinco herramientas?

Las cinco herramientas tienen su propia guía de buenas prácticas. El 21 de octubre de 2026 las leímos todas y pusimos lado a lado lo que recomiendan sobre cada tema. Para Copilot leímos juntas tres guías de GitHub (VS Code, Copilot CLI y el agente en la nube); la de Cursor es una entrada de blog del 9 de enero de 2026, y las demás no tienen fecha. En cuántas guías aparece cada uno de los seis hábitos:

Las cinco guías coinciden en 3 hábitos. Los otros 3 los recomiendan 4 guías; la guía de Antigravity CLI no los menciona, pero sí recomienda lanzar subagentes en paralelo en segundo plano en los trabajos grandes, y la CLI tiene una vista /diff que muestra los cambios. Qué dice cada guía:

Fuente: guías de buenas prácticas de las cinco herramientas, 21 de octubre de 2026. La columna de Copilot sale de las guías de VS Code, Copilot CLI y el agente en la nube de Copilot. Cada celda resume la frase de la guía. «No está en su guía»: en la guía que leímos ese día no encontramos ninguna frase que lo diga; puede estar en otros documentos de la herramienta.

Comprobación. El agente se detiene cuando la tarea parece terminada. Según la guía de Claude Code, sin una comprobación que pueda ejecutar, «looks done» es la única señal que tiene, y cada error espera a que tú lo notes. Tests, un build, un linter o un script que compare la salida con un ejemplo: sirve cualquier cosa que se lea como aprobado o suspendido. Cuando el agente diga «los tests pasan», pídele el comando que ejecutó y su salida. El agente puede comprobar una interfaz en el navegador; cómo convertir eso en un test de Playwright duradero lo contamos en el artículo sobre computer use.

Plan. El plan evita que el agente resuelva el problema equivocado. La guía de Claude Code también dice cuándo saltárselo: si puedes describir el diff en una frase, no hace falta; si no tienes clara la estrategia, si el cambio toca varios archivos o si no conoces el código, pídele un plan. La guía de Cursor también ve bien ir directamente al agente en tareas pequeñas que ya has hecho muchas veces. En una funcionalidad grande, el paso siguiente al plan es una spec; cuándo ayuda lo contamos en el artículo sobre spec-driven development.

Archivo de reglas. Codex y Cursor recomiendan el mismo camino: empezar con poco y añadir una regla cuando el agente repita un error. La guía de Codex dice que, cuando el agente comete el mismo error dos veces, le pidas una retrospectiva y actualices AGENTS.md. Qué herramienta lee qué archivo lo contamos en el artículo sobre AGENTS.md y CLAUDE.md. Para una regla que tiene que cumplirse siempre, un archivo no basta; según la guía de Claude Code, una instrucción es una recomendación, mientras que un hook se ejecuta siempre (artículo sobre hooks). Un prompt que repites una y otra vez puede convertirse en una skill. El mismo archivo sirve también en la revisión. Nuestra herramienta de revisión de código con IA, diffox, al revisar un pull request lee el AGENTS.md del repositorio (o, si no existe, el CLAUDE.md) desde la rama en la que se fusionará el pull request. Usa las frases que expresan una obligación (como «must», «never», «debe», «nunca») como las reglas que definen qué cuenta como error.

Leer el cambio. La guía de Cursor da la razón en pocas palabras: el código que escribe la IA puede parecer correcto y fallar en un detalle, y cuanto más rápido trabaja el agente, más importa la revisión. La guía de Claude Code recomienda hacer la revisión en un contexto nuevo: un subagente que solo ve el diff y los criterios no se deja influir por el razonamiento de la sesión que escribió el cambio. Cómo funciona un subagente lo contamos en el artículo sobre subagentes, y en qué debe fijarse una persona, en el artículo sobre cómo revisar código generado por IA.

Trabajo en paralelo. Dos agentes que trabajan en la misma carpeta pueden cambiar los archivos del otro. La guía de Codex considera un error ejecutar tareas paralelas sobre los mismos archivos sin worktrees; Claude Code, Cursor y Copilot también recomiendan ejecutar cada sesión en su propio worktree o carpeta. Qué separa un worktree y qué no lo contamos en el artículo sobre git worktree.

Sesión limpia. A medida que la conversación se alarga, el contexto se llena de detalles sin relación y el rendimiento del agente baja. La guía de Claude Code recomienda que, si el agente sigue fallando después de corregirlo dos veces en lo mismo, limpies la sesión y empieces de nuevo con un prompt mejor que incluya lo que has aprendido. Qué se pierde al resumir en una tarea larga lo contamos en el artículo sobre auto-compact.

¿En qué no coinciden las guías?

Las guías no dicen lo mismo en todo. Se separan en cuatro puntos; cuál te conviene depende de tu trabajo.

• ¿Cuánto detalle dar al principio? Codex pide cuatro cosas en cada prompt: el objetivo, el contexto, las restricciones y cuándo se da la tarea por terminada. La guía del agente en la nube de Copilot pide una descripción clara, criterios de aceptación completos y qué archivos hay que cambiar, pero añade que, aunque no indiques rutas de archivo, el agente a menudo encuentra por sí mismo el código correcto. Claude Code también pide que indiques archivos, restricciones y patrones de ejemplo. Cursor, en cambio, dice que etiquetes el archivo si lo conoces y que, si no, lo dejes en manos del agente; los archivos que no vienen al caso pueden confundirlo.
• ¿Hay que corregir todos los hallazgos de una revisión? La guía de Claude Code avisa: un revisor al que se le pide encontrar carencias suele encontrar alguna, aunque el trabajo sea sólido. Perseguir cada hallazgo lleva a capas innecesarias, código defensivo y tests para casos que no pueden darse. La guía recomienda pedir al revisor que solo señale las carencias que afectan a la corrección o a los requisitos indicados. Las guías de Cursor y Copilot presentan las herramientas de revisión sin esta advertencia.
• ¿Cuándo automatizar? La guía de Codex considera un error programar una tarea recurrente que todavía no funciona de forma fiable a mano: primero conviértela en una skill y prográmala cuando sea predecible. Las novedades de este otoño, en cambio, facilitan programar tareas; las automatizaciones de Copilot y Projects de Cursor pueden ejecutar trabajos sin que se lo pidas. Antes de activarlas, hazte la pregunta de Codex: ¿esta tarea funciona de forma fiable a mano?
• ¿Qué trabajos no conviene darle al agente? La única guía que lo dice abiertamente es la de Copilot. Enumera los trabajos que quizá prefieras hacer tú en lugar de asignárselos al agente: problemas críticos en producción; tareas que implican seguridad, datos personales o autenticación; tareas poco definidas y temas que quieres aprender tú mismo. Las otras cuatro guías no tienen una lista así.

¿Cuáles son las trampas del vibe coding?

Dos guías enumeran además los errores frecuentes: la de Claude Code tiene 5 puntos y la de Codex, 8. En esto coinciden las dos listas: llevar todas las tareas en una sola sesión larga, no darle al agente una forma de comprobar su trabajo y poner las reglas en el sitio equivocado (para Claude Code, inflar CLAUDE.md; para Codex, escribir reglas permanentes en cada prompt). Una frase de la lista de Claude Code parece el resumen de este artículo: si no puedes verificarlo, no lo publiques.

En las cinco trampas de abajo caímos nosotros mismos al trabajar con agentes de programación en nuestro propio repositorio; después de cada una escribimos una regla en el archivo de reglas del repositorio. Todas vienen de un solo repositorio, así que no son una estadística; pero detrás de cada una hay un error real. Las preguntas que nos hacemos cuando el agente dice «terminado»:

• ¿El test que pasa en local también pasó en la CI? En nuestro caso, el entorno local se diferenciaba de la CI en varios puntos: un archivo .env que se leía en local, el paquete instalado de otra forma en la CI y una comprobación que solo se ejecuta en la CI. Borrar variables de entorno no impedía que se leyera el archivo .env; además, una opción de instalación que faltaba mostró en rojo una rama correcta y llevó a un diagnóstico equivocado. Nuestra regla ahora: un resultado local nunca se presenta como resultado de la CI, un fallo de la CI se reproduce en un clon limpio sin .env y, después del push, se mira la propia CI.
• ¿El resultado está vacío porque el paso se ejecutó? En uno de nuestros registros, una ejecución limpia y otra en la que habían fallado parte de los pasos se veían exactamente iguales; las dos dejaban una lista de hallazgos vacía. Ahora el registro guarda también si los pasos se ejecutaron y cuántos resultados produjeron; un resultado vacío y un paso muerto se distinguen mirando el registro. Si ves en el código del agente una línea que captura un error y devuelve una lista vacía, hazte la misma pregunta.
• ¿Se leyó como 0 un valor que no existía? Uno de nuestros informes leyó como 0 un valor que nunca se midió y escribió «100% saving» junto a un trabajo que sí se había hecho; el mismo error desactivó además una comprobación sin que nadie lo notara. Un valor no medido debe quedarse en None y leerse comprobando si la clave existe:

# Ejemplo: un valor no medido debe ser None, no 0
seconds = record.get("seconds") or 0   # mal: si falta la clave, queda 0
seconds = record["seconds"] if "seconds" in record else None   # bien

or 0 convierte en cero tanto una clave ausente como None. Ese cero entra luego en una media o en un umbral y hace que un trabajo no medido parezca gratis o exitoso.

• ¿Se mostró el .env en pantalla? Una vez mostramos el archivo .env enmascarado con sed. Como no todas las líneas tienen la forma KEY=value, la máscara se saltó una línea y la clave que contenía se vio sin enmascarar. Ahora preguntamos al entorno si una clave existe, no al archivo; su contenido no se muestra, ni siquiera enmascarado. Qué herramientas impiden de entrada que el agente lea archivos secretos lo contamos en el artículo sobre el sandbox.
• ¿La ruta, la dirección o el paquete que cita existe de verdad? Una de nuestras notas de medición citaba como fuente una carpeta que no existe en ninguna rama. En un borrador que completaba nombres de archivo abreviados, la mayoría de los nombres completados estaban mal. Ahora una herramienta comprueba que cada ruta de una línea de fuente existe en el disco; la herramienta que construye este blog también rechaza una ruta de fuente que no se puede abrir. Por qué conviene comprobar aparte los paquetes que propone el agente lo contamos en el artículo sobre la revisión.

Lo que tienen en común las cinco es la diferencia entre «terminado» y «parece terminado». El consejo de la guía de Claude Code vale también aquí: pídele al agente la prueba del éxito, no que lo afirme; el comando que ejecutó y la salida que obtuvo.

¿Qué hábitos necesita cada tipo de trabajo?

No todos los trabajos necesitan todos los hábitos. En un arreglo de una frase puedes saltarte el plan; en código que toca datos de usuarios no puedes saltarte la lectura. A grandes rasgos, hay cuatro situaciones:

Cada situación en detalle, y algunos casos especiales:

• Una herramienta o un prototipo que solo usas tú. Como dice Willison, si un error solo te afecta a ti, el vibe coding no tiene inconveniente. Aun así, haz commit a menudo para poder volver atrás, y pon las claves en el entorno, no en el código.
• Un arreglo pequeño en un repositorio real. Sáltate el plan, pero no la comprobación; el diff es corto, así que leerlo también es rápido. Si estás corrigiendo un error, sigue el orden de la guía de Claude Code: primero un test que reproduzca el error y falle, después el arreglo.
• Una funcionalidad de varios archivos o código que no conoces. Primero un plan, y en un trabajo grande una spec; haz que escriba los tests antes del código y que el cambio se revise en un contexto nuevo. Cuándo marcan la diferencia un modelo de gama alta y más effort en trabajos largos y poco definidos lo contamos en los artículos sobre elección de modelo y effort.
• Ejecuciones sin supervisión y agentes en paralelo. En auto mode, en un agente en la nube o en una tarea programada no hay nadie a quien preguntar. Pon la comprobación en un hook o en la CI, mantén los permisos acotados, activa el sandbox, dale a cada agente su propio worktree y, al final, pide pruebas, no afirmaciones. Los permisos y el sandbox los contamos en el artículo sobre auto mode y sandbox.
• Datos de usuarios, inicio de sesión, pagos y secretos. Escribe los requisitos de seguridad en el prompt de forma explícita; en el estudio de Andročec, solo con añadir eso bajaron los hallazgos en todas las aplicaciones. Pero el hallazgo más grave lo detectó igualmente la prueba manual: que una persona lea este código.
• Antes de abrir a todo el mundo una aplicación hecha con vibe coding. Las vulnerabilidades que encontraron Deng y sus colegas están sobre todo en el control de acceso y la autenticación. Pruébalo tú: ¿puede un usuario ver los datos de otro?, ¿se puede llegar a una página protegida sin iniciar sesión?
• Un repositorio que no conoces. Antes de abrirlo con un agente, mira qué archivos pueden ejecutarse solos en él; cuáles son lo contamos en el artículo sobre workspace trust.