Vibe coding: crear software es más fácil, pero diseñarlo sigue siendo clave

El llamado «vibe coding» permite crear prototipos y fragmentos de software mediante instrucciones escritas en lenguaje natural, pero esa velocidad puede transformarse en un problema cuando se reemplazan el diseño, la validación y la supervisión técnica. El caso citado por El Economista resume el riesgo: una plataforma de facturación desarrollada con inteligencia artificial funcionó en una demostración, pero luego duplicó comprobantes, se cayó con pocos usuarios y expuso información de clientes.

El entusiasmo alrededor del vibe coding se explica por una transformación concreta: las herramientas de inteligencia artificial ya pueden producir código a partir de pedidos formulados como una conversación. Una persona describe una pantalla, un formulario, una base de datos o una función y recibe, en pocos minutos, una primera versión operativa. El resultado puede parecer sorprendente, especialmente para equipos que antes necesitaban semanas de trabajo para construir un prototipo.

Según Fuente original, la información se basa en Poner ladrillos es gratis, doña Rosa: el problema es el plano.

Para ampliar el contexto, también puede leerse La inteligencia artificial busca integrarse al trabajo diario de las empresas.

Sin embargo, generar código no equivale a diseñar un sistema. La diferencia es determinante para cualquier empresa que procese pagos, emita facturas, administre inventarios, coordine transporte o almacene datos personales. Una aplicación puede abrirse correctamente, mostrar botones atractivos y completar una operación sencilla, pero fallar cuando varios usuarios trabajan al mismo tiempo, cuando se interrumpe una conexión o cuando un dato llega en un formato inesperado.

Para ampliar el contexto, también puede leerse Estados Unidos y China aceleran la disputa militar por el control del espacio.

Para ampliar el contexto, también puede leerse Superávit fiscal: por qué el déficit puede trasladarse al sector privado.

El prototipo que funciona hasta que llega a producción

El ejemplo difundido en la nota original describe una empresa que armó su plataforma de facturación con inteligencia artificial, sin una arquitectura detallada ni una especificación técnica previa. En la etapa de demostración, el sistema parecía exitoso. La interfaz respondía, las operaciones básicas se completaban y el equipo podía mostrar avances en tiempo récord.

El comportamiento cambió al pasar a producción. La plataforma comenzó a duplicar facturas, tuvo problemas de estabilidad con una cantidad reducida de usuarios y dejó expuestos datos de clientes. No se trata de errores cosméticos: una factura duplicada puede alterar la contabilidad, generar reclamos y complicar la relación con proveedores o compradores. Una caída puede frenar despachos, impedir la confirmación de servicios o demorar el cobro. Una filtración de información puede derivar en pérdidas económicas, sanciones y daño reputacional.

La experiencia muestra por qué una demostración no alcanza para validar un producto digital. Un prototipo responde a un escenario controlado y generalmente favorable. Un sistema real debe tolerar excepciones, picos de demanda, permisos diferenciados, errores humanos, cambios regulatorios y procesos que no fueron previstos por quien lo desarrolló.

La diferencia entre una función aislada y un sistema completo

Una instrucción para crear una pantalla de facturación puede producir una pantalla de facturación. El desafío aparece cuando esa pantalla debe conectarse con clientes, productos, impuestos, medios de pago, inventarios, cuentas corrientes y sistemas externos. Cada vínculo incorpora reglas que necesitan ser definidas antes de escribir código.

También deben establecerse condiciones aparentemente menores. ¿Qué ocurre si el usuario presiona dos veces el botón de emitir? ¿La operación se procesa una sola vez o genera dos comprobantes? ¿Qué pasa si la conexión se corta después de enviar la orden, pero antes de mostrar la confirmación? ¿Quién puede anular una factura? ¿Cómo se registra una modificación? ¿Qué información puede observar cada empleado?

La inteligencia artificial puede colaborar con varias de esas tareas, pero no decide por sí sola cuáles son las reglas comerciales correctas. Si recibe instrucciones incompletas, llenará los espacios con supuestos. Esos supuestos pueden ser razonables para una prueba rápida y completamente inadecuados para una operación diaria.

