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

Будем откровенны: с каждым из нас такое случалось. Открываешь новый ИИ-инструмент для написания кода, и вдруг кажется — теперь ты можешь создать что угодно. Все эти годы мечтал реализовать идею, но не хватало времени? Теперь время пришло. Описываешь желаемое, итеративно общаешься с ИИ — и готово.

Ощущение опьяняет. И пугает.

Соблазн «достаточно хорошего» кода

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

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

Код родился быстро. Очень быстро. Агент выдал демон на Rust, систему классификации, четыре стратегии поиска с переранжированием через локальные модели. Со стороны выглядело впечатляюще. Тесты проходили. Компилятор не ругался.

А потом я попытался это использовать.

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

Проблема противоречий, о которой все молчат

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

Что может быть проще? Сравни два факта, отметь конфликт.

Кроме.

Что вообще является противоречием в такой системе? Если агент в понедельник узнал, что «Проект X использует PostgreSQL», а во вторник — что «Проект X использует MySQL», это противоречие? Может, стек технологий изменился. Может, один источник ошибался. Может, «Проект X» — это разные проекты. Может, слово «использует» означает разные вещи в разных контекстах.

Люди разбираются с этим через годы накопленного здравого смысла, контекста и способности сказать «здесь что-то не так», не умея точно объяснить почему. ИИ-системы могут уверенно генерировать текст про любую из этих интерпретаций, но эта уверенность часто оказывается просто паттерн-матчингом без настоящего понимания.

Где вибекодинг ломается

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

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

Когда я попросил ассистента «реализовать обнаружение противоречий», я по сути просил его решить задачу, которую не мог точно определить. Результаты были... творческими. Мы исследовали решётки Белнапа, четырёхзначную логику, формальную верификацию с доказательствами в Agda, сети Петри. Ассистент был готов к любому предложению, и честно — некоторые идеи были действительно интересными.

Но «интересно» не значит «работает».

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

Неудобная правда

Вот что вибекодинг-гуру вам не расскажут: сложная часть разработки ПО никогда не была в наборе кода. Она в том, чтобы понять, что именно строить.

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

Но это также означает, что ты можешь проваливаться быстрее и дороже, чем раньше. Генерировать горы уверенного кода, решающего не ту проблему, и осознать это только когда уже построил целую систему на кривом фундаменте.

Что реально помогает

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

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

Прототипы нужно безжалостно тестировать на реальных сценариях. Строишь систему памяти? Проводи столько же времени, пытаясь её сломать, сколько потратил на создание. Особенно старайся сломать базовые допущения, о которых ты даже не подозревал.

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

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

Итог

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

Но также научился уважать разрыв между «код работает» и «система корректна». Этот разрыв существовал всегда. ИИ-инструменты его не закрыли — они просто упростили его игнорирование.

Лучшие вибекодеры — это не те, кто лучше всех пишет промпты. Это те, кто чувствует, когда что-то идёт не так.