Сегодня не будет

• обзора фич IDE и плагинов
• списка «топ-10 промптов»
• хайпа про «AI заменит разработчиков»
• демки ради демки

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

Реальный опыт, не реклама

• Работаю с AI-инструментами в продакшен-задачах каждый день
• Прошёл фазу «волшебной таблетки» и фазу разочарования
• Видел, где AI экономит часы, и где — съедает дни
• Курс — не про инструменты, а про процесс

Что курс не делает

Куда мы идём за 5 недель

1. 01 · 7 маяСтарт проекта и базовые режимы (сегодня)
2. 1.5Бонус: обзор IDE — 12 мая
3. 02Внешние интеграции через MCP
4. 03Переиспользуемые инструкции: Skills, Rules, Memory
5. 04Spec-driven разработка (SDD)
6. 05Безопасный AI-процесс

Что останется после курса

project/
├── src/
├── .ai/
│   ├── skills/        # переиспользуемые навыки
│   ├── workflows/     # пайплайны работы
│   ├── rules/         # правила и ограничения
│   └── context.md     # ключевой контекст
├── specs/             # спецификации фич
├── docs/
│   └── ai-development.md
└── README.md

Не воспоминание о курсе, а инструмент, с которым можно работать дальше.

Карта лекции

• 01 · Почему AI часто не ускоряет
• 02 · Рамка курса и финальный артефакт
• 03 · Сквозной проект и нарезка задачи
• 04 · Ask / Plan / Agent — ядро процесса
• 05 · Tab и inline-генерация
• 06 · Типичные провалы первого дня
• 07 · Минимум безопасности
• 08 · Домашнее задание
• 09 · Q&A

Карта лекции

• 01 · Почему AI часто не ускоряет
• 02 · Рамка курса и финальный артефакт
• 03 · Сквозной проект и нарезка задачи
• 04 · Ask / Plan / Agent — ядро процесса
• 05 · Tab и inline-генерация
• 06 · Типичные провалы первого дня
• 07 · Минимум безопасности
• 08 · Домашнее задание
• 09 · Q&A

Обещание маркетинга

Цифры из вендорской рекламы. Звучит вдохновляюще.

Реальность первого месяца

METR: кто и как

• Опытные open-source разработчики
• Реальные задачи в их собственных репозиториях
• Сравнение: с AI-инструментами и без
• Замеряли: фактическое время + субъективное ощущение

Одно из самых отрезвляющих исследований в индустрии.

Почему такой разрыв

• Удобство ≠ скорость. Меньше моторного труда воспринимается как ускорение.
• Скрытое время. Перепроверка, отладка, переписывание — не считаются.
• Контекст-свитчинг. Чтение чужого diff дороже, чем кажется.
• Выигрышные моменты ярче. Помним удачные сессии, забываем провалы.

Где AI реально помогает

Где AI вреден

• Vibe-coding: «давай попробуем» без плана и критериев
• Принятие кода без понимания, что он делает
• 2.74× больше уязвимостей в AI-сгенерированном коде
• Сложная бизнес-логика с нюансами домена
• Архитектурные решения без явных границ

С чем приходите вы

Карта лекции

• 01 · Почему AI часто не ускоряет
• 02 · Рамка курса и финальный артефакт
• 03 · Сквозной проект и нарезка задачи
• 04 · Ask / Plan / Agent — ядро процесса
• 05 · Tab и inline-генерация
• 06 · Типичные провалы первого дня
• 07 · Минимум безопасности
• 08 · Домашнее задание
• 09 · Q&A

Линейка зрелости процесса

1. →разовая сессия с моделью
2. →рабочий проект (сегодня)
3. →интеграции с внешним миром
4. →переиспользуемые инструкции
5. →spec-driven пайплайн
6. →безопасный командный процесс

Инструменты и среда

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

Без этого слоя следующие — бесполезны.

Интеграции через MCP

AI начинает работать с внешним миром: базы, API, файловые системы, инструменты разработчика. Не «модель отвечает», а «модель действует».

Переиспользуемые инструкции

• Skills — навыки, которые модель применяет повторно
• Rules — границы, которые нельзя нарушать
• Memory — контекст, переживающий сессию

Spec-driven разработка

Задача → спецификация → код. Не «попроси и надейся», а воспроизводимый пайплайн от описания фичи до её реализации с проверкой.

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

Использовать AI без наивности: утечки данных, чужой код в репозитории, ревью AI-изменений, границы доверия в команде.

Дерево проекта в конце курса

