Вайб-кодеры, архитекторы и конец эпохи «ручного» программирования

Раньше мы писали код, чтобы объяснить компьютеру, что делать. Теперь мы пишем контракты, чтобы объяснить ИИ, что делать. А код пишет машина. Мы перестали быть программистами. Мы стали архитекторами решений.

Как я перестал писать код и начал проектировать системы, которые пишут код сами

---

Предисловие: я перестал быть программистом

2 года назад я был типичным full-stack разработчиком. React, Node.js, PostgreSQL. Открывал IDE, писал компоненты, настраивал маршруты, чинил баги. Как все.

Сегодня я не пишу код. Совсем.

Всё, что я делаю — я описываю системы. А код пишет Cursor.

И знаете что? Моя продуктивность выросла в 5 раз. Качество кода — выросло. Скорость доставки — выросла. А моя роль изменилась кардинально: я больше не разработчик. Я архитектор решений.

---

Часть 1. Кто такие вайб-кодеры и почему их стало так много

Что такое «вайб-кодинг»?

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

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

Они:

- Не знают, как работает useEffect - Не понимают, почему в одном месте N+1, а в другом — JOIN - Не отличают localStorage от sessionStorage - Не знают разницы между == и ===

Но они выдают готовый код за минуты.

И рынок это покупает. Потому что для 90% задач — это работает. E-commerce, лендинги, MVP, админки, простые API — ИИ справляется с ними лучше джуниора.

Почему вайб-кодеры — это не плохо

Я не хочу звучать снобистски. Вайб-кодинг — это эволюция, а не деградация. Это как переход от ассемблера к C, от C к Python, от Python к ИИ.

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

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

Но есть проблема

Вайб-кодеры не понимают архитектуру. Они не знают, как система работает «под капотом». Они не могут отличить хорошее решение от плохого, потому что они не видят последствий.

Их код:

- Работает на маленьких данных - Падает на больших - Имеет дыры в безопасности - Не масштабируется - Содержит технический долг, который аукнется через полгода

Они не знают, чего они не знают. А это опасно.

---

Часть 2. Как переквалифицироваться: от вайб-кодера к архитектору решений

Если ты вайб-кодер и хочешь оставаться востребованным в ближайшие 5 лет — тебе нужно перестать писать код и начать проектировать системы.

Звучит парадоксально, но это так.

Шаг 1. Перестань писать код руками

Да, ты не ослышался. Чем меньше кода ты пишешь руками — тем лучше.

Руками ты пишешь только:

- Критические участки (платежи, криптография, авторизация) - Тесты (чтобы проверить, что ИИ не накосячил) - Архитектурные каркасы (контракты, интерфейсы, схемы)

Всё остальное — делегируй ИИ. Твоя задача — не написать код, а описать, какой код должен быть.

Шаг 2. Научись проектировать контракты

Это самое важное. ИИ генерирует код по вашему запросу. Если запрос:

«Сделай мне форму логина»

— вы получите форму логина. Вероятно, с багами. Вероятно, без учёта edge-cases.

Если запрос:

«Сделай форму логина с валидацией email, блокировкой кнопки при сабмите, обработкой 429 ошибок с Retry-After, и с автоматическим редиректом на dashboard после успеха»

— вы получите работающий код.

ИИ — это отличный исполнитель, но плохой аналитик. Вы должны быть аналитиком. Вы должны описывать:

- Входные данные (Zod-схемы) - Выходные данные (типы ответов) - Ошибки (коды и сообщения) - Edge-cases (что при пустом поле, что при 500, что при 429) - Ограничения (TTL, лимиты, размеры)

Чем точнее контракт — тем лучше код.

Шаг 3. Создай свою библиотеку промптов

Ты пишешь один и тот же код 100 раз. Форму логина, JWT-авторизацию, CRUD-таблицу, админ-панель.

Сделай шаблоны промптов для этих задач. Я создал целую фабрику промптов — и это изменило всё.

Теперь я не пишу промпты для каждого нового проекта. Я просто подключаю фабрику, заполняю ТЗ, и она генерирует всю цепочку промптов для Cursor.

Моя документация на 80% состоит из таких шаблонов. И Cursor пишет код по ним без вопросов.

Шаг 4. Научись читать код (даже если не пишешь)

Ты не пишешь код руками — но ты обязан понимать, что написал ИИ.

Это как с такси: ты не водишь машину, но ты знаешь маршрут и понимаешь, когда водитель едет не туда.

Научись:

