Ocho honores y ocho deshonras en la ingeniería de software en la era de la IA: de ahorrar código a ampliar el espacio de operación de la IA

2026-06-03

• Enorgullécete de lo que el sistema necesita; avergüénzate de lo que limita el equipo.
• Enorgullécete de la autonomía local; avergüénzate de las dependencias globales.
• Enorgullécete de la lógica explícita; avergüénzate de las reglas implícitas.
• Enorgullécete de la implementación especializada; avergüénzate de la compatibilidad genérica.
• Enorgullécete de la validación en circuito cerrado; avergüénzate de dejarlo en manos humanas.
• Enorgullécete de la delegación controlada; avergüénzate de tirar al niño con el agua sucia.
• Enorgullécete de la iteración paralela; avergüénzate de la progresión lineal.
• Enorgullécete de la reestructuración decisiva; avergüénzate del parche temporal.

En la era de la IA, lo que realmente cambia en la ingeniería de software no es «quién escribe el código», sino que la estructura de costes de la ingeniería de software ha sufrido una transformación fundamental. Antes, el coste de codificación era alto, el coste de colaboración entre equipos era alto, y el coste de contratación y transferencia de conocimiento era alto. Por ello, muchas prácticas de ingeniería giraban en torno a «escribir menos código, cambiar menos de tecnología, evitar bifurcaciones y reducir la comunicación». Así, la homogeneidad full‑stack, una base de datos única, marcos genéricos, capacidades de plataforma central, cambios mínimos y la supervisión humana directa eran, en su momento, opciones racionales.

Pero tras la irrupción de la IA, la antigua estructura de costes empezó a aflojarse. El coste de generar código baja, el coste de entender distintos lenguajes baja, el coste de scripts de un solo uso, código de pegamento, implementaciones locales y herramientas especializadas también baja. Al mismo tiempo, lo que realmente se vuelve caro es: comprensión del contexto, verificación del sistema, observación en ejecución, límites de responsabilidad, autoridad para ejecutar automatizaciones y la capacidad de que el software evolucione de forma sostenida. Por lo tanto, la ingeniería de software en la era de la IA no debe seguir centrándose en «ahorrar código», sino en «ampliar el espacio de operación de la IA».

Este es precisamente el punto de partida de los «Ocho honores y ocho deshonras en la ingeniería de software en la era de la IA».

1. Enorgullécete de lo que el sistema necesita; avergüénzate de lo que limita el equipo

En la ingeniería tradicional, muchas decisiones técnicas no las determinaba el sistema en sí, sino lo que el equipo ya sabía hacer. El equipo frontend domina JavaScript, así que el backend también usa JavaScript; el equipo solo sabe Postgres, así que meten en la misma base de datos cachés, análisis, datos fríos, datos de hechos; el equipo no conoce Rust, así que descartan un lenguaje más adecuado para un backend de alto rendimiento.

Esta práctica tenía su lógica en el pasado, porque el coste humano era demasiado alto y la colaboración entre stacks tecnológicos era muy difícil. Pero la IA reduce el coste de comprender distintos lenguajes, distintos marcos y distintas herramientas. Ahora, los sistemas software deben volver al principio de «usar lo que el sistema necesita». El frontend puede usar TypeScript, el backend Rust, el análisis de datos Python, los datos calientes Redis, los datos fríos Parquet, los hechos transaccionales Postgres. El stack tecnológico ya no tiene que someterse al inventario del equipo, sino a las responsabilidades del sistema.

2. Enorgullécete de la autonomía local; avergüénzate de las dependencias globales

Aquí, «autonomía local» no se refiere al encapsulamiento de módulos tradicional ni al simple acoplamiento bajo y cohesión alta. Incluso los módulos tradicionales bien encapsulados suelen depender de un sistema grande y no pueden existir de forma independiente. Lo más importante en la era de la IA es la autonomía local a nivel de escenario de negocio: múltiples apps independientes y autónomas.

Antes nos gustaba construir plataformas centralizadas (中台), unificando capacidades similares de varios negocios en un sistema común, intentando reducir repeticiones y unificar criterios. Pero esto creaba a menudo nuevos puntos únicos de fallo: varios sistemas de negocio que podían haber evolucionado por separado quedaban enganchados por una capacidad central. Un cambio en un lugar afectaba a todo; un fallo en un punto paralizaba múltiples líneas de negocio; un cambio en una regla obligaba a todos los negocios a adaptarse juntos.