Por qué la especificación vuelve a ocupar el centro

Durante décadas, una parte importante del costo de desarrollar software estuvo asociada con escribir y mantener código. La escasez de programadores hacía que cada nueva función requiriera muchas horas de trabajo especializado. Las herramientas de inteligencia artificial reducen esa barrera y permiten automatizar tareas repetitivas, generar estructuras iniciales y proponer soluciones para problemas conocidos.

Cuando la producción de código se vuelve más abundante, el valor se desplaza hacia otras capacidades. Entre ellas aparecen la definición precisa del problema, la comprensión del negocio, la selección de una arquitectura adecuada y la posibilidad de verificar si el resultado cumple con lo que se necesitaba. También gana importancia la evaluación de riesgos: una aplicación barata de construir puede ser muy costosa de reparar si afecta operaciones críticas.

Una especificación no tiene que ser un documento interminable ni estar escrito en un lenguaje inaccesible. Debe explicar qué debe hacer el sistema, quién lo utilizará, qué información manejará, qué restricciones existen y cómo se comprobará que cada función funciona correctamente. Cuanto más delicado sea el proceso, mayor deberá ser el nivel de detalle.

En una operación logística, por ejemplo, una aplicación podría registrar turnos de camiones, asociar cargas con documentos, informar el estado de una entrega y notificar demoras. Antes de pedirle a una herramienta de inteligencia artificial que genere ese sistema, habría que definir los estados posibles, los permisos de cada usuario, la forma de resolver duplicaciones y el comportamiento frente a interrupciones de conectividad. Sin ese mapa, la velocidad inicial puede convertirse en retrabajo.

Facturación duplicada, accesos indebidos y otras fallas previsibles

Los problemas mencionados en el caso no son imprevisibles. La duplicación de facturas suele aparecer cuando un sistema no diferencia entre una solicitud nueva y el reintento de una operación ya enviada. Si la aplicación no utiliza controles de idempotencia, el mismo clic o la misma orden pueden producir varios registros.

Las caídas con pocos usuarios también pueden revelar una arquitectura insuficiente. Un prototipo puede ejecutar todas sus tareas en un único proceso, guardar información de manera poco eficiente o consultar una base de datos sin índices adecuados. Mientras lo utiliza una persona, el defecto permanece oculto. Cuando se conectan varios usuarios, las demoras se acumulan y los recursos disponibles se agotan.

La exposición de datos plantea una amenaza todavía más sensible. Una herramienta puede generar una pantalla que muestra información correctamente, pero dejar una ruta de acceso sin protección en el servidor. También puede incluir claves dentro del código, asignar permisos excesivos o permitir que una persona consulte registros que no necesita para cumplir su función.

Estos riesgos no desaparecen porque el código haya sido producido por un sistema avanzado. Al contrario, la facilidad de generación puede llevar a incorporar grandes cantidades de código sin que nadie comprenda con precisión cómo funciona. La revisión humana, las pruebas automatizadas, el análisis de seguridad y el control de accesos siguen siendo indispensables.

La inteligencia artificial acelera la construcción, no reemplaza el criterio

El uso responsable del vibe coding no exige rechazar la inteligencia artificial. Exige ubicarla en el lugar correcto dentro del proceso. Puede servir para explorar una idea, crear un prototipo, traducir una función a distintos lenguajes, preparar pruebas, documentar componentes o detectar errores. También puede ayudar a equipos pequeños a construir herramientas internas que antes no podían financiar.

El límite aparece cuando una primera versión se presenta como producto terminado sin atravesar controles técnicos. Una aplicación destinada a gestionar información sensible o una operación crítica necesita una revisión proporcional al riesgo. No es lo mismo generar una calculadora personal que administrar facturas, salarios, turnos de camiones o datos de clientes.

Una metodología razonable comienza con una descripción del problema y continúa con la identificación de usuarios, datos, integraciones y escenarios de error. Luego se puede utilizar inteligencia artificial para acelerar partes del desarrollo, pero cada resultado debe probarse contra criterios concretos. Las decisiones sobre seguridad, continuidad operativa y cumplimiento normativo no deberían quedar libradas a una respuesta automática.

