15 de septiembre de 202611 min de lectura

Vibe coding vs programación agéntica: qué es cada uno

Vibe coding es escribir software describiéndole en lenguaje natural a un modelo de IA lo que quieres, y aceptar el código que genera sin leerlo línea por línea. El término lo acuñó Andrej Karpathy en febrero de 2025 para nombrar una forma de trabajo que ya existía: te guías por el resultado, no por el código. La programación agéntica es ese mismo motor con la verificación de vuelta, y es lo que describo en mi guía de Claude Code y buenas prácticas. Aquí comparo los dos y explico cómo pasar del primero al segundo.

Qué es vibe coding y de dónde viene

Vibe coding es programar por descripción. Le dices al modelo qué quieres, miras lo que sale en pantalla, y si funciona sigues adelante. Si no funciona, le pegas el error y le pides que lo arregle. No lees el diff, no trazas la función que acaba de cambiar, no preguntas qué pasa si el dato llega vacío. La unidad de trabajo es la impresión: el software se ve bien, entonces está bien.

Eso no es una caricatura, es la definición. Lo que hizo Karpathy en 2025 fue ponerle nombre a algo que la IA generativa había vuelto posible de un día para otro: modelos de inteligencia artificial capaces de crear una aplicación completa a partir de un párrafo.

Lo interesante es lo que el vibe coding elimina, no lo que agrega. Un asistente de código que autocompleta es una herramienta de IA que te deja a ti al mando: tú tienes el plan, el modelo pone el siguiente bloque, tú aceptas o rechazas. El vibe coding es ese mismo ciclo con la revisión quitada. El código generado entra al repositorio sin que nadie lo haya leído.

Para prototipos eso es una ventaja real. Puedes crear una aplicación pequeña en una tarde sin ser experto ni conocer lenguajes de programación específicos, ver si la idea vale la pena, y tirarla. Para software que otra persona va a usar, mantener o pagar, el problema aparece después: nadie en el equipo puede explicar por qué el código hace lo que hace, y los problemas de calidad y de seguridad aparecen cuando ya hay usuarios. El primer incidente en producción llega a un repositorio que nadie entiende.

Qué es la programación agéntica

La programación agéntica cambia la unidad de trabajo. Ya no es una sugerencia que aceptas o rechazas: las tareas llegan con un criterio de aceptación y se entregan a un proceso que planea, edita archivos, corre las pruebas, lee el error, vuelve a intentar, y regresa solo cuando necesita algo externo. Una decisión, un permiso, un merge, o una duda genuina.

Ese proceso es un agente. En mi configuración hay varios y cada uno tiene un trabajo: uno investiga y no escribe código, otro implementa en una rama aislada, otro revisa y solo puede escribir comentarios de revisión. La sesión principal orquesta: descompone, delega, sintetiza y decide, y no escribe código nunca. Cada agente corre en el modelo que su nivel de trabajo justifica, no todos en el más caro. Escribí sobre esa topología en detalle en agentes de IA para programar.

La diferencia con el vibe coding no es el modelo de IA. Es el mismo modelo. La diferencia es que alrededor del modelo hay un arnés que define los flujos de trabajo: qué agente corre en qué modelo, qué comandos están prohibidos, qué permisos de seguridad existen, qué tiene que ser cierto antes de que un turno pueda terminar. Cognition lo resumió en Multi-Agents: What’s Actually Working después de casi un año de probar arquitecturas: “multi-agent systems work best today when writes stay single-threaded and the additional agents contribute intelligence rather than actions.” Un solo agente escribe; los demás aportan criterio. Esa es la diferencia entre usar un LLM y construir un sistema de desarrollo de software alrededor de él.

La diferencia: dónde vive la verificación

Las dos formas de trabajo producen código con la misma tecnología. Lo que las separa es dónde vive la verificación.

En vibe coding, la verificación vive en ti, o no vive en ningún lado. Tú decides si el resultado está bien mirándolo. Se rompe por una razón estructural, documentada por Anthropic: el modelo se detiene cuando el trabajo parece terminado, y sin una comprobación que se pueda ejecutar, “parece terminado” es la única señal disponible. Tú te conviertes en el ciclo de verificación.

