Vibe coding vs agentic coding: quién verifica el código

El vibe coding es aceptar lo que genera la IA sin leer el código; el agentic coding (o ingeniería agéntica) es delegar la ejecución en agentes de código y conservar tú el criterio: qué se construye, cómo se comprueba, quién lo revisa y quién responde si falla. La herramienta puede ser exactamente la misma. Lo que cambia es quién verifica.

Si estás construyendo software con IA y no tienes claro en cuál de los dos estás, la tabla y las preguntas de abajo te lo dicen en un minuto.

Vibe coding vs agentic coding, de un vistazo

	Vibe coding	Agentic coding (ingeniería agéntica)
Qué haces con el código	Lo aceptas sin leerlo	Lo delegas, pero lees el diff o lo compruebas con tests
Cómo pides	Una frase en el chat y ves qué sale	Un encargo con objetivo, límites, criterio de aceptación y forma de comprobarlo
Quién verifica	Nadie, o tú probándolo a ojo	Los tests y una revisión que haces tú
Qué entregas	Algo que parece funcionar	Algo que sabes explicar y que falla de forma visible si se rompe
Si falla en producción	No sabes por dónde empezar a mirar	Hay un test o una spec que dice qué debía pasar
Dónde encaja	Prototipos y cosas de usar y tirar	Lo que van a usar o mantener otras personas

¿Qué es el vibe coding y quién lo inventó?

El vibe coding es un estilo de programar con IA donde dejas de mirar el código. Lo acuñó Andrej Karpathy en un tuit del 2 de febrero de 2025: «there’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists»^[1], es decir, entregarte a las vibras y olvidar que el código existe.

Lo que describía era muy concreto: pulsa siempre «Accept All», ya no lee los diffs (la lista de líneas que ha cambiado el agente) y pega los errores en el chat sin comentar nada. Y él mismo le puso el techo: «not too bad for throwaway weekend projects», razonable para proyectos desechables^[1].

Fíjate en que la definición gira en torno a dejar de mirar el código, y no a usar IA ni a que sea algo malo. Por eso usar un asistente de código no te convierte en vibe coder por sí solo: lo hace dejar de leer lo que te devuelve.

¿De dónde sale «agentic coding» y qué tiene que ver con vibe engineering?

Los nombres del otro lado todavía no están fijados. En febrero de 2026, Karpathy dijo que su nombre favorito para diferenciarlo era agentic engineering: «agentic because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight»^[2]. Es decir, casi nunca escribes el código directamente: orquestas agentes que lo escriben y supervisas. Lo de «engineering» era para subrayar que hay un oficio que se aprende^[2].

Antes, en octubre de 2025, Simon Willison había propuesto vibe engineering para el mismo terreno: frente a «irresponsibly building software through dice rolls, not caring what code is produced», el uso responsable de asistentes por parte de ingenieros con experiencia, con tests, planificación, documentación y revisión^[3].

Agentic coding, agentic engineering y vibe engineering se solapan y nadie los ha estandarizado, así que nos conviene quedarnos con la práctica y no con la etiqueta. Y si la comparación que buscas es vibe coding vs software engineering: la ingeniería de software es el oficio entero (entender qué hace falta, diseñar, probar y mantener), el vibe coding es una forma de producir código que se salta esa parte, y el trabajo agéntico dirigido es seguir haciendo ingeniería con agentes que teclean por nosotros.

¿En cuál de los dos estás? Cuatro preguntas

Respóndelas sobre lo último que construiste con IA:

• ¿Leíste el diff antes de aceptarlo?
• ¿Podrías explicarle a alguien qué hace ese cambio y por qué?
• ¿Hay algo, un test o una comprobación automática, que se pondría rojo si se rompiera?
• ¿Sabes a qué datos o permisos accede?

Si contestaste que no a casi todas, estabas haciendo vibe coding, y no pasa nada mientras lo que esté en juego sea poco. El problema llega cuando ese código se queda a vivir y otra persona depende de él.

