Мне почти всё равно, какая там модель

Есть забавная штука с автопилотом.

Самолёт не становится безопасным только потому, что внутри очень хороший компьютер.

Вокруг него ещё есть датчики. Ограничения. Чек-листы. Контрольные точки. Дублирование систем.

И главное — никто не говорит: «Ну он вроде умный. Давайте взлетит в Москве, а проверим уже в Стамбуле».

Почему-то с AI-разработкой мы иногда делаем именно так. Берём модель посильнее. Даём ей большую задачу. А потом через полчаса смотрим на 47 изменённых файлов и пытаемся понять: А что именно сейчас произошло?

Недавно я делал MVP Payment Hub.

У нас есть трансграничные переводы, внешние провайдеры и около 20 Telegram-чатов с партнёрами. Когда у провайдера что-то ломается, поддержка начинает бегать между чатами и отвечать на одни и те же вопросы.

Payment Hub — это попытка убрать этот хаос.

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

В «Розетке левее» проблема была в том, что мы сами меняем требования быстрее, чем AI пишет код.

Но здесь я наступил на следующий уровень.

Требования уже были. Архитектуру я продумал. Правила описал. Разложил всё по текстовым файлам и отдал Cursor.

И довольно быстро получил новую проблему.

Файлы есть. Контекста много. А жизненного цикла у этого контекста нет.

Что уже принято? Что просто обсуждали? Что заменили вчера? Какое решение актуальное? Что уже реализовано? И где проверить, что реализация соответствует решению?

Складывать .md рядом с кодом оказалось примерно как хранить все документы дома в одном ящике.

Формально всё есть. Но попробуй быстро найти нужное.

Тогда начал собирать вокруг модели harness.

Не ещё один промпт. А среду, которая управляет её работой. OpenSpec дал жизненный цикл изменений. Context7 — актуальную документацию библиотек.

Но самое важное оказалось вообще не в инструментах.

Я сильно уменьшил размер шага. Не «реализуй модуль инцидентов». А: • Сделай модель → проверь. • Сделай миграцию → проверь. • Сделай repository → проверь. • Сделай service → проверь. • Добавь API → проверь.

Каждый маленький шаг заканчивается тестом.

Закончили логический блок — прогоняем блок целиком. Собрали несколько блоков — интеграционные тесты. Подняли приложение в контейнере — тестируем уже собранное окружение. А в конце — полный E2E-прогон.

То есть модель почти никогда не получает возможность полчаса бодро ехать в неправильную сторону.

Она делает маленький шаг. Получает обратную связь. Исправляется. И только потом получает следующий.

И вот здесь у меня немного поменялось отношение ко всей гонке AI-моделей.

Мне теперь не так важно, знает ли модель наизусть весь Spring. Для этого есть Context7.

Мне не нужно, чтобы она сама придумала архитектуру.

Архитектуру и ограничения задаю я.

Мне не нужно, чтобы она сама решила, из каких двадцати шагов состоит задача. Декомпозицию контролирую я.

От модели мне в значительной степени нужно другое: уметь хорошо писать код внутри маленькой, понятной задачи.

И если весь контур вокруг неё построен нормально, модель становится довольно заменяемой частью системы.

Сегодня одна. Завтра другая. Ведь хороший engineering process тоже строится не вокруг надежды: «У нас очень умные разработчики, они точно не ошибутся».

Он строится вокруг другого: Ошибка должна быть маленькой, быстро обнаруживаться и не ехать дальше по системе.

Payment Hub в итоге получил рабочий MVP за два дня.

Но эти два дня для меня не главное.

Главное — я впервые действительно почувствовал разницу между AI, который пишет код, и системой разработки, внутри которой AI пишет код.

И, кажется, вот тут для меня и закончился вайбкодинг.

Не потому что AI стал хуже или скучнее.

Просто в какой-то момент вокруг очень быстрого разработчика всё равно приходится строить нормальную инженерную систему.

И чем лучше эта система, тем меньше в итоге важно, как называется модель внутри.