← Вайбкодинг · Курс 30/70 EN FR Курс по OpenCode →

Практика курса

966 минут — 70% курса. Каждое задание заканчивается проверяемым результатом. Пометка [коммит] значит: прежде чем идти дальше, сделайте коммит.


Модуль 1. Окружение и первый результат — 105 мин

1.1 Окружение (20 мин)

  1. Поставьте агента с доступом к файлам (Claude Code / Cursor / Codex CLI).
  2. Проверьте: git --version, node --version, python --version.
  3. Создайте ~/projects/vibe-lab и откройте её агентом.

Критерий: агент сам, без ваших подсказок, читает файл в этой папке после запроса «прочитай README.md и перескажи в одну строку».

1.2 Первый репозиторий (20 мин)

  1. git init в vibe-lab.
  2. Создайте .gitignore (node_modules, .env, .venv, pycache, dist).
  3. Создайте README.md с одной строкой про проект.
  4. [коммит] — первый коммит до любого кода от ИИ.

Критерий: git log --oneline показывает один коммит; git status чистый.

1.3 Первая утилита (45 мин)

Задача агенту — строго по спеке ниже:

Цель: CLI-утилита читает текстовый файл построчно и выдаёт статистику.

Вход: путь к файлу аргументом. Выход в stdout:
  строк: N
  слов: N
  символов: N
  самая длинная строка: <номер>: <первые 40 символов>

Ограничения: только стандартная библиотека Python/Node, без новых зависимостей.
Один файл. Без цветного вывода, без флагов, без конфигов.

Критерии приёмки:
- файл из 3 строк даёт корректные три числа
- пустой файл: все нули, не падает
- отсутствующий файл: сообщение в stderr и код выхода 1
- файл без прав доступа: не стектрейс, понятное сообщение

Что не делаем: не добавляем флаги, не читаем stdin, не пишем лог-файлов.

Порядок: сначала попросите план (правок не делать) → потом реализацию → проверьте 4 критерия руками → [коммит].

1.4 Разбор диффа (20 мин)

Откройте git show последнего коммита и выпишите в notes.md: - какие файлы изменены и все ли они были в задаче; - есть ли красные флаги из теории (модуль 3, п. 3.2) — пока просто отметьте; - что вы приняли и что хотели бы завернуть.

Критерий: в notes.md минимум 3 наблюдения по диффу.


Модуль 2. Спека — 105 мин

2.1 Спека проекта (30 мин)

Выберите маленький проект (не капстоун), например «конвертер Markdown → HTML» или «трекер привычек в консоли». Напишите спеку по шести блокам из теории.

Критерий: спека ≤ 15 строк; в блоке «критерии приёмки» минимум 4 пункта, каждый проверяем командой или наблюдением; есть блок «что не делаем».

2.2 Плохая формулировка против спеки (30 мин)

  1. Создайте ветку exp/bad и дайте агенту запрос: «сделай конвертер markdown в html». Получите результат, зафиксируйте: сколько файлов, сколько строк.
  2. Откат: git checkout main.
  3. Ветка exp/good, тот же проект — по вашей спеке.
  4. Заполните таблицу в notes.md:
Без спеки Со спекой
файлов изменено
строк диффа
критериев приёмки пройдено
итераций до приемлемого

Критерий: таблица заполнена; вы можете назвать 2 конкретные причины разницы.

2.3 Декомпозиция (20 мин)

Разбейте спеку на 5 задач, каждая — 15–20 минут работы агента. Формат каждой: заголовок + критерий приёмки + «не трогать».

Критерий: у каждой задачи дифф ожидается < 80 строк; ни одна задача не содержит союза «и» в названии (признак склейки двух задач).

2.4 Критерий приёмки → условие /goal (15 мин)

Возьмите одну задачу из декомпозиции 2.3 и перепишите её критерий приёмки в условие остановки агента. Требования к условию:

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

Пример:

/goal pytest tests/ выходит с кодом 0, ruff check src/ чист,
git diff --name-only показывает только src/converter/, или стоп после 12 ходов

Запустите, не вмешиваясь, и запишите в notes.md:

Факт
ходов до остановки
условие выполнено с первого захода: да/нет
что агент менял вне разрешённой папки
чего не хватило в формулировке

Критерий: условие записано в notes.md; в таблице заполнены 4 строки; если условие оказалось невыполнимым, вы можете назвать, какой признак был непроверяемым.

2.5 Ретро (10 мин)

В notes.md: что в спеке оказалось лишним, что пришлось дописать в процессе, какой критерий оказался непроверяемым.

[коммит] — спека и заметки в репозитории.


Модуль 3. Цикл работы — 105 мин

3.1 Восемь формулировок (25 мин)

