Разработчика призвали работать с ИИ по спецификациям — и вот что вышло
Разработчика призвали работать с ИИ по спецификациям — и вот что вышло Автор, разработчик компании Haulmont с опытом с 2008 года, рассказывает: сначала его компания «мотивировала» всех пользоваться ИИ, затем — кодинг-агентами (программами, которые сами пишут код по заданию), а теперь призывают активно использовать OpenSpec. Он сам давно работает с ИИ — с эпохи GPT-3 — и не считает себя противником нового, но внедрение идёт «сверху». В статье он показывает на учебном примере, как встроить OpenSpec в уже отлаженный процесс и не сломать его. До OpenSpec его процесс выглядел так: приходит задача от бизнес-аналитика, он с помощью ИИ-агентов уточняет требования и готовит макеты интерфейса, агент составляет план работ, автор проверяет план, затем реализация идёт в отдельной копии кода (worktree — изолированная ветка проекта), после — проверка кода, тесты и обычное ревью командой. Инструменты: Claude Code и Codex по подписке $100 каждый, OpenCode для экспериментов, всё подключено к его IDE (среде разработки) через плагин компании. OpenSpec — открытый фреймворк (набор готовых деталей, из которых собирают программу) для разработки по спецификациям: он помогает работать со спецификациями на всём их жизненном цикле. Спецификация — документ, где зафиксировано, что система должна делать и по каким критериям это проверяется. Есть два вида: «main specs» — описание текущего поведения системы, источник истины, и «delta specs» — только разница для конкретной доработки. Требования и сценарии приёмки OpenSpec генерирует сам. Любая доработка идёт циклом из трёх этапов. Propose: агент читает существующие спецификации и код, готовит предложение, технический дизайн и план задач; автор проверяет артефакты и вносит правки. Apply: автор коммитит (сохраняет) согласованную спецификацию, создаёт отдельную копию кода и очищает сессию агента — тот пишет код по плану. Archive: спецификации синхронизируются с «источником истины» — иначе следующая задача начнётся с устаревшей картины, — и изменение архивируется. Проверки автор сохранил прежние: тесты, контроль стиля и архитектуры, покрытие тестами, мутационное тестирование PITest (проверка, что тесты действительно ловят ошибки), а также ревью кода другим агентом — если писал Claude Code, проверяет Codex, и наоборот. Сценарии проверки всей системы целиком, которые нельзя автоматизировать, проходят вручную или через тестировщиков. Итог автора: OpenSpec не стал революцией, а лишь формализовал то, что он и так делал, поэтому внедрение «сверху» оказалось не таким болезненным, как он ожидал. Главный плюс — пропал страх начинать новую сессию агента посреди работы: весь нужный контекст уже зафиксирован в документах. Минус — сами спецификации читать непросто: рядом могут стоять бизнес-требование и деталь уровня типа колонки в базе данных, а уместность формата Gherkin (запись сценариев в виде «дано — когда — тогда») он пока не решил. Цифр экономии времени или денег автор не приводит. Источник: https://habr.com/ru/companies/haulmont/articles/1085318/