project/
├── src/                   # код проекта
├── .ai/
│   ├── skills/            # навыки (созвон 03)
│   ├── workflows/         # пайплайны (созвон 02)
│   ├── rules/             # правила (созвон 03)
│   ├── context.md         # ключевой контекст (сегодня)
│   ├── tasks/             # формулировки задач (сегодня)
│   ├── notes/             # заметки сессий (сегодня)
│   └── checklists/        # чек-листы (сегодня)
├── specs/                 # спецификации (созвон 04)
├── docs/
│   └── ai-development.md  # как мы работаем
└── README.md

Карта лекции

• 01 · Почему AI часто не ускоряет
• 02 · Рамка курса и финальный артефакт
• 03 · Сквозной проект и нарезка задачи
• 04 · Ask / Plan / Agent — ядро процесса
• 05 · Tab и inline-генерация
• 06 · Типичные провалы первого дня
• 07 · Минимум безопасности
• 08 · Домашнее задание
• 09 · Q&A

Почему один сквозной проект

• Без общего объекта нет общей практики
• На разных задачах нельзя сравнивать подходы
• Один проект растёт вместе с курсом
• К нему естественно достраиваются MCP, Skills, SDD, безопасность

mini-SaaS для задач и заметок

Архитектура

┌──────────────┐     HTTP/JSON     ┌──────────────┐
│   UI слой    │ ◄───────────────► │  Backend API │
│  (React/...)  │                   │  (REST/Go)   │
└──────────────┘                   └──────┬───────┘
                                          │
                                   ┌──────▼───────┐
                                   │   SQLite     │
                                   └──────────────┘

Минимум магии. Запускается локально за 30 секунд.

Что делаем сегодня

Не «сделай весь сервис», а вертикальный срез.

Правильно резать задачу — навык №1

• Срез проходит сквозь все слои: UI → API → БД
• Видны и польза, и ограничения AI-подхода
• Можно реалистично проверить результат
• Размер влезает в одну сессию работы

Антипример: «сделай весь сервис»

Правильный формат задачи

ЧТО:        добавить endpoint POST /tasks
ГДЕ:        внутри src/api/handlers/tasks.go
ОГРАНИЧЕНИЯ: использовать существующий TaskRepository
            не трогать routes/, не менять схему БД
ГОТОВО когда: тест POST /tasks возвращает 201
            и созданная задача видна в GET /tasks

Что · Где · Ограничения · Критерий готовности.

Готов ли я начать

• Среда — IDE открыта, AI-инструмент включён
• Проект — клонирован и запускается локально
• Контекст — модель видит нужные файлы
• Задача — сформулирована в формате что/где/ограничения/критерий
• Границы — понятно, чего нельзя трогать

Что сейчас делаем у себя

1. Клонируем учебный репозиторий
2. Запускаем backend локально (`make run` или `docker compose up`)
3. Проверяем, что AI-инструмент видит проект
4. Создаём папку `.ai/` в корне
5. Пишем первый файл `.ai/context.md` — 10 строк про проект

Структура папки .ai/

.ai/
├── context.md       # ключевой контекст проекта
├── tasks/           # формулировки задач
├── notes/           # заметки сессий
└── checklists/      # чек-листы для повторяемых действий

Карта лекции

• 01 · Почему AI часто не ускоряет
• 02 · Рамка курса и финальный артефакт
• 03 · Сквозной проект и нарезка задачи
• 04 · Ask / Plan / Agent — ядро процесса
• 05 · Tab и inline-генерация
• 06 · Типичные провалы первого дня
• 07 · Минимум безопасности
• 08 · Домашнее задание
• 09 · Q&A

Три режима — три разных контракта

Три роли в стройке

Бригаду без архитектора и прораба — не зовут.

ask — режим мышления, не вопросов

ASK — это не «спросить у бота», а способ думать в паре с моделью. Кода нет, цена ошибки минимальна.

Когда ASK уместен

• Декомпозиция большой задачи на куски
• Поиск слепых зон в собственном понимании
• Уточняющие вопросы до того, как писать код
• Сравнение нескольких подходов
• Проверка плана до генерации

Где ASK ломается

• Человек ждёт сразу код, а не размышление
• Слишком широкий вопрос: «как мне сделать SaaS»
• Результат остаётся в чате, а не в репо
• Не просим у модели уточняющих вопросов

Правильный вход в задачу

Сделай мне endpoint
для создания задачи

Я хочу добавить POST /tasks.
Прежде чем писать код:
1. задай 3 уточняющих вопроса
2. предложи декомпозицию
3. укажи риски
Контекст: src/api/handlers/

plan — проект до выполнения

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

