chemx: chequeos AST locales para generar prompts de refactor cirúrgicos
La herramienta open source detecta violaciones arquitectónicas en local en 10 ms y compila un prompt estructurado para que el modelo solo devuelva el diff.
Un post en el foro de ingeniería de prompts defiende una idea sencilla: no tiene sentido pagarle a un LLM para que busque deuda técnica en un repositorio cuando un analizador estático local puede hacer ese trabajo antes y más barato. La herramienta se llama chemx, es open source, se ejecuta con npx chemx audit y lo que produce no es un informe para leer, sino un prompt de refactor ya montado y copiado al portapapeles.
El autor parte de una queja conocida por cualquiera que haya metido un repositorio entero en la ventana de contexto: pedir "revisa y limpia este código" quema tokens, invita a cambios inventados y da un resultado distinto cada vez que lo lanzas. Su propuesta invierte el orden. Primero pasan chequeos sobre el AST que marcan violaciones concretas —cápsulas de más de 100 líneas, condicionales booleanos sin componer, archivos que acumulan tipos— y esas violaciones rellenan una plantilla rígida.
La plantilla es esta, tal cual:
[ROLE]: Systems Architect
[TASK]: Refactor target file to satisfy single-responsibility capsule rules.
[TARGET]: src/components/UserProfile.vue
[CONSTRAINTS]:
- Max file length: 100 lines.
- Extract state into src/components/UserProfile.controller.ts.
- Convert multi-clause conditionals into 2-stage atomic booleans.
- Output ONLY the unified diff. Do not alter untouched symbols.
El punto interesante no es el texto en sí, sino de dónde salen los valores. El rol, el fichero objetivo y cada restricción los escribe el analizador, no una persona. Eso hace que la misma violación genere siempre la misma estructura de prompt, que es lo contrario de la lotería habitual cuando se le pide criterio a un modelo.
El ahorro y sus límites
El autor cifra el escaneo en 10 ms y 0 dólares, y sostiene que así se reserva el presupuesto completo de tokens para la generación de código. También argumenta que acotar las restricciones evita que el modelo reescriba símbolos que funcionaban y estaban fuera de alcance.
Hay que poner eso en contexto. El proyecto vive en GitHub y la documentación de arranque está en su propio sitio. La prueba de concepto que se cita —un módulo que pasa de una nota D a una A+— son dos discusiones abiertas por el propio autor en su organización, no una medición de un tercero. No hay comparativa contra otras herramientas de análisis estático ni contra el enfoque de mandar el repo a un modelo. La cifra de ahorro es suya.
Aun así, el patrón tiene miga para quien mantiene código ajeno: la parte determinista la resuelve la máquina y el modelo solo redacta el diff bajo unas reglas que no puede negociar. Si eso escala a repositorios grandes o si el AST se atraganta con lenguajes menos convencionales que TypeScript es lo que falta por ver, y para eso conviene leer el kit de arranque antes de meterlo en un pipeline.