За 3 часа и 250 рублей можно собрать систему, которая сама ходит по репозиториям, ищет проблемы и складывает замечания в Issue. Именно к такой схеме пришёл автор колонки на Habr / Карьера, описывая, как из скептика по отношению к LLM он постепенно превратился в человека, для которого ИИ-ассистент разработчика уже не игрушка, а рабочий слой поверх обычной инженерной рутины.
Текст не про очередной список промптов и не про магию «нажмите кнопку — получите продукт». Скорее это честный разбор четырёх этапов, через которые проходит разработчик, когда пытается встроить генеративный ИИ в повседневную работу: от чата «как замена Stack Overflow» до постоянного агента с памятью, cron-задачами и доступом к серверу. Для русскоязычной IT-аудитории здесь важен не пафос, а практический вывод: меняются не только корпоративные процессы, но и устройство личных проектов, где раньше всё держалось на отложенных задачах, нехватке времени и собственном упрямстве.
От чат-окна к рабочему инструменту
Первый этап, по версии автора, многим знаком до боли. Чаты с LLM сначала выглядят эффектно, но довольно быстро упираются в простой потолок полезности. Вопросы, ответы, копипаст между IDE и браузером, повторная загрузка контекста в каждом новом диалоге — всё это скорее ускоряет поиск справки, чем меняет саму разработку. Автор честно признаёт: на старте он увидел в таких инструментах лишь более быструю альтернативу Stack Overflow. Не бесполезную, но и не такую, ради которой нужно срочно переписывать привычки.
Сдвиг случился позже, когда на рынок массово пришли агентные сценарии: ассистенты внутри редакторов, полуавтоматические цепочки действий, генерация и запуск кода прямо в рабочем окружении. Автор перечисляет несколько инструментов, которые попробовал сам: OpenCode, Cline в связке с Visual Studio Code и Yandex Code Assistant. На этом уровне ИИ-ассистент разработчика уже перестаёт быть «говорящей документацией» и начинает брать на себя куски реальной работы: писать код, запускать тесты, смотреть логи, исправлять огрехи после линтера, изучать незнакомый фреймворк.
Самый показательный эпизод в статье связан с пет-проектом на Go. Автор переделал TUI-инструмент в GUI-приложение, потому что оно пригодилось знакомым, далёким от IT. По его словам, Claude Sonnet и Haiku помогли быстро разобраться с Fyne и прикрутить интерфейс к уже существующей бизнес-логике. Ключевая мысль здесь не в том, что человек «больше не нужен». Наоборот: разработчик подчёркивает, что мог бы сделать всё сам, но точно не за четыре часа. Разница не в способности, а в цене переключения внимания и в скорости прохождения скучных участков, которые обычно месяцами лежат в бэклоге «на потом».
Правда, и тут без ложки дёгтя не обошлось. Агентный режим пока требует постоянного присмотра: нужно выдавать разрешения на действия, контролировать, что именно меняется в проекте, и не терять нить происходящего. Формально можно запустить процесс и пойти за кофе, но психологически это работает плохо: либо агент зависнет в ожидании подтверждения, либо устроит локальный апокалипсис в репозитории. В такой модели машина вроде бы трудится, а человек становится не архитектором, а дежурным микроменеджером. Это ускоряет отдельные задачи, но утомляет постоянными переключениями контекста.
Почему память и автоматизация важнее красивых демо
Дальше автор описывает переломный для себя момент: проблема оказалась не только в качестве кода, а в отсутствии памяти между сессиями. Каждый новый диалог с моделью начинается как плохой понедельник: сначала снова объясни, кто ты, над чем работаешь, какие у проекта ограничения и что уже пробовали раньше. На этом фоне для него важным открытием стал Hermes Agent — проект, который добавляет персистентную память и даёт модели возможность дольше удерживать контекст пользователя, привычек и повторяющихся задач.
В статье Hermes Agent показан не как безошибочный цифровой дворецкий, а как сырой, но уже полезный слой автоматизации. Автор рекомендует разворачивать его на собственном сервере с оговорками по безопасности и отдельно упоминает риск уязвимостей вроде BadHost. Зато на выходе получается совсем другой класс взаимодействия: интеграция с Telegram, cronjob-ы для периодических задач, автоматическая сборка новостей, генерация «скиллов» под повторяющиеся сценарии, а главное — возможность писать код, запускать скрипты и что-то конфигурировать не в разовом диалоге, а в более устойчивом режиме. Для многих команд это и есть недостающий переход от эффектной демонстрации к инфраструктурному инструменту.
На следующем шаге автор сделал то, что рано или поздно попробуют многие техлиды и одиночные разработчики: поручил агенту регулярно сканировать собственные репозитории на предмет code review, архитектурных замечаний и security review, а результаты складывать в Issue. Настройка, по его оценке, заняла 3 часа и обошлась в 250 рублей. Сумма и срок здесь важнее любых абстрактных рассуждений: порог входа в такую автоматизацию уже настолько низкий, что спор «нужно ли вообще пробовать» звучит всё менее убедительно.
При этом автор сознательно не дал системе право сразу чинить код. Причина предельно инженерная: доверие к автоматике пока ограничено, а полный автопилот слишком легко превращается в авгиевы конюшни из бессистемных правок. Поэтому агенту отвели роль настырного коллеги, который замечает подозрительные места, следит за дубликатами и приносит замечания в удобную точку разбора. Даже такой осторожный режим, впрочем, быстро показал побочные эффекты: за пару недель накопилось около шести десятков Issue, которые всё равно нужно просмотреть человеку. И вот здесь к разговору о productivity наконец добавляется разговор о фильтрации шума. Проблема больше не в том, может ли ИИ найти замечание, а в том, как встроить этот поток замечаний в реальный рабочий процесс так, чтобы команда не утонула в полезных, но несрочных сигналах.
Из этой истории вытекает довольно неприятный, но трезвый вывод для рынка. Следующий этап конкуренции в AI-инструментах для разработки, похоже, будет не про ещё один чат с более бойкой моделью. Ставка смещается в сторону памяти, автономности, фоновых задач, интеграции с репозиториями и нормального контроля доступа. ИИ-ассистент разработчика всё меньше похож на умный поисковик и всё больше — на операционный слой, который постоянно живёт рядом с кодовой базой. Вопрос теперь не в том, заменит ли он инженера, а в другом: кто научится задавать ему границы, чтобы не получить вместо помощника круглосуточного стажёра с root-доступом и без чувства меры.