Блогер: чтобы ИИ-агент мог настраивать софт, тот должен быть открытым (Claude Code, нет)

Автор поста (имя в тексте не указано) пять лет назад спрашивал знакомых инженеров, писали ли они программы для себя, почти никто не писал: на кастомный софт уходило слишком много времени, а поддержка старого проекта через год превращалась в мучение. Сейчас, по его словам, ситуация изменилась из-за ИИ-агентов.

Автор описывает два вида промптов, которые снимают эту проблему. Первый: скачать исходники нужной программы, собрать локально и научить агента запоминать, что дальнейшие правки идут через изменение исходников, а не конфигов, с записью причины правки в систему контроля версий. Второй, по его словам более важный: настроить ночную cron-задачу, которая подтягивает апстрим-изменения, переносит на них локальные правки (rebase), проверяет, что всё работает, и заменяет текущую версию. Если сам агент с открытым кодом, оба промпта можно зашить прямо в него как «скилл» (текстовую инструкцию) без программирования. Автор сделал это в своём проекте Shelley, своём собственном ИИ-редакторе: чтобы изменить сам Shelley, преамбула и таймер больше не нужны, достаточно ввести, например, «сделай интерфейс Shelley высококонтрастным».

В качестве рабочего примера автор описывает свой инструмент meat.dev, который он делает последний месяц: тот берёт диффы кода и с помощью LLM убирает из них неважные части, импорты, проверки на nil, обработку ошибок, потому что за последние полгода автор заметил, что модели почти не ошибаются в этой рутине и следить за ней при ревью больше не нужно. У инструмента было два неудобства: автор хотел читать диффы в интерфейсе Shelley, а не в терминале, и не хотел ждать пару минут, пока LLM обработает дифф. Один промпт («встрой meat.dev в Shelley, установи последнюю версию в PATH, запускай обработку коммита в фоне сразу после его создания, добавь переключатель в просмотр диффов Shelley, показывай статус обработки») решил обе проблемы: коммиты стали обрабатываться в фоне ещё до того, как автор возвращался их смотреть. Единственный огрех, агент повесил на кнопку-переключатель эмодзи мяса. Автор отмечает, что аналогичная интеграция в VS Code через API расширений или в vimdiff была бы практически невозможна, там пришлось бы городить отдельный демон и API, потому что точки расширения не той формы.

Отсюда главный тезис: раньше сложному софту имело смысл поставляться с большими системами конфигов, расширений и плагинов, потому что стоимость разработки была высока (пример, ядро Vim, слишком большое и запутанное, чтобы инженер учил его код ради одной галочки «показывать номера строк»); плагинная архитектура амортизировала эти затраты на множество пользователей. Теперь стоимость изучения кода и внесения правки резко упала: топовый агент обычно добавляет фичу для одного пользователя за один проход, а вместо тщательного код-ревью для однопользовательского софта достаточно проверить, что «вроде работает». По мнению автора, это относится и к небольшим командам: незачем покупать сложно настраиваемый таск-менеджер, CMS или CRM и подгонять под него команду, если можно собрать только нужные функции из типовых блоков. Собственный блог автора, тоже такой самодельный софт, написанный на Shelley поверх библиотеки Tiptap: собрать его агентом оказалось проще, чем настраивать готовый продукт.

Вывод автора: чтобы конечный продукт сегодня был удобен, его нужно уметь персонализировать, а значит, нужен исходный код. Ту же технику, что применена к Shelley, можно применить и к другим открытым агентам вроде Pi (автор даже задаётся вопросом, зачем Pi вообще собственная система расширений, если «исходный код и есть система расширений»), и, с бо́льшими затратами токенов, к Codex, тоже открытому агенту. А вот с Claude Code это не работает: он закрытый, персонализировать его тем же способом нельзя, и остаётся надеяться, что штатные хуки Claude Code покрывают то, что нужно пользователю; если нет, совет автора один: переходить на агента, который позволяет себя настраивать.

Ключевые факты

• Автор блога описывает два промпта, которые сделали персонализацию софта тривиальной: сборка из исходников с фиксацией правок в системе контроля версий и ночная cron-задача, которая подтягивает апстрим-изменения и переносит на них локальные правки.
• На своём ИИ-редакторе Shelley автор зашил оба промпта в виде скилла: изменить сам Shelley теперь можно одной короткой фразой вроде «сделай интерфейс высококонтрастным».
• Пример из практики: инструмент meat.dev (убирает неважные строки из диффов кода через LLM) был встроен в Shelley одним промптом, с фоновой обработкой коммитов и переключателем в интерфейсе; аналогичная работа с VS Code или vimdiff была бы, по словам автора, крайне тяжёлой.
• Тезис автора: раз агенту для персонализации нужен исходный код, инструменты разработки обязаны быть с открытым кодом; та же техника применима к открытым агентам Pi и Codex.
• Закрытый Claude Code, по словам автора, выпадает из этой схемы: персонализировать его так же нельзя, остаётся полагаться на его штатные хуки настройки.

Почему это важно

Автор утверждает, что ИИ-агенты меняют экономику доработки софта: раньше кастомизация окупалась только для широко используемых программ, поэтому производители вкладывались в системы плагинов и конфигов, амортизируя расходы на множество пользователей. Если агент почти бесплатно правит исходный код и сам синхронизирует локальные изменения с апстримом, необходимость в плагинных архитектурах, по мнению автора, отпадает, но только для софта с открытым кодом, потому что агенту физически нечего редактировать в закрытом бинарнике.

Кому это важно

Разработчикам и инженерам, которые уже используют ИИ-агентов для правки чужого кода под себя; авторам и вендорам инструментов разработки, выбирающим между открытой и закрытой моделью распространения; небольшим командам, которые решают между покупкой настраиваемого готового продукта (таск-менеджера, CMS, CRM) и сборкой нужных функций агентом с нуля.

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

Автор описывает конкретный рецепт: агенту дают исходники нужной программы и просят зафиксировать в его памяти, что дальнейшие изменения идут через правку исходников с записью причины в git; отдельно настраивают ночную cron-задачу, которая подтягивает апстрим, переносит на него локальные правки, проверяет работоспособность и подменяет текущую сборку. Если сам агент открытый, эти два промпта можно один раз оформить как «скилл», текстовую инструкцию, которая ложится поверх агента и избавляет от необходимости каждый раз объяснять процесс заново, как это сделано для Shelley.

Можно ли доверять

Материал, личное мнение автора анонимного (в тексте не названного) блога blog.exe.dev, построенное на его собственном опыте с двумя его же проектами, Shelley и meat.dev. Независимой проверки, метрик использования или мнений сторонних экспертов в тексте нет, это единичный кейс и рассуждение на его основе, а не измеренный результат.

Риски и подводные камни

Автор сам оговаривается, что для «серьёзных систем» продолжает читать код перед отправкой в прод, рецепт «вроде работает» он считает приемлемым только для однопользовательского софта. Даже в его собственном примере автоматика допустила огрех, агент повесил на кнопку-переключатель эмодзи мяса вместо осмысленной подписи. А для закрытых агентов вроде Claude Code вся описанная схема персонализации попросту недоступна, пользователь заперт в рамках официальных настроек и хуков вендора.

«Для однопользовательского софта тщательное код-ревью часто можно заменить вопросом «вроде работает?».»

— автор поста в блоге blog.exe.dev