Читать книгу: «Вайбкодер, или Как подружиться с ИИ»

Манифест «Вайбкодера»

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

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

* * *

Мы здесь не за магией, а за результатом

ИИ — не оракул. Он не «знает», он угадывает. Иногда гениально, а иногда — как стажёр после трёх энергетиков.

ИИ — партнёр по черновикам. Он отлично делает «первую версию», «черновик», «варианты». А вот «истину», «правильно» и «в прод» — это всё ещё ваша зона ответственности.

Вайбкодинг — это дисциплина, а не настроение. «Вайб» — не когда вы просите «сделай красиво», а когда у вас выстроен процесс: контекст → итерации → проверка.

* * *

Три закона вайбкодера

ИИ ускоряет черновик, но не снимает ответственность. Ship’ите вы, не модель.

Качество = ваш контекст + ваша проверка. Не «умность промпта», не «новейшая версия LLM модели» и не «самоуверенность ответа».

Инструменты меняются, цикл остаётся. Задача → черновик → ревью → тест → решение.

* * *

Как выглядит дружба с ИИ (а не токсичные отношения)

Дружба — это когда у вас есть:

Границы. ИИ — да: идеи, черновики, шаблоны, тест-кейсы, рефактор по ТЗ.

ИИ — нет: «держи ключи», «реши за меня домен», «потрогай прод», «крипту напиши сам».

Ритм. Маленькие шаги. Короткие диффы. Частые проверки.

Большие запросы = большие сюрпризы. Обычно неприятные.

Трезвость. Если вы не можете объяснить изменение коллеге — значит, вы не поняли, что делаете. Значит, стоп.

* * *

Обещание книги (без маркетинговой пены)

После книги вы:

перестанете путать LLM, чат, IDE-помощника и агента (и перестанете спорить о терминах в комментариях),

перейдёте от «пишу в чатик» к системной работе: контекст, проверка, безопасность, экономия лимитов,

освоите SDD (Spec-Driven Development) — чтобы ИИ делал ровно то, что надо, а не то, что «понял по вайбу»,

научитесь не сжигать квоту в первый день и не покупать «ещё пакет токенов» вместо здравого смысла.

* * *

Чего книга не обещает (и слава богу)

Не обещает «сделай фичу без понимания» и «в прод одним промптом».

Не обещает вечный список «топ-10 инструментов на все времена» (интернет уже завален такими археологическими артефактами).

Не обещает, что ИИ перестанет ошибаться. Она обещает, что вы научитесь ловить ошибки дёшево, до того как они станут дорогими.

* * *

Правила безопасности (скучно, зато выживем)

Секреты и PII в чат не несём. Никогда. Даже «на минутку».

Большие изменения без тестов и ревью не вливаем. Никогда. Даже «оно же работает».

Деньги, безопасность, прод — только по процессу. ИИ помогает думать, но не подписывает вам релиз.

* * *

Для кого этот манифест

Для джуна и мидл− (dev/QA), которые хотят не хайп, а чёткий маршрут:

от первого диалога с ИИ — к SDD и своим агентам — оставаясь профессионалами, а не пассажирами автопилота.

Глава 1. Вайбкодинг: что это и чем точно не является

Зачем эта глава

Слово «вайбкодинг» звучит как мем. И это частично правда — мемы рождаются там, где много хайпа и мало определений.

Но за мемом стоит реальная практика: как программист/тестировщик использует ИИ каждый день, не теряя профессионализм.

Эта глава — про смысл слова в контексте этой книги. Не про тренды Twitter и не про «замену джунов».

* * *

Определение (рабочее, без магии)

Вайбкодинг — это осознанная работа с ИИ в разработке и тестировании по циклу:

задача → контекст → черновик → проверка → решение

Где:

ИИ ускоряет черновики (код, тесты, spec, объяснения)

вы держите контракт, границы, ревью и ответственность за результат

«Вайб» здесь — не «попросил красиво и надеюсь».

«Вайб» — ритм маленьких итераций и привычка не верить уверенному тону модели.

* * *

