10 сент. 2025 г.·8 мин
Человек + ИИ в создании ПО: практический плейбук для будущего
Практический взгляд на то, как люди и ИИ могут совместно создавать ПО — от идеи до релиза — с понятными ролями, рабочими процессами и защитными мерами.
Практический взгляд на то, как люди и ИИ могут совместно создавать ПО — от идеи до релиза — с понятными ролями, рабочими процессами и защитными мерами.
«Человек + ИИ» — это ко-создание: команда строит ПО, одновременно используя инструменты ИИ (ассистенты по коду и большие языковые модели) как активных помощников на всём протяжении процесса. Речь не о полной автоматизации и не о «нажал кнопку — получил продукт». Думайте об ИИ как о быстром коллеге, который может черновать, предлагать, проверять и резюмировать — а люди остаются ответственными за решения и последствия.
Ко-создание означает, что люди задают цель, определяют, что значит «хорошо», и управляют работой. ИИ даёт скорость и варианты: он может предложить код, сгенерировать тесты, переписать документацию или выявить крайние случаи.
Полная автоматизация означала бы, что ИИ владеет всеми этапами продукта с минимальным человеческим руководством — требования, архитектура, реализация и выпуск — вместе с ответственностью. Большинство команд к этому не стремятся, и многие организации не могут принять такой риск.
ПО — это не только код. Это ещё и бизнес-контекст, потребности пользователей, соответствие правилам, доверие к бренду и стоимость ошибок. ИИ великолепен в создании черновиков и исследовании альтернатив, но он не понимает ваших клиентов, внутренних ограничений и того, что ваша компания может безопасно выпустить. Сотрудничество сохраняет преимущества, обеспечивая соответствие продукта реальным целям.
Можно ожидать заметного выигрыша по скорости при черновой разработке и итерациях — особенно для повторяющейся работы, шаблонного кода и первичных решений. Вместе с тем риски качества приобретают новые формы: убедительно звучащие, но неправильные ответы, тонкие баги, небезопасные шаблоны и ошибки с лицензированием или обработкой данных.
Люди остаются ответственными за:
Дальше идут практические разделы: превращение идей в требования, совместное проектирование системы, парное программирование с ИИ, тестирование и ревью кода, охранительные меры по безопасности и приватности, поддержание актуальной документации и измерение результатов, чтобы следующая итерация была лучше — не только быстрее.
ИИ отлично ускоряет исполнение, превращая хорошо сформулированное намерение в рабочие черновики. Люди по-прежнему лучше формулируют намерение и принимают решения, когда реальность запутана.
При правильном использовании ассистент на базе ИИ может сэкономить время при:
Тема общая: ИИ быстр в генерации кандидатов — черновой код, текст, тест-кейсы.
Люди должны вести в:
ИИ может описывать варианты, но он не владеет результатами. Эта ответственность остаётся за командой.
Относитесь к ИИ как к умному коллеге, который быстро и уверенно делает черновики, но может ошибаться. Проверяйте результаты тестами, ревью, бенчмарками и быстрым сопоставлением с реальными требованиями.
Хорошо: «Вот наша существующая функция и ограничения (задержка < 50ms, требуется сохранять порядок). Предложи рефактор, объясни компромиссы и сгенерируй тесты, доказывающие эквивалентность.»
Плохо: «Перепиши наш middleware аутентификации ради безопасности», а затем скопировать вывод прямо в прод без понимания, моделирования угроз или валидации тестами и логированием.
Победа — не в том, чтобы дать ИИ рулить, а в том, чтобы он ускорял те части, которыми вы уже умеете управлять.
Сотрудничество «Человек + ИИ» работает лучше, когда все понимают, за что отвечают — и за что не отвечают. ИИ может быстро черновать, но он не может нести ответственность за продуктовые результаты, влияние на пользователей или бизнес-риски. Ясные роли предотвращают решения типа «ИИ сказал», и помогают команде двигаться уверенно.
Представляйте ИИ как высокоскоростного участника, который поддерживает каждую функцию, а не заменяет её.
Используйте простую матрицу, чтобы избежать путаницы в тикетах и PR:
Добавьте явные вехи, чтобы скорость не ушла вперёд качества:
Фиксируйте «почему» там, где команда уже работает: комментарии в тикетах для компромиссов, заметки в PR для изменений, сгенерированных ИИ, и краткий changelog для релизов. Когда решения видимы — ответственность очевидна, и будущая работа проще.
Хорошая спецификация продукта — это не «задокументировать всё», а выровнять людей относительно того, что будет сделано, зачем это важно и что значит «готово». С ИИ в процессе вы можете быстрее прийти к тестируемой спецификации — при условии, что человек остаётся ответственным за решения.
Начните с трёх опорных пунктов простым языком:
Попросите ИИ бросить вызов черновику: «Какие предположения я делаю? Что могло бы привести к провалу? Какие вопросы нужно ответить перед началом инженерии?» Относитесь к выводу как к списку задач для валидации, а не к истине.
Попросите модель сгенерировать 2–4 подхода к решению (включая базовую опцию «не делать ничего»). Требуйте, чтобы он указывал:
Вы выбираете направление; ИИ помогает увидеть, что можно упустить.
Держите PRD настолько компактным, чтобы люди его читали:
Пример acceptance criterion: «Аутентифицированный пользователь может экспортировать CSV менее чем за 10 секунд для наборов данных до 50k строк.»
Прежде чем считать спецификацию готовой, подтвердите:
Когда ИИ черновал части PRD, убедитесь, что каждое требование связано с реальной пользовательской потребностью или ограничением — и что подписанный владелец подтвердил это.
Проектирование системы — место, где сотрудничество «Человек + ИИ» может ощущаться особенно мощным: вы быстро исследуете несколько жизнеспособных архитектур, а затем применяете человеческое суждение, чтобы выбрать ту, что подходит под реальные ограничения.
Попросите ИИ предложить 2–4 архитектурных кандидата (например: модульный монолит, микросервисы, serverless, event-driven) и потребуйте структурированное сравнение по стоимости, сложности, скорости доставки, операционному риску и зависимости от вендора. Не принимайте единственный «лучший» ответ — заставьте модель аргументировать обе стороны.
Простой шаблон подсказки:
После выбора направления попросите ИИ перечислить швы, где системы соприкасаются. Пусть он сгенерирует:
Затем проверьте это с людьми: соответствуют ли эти предположения тому, как бизнес реально работает, включая краевые случаи и грязные реальные данные?
Создайте лёгкий decision log (по одной странице на решение) с:
Храните рядом с кодовой базой, чтобы он оставался доступным (например, в /docs/decisions).
До реализации пропишите границы безопасности и правила обработки данных, которые нельзя «оптимизировать» иначе, такие как:
ИИ может черновать эти политики, но люди должны владеть ими — потому что ответственность не делегируется.
Парное программирование с ИИ лучше всего работает, когда вы относитесь к модели как к младшему коллеге: быстро предлагает варианты, но слабо понимает вашу уникальную кодовую базу, если вы его не научите. Цель — не «пусть ИИ напишет приложение», а плотный цикл, в котором люди направляют, а ИИ ускоряет.
Если вы хотите, чтобы этот рабочий цикл был более «end-to-end», чем отдельный код-ассистент, платформы с vibe-coding, такие как Koder.ai, могут помочь: вы описываете фичу в чате, итеративно двигаетесь мелкими шагами и при этом сохраняете человеческие вехи — платформа генерирует каркас для веба (React), бэкенда (Go + PostgreSQL) или мобильных приложений (Flutter) с экспортируемым исходным кодом.
Прежде чем просить код, предоставьте ограничения, которые обычно человек узнаёт из репозитория:
Полезный шаблон подсказки:
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
Обратите внимание: блок кода выше оставлен без перевода — это пример шаблона подсказки, который следует передавать ИИ в исходном виде.
Ограничивайте объём: одна функция, один эндпойнт, один компонент. Меньшие куски легче верифицировать, избегают скрытых регрессий и сохраняют ясность ответственности.
Хороший ритм:
ИИ хорош в генерации шаблонного кода, сопоставлении полей, создании типизированных DTO, простых UI-компонентов и механическом рефакторинге. Люди должны:
Правило: сгенерированный код должен быть проверен, как и любой другой вклад. Запустите его, прочитайте, протестируйте и убедитесь, что он соответствует соглашениям и ограничениям. Если вы не можете объяснить, что он делает — он не идёт в релиз.
Тестирование — место, где «Человек + ИИ» может быть особенно практичным. ИИ может генерировать идеи, каркасы и объём; люди дают намерение, суждение и ответственность. Цель — не больше тестов, а больше уверенности.
Хорошая подсказка превращает LLM в неутомимого тест-партнёра. Попросите его предложить краевые случаи и режимы отказа, которые вы можете пропустить:
Относитесь к этим предложениям как к гипотезам. Люди решают, какие сценарии важны, исходя из риска продукта и воздействия на пользователей.
ИИ быстро черновит unit и integration тесты, но вы должны проверить два момента:
Полезный рабочий цикл: вы описываете поведение простым языком, ИИ предлагает тест-кейсы, вы шлифуете их в небольшой читабельный набор тестов. Если тест трудно понять — это сигнал, что требование неясно.
ИИ может помочь создать правдоподобные тестовые данные — имена, адреса, счета, логи — но никогда не используйте реальные данные клиентов. Предпочитайте синтетические наборы, обезличенные фикстуры и явно отмеченные «фейковые» значения. Для регулируемых контекстов документируйте, как производятся и хранятся тестовые данные.
В AI-assisted цикле код может выглядеть «готовым» очень быстро. Сделайте «готово» общим контрактом:
Этот стандарт не даст скорости перегнать безопасность и превратит ИИ в мультипликатор, а не в лазейку.
ИИ может ускорить ревью, взяв на себя «первую проходку»: резюмирование изменений, выявление несоответствий и предложение небольших улучшений. Но цель ревью не меняется: защищать пользователей, бизнес и здоровье кодовой базы.
Хорошо использованный ИИ — генератор чек-листа для прерентий ревью:
Это особенно полезно в больших PR — ИИ укажет 3–5 областей с реальным риском.
ИИ может уверенно ошибаться, поэтому люди несут ответственность за:
Полезное правило: относитесь к фидбеку ИИ как к умному стажёру — используйте, но всегда проверяйте важное.
Вставьте diff PR (или ключевые файлы) и попробуйте:
Попросите авторов добавить короткую заметку в PR:
Такая прозрачность превращает ИИ из чёрного ящика в документированную часть инженерного процесса.
ИИ ускоряет доставку, но он же ускоряет и ошибки. Цель — не «меньше доверять», а быстрее проверять с помощью явных guardrails, которые сохраняют качество, безопасность и соответствие.
Галлюцинации: модель может выдумывать API, флаги конфигурации или «факты» о вашей кодовой базе.
Небезопасные паттерны: предложения могут содержать небезопасные дефолты (разрешительный CORS, слабая криптография, отсутствие проверок) или часто встречающиеся, но рискованные фрагменты.
Лицензионная неопределённость: сгенерированный код может напоминать код с лицензией, а предложенные зависимости — ввести вирусные или ограничительные условия.
Обращайтесь с выводом ИИ как с любым другим сторонним вкладом:
Держите результаты видимыми: прокидывайте выводы в те же проверки PR, которые разработчики уже видят, так безопасность станет частью «готово», а не отдельной фазой.
Пропишите и соблюдайте правила:
Если предложение ИИ идёт вразрез со спеком, политикой безопасности или правилом соответствия:
Хорошая документация — не отдельный проект, это «операционная система» команды: как строят, доставляют и поддерживают ПО. Лучшие команды «Человек + ИИ» считают docs приоритетом и используют ИИ, чтобы поддерживать их в актуальном состоянии.
ИИ отлично годится для первичных версий:
Люди проверяют точность, убирают допущения и добавляют контекст, известный только команде — что такое «хорошо», что рискованно и что сознательно вне объёма.
После спринта или релиза ИИ может переводить коммиты и PR в релиз-ноты для клиентов: что изменилось, почему это важно и нужны ли какие-то действия.
Практика: дайте ИИ набор входных данных (заголовки merged PR, ссылки на задачи и короткая заметка «что важно») и запросите два варианта вывода:
Затем человек-ответственный редактирует тон, точность и месседж.
Документация устаревает, когда она отделена от кода. Привязывайте docs к работе:
Если у вас есть публичный продуктный сайт, используйте внутренние относительные ссылки, чтобы уменьшить повторы и направлять читателей к стабильным ресурсам — например, /pricing для деталей планов или /blog для развёрнутых объяснений.
Если вы не измеряете влияние помощи ИИ, разговоры сведутся к ощущениям: «Кажется быстрее» vs «Кажется рискованно». Трактуйте доставку с ИИ как любое другое изменение процесса — трассируйте, ревью и корректируйте.
Начните с небольшой группы метрик, отражающих реальные результаты, а не новизну:
Сопоставьте это с пропускной способностью ревью (время цикла PR, количество раундов ревью), чтобы понять, уменьшает ли ИИ узкие места или добавляет откатную работу.
Не маркируйте работу «ИИ» или «человеческую» морально. Маркируйте, чтобы учиться.
Практика: помечайте задачи/PR простыми флагами:
Затем сравнивайте результаты: быстрее ли проходят изменения с ИИ? Генерируют ли они больше последующих PR? Связаны ли они с откатами? Цель — найти точки высокой отдачи и зоны опасности.
Если вы оцениваете платформы, а не только ассистентов, включите в критерии «снижающие переработку» возможности: снимки/откат, деплой/хостинг и возможность экспортировать исходники. Именно поэтому команды используют Koder.ai не только для прототипирования: вы можете итеративно работать в чате и при этом сохранять привычные контролли (ревью, CI, релизные ворота) и чистый путь экспорта в стандартный репозиторий.
Создайте лёгкую «систему обучения» для команды:
Держите это практичным и актуальным — обновляйте в ретроспективах, а не раз в квартал как отдельный проект.
Ожидайте развития ролей. Инженеры будут больше времени тратить на формулирование проблем, управление рисками и принятие решений, и меньше — на механический перевод намерения в синтаксис. Новые навыки важны: писать понятные спеки, оценивать выводы ИИ, понимать безопасность/лицензирование и обучать команду через примеры. Непрерывное обучение перестаёт быть опцией — это часть рабочего процесса.
Это рабочий процесс совместного создания, в котором люди определяют намерение, ограничения и критерии успеха, а ИИ помогает генерировать варианты (черновой код, идеи для тестов, документацию, рефакторы). Люди остаются ответственными за решения, ревью и то, что выпускается в прод.
Ко-создание значит, что люди управляют работой: задают цели, выбирают компромиссы и проверяют результаты. Полная автоматизация означала бы, что ИИ сам ведёт сбор требований, архитектуру, реализацию и релиз, а также несёт ответственность — что большинство команд не готово и не может безопасно принять.
ИИ ускоряет исполнение, но ПО включает бизнес-контекст, потребности пользователей, соответствие требованиям и управление рисками. Сотрудничество позволяет командам получить выигрыш в скорости, сохранив выравнивание с реальностью, политиками и тем, что организация может безопасно поставлять.
Ожидайте более быстрой работы при черновой разработке и итерациях — особенно для шаблонной работы и первичных решений. Но появятся новые режимы ошибок:
Решение — более жёсткая верификация (тесты, контрольные вехи, проверки безопасности), а не слепое доверие.
Люди должны сохранять ответственность за:
ИИ может предлагать варианты, но не должен считаться «владельцем» результатов.
Высокоэффективные области:
Общая тема: ИИ быстро создаёт черновые варианты; решения принимает человек и проводит валидацию.
Разбивайте работу на маленькие, ограниченные задачи. Давайте реальный контекст (фрагменты кода, соглашения, ограничения, definition of done) и просите вернуть патч-дифф и список рисков. Избегайте больших переработок; итеративно двигайтесь по кускам, чтобы можно было верифицировать поведение на каждом шаге.
Относитесь к выводу ИИ как к предложению от быстрого коллеги:
Простое правило: никакого тихого копирования/вставки в прод.
Используйте простую модель ответственности «Решает / Черновик / Проверяет»:
Добавьте явные вехи (спек, дизайн, реализация, безопасность, релиз), чтобы скорость не перегнала качество.
Ключевые меры предосторожности:
Если совет ИИ противоречит требованиям или политике — эскалируйте к владельцу кода/ревьюеру по безопасности и зафиксируйте решение.
| Activity | Who decides | Who drafts | Who verifies |
|---|
| Problem statement & success metrics | Product | Product + AI | Product + Eng |
| UX flows & UI spec | Design | Design + AI | Design + Product |
| Technical approach | Engineering | Engineering + AI | Engineering lead |
| Test plan | Engineering | Eng + AI | QA/Eng |
| Release readiness | Product + Eng | Eng | Product + Eng |