Человек + ИИ в создании ПО: практический плейбук для будущего

Что на самом деле значит «Человек + ИИ» при создании ПО

«Человек + ИИ» — это ко-создание: команда строит ПО, одновременно используя инструменты ИИ (ассистенты по коду и большие языковые модели) как активных помощников на всём протяжении процесса. Речь не о полной автоматизации и не о «нажал кнопку — получил продукт». Думайте об ИИ как о быстром коллеге, который может черновать, предлагать, проверять и резюмировать — а люди остаются ответственными за решения и последствия.

Ко-создание vs. полная автоматизация (простыми словами)

Ко-создание означает, что люди задают цель, определяют, что значит «хорошо», и управляют работой. ИИ даёт скорость и варианты: он может предложить код, сгенерировать тесты, переписать документацию или выявить крайние случаи.

Полная автоматизация означала бы, что ИИ владеет всеми этапами продукта с минимальным человеческим руководством — требования, архитектура, реализация и выпуск — вместе с ответственностью. Большинство команд к этому не стремятся, и многие организации не могут принять такой риск.

Почему модель сотрудничества подходит реальным командам

ПО — это не только код. Это ещё и бизнес-контекст, потребности пользователей, соответствие правилам, доверие к бренду и стоимость ошибок. ИИ великолепен в создании черновиков и исследовании альтернатив, но он не понимает ваших клиентов, внутренних ограничений и того, что ваша компания может безопасно выпустить. Сотрудничество сохраняет преимущества, обеспечивая соответствие продукта реальным целям.

Ожидания: более быстрые циклы и новые режимы ошибок

Можно ожидать заметного выигрыша по скорости при черновой разработке и итерациях — особенно для повторяющейся работы, шаблонного кода и первичных решений. Вместе с тем риски качества приобретают новые формы: убедительно звучащие, но неправильные ответы, тонкие баги, небезопасные шаблоны и ошибки с лицензированием или обработкой данных.

Люди остаются ответственными за:

• Намерение продукта и приоритезацию
• Компромиссы (стоимость, надёжность, безопасность, сопровождаемость)
• Финальное ревью, утверждения и ответственность

Что охватит этот плейбук

Дальше идут практические разделы: превращение идей в требования, совместное проектирование системы, парное программирование с ИИ, тестирование и ревью кода, охранительные меры по безопасности и приватности, поддержание актуальной документации и измерение результатов, чтобы следующая итерация была лучше — не только быстрее.

Где ИИ помогает больше всего — а где люди должны вести

ИИ отлично ускоряет исполнение, превращая хорошо сформулированное намерение в рабочие черновики. Люди по-прежнему лучше формулируют намерение и принимают решения, когда реальность запутана.

Задачи, которые ИИ может ускорить

При правильном использовании ассистент на базе ИИ может сэкономить время при:

• Генерации шаблонов (эндпойнты, CRUD, каркас UI, конфиги)
• Рефакторинге (переименования, извлечение функций, упрощение логики)
• Написании тестов (предложение краевых случаев, каркасов тестов)
• Документации (черновики README, примеры использования API, заметки к релизу)
• Поддержке отладки (сводки логов, вероятные причины, предложения экспериментов)
• Поиске по коду и объяснении (сводки по незнакомым модулям и потокам)

Тема общая: ИИ быстр в генерации кандидатов — черновой код, текст, тест-кейсы.

Где люди приносят наибольшую ценность

Люди должны вести в:

• Уточнении целей и метрик успеха (что значит «готово»)
• Выборе компромиссов (скорость vs. стоимость, согласованность vs. гибкость, строить vs. покупать)
• Продуктовом суждении (что действительно нужно пользователям, что может подождать)
• Архитектуре и решениях по рискам (операбельность, масштабируемость, режимы отказов)
• Ответственности (подписание за поведение, обработку данных и качество)

ИИ может описывать варианты, но он не владеет результатами. Эта ответственность остаётся за командой.

Выводы ИИ — предложение, а не истина

Относитесь к ИИ как к умному коллеге, который быстро и уверенно делает черновики, но может ошибаться. Проверяйте результаты тестами, ревью, бенчмарками и быстрым сопоставлением с реальными требованиями.

Простой пример «хорошего» и «плохого» использования

Хорошо: «Вот наша существующая функция и ограничения (задержка < 50ms, требуется сохранять порядок). Предложи рефактор, объясни компромиссы и сгенерируй тесты, доказывающие эквивалентность.»

