shadcn/improve alcanza 10.000 estrellas: un modelo potente planifica y los baratos editan el código

Pagar por el modelo más inteligente para que renombre una variable en cuarenta archivos es como pedirle al arquitecto jefe que cargue ladrillos. El repositorio shadcn/improve propone repartir los papeles: piensa el modelo caro, trabajan los baratos.

Qué se sabe del proyecto

shadcn/improve entró en el top diario de GitHub Trending: +333 estrellas en un día y 10.415 en total. Su autor es shadcn, conocido por la biblioteca shadcn/ui, lo que explica parte del interés. La descripción cabe en una línea: usar el modelo más capaz para auditar una base de código y escribir planes que ejecutarán modelos más baratos.

Una salvedad importante. En la fuente solo hay esta descripción y las estadísticas. No se indica el lenguaje del repositorio y no hemos visto el README. Se desconoce qué comandos, formatos de plan y agentes se admiten, y no vamos a especular. Analizamos el patrón en sí, no una implementación concreta.

Cómo funciona, con un ejemplo

Imagina un proyecto en el que 40 componentes usan una forma obsoleta de trabajar con formularios. El modelo potente lee todo el código una sola vez: encuentra repeticiones, detecta dependencias poco evidentes y genera una lista de tareas. Por ejemplo: «en el archivo A, sustituir el hook antiguo por el nuevo, actualizar el test, no tocar el archivo B». Cada punto es autosuficiente y no requiere conocer los demás.

Después, cada punto pasa a un modelo barato. No necesita entender la arquitectura de todo el proyecto: tiene una tarea acotada, límites claros y un criterio de finalización comprensible. En esas condiciones es más difícil equivocarse, y una pasada cuesta bastante menos que el mismo volumen de trabajo hecho por un modelo estrella.

La lógica es simple. La parte cara del trabajo es entender y elegir qué cambiar exactamente. La ejecución a partir de una receta lista es mecánica. Muchos equipos ya lo hacen a mano: piden a un modelo de primera línea que redacte un plan en markdown y se lo pasan a un modelo más sencillo. A juzgar por la descripción, shadcn/improve intenta convertir este truco en un proceso repetible, para no tener que montarlo desde cero en cada proyecto.

Qué hacer con esto

Incluso sin instalar el repositorio, puedes probar la idea con tu código:

• Toma un módulo y pide a un modelo potente que elabore un plan de refactorización sin tocar una sola línea de código.
• Exige puntos atómicos: un archivo o una comprobación, y una condición explícita de «hecho».
• Haz que el juez sean los tests, el linter y el tipado, no el propio modelo.
• Haz las cuentas: compara el coste del plan más la ejecución con una pasada completa del modelo estrella.

Limitaciones

Las estrellas miden interés, no son prueba de calidad. 333 en un día indican que la idea ha enganchado, pero no que la herramienta sea fiable en bases de código reales.

El propio enfoque tiene puntos débiles. Un error en el plan se multiplica en todas las ejecuciones: si la auditoría se equivoca, los modelos baratos harán con esmero lo incorrecto. No siempre será posible meter una base de código grande entera en el contexto del modelo potente, así que habrá que dividir la auditoría en partes y vigilar que no se contradigan. Y los puntos del plan que dependen unos de otros se reparten mal en tareas paralelas.

La conclusión principal para la práctica no depende del destino de este repositorio: separa «decidir qué cambiar» de «cambiarlo». Lo primero es caro y se necesita pocas veces; lo segundo es barato y se necesita a menudo. Sigue de cerca shadcn/improve, pero por ahora considéralo una propuesta notable de un buen patrón, no una herramienta lista para producción.