Aspectos clave
- Vibe coding y desarrollo asistido por IA generan código funcional rápidamente, e igual de rápido generan errores arquitectónicos. La velocidad es real. La consistencia no lo es.
- Un prompt contiene solo lo que entiende quien lo escribió. La IA potencia el trabajo de alguien que domina el sector y multiplica los errores de quien no lo hace.
- La mayoría del software empresarial son tuberías que toda aplicación necesita: cuentas, roles, permisos, auditoría, validación, importación, exportación, trabajos en segundo plano, una API. Generar eso desde prompts es donde se acumula la deuda técnica.
- Una plataforma de datos como AtroCore entrega esas tuberías como configuración, dejando que el código generado por IA se responsabilice solo de la parte específica de tu negocio.
- Starbucks está reemplazando software que sus propios ingenieros ya estaban reescribiendo. Esa prueba aplica a cualquier tamaño de empresa. La capacidad de construir una base desde cero no es universal.
Las empresas están construyendo software empresarial personalizado de nuevo
Durante décadas, la pregunta de construir versus comprar tenía una respuesta consensuada. Comprabas software comercial y ajustabas el proceso para que se adaptara, porque construir era más lento y tenía un costo total de propiedad que nadie quería defender.
Starbucks es la señal más clara de que el cálculo cambió. La empresa gasta aproximadamente $400 millones al año en software, y el director de tecnología Anand Varadarajan dijo en un foro interno que había oportunidades claras para reducir eso, según reportajes de una presentación interna filtrada. Los ingenieros están usando codificación asistida por IA para construir reemplazos de un sistema de monitoreo de inventario de Microsoft y una herramienta de gestión de mantenimiento de IBM.
El detalle que vale la pena copiar es qué software eligió Starbucks: herramientas que sus ingenieros ya estaban modificando fuertemente. Esa prueba no tiene nada que ver con el tamaño de la empresa. Un fabricante de materiales de construcción cuyo precio depende de cláusulas de índice enterradas en acuerdos de proveedores se enfrenta a la misma pregunta. Los productos de gestión de contratos manejan la cláusula. Vincularla a las plantas y grupos de materiales que ya están en los datos maestros del fabricante es donde los que hemos evaluado se detienen.
El comportamiento se está propagando. La encuesta de Retool de 2026 de más de 800 profesionales encontró que el 35% de las empresas ya habían reemplazado al menos una herramienta SaaS con algo construido internamente, y el 78% esperaba construir más.
La historia corta de dos formas. El software interno traslada costos de suscripciones a mantenimiento y personal en lugar de eliminarlos, y el reemplazo del punto de venta para Oracle Simphony ha estado en progreso durante varios años, anterior a las herramientas de IA. La IA comprime algo de este trabajo y no ha comprimido eso. Starbucks también absorbe lo que la mayoría de las empresas no puede: una organización de ingeniería lo suficientemente grande para construir una base y mantenerla durante una década. Un fabricante de 200 personas enfrenta la misma decisión sin esa capacidad. Para ellos, la pregunta útil es en qué construir, y una plataforma de datos que no tuvieron que escribir es la respuesta más económica disponible. Vibe coding nombra el final de esto, donde alguien genera una aplicación mediante prompts y envía lo que regresa.
Lo que sigue aplica al caso más amplio también: desarrolladores profesionales usando asistencia de IA en código que revisan. Construimos software empresarial personalizado con fabricantes y distribuidores, así que los argumentos provienen de proyectos, no de una pizarra.
Qué escribe bien la IA y qué escribe mal
Veracode ha ejecutado la misma prueba contra modelos de IA desde 2023: 80 tareas de codificación, cuatro lenguajes, cuatro clases de vulnerabilidades, sin instrucciones de seguridad en el prompt. En su actualización de primavera de 2026, la corrección sintáctica pasó el 95% mientras la tasa de aprobación de seguridad se mantuvo cerca del 55%. Java obtuvo la puntuación más baja del 29%.
La razón detrás de esos números es más útil que los números. Los modelos son fuertes en patrones locales y débiles para rastrear datos entre archivos. SQL parametrizado es un patrón que el modelo ha visto marcado mil veces. Sanitizar entrada que pasa por cuatro funciones en una plantilla es una pregunta de flujo de datos, y el flujo de datos necesita contexto que el modelo no tiene.
Para un equipo profesional, los fallos interesantes son los que sobreviven la revisión. Un revisor detecta una verificación nula faltante o un nombre de variable incorrecto. La revisión es mucho más débil en cualquier cosa visible solo entre archivos y entre semanas, porque cada cambio se veía razonable solo. La lógica no documentada también pasa, porque el código generado que funciona es difícil de argumentar en una solicitud de extracción. Lo que se acumula es deuda de comprensión: código que se ejecuta correctamente y nadie en el equipo puede explicar ahora.
La mantenibilidad muestra la misma debilidad. GitClear analizó 211 millones de líneas de código modificadas de 2020 a 2024 y, como reportó LeadDev, encontró bloques duplicados de cinco o más líneas apareciendo ocho veces más frecuentemente en 2024. Las líneas copiadas superaron a las líneas movidas por primera vez en el conjunto de datos. Las líneas movidas son la huella digital de la refactorización, el trabajo de consolidar algo en un lugar reutilizable.
En la encuesta de Stack Overflow de 2025, la principal frustración, nombrada por el 66% de los encuestados, fue la salida de IA casi correcta sin ser correcta. La misma encuesta dimensiona las prácticas: el 84% usa o planea usar herramientas de IA y el 51% de los desarrolladores profesionales las usa diariamente, mientras que solo alrededor del 15% llama vibe coding parte de su trabajo profesional. La codificación asistida por IA es el caso predeterminado. Enviar salida sin leer sigue siendo raro.
Un prompt contiene solo lo que entiende su autor
La IA responde el prompt que le dieron, así que el techo del código generado es la comprensión del dominio de quien escribió el prompt. En problemas de datos B2B, esa comprensión rara vez se encuentra con el desarrollador. Un gerente de compras que ha negociado acuerdos de proveedores durante quince años sabe qué tiene que sobrevivir una cláusula de precio indexado. Un desarrollador generando prompts sin ese conocimiento obtiene código que satisface el ejemplo y nada más allá, y la brecha permanece invisible hasta que llega un contrato real.
Para equipos profesionales, esto mueve el cuello de botella. La velocidad de escritura dejó de ser la restricción hace un tiempo, y la sintaxis fue con ella. Lo que limita la salida ahora es cuán bien extrajo alguien el conocimiento del dominio primero.
Una suposición relacionada merece ser nombrada. Las empresas de software que han pasado diez años en el mismo producto rara vez han estado desperdiciando esos años. Ese tiempo contiene los casos extremos que nadie anticipó, el modelo de permisos que sobrevivió una auditoría, la importación que maneja la hoja de cálculo que un proveedor realmente envía en lugar de la que la especificación describía. Nada de eso llega a un prompt, porque nadie lo escribe hasta que se rompe una vez en producción.
Un desarrollador experimentado con buenas herramientas de IA puede reproducir la forma de un producto maduro en semanas. Reproducir lo que aprendió toma aproximadamente tanto tiempo como tomó la primera vez. Vendemos software, así que evalúa eso en consecuencia, luego pruébalo: toma un producto que conoces bien y cuenta cuántos de sus comportamientos podrías haber especificado por anticipado.
La deuda técnica está en las tuberías
Imagina una aplicación de gestión de proveedores. Antes de que administre un solo proveedor, necesita una larga lista de cosas que no tienen nada que ver con proveedores.
Cuentas, grupos y roles, más permisos a nivel de campo para que compras vea términos comerciales y el gerente de planta no. Una pista de auditoría que registra quién cambió qué campo y cuándo. Validación en cada campo. Búsqueda, filtros guardados y edición masiva. Importación desde la hoja de cálculo que un proveedor envió, exportación al ERP. Trabajos en segundo plano que sobreviven una actualización de 40,000 filas. Una API REST para la vista móvil que alguien solicitará más tarde.
Nada de eso es tu problema empresarial. Todo eso tiene que funcionar.
Genera un agente para eso, y obtienes verificación de rol implementada de una forma en el módulo de proveedores y de otra forma en el módulo de contratos tres semanas después. Dos mecanismos de permisos que discrepan en casos extremos. Componentes acoplados excesivamente, porque el modelo optimizó cada prompt localmente y nunca vio el todo. Historial de cambios en cuatro entidades y no en la quinta. Cada pieza funciona cuando se demuestra. Juntas son la factura de mantenimiento, y llega esté o no alguien llamando al proceso vibe coding.
En las implementaciones que hemos ejecutado, la división entre tuberías y lógica específica del negocio es desproporcionada de una forma consistente.
La parte específica del negocio de un cliente raramente es más que una décima parte de lo que se construye. El resto es lo mismo en cada aplicación empresarial jamás escrita, y es exactamente la parte que la IA escribe inconsistentemente.
Esa proporción decide la economía. Vibe coding es barato donde el trabajo es pequeño y caro donde el trabajo se repite.
Qué te entrega una plataforma de datos antes del primer prompt
La plataforma de datos AtroCore es software de código abierto bajo GPLv3, en desarrollo activo desde 2018, construida para gestión de datos maestros e integración de sistemas. Sus casos de uso documentados incluyen servir como plataforma de código abierto low-code para software empresarial personalizado.
Disponible a través de configuración, antes de que alguien escriba una línea de código:
- Modelo de datos.
Entidades y relaciones configurables, más de 20 tipos de campo con validación automática, diseños configurables, jerarquías multinivel con herencia, clasificación y taxonomías. - Acceso e historial.
Usuarios y grupos ilimitados, gestión de roles, control de acceso a nivel de campo, consultas de acceso configurables, registros de acciones, historial de cambios, comentarios, propiedad de registros, paneles de control, filtros almacenables. - Movimiento de datos.
Alimentaciones de importación y exportación, solicitudes de API configurables y consultas de bases de datos, transformaciones aplicadas antes de importación o exportación, XLSX, CSV, JSON y XML, conexiones sobre REST, GraphQL, SOAP y OData. - Procesamiento.
Un gerenciador de trabajos donde estableces el contador de trabajadores contra la capacidad del servidor, trabajos programados, acciones basadas en eventos, flujos de trabajo configurables, y verificaciones de calidad de datos. Botones de acción personalizada colocados en la interfaz por configuración, cada uno ejecutándose contra un solo registro o una selección completa. - Salida.
Plantillas de PDF, documentos de Office y correo electrónico, más una API REST que cubre todo, incluyendo tu propia configuración.
Lo que queda para vibe coding es la parte que es realmente tuya. La fórmula de ajuste de precio indexado. La lógica de comparación de ofertas. El conector a ese módulo ERP que nadie ha integrado antes.
Ese código tiene lugares definidos para vivir. AtroCore se extiende a través de módulos que escribes tú mismo, y la lógica más ligera cabe en acciones configurables, scripts y condiciones adjuntos a entidades existentes. El disparador es generalmente un botón configurado, lo que significa que una operación masiva sobre 300 registros seleccionados no necesita pantalla, ruta, ni lógica de permisos propia.
Los hallazgos de Veracode aún aplican a lo que el modelo escribe allí. Lo que cambia es el radio de explosión. Una fórmula de precio dentro de un sistema que ya maneja autenticación, permisos a nivel de campo, y validación de entrada tiene menos formas de lastimarte que una en un endpoint construido a mano que también inventó su propio manejo de sesiones.
El contrato de API hace el trabajo de barandilla de seguridad
Un detalle en la arquitectura de AtroCore importa más para trabajo asistido por IA de lo que parece. La capa HTTP sigue PSR-7 y PSR-15 estrictamente. Los controladores se registran a través de atributos PHP y se documentan automáticamente como OpenAPI 3.0. Según la documentación del proyecto, una ruta que no está completamente documentada no se registra, y cada solicitud y respuesta se validan contra el esquema en tiempo de ejecución.
Considera lo que eso hace con un agente de codificación. Escribe un cliente, inventa un nombre de campo plausible, y la solicitud falla inmediatamente con un error de esquema. Misma sesión, contexto aún abierto, la corrección cuesta treinta segundos. Los errores capturados dentro de la sesión nunca se convierten en deuda técnica. Sin un contrato en el límite, ese campo inventado no escribe nada silenciosamente y resurge cuatro meses después como una investigación de calidad de datos. La retroalimentación rápida e implacable es lo que hace que el código generado por IA sea barato de corregir, y la plataforma lo suministra sin que nadie lo construya.
Ese esquema también es lo que le das al agente. Porque la documentación se genera desde los controladores en lugar de mantenerse junto a ellos, la descripción OpenAPI de tus propias entidades configuradas es actual por construcción, lo que es rara vez cierto de una especificación mantenida a mano. Dale a un modelo ese esquema más tus convenciones de denominación y acceso, y escribe contra el contrato real. Extiende el modelo de datos por configuración más tarde, y el esquema se mueve con él, así el contexto del agente permanece preciso sin que nadie actualice un documento.
La investigación apunta a la base, no a la herramienta
El informe DORA 2025 de Google encontró que la IA actúa como un amplificador, magnificando fortalezas existentes y disfunción existente, con los mayores rendimientos viniendo del sistema subyacente en lugar de las herramientas. El modelo inaugural de capacidades de IA de Google Cloud es más específico: la influencia positiva de la IA en el desempeño organizacional se amplifica donde existen plataformas internas de calidad. Una segunda capacidad cubre ecosistemas de datos saludables: datos internos que son de alta calidad, accesibles y unificados. Una plataforma de datos configurable bajo tu software empresarial personalizado aborda ambos.
Las afirmaciones de velocidad siguen moviéndose. La prueba de principios de 2025 de METR encontró que desarrolladores experimentados tomaban 19% más tiempo en repositorios maduros cuando se permitían herramientas de IA, mientras que su actualización de febrero de 2026 apunta hacia una aceleración y señala efectos de selección lo suficientemente fuertes para justificar un rediseño. Trata números de productividad como no resueltos. Los hallazgos de mantenibilidad no se han movido desde 2023.
Un ejemplo de contrato de proveedor de nuestros proyectos
Nuestros clientes se presentan con una versión reconocible del mismo problema. Un fabricante mantiene acuerdos de proveedores como PDFs en una unidad compartida, términos clave en una hoja de cálculo, fechas de renovación en el calendario de un comprador. Nadie puede decir qué acuerdos contienen una cláusula de ajuste de precio vinculada a un índice de materias primas, porque esa cláusula es una oración dentro de un documento.
Existen herramientas estándar de gestión de contratos, y asumen un flujo de trabajo del departamento legal que termina en la firma. Esta empresa necesitaba contratos vinculados a grupos de materiales, plantas, y registros de proveedores que ya existían en sus datos maestros, con obligaciones que siguen produciendo trabajo durante años después de la firma.
En la plataforma de datos, contrato, cláusula, renovación y obligación se convirtieron en entidades configuradas relacionadas con los registros de proveedor y material que ya existían. El acceso a nivel de campo separó términos comerciales de obligaciones de entrega. El historial de cambios vino con la plataforma, lo que importó la primera vez que dos personas no estuvieron de acuerdo sobre un descuento. Un trabajo programado marcó ventanas de renovación.
El código personalizado cubrió dos cosas: el cálculo del ajuste de precio basado en índice, y un conector que alimenta la verificación de factura en su ERP. Ambos fueron lo suficientemente estrechos para especificar con precisión y probar adecuadamente. La plataforma restringe qué código generado puede tocar, y vibe coding cubre lo que nunca fue a saber sobre un negocio específico.
Dónde trazar la línea entre configuración y vibe coding
La mayoría de las mejores prácticas de vibe coding se reducen a dos preguntas. Qué se configura y qué se genera. La IA tiene un papel en ambos lados de esa línea, y los dos papeles no son el mismo trabajo.
Configura cualquier cosa que sea un registro con campos, relaciones, permisos, y un ciclo de vida. Eso cubre más de lo que la mayoría de los equipos esperan, incluyendo flujos de aprobación, escalaciones, y verificaciones programadas. Los equipos nuevos en esto consistentemente bajo-configuran, luego escriben código para hacer lo que una acción configurada ya hace.
La IA ayuda aquí de una forma que se pasa por alto. Pregúntale cómo modelar una renovación de contrato con herencia, o qué tipo de campo se ajusta a un rango de tolerancia, y un modelo capaz te guía a través de la configuración. Señálala a la API REST, y puede aplicar esa configuración ella misma. Sugerir y aplicar configuración es un trabajo diferente de construir el sistema, y lleva un mejor retorno, porque una configuración incorrecta se muestra en la interfaz en minutos mientras una arquitectura incorrecta se muestra en el mes seis.
Genera las transformaciones y cálculos. Una fórmula, un mapeo, un analizador, una consulta de informe. Superficie pequeña, salida esperada clara, fácil de probar.
La verificación tiene una forma concreta aquí. Configura las reglas de validación y verificaciones de calidad de datos antes de generar cualquier cosa, luego ejecuta la lógica generada contra registros cuyas respuestas ya conoces, incluyendo los incómodos como el contrato sin fecha de fin. La plataforma rechaza lo que rompe sus propias reglas, así que el cálculo falla audiblemente en el registro que de otro modo habría fallado silenciosamente en producción. Mantén ese conjunto de registros como la prueba de regresión para el próximo modelo que pruebes.
Una categoría pertenece a ninguno. Donde una respuesta incorrecta es cara y silenciosa, escríbela tú mismo. Dinero, impuestos, documentación de seguridad, cualquier cosa que un regulador lea. La IA puede producir ese código perfectamente bien. La razón para escribirlo a mano es que necesitas haberlo entendido primero.
Si puedes describirlo como datos más un cambio de estado, configúralo. Si cometer un error cuesta más que escribirlo lentamente, escríbelo lentamente.
Qué te cuesta este enfoque
Adoptas las convenciones de otra persona sobre cómo funcionan los registros, relaciones, permisos y procesos. Donde tu modelo mental difiere, el tiempo se gasta luchando con la plataforma en lugar de usarla. Lee la documentación del desarrollador antes de comprometerte.
AtroCore se ejecuta en PHP y necesita un servidor Linux con acceso raíz más PostgreSQL o MySQL. El hosting compartido ordinario no lo ejecutará. En nuestros proyectos, una vez que alguien conoce el sistema, un primer modelo de datos funcional de cuatro o cinco entidades con relaciones, diseños, roles e historial toma días. Alcanzar esa familiaridad toma más tiempo, por eso el retorno llega en el mes tres.
El ajuste está acotado. Una plataforma organizada alrededor de registros, relaciones y procesos empresariales es una base pobre para control en tiempo real o procesamiento de señales. Comienza desde un marco para esos. La sobre-configuración es su propia trampa: veinte entidades donde cinco harían es deuda técnica también, más silenciosa que código duplicado y más difícil de deshacer una vez que datos reales viven en ella.
Cómo juzgar una base antes de empezar a generar prompts
Dos alternativas compiten con una plataforma de datos, y cada una falla una prueba diferente. Un marco desnudo te deja siendo dueño de cada pieza de la tubería. Un constructor low-code resuelve eso y cobra en una moneda diferente: el vendedor es dueño de tu modelo de datos, hosting y runtime, y el precio sigue el conteo de usuarios. Ese intercambio funciona para un panel interno, mal para software que contiene contratos de proveedores por la próxima década.
Sostén cualquier candidato contra esta lista, incluyendo ambas alternativas arriba.
- Una entidad, un campo y una relación, añadidos sin un despliegue.
- Un solo mecanismo de permisos cubriendo todo el sistema, en lugar de varios que se desvíen.
- Una API generada del código y validada en tiempo de ejecución, en lugar de documentada a mano y incorrecta dentro de un mes.
- Un historial de cambios que nadie en tu equipo tuvo que construir.
- Trabajo en segundo plano que se ejecuta sin una nueva entrada cron por trabajo.
- Una salida clara: tus datos, tu base de datos, y tu derecho a mantener ejecutando el sistema si el vendedor desaparece.
La mayoría de las bases fallan varias de estas. Saber cuáles, antes del primer prompt, es la diferencia entre deuda técnica que elegiste y deuda técnica que heredaste.