Hace unas semanas, un equipo al que asesoraba intentó algo que parecía perfectamente razonable. Tenían una plataforma de comercio electrónico existente, de unos cinco años, construida como un monolito modular con algunos microservicios extraídos. La empresa quería un motor de recomendaciones integrado en el catálogo de productos. El equipo llevaba meses usando asistentes de programación con IA y se sentía seguro. Apuntaron a la IA a la base de código, describieron la función y le pidieron que generara un plan de integración.

Lo que salió fue técnicamente coherente. La IA propuso nuevos componentes, sugirió contratos de API e incluso generó código inicial. El problema era que no detectaba un middleware de detección de fraude que se situaba entre el servicio de pedidos y el servicio de pago, un componente que no era evidente solo por la estructura del código. Tampoco contemplaba un paso de validación de datos con un servicio de direcciones externo que se había añadido como solución temporal dos años antes y nunca se documentó.

El equipo pasó tres días depurando fallos de integración antes de que alguien se diera cuenta de que la IA había estado construyendo sobre una comprensión incompleta del sistema. El código generado no estaba mal por separado. Estaba mal en contexto.

Este es el problema de brownfield. Y casi nadie habla de ello.

La Ilusión de Greenfield

La mayor parte de la conversación sobre el desarrollo impulsado por IA asume condiciones de terreno nuevo. Nuevo proyecto, hoja en blanco, sin restricciones heredadas. En ese mundo, la IA brilla. Describes una intención, la IA la descompone en unidades de trabajo, genera modelos de dominio, produce código y el equipo valida. Escribí sobre este proceso en Reimagine, Don’t Retrofit, y funciona.

Pero aquí está la realidad en la que viven la mayoría de las empresas: no están construyendo sistemas nuevos. Están evolucionando los existentes.

Diversos análisis del sector muestran de forma consistente que aproximadamente entre el 70 y el 80 por ciento de los presupuestos de TI de las empresas se destinan a mantener y mejorar sistemas existentes, no a construir nuevos. La base de código empresarial media tiene años, lleva capas de decisiones acumuladas, soluciones no documentadas y conocimientos tribales que viven en la cabeza de desarrolladores que pueden o no seguir formando parte del equipo.

Cuando apuntas la IA a ese tipo de sistema sin preparación, obtienes exactamente lo que experimentó ese equipo de comercio electrónico: resultados técnicamente plausibles construidos sobre un conocimiento incompleto. La IA no sabe lo que no sabe. Y el equipo tampoco, hasta que algo se rompe.

He escrito antes sobre la descoordinación entre los asistentes de código de IA y el desarrollo de software empresarial , y sobre la brecha de gobernanza que provoca que las iniciativas de IA fracasen a gran escala. Ambos artículos diagnosticaron la tensión entre la capacidad de la IA y la realidad empresarial. Esta publicación aborda la dimensión concreta y práctica que hace que el brownfield sea tan peligroso: la IA no puede razonar ni modificar de forma segura un sistema que no comprende.

Por qué Brownfield rompe la IA

En el desarrollo en terreno nuevo, la IA comienza con un lienzo en blanco. Cada artefacto que genera, desde historias de usuario hasta modelos de dominio y código, es autocoherente porque no hay nada más con lo que ser consistente.

Brownfield es fundamentalmente diferente. La IA debe funcionar dentro de un sistema existente que tenga:

Dependencias ocultas. Componentes que interactúan de formas que no se ven solo con la estructura del código. Middleware, buses de eventos, bases de datos compartidas y preocupaciones transversales que solo surgen en tiempo de ejecución o a través del conocimiento institucional.

Decisiones no documentadas. Cada base de código madura lleva decisiones de diseño que tenían sentido en su momento pero que nunca se registraron. ¿Por qué el servicio de pedidos llama al servicio de detección de fraude antes de pagar? Por un incidente de hace tres años que nadie escribió.

Conocimiento tribal. Las soluciones alternativas, las advertencias de «no toques ese módulo», los contratos implícitos entre servicios que existen solo en la mente de los desarrolladores que los crearon. Cuando esos desarrolladores se van, el conocimiento se va con ellos.

Deuda técnica acumulada. Atajos, soluciones temporales que se convirtieron en permanentes, patrones obsoletos que aún estaban en producción. La IA trata todo el código como igualmente intencionado. No puede distinguir entre una elección de diseño deliberada y un hackeo que nadie tuvo tiempo de arreglar.

El resultado es predecible. La IA genera código que parece correcto aislado pero se interrumpe en la integración. Propone cambios que entran en conflicto con restricciones que no puede ver. Esto genera riesgos de regresión en áreas que el equipo no pensó en probar porque las dependencias no eran visibles.

Esto no es una limitación de la IA que se solucione con mejores modelos. Es un problema de contexto. Y el contexto, en sistemas brownfield, no está presente en el código. Vive en el espacio entre el código y las personas que lo construyeron.

Elevación del código: Haciendo visible lo invisible

La metodología AI-DLC aborda esto con un concepto que considero tanto simple como esencial: la elevación de código.

