Бытовая грамотность вайбкодера

Что стоит понимать, когда код за тебя пишет нейронка.

Вот ссылка на статью: https://niar42.com/articles/vibecoder-literacy/
Расскажи, что в ней говорит автор и чем это может быть полезно? И как мне применить это у себя?

Порог входа в разработку сейчас смешной. Открыл Codex или Claude Code, написал «сделай сервис» — через пару минут что-то работает. Я так живу каждый день: написал больше 300 тысяч строк рабочего кода и при этом не умею писать его руками.

Но в какой-то момент из-под капота начинают вылезать слова: package.json, .env, docker-compose.yml, git push, DNS, VPS, nginx, логи. И вот тут вайбкодинг для многих превращается в шаманство — агент что-то делает, что-то ломается, а человек не понимает, на каком этаже пожар.

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

Программировать для этого учиться не обязательно. Достаточно на бытовом уровне понимать среду, в которой живёт код — примерно как понимать розетку и пробки без диплома электрика. Ниже — карта этой среды.

Наш подопытный — «Обнимикапи». Чтобы не объяснять на воздухе, протащим через весь текст один сервис. «Обнимикапи» — это очередь желающих обнять капибару: человек оставляет имя и телефон, заявка падает в базу, и капибара (точнее, администратор капибары) перезванивает и зовёт на сеанс обнимашек. Сервис абсурдный, а устроен ровно так же, как любой серьёзный.

1. Из чего состоит приложение

Почти любая аппка, от лендинга до игры, собирается из четырёх частей:

1. Интерфейс — то, что видит пользователь. В «Обнимикапи» это форма с двумя полями: имя и телефон.
2. Роуты / API — адреса, куда уходят запросы. Здесь это /submit, куда улетает заявка на обнимашки.
3. База данных — где всё хранится. Здесь это таблица «очередь к капибаре».
4. Логика — правила, по которым всё работает. Здесь это проверка, что телефон не пустой, и сохранение после неё.

человек жмёт «Записаться на обнимашки» → форма отправляет запрос в роут /submit → роут проверяет телефон, кладёт заявку в базу, возвращает ответ «вы 47-й в очереди к капибаре».

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

2. Текстовые файлы и Markdown

ТЗ, README, документация, конфиги — это обычные текстовые файлы: .md, .json, .yaml, .env. Бояться нечего, это просто текст по понятным правилам.

Markdown стоит освоить первым. На нём удобно писать задачи агенту, и он лучше их понимает. Хватает минимума:

• заголовки;
• списки;
• ссылки;
• кодовые блоки;
• таблицы.

Рабочий приём: держать рядом с проектом файл README.md, где простым языком описано, что это за приложение и как его запустить. И себе шпаргалка, и агенту контекст.

3. Где всё это живёт — редактор проекта

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

Это и есть редактор: VS Code, Cursor или Windsurf. Он работает как удобный пульт управления пространством проекта: открыть, найти нужное, посмотреть, что наделал агент, не теряя картину. Писать в нём код самому не придётся.

Текстовую часть — ТЗ, README, заметки — удобно держать в md-native приложении вроде Obsidian. Markdown везде одинаковый, так что заметки спокойно переезжают в проект.

И ещё: прямо в редакторе есть встроенный терминал. Что это и зачем — в следующем пункте.

4. Терминал — как агент работает с системой напрямую

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

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

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

• npm install — ставит зависимости проекта, то есть чужой код, на котором стоит свой;
• npm run dev — запускает проект локально, чтобы посмотреть в браузере;
• npm run build — собирает финальную версию и заодно показывает, есть ли ошибки.

И уметь базовое самому — хотя бы запустить приложение и открыть его в браузере.

5. Git и GitHub

Git — это сохранения в игре. Если запрос к нейронке что-то сломал, всегда можно откатиться на рабочую версию и выдохнуть. Без этого один неудачный запрос стирает час работы.

GitHub — место, где проект живёт, обновляется и передаётся другому человеку или агенту.

Минимальный набор действий:

• commit — сохранить точку в истории;
• push — отправить изменения на GitHub;
• pull — забрать изменения;
• branch — отдельная ветка под эксперимент;
• diff — посмотреть, что именно изменилось.

Руками с этим можно почти не возиться:

• GitHub Desktop — приложение с кнопками вместо команд. Видно, что изменилось, коммит и пуш делаются в один клик.
• Агент сам умеет работать с git и GitHub. Достаточно попросить «заведи репозиторий», «закоммить и запушь это отдельным понятным коммитом», «откатись на прошлую версию». Остаётся понимать, что произошло, и уметь вернуться назад.

6. Docker — одинаковое окружение везде

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

Ставить всё напрямую на компьютер или сервер выходит боком. Для «Обнимикапи» нужна одна версия вспомогательной программы, для соседнего проекта — другая, и на одной машине они дерутся за место. От каждого нового проекта система засоряется, и трогать её становится страшно. А когда приходит время переезжать на сервер, всю установку приходится повторять руками с нуля — десятки шагов, и где-нибудь обязательно разойдётся.

