Но важный нюанс:
я изменил состав команды, а не сам техпроцесс.
То есть процесс производства ПО у меня остался прежним:
проектирование → изменение → тестирование → внедрение.
Изменилось другое — кто именно участвует в этих этапах.
И для меня это важный вывод: агентная разработка покрывает не только кодинг. Она закрывает практически все аспекты производства ПО.
Сначала — проектирование: аналитика, архитектура, уточнение формулировок, поиск противоречий, сборка спецификаций.
Потом — собственно изменения в коде и модели.
Дальше — тестирование, проверка сценариев, поиск слабых мест и только потом внедрение.
На примере онбординга Onto это выглядит довольно приземлённо.
Сначала формулируется пользовательский путь, потом он превращается в последовательность этапов, затем несколько агентов по очереди ищут логические дыры, архитектурные противоречия, слабые места в сценарии и недостающие проверки.
К моменту начала реализации значительная часть проблем уже снята не кодом, а качеством проектирования.
Сейчас у меня в этой работе синхронизируются:
— агент-аналитик,
— агент бэкенда,
— агент фронтенда,
— и теперь ещё агент QA.
И это, честно говоря, ощущается очень правильно.
Потому что проверка — это не хвост процесса, а полноценный участник формирования решения.
Отдельно хочу зафиксировать ещё одну вещь.
Мне часто возражают примерно так: ну хорошо, «навайбкодили», а дальше как это поддерживать?
И вот здесь у меня как раз обратный опыт.
Управлять сложностью с агентами внутри существующего проекта — нормально.
Не только в новом, пустом, игрушечном контуре, а в живом проекте с историей решений, накопленным контекстом, ограничениями и техническим долгом.
Как раз Онто для меня и есть такой пример.
Это не зелёное поле. Это развивающийся проект, в котором нужно держать архитектуру, не терять смысл, сохранять преемственность решений и не превращать изменения в хаос. И агентный подход с этим вполне совместим.
Но при одном важном условии: агентная разработка не отменяет инженерную культуру, а делает её ещё важнее.
Контроль техдолга, ведение проектной документации, фиксация решений, регулярный рефакторинг — это не бюрократия и не побочная активность. Это нормальная инженерная гигиена.
Примерно как мыть руки после улицы. Это не подвиг, это просто нормально.
Поэтому вопрос «как потом поддерживать?» для меня не выглядит аргументом против агентной разработки.
Поддерживаемость рождается не из отказа от агентов, а из дисциплины: документации, прозрачности решений, контроля долга и регулярной уборки за собой.
Следующий очевидный шаг для меня — делать уже инфраструктуру взаимодействия агентов.
Не просто набор отдельных помощников, а среду, где у них есть:
— общий словарь,
— общий контекст,
— понятные роли,
— правила передачи задач,
— и зафиксированная история решений.
То есть мы постепенно приходим не к «AI вместо команды», а к другой модели команды.
Где человек остаётся архитектором смысла и владельцем системы, а агенты усиливают производство в своих специализированных контурах.
Самое любопытное здесь вот что: многие пока только спорят о том, как ИИ изменит разработку, а я уже просто перестраиваю состав команды под эту реальность.
PS И да, этот текст тоже написан с помощью агента, который помогает мне с коммуникациями.