Estrategia brownfield
Cómo hacer la transición de un código existente al desarrollo AI-native: cuándo remediar en el sitio, cuándo aplicar el Strangler-fig, cuándo reconstruir, cuándo aislar, y la metodología que hace cada opción viable.
¿Es tu código realmente brownfield?
Los cuatro modos de esta página aplican a códigos brownfield: código existente con decisiones acumuladas, usuarios en producción y un equipo trabajando dentro de él. Antes de elegir un modo, verifica el estado del código. Tres aparecen en la práctica:
| Estado | Qué significa | Qué hacer |
|---|---|---|
| Greenfield (en desarrollo, pre-GA) | Código nuevo, aún no en producción, o en producción pero suficientemente reciente como para que todo el código esté siendo diseñado activamente. Las puntuaciones bajas de madurez aquí son decisiones de planificación, no deuda. | Continúa el desarrollo. Cierra las brechas de madurez según el calendario del roadmap. Ejecuta la evaluación de madurez en GA y trata las brechas no cerradas como brownfield entonces. |
| Brownfield (producción, acumulado) | El código existe, corre en producción, tiene usuarios reales, acumula años de decisiones. Las brechas de madurez son deuda. | Elige un modo usando los cuatro que se describen a continuación. |
| Híbrido | Un nuevo servicio listo para el Nivel 5 dentro de una organización cuyos otros sistemas son brownfield. El nuevo servicio es greenfield; el límite de integración heredada es brownfield. | Evalúa el nuevo servicio como greenfield. Para cada límite heredado, elige un modo por separado. La versión más común: una nueva aplicación AI-native que lee o escribe datos a través de una API heredada. |
Los cuatro modos
Cada modo es un camino diferente hacia el Nivel 5. La pregunta no es "¿qué modo tiene capacidad el equipo?" (esa es una decisión de asignación de recursos posterior). La pregunta es "¿cuál es el camino más corto hacia el Nivel 5 para este código, según la evidencia?" El tamaño del equipo, las prioridades estratégicas y el costo de oportunidad son entradas que un humano evalúa después de leer la recomendación; no son entradas a la recomendación misma.
| Modo | Qué significa "Camino al Nivel 5" |
|---|---|
| Remediar en el sitio | El Nivel 5 ocurre en este código mediante la construcción gradual del andamiaje. |
| Strangler-fig | El Nivel 5 ocurre gradualmente: las piezas nuevas se construyen listas para el Nivel 5 mientras las antiguas se retiran. |
| Reconstrucción completa | El Nivel 5 ocurre en una nueva versión de este código; la versión antigua se retira en la transición. |
| Aislar y evitar | El Nivel 5 no ocurre en este código. Ocurre en nuevos códigos listos para el Nivel 5 junto a él; este permanece congelado. |
Modo 1: Remediar en el sitio
Conserva el código existente. Invierte en el andamiaje: pruebas, tipos, convenciones, intención documentada. Usa la IA para acelerar la propia remediación mediante la metodología Research-Review-Rebuild que se describe a continuación.
Cuándo es correcto: la arquitectura es fundamentalmente sólida (el problema es el andamiaje, no la estructura); el equipo tiene experiencia de dominio ligada al código actual; la continuidad del negocio no puede tolerar sistemas paralelos.
El riesgo: remedias el andamiaje y el código permanece fundamentalmente en el Nivel 3 porque la estructura te lo impide. Has pasado seis meses y aún no puedes alcanzar el Peldaño 5.
Modo 2: Strangler-fig
Construye la nueva funcionalidad lista para el Nivel 5 junto al sistema antiguo. Enruta el tráfico a través de una fachada. Elimina partes del sistema antiguo una por una a medida que las nuevas demuestran su valor. El Strangler Fig Pattern de Martin Fowler es la referencia canónica.
Cuándo es correcto: el sistema existente tiene costuras limpias para la extracción; la continuidad del negocio importa; el tiempo de reconstrucción de todo el sistema excedería la tolerancia del negocio.
El riesgo: identificar las costuras es difícil. Si las costuras no son limpias, terminas con dos sistemas acoplados en lugar de uno: el doble de complejidad, ninguno de los beneficios.
Modo 3: Reconstrucción completa
Empieza de cero con un código listo para el Nivel 5. Ejecuta los dos sistemas en paralelo, migra los datos, realiza la transición cuando el nuevo sistema demuestre ser equivalente o mejor.
Cuándo es correcto: la estructura existente impide activamente el trabajo que necesitas hacer; el costo de la remediación continua supera el costo de la reconstrucción; la economía de la reconstrucción asistida por IA hace que sea viable en un plazo que antes no lo era; el dominio es bien conocido (estás reemplazando el cómo, no redescubriendo el qué).
El riesgo: el efecto del segundo sistema. Las reconstrucciones acumulan cada solicitud de funcionalidad diferida del sistema antiguo y colapsan bajo su propio peso. Mantén el alcance disciplinado.
Modo 4: Aislar y evitar
Congela el sistema heredado. Mantenlo con manos humanas al nivel que el negocio aún requiere. Construye nuevo valor como nuevas aplicaciones listas para el Nivel 5 junto a él, enrutando a través de la API o capa de datos que ya funciona. No intentes modernizar el sistema heredado en sí.
Cuándo es correcto: el costo de remediación supera el valor restante en el sistema heredado; el nuevo valor puede entregarse en paralelo sin integración profunda; el sistema heredado tiene una costura de integración viable (API, base de datos, cola) a través de la cual pueden enrutar las nuevas aplicaciones; el negocio tolera el modo de mantenimiento durante un período prolongado.
El riesgo: el sistema heredado aislado acumula más deuda con el tiempo. Eventualmente algo fuerza la decisión: un parche de seguridad que no puede aplicarse, un EOL de plataforma, un modelo de datos que no puede soportar nuevos requisitos. Aislar y evitar compra tiempo; no resuelve el problema.
"No invertir" es un resultado legítimo aquí. No todo sistema heredado vale la pena repararlo. La señal: estás escribiendo tu tercer plan de remediación para el mismo módulo, las pruebas que añadiste el trimestre pasado ya no están en verde, y el negocio sigue entregando valor a través de este código. Ese no es un código esperando ser modernizado. Es un código esperando ser reemplazado.
Criterios de decisión
| Pregunta | Remediar | Strangler-fig | Reconstruir | Aislar |
|---|---|---|---|---|
| ¿Es la arquitectura fundamentalmente sólida? | Sí | Principalmente | No | No importa |
| ¿Hay costuras limpias para la extracción? | N/A | Sí | N/A | Al menos un punto de integración usable |
| ¿Puede el equipo describir la intención del sistema? | Sí | Sí | Sí (o usa Black Box to Blueprint) | No requerido para el sistema heredado |
| ¿Puede el negocio tolerar sistemas paralelos? | N/A | Sí | Sí | Sí |
| ¿Es el pago continuo de deuda más barato que el reemplazo? | Sí | Parcialmente | No | Sí, mientras el nuevo valor se entrega junto a él |
| ¿Tiene el sistema heredado valor restante que vale la pena preservar? | Sí | Sí | Sí | Sí, pero no vale la pena repararlo |
| ¿Tienes capacidad de equipo para la opción más difícil? | La más baja | Media | La más alta | Baja (el sistema heredado permanece congelado) |
¿Sin un sí claro en la fila de reconstrucción? No reconstruyas. El efecto del segundo sistema castiga a los equipos que eligieron reconstruir por razones que no encajaban.
¿Varias respuestas "no" en Remediar/Strangler-fig/Reconstruir, pero el sistema heredado sigue teniendo valor de negocio? Aislar y evitar es probablemente el modo correcto.
El Technical Debt Quadrant agudiza la decisión de reconstrucción:
| Tipo de deuda | Causa | Remediación |
|---|---|---|
| Prudente, deliberada | Enviamos sabiendo el atajo. | Generalmente remediable. |
| Prudente, inadvertida | Aprendimos mejor después. | Remediable, pero verifica si el aprendizaje invalida decisiones estructurales. |
| Imprudente, deliberada | Lo sabíamos y lo hicimos de todas formas. | A menudo remediable con disciplina, pero señala problemas de proceso que sobreviven al código. |
| Imprudente, inadvertida | No sabíamos lo que estábamos haciendo. | Candidato a reconstrucción. La estructura refleja ignorancia que el conocimiento posterior no puede deshacer en el mismo lugar. |
¿Necesitas ayuda para elegir el modo correcto? La habilidad de Claude Code codebase-readiness evalúa un código contra el modelo de madurez de nueve dimensiones y recomienda un Camino al Nivel 5, incluyendo cuál de los cuatro modos aplica.
La metodología: Research, Review, Rebuild
Publicada por Fowler y EPAM en Research, Review, Rebuild, esta es la metodología brownfield más concreta disponible. Se aplica directamente a los Modos 1-3; en el Modo 4 aplica a la costura de integración incluso si el sistema heredado permanece congelado. El despliegue directo de agentes en un código heredado opaco produce de manera fiable resultados incorrectos con confianza. La estructura por fases previene esto.
Fase 1: Research (Investigación). La IA analiza el código existente: reconstruye la intención, extrae contratos de comportamiento, identifica patrones, documenta el grafo de dependencias. Herramientas como los conectores MCP permiten a los agentes recorrer sistemáticamente el código. Resultado: un mapa de intención, lo que el sistema hace, independientemente de cómo está estructurado.
Fase 2: Review (Revisión). Los expertos de dominio validan el mapa de intención. La IA puede extraer lo que hace el código. Solo los humanos pueden distinguir el comportamiento intencional del accidente histórico. Este es el cuello de botella de rendimiento: en el caso de estudio de Bahmni (AngularJS a React), la revisión humana tomó aproximadamente 20 minutos por componente. Planifica la capacidad para la revisión, no solo para la generación.
Fase 3: Rebuild (Reconstrucción). Con la intención validada, la IA genera código de reemplazo con ambigüedad mínima. En Bahmni: aproximadamente $2 por componente en menos de una hora, frente a 3-6 días manualmente. La economía es convincente cuando las Fases 1 y 2 son disciplinadas, y peor que la tradicional cuando se omiten.
El orden es importante. Los equipos que se saltan la investigación y la revisión para llegar más rápido a la reconstrucción no ahorran tiempo; producen resultados incorrectos más rápido y gastan el tiempo ahorrado depurando comportamiento alucinado.
Economía: lo que implican los números
El dato de Bahmni reorganiza las matemáticas: lo que era una migración de 18 meses se convierte en una de 6 meses, donde la restricción es la capacidad del revisor, no las horas de ingeniería. Tu experiencia variará según la arquitectura, la cobertura de pruebas y la complejidad del dominio, y la economía solo funciona cuando la Investigación y la Revisión son disciplinadas. Omitirlas colapsa la aceleración.
Black Box to Blueprint: ingeniería inversa de la intención
Cuando el equipo original se ha ido, la documentación es incorrecta y el código es la única fuente de verdad, la Fase 1 se convierte en un problema de ingeniería inversa. El artículo Black Box to Blueprint de Fowler describe cinco técnicas:
- Reconstrucción de la capa de UI: inferir el comportamiento a partir de la interfaz de usuario y sus transiciones de estado.
- Captura de cambios en datos: observar cómo el sistema modifica datos en producción para inferir la lógica de negocio.
- Inferencia de lógica de servidor: analizar los límites de API y los patrones de solicitud/respuesta para reconstruir la lógica detrás de ellos.
- Arqueología binaria: reconstruir a partir de binarios, registros e interfaces externas cuando se pierde el código fuente.
- Enriquecimiento multi-pasada progresivo: dividir los artefactos en fragmentos manejables, extraer insights parciales por pasada, construir contexto de manera incremental. El análisis en una sola pasada de todo el sistema falla a escala.
Dos disciplinas son innegociables: la triangulación (cada hipótesis sobre la intención confirmada a través de dos fuentes independientes: UI + registros, API + base de datos, código + comportamiento observado) y el seguimiento de linaje (para cada afirmación, registrar la evidencia en la que se basa, para que la evidencia poco fiable sea identificable más adelante).
Spec-from-code: la inversión brownfield
Los Estándares de ejecución con IA y la Guía de especificación asumen que las specs preceden al código. El brownfield invierte esto: el código ya existe y la spec debe extraerse de ingeniería inversa antes de que el trabajo spec-first pueda reanudarse. Este es un flujo de trabajo diferente.
Las herramientas de desarrollo impulsado por specs como spec-kit, Kiro y Tessl están orientadas principalmente al greenfield. El "Brownfield Bootstrap" de spec-kit es la excepción: autodescubre la arquitectura existente para establecer una Constitución (principios rectores persistentes), luego aplica el desarrollo impulsado por specs solo a las nuevas funcionalidades mientras la Investigación y la Revisión se ponen al día con la superficie heredada.
El patrón que funciona:
- Extrae la especificación implícita. ¿Qué hace realmente el sistema? Ver la secuencia brownfield del Laboratorio de IA para la versión disciplinada.
- Escribe escenarios de extremo a extremo que describan el comportamiento esperado actual a partir de la spec extraída.
- Verifica que los escenarios pasen con el código existente. Esto se convierte en tu andamiaje de regresión.
- Aplica spec-first a todo el trabajo nuevo. Sin excepciones.
- Migra mediante Strangler-fig componente por componente, usando los escenarios como protección durante la migración.
El primer paso es el trabajo más difícil en la transición. Los agentes pueden documentar lo que el sistema hace; solo los humanos pueden responder si es lo que debería hacer.
Errores comunes
Subestimar el cuello de botella de la revisión humana. Los costos de generación de IA cayeron en órdenes de magnitud. Los costos de revisión humana no. Planifica la capacidad del revisor como una restricción de primer nivel, no como un elemento secundario.
Brownfield a medias. Ejecutar parte del proyecto en modo AI-native y parte en modo tradicional porque "esa parte es más rápida a la antigua" no produce ninguno de los beneficios. La lista de errores del Laboratorio de IA nombra esto específicamente.
Tratar las costuras como dadas cuando son implícitas. El Strangler-fig se lee bien en pizarras. En la práctica, las "costuras limpias" son donde las responsabilidades pueden extraerse sin acoplarse a otros ocho módulos. Si eso no es cierto de tu código, el Strangler-fig se convierte en una reconstrucción completa con pasos adicionales.
Confundir el costo de modernización con el costo de reemplazo. La decisión "remediar vs. reconstruir" no trata sobre si reparar cuesta dinero: ambas cuestan dinero. Se trata de si la estructura puede soportar lo que necesitas que soporte. La deuda imprudente-inadvertida no puede deshacerse en el mismo lugar independientemente del presupuesto.
Panorama de herramientas (instantánea)
El marco no recomienda herramientas específicas; el panorama cambia demasiado rápido. Pero vale la pena conocer: el desarrollo impulsado por specs (spec-kit, Kiro, Tessl; ver la comparación de Fowler); los conectores MCP para el recorrido sistemático del código; las plataformas de agentes (Claude Code, Cursor, Aider, Devin) con diferentes tradeoffs de autonomía/humano-en-el-bucle; los benchmarks (SWE-bench, IDE-Bench), aunque las puntuaciones de los benchmarks en problemas curados no predicen el rendimiento brownfield en tu código.
Espejo: estrategia e infiabilidad
Ingeniería para la fiabilidad trata sobre cómo construir sistemas fiables a partir de resultados de IA poco fiables. La estrategia brownfield trata sobre cómo hacer que los agentes de IA sean efectivos en códigos poco fiables. Los dos convergen en el andamiaje: sensores rápidos, intención documentada, validación a nivel de escenario. Una migración brownfield que no termina con el código en el Nivel 5 de madurez y no cumple con la disciplina de Infiabilidad tuvo éxito en la forma pero no en la función.
Relacionado
- Madurez del código: el diagnóstico del que depende esta página
- El Laboratorio de IA: el modo de trabajo del Peldaño 5 una vez que llegas allí
- Ingeniería para la fiabilidad: el problema espejo
- Estándares de ejecución con IA y Guía de especificación: ingeniería de especificaciones
Fuentes
- Fowler, M. (2026). "Harness Engineering for Coding Agent Users." martinfowler.com
- Fowler, M. (2026). "From Black Box to Blueprint: Reverse-Engineering Legacy Systems with AI." martinfowler.com
- Fowler, M. & EPAM. (2026). "Research, Review, Rebuild: AI-Assisted Legacy Modernization." martinfowler.com
- Fowler, M. (2024). "Rewriting the Strangler Fig Application." martinfowler.com
- Fowler, M. "Strangler Fig Application." martinfowler.com
- Fowler, M. "Technical Debt Quadrant." martinfowler.com
- Fowler, M. (2026). "Spec-Driven Development: The Three Tools." martinfowler.com
- GitHub. "Spec Kit." github.com/github/spec-kit
- Duvall, P. (2026). "AI Development Patterns." github.com/PaulDuvall/ai-development-patterns
- Feathers, M. (2004). Working Effectively with Legacy Code. Addison-Wesley.
- "Artificial Intelligence for Software Architecture: A Literature Review." (2025). arXiv. arxiv.org/abs/2504.04334
- "IDE-Bench: Evaluating LLM Agents on Real Codebases." (2026). arXiv. arxiv.org/abs/2601.20886
- SWE-bench. swebench.com
← Volver al inicio · Madurez del código · El Laboratorio de IA · Ingeniería para la fiabilidad · Glosario