En la era de la IA, el coste de crear y mantener múltiples apps independientes ha bajado. En lugar de compartir una plataforma central pesada entre varios escenarios de negocio, es mejor que cada uno sea autónomo, evolucione por sí mismo y asuma sus propios límites. El valor de la autonomía local es permitir que la IA actúe de forma independiente en contextos pequeños, con radios de afectación reducidos y relaciones de dependencia débiles.

3. Enorgullécete de la lógica explícita; avergüénzate de las reglas implícitas

Lógica explícita no significa que el código tenga que ser simple, sino que el contexto de la lógica debe estar a la vista. Lo que realmente se critica no son los archivos de configuración, los decoradores, las funciones callback, los ciclos de vida, la inyección de dependencias u otras técnicas en sí mismas, sino el hecho de que crean reglas implícitas que escapan al lenguaje común del dominio público.

Muchos sistemas, para escribir menos código, esconden reglas en marcos de trabajo, dialectos, jergas internas, reglas no escritas, inyecciones dinámicas, hooks de ciclo de vida y términos poco evidentes. Los humanos expertos pueden conocer esas reglas por experiencia, pero la IA se encuentra con una barrera de información: ve el código, pero no ve el contexto real que determina el comportamiento.

En el pasado, «convención sobre configuración» funcionaba cuando la convención era lo suficientemente universal como para incluso cambiar la forma de pensar de las personas. Pero si una convención es solo una jerga interna del equipo, un dialecto local de un marco, o una regla heredada del pasado, entonces no ahorra código, sino que crea una caja negra de comprensión. En la era de la IA, el coste de la configuración explícita, las decisiones explícitas y los flujos explícitos ha bajado. Reunir la información en un solo lugar, visible directamente, suele ser más valioso que dispersar la lógica en múltiples implementaciones inyectables que se cargan dinámicamente.

4. Enorgullécete de la implementación especializada; avergüénzate de la compatibilidad genérica

El software debería servir a problemas concretos. Pero en el pasado, para escribir menos código, evitar bifurcaciones y mantener menos caminos, a menudo absorbíamos diferentes requisitos, entradas y escenarios de negocio en una capa de compatibilidad genérica. El resultado era una aparente unificación, pero en realidad los problemas se distorsionaban.

El mayor peligro de una capa de compatibilidad genérica es que exige que todos los problemas concretos se deformen primero para que encajen en ella. Así, el negocio específico pierde su forma original, las capacidades especializadas se debilitan, y el sistema empieza a girar en torno a la capa de abstracción, no en torno al problema real.

En la era de la IA, el coste de escribir código de un solo uso, código de pegamento, scripts pequeños e implementaciones especializadas se reduce drásticamente. Ya no tenemos que meter una tarea específica en un marco genérico solo para ahorrar un poco de código. Muchas veces, una implementación directa orientada a la tarea actual es más clara, más barata y más adecuada para que opere la IA que una capa de abstracción que debe ser compatible con todo tipo de posibilidades.

5. Enorgullécete de la validación en circuito cerrado; avergüénzate de dejarlo en manos humanas

La validación en circuito cerrado no debería limitarse a CI/CD. El CI tradicional ya puede hacer compilación, pruebas y comprobaciones de publicación, pero eso no es un circuito cerrado completo en la era de la IA. Lo que la IA realmente necesita son «sensores»: debe tener ojos para ver el estado en producción, sentir los cambios del sistema, y poder juzgar los resultados de sus propias acciones basándose en indicadores de observabilidad.

Si la IA solo puede ejecutar pruebas antes de enviar el código, pero no puede ver los indicadores en línea después del despliegue —comportamiento del usuario, cambios de latencia, tasas de error, consumo de recursos, embudos de negocio, alertas de anomalías—, entonces sigue siendo ciega. Solo puede esperar a que un humano le diga qué está roto, y sigue dependiendo de la supervisión humana directa.

Por lo tanto, el núcleo de la validación en circuito cerrado no es añadir más y más reglas de verificación, sino hacer que el sistema pueda observar más dimensiones de información. La IA no solo debe saber si las pruebas pasan, sino también si el sistema está sano después de salir a producción. Los humanos definen la corrección y los límites de riesgo; las máquinas se encargan de la observación continua, la validación continua y la retroalimentación continua.

6. Enorgullécete de la delegación controlada; avergüénzate de tirar al niño con el agua sucia

Muchos equipos temen que la IA cause estragos, así que solo la dejan escribir sugerencias, documentación o fragmentos de código, sin permitirle operar realmente el sistema. Pero esto no escala. Si la IA nunca tiene poder de ejecución, siempre será una asesora, no un sujeto activo de la automatización de la ingeniería.

