1. Two coders - one LLM

"Вайбкодер рождается заново каждое утро. Метакодер растет и развивается с каждым днем."

Утренний Slack взорвался сообщением от PM: «Срочно нужна фильтрация в список пользователей». Виктор, глотнув кофе, тут же нырнул в код, активировав GitHub Copilot. Найдя похожий компонент в другом модуле, он скопировал его целиком и стал наблюдать, как Copilot предлагает варианты изменений. «Отлично, здесь нужно поменять эту переменную», — бормотал Виктор, принимая одну подсказку ИИ за другой, хотя смутно представлял принцип работы. Началась лихорадочная правка: замена, перезапуск, красные ошибки, вызов Copilot для исправления, снова правка. Час спустя — о чудо! — фильтрация заработала. Быстрый коммит с лаконичным «Add filtering», и задача закрыта.

К полудню прилетело сообщение о баге. Открыв файл, Виктор уставился на функцию, написанную им же с помощью Copilot три месяца назад, как на древние иероглифы. Кто и зачем написал этот странный код? Ах да, это же был он сам с тем же Copilot. «Хей, Copilot, что здесь происходит?» — спросил он, выделив непонятный фрагмент. Пятнадцать минут отчаянного вчитывания в объяснения ИИ, и вот решение — еще одно условие if, предложенное помощником и обрабатывающее конкретный случай. Сработает? Должно. Вроде бы.

После обеда новый вызов — оптимизация загрузки данных. Быстрый запрос Copilot: «Как ускорить загрузку в React?», копирование многообещающего решения, предложенного ИИ. Интеграция, запуск — и... ничего не работает. Ошибки посыпались как из рога изобилия. Виктор начал методично удалять строки сгенерированного кода, прося Copilot исправить то, что осталось, пока не нашел проблемный фрагмент. Заменил другим сниппетом, предложенным ИИ, скрестил пальцы — вроде работает. Вечер давно наступил, но регрессии, вызванные правками, требуют внимания. Домой Виктор уйдет выжатым как лимон, с тревожным предчувствием, что завтра что-то обязательно сломается.

В соседнем опенспейсе Мария, увидев то же сообщение в Slack, отложила кофе и открыла редактор диаграмм. Набросав архитектуру будущего решения, она запустила Continue и сформулировала задачу: «Нужно создать абстракцию для фильтрации данных. Вот моя диаграмма структуры». Через пятнадцать минут на экране появилась схема взаимодействия компонентов, доработанная с учетом подсказок ИИ-ассистента. Еще полчаса ушло на написание тестов, где Continue помог сгенерировать различные сценарии использования, определяющие ожидаемое поведение новой фильтрации. И только после этого она приступила к коду, создавая с помощью ИИ универсальную абстракцию, пригодную для использования по всему проекту: «Continue, реализуй этот интерфейс согласно нашей архитектуре».

Когда пришло сообщение о баге, Мария открыла указанный модуль и улыбнулась, увидев собственные комментарии. «Continue, помоги проанализировать этот баг», — попросила она, запустив отладчик. ИИ предложил несколько гипотез, и Мария быстро локализовала проблему, вместе с ассистентом исправив не только конкретный баг, но и целый класс подобных случаев. Затем наступила очередь оптимизации. «Continue, давай профилировать приложение и найти узкие места», — набрала она. Вместо слепого копирования решений, она методично анализировала предложения ИИ, обнаружив, что истинная проблема кроется в неэффективных API-запросах. Вместе с Continue она реализовала рефакторинг с добавлением кэширования и ленивой загрузки. Запуск тестов подтвердил, что все работает корректно. Вечером, уходя домой вовремя, она поручила ассистенту помочь с подробной документацией о внесенных изменениях.

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

"Дайте вайбкодеру задачу на день — он справится за час; дайте ему задачу на месяц — он никогда не закончит."

2. вайб-вайб, мета-мета

Темный монитор отражает усталое лицо разработчика. «Почему это работает?» — шепчет он, глядя на фрагмент кода, который только что получил от ChatGPT. Код прекрасно решает задачу, тесты проходят, но суть алгоритма ускользает, как сон после пробуждения. Это и есть квинтэссенция вайбкодинга с LLM — программирования на ощущениях, когда разработчик превращается в жреца искусственного интеллекта: приносит жертву в виде промптов, получает магические заклинания в ответ, но внутренний механизм остается сакральной тайной вероятностного голема.

Вайбкодинг с использованием LLM — это цифровая алхимия наших дней. Разработчик смешивает ингредиенты промптов, добавляет щепотку контекста, жонглирует примерами, и если результат работает — празднует успех, не останавливаясь, чтобы по-настоящему понять созданное.

Работает? Не трогай. Не работает? Спроси у шамана.

