Modernizar software heredado para crear un sistema inteligente

Escenario ilustrativo: distribuidor, aplicación y cambios previstos son ficticios. No se presentan resultados de clientes ni mejoras medidas.

Empezar por el cambio que necesita el negocio

Una aplicación de pedidos puede seguir siendo útil y, al mismo tiempo, dificultar un nuevo proveedor, una integración o un informe. La modernización conecta ese obstáculo con un cambio útil para el negocio. La antigüedad del software, por sí sola, no decide qué conviene hacer.

Imagine un distribuidor ficticio cuyo equipo prepara pedidos en una aplicación existente. Los catálogos de proveedores usan descripciones distintas para productos similares. El equipo interpreta repetidamente los registros y los relaciona con el catálogo interno. Un componente de importación antiguo dificulta cambiar ese trabajo.

La entrega propuesta moderniza esa frontera y añade un flujo inteligente de catálogo. La IA interpreta los registros de proveedores acordados y propone campos normalizados y coincidencias de productos. Los casos rutinarios que cumplen las reglas definidas pueden actualizar el catálogo automáticamente; las coincidencias inciertas llegan al responsable. Las decisiones de precios y pedidos mantienen su alcance acordado.

Averiguar qué hace realmente la aplicación

Reúna el código autorizado, las versiones de dependencias, las instrucciones de compilación y la configuración de despliegue. Identifique cómo la importación llega a los productos, quién los utiliza y qué interfaces o condiciones de licencia limitan un cambio. Registre la información que falta.

Ejecute la compilación existente en un entorno de prueba adecuado. Revise con quien conoce el catálogo un archivo válido, un registro mal formado, un producto duplicado y una ejecución interrumpida. Registre resultados, avisos y efectos sobre los pedidos. Acuerde qué comportamiento observado debe conservarse y qué defecto existente debe cambiar.

La IA puede ayudar a explicar código poco conocido, sugerir recorridos de llamadas y ordenar documentación. Compruebe sus propuestas en el repositorio, en la ejecución y con quienes operan la aplicación. Si el punto de partida no es reproducible, conseguirlo puede ser la primera entrega útil.

Elegir el cambio que resuelve el obstáculo

Una actualización de seguridad trata una exposición concreta y requiere evaluar su urgencia. Una actualización de dependencias cambia una biblioteca o framework y sus condiciones de compatibilidad. Una migración de plataforma cambia dónde o cómo funciona la aplicación. Rediseñar un proceso cambia el trabajo. Un proyecto puede necesitar una intervención antes que las demás.

Para el distribuidor, estudie si una actualización de biblioteca compatible o un adaptador puede crear una frontera estable para la nueva capacidad. Conserve el comportamiento útil de los pedidos al cambiar el componente elegido. La tarea de IA necesita entradas y reglas de correspondencia evaluadas; una actualización de dependencias por sí sola no la entrega.

La documentación Strangler Fig de Microsoft describe la sustitución gradual mediante límites que dirigen trabajo entre funciones existentes y nuevas. Exige límites adecuados y supone costes temporales de integración. Su conveniencia debe evaluarse para la aplicación concreta. Lectura relacionada: Microsoft — Strangler Fig pattern

Dejar al sistema el trabajo rutinario de catálogo

En el flujo ficticio, acuerde qué registros de proveedores aceptará el sistema y qué información interna de productos podrá usar. La IA interpreta descripciones, normaliza campos candidatos y propone coincidencias. Evalúe entradas representativas con nombres similares, identificadores ausentes y unidades contradictorias. Los formatos admitidos y el comportamiento aceptable forman parte del alcance elegido.

La aplicación comprueba campos obligatorios, identidad del producto, cambios permitidos y duplicados. Cuando se cumplen las comprobaciones acordadas, puede ejecutar una actualización rutinaria autorizada y registrar el resultado sin aprobar cada elemento manualmente. Una coincidencia ambigua, un cambio inesperado o una escritura fallida llega a una cola de excepciones con el origen y la correspondencia propuesta. Una puntuación de confianza de la IA por sí sola no autoriza una actualización.

