Vibe coding vs agentic coding: la guía de decisión para fundadores no técnicos

Un fundador con quien trabajamos, ex asociado de PE y hoy CEO de un SaaS vertical para clínicas, abrió un Loom el mes pasado con la frase “vibe codeé esto el fin de semana, ¿lo pueden terminar?”. El Loom mostraba un flujo de reservas funcionando, un generador de facturas funcionando, y el principio de un producto de verdad. También mostraba tres versiones del mismo schema de base de datos en tres archivos distintos, dos implementaciones de auth compitiendo entre sí, y una carpeta llamada final_v3_actually_final con una app de React entera que él había olvidado que empezó.

Vibe coding lo llevó a una demo en dos días. Agentic coding lo habría llevado a un producto. Usó la herramienta correcta para la etapa equivocada, y la cuenta de la limpieza fueron ocho semanas de nuestro equipo.

Este es el texto sobre vibe coding vs agentic coding para fundadores no técnicos. Los dos son reales. Los dos funcionan. La elección entre ellos es una decisión de etapa, no un debate de metodología, y equivocarse es ya uno de los errores más caros que un fundador puede cometer en su primer año.

Qué es vibe coding, en la práctica

Vibe coding es el término que Andrej Karpathy popularizó a principios de 2025 para describir una forma específica de escribir software con un LLM. Describes en lenguaje natural lo que quieres, aceptas el código que el modelo produce, lo ejecutas, y cuando se rompe le describes el bug al modelo y aceptas el arreglo. No lees el código con cuidado. Te “entregas a las vibes”, como él mismo dijo, y juzgas el resultado por si la pantalla hace lo que querías.

La entrega del vibe coding es un artefacto que funciona. El costo es que no sabes lo que tiene dentro. El modelo eligió la estructura, el modelo eligió las librerías, el modelo eligió el patrón de auth, y tú eres el product owner de un código que no puedes leer.

Para un prototipo de fin de semana, está bien. Para una demo clicable que pruebe una hipótesis con cinco clientes, está más que bien. Para cualquier cosa que tenga que seguir corriendo mientras hay clientes que dependen de ella, esto es un instrumento de deuda.

Qué es agentic coding, en la práctica

Agentic coding es lo que pasa cuando los mismos LLMs se envuelven en un loop de planificación, un loop de uso de herramientas y un loop de feedback, y se apuntan a una codebase real bajo prácticas de ingeniería reales. El agente lee el código existente, planifica los cambios, escribe tests, los corre e itera hasta que el trabajo esté demostrado. Un ingeniero senior revisa y hace merge.

La entrega del agentic coding es software publicado. El modelo escribió, pero las decisiones de ingeniería (qué construir, dónde ponerlo, cómo testearlo, cómo falla con seguridad) las toma una persona que responde por ellas. La codebase tiene forma. El trabajo nuevo encaja en esa forma. Cuando algo se rompe, alguien puede encontrar la causa sin tener que llamar a Karpathy.

Si vibe coding es boceto, agentic coding es plano. Los dos dejan líneas en un papel. Solo uno de ellos es algo que puedes entregarle a un constructor.

¿Vibe coding y agentic coding son lo mismo?

No, y la confusión entre ellos es lo que hace que la herramienta equivocada se siga eligiendo en la Series A.

La confusión tiene sentido. Los dos involucran a una persona escribiendo en una caja de chat y a una IA produciendo código. La acción mecánica es idéntica. La diferencia está en lo que pasa alrededor de la salida de la IA.

Vibe coding no tiene superficie de revisión. El autor es juez y jurado, y el criterio es “la pantalla hizo la cosa”. Agentic coding tiene las mismas superficies de revisión que un equipo de ingeniería de verdad siempre tuvo: code review, suite de tests, pipeline de deploy, on-call. La IA está dentro de esa máquina. La máquina sigue funcionando.

Una prueba útil: si la entrega se rompe dentro de seis meses, quién la arregla, y cómo entiende esa persona qué se construyó. En vibe coding, la respuesta es “reescríbelo desde el historial de prompts, si alguien recuerda qué se pidió”. En agentic coding, la respuesta es “lee el código, lee los tests, lee los PRs”.

