AI >>
NATIVE DEVELOPER

Что делаем

Начинаем с проблем и вопросов студентов из вводной анкеты: подсвечиваем их и показываем, как курс каждую из них закрывает. Разбираем, как меняется роль инженера: код как ценность уступает место спекам, требованиям и управлению агентами; вводим мультиагентность как рабочий инструмент. Сразу проверяем на практике: каждый участник через ИИ-агента и спецификацию (SDD) собирает и разворачивает работающий лендинг на реальном сервере с аналитикой посещений. Спек-дривн-девелопмент показываем уже здесь — как рекомендованный ход работы — и готовим основу для следующего урока. Практику формулируем с точки зрения образовательной ценности и управления ИИ, а не конкретного стека реализации.

Что делаем

Берём лендинг с первого урока и решаем бизнесовую задачу: повысить конверсию через данные о реальном поведении пользователей. Подключаем Chrome MCP, параллельно парсим Web Visor; агент сам анализирует паттерны скроллов и кликов и передаёт нам готовые выводы, по которым вносим изменения для повышения конверсии на 5–15%. Разбираем, почему агент без жёсткого контроля смешивает реальные данные с домыслами, и как его остановить. Отдельно проговариваем стратегию тестирования: при локальном прогоне результаты у всех разные (разные ядра и железо), единообразия можно добиться только в облаке с изоляцией ресурсов — но это отдельная инфраструктура, оплата и поддержка. Цикл от данных до деплоя за одно занятие.

Что делаем

Коротко напоминаем механизм работы LLM (контекст, токены, веса) — аудитория уже в этом разбирается — и переходим к сути. Студенты пишут key-value БД «в лоб» без дополнительных инструкций; на код-ревью обнаруживаем одинаковые проблемы у всех: устаревший JS вместо TypeScript, небезопасный Dockerfile, нет персистентности, логов, обработки ошибок. Разбираем, почему это системно и как это исправить: доверие к ИИ (что можно и нельзя ему доверить), декомпозиция задач, структура правильного промта и методология SDD — спецификация как источник истины, план как маршрут, TDD как защита от мухлежа агента, релиз-гейт на выходе. Evals и тесты пишем для собственных агентов и промптов; метрики качества именно для RAG — отдельная тема в уроке про RAG.

Что делаем

Коротко проговариваем, из чего состоит контекстное окно (аудитория уже разбирается), и фокусируемся на управлении: что его засоряет (документация, промежуточные вычисления, устаревшие ссылки), когда сбрасывать сессию и почему работать по фичам лучше, чем по слоям. Разбираем память агента как класс задач и класс решений: сравниваем простой подход на MD-файлах с готовыми системами памяти (Obsidian и похожие), проговариваем OKF (стандарт конфигурации агента) и субагентов, суммаризацию упоминаем вскользь. Строим иерархию памяти: md-файлы → MCP+PostgreSQL → Redis. Устанавливаем Spec Kit и проходим полный цикл от установки и внедрения до автоматической реализации задач со сбросом контекста между итерациями.

Что делаем

Разбираемся в харнесах — способах улучшения работы агентов внешними средствами. Даём обзор популярных готовых харнесов (Cursor, OpenCode, Hermes и другие): это обвязка над API модели, которая организует агента, — её можно взять и донастроить под себя. Показываем, что выбор конкретного инструмента для демонстрации не проблема: популярные харнесы конкурируют фичами и быстро сходятся по ключевым функциям, а утилиты (OpenSpec, Obsidian и др.) умеют интегрироваться со всеми; разница — в том, как хранятся скиллы и правила. Отдельно разбираем не «как написать MCP» (это легко), а фреймворк решения: когда делать MCP, когда собственный тул для агента, когда правило, а когда достаточно просто выполнить скрипт.

Что делаем

Разбираем агента как операционную систему: LLM = CPU, контекст = RAM, субагенты = процессы, MCP = сетевые вызовы. Пишем собственный MCP-сервер на Python (fastMCP) и подключаем к IDE, проверяем, как docstring инструмента влияет на его вызов. Создаём первого субагента на markdown и выясняем, почему размытое описание может сломать всю систему. Проходим все паттерны мультиагентных систем: Router, Supervisor, Graph, Evaluator-Optimizer, Human-in-the-Loop — с эволюцией от group chat до Chat DEF. Разбираем мультиэкспертность: как скиллы превращают агента в системного аналитика, QA, дизайнера или DevOps (SDLC через скиллы, OpenSpec, API-first) и как обеспечивать безопасность агентов; при этом запуск нескольких агентов почти всегда означает разные роли, а не копии одного эксперта. Финал: собираем мультиагентную систему для полного SDD-цикла на живом кейсе — например, MVP агрегатора гостиниц, где второй агент параллельно анализирует топ-10 сайтов на возможность автоинтеграции.

Что делаем

Различаем типы RAG по подходу: поиск по точным совпадениям и поиск по базе знаний — это принципиально разные раги, с разными примерами применения. Знакомимся с моделями, которые отдельно улучшают качество RAG (эмбеддинги, re-ranker, query rewrite); репозитории готовых моделей — HuggingFace и Yandex Cloud — упоминаем кратко, без разбора выбора по вендорам (рынок меняется быстрее). Строим RAG с нуля: чанкинг через Chonkie → embeddings → ChromaDB → поиск → ответ LLM, затем усиливаем query rewrite перед поиском и re-ranker после. Оцениваем качество через RAGAS — это метрики именно для RAG, отдельно от общей темы Evals.

Что делаем