El enfoque correcto no es rechazar que la IA opere sistemas reales, sino asumir primero que la IA puede tocar todo: código, datos, despliegues, recursos en la nube, configuración, monitorización, rollbacks. Luego se añaden límites de permisos, auditoría, dry-run, sandboxes, umbrales de aprobación, mecanismos de rollback y aislamiento de riesgos.

El punto clave de la delegación controlada es dar a la IA un poder de ejecución real, pero asegurando que cada acción esté dentro de un alcance controlable. Tirar al niño con el agua sucia significa que los humanos siguen copiando comandos manualmente, haciendo clic en consolas y solucionando problemas a mano, sin que la automatización de la ingeniería pueda realmente amplificarse.

7. Enorgullécete de la iteración paralela; avergüénzate de la progresión lineal

La evolución del software en la era de la IA no debería entenderse como un proyecto de ingeniería lineal y unipersonal, sino como el proceso de resolución de un optimizador o solver. Frente a un mismo problema, la IA puede proponer múltiples candidatos simultáneamente: una reparación local, una reestructuración de un módulo, un reemplazo de biblioteca, una reescritura de una ruta, una optimización de rendimiento.

La ingeniería tradicional, limitada por el factor humano, solo podía intentar un camino a la vez. Si fallaba, había que volver atrás y probar el siguiente. La IA cambia esto. Podemos generar, desplegar, validar y comparar en paralelo, haciendo que la evolución del software pase de ser lineal a una búsqueda multi‑ruta.

Por supuesto, la evaluación automática no siempre es fiable. La calidad del software suele ser no diferenciable, no atribuible y no evaluable al instante. Pero el valor de la iteración paralela no es que la máquina encuentre automáticamente la solución óptima absoluta, sino que amplía el espacio de exploración, haciendo que más rutas candidatas sean asumibles, comparables y verificables.

8. Enorgullécete de la reestructuración decisiva; avergüénzate del parche temporal

Antes, muchas normas de ingeniería exigían cambios mínimos, porque el coste humano de codificar era alto, el coste de reestructurar era alto y el coste de validación era alto. Los cambios mínimos eran una forma de reducir el riesgo. Pero en la era de la IA, si seguimos exigiendo que la IA haga siempre el cambio más pequeño, la reduciremos a una máquina de parches.

Muchos sistemas tienen problemas que no están en una línea de código, sino en una estructura que ha caído en un punto muerto: el harness se vuelve cada vez más pesado, la validación más rígida, el coste de reestructurar más alto, y cualquier cambio un poco mayor es rechazado por el proceso. El sistema parece seguro en la superficie, pero en realidad ya no es iterable. La mejora del software fracasa, y solo queda una muerte lenta o una reescritura total cuando el equipo lo decide.

En la era de la IA, el coste de codificar ha bajado. Las reestructuraciones que antes requerían un gran esfuerzo humano y no eran rentables, vuelven a ser posibles. No debemos encerrar a la IA en parches mínimos; debemos permitirle, bajo la protección de la validación en circuito cerrado, realizar rupturas estructurales. Replantear los límites cuando sea necesario, eliminar caminos antiguos cuando sea necesario, y reestructurar cuando sea necesario. El parche no es vergonzoso en sí mismo, pero seguir parcheando cuando el sistema ya ha entrado en una zona muerta es un parche de conveniencia.

Conclusión: hacer del software un objeto operable, verificable y evolucionable por la IA

La ingeniería de software en la era de la IA no consiste en que la IA escriba más rápido código con viejos paradigmas, sino en rediseñar el software en sí mismo para que sea adecuado para la operación de la IA. Los nuevos sistemas software deberían ser más locales, más explícitos, más especializados y más observables, y también deberían permitir que la IA obtenga poder de ejecución real, realice exploración en paralelo y reestructuraciones estructurales.

Muchas malas arquitecturas del pasado no eran fruto de la ignorancia de los ingenieros, sino de compromisos racionales bajo la antigua estructura de costes. La homogeneidad full‑stack, una base de datos que lo abarca todo, marcos genéricos, dependencias de plataformas centrales, supervisión humana directa y cambios mínimos ayudaron en su momento a ahorrar mano de obra. Pero cuando la IA cambia los costes de codificar, entender, ejecutar y verificar, esos viejos compromisos ya no son naturalmente razonables.

El objetivo central de la ingeniería de software en la era de la IA es transformar el software de un activo estático mantenido por humanos en un sistema dinámico que la IA pueda operar, observar, verificar, delegar, explorar en paralelo y reestructurar de manera decisiva.

Este es el juicio común detrás de los Ocho honores y ocho deshonras: No hagas que la IA sea solo un acelerador de la vieja ingeniería de software; haz que la ingeniería de software se reorganice para la IA.