Задача одна на все восемь: «в утилите из модуля 1 нужно ограничить длину строки вывода 40 символами». Напишите 8 вариантов запроса:

  1. Слишком короткий: «ограничь длину строки».
  2. Слишком широкий: «улучши вывод утилиты».
  3. Без контекста: «добавь обрезку».
  4. С контекстом и файлом: «в stat.py, функция вывода…».
  5. Со критерием: «…строка длиннее 40 символов обрезается и получает ...».
  6. С границей: «ровно 40 символов не обрезается».
  7. С запретом: «…не меняй подсчёт символов, не рефактори остальное».
  8. С форматом: «сначала покажи план, правок не делай».

Критерий: в notes.md восемь вариантов и напротив каждого — предсказание, что сделает агент (сбудется или нет — отметите после прогона 2–3 вариантов).

3.2 Фича в четыре шага (40 мин)

Возьмите задачу из 2.3 и выполните её ровно четырьмя шагами, после каждого — проверка и [коммит]:

  • шаг 1: тест или ручная проверка, фиксирующая текущее поведение;
  • шаг 2: минимальная правка под критерий;
  • шаг 3: граничный случай (пусто / максимум / неверный тип);
  • шаг 4: сообщение об ошибке или README.

Критерий: 4 коммита; каждый дифф читается за 5 минут; git log --oneline показывает 4 разных сообщения.

3.3 Найди красные флаги (25 мин)

Попросите агента: «добавь обработку ошибок в утилиту». Скорее всего получите дифф с 2–4 флагами. Пройдите по списку 3.2 и выпишите найденное в notes.md с номерами строк.

Критерий: найдено минимум 2 флага; для каждого написано, чем он опасен.

3.4 Ретро (15 мин)

Сколько откатов сделали, на каком шаге потеряли больше всего времени, какой элемент запроса (контекст/критерий/запрет) дал больше всего пользы.


Модуль 4. Контекст — 105 мин

4.1 Файл инструкций (30 мин)

Создайте AGENTS.md (или CLAUDE.md) по шаблону из теории 4.2, заполните под свой проект: стек, команды, правила, запреты.

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

Критерий: файл на месте, агент отвечает верно; [коммит].

4.2 Один чат против трёх (45 мин)

Возьмите 3 мелкие задачи (например: добавить счётчик слов; поправить формат вывода; добавить проверку кодировки файла).

  • Прогон A: все три задачи в одном чате подряд, без очистки.
  • Прогон B (git reset между): каждая задача в новом чате.

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

Критерий: таблица сравнения A/B в notes.md + вывод в одну строку.

4.3 Сброс сессии (20 мин)

Возьмите любую сломанную ситуацию (или искусственную: попросите агента сделать заведомо неверное изменение). Практикуйте приём: новый чат + 3 факта (что происходит, чего ждали, стектрейс) + «предложи 3 проверяемые гипотезы, правок не делай».

Критерий: в notes.md записан шаблон сообщения-сброса, который сработал.

4.4 Ретро (10 мин)

Какое правило в инструкции сэкономило больше всего времени? Какое оказалось бесполезным? Удалите бесполезные.


Модуль 5. Отладка — 105 мин

5.1 Три бага (20 мин)

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

Для каждого бага: команда/файл, который его воспроизводит.

Критерий: три воспроизводимых кейса, записанных в bugs.md.

5.2 Три фикса (50 мин)

На каждый баг — строго по циклу: гипотеза → проверка → правка → [коммит]. Гипотеза обязана быть сформулирована до правки и записана в bugs.md в формате «если ..., то ...».

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

5.3 Спровоцируйте спор (25 мин)

Дайте агенту заведомо неверную гипотезу: «проблема в кодировке файла, исправь чтение как latin-1». Смотрите, будет ли он спорить.

Если спорит — хорошо. Если нет — учитесь формулировать: «прежде чем править, проверь эту гипотезу и скажи, подтверждается ли она. Если нет, правок не делай».

Критерий: в notes.md записана формулировка, после которой агент начал проверять гипотезу, а не выполнять её.

5.4 Ретро (10 мин)

Сколько циклов до фикса в среднем? Что сократило бы это вдвое?


Модуль 6. Тесты — 105 мин

6.1 Тест-раннер (20 мин)

Поставьте vitest (Node) или pytest (Python). Один тест на существующую функцию из модуля 1. Запустите.

Критерий: npm test / pytest зелёный; команда записана в AGENTS.md.

6.2 TDD-цикл, 5 тестов (45 мин)

Новая фича: в утилите — флаг --top N, показывающий N самых длинных строк.

Для каждого из 5 тестов: написать тест → убедиться, что падает по правильной причине → реализация → зелёный → [коммит].

Тесты: (1) без флага поведение прежнее; (2) --top 3 даёт 3 строки; (3) --top 0 — пустой вывод, код 0; (4) --top abc — ошибка, код 1; (5) файл с 2 строками и --top 5 — 2 строки.