Проходим базовые паттерны построения агентов: воркфлоу, маршрутизацию, параллелизацию, оркестрацию и цикл с самопроверкой через судью. Разбираем контракт Responses API и его отличие от устаревшего Completions. Пишем первого агента, который возвращает структурированный вывод по заданной схеме. Добавляем вызов функций: объявляем тул, читаем function_call в ответе модели и вызываем нужную функцию. Строим трёхагентную систему через A2A и реализуем её же через фреймворк на выбор (LangGraph, CrewAI, Google ADK, AutoGen, Haystack) — фреймворк как инструмент создания агентов. В финале объединяем инструменты — RAG, MCP и скиллы — в одном агенте через общий параметр tools и получаем работающего агента, который умеет искать по знаниям, обращаться к внешним сервисам и использовать локальные окружения.

Что делаем

Собираем набор инструментов, усиливающих качество агентной разработки. Разбираем тулсет, который стоит заюзать: CodeGraph и семантический поиск по коду, context7, Chrome DevTools, готовые MCP, готовые раги, скиллы. Не «какие бывают агенты», а какие примочки к коду и окружению делают агента точнее и полезнее — и как собрать из них личный набор под свои задачи.

Что делаем

Разворачиваем настоящий большой legacy-проект через Docker и работаем с ним как с боевой задачей, разбирая проблемные и беспроблемные кейсы использования LLM. Беспроблемные кейсы: картографирование архитектуры незнакомого репо, объяснение 6500-строчного монолита на чужом языке, трассировка flow от клика до БД. Проблемные: аудит безопасности; один и тот же промт даёт разный результат при двух запусках; AI документирует несуществующий класс как реальный. Для каждого кейса — конкретный алгоритм получения нужного результата.

Что делаем

Учимся работать со сложными задачами через системную декомпозицию и осваиваем внедрение новых элементов в существующую архитектуру — или построение архитектуры с нуля. Проектирование продуктовой системы через 5 этапов: UI прототипы, структура БД, API контракты, архитектура, бизнес-логика. Практически добавляем в проект базу данных, API-контракты, архитектурные компоненты и бизнес-логику с демонстрацией полного пайплайна.

Что делаем

Осваиваем методики работы с большими незнакомыми проектами и legacy-кодом: как эффективно изучать структуру, выстраивать связи между модулями и понимать логику работы, опираясь на инструменты анализа. Разбираем иерархию инструментов: от grep и полнотекстового индекса до семантического RAG, tree-sitter, LSP и графовых баз знаний. На реальном open-source-репозитории строим граф зависимостей кодовой базы в Docker через агента, пишем аналитические запросы и находим архитектурные проблемы, не читая код вручную; получаем пошаговый план изменений через режим Code Map. Переходим от чтения кода к запросам к коду как к данным — это база для автоматизированного рефакторинга и архитектурной трансформации.

Что делаем

Разбираем инфраструктуру для агентов с точки зрения разработчика: агентские платформы, где агенты запускаются и контролируются, и как устроена observability, когда одновременно работают десятки и сотни агентов (сколько тулов вызывает сессия, алерты, логи, трейсы). Детекция аномалий: как понять, что агент «улетел» и начал выдавать ерунду. Управление доступом агентов через IAM-контроль и говернанс: формулируем общие принципы поведения, которые оценивает система LLM-as-a-Judge. Смотрим на готовые платформы облачных провайдеров (Google, Amazon, Microsoft) и open-source. Урок сфокусирован на агенте с точки зрения разработчика — без разбора сервинга и инференса моделей.

Что делаем

Учимся разделять монолитную архитектуру на микросервисы с помощью AI: аудит зависимостей в коде и БД, выделение bounded contexts через Domain-Driven Design, создание API-границ (API Gateway, anti-corruption layer, контракты), паттерны консистентности (Outbox, Saga) и безопасный поэтапный переезд через dual writes и Strangler Fig. Работаем в spec-driven режиме на OpenSpec: готовим proposal, гоняем его через параллельных агентов-ревьюеров (БД, перформанс, безопасность, gateway) и доводим до спецификации с API-контрактом, моделью данных, runbook миграции и тест-планом. Подготовку кода делаем детерминистическими утилитами статического анализа, которые не тратят токены: ast-grep (YAML-правила scan/fix, коммитятся как миграции БД), OpenRewrite для переезда между фреймворками и CodeQL для запросов на потоки данных (source → sink) — поиск утечек секретов и JWT-токенов. Относимся к кодовой базе как к данным, а не к произведению искусства.

Что делаем

Разбираем, как AI изменил рынок труда в IT, — с реальными данными hh.ru и мировых площадок на руках. Смотрим на 12-летние циклы спроса и предложения: дефицит кадров, пузырь 2021 года, обвал 2022-го и текущий рынок работодателя. Обсуждаем, где избыток, а где дефицит по направлениям, и разбираем сдвиг грейдов: сеньор сегодня — это мидл пятилетней давности. Формулируем стратегию, как оставаться востребованным: расширение профессии до разработчика-дженералиста, углубление фундаментальных знаний, ответственность за результат и умение управлять инструментами. Проговариваем практику найма: ATS-системы, каналы поиска, собеседования с AI, мультизанятость и корпоративную безопасность — как правильно себя позиционировать, что подчеркнуть и на какие суммы можно претендовать.

Что делаем

Переходим от личного использования AI к масштабированию практик на всю команду или компанию. Осваиваем роль лидера AI-трансформации: как внедрять новые стандарты работы, преодолевать сопротивление коллег, обосновывать эффективность внедрения AI перед руководством через метрики и ROI. Оцифровка SDLC, план внедрения на базе агента-аналитика, создание корпоративной академии.

Что делаем

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