Практичный взгляд на будущее создания ПО: как разделять роли между людьми и ИИ, выстроить процесс, снизить риски и повысить качество результата.
«Создавать ПО вместе с ИИ» — это не история про замену разработчиков, аналитиков или тестировщиков. Это про изменение способа работы: часть действий, которые раньше делались вручную и занимали часы, выполняется быстрее за счёт ИИ, а люди остаются теми, кто определяет смысл, несёт ответственность и отвечает за финальное качество.
ИИ хорошо справляется с генерацией вариантов и рутинными преобразованиями: черновики требований, примеры API, шаблоны тестов, пояснения к коду, предложения по улучшению. Но он не «понимает бизнес» сам по себе и не несёт последствий.
Продуктивная модель — партнёрство: человек формулирует цель, критерии успеха и ограничения, а ИИ ускоряет путь к решению.
Быстрее всего эволюционируют этапы, где много текста, повторяемости и типовых проверок:
Это не означает, что «всё будет сделано автоматически». Скорее, у команды появляется возможность быстрее пройти черновую стадию и потратить больше времени на проверку гипотез и качество.
Есть области, где ответственность нельзя «делегировать» модели:
Главная идея проста: человек задаёт цель и критерии, а ИИ помогает быстрее пройти путь — предложить варианты, ускорить подготовку артефактов и подсветить потенциальные проблемы. Но доверие к результату не «автоматизируется»: его нужно заслуживать проверками, правилами и ответственными решениями команды.
Совместная разработка с ИИ работает лучше всего, когда роли распределены не «по моде», а по ответственности. ИИ‑ассистент программиста может заметно ускорить процессы разработки, но смысл, приоритеты и риски остаются на стороне команды.
Человек отвечает за цель и контекст: зачем мы делаем продукт, какие компромиссы приемлемы, где нельзя ошибаться. Это включает выбор критериев успеха, согласование требований с бизнесом и пользователями, а также финальное решение при конфликте вариантов.
Если решение повлияет на клиентов, деньги, безопасность или репутацию — команда должна уметь объяснить, почему сделала именно так, а не иначе.
ИИ хорош там, где нужно быстро перебрать варианты и снять рутину:
В этих задачах «правильность» часто подтверждается экспериментом или тестами, а не авторитетом.
Любое предложение ИИ должно быть проверяемым: через тесты, измерения производительности, статический анализ, чек‑листы безопасности. Если решение нельзя нормально проверить — требуйте объяснение: какие допущения сделаны, какие альтернативы отвергнуты, какие риски остаются.
Главная ловушка — принимать сгенерированное как готовое. Рабочая привычка: сначала сформулировать своё ожидание (что должно получиться и почему), затем сравнить с ответом ИИ, и только после этого интегрировать изменения маленькими порциями. Так контроль остаётся у команды, а ускорение — у инструмента.
ИИ помогает быстрее превращать идеи в понятные требования — но только если команда даёт ему ясный «вход». Хорошая постановка задачи для ИИ почти не отличается от хорошей постановки задачи для людей: меньше предположений, больше проверяемых формулировок.
Опишите, какую боль решаем и для кого, затем зафиксируйте критерии успеха в цифрах или наблюдаемых результатах. Вместо «сделать удобнее» — «уменьшить время оформления заявки с 4 минут до 2» или «снизить долю обращений в поддержку по теме X на 20%». ИИ можно попросить предложить варианты метрик, но выбрать и утвердить их должны вы.
Перед тем как просить ИИ формализовать требования, дайте ему рамки:
Чем конкретнее контекст, тем меньше «галлюцинаций» и спорных допущений.
Если требований пока нет, оформляйте предположения как гипотезы: «если добавим автозаполнение, конверсия вырастет». Попросите ИИ предложить минимальные эксперименты: прототип, A/B, фейковый экран, опрос — и заранее определите, какие результаты подтвердят или опровергнут гипотезу.
ИИ хорошо делает «черновики»:
Мини-шаблон запроса к ИИ:
Сформулируй user stories и acceptance criteria.
Контекст: [аудитория], [основной сценарий], [ограничения], [данные].
Критерии успеха: [метрики].
Не делай допущений: если информации не хватает — задай вопросы.
Так вы превращаете диалог с ИИ в управляемый процесс, где требования проверяемы, а не «на глаз».
ИИ особенно полезен на этапе проектирования: он быстро генерирует варианты, помогает сравнивать компромиссы и подсвечивает риски, которые команда может упустить в спешке. Но ключевое правило остаётся прежним: архитектуру выбирают люди, потому что ответственность за последствия — тоже на людях.
Попросите ИИ предложить 2–4 наброска архитектуры под одну и ту же задачу (например, монолит, модульный монолит, микросервисы, event-driven). Затем уточните критерии сравнения: стоимость изменений, сложность эксплуатации, требования к команде, риски блокировок, деградация производительности.
Удобный приём — попросить ИИ сделать таблицу компромиссов и отдельно перечислить, какие факты нужно проверить на практике (PoC, нагрузочный тест, оценка SLA у облака).
Чтобы рекомендации не превратились в список модных инструментов, задавайте вопросы в формате ограничений:
ИИ хорошо ускоряет проработку контрактов: схемы DTO, варианты версионирования, правила идемпотентности, коды ошибок, примеры запросов/ответов. Полезно также попросить его найти «неочевидные» сценарии: частичные отказы, таймауты, повторные запросы, конкурирующие обновления.
Сильная сторона ИИ — поддерживать актуальность артефактов. Попросите его оформить ADR (Architecture Decision Record): контекст, решение, альтернативы, последствия, критерии пересмотра.
Диаграммы (например, C4) можно держать в текстовом виде, чтобы ИИ обновлял их вместе с изменениями в требованиях и модулях — при условии, что финальную версию утверждает команда.
Промптинг в разработке — это не «умение красиво спросить», а часть инженерной дисциплины. Хороший промпт снижает число итераций, делает ответы ИИ воспроизводимыми и помогает команде говорить об одном и том же: цели, контексте и ограничениях.
Полезно мыслить промптами как короткими спецификациями. В них стоит явно фиксировать:
Например: «Сгенерируй варианты архитектуры, но не предлагай новые внешние сервисы, используй текущие компоненты, учти лимит 200 мс на ответ». Это сразу отсеивает половину нерелевантных идей.
Чтобы ИИ не переходил сразу к коду, задавайте последовательность:
Этот порядок дисциплинирует и человека: проще заметить спорные предположения, пока они не превратились в реализацию.
Лучше всего работают промпты с примерами входов/выходов и перечнем пограничных случаев: пустые значения, дубликаты, неверные форматы, конкурентные обновления. Просите ИИ явно перечислить, какие случаи он покрыл, а какие — нет.
Собирайте шаблоны (для дизайна API, генерации тестов, проверки требований) и храните их рядом с проектом — например, в репозитории. Добавляйте пометки: «когда использовать», «типовые ошибки», «пример удачного результата». Так промптинг становится масштабируемым навыком команды, а не личной магией отдельных разработчиков.
ИИ в кодинге лучше всего работает как «ускоритель рутины»: он быстро предлагает заготовки, варианты реализации и улучшения, а человек сохраняет контроль над смыслом, рисками и качеством.
На практике помогает, когда ассистент встроен в поток работы: например, в TakProsto.AI можно вести диалог в режиме планирования, быстро собирать прототипы веб/бэкенд/мобайл, а затем при необходимости экспортировать исходники и продолжать работу в привычном процессе.
Самая заметная экономия времени — в стартовой фазе. ИИ может набросать структуру модулей, типовые CRUD-операции, обёртки для логирования, конфиги окружений, шаблоны API‑эндпоинтов, базовые модели данных.
Чтобы результат был полезным, задавайте контекст: язык, фреймворк, стиль проекта, ограничения по зависимостям, требования к ошибкам и валидации. Чем конкретнее вход, тем меньше «магии» и больше предсказуемости.
ИИ хорошо переписывает код так, чтобы его было легче сопровождать: сокращает дублирование, делает именование последовательным, приводит к единому стилю, добавляет понятные сообщения об ошибках.
Полезный приём — попросить не просто «улучшить», а объяснить изменения: что было не так, почему стало лучше, какие компромиссы появились. Так команда сохраняет понимание, а не получает «чёрный ящик».
Для рефакторинга используйте ИИ как помощника по плану: предложить маленькие шаги, список затрагиваемых файлов, критерии готовности и точки отката. Хорошая практика — сначала зафиксировать ожидаемое поведение (примеры вход/выход), затем менять реализацию поэтапно, проверяя на каждом шаге.
Слепое копирование кода от ИИ повышает риск скрытых ошибок, уязвимостей и несовместимости с архитектурой проекта. Правило простое: если вы не можете объяснить фрагмент кода и его последствия, он не готов к продакшену. ИИ ускоряет написание, но ответственность за выбор решения и его влияние остаётся за командой.
ИИ хорошо масштабируется на рутинных проверках: быстро перебирает варианты, сопоставляет сценарии и ищет противоречия. Но ответственность за качество остаётся у команды: ИИ может подсказать, где смотреть, а решение «это достаточно хорошо для релиза» принимает человек.
Если у вас есть пользовательские истории, критерии приёмки и простые сценарии («пользователь оформляет заказ», «меняет тариф», «восстанавливает доступ»), ИИ может:
Важно: просите ИИ ссылаться на конкретные пункты требований и помечать допущения. Всё, что было добавлено без опоры на спецификацию, должно уйти в вопросы, а не в тест‑план.
ИИ обычно лучше всего помогает на уровне юнит- и интеграционных тестов: генерирует заготовки, предлагает наборы данных, быстро покрывает ветвления и ошибки обработки.
Для e2e тестов польза тоже есть, но риск выше: такие тесты чувствительны к окружению и часто «ломаются» из‑за мелких изменений интерфейса. Здесь ИИ полезнее как помощник в написании стабильных локаторов, подготовке тестовых данных и анализе падений.
Хорошая практика — попросить ИИ сыграть роль придирчивого тестировщика и задать вопросы: что происходит при отмене операции, частичной оплате, двойном клике, повторной отправке, разрыве сети? Такие вопросы часто выявляют пробелы в требованиях раньше, чем баги в коде.
Максимальная отдача появляется, когда результаты работы ИИ попадают в CI:
Так ИИ помогает быстрее находить проблемы, а команда не переносит контроль качества на «магический чёрный ящик».
Код‑ревью в команде с ИИ работает лучше всего, когда ИИ не «судья», а второй рецензент: он быстро находит типовые промахи, а человек принимает решения и отвечает за последствия. Секрет в том, чтобы ревью опиралось на стандарты, а не на вкусовщину.
Дайте ИИ понятный чек‑лист — тогда он будет проверять одно и то же из раза в раз:
Практика: просите ИИ приводить примеры «до/после» и выделять риск в терминах влияния (что сломается, где проявится, как воспроизвести).
ИИ хорош в обсуждении, но гарантии дают автоматические правила. Линтеры, форматтеры, статический анализ и проверки в CI превращают часть замечаний в объективные требования: «не прошло — нельзя мержить». Это снижает нагрузку на ревью и убирает спорные комментарии.
Полезный комментарий отвечает на три вопроса: где, что не так, как проверить исправление. Вместо «плохой код» — «в функции X на входе null приведёт к исключению; добавь проверку и тест на кейс Y». ИИ можно просить переформулировать замечания в таком формате.
Чтобы не утонуть в дискуссиях, применяйте порядок:
Так ревью остаётся быстрым, а качество растёт предсказуемо.
Совместная разработка с ИИ ускоряет работу, но повышает цену ошибки: один неосторожный запрос может раскрыть коммерческие тайны, персональные данные или детали уязвимостей. Поэтому безопасность — это не «настройка в конце», а правила общения с ИИ и проверки на каждом шаге.
Если вы работаете с чувствительными данными, заранее выбирайте инструменты с подходящей моделью развертывания и хранения: например, TakProsto.AI работает на серверах в России и использует локализованные open-source LLM‑модели, что помогает снижать риск передачи данных за пределы контура.
Главное правило: в промпты не попадает ничего, что вы не готовы увидеть в публичном отчёте.
К запретным категориям обычно относят: секреты (токены, ключи, пароли), персональные данные, внутренние URL и IP, конфиденциальные документы, содержимое продакшн‑логов, а также детали уязвимостей до их исправления.
На практике помогает простая дисциплина: использовать обезличенные примеры, вырезать секреты, подменять реальные значения фиктивными и хранить «словарь подстановок» рядом с задачей.
ИИ полезен как «ускоритель мышления»: по описанию функции он подскажет типовые угрозы (утечки, подмена данных, злоупотребление ролями, ошибки авторизации) и варианты mitigations. Важно: итоговый список угроз и приоритетов утверждает человек — тот, кто понимает контекст бизнеса и архитектуру.
Зависимости — частый источник рисков. Автоматизируйте:
ИИ может объяснять результаты сканов и предлагать безопасные альтернативы, но решения о принятии риска и сроках обновления должны быть формальными (политика, тикет, ответственный).
ИИ — не источник истины. Любая рекомендация проверяется: воспроизведением, тестами, статическим анализом, ревью и сверкой с требованиями (например, 152‑ФЗ/PCI DSS/внутренние политики). Удобно закрепить это в чек‑листе pull request и в правилах работы команды (см. /security-policy).
Документация обычно страдает не потому, что она «не важна», а потому что ей не хватает регулярности. ИИ помогает сделать её частью потока разработки: не вместо авторов, а как ускоритель — черновики, структурирование, обновления и проверка на несоответствия.
Начните с набора, который реально читают:
ИИ хорошо справляется с превращением «разрозненных знаний из чатов и задач» в связный текст: попросите собрать структуру, выделить допущения, добавить раздел «что может пойти не так».
Самая полезная документация — та, где есть примеры. ИИ можно поручить:
Важно: примеры должны быть проверяемыми. Хорошая практика — хранить их как «исполняемую документацию» (скрипты/сниппеты, которые прогоняются в CI), а ИИ использовать для первичного текста и вариантов.
Чтобы документация не устаревала, связывайте её с изменениями:
ИИ можно попросить: «посмотри diff и предложи, что нужно поправить в README/runbook». А дальше человек утверждает правки.
Сделайте единый вход: /docs, а также ссылки на процессы и инструкции, например /blog/guide-to-ci. Когда ИИ генерирует текст, просите его сразу добавлять внутренние ссылки и раздел «связанные материалы» — так знания перестают быть разрозненными и превращаются в навигацию по продукту.
ИИ в разработке меняет не только скорость работы, но и состав «идеальной» команды. Чтобы выиграть от совместной работы, важно пересобрать навыки, роли и правила взаимодействия — иначе ИИ станет источником шумных правок и скрытых рисков.
На первом месте — умение ставить задачу: формулировать цель, ограничения, входные данные, ожидаемый формат ответа и критерии приемки. Следом — критическое мышление: проверять допущения, выявлять «галлюцинации», сравнивать альтернативы.
Третий навык — проверка результатов. Команда должна привыкнуть к мысли: ИИ может подготовить черновик, но ответственность за итог несут люди. Полезно закрепить привычку «доверяй, но проверяй»: запуск тестов, чтение диффов, контроль безопасности, сверка с требованиями.
Появляются функции, которые раньше были размыты:
В найме стоит оценивать не «умение нажимать кнопку ИИ», а способность кандидата объяснить выбор решения, провести мини‑ревью вывода модели и описать риски. В онбординге полезны чек‑листы: какие источники истины, как оформлять промпты, что запрещено отправлять в ИИ, как фиксировать выводы.
Начните с пилотного проекта на 2–4 недели: ограниченный участок кода, ясные критерии успеха. Выберите метрики (время цикла, доля отклонённых PR, дефекты после релиза) и договоритесь о правилах: где ИИ разрешён, как помечать сгенерированный код, кто и как его проверяет. После пилота зафиксируйте практики в командном гайде и масштабируйте постепенно.
Это подход, где ИИ берёт на себя ускорение рутины и генерацию вариантов (черновики требований, шаблоны кода, идеи тестов, черновики документации), а люди задают цель, контекст и принимают финальные решения.
Практическое правило: ИИ — инструмент повышения скорости, но ответственность за смысл и результат остаётся у команды.
Обычно быстрее всего ускоряются задачи с повторяемостью и большим объёмом текста:
Выигрыш максимальный, если результат можно быстро проверить тестами/экспериментом.
За людьми остаётся то, что нельзя «делегировать» без потери ответственности:
Если команда не может объяснить, почему выбрала решение, оно не готово к продакшену.
Давайте ИИ вводные так же строго, как человеку:
Добавьте требование: «не делай допущений — если не хватает данных, задай вопросы».
Используйте паттерн «план → реализация → проверка»:
Так вы снижаете шанс получить красивое, но неверное решение.
Просите 2–4 альтернативы под одну задачу и фиксируйте критерии сравнения:
Полезно попросить таблицу компромиссов и список фактов, которые надо проверить PoC/нагрузочным тестом.
Лучше всего — как «ускоритель рутины»:
Не копируйте фрагмент, если не можете объяснить его поведение, ограничения и последствия для архитектуры.
Делегируйте ИИ генерацию вариантов проверок, но не доверие к качеству:
Обязательно: привязка к пунктам требований и пометка допущений, чтобы «придуманное» не попадало в тест-план как факт.
Дайте ИИ чек-лист, чтобы ревью было воспроизводимым:
А для гарантий опирайтесь на автоматические правила: линтеры/форматтеры/статический анализ и CI-барьеры «не прошло — нельзя мержить».
Базовое правило: в промпты не отправляйте то, что не готовы увидеть в публичном отчёте.
Нельзя отправлять:
Закрепите это в правилах команды и чек-листе PR (см. /security-policy).