Tag: vibe-coding

Как валидировать проектные требования перед передачей ИИ-агенту

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

Живой разработчик получает тикет «ускорьте каталог» и идёт спрашивать. В курилке, в личку, на дейли. Он додумывает: знает, что каталог у нас на PostgreSQL, что прошлый раз сломались на импорте, что «ускорить» в этой компании значит p99, а не среднее. Половину требований он достраивает из доменного опыта команды, и никто этого не замечает.

ИИ-агент получает тот же тикет и, если в процессе нет шага уточнения, начинает писать код по буквальному тексту задачи.

Через три недели на ретро звучит «ИИ не тянет архитектуру». Это неправда. Он реализовал наиболее вероятную интерпретацию неполного описания.

Continue reading “Как валидировать проектные требования перед передачей ИИ-агенту”

ИИ — не просто кодер: как AI покрывает весь жизненный цикл разработки ПО

«ИИ — просто очень быстрый стажер-кодер» — это точное описание первого этапа. На втором ИИ становится исполнителем мышления на каждом шаге SDLC: от clarify-диалога с заказчиком в Jira до мультиагентных связок, которые ловят, исправляют и верифицируют сами себя.

Есть один популярный аргумент против AI в разработке: «Написание кода — это лишь малая часть SDLC. Есть ещё интервью с заказчиком, формулирование требований, архитектурное проектирование, тестирование, мониторинг. ИИ — это просто очень быстрый кодер, а не думающий участник команды».

Этот аргумент справедлив. Для первого этапа освоения инструмента.

На первом этапе человек видит, что AI пишет код — и делает вывод: «ИИ = кодер». Потом замечает, что кодинг — не вся разработка. Делает следующий вывод: «значит, AI не заменит разработку целиком». Логика правильная, но вывод устаревает раньше, чем его успевают произнести вслух.

На следующем витке выясняется, что нейросети прекрасно умеют делать именно то, о чём говорит этот аргумент.

Continue reading “ИИ — не просто кодер: как AI покрывает весь жизненный цикл разработки ПО”

Как сделать eval критерием релиза AI-фичи, а не оценкой «на демо выглядело нормально»

Demo-grade eval одобряет фичу на тех же примерах, что и питч. Дальше прод показывает длинный хвост. Три слоя — regression из инцидентов, distribution diff к снапшоту, human spot-check — и один named owner. Минимальный harness: github.com/dobryakov/eval-harness.

Сделайте качество AI-вывода release-критерием: фиксированный regression из прошлых инцидентов, distribution-diff к снапшоту прошлого релиза (20–50 реальных входов), human spot-check перед первым продом нового вида вывода — и один человек, который подписывает sign-off. Ниже — антипаттерн demo-grade, три слоя методики и минимальный harness, который падает в CI с понятным exit code.

Continue reading “Как сделать eval критерием релиза AI-фичи, а не оценкой «на демо выглядело нормально»”

Как делать профессиональную архитектуру ПО с AI, даже не разбираясь в теме

Без предметной подложки агент выдаёт FTP и CSV и рапортует «готово». Book-as-context — книга как wiki в проекте (рядом с LLM Wiki и book-to-skill): с короткого промпта получаются outbox, очереди, идемпотентность и отказоустойчивость.

Подложите агенту авторитетную книгу по предмету как wiki в репозитории — целиком, с индексом и ссылками, а не разовым вложением файла в диалог. Тогда даже с короткого промпта он проектирует в понятиях первоисточника: очереди, гарантии доставки, идемпотентность, отказоустойчивость. Ниже — приём book-as-context, сквозной пример магазин→ERP и ограничения метода.

Continue reading “Как делать профессиональную архитектуру ПО с AI, даже не разбираясь в теме”