Я помню, как с восторгом рассказывал в профессиональном чате: «Наконец-то попробовал хвалёный вайб-кодинг! Использую GPT-4o для генерации кода нашей новой фичи в рабочем проекте — просто описываю, что нужно, и получаю готовые решения». Реакция коллег меня удивила. «Это не вайб-кодинг», — ответили мне. «Вайб-кодинг — это когда ты не понимаешь, что модель делает, и просто наслаждаешься результатом. А ты, судя по всему, анализируешь ответы и контролируешь процесс».

Это заставило меня задуматься. А что же тогда я делаю? Если вайб-кодинг — это мистическое отношение к коду: «Оно работает, и не трогай», то как назвать мой подход, где я уже не пишу код напрямую, а 95% времени формулирую промпты — по сути, метаинструкции для его создания, но, тем не менее, знаю о коде всё? Так родилось мое понимание метакодинга в контексте LLM.

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

Звучит скучно? А вот и нет. Именно здесь начинается настоящий хардкор.

Метакодер не просто дирижёр. Он знает, когда оркестр фальшивит — и как это предотвратить.

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

Вы спросите: а что, собственно, изменилось с приходом LLM? Разве раньше не было плохих и хороших программистов? Безусловно, были. Но теперь граница между ними стала иной. Раньше вайбкодер отличался от метакодера качеством кода, сегодня — качеством промптов. И вот тут-то вся соль: LLM усиливает естественные склонности разработчика. Вайбкодер получает мощный инструмент для производства говнокода в промышленных масштабах, метакодер — помощника в реализации всех известных ему и релевантных для проекта best practices, на которые раньше просто не хватало времени.

"Вайбкодинг — это джаз-импровизация, метакодинг — симфония с партитурой."

3. Метакодинг: инструкция по сборке

Давайте честно: большинство разработчиков, столкнувшись с LLM, ведут себя как туристы без карты. Сначала восторг, потом растерянность, а дальше — кто во что горазд. Кто-то строит хижину из подручных веток, кто-то пытается возвести небоскрёб на песке. Но если вы хотите, чтобы ваш код не сдуло первым же ветром, придётся стать архитектором. Не только для себя — для всей команды. И, что особенно важно, для железяки, которая теперь ваш лучший друг.

3.1. Промежуточные артефакты: инструкции для людей и машин

Вот в чём фокус: метакодинг начинается не с кода. И даже не с обсуждения в чате. Всё начинается с артефактов — документов, которые становятся не просто памяткой для забывчивого коллеги, а настоящей инструкцией для LLM. Это не бюрократия ради галочки. Это — фундамент, на котором строится всё остальное.

Solution Design — это не просто «что делаем». Это карта, по которой будет двигаться и человек, и машина. Здесь фиксируются цели, ограничения, критерии успеха. Не хотите, чтобы LLM блуждал в потёмках? Дайте ему карту.

# Solution Design: Система нотификаций

## Цель
Пользователи должны получать уведомления о важных событиях в системе через email, push и в интерфейсе.

## Ограничения
- Максимальная задержка доставки — 1 минута
- Отказоустойчивость: уведомления не должны теряться при сбоях
- Масштабируемость: до 100,000 уведомлений в час

## Ожидаемый результат
- Единый API для отправки уведомлений
- Гарантированная доставка через очередь сообщений
- Возможность легко добавлять новые каналы доставки

## Флоу
...

В чём магия? LLM, получив такой документ, перестаёт быть шаманом, вызывающим дождь, и становится инженером, строящим мост. Чёткие рамки, понятные критерии — и вот уже результат не случаен, а предсказуем.

Dependencies Map — это не просто список зависимостей. Это — схема коммуникаций, карта дорог, по которым будет двигаться ваш проект. Для человека — способ не забыть про важные интеграции. Для LLM — способ не изобрести велосипед там, где уже есть шоссе.

# Dependencies: Система нотификаций

## Внутренние зависимости
- UserService — получение контактов пользователей
- EventSystem — источник событий для уведомлений
- Frontend notification component — отображение в интерфейсе

## Внешние API
- SendGrid — отправка email
- Firebase Cloud Messaging — отправка push-уведомлений

## Существующие модели
- User (имеет поля email, device_token)
- Event (генерирует события в системе)

## Новые компоненты
- NotificationService (создать)
- NotificationQueue (создать)
- NotificationWorker (создать)
...

Implementation Plan — это уже не просто карта, а пошаговая инструкция. Здесь нет места импровизации. Каждый шаг — как нота в партитуре. И если вы хотите, чтобы LLM играл симфонию, а не джаз на слух, дайте ему эту партитуру.

# Implementation Plan: Система нотификаций

