Будущее разработки ПО: как люди и ИИ создают вместе

Что значит «создавать ПО вместе с ИИ»

«Создавать ПО вместе с ИИ» — это не история про замену разработчиков, аналитиков или тестировщиков. Это про изменение способа работы: часть действий, которые раньше делались вручную и занимали часы, выполняется быстрее за счёт ИИ, а люди остаются теми, кто определяет смысл, несёт ответственность и отвечает за финальное качество.

Сотрудничество важнее «автоматизации людей»

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

Продуктивная модель — партнёрство: человек формулирует цель, критерии успеха и ограничения, а ИИ ускоряет путь к решению.

Что изменится быстрее всего

Быстрее всего эволюционируют этапы, где много текста, повторяемости и типовых проверок:

• Анализ и уточнение требований: ИИ помогает выявлять противоречия, недостающие условия, формулировать вопросы к заказчику.
• Прототипы и черновые решения: быстрые наброски интерфейсов, структуры данных, варианты пользовательских сценариев.
• Тесты: генерация тест-кейсов, идей для негативных сценариев, подготовка данных, первичная проверка регрессий.
• Документация: черновики README, описания модулей, инструкции по запуску и эксплуатации.

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

Что остаётся человеческой зоной ответственности

Есть области, где ответственность нельзя «делегировать» модели:

• Выбор цели продукта и приоритетов: что именно строим и зачем.
• Критерии качества и риски: где недопустимы ошибки, какие компромиссы приемлемы.
• Решения по безопасности и приватности: какие данные можно использовать, как соблюсти требования.
• Окончательное принятие изменений: кто подписывает релиз, кто отвечает перед пользователями и бизнесом.

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

Роли в команде: человек, ИИ и границы ответственности

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

Что остаётся за человеком

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

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

Где ИИ приносит максимум пользы

ИИ хорош там, где нужно быстро перебрать варианты и снять рутину:

• предложить несколько реализаций или архитектурных подходов;
• найти типовые шаблоны (например, обработки ошибок, логирования, валидации);
• подсказать частые причины багов по описанию симптомов;
• ускорить подготовку черновиков тестов, документации, комментариев.

В этих задачах «правильность» часто подтверждается экспериментом или тестами, а не авторитетом.

Проверяемость и объяснимость как правило

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

Как не уйти в «автопилот»

Главная ловушка — принимать сгенерированное как готовое. Рабочая привычка: сначала сформулировать своё ожидание (что должно получиться и почему), затем сравнить с ответом ИИ, и только после этого интегрировать изменения маленькими порциями. Так контроль остаётся у команды, а ускорение — у инструмента.

Постановка задачи и требования: как говорить с ИИ точно

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

Начните с проблемы и измеримого успеха

Опишите, какую боль решаем и для кого, затем зафиксируйте критерии успеха в цифрах или наблюдаемых результатах. Вместо «сделать удобнее» — «уменьшить время оформления заявки с 4 минут до 2» или «снизить долю обращений в поддержку по теме X на 20%». ИИ можно попросить предложить варианты метрик, но выбрать и утвердить их должны вы.

Соберите контекст: ограничения, аудитория, сценарии, данные

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

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

Чем конкретнее контекст, тем меньше «галлюцинаций» и спорных допущений.

Работайте с неопределённостью через гипотезы и быстрые проверки

Если требований пока нет, оформляйте предположения как гипотезы: «если добавим автозаполнение, конверсия вырастет». Попросите ИИ предложить минимальные эксперименты: прототип, A/B, фейковый экран, опрос — и заранее определите, какие результаты подтвердят или опровергнут гипотезу.

Артефакты, которые стоит поручить ИИ (с вашей проверкой)

ИИ хорошо делает «черновики»:

• user stories в формате «Как [роль], я хочу [действие], чтобы [ценность]»
• acceptance criteria в стиле Given/When/Then
• матрицу рисков (вероятность × ущерб) с митигациями

Мини-шаблон запроса к ИИ:

Сформулируй user stories и acceptance criteria.
Контекст: [аудитория], [основной сценарий], [ограничения], [данные].
Критерии успеха: [метрики].
Не делай допущений: если информации не хватает — задай вопросы.

Так вы превращаете диалог с ИИ в управляемый процесс, где требования проверяемы, а не «на глаз».

Проектирование и архитектура при поддержке ИИ

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

Черновые архитектурные варианты и их сравнение

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

Удобный приём — попросить ИИ сделать таблицу компромиссов и отдельно перечислить, какие факты нужно проверить на практике (PoC, нагрузочный тест, оценка SLA у облака).

Выбор технологий: вопросы, которые стоит задать ИИ

