Немного насчет - «AI-агенты сделают разработку самоподдерживаемой».
Прогнал spec-driven агентный пайплайн на нескольких проектах, и картина каждый раз одна: узкое место, где тормозится разработка, не исчезает, оно сдвигается.
Для примера, один из таких полигонов - небольшой проект, приложение для книг на виртуальных полках, начинался как пет-проджект жены. В нем можно толкать агентные воркфлоу сильно дальше, чем я бы рискнул на нагруженном проде.
Как это работает на практике:
Я задаю намерение. Claude Code набрасывает спеку, я проверяю/правлю, дальше по необходимости рулю текстом или голосом. Агенты исполняют, направление держу я.
Claude Code и Claude Design пишут код и UI по спекам (DDD, TDD, Trophy Testing), ревью на каждом изменении.
AI гоняет regression и пишет E2E через MCP Playwright, прод-ошибки возвращаются через MCP Sentry.
Периодически Claude Code сам делает выводы в insights-inbox - где споткнулся, какие паттерны зашли. Еженедельная рутина обрабатывает их вместе с настройками агента, даёт предложения сразу по всем проектам (и user-level). Так что правила самого агента со временем становятся точнее.
Что не автоматизируется - это решение, что вообще нужно строить, и отслеживание, когда агент тихо уходит в сторону. Зелёные тесты не равны корректности: агент с большей вероятностью напишет проходящий тест, который проверяет не то.
Так что главная работа теперь - намерение и отлов дрейфа в сторону от этого намерения.
Контур не замыкается сам на себя. Он просто поднимает человека выше, на слой, где решаешь, что строить и справилась ли с этой задачей машина. Этот слой в ближайшем будущем не исчезнет, и это одна из интереснейших вещей. Инженерия не пропала - она стала даже сложнее написания кода.
А без сильного инженерного подхода проекты на AI-агентах расползаются по швам.
PS: тот самый проект book-shelves.ru: TypeScript, React, Vite, Tailwind, Node.js, NestJS, PostgreSQL, MinIO S3, Vitest, Testcontainers, Playwright, Sentry, Caddy, Nginx
Комментарии (5)

WinLin2
23.06.2026 23:03Недавно начал использовать ии - бесплатный gemini от google. Простые вещи делает быстро и хорошо, например пишет функции на разных языках (perl, tt, js, sql, bash), помогает css. Вставляет свои комментарии и каждый раз разные. Существует проблема выбора компонентов, особенно когда тема тебе незнакомая. Как-то 3 дня ии водил по разным библиотекам js, строил многоэтажные обходы своих же предложений. Интпресно, что ии в разных сессиях может сам себя опровергать, как строители - "кто тут криворукий наделал" :)
gerbert_MX
гребаный нейротекст!
хабру пора уже прикрутить кнопку к постам, которая будет использовать LLM и кратко давать вывод по "статье"
я несколько раз перечитал и не понял, что двигает, куда двигает, что там вообще с приложением жены
yastcher Автор
Не, от нейронки был совсем полностью противоположный тезис, когда через агента решил сформулировать кратко процесс разработки (то есть был тезис, что "разработка через агентов сама становится самоподдерживаемой системой").
Далее результат скормил другой нейронке, еще раз скормил все документы с флоу и кратко описал процесс, и дал задание покритиковать, убрать хайпожерство.
Затем еще раз с 3-й - оставить лишь важное)
И так еще несколько раз, с постоянными правками по пути, пока не получилось что-то, что как я увидел, можно использовать как заготовку. И почти полностью переделал
Главная мысль статьи была в том, что "делай хорошо, плохо не делай" не работает, даже при продвинутых зацикленных процессах с обратной связью. (И она достаточно банальна, но все равно часто вижу людей, кто пытается в этом сомневаться).
То есть без намерения человека и его постоянных усилий в удержании этого намерения - ничего не выйдет. Но даже при сильном намерении без инженерных скиллов все развалится.
Dhwtj
Да, сначала намерения. И надо удерживать (ся) чтобы не перескочить к планированию и разработке раньше, чем понятно что делать. Ближе к водопаду, итерации только если необходимо
У меня 3 слоя до планирования
Намерения. Бизнес цели, приоритеты. Тогда при развилках понятно куда идти.
Функциональные и нефункциональные требования. Ограничения. Тут и далее независимо и постоянно вопросы архитектуры.
Технические спецификации. Сценарии использования и соответствующие им тесты. Контракты / спецификации апфронт. Полный реестр спек до планирования
План. Важно первым продумать элементы, изменение которых будет влиять на множество частей. Часто agile spike
Реализация... Удерживаем унифицированные решения без велосипедов. Удерживаем code style
sunnybear
Это просто люди, по умолчанию, пишут не сильно лучше нейросетей :)