## Фаза 1: Фундамент
1. Создать модель Notification с полями:
   - id, type (email, push, ui), user_id, content, status, created_at
   - Интегрировать с существующей моделью User для получения контактных данных
   - Взаимодействие с EventSystem как источником событий

2. Разработать NotificationService с интерфейсом:
   ```typescript
   interface INotificationService {
     send(userId: string, type: NotificationType, content: NotificationContent): Promise<void>;
     getStatus(notificationId: string): Promise<NotificationStatus>;
   }

...

## Фаза 2: Каналы доставки
...

...

## Ограничения и контрольные точки
- ✓ Максимальная задержка доставки < 1 минута (проверка на этапе 8)
- ✓ Отказоустойчивость через RabbitMQ + retry-механизм (проверка на этапе 8)
- ✓ Масштабируемость до 100,000 уведомлений/час (проверка на этапе 9)
- ✓ Единый API для всех каналов (проверка на этапе 2)
- ✓ Легкое добавление новых каналов через INotificationChannel (проверка на этапе 4)

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

3.2. Живая документация: контекст, который работает

Вот здесь стоит сделать важное уточнение. Все эти промежуточные артефакты — Solution Design, Implementation Plan, карты зависимостей — прекрасны на этапе проектирования и генерации бизнес-логики. Но не обманывайтесь: они редко становятся полноценной документацией проекта. Их задача — провести команду (и LLM) через этап рождения архитектуры, но для поддержки и развития системы нужен цельный, связный README, который будет ориентирован не на процесс разработки, а на долгую жизнь проекта. Именно такой README становится точкой входа для новых участников, основой для поддержки и эволюции кода. Всё остальное — рабочие черновики, которые хороши в моменте, но быстро теряют актуальность.

README.md — это не формальность. Это — инструкция для всех: от новичка до искусственного интеллекта. Чем подробнее и структурированнее README, тем меньше шансов, что LLM сгенерирует что-то не то.

# Payment Processing Module

## Назначение
Обработка платежей через различные платежные шлюзы.

## Архитектура
- Controllers: src/controllers/payment/*
- Models: src/models/payment.ts, src/models/transaction.ts
- Services: src/services/payment-service.ts
- DTO: src/dto/payment-requests.ts, src/dto/payment-responses.ts

## Поддерживаемые платежные шлюзы
- Stripe (основной)
- PayPal (альтернативный)
- Yookassa (для России)

## Как добавить новый платежный шлюз
1. Создать имплементацию PaymentGatewayInterface
2. Зарегистрировать в PaymentGatewayFactory
3. Добавить тесты в tests/payment/gateways/

## Примеры использования
См. examples/process-payment.ts

3.3. Layer guides

Layer Guides — это уже не просто документация, а свод законов для каждого слоя архитектуры. Для LLM — это Конституция. Для команды — гарантия, что никто не навайбкодит SQL-запросы в контроллере.

Пример Layer Guide для слоя сервисов:

# Service Layer Guide

## Назначение
- Инкапсулирует бизнес-логику
- Не содержит SQL-запросов и прямого доступа к базе
- Использует только репозитории и DTO

## Принципы
- Каждый сервис отвечает за одну бизнес-операцию
- Валидация данных — до входа в сервис
- Исключения — только бизнес-ошибки, технические ловятся на уровне выше

## Пример структуры
- services/
  - user-service.ts
  - payment-service.ts
- Все сервисы реализуют интерфейсы из contracts/

3.4. Контракты для агентов

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

Контракт — это слово, превращённое в действие. Это обещание, ставшее кодом. Это страх ошибки, обернувшийся гарантией.

// user-service.interface.ts
export interface IUserService {
  getUserById(id: string): Promise<UserDTO | null>;
  updateUserProfile(id: string, data: UpdateProfileDTO): Promise<UserDTO>;
  deactivateUser(id: string): Promise<void>;
  listUsersWithFilters(filters: UserFiltersDTO): Promise<PaginatedResponse<UserDTO>>;
}

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

API Contracts через OpenAPI — это не просто документация, а договор между всеми участниками процесса: фронтендом, бэкендом, LLM и бизнесом.

3.5. Что даёт такой подход?

Всё просто. Чем больше структуры — тем меньше хаоса. Чем больше правил — тем меньше сюрпризов. LLM, получая чёткие инструкции, начинает работать не как гадалка, а как инженер. Команда перестаёт тратить время на разбор полётов и начинает строить.

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

• Меньше итераций — больше результата.
• Меньше багов — больше предсказуемости.
• Меньше «а почему оно так?» — больше «вот почему оно так».

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

Создавать такие промежуточные артефакты можно не только вручную. LLM отлично справляется с генерацией Solution Design, Dependencies Map или Implementation Plan — если дать ей хороший шаблон, пример или даже просто поток мыслей в виде неструктурированного промпта. Иногда достаточно набросать мысли в свободной форме, а дальше — попросить LLM структурировать их по нужному формату. Главное — не бояться использовать ИИ не только для кода, но и для создания самих правил игры.

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

4. Пределы вайбкодинга

Утро. Команда в панике: баг в проде, дедлайн вчера, LLM-ассистент уже третий раз генерирует патч — и каждый раз баг только меняет форму. Кто-то шутит: «Может, просто попросим Copilot объяснить, что он сам тут наваял?» Смех нервный. Вайбкодинг в чистом виде: быстро, на ощупь, с надеждой на чудо. Код работает — пока не перестаёт. И вот уже каждый новый prompt — как попытка обезвредить мину, заложенную вчерашним собой.

Вайбкодинг — это искусство выживания. Он нужен, когда надо быстро: MVP, хакатон, прототип, proof-of-concept. LLM здесь — ускоритель, генератор идей, иногда даже спасатель. Но стоит проекту вырасти, команде — увеличиться, а требованиям — измениться, и минус вайб. Кодогенерация становится игрой в «угадай, что хотел сказать предыдущий вайбкодер».

Метакодинг — не про медленную бюрократию. Это про умение строить такие правила, при которых и человек, и машина понимают, что происходит. Контракты, документация, тесты — не для галочки, но чтобы LLM не гадал, а проектировал. Чтобы кодогенерация была не лотереей, а инженерией. Здесь LLM — не шаман, а надёжный исполнитель, который строит по чертежу, а не по наитию.

Организации, сами того не замечая, часто подталкивают к вайбкодингу: KPI на скорость, оплата за фичи, культ «быстрее, выше, сильнее». Но потом удивляются, почему кодовая база напоминает руины древней цивилизации, где каждый новый разработчик — археолог. Системные стимулы, которые раньше формировали просто smelling repos, теперь формируют целые культуры кодогенерации, где LLM становится акселератором хаоса.

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

Чем опытнее разработчик, тем изощрённее его вайбкодинг. Старые привычки — как тёмные воды, в которые легко нырнуть, если не держать в голове одну простую истину: главное ограничение в системе «человек-компьютер» — это не компьютер. Это человек. LLM не устает, не забывает, не теряет контекст. А вот мы — да. И скорость кодинга теперь ограничена не тем, сколько строк кода мы можем написать, а тем, сколько изменений в час мы способны придумать, осмыслить и описать.

Раньше реализация занимала дни и недели. Теперь — если ты умеешь строить качественные промпты и создавать промежуточные артефакты, можно за двухнедельный спринт выдавать мердж-реквесты на десятки тысяч строк кода. Не просто кода — а кода, покрытого тестами, снабжённого документацией, вылизанного по всем best practices, согласованным в команде. Кода, который не стыдно показать ни человеку, ни машине. Кода, который закрывает бизнес-задачу не на 80%, а на 120%.

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

Рефакторинг? Теперь это не подвиг, а рутинная операция. Если правильно построить промпты и промежуточные артефакты, можно мигрировать фичу за фичей с одной архитектуры на другую, как поезд по рельсам. Переезд с clean architecture на hexagonal — задача не на месяцы, а на неделю. Даже если у вас сотни тысяч строк кода. А если останется время — можно мигрировать обратно, просто по фану.

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

В конце концов, метакодинг — это не про скорость или размер коммитов. Это про то, чтобы человек оставался главным ограничением — но не главным источником хаоса.

Подумайте: а ваш код — это фундамент для будущего или очередная археологическая загадка, оставленная в спешке?

5. Мосты и развилки: ваш путь только начинается

Важно помнить: вайбкодинг хорош там, где требуется скорость и гибкость — при создании MVP, прототипов, proof-of-concept, на хакатонах, в индихакинге и в ситуациях, когда результат нужен «ещё вчера».

Здесь интуиция и импровизация позволяют быстро проверить гипотезу или найти нестандартное решение.

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

Для долгосрочных, масштабируемых и критичных проектов необходим переход к метакодингу — структурированному подходу с документацией, тестами и архитектурными артефактами.

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

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

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

Метакодер строит мосты. Но тот, кто знает, когда какой подход применить, — меняет русла рек. Вот где настоящая сила.

Не существует единственно верного пути. Завтра появится новый инструмент — и все наши best practices станут вчерашним днём. Привыкайте. Мир меняется быстрее, чем вы думаете.

Важно не бояться меняться. И не забывать, ради чего мы вообще пишем код.

Что делать уже сегодня?

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

Данный пост навайбкоден наметакоден в рамках проекта Daniyar and his machines, преимущественно с помощью gpt-4.1. Количество вручную модифицированного текста не превышает 5%