Dónde funciona vibe coding de verdad

Hemos usado vibe coding nosotros mismos. Lo vamos a seguir usando. Hay tres lugares donde paga lo que cuesta.

Prototipos descartables que existen para matar una idea. Si puedes construir la cosa un sábado y la respuesta es “no, ningún cliente quiere esto”, te ahorraste un trimestre de ingeniería real. El descartable es el punto. No le pongas un cliente encima. No le pongas tu ronda encima.

Experimentos internos donde tú eres el único usuario. Un script de admin improvisado, una limpieza puntual de datos, un reemplazo temporal de Google Sheets que vive seis semanas durante un lanzamiento. Si se rompe, lo arreglas o lo dejas. Nadie más depende de eso.

El primer MVP, con fecha de vencimiento firme. Este es el peligroso. Vibe coding produce un MVP creíble en un fin de semana, y la credibilidad de la demo seduce al fundador a dejar que clientes que pagan lo usen. La regla que damos a clientes: si vibe codeaste el MVP, tienes noventa días para reemplazar la fundación o matar el producto. Cualquier otra cosa es un accidente en cámara lenta.

El patrón en los tres casos es el mismo. La entrega tiene una vida corta conocida y la consecuencia de que se rompa está acotada. En cuanto el producto cruza al territorio de “hay gente dependiendo de esto y no vamos a parar”, vibe coding es la herramienta equivocada.

Dónde funciona agentic coding de verdad

Agentic coding es la herramienta correcta en todo lugar donde vibe coding es la equivocada. Y eso incluye la mayor parte de lo que una startup efectivamente publica.

La ganancia sobre un equipo puro de humanos no es “la IA escribe código, así que no necesitamos ingenieros”. Es que un equipo pequeño de seniors produce notablemente más. Hemos medido algo así como un 40 a 60 por ciento de aumento de output por ingeniero en el tipo de trabajo de producto CRUD-pesado que llena la mayor parte de un roadmap early-stage. El ingeniero senior sigue haciendo el pensamiento que sostiene todo: la arquitectura, el modelo de datos, los modos de falla, los límites de seguridad. El agente absorbe la escritura, el boilerplate y una parte significativa de los tests.

La trampa a evitar es usar agentic coding sin el senior. Los agentes producen alegremente código arquitectónicamente equivocado con plena confianza y cobertura completa de tests de la cosa equivocada. No son revisores que sostienen la decisión. Son colaboradores junior muy rápidos. El ingeniero senior sigue siendo el revisor que sostiene la decisión, y la startup que despide a los seniors porque “ahora los agentes hacen el trabajo” repite el mismo error que la ola de no-code nos enseñó. Confunde la apariencia de palanca con la sustancia de ella.

Esto conecta directamente con un consejo que ya escribimos: el CTO que no puedes contratar casi nunca es tu problema real en Pre-Seed y Seed. El ingeniero senior sí lo es. Vibe coding no cambia esa cuenta. Agentic coding hace al senior más productivo, lo cual hace la cuenta menos dolorosa, pero no elimina la necesidad.

¿Vibe coding es mejor que codear?

Esta es la pregunta equivocada, y recibimos alguna versión de ella en cada call de fundador este año.

Es la pregunta equivocada porque “codear” no es una sola actividad. Escribir la primera prueba de que un flujo es posible es distinto de escribir la versión en la que un hospital va a confiar. La primera quiere velocidad y baja penalización por estar equivocada. La segunda quiere correctitud y baja penalización por cambiar después. Distintas herramientas ganan en distintas etapas.

Un encuadre más útil: vibe coding es más rápido que agentic coding en la primera hora de un proyecto, y más lento que agentic coding en cada hora siguiente. El cruce ocurre en algún punto cerca de la tercera feature, cuando la codebase es lo bastante grande para que el modelo necesite contexto que el prompt no puede entregar fácilmente, y los cambios en una parte del sistema empiezan a romper otras partes que el modelo nunca supo que existían.

Los fundadores que más valor sacan de la codificación asistida por LLM son los que usan vibe coding como prueba de viabilidad y luego cambian a un proceso de ingeniería de verdad (agentic u otro) para la construcción. Los fundadores que se hacen daño son los que nunca hacen ese cambio.

