shadcn/improve набрал 10 тыс. звёзд: сильная модель планирует, дешёвые правят код

Платить за самую умную модель, чтобы она переименовывала переменную в сорока файлах, — всё равно что звать главного архитектора таскать кирпичи. Репозиторий shadcn/improve предлагает развести роли: думает дорогая модель, работают дешёвые.

Что известно о проекте

shadcn/improve вышел в дневной топ GitHub Trending: +333 звезды за сутки и 10 415 в сумме. Автор — shadcn, которого знают по библиотеке shadcn/ui, и это объясняет часть интереса. Описание умещается в одну строку: использовать самую способную модель, чтобы аудировать кодовую базу и писать планы, которые выполнят модели подешевле.

Важная оговорка. В источнике есть только это описание и статистика. Язык репозитория не указан, README мы не видели. Какие именно команды, форматы планов и агенты поддерживаются, неизвестно, и додумывать мы не будем. Разбираем сам паттерн, а не конкретную реализацию.

Как это работает на примере

Представьте проект, где 40 компонентов используют устаревший способ работы с формами. Сильная модель один раз читает код целиком: находит повторы, замечает неочевидные зависимости и выдаёт список задач. Например: «в файле A заменить старый хук на новый, обновить тест, не трогать файл B». Каждый пункт самодостаточен и не требует знать остальные.

Дальше каждый пункт получает дешёвая модель. Ей не нужно понимать архитектуру всего проекта: у неё узкая задача, чёткие границы и понятный критерий готовности. Ошибиться в таких условиях сложнее, а один проход стоит в разы меньше, чем такой же объём работы флагмана.

Логика простая. Дорогая часть работы — это понимание и выбор, что именно менять. Само исполнение по готовому рецепту механическое. Многие команды уже делают это руками: просят флагманскую модель составить план в markdown и скармливают его модели попроще. Судя по описанию, shadcn/improve пытается превратить этот приём в повторяемый процесс, чтобы не собирать его заново в каждом проекте.

Что с этим делать

Даже не устанавливая репозиторий, можно проверить идею на своём коде:

• Возьмите один модуль и попросите сильную модель составить план рефакторинга без единой правки кода.
• Требуйте атомарные пункты: один файл или одна проверка и явное условие «готово».
• Судьёй делайте тесты, линтер и типизацию, а не саму модель.
• Посчитайте деньги: сравните стоимость плана плюс исполнения со сплошным прогоном флагманом.

Ограничения

Звёзды — это интерес, а не доказательство качества. 333 за день говорят, что идея зацепила, но не что инструмент надёжен на реальных кодовых базах.

У самого подхода есть слабые места. Ошибка в плане размножится на все исполнения: если аудит ошибся, дешёвые модели аккуратно сделают неправильно. Большую кодовую базу не всегда получится целиком уложить в контекст сильной модели, значит, аудит придётся резать на части и следить, чтобы части не противоречили друг другу. А пункты плана, которые зависят друг от друга, плохо раскладываются на параллельные задачи.

Главный вывод для практики не зависит от судьбы этого репозитория: разделяйте «решить, что менять» и «поменять». Первое стоит дорого и нужно редко, второе дёшево и нужно часто. Следите за shadcn/improve, но пока воспринимайте его как заметную заявку на хороший паттерн, а не как готовый инструмент для продакшена.