En programación agéntica la verificación está en el arnés, y se ejecuta sola. Es la pieza que convierte un montón de generación de código en algo que puedes mantener. En mi configuración eso son unas 200 líneas de bash en tres archivos. Un hook de Claude Code se dispara en el evento Stop (y su gemelo SubagentStop) y corre el archivo .claude/check.sh del repositorio antes de permitir que el agente termine su turno. Si la comprobación falla, el hook sale con código 2 y el error vuelve al contexto del agente: no puede terminar, tiene que arreglarlo. Anthropic lo dice en una línea: “Unlike CLAUDE.md instructions which are advisory, hooks are deterministic and guarantee the action happens.” Una instrucción en un archivo de contexto es una petición. Un código de salida distinto de cero no lo es.

Cadena del hook Stop: tres condiciones dejan terminar el turno; si no, corre check.sh y un fallo sale con código 2 y el error vuelve al agente.

La segunda capa es humana en su forma pero agéntica en su ejecución: un agente revisor distinto, con el modelo más capaz, sin permiso de escribir código. Existe porque el agente que escribió el código es el peor juez posible de ese código. Anthropic lo documentó al diseñar arneses para tareas largas: “When asked to evaluate work they’ve produced, agents tend to respond by confidently praising the work—even when, to a human observer, the quality is obviously mediocre.”

Dónde se queda corta mi configuración: el hook es opcional y no hace nada en un repositorio sin check.sh, así que un repo descuidado sigue sin puerta. El revisor es de la misma familia que el autor (Claude revisando Claude), y hay evidencia de que esa combinación aporta poco. Y no mido la calidad de nada: no llevo registro de cuántas rondas de revisión toma un cambio ni cuántos comentarios humanos sobreviven, así que una regresión en mis propias instrucciones sería invisible.

Cuándo usar cada uno

No son rivales. Son dos puntos de la misma escala, y la variable que decide es cuánto cuesta equivocarse.

Criterio Vibe coding Programación agéntica
Tipo de trabajo Prototipo, demo, script de un solo uso Producción, código con dueño y mantenimiento
Riesgo aceptable Alto: si falla, lo tiras y empiezas de nuevo Bajo: falla con datos, dinero o usuarios reales
Quién revisa Nadie, o tú mirando el resultado Un agente revisor y un humano en el merge
Unidad de trabajo Una conversación Una tarea con criterio de aceptación
Qué corre solo Nada Lint, tipos y pruebas en cada turno
Tu rol Describir y mirar Diseñar el arnés y decidir
Señal de que se acabó “Se ve bien” La comprobación pasa en verde

El caso híbrido es el más común en mi trabajo: empiezo en modo vibe coding para explorar una idea en una rama desechable, y en cuanto decido que eso se queda, lo tiro y lo vuelvo a construir con el flujo agéntico completo. El prototipo sirvió para saber qué construir, no como base.

Herramientas de vibe coding y de programación agéntica

Las herramientas no se dividen limpiamente en dos grupos: casi todas soportan los dos modos con los mismos modelos por debajo, y lo que cambia es dónde ponen el acento.

  • Claude Code (Anthropic): agente de terminal, integrado también en VS Code. Ejecuta comandos, edita archivos y corre pruebas por su cuenta. Soporta agentes especializados, hooks en eventos del ciclo de vida y listas de permisos, que es lo que lo hace usable para programación agéntica.
  • Cursor: editor de código con IA, con chat sobre el repositorio y un modo agente que edita varios archivos. Es el punto de entrada habitual al vibe coding porque el ciclo de describir y ver el resultado ocurre en el mismo editor.
  • Codex (OpenAI): asistente de código con CLI y modo en la nube, orientado a delegar tareas completas sobre un repositorio.
  • GitHub Copilot: autocompletado en tiempo real dentro del editor, más chat y un modo agente.