- Читать код на уровне архитектуры (не строки, а паттерны) - Понимать, что такое индексы, транзакции, join'ы, N+1 - Видеть дыры в безопасности (IDOR, XSS, SQL-инъекции) - Оценивать производительность по коду (а не по метрикам)

Шаг 5. Стань ответственным за архитектуру

Ты больше не «разработчик фичи». Ты — владелец системы.

Ты принимаешь решения:

- Монолит или микросервисы? - Какая БД? - Как кешировать? - Как масштабировать? - Как защищать?

Ты отвечаешь за:

- Безопасность (сначала) - Производительность (потом) - Масштабируемость (потом) - Поддерживаемость (всегда)

---

Часть 3. Куда движется профессия разработчика

Короткий ответ

Профессия «разработчик» не исчезнет. Она трансформируется.

Вместо «программист, который пишет код» — будет «инженер, который описывает системы и управляет ИИ».

Долгий ответ

Я вижу три слоя разработчиков в ближайшем будущем:

1. Операторы ИИ (вайб-кодеры)

- Пишут промпты, проверяют результат - Работают над простыми задачами (CRUD, формы, интеграции) - Зарабатывают немного, потому что конкуренция огромна

2. Архитекторы решений

- Проектируют системы на уровне контрактов и диаграмм - Создают библиотеки промптов и шаблонов - Отвечают за безопасность, производительность, масштабирование - Зарабатывают много, потому что таких мало

3. Инженеры доверия (Trust Engineers)

- Проверяют код, написанный ИИ - Находят уязвимости, неочевидные баги, технический долг - Строят системы автоматической проверки (CI, линтеры, автотесты) - Зарабатывают больше архитекторов, потому что их ещё меньше

Что будет через 5 лет

1. Код, написанный руками, станет исключением (только критические участки) 2. Архитекторы станут главными в командах (не тимлиды, а архитекторы) 3. Вайб-кодеры будут конкурировать с ИИ напрямую — и проигрывать 4. Тестирование станет главным навыком — умение написать тест, который поймает баг ИИ, станет дороже умения написать код 5. Появятся новые роли: «промпт-инженер», «контракт-дизайнер», «инженер качества ИИ-кода»

Что делать, чтобы не выпасть

1. Учись проектировать (не писать код) 2. Учись описывать (контракты, схемы, спецификации) 3. Учись проверять (код, безопасность, производительность) 4. Создавай шаблоны (для себя и для других) 5. Будь готовым к постоянному обучению — ИИ меняется быстрее, чем мы

---

Часть 4. Мой стек сегодня (и завтра)

Сегодня

Я описываю архитектуру в Markdown. Cursor пишет код. Я проверяю, тестирую, деплою.

Я не пишу:

- Компоненты React (их пишет Cursor по моим промптам) - API-роуты (их пишет Cursor) - Миграции БД (их пишет Cursor) - Тесты (их пишет Cursor)

Я пишу:

- ТЗ и контракты - Архитектурные решения (ADR) - Промпты для Cursor - Критические участки (безопасность, платежи)

Завтра

Я перестану писать даже контракты. Их будет генерировать Prompt Factory на основе ТЗ.

Я буду:

- Определять требования (что делаем, зачем, для кого) - Выбирать модули (какие компоненты использовать) - Утверждать архитектуру (проверять, что всё связано правильно) - Принимать релизные решения (готово к деплою или нет)

Моя роль — не писать, а принимать решения.

---

Часть 5. Конкретный пример: как я работаю сегодня

Вместо того чтобы писать код…

Раньше:

1. Открывал IDE 2. Создавал файл auth.routes.ts 3. Писал маршруты 4. Писал контроллеры 5. Писал валидацию 6. Писал тесты 7. Коммитил

Сегодня:

1. Открываю Cursor 2. Вставляю промпт:

markdown ТЕХНИЧЕСКОЕ ЗАДАНИЕ: JWT АВТОРИЗАЦИЯ

Модель User: id (UUID), email, passwordHash, role, isActive. RefreshToken: id, token, userId, expiresAt, revoked, userAgent, ipAddress.

Эндпоинты: POST /api/auth/register — регистрация POST /api/auth/login — вход, установка httpOnly cookies POST /api/auth/refresh — обновление токенов с ротацией POST /api/auth/logout — выход, отзыв токена GET /api/auth/me — получение текущего пользователя

Защита от кражи токенов: при повторном использовании отозванного refresh токена — отозвать все токены пользователя.

Я перестал быть программистом в тот день, когда понял: мой код больше не пишет человек. Его пишет машина. А я — тот, кто объясняет машине, что именно нужно построить. Я стал архитектором. И это — лучшее, что случилось с моей карьерой.