Qué debería incluir un plano digital antes de escribir código

El equivalente de un plano en un proyecto de software es una combinación de alcance, reglas de negocio y decisiones de arquitectura. Allí conviene definir qué queda dentro y fuera del proyecto, qué información se almacena, cómo se relacionan los datos y qué acciones puede realizar cada perfil.

También es necesario describir los casos excepcionales. Un sistema maduro no solo especifica el camino ideal; contempla pagos rechazados, documentos repetidos, usuarios sin permisos, datos incompletos, servicios externos que no responden y operaciones que deben revertirse. Cada excepción que no se analiza antes puede convertirse en un incidente durante la operación.

La documentación además facilita la continuidad. Si el equipo que creó una aplicación deja de participar, otras personas necesitan entender sus componentes y dependencias. El código generado automáticamente puede ser útil, pero sin una explicación de su propósito y sus límites se vuelve difícil de mantener. La velocidad de creación no garantiza la capacidad de evolución.

El efecto sobre empresas que dependen de operaciones coordinadas

En sectores como el comercio exterior, los puertos y la logística, una falla digital rara vez queda confinada a una pantalla. Un dato incorrecto puede afectar la planificación de un retiro, el ingreso de un camión, la disponibilidad de una carga o la emisión de documentación. Por eso, quienes implementen herramientas generadas con inteligencia artificial deberían vincular cada función con una consecuencia operativa concreta.

Una plataforma que administra turnos, por ejemplo, debe evitar reservas duplicadas y conservar un historial confiable de cambios. Un sistema de seguimiento necesita distinguir entre una demora real y una falta temporal de actualización. Una aplicación de facturación debe mantener consistencia entre los comprobantes, los pagos y los registros contables. En todos los casos, la prioridad no es solamente que la interfaz responda, sino que la información sea correcta y recuperable.

Este enfoque se relaciona con la necesidad de fortalecer la gestión logística y la trazabilidad de las operaciones. También resulta útil consultar el contexto de la digitalización en el comercio exterior, donde las plataformas suelen intercambiar información entre empresas, organismos, transportistas y terminales.

Para exportadores e importadores, una falla de software puede generar costos indirectos aunque no exista una pérdida física de mercadería. La información incorrecta produce esperas, reprocesos, reclamos y decisiones tomadas con datos desactualizados. En cadenas con ventanas horarias ajustadas, una interrupción breve puede alterar la coordinación de múltiples actores.

La ventaja competitiva será saber qué construir

La expansión del vibe coding probablemente reduzca el tiempo necesario para crear aplicaciones sencillas y prototipos. Eso puede ampliar el acceso a herramientas digitales y permitir que más empresas experimenten con soluciones propias. Pero también puede aumentar la cantidad de sistemas frágiles si la facilidad de generación se confunde con calidad.

El criterio técnico no pierde valor; cambia de lugar. Será menos importante escribir manualmente cada línea y más importante formular buenas preguntas, ordenar prioridades, identificar dependencias y revisar las respuestas de la máquina. La capacidad de reconocer una solución incompleta puede ser tan decisiva como la capacidad de producir una solución inicial.

La comparación con la construcción resulta directa: tener materiales y mano de obra disponible no elimina la necesidad de calcular cargas, prever instalaciones y respetar condiciones de seguridad. En el software, la inteligencia artificial puede poner ladrillos a gran velocidad, pero la empresa todavía necesita un plano que indique qué debe levantarse, cómo se probará y qué ocurrirá cuando la realidad se aparte del escenario ideal.

Para los equipos que evalúan estas herramientas, la decisión no debería ser si usar o no inteligencia artificial, sino en qué etapas utilizarla y qué controles mantener. Un prototipo rápido puede ser una ventaja. Convertirlo en una plataforma confiable requiere especificación, pruebas, seguridad, monitoreo y responsables capaces de entender el funcionamiento completo.