Кто сегодня разрабатывает с ИИ?

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

ИИ радикально снизил порог входа в разработку. Это не гипотеза – это статистика:

• 63% пользователей, практикующих вайбкодинг, идентифицируют себя как не-разработчики (Second Talent, 2026)

• Gartner прогнозирует, что к 2026 году «citizen developers» превысят число профессиональных разработчиков 4:1 (VentureBeat/Gartner)

• 51% всего кода, закоммиченного на GitHub в начале 2026 года, был сгенерирован или существенно написан с помощью AI (BetaNews)

• 70% новых корпоративных приложений создаются «citizen developers», а не IT-командами (Gartner via Kissflow)

Маркетологи строят лэндинги. Аналитики пишут дашборды. Владельцы бизнеса собирают CRM-интеграции. Энтузиасты создают полноценные приложения. Все это – без единой строчки кода, написанной вручную.

Звучит как революция. И она уже произошла.

Но у революции есть обратная сторона.

---

Как разрабатывают с ИИ?

Типичный подход к ИИ-разработке выглядит так:

1. Человек описывает задачу

2. ИИ пишет код

3. Человек смотрит – работает ли

4. Если нет – кидает ошибку обратно в чат

5. Повторять до результата

В лучшем случае добавляется этап планирования: человек просит ИИ составить план, а потом реализовать его. Выглядит разумно. Работает – тоже, в каком-то проценте случаев.

Этот подход я называю «прямой разработкой». Задача – код – результат. Минимум промежуточных шагов. Максимум скорости. Ощущение продуктивности зашкаливает.

И это проблема.

---

«Но я разрабатывал с таким подходом, и меня устраивает результат. Что не так?»

Если вы прямо сейчас подумали эту фразу – я вас понимаю. Я и сам так думал. Делаешь задачу, ИИ выдает код, код работает. В чем проблема?

Проблема называется «ошибка выжившего».

Что видите вы

Ваш проект. Он работает. ИИ помог написать его быстро. Вы довольны.

Что вы не видите

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

Код, который сломался при первом изменении требований. ИИ пишет код под задачу «как она звучит сейчас». Заказчик говорит «добавь фильтр по дате» – ИИ добавляет. Потом заказчик говорит «а теперь по диапазону дат» – и выясняется, что вся логика фильтрации захардкожена, селект зашит в 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 (~560M) и AT&T (~110M), Change Healthcare (~100M человек). По данным IBM Cost of a Data Breach Report 2024, средняя стоимость утечки – $4,88M, а если утечка связана с AI-системами – $5,17M. Среднее время обнаружения утечки через украденные учетные данные – 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

---

Исследование: фундамент контекста

Качество работы ИИ на всех последующих этапах напрямую зависит от того, что он знает о задаче. Фаза исследования – это и есть тот момент, когда этот контекст создается. Чем он точнее и полнее – тем лучше результат.

В прямом подходе ИИ этот этап пропускает. Получает задачу – и сразу начинает генерировать код. Откуда он берет информацию? Из обучающих данных. Которые могут быть устаревшими, неполными или просто неправильными для вашего конкретного проекта. Результат – код, построенный на предположениях, а не на фактах. Низкая корректность, низкая полнота – низкое качество.

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

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

Каждый факт получает уровень уверенности:

Реализация при уверенности ниже MEDIUM (70%) – запрещена. Это правило, которое спасает от самых дорогих ошибок – тех, что построены на предположениях.

---

Интервью и требования: узнать, чего хочет пользователь

Требования – это не «сделай авторизацию». Требования – это:

• Какие способы авторизации нужны?

• Что происходит при неверном пароле? Блокировка? Задержка? Капча?

• Нужна ли двухфакторная аутентификация?

• Что видит пользователь без авторизации?

• Какие данные мы храним? GDPR применим?

При прямом подходе все эти вопросы остаются без ответа. ИИ берет задачу «сделай авторизацию» и делает – самую простую версию. Без блокировки, без капчи, без 2FA, без GDPR. И формально задача выполнена.

Фаза требований заставляет задать эти вопросы до написания кода. Каждое требование получает:

• Идентификатор (F1, F2, NF1)

• Уровень уверенности (HIGH / MEDIUM / LOW)

• Критерии приемки

Требования – это контракт. Все, что записано – будет реализовано. Все, что не записано – за рамками задачи. Четкие границы вместо «ну я думал, что это очевидно».

---

Design: архитектура – не роскошь

Многие путают дизайн с планированием. «Я же попросил ИИ составить план!» – говорят они. Да, но план – это что делать. Дизайн – это как делать правильно.

Правило трех вопросов. Каждое нетривиальное архитектурное решение отвечает на:

1. Почему именно это? – Какую проблему решает?

2. Что рассматривалось? – Какие были альтернативы?

3. Что будет, если выбрать альтернативу? – Что потеряем?

Пример:

Решение: хранить тарифы в 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) поддержал – и это стало консенсусом: промпт – это малая часть контекста. Остальное – история диалога, документация, состояние проекта, результаты предыдущих этапов.

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

Формула качества контекста

В нашей методологии качество контекста определяется формулой:

К = (Корректность + Полнота) / (Объем + Шум)

Высокое К – это когда каждый факт подтвержден, все пробелы закрыты, ничего лишнего и никакого шума. Это конкретный чеклист, который ИИ проходит при каждом исследовании. И именно поэтому артефакты с предыдущих этапов так важны: они и есть тот качественный контекст, который делает следующие этапы успешными.

---

Проверка человеком: зачем нужны гейты

В нашей методологии ИИ останавливается и ждет подтверждения от человека в четырех точках:

После требований – ИИ собрал список того, что нужно реализовать, задал уточняющие вопросы, зафиксировал критерии приемки. Теперь ждет: «Все верно? Ничего не упустил? Границы задачи такие?» Без этого ИИ может реализовать совсем не то, что вы имели в виду.

После дизайна – ИИ предложил архитектурное решение: какие компоненты, как данные текут, какие альтернативы рассмотрены. Ждет: «Подход устраивает?» Это последний момент, когда изменить архитектуру дешево – пока это просто документ, а не код.

После плана – ИИ расписал пошаговый план реализации с конкретными файлами и проверками. Ждет: «Начинаем писать код?» Это последняя контрольная точка перед тем, как появятся реальные изменения в проекте.

После реализации – код написан, ИИ прогнал тесты. Ждет: «Проверьте, все ли работает как ожидалось?» Только пользователь может подтвердить, что задача действительно решена.

Почему это критично? По данным 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% ИИ-кода содержит уязвимости, а код при этом выглядит безупречно. Гейты – не бюрократия, а защита. И именно поэтому инженерный подход еще долго будет нужен.

ИИ проверяет ИИ – но независимо. Модель предвзята к собственному коду. Изоляция ревьюеров и доказательства для каждого пропуска – не перестраховка, а необходимость.

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

---

Разрабатывайте с ИИ. Но разрабатывайте эффективно – с исследованием, требованиями, архитектурой и проверками. Не потому что так сложнее. А потому что так дешевле.