Lo que ninguna herramienta te da por defecto es la parte que importa: la comprobación que corre sola, el revisor separado y el límite de tamaño de cada cambio. Eso lo configuras tú en cualquiera de ellas, y es exactamente la frontera entre los dos modos de trabajo.

Cómo pasar de vibe coding a programación agéntica en tres pasos

Tres cambios, en este orden. Los tres se implementan en una tarde, funcionan en cualquier repositorio y ninguno depende de una herramienta específica.

1. Una comprobación que corra sola. Escribe un .claude/check.sh en el repositorio con lint, tipos y pruebas unitarias, y conéctalo a un hook de Claude Code en el evento Stop. La única restricción dura es la velocidad: corre en cada fin de turno, a veces varias veces por minuto, así que tiene que tardar segundos. La CI completa se queda en la CI.

#!/usr/bin/env bash
set -euo pipefail
uv run ruff check
uv run mypy src/
uv run pytest -q

2. Un agente revisor separado. Un agente distinto, con instrucciones adversariales y sin permiso de escribir código, que lea el diff y los archivos alrededor. En mi configuración revisa en este orden: alcance (¿este cambio hacía falta para lo que se pidió?), corrección (¿qué entrada o estado hace que esto falle?), verificación (¿el autor realmente probó?) y calidad. Un revisor al que le pides encontrar problemas va a encontrar alguno siempre, así que el criterio para arreglar es que el hallazgo nombre un escenario de falla concreto.

3. Pull requests pequeños. Los cambios chicos se revisan más rápido y mejor, un punto que Google lleva años documentando en Small CLs. Mi límite es un techo de unas 400 líneas, con una aclaración importante: el número es un aviso, no una puerta. El costo real de un cambio es cuántos archivos toca y cuántas preocupaciones mezcla, no cuántas líneas tiene. Y el merge lo autoriza una persona, siempre.

El orden importa. Sin el paso 1, los pasos 2 y 3 solo producen más cosas que leer. Con el paso 1, el agente ya no puede entregarte trabajo roto, y tu atención se libera para lo único que la IA no hace: decidir qué ideas vale la pena construir.

Preguntas frecuentes

¿Qué significa vibe coding?

Vibe coding significa escribir software describiendo lo que quieres en lenguaje natural y aceptando el código generado sin revisarlo en detalle. El término lo acuñó Andrej Karpathy en febrero de 2025. La idea central es que dejas de leer el código y te guías por si el resultado funciona o no.

¿Qué se puede hacer con vibe coding?

Sirve muy bien para prototipos, demos, aplicaciones internas pequeñas y para explorar ideas antes de comprometerte con ellas. También es la vía más rápida para que alguien sin experiencia técnica construya algo que funcione. Donde se rompe es en software con usuarios, datos sensibles o mantenimiento a largo plazo, porque el código generado entra al repositorio sin que nadie lo entienda.

¿Cuáles son las herramientas de vibe coding?

Cursor, Claude Code, Codex de OpenAI, GitHub Copilot y Google AI Studio son las más usadas, y todas aceptan instrucciones en lenguaje natural sobre un proyecto. La distinción no está en la herramienta sino en cómo la usas: las mismas herramientas soportan programación agéntica si les agregas comprobaciones automáticas, un agente revisor y límites de permisos.

¿Vibe coding es bueno o malo?

Es una herramienta con un rango de uso claro, no una postura moral. Permite avanzar rápido cuando equivocarse es barato, y falla cuando el error llega a producción con usuarios reales. Conviene además desconfiar de la intuición de velocidad: el estudio controlado de METR de julio de 2025 encontró que los desarrolladores con acceso a herramientas de IA tardaron 19% más en cerrar issues, aunque ellos creían haber ido más rápido.

¿Qué significa vibe coding en español?

No tiene una traducción establecida; en español se usa el término en inglés. Las versiones que circulan son “programación por vibras” o “programación intuitiva”, y ninguna se ha impuesto. Si necesitas explicarlo en una frase: programar describiendo el resultado, sin revisar el código que lo produce.

Fuentes

vibe codingprogramación agénticaclaude codeia aplicada
← Volver al blog