Бесплатный курс · 9 модулей · 52 минуты. Фокус смещается с написания кода на спецификацию и окружение. Курс о том, что такое AI-PDLC и чем этот подход отличается от привычной разработки. Ключевая мысль: результат определяет среда вокруг модели, а не выбор самой модели. Без установки инструментов и разбора промптов — на уровне того, как устроен сам процесс создания продукта.
Для всех участников производственных команд и для всех, кто хочет понять, как будет устроен процесс создания продукта в ближайшие годы. Технический бэкграунд не нужен: разбираемся на примере одной задачи, а не на уровне кода.
Определение простыми словами, откуда это взялось и чем не является
Определение · Из чего состоит · Чем это не является
Одна и та же задача проходит через два процесса — смотрим, что меняется
Задача и то, как она идёт сейчас · Та же задача в новом процессе · Где выигрыш испаряется
Арифметика цикла, эффект масштаба и цена скорости без контроля
Простой расчёт, который объясняет разочарование · Скорость в долг · Договоритесь заранее, что считать результатом
Честная картина: где данные подтверждают эффект, а где опровергают
Самое строгое исследование даёт неудобный результат · DORA: ускорение обнажает слабости · Где эффект есть, а где его нет
Почему бюджет идёт в окружение агента, а не в подписки
Что такое окружение и почему оно решает · Спецификация становится главным документом · Контекст стоит денег
Как ускориться, не потеряв контроль над тем, что делает агент
Три вопроса, на которые отвечают разные участники · Права агента зависят от того, что он может испортить · Что нужно учесть по требованиям регулятора и безопасности
Кого нанимать, кого растить и правда ли можно сократить штат
Главный вопрос владельца · Какая работа исчезает и какая появляется · Как меняется каждая роль · Новые роли и когда их заводить · Что делать сотруднику, если руководство решило переходить · Что делать с людьми, которые не хотят
Метрики, ложная атрибуция и почему цифру скорости нельзя показывать одну
Четыре группы показателей · Три способа обмануть самого себя · Держите метрики парами
Семь шагов первого квартала: что делать, кто отвечает, чем закончится
Что нужно подготовить заранее · Семь шагов первого квартала · Чем закончится квартал и что сказать наверх
Отчасти хайп, отчасти нет, и разделить их можно по простому признаку. Обещания вроде «разработка подешевеет в десять раз» — хайп. А вот сдвиг узкого места с написания кода на проверку намерения никуда не денется, потому что он вызван не модой, а тем, что генерация действительно стала дешёвой. Даже если конкретные названия методологий сменятся, работа по наведению порядка в коде, автопроверкам и следу действий останется полезной при любом сценарии — это и есть разумная страховка.
Ровно тот же, кто отвечал раньше: команда и её руководитель. Ответственность не переносится на инструмент, как она не переносится на компилятор или на фреймворк. Практическая сторона вопроса другая — она про то, чтобы у вас был след действий агента, протестированный откат и понятные уровни прав. Тогда разбор инцидента ничем не отличается от обычного: видно, что было предложено, кто утвердил и на каком шаге проверка не сработала.
Это вопрос выбора модели и контура, а не методологии. Сама методология агностична: она описывает процесс и одинаково работает с моделью в публичном облаке, в изолированном контуре или развёрнутой локально. Что действительно требует внимания — какие данные попадают в контекст агента и в логи. Персональные данные утекают чаще не через саму модель, а через отладочные логи и тестовые выборки, и это надо закрывать независимо от того, внедряете вы что-то новое или нет.
Расходы делятся на три части, и самая заметная из них не самая большая. Первая — плата за использование моделей, её порядок вы узнаете уже на первой реальной задаче, и именно поэтому цену прохода нужно измерить сразу. Вторая — работа по подготовке окружения: автотесты, границы модулей, автоматические проверки. Третья — время людей на переучивание. Вторая часть обычно оказывается крупнее первой в несколько раз, и её же чаще всего забывают заложить в бюджет.
Не в первый год и не автоматически. Работа не исчезает, она смещается вверх по сложности: меньше написания типового кода, больше вычитки требований, проектирования проверок и оценки планов. Компактные команды из четырёх-шести человек существуют, но появляются они после того, как выстроено окружение, а не до. Если сократить людей раньше, некому будет делать ту самую работу по подготовке, ради которой всё затевалось.
Расходы делятся на три части. Первая — плата за использование моделей. По моей оценке, для команды из десяти человек, работающей ежедневно, это обычно сотни долларов в месяц, а не десятки тысяч, — но разброс огромный и зависит от модели и объёма контекста, поэтому точную цифру вы узнаете только на первой реальной задаче, поэтому её и надо измерить в первую очередь. Вторая часть — подготовка: автопроверки, наведение порядка в коде, настройка среды. Она обычно в несколько раз крупнее первой и измеряется человеко-месяцами, а не подписками. Третья — время людей на переучивание, примерно квартал сниженной производительности у тех, кто переходит первым. Самая частая ошибка бюджета — заложить только первую часть.
Относится, но по-другому. Вы не внедряете методологию сами — вы меняете то, что покупаете и как проверяете. Практически: попросите подрядчика показать спецификации, из которых порождается работа, а не только результат; включите в договор передачу автопроверок вместе с кодом; спросите, как у них устроен откат и есть ли след действий агента. Если подрядчик уже работает с агентами, скорость для вас вырастет — но риск, что вам сдадут непроверенный сгенерированный код, вырастет тоже. Приёмка становится важнее, чем была.
Это вопрос к вашим юристам, а не ко мне, и он зависит от юрисдикции и от условий конкретного поставщика модели. Что стоит проверить до начала: условия использования выбранного сервиса — что там сказано о правах на результат и об использовании ваших данных для обучения; договоры с сотрудниками и подрядчиками — покрывают ли они результат, созданный с помощью инструментов; обязательства перед вашими клиентами по конфиденциальности. Отдельный практический риск: агент может воспроизвести фрагмент кода под лицензией, несовместимой с вашей. Проверка лицензий зависимостей и происхождения кода — такая же автоматическая проверка в конвейере, как и остальные.
Ставить на паузу и не нужно. Первый месяц — это одна команда и одна задача из обычного бэклога, то есть работа, которую вы всё равно собирались делать. Дополнительных ресурсов не требуется, требуется согласие на то, что эта конкретная задача пойдёт медленнее обычного: разбор требований на входе и записи по ходу занимают время. По моему опыту работы с этим стоит закладывать, что первая задача выйдет дольше типовой примерно в полтора раза — это оценка, а не измеренная величина. Это плата за то, чтобы узнать, где у вас дыры, на одной задаче, а не на всём портфеле.
Зависит только от того, что вы сделаете с проверками. Данные показывают: генерация ускоряет написание примерно на треть и при неизменном ревью добавляет около четверти уязвимостей. То есть само по себе качество падает. Оно перестаёт падать, когда проверки становятся автоматическими и блокирующими: регресс, анализ безопасности, оценка на эталонном наборе сценариев (golden dataset). Это и есть основная работа второго месяца в плане внедрения.
Применимо, но медленнее и с другим первым шагом. Агенту тяжело работать с кодом без внятных границ: чем больше приходится втягивать в контекст, тем ниже качество плана и выше стоимость. Поэтому на легаси первые задачи берут в наиболее изолированных участках, а параллельно занимаются нарезкой на модули — работой, которая и без ИИ была нужна, просто теперь у неё появилось измеримое обоснование. Ожидать пятикратного ускорения на монолите в первый квартал не стоит.
Первый измеримый результат — через месяц, и это не ускорение. Это список контролей, которые не сработали, и цена прохода одной задачи. Ускорение на уровне отдельных команд обычно проявляется на втором-третьем месяце, а на уровне сроков выхода продуктов — не раньше полугода, потому что до этого выигрыш упирается в неизменённые релизные окна и согласования.
Не сразу и не по презентации. Структуру осмысленно менять по итогам практики: сначала три команды проходят реальные задачи, потом становится видно, какие роли действительно изменились и где появились новые обязанности — например, кто-то должен следить за поведением агентов в проде. Перерисовка ролей до первого прохода — один из самых распространённых способов потратить квартал впустую.
Это ровно тот случай, где вложения в окружение окупаются. Методология не привязана к конкретной модели или инструменту: правила процесса, спецификации, автопроверки и след действий остаются вашими. Смена модели превращается в замену компонента с перепрогоном проверок. Именно поэтому не стоит строить процесс вокруг уникальных возможностей одного поставщика — и стоит держать набор эталонных сценариев, на которых новую модель можно быстро сравнить со старой.
Тем же, чем покупка станков отличается от перестройки цеха. Ассистент в редакторе ускоряет одну операцию, которая занимает около четверти цикла, — арифметически это даёт 12–15% и теряется в разбросе сроков. Методология меняет порядок работ: требования разбираются с агентом на входе, проверки становятся автоматическими и распределёнными, согласование получает готовый комплект документов. Данные это подтверждают: у компаний с десятью и более сценариями применения ускорение видят 66%, у компаний с пятью и меньше — 35%.
Так и есть — начать можно почти из любой точки, и тесты агент действительно напишет. Вопросы готовности нужны не для решения «начинать или нет», а чтобы заранее понимать, что придётся доделать руками. Два пункта из четырёх спецификацией не закрываются в принципе: возможность быстро вернуть систему назад — это свойство того, как устроена выкатка, а не текст в документе; и базовая стоимость прохода задачи, которую нельзя восстановить задним числом. Плюс написанные агентом тесты ничего не блокируют сами по себе — нужно место, где они прогоняются автоматически, и договорённость, что красный прогон останавливает выпуск. При этом саму подготовку тоже разумно делать агентом: развернуть запуск тестов, дописать проверки на существующий код, собрать скрипт отката, поднять сбор метрик — это дни вместо недель. Агент не заменяет только то, что требует чьего-то согласия или принятия риска: решение остановить выпуск по красному тесту, проверку отката на живой системе и оценку того, осмысленны ли написанные проверки.
Методологии, о которых речь, появились в 2025–2026 годах, отраслевого стандарта пока нет, и через год многое будет выглядеть иначе. Это правда. Но обратите внимание, что именно устаревает: названия методологий, конкретные инструменты, формулировки шагов. А то, что вы делаете по ходу — автопроверки, порядок в коде, прослеживаемость изменений, быстрый откат, измеренная стоимость работы — полезно при любом развитии событий и не пропадёт, даже если через год всё будет называться иначе. Поэтому разумная стратегия не «ждать стандарта», а вкладываться в то, что переживёт смену моды.
С четырёх вопросов из восьмого модуля — есть ли блокирующий автоматический регресс, есть ли пригодный для проверки след, проверялся ли откат, известна ли цена прохода задачи. Дальше выберите одну команду, добровольно, и одну настоящую задачу из бэклога. Через месяц у вас будет два документа: список контролей, которые не сработали, и стоимость прохода. С ними уже можно идти к совету директоров, а без них разговор неизбежно сведётся к обсуждению хайпа.
Курс интерактивный: после каждого модуля идёт короткий тест, следующий модуль открывается после его прохождения. Для прохождения нужен включённый JavaScript. Выше — полная программа, ответы на частые вопросы и глоссарий в статичном виде.
Автор — Юрий Кононов, Chief Technical Officer. Курс бесплатный, распространяется по лицензии CC BY 4.0. Контакт: @ykononov, ykononov.com.