Семинар 3: «В лоб» не работает — от провала к системному подходу

Контекст

На предыдущем семинаре (С2) студенты получили задание: выбрать pet-проект, написать мини-спецификацию и попытаться реализовать MVP «в лоб» — одним промптом или минимальным диалогом. На Лекции 3 мы разобрали, почему это ломается (антипаттерны, 4 стратегии контекста, SDD). Сегодня соединяем теорию с практикой.

Формат: 70 минут, гибрид разбора провалов и live-демо

---

Часть 1: Разбор провалов (25 мин)

Показ результатов ДЗ (15 мин)

3-4 студента шарят экран и показывают:

• Свой исходный промпт (что просили)
• Что получилось (где сломалось)
• В какой момент модель потеряла контекст или ушла не туда

Вопросы для обсуждения каждого кейса:

• Какой антипаттерн из Л3 тут сработал? (Kitchen Sink? Implicit Requirements? Оверинжиниринг?)
• Что бы вы изменили, зная то, что знаете после Л3?
• Был ли момент, когда можно было «спасти» сессию, или нужно было начинать заново?

Сбор антипаттернов (10 мин)

Преподаватель фиксирует на доске/экране общий список:

Антипаттерн	Сколько студентов столкнулись	Пример
Монолитный промпт	?	«Сделай мне todo-приложение с авторизацией, базой данных и деплоем»
Неявные требования	?	«Не сказал про валидацию — модель её не сделала»
Prompt rot	?	«Переключился на другую модель — всё сломалось»
Оверинжиниринг	?	«Модель создала 15 файлов для hello world»
Потеря контекста	?	«После 5-й итерации модель забыла начальные требования»

Вывод

Наивный подход ломается предсказуемо. Одни и те же антипаттерны повторяются у всех. Это значит, что их можно предотвратить системно.

---

Часть 2: Live-демо — тот же проект, но через GSD (30 мин)

Идея

Берём один из сломанных проектов студента (самый показательный провал из части 1) и реализуем его заново — но через системный подход с использованием GSD (Get Shit Done).

Почему GSD: это open-source инструмент, который реализует все концепции из Л3 — spec-driven development, context engineering (write/select/compress/isolate), wave-based параллелизм, атомарные коммиты. Студенты видят теорию в действии.

Ход демо

Шаг 1: Инициализация проекта (3 мин)

# Создаём новый проект через GSD
/gsd:new-project

GSD задаёт уточняющие вопросы (борьба с implicit requirements). Сравниваем: студент написал один промпт → GSD провёл 5-7 вопросов и получил полное понимание задачи.

Параллель с Л3

Это итеративный бриф из блока 4. GSD автоматизирует то, что мы обсуждали как ручной процесс.

Шаг 2: Требования и роадмап (5 мин)

GSD генерирует:

• PROJECT.md — видение проекта
• REQUIREMENTS.md — структурированные требования (v1/v2)
• ROADMAP.md — фазы реализации

Показываем файлы: вот ваша «спецификация», которая живёт в файловой системе, а не в голове. Это стратегия Write — знания записаны за пределами контекстного окна.

Шаг 3: Обсуждение фазы (3 мин)

/gsd:discuss-phase

GSD выявляет неочевидные решения до начала кодинга. Спрашиваем группу: «Какие из этих вопросов вы бы не подумали задать?»

Шаг 4: Планирование (5 мин)

/gsd:plan-phase

GSD запускает researcher → planner → checker. Показываем PLAN.md:

• Задачи в XML-формате с полями <files>, <action>, <verify>, <done>
• Зависимости между задачами
• Wave-группировка (независимые задачи параллельно)

Параллель с Л3

Вертикальные слайсы + acceptance criteria (GIVEN/WHEN/THEN) — только автоматизированные. Каждая задача помещается в одно контекстное окно — «железное правило» GSD.

Шаг 5: Выполнение (10 мин)

/gsd:execute-phase

Наблюдаем:

• Субагенты запускаются с чистым контекстом (Isolate)
• Каждый получает только свою задачу + релевантный контекст (Select)
• Атомарные коммиты после каждой задачи
• Верификация (lint/test/build) после каждого шага

Ключевой момент: сравнить с наивным подходом. Студент потерял контекст через 5 итераций. GSD выполняет 10+ задач, и каждая начинается с чистого контекста.

Шаг 6: Результат (4 мин)

Показываем:

• Рабочий код (vs сломанный MVP из части 1)
• Чистая git-история с атомарными коммитами (vs один коммит «initial commit»)
• Файлы .gsd/ как документация проекта (PROJECT.md, REQUIREMENTS.md, PLAN.md)

Сравнительная таблица (на доске)

	«В лоб» (ДЗ)	Через GSD (демо)
