Как я доделал все пет-проекты и работаю с 10 млн строк кода
Подход работает с любыми агентно-ориентированными LLM — DeepSeek, Claude, GLM и т.п.
1. Архитектура — один раз. Фиксирую CJM, бизнес-требования, контракты между компонентами, доменную модель, потоки данных, безопасность. Без бизнес-требований нет системного дизайна. Это фундамент и «память о проекте» для ИИ-агента. Занимает 1–2 недели проб и ошибок.
2. План вместо разрастающихся спецификаций. Спецификации на больших проектах сами становятся проблемой. План не разрастается: выполнил — в архив. Зачем держать спецификацию, если уже есть код? Планирование — самое трудоёмкое: план нужно перечитать несколько раз и убедиться, что нейросеть поняла правильно.
3. Запуск плана. Специальная утилита, написанная на Go берёт последний невыполненный пункт и выполняет его. Обычно хватает одной сессии; иногда каждому пункту нужен свой контекст. Выполнение переживает обрыв сессии и продолжает с последнего невыполненного пункта.
4. Код-ревью — самый затратный этап. Когда план выполнен и тесты зелёные, запускаю 5–9 агентов. Они смотрят код через разные призмы. Результат идёт в агент-синтезатор: убирает дубли и выдаёт список. Потом агенты другой нейросети верифицируют находки. На моих задачах это даёт очень качественный код — сужу как эксперт с 8-летним стажем ревью.
5. Ручная верификация или автопилот. Обычно проверяю руками. В сложных системах писал нейросеть-автопилота, которая проходит по системе и принимает решения по ситуации. Это полезно там, где сложный мир, роли и права, фичи, которые в итоге тестируют конечные пользователи.
PS: Чтобы не собирать промпт для плана вручную из многих источников, я сделал KB — RAG-систему, объединяющую знания из чатов, кода, документации и задач. Первая версия была на LangChain/ChromaDB (Python), потом переписал на Go ради стабильности и скорости. Код: https://github.com/alterfo/kb
А вы как организуете работу LLM-агентов? Что пробовали?
· 20.09
Самое узкое место не в ревью, а в пункте 1: архитектура "один раз" на практике не выдерживает — бизнес-требования меняются, и агент честно строит по устаревшей памяти. Поэтому архитектурные артефакты должны жить не как документы, а как исполняемые проверки: контракт компонентов — это тест, доменная модель — линтер. Когда описание устаревает, падает не документ, а сборка. Пока память проекта не проверяется автоматически, она протухает — вопрос только времени.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 22.09
Давайте посмотрим на эту вашу "практику" детальнее, что именно не выдерживает изменения бизнес-требований? Клиент захотел камин в многоэтажном доме?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён