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

Я отвечаю людям с таким запросом, как мне кажется, наиболее здраво. Предлагаю вместо подбора магического стэка, секретных практик CLAUDE.md, каких-то нишевых расширений MCP серверов с SKILLS.md … просто задуматься чё вообще они делают и начать понимать то, что выплёвывает LLM. То есть, непосредственно, стать разработчиком! ШОК. Мы же пытаемся от них избавиться… но ведь… программисты… ВСЁ…

Знаете, как будто бизнес ждёт очередного чуда — вот-вот будет машина, которая полностью заменит всех разрабов)) Ну, смотрите, там уже компиляторы клод пишет! Нужно просто сделать более грамотный CLAUDE.md, надо просто скопипастить startup project вот смотрите умные люди с github приготовили как раз для небольших стартапов… Просто хочется чтобы за меня ВСЁ сделали! То есть хочется черную коробочку которая бы решала все мои проблемы!

У меня один вопрос: вам вообще комфортно с тем, что ваш продукт работает на чёрной коробке, о внутренностях которой вы ничего не знаете? Мне, честно, не очень…

Проблема 1: Выбор технического стэка

У меня выборка не большая но я вижу что ребята на вопросы о техническом стэке говорят ЛЛМкам “давай сделаем просто, потом допилим”. С одной стороны в чём они не правы. Реально же все хотят сделать “просто”! И спорить не с чем, я-то и сам, разраб, пытаюсь сделать как можно проще.

Но вот нюанс: а мы делаем проще для кого? Для ллки? Для себя? Для клиентов? А как мы можем выбрать простое решение если мы не сказали ЛЛМке что именно нам технически требуется? У меня нет четкой статистики но я ЧУВСТВУЮ паучьим чутьём что для ЛЛМки “просто” = react / python+jinja+vanilla js. Откуда она знает, у нас будет много интерактивности на стороне клиента или сервера? Нужно данные сохранять локально или иметь БД? Откуда ллмка знает, у нас будет мобильное приложение? Может у вас есть в голове идеи прикрутить реалтайм чат? Я честно хз в чём проблема потратить пару деньков посмотреть технических видосов со сравнением какой техстэк когда применять. Ну или самое простое - напрямую початиться об этом с LLM. Написать все планы на проект “мне нужен сайт похожий на профи ру где заказчик заполняет заявку Х и потом идёт проверка У …” - составить подробный диздок ПЕРЕД началом разработки. И дать ллмке время подумать как это РЕАЛЬНО ПРОСТО реализовать.

Мой совет архитектуры веба для начинающих вайбкодеров с целью экономить токены:

uv python fastapi(sync) jinja htmx alpine daisyui(cdn).

Использовать на свой страх и риск.

Проблема 2: Не следить за LOC

Я бы относился к коду как к стоимости которую мы платим за какую-то фичу. То есть любая доп строка — не важно это конфиг или бизнес-логика или SQL — стоит какое-то количество “валюты”. Это лишний контекст, лишние токены, лишняя сложность в конце концов. Самый ад начинается тогда, когда немало строк становятся “мёртвыми” — то есть строки кода никогда не исполняются! Они буквально не нужны… но они все равно тратят токены и усложняют код. Ллмка кушает их и может приходить к абсолютно неверным заключениям… отсюда и отвал уже рабочего функционала. Если вам впадлу прямо следить за каждым файликом то я советую хотя бы изредка запускать утилиту по подсчёту LOC проекта и сравнивать с какой-то предыдущей версией.

Относиться к этому так: мы добавили функционал фильтрации по частичному вводу идентификатора. Нам это стоило +440 строк и +2 файла. Можете даже у ЛЛМ спросить нормальная ли это “цена” за такую фичу или вас заскамили.

И ещё пара вещей пока не забыл:

  • Текущий клод ваншотит порядка 90% не сложных задач. Если вы не можете “подвинуть кнопочку” или “перекрасить сайдбар” или “пересчитать колонку” уже полчаса — в проекте ЯВНО чёто не так. Я бы рекомендовал общаться с LLM уже не “вот надо теперь прибавить тут 12.46” — я бы уже начинал спрашивать “а почему эта задача занимает столько времени?”. Я бы такие ситуации трактовал как сигналы о том, что настало время изменить инструментарий для выполнения вашей задачи.
  • Поток данных. Откуда у вас берутся данные? Сохраняются ли они вообще или используются один раз на каждый запрос? Какие API внешние используем? Что хранится на сервере или облаке? Что будет если не заплатим? Есть бекапы? А мб бэкапим данные которые в целом не особо то и важны?
  • Секреты. Ваша LLM без зазрения совести прочитает ваш .env, ребят)) Я, лично, шифрую ценные данные и даю возможность читать мой конфиг, там ничего полезного нет. Решение не идеальное тк ЛЛМ чисто технически может найти на компе ключ и расшифровать. Но у вас вообще хоть какое-то решение этой проблемы есть?

И, конечно, Git!

Git решает конкретные задачи: История изменений. Возможность откатиться. Посмотреть текущий diff (как раз тот самый промежуточный результат). Пуш, коммит, пулл, мердж реквест… Плюс рекомендую глянуть базу того, как именно гит связан с деплоем, узнать что такое ci/cd и подумать нужен ли он конкретно вам.

Я не то чтобы верю в идеальную чёрную коробку

LLM выдаёт человекочитаемые промежуточные результаты. Код — это текст. Объяснения — текст. Архитектурные решения — текст. Вы можете остановиться в любой момент, прочитать что происходит, и сказать “нет, не туда”.

Если бы LLM сразу писала бинарник — ей было бы мало смысла. Вы бы просто получали исполняемый файл и надеялись что он делает то что нужно. Никакого контроля. Но именно потому что результат читаемый — у вас есть точки входа для коррекции на каждом шаге. Это и есть основная фича которая делает инструмент полезным!

Уважаемые вайбкодеры, не бойтесь погрузиться поглубже в ваши инструменты. Это не рокет саенс и от вас никто никаких секретов не скрывает. Вся инфа о разработке ПО в ютюбе, в статьях на хабре, да много где.

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