¿Los vibe coders entienden su propio código?

Respuesta honesta: en general no, y ese es el diseño.

La propuesta entera del vibe coding es que no necesitas entender el código para entregar el artefacto. Eso es un ahorro real para un boceto. Se vuelve un pasivo real en el momento en que necesitas cambiar el artefacto. Cada cambio es otra ronda de describir-y-rezar. Cada bug se debugea por síntomas, no por causas. Y toda presión externa (una revisión de seguridad, una auditoría SOC 2, un partner de integración pidiendo ver tu spec de API) expone la falla.

Hemos reconstruido tres sistemas vibe-coded este año. El patrón fue idéntico cada vez. El fundador se quedó sin vibes alrededor del tercer mes, cuando el modelo empezó a insistir en cambios que rompían producción y se negaba a recordar restricciones que estaban dos prompts atrás. Pedirle al modelo que arregle el trabajo del propio modelo a partir de cierto nivel de complejidad es una cinta. En algún momento te bajas y le pagas a un ingeniero para leer todo.

Cobramos menos por reconstruir un sistema vibe-coded que por rescatar uno no-code, pero más que por construir el mismo producto desde cero. El caso del medio es el más caro de los tres. La codebase tiene forma, pero la forma está equivocada, y deshacerla lleva más tiempo que empezar limpio.

Una regla de decisión por etapa

La forma más limpia que encontramos de pensar vibe coding vs agentic coding es por etapa y por usuario.

Si la pregunta es “esta idea funciona, y soy el único que la va a tocar”, vibe code. Vas rápido, lo tiras, y tratas cualquier cosa que sobreviva como un accidente feliz.

Si la pregunta es “quiero ponerlo frente a cinco clientes para ver si me lo arrancan de las manos”, vibe code la demo, pero escribe el contrato contigo mismo antes de empezar. No vas a dejar que la demo se vuelva el producto. En el instante en que el quinto cliente dice sí, empieza la construcción real.

Si la pregunta es “esto va a producción, los clientes van a depender, y no lo apagamos en seis semanas”, eso es territorio de agentic coding, con un ingeniero senior sosteniendo la pluma y el LLM sosteniendo el teclado. El senior es no negociable. La suite de tests es no negociable. El pipeline de deploy es no negociable. Ninguna de esas cosas se vuelve negociable solo porque hay una IA en el loop.

Si la pregunta es “ya vibe codeamos el MVP y los clientes están usándolo”, tienes un reloj. Noventa días, y o se reemplaza la fundación o se apaga el producto. Cuanto más corre el reloj, más cara se vuelve la reconstrucción, y la reconstrucción va a pasar de todos modos. Lo vimos pasar en seis engagements de cliente este último año. Siempre pasa. Pasa más rápido de lo que esperas.

La elección real del fundador no técnico

La pregunta de vibe coding vs agentic coding se enmarca como una pelea entre dos técnicas de IA. No lo es. Es una pregunta de etapa vestida de herramienta.

Estás decidiendo, en cada superficie de producto, cuánto quieres que dure el trabajo. Vibe coding optimiza para la primera versión de una respuesta. Agentic coding optimiza para la versión que sobrevive a la segunda versión. Los dos tienen su lugar. Ninguno es una religión.

Los fundadores que aciertan tratan al vibe coding como tratan a un modelo financiero de servilleta: útil, rápido, tíralo antes de que tome una decisión real por ti. Agentic coding es el estado financiero auditado. No diriges una empresa con la servilleta. Tampoco diriges una empresa con vibes.

Si quieres una versión más afilada de este razonamiento aplicada a tu propio producto, es la mitad de las conversaciones que estamos teniendo con fundadores ahora. Lee nuestro texto sobre lo que un MVP es realmente para el encuadre que usamos para trazar la línea. Y si estás decidiendo si traer una software house al juego, la misma lógica de etapa aplica. Elige el partner cuyo default es la próxima etapa, no la actual.

La síntesis cabe en una frase. Vibe coding construye la pregunta. Agentic coding construye la respuesta. No entregues la pregunta.