En esta entrega propuesta, el registro de producto de la aplicación sigue siendo la fuente de referencia. Acuerde los campos descriptivos editables, como descripción normalizada y referencia del proveedor, antes de implementar. Precios, compromisos de pedido y campos no autorizados quedan fuera de esta acción rutinaria. Evalúe las coincidencias semánticas con ejemplos del catálogo, además del formato.

Dé al responsable una vista de las actualizaciones completadas, excepciones e historial de acciones, con medios para corregir una correspondencia o pausar la automatización. El objetivo es disponer antes del catálogo con menos preparación repetitiva y reservar a las personas las decisiones importantes de producto. Compare esfuerzo, tiempo de respuesta y correcciones con el proceso inicial antes de comunicar mejoras.

Figura 1 en texto

La IA interpreta los registros acordados, normaliza campos candidatos y relaciona productos con contexto autorizado. Reglas de correspondencia evaluadas, validación y permisos determinan qué actualizaciones descriptivas rutinarias pueden escribirse en el registro de referencia de la aplicación sin aprobación individual. La confianza del modelo no basta. Coincidencias inciertas o contradictorias, cambios inesperados y escrituras fallidas llegan al responsable con origen e historial. Las personas corrigen excepciones y pueden pausar el flujo. Precios y compromisos de pedido quedan fuera de estas escrituras. Los pedidos existentes siguen siendo una dependencia que probar. Aplicamos IA donde aporta valor útil, con contexto, arquitectura y comprobaciones definidos. Una vía separada del método Devmojos muestra IA útil y contexto definido, arquitectura y acciones delimitadas, y después pruebas, revisión y evolución controlada.

El método Devmojos: contexto, arquitectura y comprobaciones visibles

Construimos esta capacidad con ayuda de IA mediante el proceso de entrega de Devmojos. El harness proporciona a los agentes de programación la tarea definida, código y contratos relevantes, ejemplos representativos y permisos explícitos. Los agentes proponen cambios, pruebas y documentación; los ingenieros examinan los resultados y deciden la aceptación de la versión. Este método de entrega es distinto de la IA que interpreta catálogos en funcionamiento.

Una prueba generada puede repetir la misma suposición errónea del código generado. Compare ambos con ejemplos y resultados esperados elegidos de forma independiente. Ejecute comprobaciones de dependencias, compatibilidad y seguridad adecuadas a la tecnología. OWASP Dependency-Check, por ejemplo, busca vulnerabilidades conocidas y divulgadas en dependencias; eso no demuestra la seguridad de toda la aplicación.

Registre el trabajo útil, incluida la revisión y las correcciones. Un cambio aceptado aporta evidencia para esa aplicación y alcance. Las afirmaciones sobre mayor rapidez o menor coste total requieren una referencia comparable y los costes relevantes de trabajo y operación. Lectura relacionada: OWASP — Dependency-Check

Tareas claras y contexto reutilizable buscan reducir retrabajo y acortar el camino a una entrega útil. Pruebas y revisión independiente aportan evidencias de calidad; permisos delimitados y comprobaciones adecuadas apoyan control y seguridad. Interfaces modulares, decisiones documentadas y pruebas de carga ayudan a preparar evolución, desarrollo futuro y escalabilidad. Compare costes de implementación, revisión, modelos y operación antes de afirmar un resultado más económico. El software convencional resuelve los pasos que no necesitan IA.

Entregar una parte completa de la importación

Prepare la importación inteligente en un entorno de pruebas con datos representativos autorizados. Pruebe la extracción de campos y las coincidencias de productos por separado de la validación y escritura de registros. Incluya un caso rutinario que avance automáticamente y una coincidencia incierta que deba llegar a una persona. Compruebe duplicados, entradas rechazadas y efectos en los pedidos.