Подготовка	0 мин	10 мин (инициализация + план)
Результат	Сломанный MVP	Рабочий код
Git история	1-2 коммита	10+ атомарных коммитов
Документация	Нет	PROJECT.md, REQUIREMENTS.md, PLAN.md
Воспроизводимость	Нет (промпт привязан к сессии)	Да (спеки + планы в файлах)
Контекст	Деградирует	Свежий на каждую задачу

---

Часть 3: Рефлексия и планирование (15 мин)

Обсуждение (10 мин)

Вопросы для группы:

• Что из демо было неожиданным? Что вас удивило?
• Какие из 4 стратегий контекста (Write/Select/Compress/Isolate) вы увидели в демо?
• Обязательно ли использовать GSD? Можно ли применить те же принципы вручную?
• Где граница между «слишком мало подготовки» (vibe-coding) и «слишком много подготовки» (paralysis by analysis)?

Важно

GSD — один из инструментов, не единственный. Принципы (спецификация → декомпозиция → изоляция контекста → верификация) работают с любым AI-ассистентом. Можно использовать SpecKit, Ralph, ai-dev-tasks, или просто Markdown-файлы.

Мини-ДЗ (5 мин — объяснение)

Задание: переделать свой сломанный проект из ДЗ2, применив минимум 3 техники из Л3.

Варианты подхода (на выбор):

1. GSD — установить и пройти полный цикл (new-project → plan-phase → execute-phase)
2. SpecKit — написать spec.md и constitution.md, запустить /speckit.implement
3. Ручной SDD — написать спецификацию в Markdown, разбить на слайсы, реализовать по одному
4. ai-dev-tasks — использовать шаблоны create-prd.md → generate-tasks.md → build

Формат отчёта:

## Было (наивный подход)
- Промпт: [ваш оригинальный промпт]
- Результат: [что получилось, где сломалось]

## Стало (системный подход)
- Инструмент/подход: [GSD / SpecKit / ручной SDD / ai-dev-tasks]
- Что сделали по-другому: [список техник]
- Результат: [что получилось]

## Почему
- Какие антипаттерны из Л3 вы устранили?
- Какие стратегии контекста использовали?
- Что было самым полезным?

---

Домашнее задание: AI в повседневных задачах

Подготовка к Семинару 4

Это задание нужно выполнить до следующего семинара. Результаты будем разбирать на С4.

Протестируйте AI-ассистент на трёх типичных задачах разработчика. Используйте свой рабочий или учебный код — не синтетические примеры.

Задача 1: Code Review

Скормите модели фрагмент своего кода (50-200 строк) и попросите провести code review.

• Что в ответе модели было полезным?
• Что было шумом или очевидностью?
• Нашла ли модель реальный баг или проблему, которую вы не замечали?

Задача 2: Рефакторинг или документация

Выберите одно:

• Рефакторинг: дайте модели messy-код и попросите улучшить (упростить, разбить на функции, убрать дублирование)
• Документация: попросите модель написать docstrings, README или inline-комментарии к вашему коду

Сравните результат «до» и «после»:

• Стал ли код/документация лучше?
• Что модель сделала хорошо, а что пришлось переписывать?

Задача 3: Дебаггинг

Дайте модели ошибку (traceback, неожиданное поведение, failing test) вместе с релевантным контекстом кода.

• Нашла ли модель причину?
• Насколько точным было предложенное исправление?
• Пришлось ли давать дополнительный контекст?

Формат отчёта

По каждой из трёх задач зафиксируйте:

	Что записать
Промпт	Дословно — что вы написали модели
Контекст	Какой код/ошибку приложили
Результат	Что модель ответила (скриншот или текст)
Оценка	Полезно / Частично полезно / Бесполезно
Доверие	Вы бы приняли этот результат без проверки? Да / С оговорками / Нет

Подсказка

Попробуйте разные инструменты для разных задач. Например: Claude Code для дебаггинга, Cursor для рефакторинга, ChatGPT для code review. На С4 будем сравнивать кто что использовал и с каким результатом.

---

Подготовка преподавателя

До семинара

• Установить GSD2: npx gsd-install или по инструкции gsd-build/gsd-2
• Проверить что демо работает на типичном pet-проекте (todo-app, CLI-утилита)
• Подготовить fallback-проект на случай если студенческие проекты слишком специфичны
• Проверить что Claude Code + GSD работают без проблем с интернетом аудитории

Fallback-проект для демо

Если ни один студенческий проект не подходит для live-демо, использовать:

• CLI weather app — простой, понятный, можно показать полный цикл за 15 мин
• Заранее подготовленный «сломанный промпт» для сравнения

Тайминг

Часть	Время	Содержание
1. Разбор провалов	25 мин	Показ 3-4 кейсов + сбор антипаттернов
2. Live-демо GSD	30 мин	new-project → discuss → plan → execute → результат
3. Рефлексия	15 мин	Обсуждение + объяснение мини-ДЗ
Итого	70 мин