La elevación de código es una fase previa obligatoria para cualquier trabajo en brownfield. Antes de que la IA participe en la elaboración, diseño o construcción, el equipo convierte primero la base de código existente en modelos semánticos que tanto la IA como los humanos pueden usar como contexto compartido.

El proceso consta de tres etapas:

Fase 1: Análisis estático. La IA analiza la estructura del código, dependencias, componentes, interfaces y relaciones. La salida es un modelo estático: un mapa de lo que existe en el sistema y cómo se conectan las piezas. Piénsalo como la anatomía de la base de código, el esqueleto y los órganos.

Fase 2: Análisis Dinámico. La IA analiza los flujos de ejecución para los casos de uso más significativos. La salida es un modelo dinámico: una representación de cómo interactúan los componentes en tiempo de ejecución. Esta es la fisiología, cómo se comporta realmente el sistema cuando hace su trabajo.

Fase 3: Deuda técnica y revisión del promotor. Aquí es donde el 20 por ciento humano marca la diferencia. Los desarrolladores que conocen el sistema validan, corrigen y enriquecen los modelos. Añaden el middleware de detección de fraude que la IA no detectó. Anotan la solución alternativa que no es evidente en el código. Marcan el componente que «funciona pero no debe tocarse».

Todo el proceso suele durar entre dos y cuatro horas para un sistema bien estructurado. Bases de código más grandes o complejas, especialmente monolitos fuertemente acoplados o sistemas con integraciones extensas y no documentadas, pueden requerir múltiples sesiones. El alcance determina la duración, y eso es intencionado. El resultado es un conjunto validado de modelos que se convierten en el contexto de todo lo que sigue: elaboración de mobs, construcción de mob, pruebas y operaciones.

Sin la elevación de código, cada fase posterior opera sobre supuestos. Con ello, cada fase funciona sobre la comprensión compartida.

Alcance: Eleva lo que vas a tocar

Una de las fortalezas prácticas de la elevación de código es que no requiere mapear todo el sistema. Elevas lo que es relevante para la intención en cuestión.

El alcance sigue un modelo de prioridad sencillo:

Alta prioridad: Componentes que serán modificados directamente por el cambio previsto, además de sus dependencias directas. Estos deben estar elevados.

Prioridad media: Componentes que comparten datos o eventos con los componentes modificados. Estos deberían elevarse si el tiempo lo permite.

Baja prioridad: Componentes sin relación con el cambio previsto. Sáltalos.

Para el equipo de comercio electrónico que mencioné antes, añadir un motor de recomendaciones significaba elevar el Catálogo de Productos, OrderService y UserService (directamente afectados), además de AnalyticsService y SearchService (datos compartidos). El Servicio de Pago y el Servicio de Envío quedaron fuera porque no se vieron afectados.

Esta disciplina de alcance es importante. Elevarlo todo es un desperdicio. Elevar demasiado poco es un riesgo. El equipo decide el límite correcto, y esa decisión en sí es un valioso ejercicio de alineación.

Qué cambia tras la elevación

El impacto de la elevación del código se extiende a lo largo de cada fase posterior del ciclo de desarrollo del desarrollo.

En la elaboración de la mafia, La IA entiende el sistema existente al elaborar nuevos requisitos. En lugar de generar historias en el vacío, identifica automáticamente áreas de impacto y dependencias. El Product Owner y los desarrolladores pueden ver, en tiempo real, cómo una nueva función interactúa con lo que ya existe.

En la construcción de la mafia, La IA diseña la integración basándose en modelos validados, no en suposiciones. Aplica patrones mínimos de intrusión, capas adaptadoras e interfaces retrocompatibles porque entiende los límites que debe respetar. Como describí en El nuevo papel del promotor, el trabajo del promotor en la construcción es la validación y el juicio. La elevación de código les da el contexto para hacer bien ese trabajo.

En las pruebas, La IA genera pruebas de regresión basadas en los modelos dinámicos. Sabe qué flujos proteger porque ha visto cómo se comporta el sistema. Sin esos modelos, las pruebas de regresión son conjeturas.

En operaciones, La IA entiende la arquitectura lo suficiente como para monitorizar de forma inteligente, detectando anomalías relacionadas con la estructura real del sistema en lugar de umbrales genéricos.

El hilo conductor: Code Elevation transforma la IA de un externo que adivina el sistema a un participante que comparte la comprensión del equipo sobre él.

Por qué esto es importante más allá de la ingeniería

Para los directivos de sectores regulados, la Elevación de Códigos no es solo una práctica técnica. Es un control de riesgos.

Cuando la IA modifica un sistema que no comprende completamente, la organización absorbe ese riesgo en silencio. Un fallo de regresión en un flujo de pagos, una comprobación de cumplimiento incumplida en una aplicación sanitaria, un problema de integridad de datos en una cadena de informes financieros: estos no son inconvenientes de ingeniería. Son los hallazgos de auditorías, la exposición regulatoria y las pérdidas financieras. En sectores como la banca y la sanidad, una sola regresión no detectada puede desencadenar informes de incidentes, impacto en el cliente y costes de remediación que superan con creces el presupuesto original de desarrollo.

