AI-Assisted Implementation and Change Maintenance
AI-Assisted Implementation and Change Maintenance es la práctica de incorporar asistencia de IA al modificar software existente, preservando el alcance del encargo, los contratos relevantes y la posibilidad de revisar qué cambió y con qué evidencia. Incluye desarrollo de funcionalidades, investigación de defectos y mantenimiento de código, documentación y dependencias. La contribución del agente se evalúa por el cambio situado que ayuda a producir, no por la cantidad de código generado.
Un Coding Agent es un sistema que puede participar en ese trabajo utilizando herramientas y retroalimentación. La implementación asistida es una actividad de ingeniería que también involucra intención de producto, decisiones humanas, entorno y revisión. El actor y el workflow no son equivalentes: disponer de un agente capaz de editar y ejecutar comandos no determina qué cambio es correcto ni quién tiene autoridad para aceptarlo.
Del encargo al cambio concreto
Repository Exploration and Task Framing identifica el problema, los componentes pertinentes y las restricciones. La implementación utiliza ese encuadre para elegir un incremento abordable. Cuando hace falta conservar expectativas o comparar diseños, Specification-Assisted Development aporta una referencia. Estas actividades pueden alternarse: descubrir una dependencia durante la edición puede obligar a revisar el encuadre antes de continuar.
Un recorrido típico incluye adquirir contexto, proponer o ajustar un plan, modificar código, recibir resultados de herramientas y revisar el diff. No es una secuencia universal obligatoria. Una corrección evidente puede requerir pocos pasos; una migración puede tener muchos ciclos de exploración y comprobación. La disciplina consiste en conservar coherencia entre objetivo, acción y evidencia durante ese recorrido.
El agente debe distinguir cambios necesarios de mejoras cercanas. Una función incómoda puede merecer atención futura sin pertenecer al encargo actual. Ampliar el diff para corregir cada imperfección observada dificulta atribuir efectos y revisar el resultado. Si una modificación adicional resulta imprescindible, conviene explicar la dependencia concreta y su impacto, en lugar de presentarla como una limpieza inocua.
Feature Development
Al desarrollar una funcionalidad, el agente puede localizar puntos de extensión, adaptar contratos y generar implementaciones iniciales. Necesita comprender cómo entra la información, dónde se aplican reglas y qué consumidores observarán el cambio. Reproducir la forma de una funcionalidad vecina ayuda con convenciones, pero no demuestra que comparta las mismas restricciones de negocio o seguridad.
El contexto relevante incluye ejemplos aceptados y excepciones importantes. Una operación que parece similar puede tener otra política de errores, compatibilidad o persistencia. El agente debería verificar esas diferencias antes de copiar su estructura. Las Persistent Instructions orientan decisiones recurrentes, mientras el pedido vigente y los contratos del sistema delimitan el resultado específico que se busca.
Un incremento útil permite observar comportamiento sin construir una plataforma anticipada. Si una tarea necesita soportar una segunda forma de entrada, no se sigue que requiera un sistema genérico de extensiones. La IA puede producir abstracciones rápidamente, pero su costo de comprensión y mantenimiento permanece en el proyecto. Aplicar simplicidad exige justificar cada mecanismo por una necesidad presente.
La colaboración humana puede mejorar el diseño antes de que exista un diff grande. Mostrar una alternativa de interfaz y su efecto sobre consumidores permite corregir una interpretación temprano. Esa interacción no obliga a consultar cada edición rutinaria; concentra la conversación en decisiones que cambian expectativas o compromisos y deja al agente ejecutar dentro de los límites ya acordados.
Bug Investigation
Investigar un bug busca explicar un comportamiento observado con evidencia. Corregirlo modifica el sistema para resolverlo. El agente puede contribuir a una investigación sin producir un fix: reproducir el síntoma, localizar una ruta ejecutada o descartar una hipótesis ya son resultados útiles. Inventar una corrección para cerrar el encargo puede ocultar que la causa sigue siendo desconocida.
Una investigación situada distingue síntoma, condición desencadenante, hipótesis y observación que la respalda. Un error de timeout puede deberse a latencia externa, bloqueo interno o un presupuesto insuficiente; aumentar el límite solo trata una de esas posibilidades. La explicación del modelo debe conectarse con la versión ejecutada y las condiciones reales. Una historia técnicamente plausible no es una causa confirmada.
El agente puede rastrear valores, comparar revisiones y proponer un experimento acotado. Conviene elegir experimentos capaces de discriminar entre hipótesis. Agregar mensajes a todas las funciones o reescribir un módulo completo puede generar más datos sin responder la pregunta. Si no hay acceso al entorno afectado, la limitación debe acompañar la conclusión y cualquier propuesta de cambio.
Cuando la evidencia identifica un defecto, la corrección necesita preservar el comportamiento no afectado. Una prueba de regresión puede aportar evidencia si expresa una expectativa válida y alcanza la condición problemática. No siempre hace falta una nueva prueba para un cambio trivial, pero tampoco basta con ejecutar una suite que nunca ejercita el caso. La elección debe seguir el riesgo y la posibilidad real de observar el resultado.
Ejemplo: una actualización que pierde información
Un servicio permite actualizar la dirección de un cliente. El agente recibe un reporte de que modificar el código postal borra el teléfono. Puede sospechar un mapeo incorrecto, pero debe localizar el contrato de actualización y comprobar si los campos omitidos significan conservar, borrar o usar un valor predeterminado. La semántica de ausencia condiciona la corrección.
Si observa que el mapper construye un objeto completo con valores vacíos y el repositorio lo persiste, tiene una cadena causal candidata. Todavía interesa confirmar qué solicitud produjo el problema y si otro consumidor depende del reemplazo completo. La intervención podría necesitar una operación parcial explícita, no solo evitar asignar una propiedad concreta. La decisión depende del contrato acordado.
El cambio puede limitarse al recorrido de actualización parcial, con comprobaciones para campos omitidos, vacíos y presentes. Un resultado responsable explica qué comportamiento se corrigió y qué otros recorridos permanecen fuera del análisis. No afirma que toda la gestión de clientes quedó verificada porque pasó una prueba del nuevo mapper.
Refactoring, Modernization and Migration
La participación de IA en estas actividades no redefine sus conceptos generales. Refactor vs Rewrite conserva la distinción entre transformar una solución existente y reemplazarla. El agente puede ayudar a identificar repeticiones, adaptar interfaces o mover responsabilidades, pero debe aclarar qué comportamiento se espera preservar y dónde se aceptan cambios semánticos.
Una transformación mecánica tiene reglas locales relativamente explícitas; una semántica modifica interpretación, contratos o efectos. Renombrar un símbolo puede parecer mecánico y aun así afectar configuración, serialización o consumidores dinámicos. El agente necesita comprobar los límites de la herramienta utilizada y buscar dependencias que no aparezcan como referencias estáticas. La automatización no vuelve inexistentes esos vínculos.
En modernización pueden coexistir cambios de lenguaje, bibliotecas y organización interna. Aplicarlos todos juntos dificulta saber qué produjo una regresión. Conviene separar incrementos cuando sus riesgos son distintos y conservar una base de comparación pertinente. La velocidad de generación de código no justifica perder la capacidad de explicar diferencias observables.
Migration Strategy aporta el marco para transiciones entre estados. El agente puede inventariar consumidores y proponer pasos compatibles, pero una migración también puede involucrar datos, operación y coordinación humana. Compilar la versión nueva no demuestra que se pueda volver atrás ni que todas las instancias puedan convivir. Esas condiciones requieren decisiones y evidencia propias del sistema.
Alcance, deuda y mantenimiento
La IA puede abaratar la producción inicial de cambios y aumentar el volumen que el equipo debe entender. Si cada modificación introduce convenciones nuevas o abstracciones innecesarias, el costo posterior puede superar el ahorro local. Technical Debt ayuda a discutir compromisos concretos, evitando llamar deuda a cualquier estilo que el agente prefiera reemplazar.
Durante una refactorización importa preservar trabajo ajeno y límites del encargo. Un diff que incluye archivos generados, formatos globales o ediciones no relacionadas exige revisión adicional aunque el código funcional sea correcto. Revisar el estado inicial y el final permite separar esos efectos. El agente debe corregir sus cambios accidentales de manera focalizada, sin descartar modificaciones que no le pertenecen.
La mantenibilidad también depende de dejar una explicación suficiente. Una solución sorprendente puede necesitar una razón junto a su restricción real; una función obvia no necesita comentarios que narren cada línea. La asistencia puede proponer documentación, pero debe elegir lo que ayuda al próximo lector a comprender una decisión y evitar duplicar información que quedará obsoleta.
Documentation
La documentación generada puede resumir interfaces, actualizar ejemplos o explicar una decisión. También puede reproducir con confianza una suposición incorrecta del modelo. El código revela comportamiento actual, pero no siempre su intención ni las promesas hechas a consumidores. La revisión debe contrastar contratos, decisiones y ejemplos pertinentes, especialmente cuando el texto usa palabras como “garantiza” o “siempre”.
Actualizar documentación junto al cambio ayuda a conservar coherencia. No implica reescribir documentos enteros si solo cambió un requisito localizado. El agente debería identificar qué afirmaciones quedaron afectadas y preservar el contexto no relacionado. Los ejemplos ejecutables o comprobaciones de enlaces pueden ayudar con errores mecánicos; no determinan por sí solos que la explicación conceptual sea correcta.
Una referencia externa requiere comprobar que respalde la afirmación atribuida. Citar una página oficial no valida todo el párrafo que la rodea. Cuando una conclusión es análisis del proyecto, conviene presentarla como tal. La misma disciplina aplica a un resumen de código: el agente debe poder conectar una afirmación relevante con evidencia concreta y reconocer dónde está infiriendo intención.
Dependency Upgrades
Actualizar una dependencia puede cambiar APIs, comportamiento transitivo, requisitos de entorno y componentes nativos. El agente puede identificar la cadena afectada y proponer la actualización compatible más pequeña. No debe perseguir un número de audit limpio mediante cambios amplios sin analizar el riesgo efectivo y la compatibilidad. El objetivo de mantenimiento es un sistema comprendido y sostenible, no una métrica aislada.
Semantic Versioning expresa convenciones sobre cambios de API pública y versiones; su especificación distingue incrementos de patch, minor y major según esas condiciones. Para un proyecto consumidor, una versión declarada compatible sigue necesitando evidencia situada: configuración, uso de APIs, dependencias transitivas y entorno pueden afectar el resultado. La convención orienta la selección, no sustituye probar el cambio.
Conviene diferenciar la actualización de resolución de una modificación del código fuente de una dependencia. También importa conservar reproducibilidad y entender qué archivos cambiaron. El agente puede explicar el diff del lockfile y ejecutar las comprobaciones autorizadas. No necesita introducir overrides, parches o una renovación general si la necesidad se resuelve con una actualización compatible acotada.
Herramientas, entorno y autoridad
El Agent Harness organiza el uso de herramientas y el estado de ejecución; el Agent Execution Environment determina recursos disponibles. Una prueba puede pasar en un entorno y no representar otro con binarios o configuración diferentes. Por eso el agente debe indicar dónde ejecutó los checks y qué limitaciones afectan su interpretación.
Las Agent Skills pueden aportar procedimientos reutilizables y los Agent Profiles pueden configurar capacidades o instrucciones. Son opciones de soporte, no requisitos universales. Del mismo modo, MCP, ACP o A2A pueden facilitar herramientas o interacción, pero este workflow no depende de adoptar esos protocolos ni de usar varios agentes.
Los Lifecycle Hooks pueden disparar comportamiento por eventos de ejecución; no definen por sí solos el trabajo de ingeniería. Los Agent Extension Packages distribuyen capacidades que podrían participar en él. Conviene comprobar cuáles están efectivamente activas y qué efectos producen, sin confundir disponibilidad de un paquete con ejecución de un procedimiento ni añadir mecanismos para una tarea que no los necesita.
Las acciones deben respetar Agent Permissions and Approval Boundaries. Editar localmente, publicar un cambio y modificar un sistema externo tienen efectos diferentes. La autorización existente permite continuar trabajo dentro de su alcance; no concede automáticamente autoridad para desplegar cualquier resultado generado. La colaboración incluye decidir prioridades, resolver ambigüedades y discutir riesgos, además de aprobar acciones cuando corresponde.
Entrega para revisión
Efectos y estado durante el cambio
Modificar código y ejecutar herramientas puede producir efectos fuera del diff: datos de prueba, archivos temporales, procesos o llamadas a servicios compartidos. El agente necesita identificar cuáles pertenecen al trabajo autorizado y cuáles requieren otra frontera de ejecución. Workspace Isolation for Coding Agents permite separar copias de fuente, pero no independiza automáticamente esos recursos. Un experimento útil debe poder describir tanto la modificación propuesta como las condiciones en las que se observó su resultado.
Si una acción falla a mitad de camino, no corresponde asumir que no ocurrió nada. Puede haber quedado un archivo parcial, un proceso activo o una operación externa completada aunque el cliente no recibiera respuesta. Antes de repetir conviene comprobar el estado pertinente y evitar ampliar efectos accidentalmente. La recuperación puede consistir en continuar una parte segura, informar una limitación o pedir una decisión cuando cambia el riesgo del encargo.
La entrega debe conservar también lo que no llegó a realizarse. Una propuesta de actualización no es una actualización aplicada; un comando preparado no es una ejecución. Esa precisión permite revisar y continuar el trabajo sin repetir acciones por error ni atribuir resultados a una versión que todavía no existe.
La entrega debería explicar el comportamiento resultante, el motivo del cambio y la evidencia obtenida. AI-Assisted Test Generation y AI-Assisted Code Review pueden aportar piezas, pero código generado no equivale a código verificado. Tampoco una afirmación de “terminado” convierte una implementación en aceptada. El tratamiento completo de verificación pertenece a su ámbito específico.
Los Development Context and Execution Records conservan decisiones, comandos realmente ejecutados, resultados fallidos y dudas pendientes. Conviene informar una comprobación omitida en vez de describirla como implícita. Un resumen breve y preciso permite al revisor concentrarse en el cambio y sus límites sin reconstruir toda la sesión.
Un coding-agent workflow organiza actividades de desarrollo con participación de agentes. Agentic Workflow Patterns describe formas reutilizables de control o coordinación del sistema agente. Se pueden combinar de distintas maneras, pero implementar una funcionalidad no exige un patrón determinado ni ejecución multiagente. El criterio final sigue siendo el trabajo de ingeniería realizado y la evidencia disponible sobre él.
Fuentes
- Semantic Versioning 2.0.0: convención de versionado citada; las decisiones de mantenimiento y los límites de la evidencia se desarrollan aquí como criterio de ingeniería.