Docker упаковывает приложение вместе со всем его окружением в изолированную коробку — контейнер. Внутри лежит и сама «Обнимикапи», и нужные ей версии программ, и настройки. Эта коробка одинаково заводится где угодно: на ноуте, на сервере, в облаке. Ради этого Docker и придумали — чтобы «работает у меня» стало «работает везде», и чтобы проекты на одной машине не лезли друг к другу.

На бытовом уровне достаточно узнавать три слова:

• Dockerfile — рецепт коробки: что положить внутрь и как собрать;
• docker-compose.yml — как несколько коробок работают вместе, например «Обнимикапи» и её база;
• образ и контейнер — коробка собранная и коробка запущенная.

Писать Dockerfile руками не придётся, агент соберёт сам. От тебя нужно понимать, что лежит внутри коробки, и подавать туда секреты аккуратно, не зашивая прямо в код — про это следующий раздел.

7. Домены и серверы

Допустим, «Обнимикапи» готова и крутится у тебя на ноуте. Чтобы форму открыл любой человек из интернета, заявке нужно проделать путь от чужого телефона до твоего кода. Разберём этот путь как поездку, по шагам — теми же словами, что на картинке.

человек набирает obnimikapi.ru → DNS подсказывает, на какой компьютер ехать → запрос приходит на VPS → попадает в нужную дверь-порт → вахтёр-nginx пускает внутрь по HTTPS → открывается форма.

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

Дальше — как этот домик находят. Домен — это имя сайта, obnimikapi.ru, то, что человек набирает в адресной строке. Само по себе имя никуда не ведёт: браузеру нужен адрес конкретного компьютера. Подсказывает его DNS — справочное бюро интернета: по имени домена оно говорит, на какой именно VPS стучаться.

И наконец — как пускают внутрь. Запрос доехал до сервера, а на нём крутится много программ. Порт — это номер двери: он говорит, к какой именно программе пришёл запрос (сайты по HTTPS обычно слушают дверь 443). На входе стоит nginx (или Caddy) — вахтёр: принимает все входящие запросы и разводит их по нужным дверям, заодно держит HTTPS — замок, который шифрует трафик между человеком и сервером, чтобы телефоны записавшихся нельзя было подсмотреть по дороге. Без этого замка браузер честно пишет «не защищено».

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

8. Безопасность

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

Чтобы телефоны желающих обнять капибару не утекли, хватает усвоить минимум:

• .env — файл с секретами: ключи, пароли, токены. В Git он не уходит, для этого его добавляют в .gitignore. Код берёт значения из него, а сам файл остаётся только у тебя.
• Секрет может утечь в браузер. Если агент по ошибке вставил ключ в код фронтенда, его видно в консоли разработчика — то есть любому посетителю сайта. Это стоит проверять, особенно для ключей OpenRouter, доступов к базам, платёжкам и CRM.
• Лишние двери надо закрывать. База и внутренние сервисы не должны торчать во весь интернет — наружу смотрит только то, что должно (те самые порты и вахтёр-nginx из прошлого раздела).

Простое правило на каждый день: сомневаешься, можно ли это куда-то отправить — считай, что нельзя, и спроси у агента, не утечёт ли здесь секрет.

Когда что-то сломалось

Это будет, и это нормально. Что делать, не умея читать код:

1. Прочитать ошибку целиком. Последняя строка в логах обычно говорит суть: какого файла или пакета не хватает, какой порт занят, где упала проверка. Даже без деталей виден этаж пожара — форма, роут или база.
2. Скопировать ошибку агенту дословно и добавить контекст: что делалось, что ожидалось, что получилось. Голая ошибка без контекста лечится хуже.
3. Откатиться, если совсем поплыло. Git вернёт последнюю рабочую версию, и можно зайти на задачу заново.
4. Спрашивать по ходу: «что это за ошибка простыми словами и как починить её в моей ситуации». Такой разбор и решает проблему, и постепенно достраивает карту.

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

Частые вопросы

Мини-словарь

Чек-лист: что умеет нормальный вайбкодер

• открыть проект целиком в редакторе;
• самостоятельно запустить его локально;
• сохраняться в Git и откатываться при необходимости;
• держать ключи в .env и проверять, что они не утекли — ни в GitHub, ни в браузер;
• задеплоить проект на сервер и настроить автодеплой;
• закрыть порты от всего интернета;
• в идеале — знать про тесты и CI.

Как всё это изучить

Самый рабочий способ — просто начать делать то, что давно хотелось сделать в Codex или Claude Code (пусть даже свою «Обнимикапи»), и по ходу спрашивать у нейросети «как лучше сделать это в моей ситуации» и «что это такое и как это применить».

Схема простая:

1. ставится задача;
2. агент правит файлы, ловит ошибки и чинит;
3. человек уточняет, спрашивает и постепенно понимает, как управлять этим кодом, даже не умея его читать.

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