Сломанный SDLC Разработка классического программного обеспечения по SDLC — даже с активным применением AI-инструментов вроде Claude Code, Codex или Cursor — и разработка продуктов, в основе которых лежит AI для конечного пользователя, — это принципиально разные процессы. При этом каждый из них претерпевает изменения по-своему. AI для SDLC Современные AI инструменты ускоряют написание кода, рефакторинг, тестирование, документацию и ревью, они быстро эволюционируют: например, Anthropic добавляет в Claude Code режим security‑сканирования кодовой базы с предложением патчей подтверждая тренды от google. Цена строчки кода стремительно падает. Это влияет на методологию, процесс претерпивает глобальные изменения, например OpenAI называет смещение фокуса как harness engineering: инженерная работа уходит в проектирование спецификаций и намерений. AI как продукт Главная сложность в разработки этих систем — описать желаемое поведение и сделать его проверяемым. Классический SDLC плохо описывает исследовательские подходы, делая упор на инженерные. Мы смогли скорректировать процесс для GenAI продуктов, но те сложности, что нас преследовали, лишь подтвердили кризис в отрасли. Этот кризис заметен не только в разработке, но и в продуктовом видении: понять, где нужен AI, а где нет — не самая тривиальная задача. Почему классический SDLC ломается? Классический SDLC начинается с идеи. В корпоративной среде эту роль берет на себя Product Owner: он формирует видение, передает его аналитикам, которые описывают требования для разработчиков и AI-инженеров. Далее команда разрабатывает систему, передает ее в тестирование и выводит в продакшн. С GenAI и агентными системами эта схема ломаться: Боль №1 — Требования Первая проблема возникает на этапе требований. Аналитик не понимает, как перевести образ результата в формализованные требования. Практик разработки требований для агентов пока просто нет. В итоге по цепочке передается все тот же образ результата от Product Owner, без декомпозиции, критериев качества и проверяемых ожиданий. В результате все участники процесса — PO, аналитик, разработчик, AI-инженер, QA — работают с одним и тем же образом результата и каждый по-своему пытается превратить его в конечный артефакт. Как следствие: резко возрастает ценность людей, способных брать ответственность end-to-end. Роль вторична — ключевым становится умение доводить продукт от идеи до результата. Боль №2 — Время от идеи до результата Агентные системы позволяют получить первый эффект буквально за дни: Product Owner может за вечер собрать агента, который решает конкретную бизнес-проблему. Но у такого решения не будет требований, метрик качества, масштабируемости и воспроизводимости. Альтернативный путь — передать образ результата аналитику, который соберет прототип агента и опишет требования. В этом случае появление первого агента будет измеряться уже неделями. Отсутствуют практики, методологии и фреймворки разработки агентных систем, поэтому продвижение по классической цепочке сильно затягивается. Боль №3 — Итеративный процесс Исследовательский подход подразумевает итеративный процесс развития систем с AI. Сначала мы собираем бейзлайн (максимально простую систему), выстраивая метрики качества. Начинаем собирать датасеты и проверять результат. Итеративным путем улучшаем систему элемент за элементом. Это приводит к тому, что люди, привыкшие к появлению новых фич после каждого спринта, сталкиваются с системой, которая пока не удовлетворяет стандартам качества, и не всегда готовы ждать, пока это качество наработается. В этот момент в Jira может прилететь куча задач о том, что система ведет себя неправильно мешая исследователям. Какую стратегию выбрать? В итоге мы оказываемся перед выбором: - Либо строить команды вокруг людей, готовых отвечать за результат end-to-end, но таких людей мало. - Либо вырабатывать новые методологии и практики, которые позволят проходить весь путь — от идеи до продакшна — с узкоспециализированными ролями, снижая требов