На прошлой неделе снова съездил на крупнейшую диджитал-конференцию Boost 2026.
В этом году она проходила не в Сколково, а в МГТУ имени Баумана. Эта площадка мне понравилась больше: она компактнее, удобнее, меньше ненужной беготни.
Правда, и сама конференция в этом году стала поменьше: участников и спикеров было меньше. Хотя спикеров всё равно набралось около 70, а участников — несколько сотен. Работали три потока: управление бизнесом, маркетинг и разработка.
Если в прошлом году из пяти потоков только некоторые доклады касались ИИ, то в этом году вся конференция была посвящена искусственному интеллекту и его влиянию на диджитал-отрасль.
С получением новых инсайтов была одна сложность: некоторые спикеры занимаются темой ИИ меньше, чем я. Но, несмотря на это, я записал около 30 идей и уже начал кое-что внедрять. Результаты мне очень нравятся, поэтому сегодня поделюсь одной штукой, которую уже внедрил и теперь всем советую. По отзывам тех, кто раньше с ней не сталкивался, им она тоже понравилась.
Называется SDD — Spec-Driven Development, или разработка на основе спецификаций.
Суть в том, что перед написанием кода мы описываем, что именно должно получиться: требования, поведение системы, важные сценарии. Затем ИИ-агент опирается на эту спецификацию при написании и проверке кода.
Спецификации существовали и до ИИ, но с появлением агентов такой подход стал особенно полезен: у агента появляется понятный ориентир, а у нас — возможность заранее заметить неточности и проверить результат.
Я уже давно занимаюсь агентной разработкой и самостоятельно пришёл к похожему принципу: сначала пишу документацию, а потом агент пишет по ней код. Но в некоторой степени это было изобретение велосипеда: я не посмотрел, что происходит в сообществе, и упустил, что для такого подхода уже есть готовые инструменты.
Один из них — OpenSpec на GitHub.
Как OpenSpec помогает в работе?
- Проверяет документы. В OpenSpec есть встроенная проверка, которая следит за соблюдением структуры спецификаций и обнаруживает некоторые конфликты при внесении изменений в существующие спецификации.
- Помогает проверить код по требованиям. OpenSpec даёт агенту инструкции для проверки реализации: агент сопоставляет написанный код со спецификацией, смотрит, выполнены ли задачи и есть ли тесты для описанных сценариев.
- Помогает тестировать. Сам OpenSpec не является системой тестирования, но спецификация показывает, что нужно проверить. Опираясь на неё, агент может писать и запускать тесты с помощью инструментов проекта.
- Архивирует завершённую работу. Актуальные требования к готовой функции остаются в основной спецификации, а документы выполненного изменения переносятся в архив. Архивирование помогает управлять контекстом и сохранять историю: готовую функцию можно менять в дальнейшем, но при работе не приходится закапываться в кучу старых планов и выполненных задач.
Причём для меня польза стала очевидной почти сразу. Я начал переводить документацию по своей игре в формат OpenSpec, и в процессе обнаружилось 27 противоречий.
При этом по этой документации уже написано около 80% игры. Значит, часть противоречий вполне могла перейти и в код. Теперь есть возможность их разобрать и исправить.
На мой взгляд, это очень мощная штука. Даже если бы это была единственная идея, которую я забрал с конференции, поездка уже стоила бы того.
В ближайшие две недели буду максимально быстро внедрять остальное из того, что записал. Есть правило 72 часов: если не начать реализовывать пришедшую идею сразу, её легко отложить в долгий ящик и так никогда к ней и не вернуться.
Понятно, что за 72 часа всё не сделать, поэтому отвожу себе две недели. А в процессе буду писать посты и делиться результатами новых внедрений.
Так что посещаем профильные конференции и идём с ИИ до результата. 🚀
