От идеи до продукта
на реальном устройстве

Когда ты вводишь адрес сайта в браузер — например, google.com — браузер сначала спрашивает у специального сервера (DNS): «А где физически живёт этот сайт?». DNS отвечает IP-адресом — чем-то вроде 142.250.185.46. Браузер идёт по этому адресу, стучится в сервер и говорит: «Дай мне главную страницу». Сервер отвечает HTML-кодом — и браузер превращает его в красивый интерфейс, который ты видишь.

Весь этот разговор происходит по протоколу HTTP (или HTTPS — защищённая версия). Это как язык, на котором браузер и сервер общаются. Каждый такой запрос-ответ занимает доли секунды, а за одну загрузку страницы таких запросов может быть десятки.

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

Клиент отвечает за то, что пользователь видит и с чем взаимодействует. Сервер отвечает за то, что происходит «под капотом»: хранит данные, проверяет права доступа, выполняет вычисления, общается с базой данных. Когда ты нажимаешь «Купить» в интернет-магазине — клиент отправляет запрос серверу, сервер проверяет наличие товара, списывает деньги и отвечает «Заказ принят».

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

Для разработчика терминал незаменим: именно через него запускают программы, устанавливают инструменты, работают с Git, деплоят приложения. AI-инструменты типа Claude умеют объяснять любую команду терминала — просто вставь непонятную строку в чат и спроси «что это делает».

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

GitHub, GitLab, Bitbucket — это облачные хранилища для Git-проектов. Туда «загружается» твой код, там он хранится в безопасности, и оттуда его может взять сервер для деплоя. Большинство хостинг-платформ (Vercel, Railway) деплоят приложение автоматически как только ты загружаешь новый код на GitHub.

Коммит (commit) — это сохранённая точка в истории проекта. Как «Сохранить» в игре: ты поработал, что-то сделал, сохранил состояние с описанием «добавил форму входа». Коммит хранится локально, на твоём компьютере. Важная традиция: коммиты делают часто и пишут понятные сообщения — чтобы через месяц было понятно что и зачем менялось.

Пуш (push) — это отправка локальных коммитов на удалённый сервер (GitHub). Без пуша твои сохранения существуют только на твоём компьютере. После пуша код становится доступен другим людям и платформам деплоя. Простая схема: сделал изменения → commit (сохранил локально) → push (отправил в облако).

Переменные окружения (environment variables, ENV) — это способ хранить секретные данные отдельно от кода. API-ключи, пароли к базе данных, токены — всё это нельзя писать прямо в коде и загружать на GitHub, потому что репозиторий может быть публичным, и эти данные увидят все.

Вместо этого ты создаёшь файл .env, добавляешь его в .gitignore (чтобы Git его игнорировал) и пишешь туда секреты. В коде обращаешься к ним через process.env.API_KEY. На хостинге те же переменные прописываются в настройках — Vercel, Railway и другие платформы имеют специальный раздел для ENV-переменных.

В разработке принято не писать всё с нуля — а использовать готовые библиотеки, которые другие программисты уже написали и опубликовали. Хочешь работать с датами? Возьми библиотеку dayjs. Хочешь красивые иконки? Возьми lucide-react. Хочешь отправлять email? Возьми nodemailer.

Пакетный менеджер — это инструмент, который скачивает эти библиотеки и управляет ими. npm и yarn — для JavaScript-проектов. pip — для Python. Все зависимости записываются в файл package.json или requirements.txt — поэтому другой человек (или сервер) может установить всё нужное одной командой.

Локальная разработка — это когда ты запускаешь своё приложение прямо на своём компьютере, для себя, без публикации в интернет. Обычно оно доступно по адресу http://localhost:3000 — только у тебя в браузере. Это безопасное место для экспериментов: можно ломать, чинить, пробовать новое — пользователи ничего не видят.

Именно здесь и происходит основная разработка. Сохранил код → браузер автоматически обновился → видишь результат. После того как всё работает локально — делаешь коммит, пуш и деплой на реальный сервер. Важный нюанс: «у меня работает локально, на сервере не работает» — классическая ситуация. Обычно причина в разных переменных окружения или отсутствующих зависимостях.

Качество кода, который генерирует AI, напрямую зависит от качества твоего описания. Расплывчатый промпт → расплывчатый результат. Конкретное ТЗ → рабочий код. Это главный навык вайбкодера: уметь точно описать что нужно сделать, каком стеке, с какими ограничениями и в каком формате получить результат.

Хороший промпт включает: контекст (что уже есть), задачу (что нужно добавить), технологии (React + Supabase + TypeScript), ограничения (не менять существующую структуру БД) и формат ответа (только код, без объяснений). Плохой промпт: «сделай форму входа». Хороший: «Добавь форму входа через email/пароль. Стек: React, Supabase Auth. Используй shadcn/ui компоненты. После входа редиректить на /dashboard. Показать ошибку если неверный пароль».

AI-модели имеют ограниченное «окно памяти» — context window. В рамках одного чата AI помнит всё что было сказано. Но если начать новый чат — AI не помнит ни предыдущего кода, ни принятых решений, ни контекста проекта. Это важно понимать при разработке больших проектов.

Лучшая практика: держи один долгий чат для одной задачи. Для нового чата давай AI краткий контекст: «Я делаю сервис для записи клиентов. Стек: Next.js, Supabase, TypeScript. Уже реализованы: авторизация, список клиентов. Сейчас нужно добавить...». Claude Projects решает эту проблему системно: ты один раз добавляешь файлы проекта и описание — и AI всегда знает контекст. Cursor и Windsurf тоже индексируют весь проект и используют его как контекст.

Ошибки в коде — это норма, а не признак того что что-то пошло не так. Даже опытные разработчики постоянно сталкиваются с багами. Разница в том, что с AI процесс отладки занимает минуты, а не часы: скопировал ошибку из консоли, вставил в чат — получил объяснение и исправление.

Ошибки бывают трёх типов: синтаксические (написал неправильно — код не запускается), логические (код работает, но делает не то) и runtime (запускается, но падает при определённых условиях). Для поиска ошибок используй консоль браузера (F12 → Console) — там видно все ошибки фронтенда. Для бэкенда — логи в терминале или в панели хостинга. Всё что нашёл — сразу в чат к AI с вопросом «что это значит и как исправить».

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

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

Не нужно изучать всё сразу. Каждый уровень — это реальный работающий продукт, а не просто теория. Начни с уровня 1, запусти что-то живое, потом переходи дальше.