El 2 de febrero de 2025 Andrej Karpathy, investigador en IA y uno de los fundadores de OpenAI, escribió en X una publicación que dio nombre a todo un fenómeno. Describió una forma nueva de programar: entregarse por completo al «vibe», dictar las tareas a la red neuronal por voz, casi sin tocar el teclado, aceptar todas sus correcciones y olvidar que el código existe. En la misma publicación él mismo aclaró que para proyectos de un fin de semana y de usar y tirar esto «no está tan mal», y reconoció que ya no lee los diffs, las listas de cambios en el código.
La palabra se quedó. Ahora «vibe coding» nombra casi cualquier desarrollo en el que el código lo escribe una red neuronal a partir de una descripción en lenguaje corriente. Para un negocio esto sí abrió posibilidades nuevas: un landing, una herramienta interna o un prototipo se pueden armar sin un equipo de desarrolladores. Pero la reserva de Karpathy sobre los proyectos de fin de semana no desapareció. Voy a separar qué puede armar un negocio por su cuenta y dónde, sin un desarrollador, al proyecto le cuesta llegar al lanzamiento.
Qué es el vibe coding
El vibe coding es cuando usted describe con palabras lo que quiere obtener y la red neuronal escribe el código. Mira el resultado, dice qué corregir, y así en círculo. En el código se puede no entrar: se valora lo que se ve en la pantalla.
Para esto se usan chats como ChatGPT o Claude, agentes de IA para código y servicios especiales que arman la aplicación a partir de la descripción y muestran el resultado enseguida.
El lado fuerte del enfoque es la velocidad de la primera versión. Lo que antes exigía un trabajo notable del desarrollador ahora se arma mucho más rápido. El lado débil es todo lo que ocurre después de la primera versión. Cuando usted no lee el código, no sabe cómo está hecho lo que obtuvo, y cada corrección siguiente puede romper algo en un lugar inesperado.
En la práctica una sesión de vibe coding se ve así. Escribe: «Haz una página con un formulario para reservar una consulta». La red neuronal entrega el código, usted abre el resultado y ve que el botón no es del color y que el campo del teléfono acepta letras. Lo escribe, recibe una versión corregida y vuelve a mirar. Tras varias vueltas la página se ve como debe. Qué cambió exactamente en el código en esas vueltas, usted no lo sabe, y en eso está toda la esencia del enfoque. Y su riesgo principal.
También importa que la red neuronal casi nunca se niega. Pídale añadir el pago, un área personal o una integración con el CRM, y escribirá el código. La pregunta no es si lo escribirá, sino si ese código será fiable cuando lo usen clientes de verdad.
El vibe coding y el bloque vibe de Tilda no son lo mismo
Tilda tiene un bloque vibe: un bloque de la biblioteca que genera su contenido con IA a partir de un pedido en el chat. El resultado se puede ajustar: cambiar el contenido, el estilo o el código, y también convertirlo en Zero Block (una función en prueba beta). Es una herramienta dentro del constructor: crea un bloque aparte en la página de Tilda, y el hosting, los formularios y el resto de la infraestructura se quedan en la plataforma. El vibe coding en sentido amplio es el desarrollo de un sitio o una aplicación enteros, donde todas esas preguntas hay que resolverlas uno mismo. Yo no uso bloques vibe: para el desarrollador es un camino fácil, pero para el cliente es una mina bajo el mantenimiento posterior del sitio, porque él y sus gestores reciben en el editor un contenido incomprensible. Mi principio es que la página en el editor, en Zero Block, se vea lo más parecida posible a la publicada y se pueda corregir con claridad. Además, la función sigue en pruebas: la propia Tilda advierte que para corregir el código de un bloque vibe hacen falta conocimientos básicos de HTML, CSS y JavaScript, el soporte no asesora sobre el código, y la conversión a Zero Block está en beta.
Qué puede armar un negocio por su cuenta
Landing
Un sitio de una página es la variante más clara. La estructura es simple, hay poca lógica y el resultado se comprueba fácil a ojo. La red neuronal armará una página con bloques, textos y maquetación adaptable, y después hay que colocarla en el hosting y conectar el formulario.
Dónde esperan los problemas: un formulario que parece que funciona pero no envía las solicitudes a ninguna parte; una página que se ve bien en el ordenador y se rompe en el teléfono; textos en los que la red neuronal añadió promesas que usted no hizo. Todo eso se resuelve si se revisa.
Un orden razonable para un landing es este: primero la estructura y los textos que usted revisó, después el código, después la prueba en el teléfono, después la publicación y una solicitud de prueba. Si en algún paso queda claro que la tarea es más compleja de lo que parecía — por ejemplo, hace falta una reserva con elección de hora o un pago —, es un buen momento para parar y pensar si no conviene tomar un constructor o un desarrollador.
Herramienta interna
El área más acertada del vibe coding en un negocio son las herramientas para uno mismo. Una calculadora para los gestores, una tabla de solicitudes con una interfaz cómoda, un generador de propuestas comerciales a partir de una plantilla, un panel simple con los indicadores clave de una tabla.
Por qué es un área acertada: los usuarios son los propios empleados, que avisarán de un error; los datos a menudo no salen de la empresa; si algo se rompe, es desagradable, pero no es crítico para los clientes. Y lo principal: esas tareas a menudo no llegan a los desarrolladores durante años, porque son demasiado pequeñas. El vibe coding permite resolverlas por cuenta propia.
Una reserva: «interno» no significa «sin datos personales». Si en su tabla de solicitudes hay nombres y teléfonos de clientes, la herramienta interna también trabaja con datos personales. Entonces conviene pensar dónde está alojada, quién tiene acceso y si no quedará abierta por casualidad para todos mediante un enlace.
Prototipo de un servicio
Un prototipo es un modelo de trabajo de una idea que se puede mostrar a clientes, socios o desarrolladores. No para lanzarlo, sino para comprobar: si la gente lo necesita, cómo lo usa, qué no se entiende.
Para un prototipo el vibe coding encaja de forma ideal: la velocidad importa más que la calidad del código, y tirarlo y rehacerlo no duele. Un prototipo de una mini aplicación, de un área personal o de un catálogo se puede armar y probar con personas reales antes de invertir en un desarrollo completo.
Dónde hace falta un desarrollador
Datos de clientes y accesos
En cuanto en el proyecto aparecen datos de clientes — nombres, teléfonos, direcciones, historial de pedidos —, el error deja de ser pequeño. Una filtración por una configuración incorrecta, acceso al área personal de otra persona, contraseñas en claro dentro del código: la red neuronal puede cometer cualquiera de estos errores, y en el vibe coding no hay quien los note.
Aquí entran también los accesos: claves de servicios, contraseñas de bases de datos, tokens. La red neuronal puede escribirlos directo en el código, que después queda a la vista de todos. El desarrollador sabe dónde guardar esas cosas y cómo comprobar que no se filtraron.
Pago e integraciones
Cobrar pagos, la conexión con el CRM, el intercambio de datos con el servicio de entrega, el envío de recibos: cada integración tiene sus reglas, sus límites y sus formas de romperse. Un error en el pago significa dinero perdido o clientes descontentos. Un error en la integración significa solicitudes perdidas o datos incorrectos en otro sistema.
La red neuronal escribirá el código de la integración según la documentación, pero comprobar que trata bien los errores, las repeticiones y los casos límite es difícil sin entender el código.
Cambios al cabo de medio año
Lo más subestimado. La primera versión funciona, todos están contentos. Medio año después hay que añadir una función, cambiar la lógica, actualizar una biblioteca vieja. Y resulta que nadie sabe cómo está hecho el código. La red neuronal a la que usted describe la tarea nueva tampoco lo sabe: ve el código por primera vez y puede proponer un cambio que rompa algo en otro sitio.
Cuanto más vive el proyecto y cuantas más correcciones tiene, más se nota. El código que nadie leyó se convierte con el tiempo en código que nadie puede cambiar con seguridad.
| Tarea | Por su cuenta | Con un desarrollador | Por qué |
|---|---|---|---|
| Landing sin formularios complejos | Sí | Si se quiere | Poca lógica, fácil de comprobar |
| Calculadora o tabla interna | Sí | Si se quiere | Usuarios propios, datos dentro |
| Prototipo para probar una idea | Sí | No es obligatorio | El objetivo es la prueba, no el lanzamiento |
| Área personal con datos de clientes | Prototipo | Sí | Seguridad de los datos y de los accesos |
| Cobro de pagos | No | Sí | Los errores cuestan dinero |
| Integraciones con CRM y servicios | Prototipo | Sí | Tratamiento de errores y repeticiones |
| Un proyecto que va a seguir creciendo | Primera versión | Sí | Hay que entender el código para cambiarlo |
Cómo entender que el prototipo ya hay que pasarlo a desarrollo
El prototipo hizo su trabajo si en él se pudo comprobar la idea. Después conviene mirar con honestidad las señales de que ya toca llamar a un desarrollador.
La primera señal: aparecieron usuarios reales y sus datos. Mientras el prototipo lo usan los colegas con datos de prueba, los errores no asustan. Cuando llegan clientes con teléfonos y direcciones de verdad, la responsabilidad cambia.
La segunda: hace falta el pago o integraciones con sistemas externos. Es el lugar donde los errores cuestan dinero o solicitudes.
La tercera: cada corrección nueva rompe algo viejo. Si nota que arregla una cosa y se rompe otra, el código se volvió demasiado enredado para llevarlo a ciegas.
La cuarta: le da miedo cambiar algo. Es una señal segura de que ya no controla el proyecto.
La quinta: el proyecto hace falta para mucho tiempo. Si la herramienta debe funcionar y crecer durante años, su código debe ser comprensible para una persona, no solo para la red neuronal.
Pasar el prototipo a desarrollo no significa reconocer un fracaso. Al contrario: un prototipo que funciona es el mejor encargo para un desarrollador. Muestra qué hay que hacer, cómo debe verse y cómo trabajan con ello los usuarios. Eso es mucho más claro que cualquier descripción en texto.
También hay una variante intermedia: mostrar el prototipo a un desarrollador para una auditoría. Mirará el código y marcará qué se puede dejar, qué es peligroso y qué habrá que reescribir. A veces resulta que la base es bastante viable y solo hay que terminar la seguridad y las integraciones. A veces, que es más simple escribirlo de nuevo usando el prototipo como muestra. En ambos casos la decisión se toma a partir de entender el código, no de una esperanza.
Si su prototipo llegó a este punto, mire el desarrollo a medida. Si es una aplicación dentro de Telegram, el desarrollo de una Telegram Mini App. Y qué hacer con el prototipo se puede hablar por el cuestionario de mara-craft.com: miraré qué se puede dejar y qué conviene rehacer.