Кажется, мой процесс разработки окончательно изменился.
Раньше я думал в первую очередь про spec-driven development. Хорошая спецификация, понятная архитектура, потом реализация.
Сейчас всё больше ловлю себя на другом подходе. Если попробовать его описать, то получится что-то вроде test-driven product development.
Мой пайплайн сейчас выглядит примерно так:
- Бизнес-проблема. Зачем вообще существует эта фича? Какую проблему она решает? Какие метрики должны измениться?
- Спецификация. Что именно мы строим и как это должно работать.
- Пользовательские сценарии. Не функции системы, а реальные действия пользователя.
- End-to-end тесты. Каждый сценарий превращается в автоматический тест. Пока он не проходит — задача считается незавершённой.
И только после этого начинается разработка.
Самое интересное, что с появлением AI у меня поменялось не только начало процесса, но и моя собственная роль.
Раньше я постоянно смотрел промежуточный результат.
Агент что-то написал.
— «Нет, не так.»
Переделал.
— «Опять не так.»
И так по кругу десятки раз.
В какой-то момент я понял, что это очень дорогой способ работы. Я трачу время не на инженерные решения, а на бесконечное ревью промежуточных состояний.
Теперь я практически не вмешиваюсь в процесс реализации.
Моя работа — спроектировать систему, определить пользовательские сценарии и описать ожидаемое поведение. Дальше агенты могут переписывать код хоть двадцать раз — мне всё равно, пока они не пройдут все проверки.
Конечно, это не означает отсутствие контроля. Архитектурные агенты следят за структурой проекта, другие проверяют качество кода, линтеры, тесты и всё остальное. Но я подключаюсь только в двух точках.
- В начале — когда принимаются архитектурные решения.
- И в конце — когда прохожу UAT и отвечаю на вопрос: решает ли продукт ту проблему, ради которой вообще начиналась разработка?
Наверное, именно так я сегодня представляю себе работу продуктового инженера в эпоху AI.
Чем меньше времени ты тратишь на проверку каждой строчки кода, тем больше можешь уделить архитектуре, пользовательским сценариям и качеству конечного решения.
Кстати, именно такой подход мы будем подробно разбирать на Vibe Аналитике. Не с точки зрения “как написать промпт”, а с точки зрения того, как перестроить весь процесс разработки, когда код всё чаще пишет не человек, а агент.
Дискуссия