¿Existen herramientas que ataquen el AST directamente para refactors rápidos con IA?
Un refactor pequeño que antes se resolvía en dos clics desde el IDE ahora puede hacer que el agente "dé vueltas" leyendo todo el código como prosa. MCPs orientados al AST, como Serena, prometen atajar ese rodeo.
La pregunta real
Un refactor pequeño y muy concreto —extraer un método, renombrar un parámetro, mover un campo del modelo de dominio— antes se resolvía en dos clics desde el IDE con "Extract Method" o "Rename Symbol". Al pedírselo hoy a un agente de codificación en lenguaje natural, muchas veces el agente se pone a "dar vueltas": explora archivo por archivo, lee el código entero como si fuera prosa, y consume bastantes más tokens y tiempo de los que el cambio realmente necesitaba. Esto no habla de migraciones grandes de arquitectura, sino de operaciones pequeñas y mecánicas.
¿Existen herramientas (MCPs) que ataquen directamente el AST del código en lugar de leerlo línea a línea como texto, para que este tipo de refactor sea rápido de nuevo?
Por qué el agente "da vueltas" leyendo prosa
Por defecto, un agente conversacional trata el código como texto: lo lee token a token, razona sobre él en lenguaje natural, y para localizar todos los usos de un símbolo tiene que ir explorando archivo por archivo con búsquedas de texto. Eso es exactamente lo que hacía un IDE antes de tener refactors nativos — solo que ahora ese trabajo de exploración lo paga un LLM en tokens, no un motor de análisis estático en milisegundos.
Herramientas como Serena, un MCP orientado precisamente a esto, exponen al agente operaciones sobre el árbol de sintaxis (AST) del proyecto: encontrar todas las referencias reales a un símbolo, renombrarlo de forma consistente, extraer un fragmento a una nueva función. En vez de que el agente infiera esas relaciones leyendo prosa, las obtiene ya resueltas del analizador estático — el mismo tipo de índice que usa un IDE por debajo, pero expuesto como herramienta que el agente puede invocar.
Lo que se gana — y lo que todavía no está resuelto
El beneficio esperado es claro: para refactors mecánicos y acotados, delegar la localización de referencias al AST en vez de a una lectura completa del repositorio debería reducir drásticamente el consumo de tokens y el tiempo de respuesta, devolviendo a este tipo de cambio la agilidad que tenía con un IDE clásico.
Con matices. Para un refactor real de mayor alcance (por ejemplo migrar una aplicación consolidada a otra plataforma), el enfoque que sigue funcionando de forma probada es otro: definir todo mediante reglas explícitas — qué mantener, qué formato seguir, qué simplificar — antes de tocar código, en lugar de confiar en que un MCP de AST resuelva sin más un cambio de esa envergadura. Requiere más tiempo de preparación, pero es el enfoque que hoy se domina con garantías.
Cuándo importa este tipo de herramienta
Un riesgo adicional al dejar demasiado margen a un agente en un refactor —tenga o no soporte de AST— es la sobre-ingeniería: sin restricciones claras, un LLM tiende a añadir herramientas, capas o funcionalidades que nadie pidió. Por eso conviene combinar cualquier MCP de este tipo con reglas que acoten el alcance exacto del refactor, y con una forma de medir el "coste en tokens" de cada enfoque para comparar cuál compensa realmente en la práctica.
En definitiva: para refactors pequeños y mecánicos (extraer un método, renombrar, mover un campo), un MCP orientado al AST puede devolver la velocidad perdida. Para refactors grandes y con decisiones de diseño reales, seguir dependiendo de reglas explícitas bien escritas sigue siendo, hoy, la apuesta más segura.
Resumen rápido
- Por defecto un agente lee el código como prosa, lo que hace lentos y costosos los refactors mecánicos pequeños.
- MCPs orientados al AST (como Serena) exponen operaciones ya resueltas por un analizador estático, evitando que el agente tenga que inferirlas leyendo todo el repositorio.
- Para refactors grandes con decisiones de diseño, definir reglas explícitas sigue siendo el enfoque más fiable frente a delegarlo sin más en la IA.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.