Плохо: «Перепиши наш middleware аутентификации ради безопасности», а затем скопировать вывод прямо в прод без понимания, моделирования угроз или валидации тестами и логированием.

Победа — не в том, чтобы дать ИИ рулить, а в том, чтобы он ускорял те части, которыми вы уже умеете управлять.

Чёткое разделение труда: роли, ответственность и отчётность

Сотрудничество «Человек + ИИ» работает лучше, когда все понимают, за что отвечают — и за что не отвечают. ИИ может быстро черновать, но он не может нести ответственность за продуктовые результаты, влияние на пользователей или бизнес-риски. Ясные роли предотвращают решения типа «ИИ сказал», и помогают команде двигаться уверенно.

Ясность ролей: кто за что отвечает

Представляйте ИИ как высокоскоростного участника, который поддерживает каждую функцию, а не заменяет её.

• Продукт отвечает за цели, объём и приоритезацию. ИИ может помогать суммировать исследования, черновать пользовательские истории и предлагать критерии приёмки.
• Дизайн отвечает за UX, доступность и взаимодействие. ИИ может генерировать варианты, критиковать потоки и предлагать тексты.
• Инжиниринг отвечает за архитектуру, реализацию, надёжность и долгосрочную сопровождаемость. ИИ может предлагать подходы, черновать код и помогать в отладке.
• ИИ (инструменты) ничего официально не владеет — но может ускорять черновики, выявлять риски и предлагать альтернативы. Люди должны проверять.

Лёгкая матрица ответственности (Решает / Черновик / Проверяет)

Используйте простую матрицу, чтобы избежать путаницы в тикетах и PR:

Ворота ревью перед мёрджем или релизом

Добавьте явные вехи, чтобы скорость не ушла вперёд качества:

1. Spec gate: согласованы проблема, объём и критерии приёмки.
2. Design gate: ключевые экраны/потоки утверждены (включая проверки доступности).
3. Implementation gate: PR просмотрен человеком; фидбек ИИ — советующий.
4. Safety gate: тесты проходят; проверки безопасности/приватности выполнены, где требуется.
5. Release gate: написан changelog; подтверждён план мониторинга/отката.

Делайте решения видимыми (и проверяемыми)

Фиксируйте «почему» там, где команда уже работает: комментарии в тикетах для компромиссов, заметки в PR для изменений, сгенерированных ИИ, и краткий changelog для релизов. Когда решения видимы — ответственность очевидна, и будущая работа проще.

От идеи к требованиям: совместное написание спецификации продукта

Хорошая спецификация продукта — это не «задокументировать всё», а выровнять людей относительно того, что будет сделано, зачем это важно и что значит «готово». С ИИ в процессе вы можете быстрее прийти к тестируемой спецификации — при условии, что человек остаётся ответственным за решения.

Начинайте с проблемы, а не с фичи

Начните с трёх опорных пунктов простым языком:

• Problem statement: Какую боль пользователя или бизнес-риск мы снижаем?
• Success metrics: Как мы поймём, что это сработало (сэкономленное время, конверсия, меньше тикетов, влияние на выручку)?
• Constraints: Бюджет, сроки, поддерживаемые платформы, источники данных и правила «нельзя делать».

Попросите ИИ бросить вызов черновику: «Какие предположения я делаю? Что могло бы привести к провалу? Какие вопросы нужно ответить перед началом инженерии?» Относитесь к выводу как к списку задач для валидации, а не к истине.

Используйте ИИ для предложений вариантов — и заставляйте его показывать компромиссы

Попросите модель сгенерировать 2–4 подхода к решению (включая базовую опцию «не делать ничего»). Требуйте, чтобы он указывал:

• Зависимости (системы, команды, вендоры)
• Риски и неясности
• Оценки усилий
• Что потребует юзер-исследования или юридической проверки

Вы выбираете направление; ИИ помогает увидеть, что можно упустить.

Превращайте идеи в короткий PRD- outline

Держите PRD настолько компактным, чтобы люди его читали:

• Goal и non-goals
• Целевые пользователи и ключевые сценарии
• Объём (MVP vs позже)
• Acceptance criteria (тестируемые утверждения, а не расплывчатые обещания)

Пример acceptance criterion: «Аутентифицированный пользователь может экспортировать CSV менее чем за 10 секунд для наборов данных до 50k строк.»

Контрольный список требований (не пропускайте это)

Прежде чем считать спецификацию готовой, подтвердите:

• Приватность и обработка данных: какие данные используются, хранятся, передаются и как долго хранятся
• Соответствие: отраслевые правила и внутренние политики
• Производительность: время ответа, пропускная способность, ожидания по масштабированию
• Доступность: цели WCAG, навигация с клавиатуры, поддержка скринридеров

Когда ИИ черновал части PRD, убедитесь, что каждое требование связано с реальной пользовательской потребностью или ограничением — и что подписанный владелец подтвердил это.

Совместное проектирование системы: варианты, компромиссы и решения

Проектирование системы — место, где сотрудничество «Человек + ИИ» может ощущаться особенно мощным: вы быстро исследуете несколько жизнеспособных архитектур, а затем применяете человеческое суждение, чтобы выбрать ту, что подходит под реальные ограничения.

Просите ИИ генерировать варианты — а потом заставляйте сравнивать

Попросите ИИ предложить 2–4 архитектурных кандидата (например: модульный монолит, микросервисы, serverless, event-driven) и потребуйте структурированное сравнение по стоимости, сложности, скорости доставки, операционному риску и зависимости от вендора. Не принимайте единственный «лучший» ответ — заставьте модель аргументировать обе стороны.

Простой шаблон подсказки:

• «Предложи три архитектуры для X; перечисли допущения.»
• «Сравни их в таблице: стоимость/сложность/риск.»
• «Что может привести каждую опцию к провалу в продакшене?»

Пропишите швы: точки интеграции, потоки данных, режимы отказа

После выбора направления попросите ИИ перечислить швы, где системы соприкасаются. Пусть он сгенерирует:

• Точки интеграции (API, очереди, вебхуки, пакетные импорты)
• Потоки данных (какие данные куда передаются и зачем)
• Режимы отказа (таймауты, ретраи, дублирующие события, частичные записи)

Затем проверьте это с людьми: соответствуют ли эти предположения тому, как бизнес реально работает, включая краевые случаи и грязные реальные данные?

Ведите журнал решений, который переживёт смену людей

Создайте лёгкий decision log (по одной странице на решение) с:

• Контекстом и ограничениями
• Рассмотренными вариантами
• Принятым решением и причинами
• Принятыми компромиссами
• Follow-up задачами (что измерять, когда пересмотреть)

Храните рядом с кодовой базой, чтобы он оставался доступным (например, в /docs/decisions).

Определите ранние «неподлежащие оптимизации»

До реализации пропишите границы безопасности и правила обработки данных, которые нельзя «оптимизировать» иначе, такие как:

• Где можно хранить и обрабатывать чувствительные данные
• Модель аутентификации/авторизации и границы доверия
• Требования к логированию/редакции
• Ожидания по хранению и удалению

ИИ может черновать эти политики, но люди должны владеть ими — потому что ответственность не делегируется.

Парное программирование с ИИ: практический рабочий цикл

Парное программирование с ИИ лучше всего работает, когда вы относитесь к модели как к младшему коллеге: быстро предлагает варианты, но слабо понимает вашу уникальную кодовую базу, если вы его не научите. Цель — не «пусть ИИ напишет приложение», а плотный цикл, в котором люди направляют, а ИИ ускоряет.

Если вы хотите, чтобы этот рабочий цикл был более «end-to-end», чем отдельный код-ассистент, платформы с vibe-coding, такие как Koder.ai, могут помочь: вы описываете фичу в чате, итеративно двигаетесь мелкими шагами и при этом сохраняете человеческие вехи — платформа генерирует каркас для веба (React), бэкенда (Go + PostgreSQL) или мобильных приложений (Flutter) с экспортируемым исходным кодом.

Шаг 1: задайте сцену с реальным контекстом

Прежде чем просить код, предоставьте ограничения, которые обычно человек узнаёт из репозитория:

• Релевантные файлы (или ключевые фрагменты) и структура папок
• Конвенции наименования, правила линтинга/форматирования и предпочтительные библиотеки
• Непримиримые требования (производительность, доступность, безопасность, версионирование API)
• «Definition of done» для этого куска (ожидаемые входы/выходы, краевые случаи)

Полезный шаблон подсказки:

You are helping me implement ONE small change.
Context:
- Tech stack: …
- Conventions: …
- Constraints: …
- Existing code (snippets): …
Task:
- Add/modify: …
Acceptance criteria:
- …
Return:
- Patch-style diff + brief reasoning + risks