Acuerde qué sucede si una ejecución se interrumpe. Algunos sistemas pueden completar la importación en una transacción; otros requieren procesamiento reanudable o conciliación explícita. La implementación debe ajustarse a la aplicación y al modelo de datos. Defina los registros de referencia y cómo detectar trabajo parcialmente procesado.

Relacione cada ejemplo acordado con su resultado real, incluidas coincidencias erróneas, actualizaciones indebidas, excepciones y correcciones del operador. Compruebe que una persona entiende por qué ocurrió una actualización y puede detener el flujo. El responsable de negocio y el técnico aceptan la capacidad elegida a partir de estas evidencias.

Preparar la puesta en marcha y la recuperación

Ensaye los pasos de despliegue. Acuerde quién puede pausar la importación, comprobar resultados y organizar la continuidad del trabajo si se detiene el cambio. Un despliegue limitado puede ayudar cuando se puede separar trabajo representativo. Elija señales que permitan detectar fallos en el comportamiento modificado.

La documentación SRE de Google describe un despliegue canario como una implementación parcial y limitada en el tiempo, evaluada antes de continuar. Su utilidad depende de tráfico representativo y señales relevantes. Una muestra pequeña o un periodo tranquilo puede ocultar un problema importante.

Distinga volver al código anterior de recuperar datos ya escritos. Una versión antigua puede no leer un esquema cambiado. Restaurar una copia puede eliminar trabajo válido posterior. Prepare compatibilidad, restauración, reprocesamiento o acciones compensatorias antes de modificar datos de producción y pruebe el procedimiento cuando sea viable. Lectura relacionada: Google SRE — Canarying releases

Figura 2 en texto

Dos decisiones relacionadas requieren evidencia separada. Primero, ¿puede el código anterior trabajar con los datos y esquema actuales? Después, ¿cómo recuperar o conciliar los registros ya escritos? Según el cambio, pueden necesitarse compatibilidad, restauración, reprocesamiento o una acción compensatoria. Restaurar una copia puede eliminar trabajo válido posterior. El procedimiento se elige para la aplicación y se prueba cuando es viable. Una vía de entrega separada muestra contexto de tarea, código e interfaces, propuestas de cambios y pruebas con IA y después pruebas, revisión y decisión técnica de lanzamiento. Explica cómo se construye la capacidad inteligente; no es una recuperación automática.

Usar la primera entrega para decidir el siguiente paso

Entregue el componente modificado, la compilación reproducible, las pruebas y los procedimientos de lanzamiento y recuperación de datos. Incluya la vista operativa, reglas de excepción, dependencias de modelos y entradas y autoridad para pausar o reanudar. La documentación útil y el control directo pueden reducir la dependencia del proveedor para ajustes cotidianos; modelos, software y plataformas siguen necesitando responsables.

El siguiente paso puede ser otro componente, una actualización corriente o conservar la aplicación actual. La falta de acceso, responsables de integración o evidencia de recuperación puede detener una migración propuesta. Un sistema útil con una necesidad pequeña puede justificar una intervención mucho menor que una reescritura.

Traer una aplicación y el cambio necesario

Para una primera conversación, identifique la aplicación, el cambio que bloquea y quienes la usan y mantienen. Describa el acceso disponible al código y compilación, integraciones importantes, restricciones de dependencias y ventana operativa aceptable. Reserve las credenciales y datos sensibles para un entorno de trabajo acordado por separado.

Devmojos conecta la modernización gradual con una capacidad inteligente útil en la aplicación de la que ya depende el negocio. Una primera entrega delimitada y componentes reutilizables buscan costes accesibles y margen para adaptar productos, procesos y servicios. La evaluación se utiliza cuando hace falta; un alcance claro puede pasar directamente a la entrega. AI Engineering puede apoyar a su equipo, y la operación continuada se acuerda por separado.