Qué es el vibe coding y qué riesgo tiene en una empresa

El dolor: código que nadie puede explicar cuando falla

En una constructora mediana de Bogotá, el área comercial necesitaba un cotizador rápido para no depender de la hoja de cálculo que se rompía cada vez que cambiaban los precios de material. Alguien del equipo, sin ser desarrollador, le describió el problema a una IA, recibió un código funcional, lo probó con tres cotizaciones reales y lo puso a correr en la computadora del área comercial. Funcionó durante dos meses. Nadie de sistemas lo sabía.

El día que un cliente reclamó una cotización con un error de cálculo, la pregunta obvia (¿por qué el sistema calculó así?) no tuvo respuesta. La persona que armó el cotizador recordaba la conversación general que tuvo con la IA, no la lógica exacta que quedó escrita en el código. Revisarlo tomó más tiempo que rehacerlo desde cero, porque nadie había verificado nunca qué reglas de negocio había asumido la IA al momento de escribir.

Esto no es un caso aislado de una empresa con mala disciplina técnica. Es lo que pasa en cualquier organización donde alguien, con buena intención y bajo presión de tiempo, encuentra que describirle a una IA lo que necesita es más rápido que pedir una tarea al equipo de sistemas, y ese atajo se vuelve costumbre antes de que exista una regla sobre dónde sí y dónde no aplica.

Qué es el vibe coding, en criterio de negocio

El vibe coding no es una técnica de programación nueva, es un cambio en quién decide si el código está bien: antes lo decidía una revisión técnica, ahora lo decide si el resultado se ve bien en la prueba que alcanzaste a hacer. Esa diferencia parece pequeña y no lo es, porque cambia qué tan seguro puedes estar de que el sistema hace lo que crees que hace.

En criterio de negocio, el vibe coding es velocidad comprada con opacidad. Ganas tiempo de construcción y pierdes certeza de qué hay adentro. Eso es un intercambio razonable cuando lo que estás construyendo es desechable o de bajo riesgo, y es un intercambio caro cuando lo que estás construyendo va a quedarse, va a crecer, o va a tocar algo que le importa a un cliente.

Por eso la pregunta que debería hacerse cualquier gerente no es si su equipo usa IA para escribir código, eso ya casi no distingue nada, sino si alguien revisó lo que quedó escrito antes de dejarlo correr sin supervisión. Esa revisión, no la herramienta, es lo que separa una prueba rápida de una decisión que la empresa va a sostener.

Dónde el vibe coding sí es una buena idea

El vibe coding funciona mejor de lo que la desconfianza técnica suele admitir en un terreno específico: el descubrimiento. Cuando lo que necesitas responder es si una idea funciona antes de invertir en construirla bien, describirle el problema a una IA y ver qué sale es, muchas veces, la forma más barata de obtener esa respuesta.

• Un prototipo para mostrarle a un cliente interno o a un inversionista si una idea de producto tiene forma antes de comprometer presupuesto real.
• Una prueba interna que solo va a usar la persona que la construyó, sin tocar datos de otros ni depender de que siga corriendo mañana.
• Una herramienta de uso personal para ordenar algo propio: automatizar una tarea repetitiva en tu propia computadora, sin que nadie más dependa de ella.
• Validar en horas una hipótesis de negocio que de otra forma tomaría semanas de desarrollo formal, cuando el costo de estar equivocado es bajo.
• Un experimento que se va a botar sin importar el resultado, donde el valor está en la respuesta que da, no en el código que queda.

Dónde el vibe coding se convierte en una decisión cara

El mismo atajo que es barato para descubrir se vuelve caro en el momento en que el resultado empieza a sostener algo que otros van a usar. La frontera no es técnica, es de exposición: qué tan cerca está ese código de un cliente real, de dinero real o de un dato personal.

• Cualquier flujo que toque el cobro o pago de un cliente, porque un error silencioso ahí no se descubre en una prueba, se descubre en un reclamo.
• Cualquier sistema que almacene o procese datos personales, donde una decisión de diseño que nadie revisó puede convertirse en una filtración o un uso indebido.
• Cualquier proceso que otra área de la empresa empieza a dar por hecho, porque ya nadie recuerda que nació como una prueba rápida y no como algo diseñado para durar.
• Cualquier integración con un sistema externo o con otro sistema interno crítico, porque el error deja de ser local y se propaga a algo que ya funcionaba.
• Cualquier cosa que un cliente externo va a ver o usar directamente, donde la reputación de la empresa queda atada a un código que nadie audita.

En ninguno de estos casos el problema es que el código sea feo o esté mal organizado. Un desarrollador experimentado puede escribir código desordenado y aun así saber exactamente qué hace y por qué. El problema real es otro, y aparece más adelante en esta misma página.

El riesgo real no es el código feo