Обратите внимание: блок кода выше оставлен без перевода — это пример шаблона подсказки, который следует передавать ИИ в исходном виде.

Шаг 2: работайте маленькими кусками, а не большими переработками

Ограничивайте объём: одна функция, один эндпойнт, один компонент. Меньшие куски легче верифицировать, избегают скрытых регрессий и сохраняют ясность ответственности.

Хороший ритм:

1. Вы описываете намерение и границы.
2. ИИ предлагает каркас (файлы, интерфейсы, проводку).
3. Вы выбираете подход и просите следующий инкремент.

Шаг 3: позвольте ИИ делать повторяющуюся работу — затем вы полируете

ИИ хорош в генерации шаблонного кода, сопоставлении полей, создании типизированных DTO, простых UI-компонентов и механическом рефакторинге. Люди должны:

• Проверять корректность относительно продуктовой цели
• Упрощать и давать осмысленные имена
• Согласовывать с архитектурой и долгосрочной сопровождаемостью

Шаг 4: никакого тихого копирования в прод

Правило: сгенерированный код должен быть проверен, как и любой другой вклад. Запустите его, прочитайте, протестируйте и убедитесь, что он соответствует соглашениям и ограничениям. Если вы не можете объяснить, что он делает — он не идёт в релиз.

Тестирование как общий механизм безопасности

Тестирование — место, где «Человек + ИИ» может быть особенно практичным. ИИ может генерировать идеи, каркасы и объём; люди дают намерение, суждение и ответственность. Цель — не больше тестов, а больше уверенности.

Давайте ИИ расширять ваше мышление (особенно по краям)

Хорошая подсказка превращает LLM в неутомимого тест-партнёра. Попросите его предложить краевые случаи и режимы отказа, которые вы можете пропустить:

• Пограничные значения (пустые входы, максимальные длины, необычные кодировки)
• Временные нюансы (часовые пояса, переход на летнее/зимнее время, дрейф часов)
• Конкурентность и ретраи (двойные сабмиты, частичные отказы)
• Комбинации прав и ролей

Относитесь к этим предложениям как к гипотезам. Люди решают, какие сценарии важны, исходя из риска продукта и воздействия на пользователей.

Черновые тесты от ИИ — затем проверяйте смысл и покрытие

ИИ быстро черновит unit и integration тесты, но вы должны проверить два момента:

1. Покрытие: Проверяют ли тесты поведение, которое важно, или только happy path?
2. Смысл: Доказывают ли утверждения нужное, или это хрупкие снапшоты, создающие шум?

Полезный рабочий цикл: вы описываете поведение простым языком, ИИ предлагает тест-кейсы, вы шлифуете их в небольшой читабельный набор тестов. Если тест трудно понять — это сигнал, что требование неясно.

Генерация тестовых данных обдуманно (и безопасно)

ИИ может помочь создать правдоподобные тестовые данные — имена, адреса, счета, логи — но никогда не используйте реальные данные клиентов. Предпочитайте синтетические наборы, обезличенные фикстуры и явно отмеченные «фейковые» значения. Для регулируемых контекстов документируйте, как производятся и хранятся тестовые данные.

Определите «готово» шире, чем «компилируется»

В AI-assisted цикле код может выглядеть «готовым» очень быстро. Сделайте «готово» общим контрактом:

• Тесты проходят локально и в CI
• Новое поведение имеет новые/обновлённые тесты
• Человек проверил намерение тестов и покрытие рисков

Этот стандарт не даст скорости перегнать безопасность и превратит ИИ в мультипликатор, а не в лазейку.

Ревью кода с ИИ: быстрее фидбек, те же стандарты

ИИ может ускорить ревью, взяв на себя «первую проходку»: резюмирование изменений, выявление несоответствий и предложение небольших улучшений. Но цель ревью не меняется: защищать пользователей, бизнес и здоровье кодовой базы.

Что ИИ может сделать до того, как человек откроет diff

Хорошо использованный ИИ — генератор чек-листа для прерентий ревью:

• Резюмировать изменения: «Что делает этот PR простыми словами? Какие файлы и поведения затронуты?»
• Найти несоответствия: разные имена, дублирование логики, пропущенная обработка ошибок, неожиданные дефолты.
• Предложить улучшения: более жёсткая валидация, понятные имена переменных, упрощение контрольного потока, лучшие комментарии.

