Появилась запись моего апрельского выступления на DevOps Conf с докладом про "State of AI4SDLC" или что сейчас реально происходит с AI в разработке и почему история уже давно не только про генерацию кода.
Про само исследование я уже рассказывал много раз, поэтому коротко. AI уже стал повседневным инструментом для кодогенерации. По нашим данным, 58% часто или всегда используют AI для генерации кода, 64% видят рост продуктивности. Но дальше картинка сложнее: доверие к AI-коду остается низким, а качество не улучшается автоматически. Главный вывод для меня такой: AI ускоряет не весь SDLC, а отдельные его участки. Если ничего не менять в инженерной системе, bottleneck просто переезжает из написания кода в review, тесты, CI/CD, интеграцию, безопасность, релизы и управление контекстом.
И вот здесь начинается самое интересное: мы движемся от Software Engineering 1.0 к Software Engineering 2.0.
В классическом Software Engineering 1.0 разработка часто выглядит как цепочка стадий и handoff’ов: требования, дизайн, реализация, review, тестирование, релиз. Даже в agile-командах эта логика никуда полностью не исчезла: есть тикет, есть исполнитель, есть diff, есть ревью, есть pipeline. В AI-native варианте часть работы начинают делать ассистенты и агенты. Они могут писать код, предлагать тесты, читать документацию, анализировать баги, готовить PR, помогать с миграциями. Но человек при этом не исчезает. Скорее меняется его позиция.
Разработчик становится не только автором кода, но и навигатором: задает intent, собирает context, формулирует ограничения, декомпозирует work graph, делегирует задачи агентам, проверяет результат и принимает инженерное решение.
Мне все больше нравится описывать это как цепочку:
intent -> context -> plan -> tasks -> implementation -> verification.И это сильно меняет привычный inner loop. Раньше основное усилие часто было в том, чтобы самому написать реализацию. Теперь все больше усилия уходит в то, чтобы правильно поставить задачу, дать системе достаточно контекста, ограничить пространство решений и построить проверку, которой можно доверять.
Отсюда следующий важный сдвиг: классический ticket tracker начинает трещать. Тикет как “описание задачи + статус + комментарии” был нормальной единицей координации для людей. Но агенту этого мало. Агенту нужен связанный контекст: цель, ограничения, зависимости, решения из прошлого, права доступа, кодовая база, тесты, логи, критерии приемки, доступные инструменты и границы того, что можно менять. Новая единица работы - не тикет, а context-rich work graph, в котором человек и агент могут безопасно довести задачу до результата.
Это влияет и на оргдизайн. AI-native организация - это не просто “меньше людей”. Скорее это меньше лишних handoff’ов, сильнее роль senior и staff engineers, больше self-service, сильнее platform engineering, больше automation и guardrails. То есть организация должна не только генерировать больше output’а, но и уметь безопасно его переваривать.
Именно поэтому метрики usage почти ничего не говорят. Количество запросов к AI, включенных лицензий или сгенерированных строк кода - это vanity metrics. Смотреть надо на всю цепочку:
adoption -> throughput -> quality/risk -> economics. То есть: используют ли инструмент; ускорились ли PR, review, time to merge и cycle time; не выросли ли дефекты, инциденты, security-риск и технический долг; какая экономика у этой новой скорости.Для разработчиков вывод в том, что надо уметь работать с AI как с инженерным контуром: декомпозировать задачи, писать хорошие acceptance критерии, проверять диффы, сгенерированные AI, понимать архитектурные последствия и держать в голове эксплуатацию.
Для тимлидов, EM и CTO вывод еще жестче: AI-внедрение нельзя вести как закупку инструмента. Это изменение production-системы разработки. Нужны правила, доступ к контексту, безопасные контуры, CI/CD, тесты, ownership, platform engineering, evals, observability и метрики результата.
#AI #AI4SDLC #Engineering #DevOps #Management #Architecture