La objeción más común contra el vibe coding es estética: que el código queda desordenado, mal nombrado, sin buenas prácticas. Esa objeción distrae de lo que de verdad importa. Un código feo pero entendido se puede mantener. Un código bonito pero que nadie entiende, no.

El riesgo real es la pérdida de capacidad de cambio y de auditoría. Cuando nadie en la empresa puede explicar con certeza qué hace una parte del sistema, ni por qué está escrita así, dos cosas dejan de ser posibles: modificarla con confianza cuando el negocio lo necesita, y verificarla cuando algo sale mal o cuando un regulador, un cliente o un auditor pregunta cómo se procesó un dato o un cálculo.

Esto conecta directo con lo que en este glosario se trata como deuda técnica de IA: cada línea de código que nadie revisó a fondo es una obligación futura que la empresa todavía no sabe que contrajo. No se paga cuando el sistema es chico y lo usa una sola persona. Se paga completa el día que ese sistema tiene que escalar, integrarse con otro, o sobrevivir a que la persona que lo pidió ya no esté en la empresa.

Por eso la pregunta que de verdad protege a una empresa no es qué tan bien escrito está el código, es si existe al menos una persona capaz de explicarlo, cambiarlo y responder por él sin depender de reconstruir de memoria una conversación con una IA.

La regla práctica: se vibe codea el descubrimiento, no la operación

Toda esta página se reduce a una regla que se puede aplicar sin necesitar formación técnica: se puede vibe codear el descubrimiento, no la operación. Descubrir si una idea funciona, si un cliente la entiende, si un flujo tiene sentido, admite el atajo. Operar algo de lo que la empresa va a depender, no.

Aplicar esa regla en la práctica no requiere prohibir nada, requiere tres decisiones simples antes de que alguien pida el primer prototipo. Primero, dónde corre: un entorno aislado, lo que en este glosario se describe como un sandbox de IA, separado de cualquier dato real de cliente. Segundo, quién decide que algo pasa de prueba a producción, y con qué revisión, no con la sensación de que ya funciona. Tercero, qué pasa el día que esa prueba resulta útil: se convierte en lo que aquí se llama un MVP con IA, construido con criterio de negocio y con alguien que pueda sostenerlo, o se descarta.

También ayuda separar el rol de quien prueba del rol de quien automatiza procesos de forma recurrente para la empresa, que suele apoyarse en un agente de código o en lo que en este glosario se define como un automatizador. Esos roles trabajan con supervisión y trazabilidad desde el diseño, no como un experimento que se coló en producción sin que nadie lo decidiera así.

Mi criterio

Cuándo sí y cuándo no usar vibe coding

No hace falta ser desarrollador para aplicar este criterio, hace falta mirar quién depende del resultado y qué tan cerca está de algo que la empresa no puede darse el lujo de que falle.

Señales de que el vibe coding es la decisión correcta

• Lo que estás construyendo se va a usar en las próximas horas o días, no en los próximos meses.
• Solo tú, o un grupo muy chico, va a usar el resultado, y nadie más depende de que siga funcionando.
• No toca ningún dato de un cliente real ni ningún proceso de cobro o pago.
• El objetivo es responder una pregunta de negocio (¿esto tiene sentido?, ¿la gente lo entiende?), no entregar un sistema terminado.
• Estás dispuesto a botar el resultado por completo si la respuesta a la pregunta anterior es no.

Señales de que el vibe coding es una mala decisión

• El resultado va a tocar dinero de un cliente, un cobro, un pago o cualquier cálculo del que dependa una factura.
• El sistema va a almacenar o procesar cualquier dato personal, así sea de un solo cliente.
• Otra área de la empresa va a empezar a depender de que ese sistema siga funcionando mañana.
• Nadie en el equipo puede explicar, sin volver a leer el código con calma, qué hace cada parte y por qué.
• La persona que lo construyó es la única que entiende cómo funciona y no va a estar disponible para mantenerlo.

El orden correcto también aplica aquí

El error de fondo detrás de los peores casos de vibe coding no es haber usado una IA para escribir código, es haber empezado por la herramienta. El orden que sí funciona es el mismo en cualquier decisión de IA en una empresa: primero el dolor real que quieres resolver, después el proceso que ese dolor necesita, después qué dato vas a necesitar para sostener ese proceso, y solo al final la herramienta que lo ejecuta. El vibe coding, usado como método de descubrimiento dentro de ese orden, es rápido y razonable. Usado para saltarse ese orden entero y llegar directo a un sistema corriendo, es una apuesta que la empresa termina pagando sin haber firmado el contrato.

La empresa que sabe distinguir entre probar una idea y sostener una operación no pierde velocidad, la gana donde importa: descubre rápido lo que no sirve, y construye con calma lo que sí. La que no distingue esa frontera no tiene un problema de código, tiene un sistema entero del que nadie puede responder, y eso se paga siempre más caro que el tiempo que se ahorró escribiéndolo rápido.