La diferencia se nota ya al pedir las cosas. Un mensaje de ejemplo, inventado para ilustrar:

Vago: "Hazme el login con Google."

Dirigido: "Añade login con Google en la ruta /auth. No toques el modelo de
usuarios. Está listo cuando un usuario nuevo se crea una sola vez aunque
pulse el botón dos veces, y hay un test que lo comprueba."

El segundo es mejor porque tiene un criterio de aceptación, la condición que tiene que cumplirse para dar la tarea por terminada, y puedes comprobarlo sin fiarte de una sensación. Cuánto puedes soltarle a un agente depende de cuánto puedes comprobar, y eso lo desarrollo en la brecha de delegación entre usar IA y delegar de verdad. Y si quieres que ese criterio sobreviva de una sesión a otra, se escribe: lo explico en cómo convertir la spec en la memoria del equipo con spec-driven development.

¿Son prompt engineering y context engineering lo contrario del vibe coding?

No, miden otra cosa. Prompt engineering y context engineering tratan de cómo alimentas al modelo: qué le dices y qué ve en cada paso. Vibe coding frente a agentic coding trata de si verificas lo que sale. Son dos ejes distintos.

Puedes darle un contexto perfecto a un agente y aceptar todo sin leer, que sería vibe coding muy bien alimentado, o escribir prompts mediocres y revisar cada diff, que ya es trabajo dirigido. Un buen contexto ayuda a que el agente acierte, pero no sustituye a comprobar. Cada eje tiene su guía: los patrones de prompt engineering para desarrolladores y context engineering, la habilidad de gobernar lo que ve el modelo.

¿Cuándo vale cada uno?

El vibe coding vale para un prototipo o un script que vas a tirar, siempre que no toque datos de otras personas ni dinero y lo reescribas si sigue adelante. El trabajo agéntico dirigido es lo que necesitas cuando alguien más va a usar el resultado, cuando hay que mantenerlo, o cuando vas a tener que responder tú de lo que hace.

En los dos casos respondemos nosotros del resultado. Lo único que cambia es si tenemos con qué demostrar que funciona. Si quieres practicar esa parte, la trabajamos con ejercicios en el curso Patrones de Diseño para Agentes de IA.

Fuentes

1. «Vibe coding» — Andrej Karpathy (X) — tuit del 2 de febrero de 2025 que acuña el término, con «Accept All», los diffs sin leer y «throwaway weekend projects».
2. Retrospectiva de Karpathy (X) — tuit del 4 de febrero de 2026 donde propone «agentic engineering».
3. Vibe engineering — Simon Willison — propuesta del 7 de octubre de 2025 (tuit).

Preguntas Frecuentes

¿Qué es el vibe coding en una frase?

Programar con IA aceptando el resultado sin leer el código. Lo definió Andrej Karpathy en febrero de 2025.

¿Vibe coding y agentic coding son lo mismo con otro nombre?

No, aunque a menudo usen las mismas herramientas. En vibe coding aceptas el resultado sin leerlo; en agentic coding delegas la escritura, pero tú defines el objetivo y el criterio de aceptación, y hay tests o una revisión que verifican el resultado antes de darlo por bueno.

¿Vibe coding es lo mismo que vibe engineering?

Es casi lo contrario. Simon Willison propuso «vibe engineering» para distinguir el uso responsable de asistentes de código, con tests, planificación, documentación y revisión, del vibe coding, que describió como construir software a base de tirar los dados sin fijarse en qué código sale.

¿Puede un junior hacer vibe coding?

Para aprender y para prototipos, sí. El riesgo es que, sin experiencia, te falta con qué juzgar lo que aceptas, así que conviene crear el hábito de leer el diff de lo que te importa, pedir un test junto a cada cambio y preguntarle al agente que te explique lo que no entiendas.