Чем вайбкодинг НЕ является

Если узнали себя в левой колонке — добро пожаловать в клуб. Выход есть: глава 7.

* * *

Три закона (они будут повторяться — специально)

Из манифеста:

ИИ ускоряет черновик, не снимает ответственность.

Качество = ваш контекст + ваша проверка.

Инструменты меняются, цикл остаётся.

Запомните их как «стоп-слова», когда хочется нажать «принять весь diff».

* * *

Мини-история: два джуна и один Task keeper

Джун A (вайб без дисциплины):

«Сделай мне REST API для задач на Go»

Получил: gin, postgres, JWT, CRUD, 600 строк. Тестов нет. В прод не пойдёт, в голове — каша.

Джун B (вайбкодер):

«Go, net/http, spec 0001, шаг 1: только internal/storage + unit tests»

Получил: маленький пакет, go test зелёный, понимает каждую строку.

Разница не в «умности промпта». Разница в цикле и границах.

Подробный walkthrough — глава 4.

* * *

Кому подходит вайбкодинг

Хорошо заходит:

джунам и мидл−, которые хотят ускорить рутину и учиться на объяснениях

тестировщикам/SDET — черновики кейсов, чек-листы, скелеты автотестов (глава 10)

тем, кто устал от «вечного гугления синтаксиса»

С осторожностью:

если в компании запрет на внешние LLM — сначала политика (глава 5)

если нет тестов и культуры ревью — ИИ ускорит хаос (глава 13)

Плохо заходит:

как оправдание «я не разбираюсь, но залил»

для задач с высокой ценой ошибки без экспертизы (глава 8)

* * *

Что вы получите, если дочитаете книгу

Не «секретный промпт». А систему:

* * *

Домашка (15 минут)

Прочитайте “Манифест” и выпишите один пункт, который вам «не нравится» — и один, с которым согласны

Сформулируйте для себя: что вы готовы отдать ИИ, а что — нет (3 пункта в каждой колонке)

