Qué ocurre cuando desarrollar software deja de ser caro

Durante décadas, escribir código fue la parte cara de un proyecto. Cada pantalla, cada integración y cada informe costaba horas de alguien que sabía programar. Por eso las empresas se lo pensaban dos veces antes de construir algo propio, y por eso las herramientas estándar ganaban casi siempre.

Eso está cambiando deprisa. Los agentes de programación ya escriben funciones, pantallas, tests y migraciones a una velocidad que hace pocos años no era realista. Yo trabajo así cada día: la IA amplía lo que una persona puede construir.

Pero que el código sea barato no significa que un sistema sea barato. Significa que el coste se mueve de sitio.

Lo que se abarata y lo que no

Se abarata todo lo que consiste en producir: escribir una función a partir de una especificación clara, maquetar una pantalla, generar tests, repetir un patrón en cien sitios, traducir un esquema de datos a otro.

No se abarata, o no al mismo ritmo, todo lo que consiste en decidir:

Entender cómo trabaja de verdad una empresa y dónde se atasca.
Elegir qué construir y, sobre todo, qué no construir.
Diseñar el modelo de datos del que dependerá todo lo demás.
Integrar lo nuevo con lo que ya funciona.
Comprobar que lo que el sistema dice es cierto.
Mantenerlo en marcha cuando la empresa cambie.

Cuando una parte del trabajo se vuelve casi gratuita, la otra pasa a ser el cuello de botella.

Dónde está ahora el cuello de botella

Decidir qué construir

Si construir cuesta poco, la tentación es construirlo todo. Pero cada pieza que se añade hay que integrarla, entenderla y mantenerla. La decisión más valiosa de un proyecto sigue siendo la de no construir algo.

La arquitectura

La IA amplifica el diseño, sea bueno o malo. Un modelo de datos equivocado se replica ahora más deprisa que nunca, en más pantallas, más informes y más integraciones. En Rocio.com lo primero fue normalizar un archivo que vivía en 320.093 filas de metadatos en texto. Construir encima sin hacerlo habría heredado el problema en cada funcionalidad nueva.

La integración

Los sistemas no suelen fallar dentro de una pieza, sino en las costuras: entre el proceso y los datos, entre los datos y la herramienta, entre la herramienta y la IA. Producir piezas más rápido no arregla las costuras. Las multiplica.

La validación

Generar un dashboard lleva minutos. Saber si sus cifras son ciertas, no. En AtalayaIQ los hallazgos se concilian de forma independiente con SQL escrito a mano, y cada día se compara con el anterior del mismo tipo y al mismo retraso de registro. Sin eso, el sistema habría anunciado caídas que no existían, con total seguridad.

El mantenimiento

Un sistema en producción sigue vivo: cambian los proveedores, los modelos, los datos y la propia empresa. Por eso importa diseñar para el cambio. En Rocio.com el índice de IA es desechable y se reconstruye desde la base de datos: cambiar de proveedor no toca el contenido.

Qué significa esto para las profesiones

No hace falta hacer predicciones absolutas. Programar no va a desaparecer, igual que no desapareció cuando llegaron los compiladores, los frameworks o las librerías de código abierto. Lo que cambia es el peso de cada tarea dentro del trabajo.

Probablemente se escribirá más código que nunca, y por tanto habrá más sistemas que diseñar, integrar, verificar y mantener. El valor se desplaza hacia quien sabe qué construir, cómo encaja y cómo comprobar que funciona.

El perfil que gana peso: el Digital Architect

Un Digital Architect diseña y construye sistemas digitales completos: entiende el proceso de la empresa, ordena sus datos, construye las herramientas e integra la IA donde aporta. Y responde del conjunto, no de una pieza.

No es un perfil nuevo en esencia. Lo nuevo es que, con agentes de programación, una misma persona puede cubrir el diseño y la construcción de sistemas que antes necesitaban un equipo, siempre que el criterio esté claro. Menos traspasos entre perfiles significa menos contexto perdido por el camino.

Qué cambia al trabajar así

En la práctica, mi forma de trabajar parte del problema y no del código. Cómo trabajo se resume en cuatro entradas —el problema, los datos, las restricciones y el objetivo— y una salida: el sistema. La IA acelera la ejecución; las decisiones, la verificación y la responsabilidad no se delegan.

Si quieres ver cómo se traduce esto en sistemas reales, los casos están documentados sin cifras inventadas.

Cuando construir es rápido, el cuello de botella es el criterio.