Когда PLAN уместен

• Многосоставная задача с несколькими файлами
• Когда нужно увидеть весь diff до того, как он применится
• Когда хочется проверить, что модель правильно поняла задачу
• Перед запуском Agent на серьёзную работу
• Когда цена ошибки выше, чем стоимость лишней итерации планирования

Где PLAN ломается

• План не читают — сразу нажимают «выполнить»
• Нет границ: модель планирует на 20 файлов вперёд
• План формальный: «изменим x, изменим y» без сути
• План пишут, но критерии готовности не проверяют

Правильный вход в PLAN

Цель: добавить POST /tasks.
Составь план изменений:
- список файлов, которые тронем
- список файлов, которые НЕ тронем
- порядок шагов
- критерий готовности (тест/команда)
Не выполняй пока. Я сначала посмотрю.

PLAN — это контракт на радиус и порядок работ.

agent — оркестрация действий

AGENT — это не «улучшенный PLAN». Это режим, в котором модель читает проект, выполняет серию шагов, запускает команды, проверяет результат. Максимум силы и максимум риска.

Когда AGENT уместен

• Задача уже хорошо очерчена (ASK + PLAN пройдены)
• Есть понятный контекст проекта
• Есть критерии success/fail (тест, команда, проверка)
• Допустима серия действий, а не одна правка
• Готовы откатить целиком, если пошло не туда

Где AGENT ломается

• Размытая задача: «сделай как лучше»
• Слишком широкий доступ к проекту
• Нет checkpoints — узнаёшь о проблеме на 15-м шаге
• Человек не понимает, что агент уже успел сделать
• Тесты не настроены — критерия готовности нет

Правильный вход в AGENT

Реализуй план из .ai/tasks/post-tasks.md.
Ограничения:
- работай только в src/api/handlers/
- не меняй схему БД
- после каждого файла — пауза для проверки
Готово когда:
- go test ./... зелёный
- POST /tasks возвращает 201

Явные ограничения, явные критерии, явные checkpoints.

Сравнение трёх режимов

Один кейс — три прохода

Возьмём ОДНУ задачу — добавить эндпоинт `POST /tasks` — и пройдём её три раза:

1. ASK — понять задачу, задать вопросы, получить декомпозицию
2. PLAN — увидеть точный план изменений до выполнения
3. AGENT — выполнить план под контролем

На что обращаем внимание

• Что модель поняла из контекста
• Какие задаёт уточняющие вопросы
• Что она не видит (и не скажет, что не видит)
• Какие альтернативы предлагает
• Где её декомпозиция расходится с нашим пониманием

На что обращаем внимание

• Какие файлы план собирается тронуть
• Какие файлы НЕ должны попасть в радиус
• Есть ли явные критерии готовности
• Можно ли план переписать руками — это и есть фиксация контракта
• Что план не учёл (всегда что-то есть)

На что обращаем внимание

• Где остановить, чтобы проверить промежуточный результат
• Что агент сделал «по пути», без явного запроса
• Запустил ли тесты сам или это надо потребовать
• Как выглядит итоговый diff целиком
• Что могло бы пойти не так без нашего контроля

Что увидели

• Одна задача в трёх режимах — три разных результата
• ASK ловит непонимание дёшево
• PLAN превращает мысль в контракт
• AGENT работает только когда первые два пройдены
• Перепрыгивать прямо в AGENT — самый дорогой способ

Как выбирать режим

задача ясна?
├── нет ──────────────────────► ASK
└── да
    │
    нужно увидеть весь радиус?
    ├── да ─────────────────► PLAN → AGENT
    └── нет (1–2 файла)
        │
        задача многосоставна?
        ├── да ─────────────► PLAN → AGENT
        └── нет ────────────► AGENT (с осторожностью)

Карта лекции

• 01 · Почему AI часто не ускоряет
• 02 · Рамка курса и финальный артефакт
• 03 · Сквозной проект и нарезка задачи
• 04 · Ask / Plan / Agent — ядро процесса
• 05 · Tab и inline-генерация
• 06 · Типичные провалы первого дня
• 07 · Минимум безопасности
• 08 · Домашнее задание
• 09 · Q&A

Что это и где живёт

• Tab-autocomplete — подсказка прямо в коде, принимается одной клавишей
• Inline generation — короткая команда «допиши тут», результат вставляется в файл
• Не имеет своего «окна разговора» — живёт внутри редактора
• Контекст ограничен соседними строками и файлом

Где tab реально помогает

Где tab опасен