Критерий: 5 коммитов; для каждого теста в notes.md записана причина падения до реализации (не «модуль не найден»).

6.3 Проверка на прочность (30 мин)

Попросите агента: «сломай реализацию --top — верни все строки. Тесты должны это поймать. Не правь тесты».

  • Если тесты поймали — верните реализацию, [коммит].
  • Если не поймали — тест декоративный, переписать и повторить.

Критерий: минимум один тест поймал поломку; в notes.md — какие тесты оказались бесполезными и почему.

6.4 Ретро (10 мин)

Сколько тестов на строку кода у вас получилось? Сколько границ покрыто: пусто / максимум / неверный тип / нет сети?


Модуль 7. Данные, API, безопасность — 105 мин

7.1 Секреты (20 мин)

.env с тестовым ключом, .env.example без значения, .gitignore с .env. Проверьте: git status не видит .env; git log --all -p | grep <ключ> пуст.

Критерий: ключ отсутствует в истории git; .env.example в репозитории.

7.2 API: curl → клиент → ошибки (50 мин)

Возьмите публичный API без ключа (например, открытые курсы валют или погоду).

  1. curl руками, сохраните реальный ответ в fixtures/sample.json.
  2. Дайте агенту этот файл: «вот реальная форма ответа, используй только эти поля».
  3. Клиент + валидация ответа.
  4. Обработка ошибок: 4xx, 5xx, таймаут, невалидный JSON.

Критерий: 4 сценария ошибок обработаны и проверены руками; ни одного поля, которого нет в sample.json.

7.3 Тесты на плохие данные (25 мин)

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

Критерий: 4 теста зелёные; при удалении валидации они падают.

7.4 Ретро (10 мин)

Чему агент соврал (метод, параметр, поле) и как вы это поймали?

[коммит] — всё вместе.


Модуль 8. Деплой и гигиена — 105 мин

8.1 Ветки и PR (15 мин)

main защищён (в настройках GitHub). Работа только через ветку и PR. Сделайте один PR по задаче из модуля 6.

Критерий: прямой пуш в main отклоняется; PR содержит описание: что/зачем/как проверить.

8.2 Деплой (40 мин)

Задеплойте проект на Vercel или Netlify: подключите репозиторий, задайте переменные окружения в панели, дождитесь сборки, откройте ссылку.

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

8.3 Ломаем и откатываем (35 мин)

  1. Задеплойте коммит с явной поломкой (например, бросает исключение на главной).
  2. Убедитесь, что прод сломан.
  3. Откат №1: редеплой предыдущей версии из панели. Замерьте время.
  4. Откат №2: git revert в ветку → PR → мердж → автодеплой. Замерьте время.
  5. Запишите оба замера в notes.md.

Критерий: оба способа отработали; время каждого замера записано.

8.4 Ревью по чек-листу (15 мин)

Возьмите свой последний PR и пройдите 12 пунктов ревью из теории 8.4. Проблемы — в комментарии к PR, исправление — отдельным коммитом.

Критерий: чек-лист пройден, минимум одна проблема найдена и исправлена.


Модуль 9. Капстоун — 126 мин практики

9.1 Старт (16 мин)

  • Выбрать проект из 05-proekty.md.
  • Спека на 10 строк + 4 шага сборки (из теории 9.2).
  • git init, .gitignore, .env.example, AGENTS.md, README-заготовка.
  • [коммит]

Критерий: спека и план в репозитории; репозиторий создан на GitHub.

9.2 Ядро (60 мин)

Главный сценарий end-to-end на минимальных данных. Ветка → 4 коммита → проверка главного сценария руками каждый шаг.

Критерий: главный сценарий проходит целиком локально.

9.3 Обвязка (30 мин)

  • Обработка ошибок: минимум 3 сценария.
  • Один тест на главный сценарий (+ один на границу, если успеваете).
  • README: запуск с нуля, известные ограничения.

Критерий: npm test зелёный; README позволяет запустить проект с нуля (проверьте в чистой папке: git clone → по инструкции → работает).

9.4 Деплой и сдача (20 мин)

  • Деплой, переменные окружения на хостинге.
  • Открыть ссылку с телефона, пройти главный сценарий.
  • Пройти чек-лист сдачи из теории 9.4, отметить пункты в 06-tracker.md.
  • [коммит] + [мердж PR]

Критерий: публичная ссылка живая, чек-лист сдачи полностью отмечен.


Как понять, что модуль пройден

Модуль считается пройденным, когда выполнены все критерии его практики и отметки стоят в 06-tracker.md. Не «в основном», не «почти» — критерий либо выполнен, либо нет. Это та же дисциплина, которую вы требуете от агента.