Чтобы рекомендации не превратились в список модных инструментов, задавайте вопросы в формате ограничений:

• Какие требования к масштабированию и отказоустойчивости это решение реально закрывает?
• Какие зависимости и скрытые издержки появятся через 6–12 месяцев?
• Какие навыки нужны команде и что станет узким местом в найме?
• Как будет устроено наблюдение: логи, метрики, трассировка?

Проектирование интерфейсов и контрактов API

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

Фиксация решений: ADR и диаграммы, которые легко обновлять

Сильная сторона ИИ — поддерживать актуальность артефактов. Попросите его оформить ADR (Architecture Decision Record): контекст, решение, альтернативы, последствия, критерии пересмотра.

Диаграммы (например, C4) можно держать в текстовом виде, чтобы ИИ обновлял их вместе с изменениями в требованиях и модулях — при условии, что финальную версию утверждает команда.

Промптинг как новый навык команды разработки

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

Промпт как инженерное ТЗ в миниатюре

Полезно мыслить промптами как короткими спецификациями. В них стоит явно фиксировать:

• Цель: что именно нужно получить (план, набросок API, варианты решений).
• Контекст: язык, стек, существующие ограничения проекта, кто пользователь.
• Ограничения: производительность, безопасность, совместимость, стиль кода.
• Критерии приемки: что будет считаться «правильным» результатом.

Например: «Сгенерируй варианты архитектуры, но не предлагай новые внешние сервисы, используй текущие компоненты, учти лимит 200 мс на ответ». Это сразу отсеивает половину нерелевантных идей.

Паттерн: сначала план — потом код — потом проверка

Чтобы ИИ не переходил сразу к коду, задавайте последовательность:

1. попросить краткий план и список допущений;
2. после согласования — код или псевдокод;
3. затем — самопроверку: тест-кейсы, риски, что могло быть упущено.

Этот порядок дисциплинирует и человека: проще заметить спорные предположения, пока они не превратились в реализацию.

Примеры и edge cases — топливо для точности

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

Библиотека промптов: командный актив

Собирайте шаблоны (для дизайна API, генерации тестов, проверки требований) и храните их рядом с проектом — например, в репозитории. Добавляйте пометки: «когда использовать», «типовые ошибки», «пример удачного результата». Так промптинг становится масштабируемым навыком команды, а не личной магией отдельных разработчиков.

Кодинг с ИИ: ускорение без потери качества

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

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

Генерация каркаса проекта и типового кода

Самая заметная экономия времени — в стартовой фазе. ИИ может набросать структуру модулей, типовые CRUD-операции, обёртки для логирования, конфиги окружений, шаблоны API‑эндпоинтов, базовые модели данных.

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

Переписывание: читаемость, стиль, единообразие

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

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

Рефакторинг: безопасные шаги и критерии готовности

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

Ограничения: почему не стоит копировать без понимания

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

Тестирование и качество: делегируем ИИ проверку, а не доверие

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

Генерация тест-кейсов из требований и сценариев

Если у вас есть пользовательские истории, критерии приёмки и простые сценарии («пользователь оформляет заказ», «меняет тариф», «восстанавливает доступ»), ИИ может:

• разложить сценарий на шаги и ожидаемые результаты;
• предложить граничные случаи (пустые значения, максимальные лимиты, таймауты, повторы);
• составить матрицу проверок по ролям и правам доступа.

Важно: просите ИИ ссылаться на конкретные пункты требований и помечать допущения. Всё, что было добавлено без опоры на спецификацию, должно уйти в вопросы, а не в тест‑план.

Юнит-, интеграционные и e2e тесты: где ИИ сильнее

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

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

ИИ как инструмент поиска «дыр» в спецификации

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

Связка с CI: проверки до слияния

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

• автозапуск тестов и линтеров для каждого pull request;
• пороги качества (покрытие, критичные проверки безопасности, статический анализ);
• автоматические отчёты о регрессиях до слияния изменений.

Так ИИ помогает быстрее находить проблемы, а команда не переносит контроль качества на «магический чёрный ящик».

Код-ревью и стандарты: как снизить количество ошибок

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

ИИ как второй рецензент: чек‑листы для ревью

Дайте ИИ понятный чек‑лист — тогда он будет проверять одно и то же из раза в раз:

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

Практика: просите ИИ приводить примеры «до/после» и выделять риск в терминах влияния (что сломается, где проявится, как воспроизвести).

Статический анализ, линтеры и правила как «страховка»

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

Как писать комментарии к ревью: конкретно и измеримо

Полезный комментарий отвечает на три вопроса: где, что не так, как проверить исправление. Вместо «плохой код» — «в функции X на входе null приведёт к исключению; добавь проверку и тест на кейс Y». ИИ можно просить переформулировать замечания в таком формате.