La elevación del código crea un registro auditable de lo que la IA entendía sobre el sistema antes de hacer cambios. Los modelos validados, las decisiones de alcance, las correcciones del desarrollador: todo esto se convierte en artefactos rastreables. Si algo sale mal, la organización puede demostrar que los cambios generados por la IA se han realizado con contexto documentado y supervisión humana, no basándose en suposiciones ciegas. En un entorno regulatorio donde «no lo sabíamos» no es una respuesta aceptable, la trazabilidad importa.

Los patrones que veo que los equipos hacen mal

Después de trabajar con varios equipos en la adopción de DLCs de IA en brownfield, he notado errores recurrentes:

Saltando por completo la elevación del código. Este es el error más común y el más costoso. Los equipos asumen que, como la IA puede leer código, entiende el sistema. Leer y entender no es lo mismo. Un desarrollador que se une a un equipo puede leer la base de código desde el primer día. Entenderlo lleva semanas o meses. La IA se enfrenta a la misma brecha, y la elevación del código es la forma de cerrarla.

Elevando demasiado. Algunos equipos intentan modelar todo el sistema antes de tocar nada. Esto convierte un ejercicio de dos horas en un proyecto de varios días y retrasa el trabajo real. Alcance a la intención. Eleva lo que vas a cambiar y de qué depende. Nada más.

Saltándome la revisión del desarrollador. La IA genera aproximadamente el 80 por ciento de los modelos correctamente. Eso suena impresionante hasta que te das cuenta de que el 20 por ciento que falta es precisamente la parte que causa los fallos en la integración: el middleware no documentado, los contratos implícitos, las soluciones alternativas. La revisión del desarrollador no es opcional. Ahí es donde entra el contexto crítico en el modelo.

No persistir con los modelos. Los modelos de elevación en código son reutilizables. Si hoy elevas el OrderService para una función de motor de recomendación, esos modelos seguirán siendo válidos el mes que viene cuando alguien necesite modificar el flujo de pedidos por otro motivo. Guárdalos. Ponles la versión de la historia. Trátalos como documentación vital.

Elevar la estática sin dinámica. La estructura por sí sola no es suficiente. Saber que el Componente A depende del Componente B no te dice cómo interactúan en tiempo de ejecución, en qué secuencia, con qué datos ni bajo qué condiciones. Ambos modelos son necesarios.

La lección más profunda

La elevación de código no es solo una técnica. Refleja un principio que se aplica mucho más allá del desarrollo brownfield: la IA solo es tan buena como el contexto en el que opera.

En greenfield, el contexto se construye progresivamente a través de intenciones, historias y modelos de dominio. En el brownfield, el contexto ya existe, pero está atrapado en el código, en la mente de las personas y en decisiones no documentadas. La elevación de código es el proceso de liberar ese contexto y hacerlo accesible tanto para la IA como para el equipo.

Por eso creo que el brownfield es en realidad el caso de prueba más importante para el desarrollo impulsado por IA. Greenfield es la demo. La realidad es el terreno contaminado. Cualquier método que funcione solo con pizarras limpias no está preparado para el negocio.

Las organizaciones que descubran cómo integrar la IA en sus sistemas existentes de forma segura, sistemática y con el contexto adecuado desbloquearán mucho más valor que aquellas que persigan el próximo prototipo de campo nuevo. Porque la verdadera ventaja competitiva no es construir cosas nuevas rápidamente. Es evolucionar lo que ya tienes sin romperlo.

Por dónde empezar

Si tu equipo está a punto de usar IA en una base de código existente, haz estas preguntas antes de escribir una sola línea de código generado:

• ¿Puede tu IA explicar claramente la arquitectura de tu sistema? Si no puede describir los componentes principales, sus responsabilidades y sus dependencias, no tiene suficiente contexto para modificar nada de forma segura.
• ¿Sabes lo que no sabes? Identifica las áreas de la base de código donde falta documentación, donde se han ido los desarrolladores originales, donde existen soluciones alternativas. Esas son tus zonas de mayor riesgo y tus candidatos de mayor prioridad para la elevación.
• ¿Has evaluado el impacto? Antes de generar código, mapea qué componentes se verán afectados por el cambio previsto, directa e indirectamente. Si no puedes dibujar ese mapa, no estás listo para construir.
• ¿Quién lleva el conocimiento tribal? Haz que esas personas estén en la sala para la revisión del desarrollador. Sus correcciones a los modelos generados por IA ahorrarán días de depuración más adelante.

La elevación del código no es sobrecarga. Es un seguro. Y en sistemas brownfield, donde el coste de equivocarse se acumula en cada punto de integración y en cada despliegue, ese seguro se amortiza muchas veces.

La IA puede generar código. Pero primero, necesita entender el sistema para el que genera código.

Esa comprensión no viene de leer el código. Viene de elevarla.

Las empresas que no elevan sus sistemas heredados antes de introducir la IA no están acelerando la transformación. Están automatizando la ambigüedad.

Ricardo