Это особенно полезно в больших PR — ИИ укажет 3–5 областей с реальным риском.

Что люди всё ещё должны проверять

ИИ может уверенно ошибаться, поэтому люди несут ответственность за:

• Корректность: соответствует ли требованию? Покрыты ли краевые случаи? Допустимы ли режимы отказа?
• Безопасность & приватность: риски инъекций, небезопасная десериализация, дырки в авторизации, утечка секретов?
• Сопровождаемость: читаемо ли? Вписывается ли в архитектуру? Тестируемо ли? Смогут ли инженеры на дежурстве разобраться в 2 часа ночи?

Полезное правило: относитесь к фидбеку ИИ как к умному стажёру — используйте, но всегда проверяйте важное.

Подсказки для ревьюеров

Вставьте diff PR (или ключевые файлы) и попробуйте:

• «Резюмируй изменение поведения и перечисли пользовательские влияния.»
• «Найди рискованные допущения или скрытые связи с другими модулями.»
• «Определи проблемы безопасности и точные строки, где они встречаются.»
• «Какие крайние случаи не покрыты тестами?»
• «Предложи рефакторы, снижающие сложность без изменения поведения.»

Делайте видимым использование ИИ в PR

Попросите авторов добавить короткую заметку в PR:

• Что сделал ИИ: сгенерировал функцию, предложил regex, переписал обработку ошибок, набросал тесты.
• Что проверили люди: требования выполнены, тесты добавлены/обновлены, проверки безопасности пройдены, шаги ручного тестирования выполнены.

Такая прозрачность превращает ИИ из чёрного ящика в документированную часть инженерного процесса.

Безопасность, приватность и лицензии: важные guardrails

ИИ ускоряет доставку, но он же ускоряет и ошибки. Цель — не «меньше доверять», а быстрее проверять с помощью явных guardrails, которые сохраняют качество, безопасность и соответствие.

Ключевые области риска

Галлюцинации: модель может выдумывать API, флаги конфигурации или «факты» о вашей кодовой базе.

Небезопасные паттерны: предложения могут содержать небезопасные дефолты (разрешительный CORS, слабая криптография, отсутствие проверок) или часто встречающиеся, но рискованные фрагменты.

Лицензионная неопределённость: сгенерированный код может напоминать код с лицензией, а предложенные зависимости — ввести вирусные или ограничительные условия.

Практические меры (сделайте их обязательными)

Обращайтесь с выводом ИИ как с любым другим сторонним вкладом:

• SCA в CI для обнаружения уязвимых пакетов и запрещённых лицензий
• SAST на каждом PR для поиска инъекций, проблем с авторизацией, небезопасной десериализации и опасных мест
• DAST (или хотя бы дымовые security-тесты API) на staging для реальных runtime-сигналов
• Детектор секретов в коммитах и логах сборки; фейл при утечке ключей
• Лёгкая модель угроз для изменений с высоким воздействием (аутентификация, платежи, экспорт данных)

Держите результаты видимыми: прокидывайте выводы в те же проверки PR, которые разработчики уже видят, так безопасность станет частью «готово», а не отдельной фазой.

Правила по чувствительным данным в подсказках

Пропишите и соблюдайте правила:

• Никогда не вставлять учётные данные, приватные ключи, токены или куки сессий.
• Никогда не вставлять данные клиентов, персональные данные или продакшн-логи с идентификаторами.
• Избегать прописи конфиденциального исходного кода, если ваши инструменты и договора этого не позволяют.
• Отдавать предпочтение редактируемым примерам и синтетическим данным.

Когда ИИ противоречит требованиям: простой путь эскалации

Если предложение ИИ идёт вразрез со спеком, политикой безопасности или правилом соответствия:

1. Инженер помечает это в PR («предложение ИИ конфликтует с требованием X»).
2. Перепроверяют спек и добавляют уточняющую заметку или критерий приёмки.
3. Эскалируют к владельцу кода/ревьюеру по безопасности для окончательного решения.
4. Фиксируют результат как короткое правило в документации команды, чтобы конфликт не повторялся.

Документация и обмен знаниями, которые остаются актуальными

Хорошая документация — не отдельный проект, это «операционная система» команды: как строят, доставляют и поддерживают ПО. Лучшие команды «Человек + ИИ» считают docs приоритетом и используют ИИ, чтобы поддерживать их в актуальном состоянии.

Что ИИ должен черновать (а люди финализировать)

ИИ отлично годится для первичных версий:

