Два года назад для создания веб-приложения требовались знания языка программирования, фреймворков, баз данных, навыки деплоя и отладки. Сегодня достаточно уметь сформулировать задачу.
ИИ радикально снизил порог входа в разработку. Это не гипотеза — это статистика:
- 63% пользователей, практикующих вайбкодинг, идентифицируют себя как не-разработчики (Second Talent, 2026)
- Gartner прогнозирует, что к 2026 году «citizen developers» превысят число профессиональных разработчиков в соотношении 4:1 (VentureBeat/Gartner)
- 51% всего кода, закоммиченного на GitHub в начале 2026 года, был сгенерирован или существенно написан с помощью ИИ (BetaNews)
- 70% новых корпоративных приложений создаются «citizen developers», а не IT-командами (Gartner via Kissflow)
Маркетологи строят лендинги. Аналитики пишут дашборды. Владельцы бизнеса собирают CRM-интеграции. Энтузиасты создают полноценные приложения. Все это — без единой строчки кода, написанной вручную.
Звучит как революция. И она уже произошла.
Но у революции есть обратная сторона.
Как разрабатывают с ИИ?
Типичный подход к ИИ-разработке выглядит так:
- Человек описывает задачу
- ИИ пишет код
- Человек проверяет — работает ли
- Если нет — отправляет ошибку обратно в чат
- Повторять до результата
В лучшем случае добавляется этап планирования: человек просит ИИ составить план, а потом реализовать его. Выглядит разумно. Работает — тоже, в каком-то проценте случаев.
Этот подход называется «прямой разработкой». Задача → код → результат. Минимум промежуточных шагов. Максимум скорости. Ощущение продуктивности зашкаливает.
И в этом — проблема.
«Но я разрабатывал с таким подходом, и меня устраивает результат. Что не так?»
Если вы подумали это — вы не одиноки. Делаешь запрос, ИИ выдает код, код работает. В чём проблема?
Проблема называется «ошибка выжившего».
Что видите вы
Ваш проект. Он работает. ИИ помог написать его быстро. Вы довольны.
Что вы не видите
Тысячи проектов, где такой подход привел к повторяющимся проблемам.
Код, который сломался при первом изменении требований. ИИ пишет код под задачу «как она звучит сейчас». Заказчик говорит: «Добавь фильтр по дате» — ИИ добавляет. Потом: «А теперь по диапазону» — и выясняется, что вся логика захардкожена, селект зашит в HTML, данные приходят одним запросом без пагинации. Менять — проще переписать. Это не гипотеза, это типичный результат прямого подхода.
Архитектура, где всё связано со всем. Профессиональные разработчики знают термин «спагетти-код», но ИИ создаёт его новую форму — «спагетти с красивой сервировкой». Код выглядит аккуратно: чистые имена, структурированные файлы. Но внутри — компонент авторизации напрямую дергает таблицу заказов, обработчик формы пишет в три базы, бизнес-логика живёт в контроллере. Нет границ, нет слоёв абстракции, нет разделения ответственности. Почему это катастрофа? Потому что изменение в одном месте ломает три других. Нельзя заменить одну часть, не переписав остальные. Нельзя тестировать изолированно. ИИ не видит в этом проблемы — он не мыслит архитектурой, он генерирует файл за файлом.
Безопасность, которой нет. Исследование Стэнфордского университета (Do Users Write More Insecure Code with AI Assistants?) показало: разработчики с ИИ-ассистентами писали менее безопасный код — и при этом были уверены в его защищённости. ИИ не ставит валидацию на ввод, не экранирует SQL, оставляет XSS-дыры, генерирует API-эндпоинты без авторизации. Хуже того — прописывает API-ключи и пароли прямо в коде. По данным GitGuardian, в публичных репозиториях GitHub за один только 2023 год обнаружено 12,8 млн новых секретов — рост на 28%.
А последствия реальны. 2024 год стал рекордным по масштабу утечек: National Public Data (~2,9 млрд записей), Snowflake-атаки на Ticketmaster (~560 млн) и AT&T (~110 млн), Change Healthcare (~100 млн человек). По данным IBM Cost of a Data Breach Report 2024, средняя стоимость утечки — $4,88 млн, а если она связана с ИИ-системами — $5,17 млн. Среднее время обнаружения утечки через украденные учётные данные — 292 дня. Почти год незамеченного доступа к данным.
Когда ИИ генерирует эндпоинт /api/users без проверки токена — это не «мелкий недочёт». Это открытая дверь. А вы её не увидите, потому что код выглядит аккуратно и приложение работает.
Технический долг, который делает развитие невозможным. Технический долг — это когда ради скорости принимается не лучшее, а самое быстрое решение. Как кредит: берёшь сейчас — платишь потом, с процентами. Скопировал функцию вместо выноса в модуль — долг. Захардкодил ID вместо конфига — долг. Пропустил обработку ошибок — долг. Каждое такое решение по отдельности — мелочь. Вместе — снежный ком, который в какой-то момент делает любое изменение дороже, чем разработка с нуля. ИИ генерирует технический долг по умолчанию, потому что оптимизирует под «работает сейчас», а не под «будет работать через год».
Зацикливание на исправлении ошибок. Знакомая картина: ИИ написал код, вы нашли баг, отправили ошибку обратно, ИИ «исправил» — и сломал что-то другое. Отправляете новую ошибку — ИИ исправляет, ломая первое исправление. И так по кругу: 5, 10, 20 итераций — а проблема не решается, потому что корень не в строке, а в неправильном архитектурном решении, принятом в самом начале. 63% разработчиков хотя бы раз тратили больше времени на отладку ИИ-кода, чем потратили бы, написав с нуля (Second Talent, 2026). Это не баг — это закономерный результат разработки без проектирования.
Заходы в тупик. Ещё хуже зацикливания — момент, когда ИИ заходит в тупик. Контекстное окно забито предыдущими попытками, модель повторяет одни и те же решения, а откатиться не к чему — ни промежуточных коммитов, ни сохранённых точек. Единственный выход — начать новый чат и объяснять всё заново. Или начать проект с нуля — потому что код проще выбросить, чем разобрать.
Почему «прямой подход» не работает
Проблема не в ИИ. Проблема в том, что при прямом подходе пропускаются этапы, которые в традиционной разработке существуют не просто так: исследование, требования, архитектура, безопасность, производительность. Когда вы даёте ИИ задачу напрямую, он не делает ни одного из этих шагов. Он просто генерирует код, который выглядит правильным. А вы подтверждаете — потому что код работает в тестовом сценарии. Ошибка выжившего в чистом виде.
По данным Standish Group CHAOS Report (50 000+ проектов): только 31% IT-проектов завершаются успешно. 39% провалов вызваны плохим сбором требований. В ИИ-разработке проблема острее: ИИ не спросит вас о требованиях. Он не скажет «а вы уверены?». Он просто сделает то, что вы сказали — даже если это неправильно.
Разработка по методикам
Хорошо, ИИ не умеет сам выстраивать процесс. Но что, если дать ему процесс?
Не промпт «сделай фичу», а методику — последовательность этапов с чёткими правилами, артефактами и точками проверки.
Идея не нова. В 2025 году вышла серия статей HumanLayer о том, что ИИ-агентам нужны человеческие контрольные точки, структурированные этапы и документированные решения. AWS выпустили Kiro — IDE с подходом «сначала спецификация, потом код». Superpowers набрал 93 000 звёзд на GitHub как плагин, который не даёт ИИ прыгать сразу в реализацию. Тренд очевиден: индустрия пришла к выводу, что код пишется последним.
Методология RDPI (Research → Design → Plan → Implement) — это практическое применение этих идей. Не теоретический фреймворк, а набор правил, выросших из реальной работы над проектами. Главное отличие от «просто планирования»: каждый этап порождает артефакт — документ, который сохраняется и используется дальше.
Зачем нужны артефакты? Две причины:
Контекст. Исследование, требования, дизайн, план — всё это документы, которые ИИ загружает на следующих этапах. Без них каждый новый запрос — это работа «с чистого листа», с потерей всего, что было наработано.
Возврат. Если через месяц нужно вернуться к задаче — артефакты позволяют восстановить контекст за минуты, а не за часы. И вам, и ИИ.
Это работает, потому что ИИ — мощный инструмент, но плохой руководитель проекта. Методика берёт на себя роль руководителя: ведёт ИИ по проверенным этапам, не позволяя пропускать шаги.
Это подтверждает DORA — ежегодный отчёт Google о состоянии DevOps-практик в индустрии, один из самых авторитетных источников в отрасли. DORA 2025 прямо говорит: ИИ — это усилитель существующих условий, а не волшебная палочка. Если у вас хороший процесс — ИИ сделает его быстрее. Если процесса нет — ИИ усилит хаос.
«ИИ не улучшает качество разработки автоматически — он усиливает существующие условия.»
DORA Report 2025
Исследование: фундамент контекста
Качество работы ИИ на всех последующих этапах напрямую зависит от того, что он знает о задаче. Фаза исследования — это момент, когда этот контекст создаётся. Чем он точнее и полнее — тем лучше результат.
В прямом подходе ИИ этот этап пропускает. Получает задачу — и сразу начинает генерировать код. Откуда он берёт информацию? Из обучающих данных. Которые могут быть устаревшими, неполными или просто неправильными для вашего проекта. Результат — код, построенный на предположениях, а не на фактах. Низкая корректность, низкая полнота — низкое качество.
Исследование решает эту проблему: ИИ изучает кодовую базу, находит похожие решения в проекте, определяет ограничения платформы и собирает факты в документ, который станет контекстом для всех последующих этапов.
Ключевое правило: сначала источник, потом утверждение. Не наоборот. Именно обратный порядок — «напишу, а потом подтвержу» — является главной причиной галлюцинаций ИИ. Когда модель сначала генерирует ответ, а потом ищет подтверждение — она находит его всегда, даже если ответ неверный.
Каждый факт получает уровень уверенности:
Уверенность
Код проекта + аналогичный кейс
Реализуем уверенно
Код проекта без кейса
Реализуем осторожно
Только документация
СТОП — нужна верификация
Нет источника / предположение
🔴 VERY LOW
СТОП — не включаем
Реализация при уверенности ниже MEDIUM (70%) — запрещена. Это правило, которое спасает от самых дорогих ошибок — тех, что построены на предположениях.
Интервью и требования: узнать, чего хочет пользователь
Требования — это не «сделай авторизацию». Требования — это:
- Какие способы авторизации нужны?
- Что происходит при неверном пароле? Блокировка? Задержка? Капча?
- Нужна ли двухфакторная аутентификация?
- Что видит пользователь без авторизации?
- Какие данные мы храним? GDPR применим?
При прямом подходе все эти вопросы остаются без ответа. ИИ берёт задачу «сделай авторизацию» и делает — самую простую версию. Без блокировки, без капчи, без 2FA, без GDPR. И формально задача выполнена.
Фаза требований заставляет задать эти вопросы до написания кода. Каждое требование получает:
- Идентификатор (F1, F2, NF1)
- Уровень уверенности (HIGH / MEDIUM / LOW)
- Критерии приемки
Требования — это контракт. Всё, что записано — будет реализовано. Всё, что не записано — за рамками задачи. Чёткие границы вместо «ну я думал, что это очевидно».
Design: архитектура — не роскошь
Многие путают дизайн с планированием. «Я же попросил ИИ составить план!» — говорят они. Да, но план — это что делать. Дизайн — это как делать правильно.
ПОЧЕМУ и КАК на уровне архитектуры
ЧТО и ГДЕ на уровне файлов
Какие компоненты? Как данные текут? Какие границы?
Какой файл? Какая функция? Какая команда для теста?
Цена ошибки
Дорого менять после утверждения
Дешево менять при реализации
Правило трёх вопросов. Каждое нетривиальное архитектурное решение отвечает на:
- Почему именно это? — Какую проблему решает?
- Что рассматривалось? — Какие были альтернативы?
- Что будет, если выбрать альтернативу? — Что потеряем?
Пример:
Решение: хранить тарифы в key-value store
Почему? Нужна гибкая схема без фиксированных колонок. Админка из коробки.
Альтернативы? Реляционная таблица, конфиг-файл.
Почему нет? Реляционная — жёсткая структура, сложно добавить варианты тарифов. Конфиг — нет UI, нужно писать с нуля.
Без этого анализа коллега (или вы через месяц) спросит «а почему не реляционная?» — и ответа не будет.
На этапе реализации ИИ пишет код строго по design.md и plan.md, фаза за фазой. Не импровизирует — следует плану.
Каждая фаза проходит самопроверку:
- Соответствует документам дизайна и плана
- Нет уязвимостей (XSS, SQL-инъекции)
- Нет отладочного кода (console.log, var_dump)
- Источники указаны в комментариях
Контроль контекста. Критически важный момент, о котором не говорят. У каждого ИИ есть окно контекста, и по мере его заполнения качество ответов деградирует незаметно:
- менее 60% — безопасная зона
- 60–80% — предупреждение
- более 80% — зона деградации (качество падает, ИИ начинает «забывать» ранние инструкции)
Если при прямом подходе вы переписываетесь с ИИ на протяжении 50 сообщений — вы почти наверняка в зоне деградации. И не знаете об этом.
Тестирование и верификация
Код написан — но задача не закрыта.
ИИ как помощник в тестировании. ИИ отлично справляется с написанием автотестов и тест-кейсов: он видит код, понимает граничные условия, может сгенерировать десятки сценариев за минуты. Это стоит использовать — пусть ИИ готовит тесты, прогоняет их, ловит очевидные баги.
Но ручное тестирование незаменимо. Автотесты проверяют то, что заложено в сценарий. Человек проверяет то, что в сценарий не попало: «а что, если нажать сюда дважды?», «а на мобильном это выглядит нормально?», «а если данных нет?». Пользователь лично тестирует реализацию и подтверждает, что результат соответствует ожиданиям.
Исправление ошибок — отдельный процесс. Если при тестировании найдены проблемы — они классифицируются:
- Локальный баг — исправить на месте
- Системная проблема — вернуться к дизайну
И здесь в методике заложена важная защита: предохранитель от зацикливания. Если после 3 попыток исправить проблему не получается — стоп. Не четвёртая попытка того же самого, а осознанная смена подхода. Методика помогает человеку в этот момент: записать логи неудачных попыток, проанализировать, почему не работает, вернуться к фазе исследования или провести новое, переосмыслить архитектуру. Без методики человек в этот момент теряется — «ну попробую ещё раз». С методикой — у него есть конкретный план выхода из тупика.
Кейс: сохранение знаний
После завершения задачи — документирование: что сделано, какие были отклонения от дизайна, какие паттерны пригодятся в будущем. Это инвестиция: следующая похожая задача будет решена быстрее, потому что ИИ найдёт готовый кейс при фазе исследования.
Контекст: ключевое правило
Вот главное, что я понял за время работы с ИИ:
Важен не промпт. Важен контекст.
В 2025 году CEO Shopify Тоби Лютке сформулировал это точнее всех: «Мне нравится термин "инженерия контекста" вместо "инженерия промптов". Он лучше описывает ключевой навык: искусство предоставить весь контекст, чтобы задача была решаемой для ИИ». Андрей Карпатый (бывший директор ИИ в Tesla, один из основателей OpenAI) поддержал — и это стало консенсусом: промпт — это малая часть контекста. Остальное — история диалога, документация, состояние проекта, результаты предыдущих этапов.
Проще говоря: вы можете написать идеальный запрос, но если ИИ не видит вашу кодовую базу, не знает ваших требований и не понимает архитектуру — результат будет посредственным. А если контекст полный и качественный — даже простой запрос даст хороший результат.
Формула качества контекста
В нашей методологии качество контекста определяется формулой:
К = (Корректность + Полнота) / (Объём + Шум)
Как улучшить
Корректность
Каждое утверждение подтверждено источником
Сначала источник — потом утверждение — потом ссылка
Все вопросы для следующей фазы отвечены
Проверка по требованиям задачи
Только то, что нужно для задачи
Не включать лишние детали
Мнения без источников, дубликаты, нерелевантное
Максимум 3 аналогичных примера
Высокое К — это когда каждый факт подтверждён, все пробелы закрыты, ничего лишнего и никакого шума. Это конкретный чек-лист, который ИИ проходит при каждом исследовании. И именно поэтому артефакты с предыдущих этапов так важны: они и есть тот качественный контекст, который делает следующие этапы успешными.
Проверка человеком: зачем нужны гейты
В нашей методологии ИИ останавливается и ждёт подтверждения от человека в четырёх точках:
После требований — ИИ собрал список того, что нужно реализовать, задал уточняющие вопросы, зафиксировал критерии приёмки. Теперь ждёт: «Всё верно? Ничего не упустил? Границы задачи такие?» Без этого ИИ может реализовать совсем не то, что вы имели в виду.
После дизайна — ИИ предложил архитектурное решение: какие компоненты, как данные текут, какие альтернативы рассмотрены. Ждёт: «Подход устраивает?» Это последний момент, когда изменить архитектуру дешево — пока это просто документ, а не код.
После плана — ИИ расписал пошаговый план реализации с конкретными файлами и проверками. Ждёт: «Начинаем писать код?» Это последняя контрольная точка перед тем, как появятся реальные изменения в проекте.
После реализации — код написан, ИИ прогнал тесты. Ждёт: «Проверьте, всё ли работает как ожидалось?» Только пользователь может подтвердить, что задача действительно решена.
Почему это критично? По данным Veracode (анализ 100+ моделей на 4 языках программирования), 45% ИИ-сгенерированного кода содержит уязвимости из списка OWASP Top 10. При этом ИИ-код выглядит профессионально и тщательно — чистые имена, аккуратная структура. Вы смотрите на него и доверяете. А внутри — SQL-инъекция или незащищённый эндпоинт.
Без гейтов ИИ может реализовать не те требования, принять архитектурное решение, которое невозможно масштабировать, написать код с уязвимостями — и пометить задачу как выполненную. Каждая ошибка на одном этапе умножается на следующих.
Именно поэтому ИИ-разработка требует инженерного подхода. И именно поэтому ИИ ещё долго не заменит разработчиков полностью: кто-то должен принимать решения на каждом гейте. Машина готовит, человек решает.
Но гейты нужны не только профессионалам. Если вы не разработчик и используете ИИ для создания приложений — контрольные точки нужны вам тем более. Они позволяют убедиться, что ИИ не ушёл в свои фантазии и делает то, что вы просили, а не то, что ему «показалось правильным».
Проверка ИИ: агенты-ревьюеры
Человеческая проверка важна, но человек не может (и не должен) проверять каждую строчку на уязвимости, производительность и соответствие стандартам. Для этого — агенты-ревьюеры.
В нашей методологии 15 независимых ревьюеров работают параллельно на каждом этапе:
На этапе исследования:
- Ревьюер полноты исследования (все ли источники проверены?)
- Ревьюер качества исследования (есть ли шум? Верные ли уровни уверенности?)
На этапе дизайна:
- Ревьюер архитектуры (SOLID, масштабируемость)
- Ревьюер безопасности (уязвимости на уровне архитектуры)
- «Адвокат дьявола» (оспаривает решения, ищет слепые зоны)
На этапе реализации:
- Ревьюер соответствия стандартам
- Ревьюер безопасности
- Ревьюер производительности
- Ревьюер обслуживаемости
- Ревьюер надёжности
Почему независимость критична
Ключевое: каждый ревьюер изолирован. Не видит результатов других. Проверяет один аспект.
Это не паранойя — это доказанный эффект. Исследования показывают, что языковые модели предпочитают собственные результаты и оценивают их выше, чем аналогичные по качеству результаты других моделей. Когда одна и та же модель и пишет код, и проверяет его — предвзятость накапливается. Это как если бы аудитор проверял свою же бухгалтерию: конфликт интересов встроен в систему.
Поэтому в нашей методологии:
- По возможности — разные модели для написания кода и ревью
- Полная изоляция ревьюеров друг от друга (ни один не видит выводов другого)
- Каждый пропуск должен быть подтверждён конкретным доказательством — «проверил, всё в порядке» не принимается
Обслуживаемость: код, который будет жить
Вот утверждение, к которому стоит привыкнуть:
Код, написанный ИИ, с большой вероятностью будет обслуживаться тоже ИИ.
И это создаёт новый класс требований. Код должен быть понятен не только человеку, но и следующему ИИ-агенту, который его прочитает.
Долг понимания: невидимая проблема
Addy Osmani (инженер Google Chrome) описал новый вид технического долга — «долг понимания»: растущий разрыв между объёмом кода в проекте и тем, сколько из него кто-либо реально понимает.
Исследование Anthropic (52 инженера) показало: ИИ-помощь не замедлила работу, но инженеры на 17% хуже понимали написанный код. Сильнее всего просело умение находить и исправлять ошибки — то есть именно то, что нужно при сопровождении.
Стандартные метрики — скорость, покрытие тестами, количество релизов — при этом выглядят отлично. Но никто не измеряет, понимает ли команда свой код. А если не понимает — следующее изменение сломает то, что работало.
Критерии обслуживаемости
В нашей методологии обслуживаемость — отдельная дисциплина с конкретными критериями. Вот ключевые из них:
Размер файла — не более 300 строк, одна ответственность. Почему это важно для ИИ: у языковых моделей ограниченное окно контекста. Файл на 1000 строк — это потеря точности, потому что модель «размазывает» внимание. Файл на 300 строк ИИ понимает целиком и работает с ним точно.
Понятные имена файлов — по функциональности, а не «общие». Файл utils.php или helpers.js — это мусорная корзина, куда складывают всё подряд. ИИ не может понять назначение такого файла по имени и не знает, когда его использовать, а когда нет. OrderCalculator.php — другое дело.
Когнитивная сложность — не более 15. Когнитивная сложность — это мера того, насколько трудно понять код. Каждое ветвление (if, switch), каждый вложенный цикл, каждое исключение увеличивает её. Код с вложенностью в 4–5 уровней (if внутри for внутри if внутри try) — сложен для человека и катастрофичен для ИИ: модель начинает терять логические связи и генерирует некорректные исправления.
Запрет глобального состояния в бизнес-логике. Глобальное состояние — это когда функция зависит не только от своих аргументов, а от какой-то переменной «снаружи», которую может изменить кто угодно и когда угодно. Для ИИ это ловушка: он не видит, кто и когда меняет эту переменную, и строит решения на ложных предположениях.
Запрет циклических зависимостей. Циклическая зависимость — это когда модуль А зависит от модуля Б, а модуль Б — от модуля А. Получается замкнутый круг: нельзя понять один без другого, нельзя изменить один без другого, нельзя тестировать по отдельности. ИИ в таких ситуациях теряет контекст и предлагает решения, которые ломают обе стороны.
Пустые блоки обработки ошибок — запрещены. Когда ИИ видит пустой catch {}, он не знает: ошибка сознательно проглочена или разработчик забыл дописать обработку? И начинает «помогать» — либо удаляет обработку, либо добавляет лишнюю, ломая логику.
Все эти правила работают в обе стороны: и для человека, и для ИИ. Код, написанный по этим критериям, одинаково хорошо читается и разработчиком, и агентом.
CodeRabbit точно подвёл итог: «2025 был годом скорости ИИ. 2026 будет годом качества ИИ».
ИИ снизил порог входа — и это прекрасно. Больше людей могут создавать программные продукты, чем когда-либо в истории.
Но снижение порога — не отмена правил. Прямой подход «задача → код → результат» работает на маленьких проектах. На реальных задачах — нет. Разработчики переоценивают пользу ИИ, а код деградирует незаметно.
Ошибка выжившего реальна. Вы видите свой работающий проект. Вы не видите тысячи проектов, которые сломались при первом изменении требований.
Методики существуют не зря. Исследование → Требования → Дизайн → План → Реализация → Проверка — каждый этап порождает артефакт, каждый артефакт становится контекстом для следующего. ИИ — усилитель: хороший процесс он ускоряет, отсутствие процесса — усугубляет.
Контекст важнее промптов. К = (Корректность + Полнота) / (Объём + Шум). Не тратьте время на идеальные формулировки — тратьте на качественный контекст.
Человек проверяет — потому что 45% ИИ-кода содержит уязвимости, а код при этом выглядит безупречно. Гейты — не бюрократия, а защита. И именно поэтому инженерный подход ещё долго будет нужен.
ИИ проверяет ИИ — но независимо. Модель предвзята к собственному коду. Изоляция ревьюеров и доказательства для каждого пропуска — не перестраховка, а необходимость.
Код будет жить. И его, скорее всего, будет обслуживать другой ИИ. Долг понимания — невидимая проблема, которую не ловят стандартные метрики. Пишите обслуживаемый код сегодня, чтобы не переписывать завтра.
Разрабатывайте с ИИ. Но разрабатывайте эффективно — с исследованием, требованиями, архитектурой и проверками. Не потому что так сложнее. А потому что так дешевле.