Процесс «сначала исправь — потом объясни — потом упрости»

Чтобы не утонуть в дискуссиях, применяйте порядок:

1. исправь минимально, чтобы стало безопасно и корректно;
2. коротко объясни, почему так (для истории в PR);
3. упрости: рефакторинг и косметика — отдельным коммитом.

Так ревью остаётся быстрым, а качество растёт предсказуемо.

Безопасность, приватность и соответствие требованиям

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

Если вы работаете с чувствительными данными, заранее выбирайте инструменты с подходящей моделью развертывания и хранения: например, TakProsto.AI работает на серверах в России и использует локализованные open-source LLM‑модели, что помогает снижать риск передачи данных за пределы контура.

Риски утечки данных: что нельзя отправлять в запросы

Главное правило: в промпты не попадает ничего, что вы не готовы увидеть в публичном отчёте.

К запретным категориям обычно относят: секреты (токены, ключи, пароли), персональные данные, внутренние URL и IP, конфиденциальные документы, содержимое продакшн‑логов, а также детали уязвимостей до их исправления.

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

Моделирование угроз: как ИИ помогает составить список

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

Проверка зависимостей и лицензий: что автоматизировать

Зависимости — частый источник рисков. Автоматизируйте:

• сканирование уязвимостей в библиотеках и контейнерах;
• контроль лицензий (запрещённые/несовместимые);
• обновления с понятным отчётом «что изменилось и почему».

ИИ может объяснять результаты сканов и предлагать безопасные альтернативы, но решения о принятии риска и сроках обновления должны быть формальными (политика, тикет, ответственный).

Принцип: доверяй результатам только после верификации

ИИ — не источник истины. Любая рекомендация проверяется: воспроизведением, тестами, статическим анализом, ревью и сверкой с требованиями (например, 152‑ФЗ/PCI DSS/внутренние политики). Удобно закрепить это в чек‑листе pull request и в правилах работы команды (см. /security-policy).

Документация и передача знаний с помощью ИИ

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

Какие документы проще всего поддерживать с ИИ

Начните с набора, который реально читают:

• README: цель проекта, быстрый старт, основные команды.
• ADR (Architecture Decision Records): почему выбрали именно это решение, какие были альтернативы, последствия.
• Runbook: как запускать, мониторить, реагировать на инциденты.
• FAQ: ответы на повторяющиеся вопросы команды и поддержки.

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

Автогенерация примеров и инструкций

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

• сгенерировать варианты примеров использования API/CLI (включая типовые ошибки);
• подготовить шаблоны для новых модулей, эндпоинтов, компонентов;
• собрать «путь новичка»: от клонирования репозитория до первого успешного запуска.

Важно: примеры должны быть проверяемыми. Хорошая практика — хранить их как «исполняемую документацию» (скрипты/сниппеты, которые прогоняются в CI), а ИИ использовать для первичного текста и вариантов.

Как привязать документацию к коду и релизам

Чтобы документация не устаревала, связывайте её с изменениями:

• обновляйте ADR и runbook в той же ветке, где меняется поведение;
• добавляйте ссылки на PR/issue и номер релиза;
• используйте шаблоны PR с чеклистом «доки обновлены».

ИИ можно попросить: «посмотри diff и предложи, что нужно поправить в README/runbook». А дальше человек утверждает правки.

Где хранить и как связывать внутри команды

Сделайте единый вход: /docs, а также ссылки на процессы и инструкции, например /blog/guide-to-ci. Когда ИИ генерирует текст, просите его сразу добавлять внутренние ссылки и раздел «связанные материалы» — так знания перестают быть разрозненными и превращаются в навигацию по продукту.

Команда будущего: навыки, роли и план внедрения

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

Ключевые навыки

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

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

Новые роли в команде

Появляются функции, которые раньше были размыты:

• AI‑партнёр по разработке (роль, а не человек): ведёт диалог с ИИ, уточняет вводные, собирает варианты решения и оформляет их в задачи/PR.
• Куратор качества: следит, чтобы использование ИИ не ухудшало тесты, наблюдаемость, безопасность и стиль.
• Владелец контекста: хранит продуктовые и технические решения, ограничения домена, «почему мы сделали так», чтобы ИИ не тянул команду в неверную сторону.

Найм и онбординг

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

Как начать внедрение

Начните с пилотного проекта на 2–4 недели: ограниченный участок кода, ясные критерии успеха. Выберите метрики (время цикла, доля отклонённых PR, дефекты после релиза) и договоритесь о правилах: где ИИ разрешён, как помечать сгенерированный код, кто и как его проверяет. После пилота зафиксируйте практики в командном гайде и масштабируйте постепенно.