• Runbooks: пошаговые инструкции «если X случилось — делай Y» для инцидентов и распространённых операций
• Onboarding notes: как запустить проект локально, ключевые концепции, карта важных папок
• Decision summaries: краткие записи о том, почему был выбран тот или иной компромисс

Люди проверяют точность, убирают допущения и добавляют контекст, известный только команде — что такое «хорошо», что рискованно и что сознательно вне объёма.

Превращение технической работы в понятные заметки о релизе

После спринта или релиза ИИ может переводить коммиты и PR в релиз-ноты для клиентов: что изменилось, почему это важно и нужны ли какие-то действия.

Практика: дайте ИИ набор входных данных (заголовки merged PR, ссылки на задачи и короткая заметка «что важно») и запросите два варианта вывода:

1. Для нетехнической аудитории (продукт, продажи, клиенты)
2. Для операторов (support, on-call, внутренние команды)

Затем человек-ответственный редактирует тон, точность и месседж.

Предотвращение устаревания документации

Документация устаревает, когда она отделена от кода. Привязывайте docs к работе:

• Обновляйте документацию в том же PR, что и изменение кода
• Добавьте пункт в чек-лист PR: «Docs updated or not needed»
• Используйте ИИ в ревью кода, чтобы находить возможный дрейф (переименованные эндпойнты, конфиги, новые флаги)

Если у вас есть публичный продуктный сайт, используйте внутренние относительные ссылки, чтобы уменьшить повторы и направлять читателей к стабильным ресурсам — например, /pricing для деталей планов или /blog для развёрнутых объяснений.

Измерение результатов и подготовка к следующей волне

Если вы не измеряете влияние помощи ИИ, разговоры сведутся к ощущениям: «Кажется быстрее» vs «Кажется рискованно». Трактуйте доставку с ИИ как любое другое изменение процесса — трассируйте, ревью и корректируйте.

Что измерять (и зачем)

Начните с небольшой группы метрик, отражающих реальные результаты, а не новизну:

• Lead time (идея → прод): действительно ли вы релизите быстрее, или просто производите больше черновиков?
• Дефекты и утечки: отслеживайте частоту багов, их серьёзность и сколько проблем дошло до клиентов
• Инциденты: частота, время обнаружения, время восстановления и послесрочные действия
• Удовлетворённость: короткие опросы для разработчиков и заинтересованных сторон (ясность, уверенность, воспринимаемое качество)

Сопоставьте это с пропускной способностью ревью (время цикла PR, количество раундов ревью), чтобы понять, уменьшает ли ИИ узкие места или добавляет откатную работу.

Отслеживайте, где ИИ помогает, а где создаёт переработку

Не маркируйте работу «ИИ» или «человеческую» морально. Маркируйте, чтобы учиться.

Практика: помечайте задачи/PR простыми флагами:

• AI used for boilerplate/scaffolding
• AI used for refactoring
• AI used for test generation
• AI used for debugging

Затем сравнивайте результаты: быстрее ли проходят изменения с ИИ? Генерируют ли они больше последующих PR? Связаны ли они с откатами? Цель — найти точки высокой отдачи и зоны опасности.

Если вы оцениваете платформы, а не только ассистентов, включите в критерии «снижающие переработку» возможности: снимки/откат, деплой/хостинг и возможность экспортировать исходники. Именно поэтому команды используют Koder.ai не только для прототипирования: вы можете итеративно работать в чате и при этом сохранять привычные контролли (ревью, CI, релизные ворота) и чистый путь экспорта в стандартный репозиторий.

Постройте плотную обратную связь

Создайте лёгкую «систему обучения» для команды:

• Общая библиотека подсказок (что спрашивать, когда и с каким контекстом)
• Галерея хороших выводов (что значит «готово»)
• Галерея плохих выводов (галлюцинации, небезопасные паттерны, вводящие в заблуждение тесты) и способы их отлова

Держите это практичным и актуальным — обновляйте в ретроспективах, а не раз в квартал как отдельный проект.

Готовность к следующему этапу

Ожидайте развития ролей. Инженеры будут больше времени тратить на формулирование проблем, управление рисками и принятие решений, и меньше — на механический перевод намерения в синтаксис. Новые навыки важны: писать понятные спеки, оценивать выводы ИИ, понимать безопасность/лицензирование и обучать команду через примеры. Непрерывное обучение перестаёт быть опцией — это часть рабочего процесса.