Откройте главу 4: соберите Task keeper сами по шагам или разберите готовый taskkeeper (https://github.com/dontagr/taskkeeper) и тренируйтесь на доп. задачах (тесты, ревью)

* * *

Что дальше

Глава 2 — разложим по полочкам: LLM, чат, copilot, агент — без путаницы в терминах.

Глава 2. LLM, чат, copilot, агент: одна схема без боли в голове

Термины: глоссарий

Углубление: глава 11

Сквозной пример: Task keeper (https://github.com/dontagr/taskkeeper)

* * *

Зачем эта глава

В комментариях, на митингах и в резюме путают:

«мы используем GPT»

«у нас агент в Cursor»

«copilot всё написал»

Часто это одно и то же под разными названиями. Иногда — разные вещи, и путаница стоит денег.

Эта глава — карта местности. Без курса ML. С примерами из жизни разработчика.

* * *

LLM — «мозг», который угадывает текст

LLM (Large Language Model) — большая языковая модель.

Она предсказывает следующий токен (слово/кусок) по контексту.

Важно:

она не «знает» ваш проект, пока вы не дали контекст

она не «понимает» в человеческом смысле — она генерирует правдоподобное

код для неё — тоже текст

Отсюда три следствия:

Ответ может быть уверенным и неверным

Чем лучше контекст, тем лучше ответ (глава 6)

Проверка обязательна — тесты, spec, ревью

* * *

Чат — интерфейс разговора с LLM

Чат (ChatGPT, Claude в браузере, вкладка в IDE) — способ диалога: вы пишете, модель отвечает.

Силён в:

объяснениях («почему 201, а не 200?»)

черновиках (тест-кейс, кусок функции, spec)

сравнении вариантов

вопросах «что я не учёл?»

Слаб в:

длинных цепочках действий без вашего участия

«сделай весь проект» без границ

задачах, где нужны руки (запустить тест, прочитать 50 файлов)

Пример (Task keeper):

«Объясни, зачем для POST /tasks нужен статус 201 Created, а не 200»

Это чат. И это нормально.

* * *

Copilot / IDE-ассистент — подсказки в моменте

Copilot (и аналоги в Cursor, JetBrains, VS Code) — LLM внутри редактора:

автодополнение строки/блока

«допиши функцию по комментарию»

локальный рефактор выделенного кода

Силён в:

рутине внутри файла

шаблонном коде (boilerplate, тест-скелет)

ускорении набора, когда вы уже знаете, что хотите

Слаб в:

архитектурных решениях «на весь репо»

соблюдении вашего spec без явной ссылки

гарантии, что подсказка не нарушит контракт API

Правило: copilot — ускоритель печати, не архитектор.

* * *

Агент — LLM + руки + цикл

Агент — это не «модель получше». Это организация работы:

«Руки» — инструменты: чтение/запись файлов, терминал, поиск по репо, иногда браузер.

Силён в:

«сделай N шагов, пока go test не зелёный»

повторяющемся цикле «починил → запустил → прочитал ошибку»

Опасен в:

широких правах без spec и стоп-условий

security/деньги/prod (глава 8)

Подробно: глава 11.

* * *

Одна схема

LLM → чат → copilot → агент → SDD

Как выбирать за 10 секунд:

* * *

Частые путаницы (разбор по-взрослому)

* * *

Азбуковник

Таблица терминов, шпаргалка «чат / copilot / агент» и разбор путаницы в речи — вынесены в отдельную главу Голосарий.

* * *

Практика: назовите инструмент правильно

Три ситуации — как бы вы назвали инструмент?

В браузере спросили, как оформить bug report → чат

В Go-файле Tab дописал тело функции → copilot

«Почини тесты, пока не пройдут» — IDE сама правит файлы и запускает go test → агент

Если в вашей компании всё это называют «ИИ» — ок. Но в голове держите различие — проще выбирать режим работы.

* * *

Что дальше

Глава 3 — не «топ-10 приложений», а классы инструментов и как выбрать под задачу, чтобы не устареть через квартал.

Глава 3. Что есть на рынке: классы инструментов (не «топ-10 на май»)

Термины: глава 2 · глоссарий

Выбор режима: глава 11

Безопасность: глава 5

* * *

Зачем эта глава

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

Поэтому эта глава не — рейтинг «лучших IDE 2026».

Это — классы инструментов и принципы выбора. Они переживут смену брендов.

* * *

Пять классов (карта рынка)

Класс A: Веб-чаты с LLM

Что это: ChatGPT, Claude, Gemini в браузере (и аналоги).

Для чего:

учёба, объяснения, brainstorm

черновики spec, тест-кейсов, писем

разбор ошибок (без секретов в промпте!)

Минусы:

нет прямого доступа к вашему репо (если не копируете контекст)

легко «слить» лимиты большими вставками

Когда достаточно: вы только начинаете, или задача — текст/идеи.

* * *

Класс B: IDE с встроенным ИИ (чат + edit + иногда agent)

Что это: Cursor, Windsurf, JetBrains AI or plugins, Copilot в VS Code и т.д.

Для чего:

ежедневная разработка: правки в файлах, чат по коду

контекст репозитория (индексация, @file)

agent mode: цикл «правка → тест»

Минусы:

нужна политика компании (куда уходит код)

соблазн «принять весь diff»

Когда выбирать: основной рабочий инструмент dev/QA с доступом к репо.

* * *

Класс C: CLI / терминальные ассистенты

Что это: ИИ в терминале: объяснение команд, скрипты, иногда агентные циклы.

Для чего:

DevOps-рутина, одноразовые скрипты

«как сделать X в git/kubectl»

Минусы:

высокий риск выполнить опасную команду без понимания

секреты в истории shell

Правило: вы нажимаете Enter. ИИ предлагает — вы отвечаете.

* * *

Класс D: API + свои интеграции (боты, CI, внутренние порталы)

Что это: вызываете LLM через API в пайплайнах: review bot, генерация release notes, помощник в Slack, помощник в Jira.

Для чего:

команда, стандартизация, корпоративный контур

RAG по внутренней документации

Минусы:

нужны инженеры, безопасность, бюджет

легко сделать «бота, которому никто не доверяет»

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

* * *

Класс E: Специализированные продукты

Что это: code review bots, test generators, security scanners с LLM, low-code с ИИ.

Для чего:

узкая задача: ревью PR, генерация тестов, поиск уязвимостей

Минусы:

vendor lock-in

«коробка» не знает ваш spec

Правило: смотрите, встраивается ли в ваш цикл (глава 7), а не «у них красивый сайт».

* * *

Как выбрать инструмент под задачу (чеклист)

Ответьте на 5 вопросов — не на «какой бренд круче»:

Нужен доступ к репозиторию?

Нет → класс A. Да → B или D.

Нужны автоматические действия (тесты, файлы)?

Да → B (agent) или D. Нет → A или copilot.

Политика компании разрешает внешний LLM?

Нет → только корп. решение (D) или локальные модели (если есть).

Какая цена ошибки?

Высокая → меньше автономии, больше spec и ревью (глава 8).

Кто платит и за что?

Подписка, API по токенам, место в CI — см. глава 5.

* * *

Сценарии для dev и QA (без названий брендов)

* * *

Корпоративный контур: что спросить у компании

Перед установкой «очередной крутой IDE»:

Можно ли отправлять исходный код во внешний сервис?

Есть ли корп. альтернатива (внутренний чат, on-prem)?

Как хранятся логи промптов? Кто имеет доступ?

Что делать с секретами в коде (pre-commit, сканеры)?

Нужно ли указывать в PR, что код писался с ИИ?

Если ответов нет — работайте как минимум с главой 5 и не кладите в чат .env.

* * *

Как не устареть через квартал

Думайте классами, не брендами.

Фиксируйте процесс (цикл, spec, PR-шаблон) — он переживёт смену IDE.

Ведите notes/tools.md (https://github.com/dontagr/taskkeeper/blob/main/notes/tools.md): что пробовали, что сработало, политика компании.

Раз в квартал — 30 минут: «наш класс B всё ещё лучший выбор?»

* * *

Миф «нужен один идеальный инструмент»

На практике у вайбкодера часто стек из 2–3 классов:

B — основная разработка

A — быстрые вопросы без открытия IDE

D (опционально) — команда, CI, боты

Главное — не плодить 7 подписок и не дублировать одно и то же в трёх чатах.

* * *

Связка с книгой (маршрут читателя)

* * *

Домашка

Определите, какой класс у вашего текущего инструмента (A–E)

Выпишите одну боль: лимиты / политика / непонимание agent mode

* * *

Что дальше

Глава 4 — перестаём теорию: один рабочий день с ИИ на Task keeper.

Список конкретных продуктов намеренно не включён — заполните notes/tools.md (https://github.com/dontagr/taskkeeper/blob/main/notes/tools.md) под свой стек.

Глава 4. Первый рабочий день с ИИ (на примере Task keeper)

Сквозной проект: Task keeper на Go — HTTP API (net/http), два эндпоинта, in-memory storage, unit-тесты.

Код: taskkeeper на GitHub (https://github.com/dontagr/taskkeeper)

Спека: spec 0001 (https://github.com/dontagr/taskkeeper/blob/main/specs/0001-task-keeper.md)

Манифест: если забыли, почему мы не «верим на слово» — вернитесь к «Манифесту»

* * *

Зачем эта глава

Первый день с ИИ — это не день, когда вы «научились промптить». Это день, когда вы один раз прошли цикл:

задача → контекст → черновик → проверка → маленький фикс.

Без этого цикла любой инструмент (чат, Cursor, агент) превращается в генератор красивых диффов, которые вы боитесь трогать.

Сегодня мы не строим Netflix. Мы строим Task keeper — сервис, который умеет сохранить задачу и отдать её по id. Скучно? Отлично. Скучные задачи — лучший полигон: мало домена, много инженерии.

* * *

Что вам понадобится (15 минут подготовки)

Go 1.22+ (или ваша LTS-версия — главное, чтобы go test работал)

Редактор с ИИ (чат в браузере, IDE-copilot — неважно; важен процесс)

Клон репозитория: git clone https://github.com/dontagr/taskkeeper.git (или своя пустая папка + модуль taskkeeper)

Открытая spec 0001 (https://github.com/dontagr/taskkeeper/blob/main/specs/0001-task-keeper.md) — это ваш «контракт», не ваш «вайб»

Правило дня: ИИ пишет черновик, вы принимаете решения и вы жмёте «ок, ship».

* * *

План дня (4 итерации, ~1–2 часа)

Не просите «сделай весь сервис». Просите одну итерацию. Иначе получите музей кода: красиво, много, и страшно.

* * *

Итерация 0: прочитайте spec как тестировщик

Откройте spec 0001 (https://github.com/dontagr/taskkeeper/blob/main/specs/0001-task-keeper.md) и выпишите себе три списка:

Must have: R1–R5, форматы JSON, коды ошибок

Must not: не-цели (нет auth, нет БД, нет update/delete)

Как поймаем баги: раздел 10 (unit + httptest)

Если ИИ предложит «добавим JWT и Postgres для надёжности» — это не забота. Это саботаж spec.

* * *

Итерация 1: storage (без HTTP, без героизма)

Что делаем

In-memory хранилище: Create(title) -> Task, Get(id) -> (Task, ok).

По spec:

id: t_000001, t_000002, …

потокобезопасность: sync.RWMutex

пустой/длинный title — валидация (можно в internal/task, можно в storage — но одно место)

Промпт для ИИ (скопируйте целиком)

###

Ты помощник по Go. Работай строго по spec ниже. Маленький дифф, один пакет за ра з.

Сейчас: только internal/storage (+ при необходимости internal/task). Не делай HTTP, не делай main, не добавляй зависимости.

Spec (фрагмент):

- Create возвращает Task с id t_000001, t_000002...

- Get по id, если нет — ошибка not found

- Потокобезопасность: RWMutex

- title: TrimSpace, длина 1..200, иначе invalid argument

Сгенерируй:

1) типы

2) MemoryStore с Create/Get

3) table-driven unit tests

После кода: список edge cases, которые ты покрыл тестами.

###

Как проверяете (вы, не ИИ)

Красные флаги:

тесты «зелёные», но id не того формата (1, uuid) — не по spec

нет теста на «несуществующий id»

Create без lock — гонки (поймаете позже, но лучше сейчас)

* * *

Итерация 2: POST

/tasks

(httptest)

Что делаем

Хендлер создания:

POST /tasks → 201 + JSON task

пустой title / мусорный JSON → 400 + { “error”: { “code”, “message” } }

Промпт

###

Продолжаем Task keeper на Go. Есть internal/storage (готов).

Сейчас: internal/httpapi — только POST /tasks + тесты через net/http/httptest. Используй net/http, без сторонних роутеров.

Ошибки — JSON формат из spec (invalid_argument).

Не делай GET пока. Не делай main.

В конце: какие тесты добавил и какие коды статусов проверил.

###

Проверка

Типичный провал ИИ: статус 200 вместо 201, или ошибка текстом, а не JSON. Spec не обсуждает — spec выполняет.

* * *

Итерация 3: GET

/tasks/{id}

Промпт

###

Добавь GET /tasks/{id} в internal/httpapi.

200 — task JSON, 404 — not_found в формате error из spec.

Тесты httptest: happy path (создали через POST, получили через GET) + unknown id -> 404.

###

Проверка

Снова go test ./internal/httpapi/… -v.

Совет: один тест «POST потом GET» ловит половину интеграционных косяков без Docker и без драмы.

* * *

Итерация 4:

main

и ручной smoke

Промпт

###

Добавь cmd/taskkeeper/main.go: поднимает HTTP сервер на :8080, роутит /tasks. Минимум кода. README: как запустить и примеры curl для POST и GET.

###

Ручная проверка (2 минуты, зато честно)

Если curl не совпал с тестами — верите тестам, чините код, не «ну curl же как-то странно».

* * *