• Незнакомый код — глаз не увидит подвох
• Безопасность — модель додумает «правдоподобную» проверку
• Бизнес-логика с нюансами — упростит до неправильного
• Большой diff «по табу» — несколько правок подряд без чтения
• Чужая кодовая база — берётся стиль из обучения, не из проекта

Карта лекции

• 01 · Почему AI часто не ускоряет
• 02 · Рамка курса и финальный артефакт
• 03 · Сквозной проект и нарезка задачи
• 04 · Ask / Plan / Agent — ядро процесса
• 05 · Tab и inline-генерация
• 06 · Типичные провалы первого дня
• 07 · Минимум безопасности
• 08 · Домашнее задание
• 09 · Q&A

провал 1. бесконечный контекст

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

Как это выглядит изнутри

• «На всякий случай» добавляю ещё один файл
• Потом ещё один. И ещё.
• Модель отвечает всё более общими словами
• Конкретика теряется в шуме
• Лечение: явный список «что в контексте» + причины

провал 2. «починил одно — сломал другое»

Радиус правок не задан. Модель оптимизирует то, что видит, а не то, что просили. Каскад правок не виден в одном diff целиком.

Как избежать

• Явно перечислить файлы и функции, которые можно трогать
• Запретить «улучшения по пути» в инструкции
• Запускать тесты после каждого этапа
• Если diff больше ожидаемого — откатывать целиком

провал 3. агент ушёл не туда

Модель делает не откровенную ерунду, а что-то «в целом логичное» — но не вашу задачу. Самый коварный провал, потому что результат выглядит правдоподобно.

Как избежать

• PLAN до старта: фиксируем понимание задачи письменно
• Промежуточный review плана перед AGENT
• Checkpoint до каждого этапа: «продолжить или остановиться»
• Критерии готовности заданы как тест, а не как «выглядит хорошо»

провал 4. иллюзия качества

Принят код, который человек не понимает. «Тесты зелёные, наверное, ок». Это не ускорение, а отложенный инцидент.

Почему это особенно опасно

• Команда: код становится «ничьим»
• Безопасность: незаметные дыры в проверках
• Сопровождение: править будет тот, кто и не писал
• Долг: чем дальше — тем дороже разобраться
• Правило: если не понимаешь diff — не мержи

У каждой проблемы — следующий слой

До отдельной лекции — базовая гигиена

Полноценный блок безопасности — на пятой лекции. Но отпускать в практику без минимальных правил нельзя. Есть три вещи, которые просто нельзя делать уже сегодня.

Три красные линии

Кейс Samsung — три утечки за 20 дней

• Инженер вставил исходный код в ChatGPT, чтобы дебажить
• Другой — конфиденциальные тесты железа
• Третий — стенограмму внутреннего совещания
• Через 20 дней — корпоративный запрет на публичные LLM
• Главный урок: «никто не собирался утекать», но утекло

Карта лекции

• 01 · Почему AI часто не ускоряет
• 02 · Рамка курса и финальный артефакт
• 03 · Сквозной проект и нарезка задачи
• 04 · Ask / Plan / Agent — ядро процесса
• 05 · Tab и inline-генерация
• 06 · Типичные провалы первого дня
• 07 · Минимум безопасности
• 08 · Домашнее задание
• 09 · Q&A

ДЗ 1: один цикл осознанно

1. Сформулируйте задачу в формате что/где/ограничения/критерий
2. Получите план через ASK — с уточняющими вопросами
3. Уточните и зафиксируйте план
4. Сделайте PLAN-проход — точный список изменений
5. Реализуйте через AGENT (или вручную)
6. Проверьте результат по критериям
7. Опишите, что сработало, а что нет

Что нужно сдать

• Краткое описание задачи (что/где/ограничения/критерий)
• Исходный запрос или структура взаимодействия с моделью
• План до кодинга (из ASK / PLAN)
• Итоговый результат (diff или ссылка на коммит)
• Как проверялось качество
• Что сломалось или удивило

Критерии оценки

• Был ли план до генерации кода?
• Была ли декомпозиция?
• Был ли правильно выбран режим (ASK / PLAN / AGENT)?
• Были ли явные ограничения и контекст?
• Понимаете ли вы, что именно получилось?
• Была ли проверка результата по критериям?

Оцениваем процесс, а не красоту демки.

Дедлайн и куда сдавать

Как пройдёт Q&A

Вопрос 1.
Как не терять контекст
на большом проекте?

Из частых болей опроса.

Вопрос 2.
Как сделать процесс
повторяемым, а не случайным?

Вопрос 3.
Когда можно использовать
внешний AI в компании?