Современные методы разработки программных продуктов с помощью методов искусственного интеллекта 2026

Общие сведения

• Семестр: 5/7
• Форма контроля: дифференцированный зачет
• Дни и время занятий: вторник, 17:05-18:30
• Первое занятие: 1 сентября 2026 года

Преподаватель

• Ахтямов Павел

О курсе

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

Курс отвечает именно на такой запрос. Мы не учимся просить у модели функции - мы строим вокруг агента инженерную обвязку: намерение, спецификацию, проверки, права, цену запуска, выкатку. Профессия, которая из этого складывается, называется agentic engineering, и на рынке она уже оплачивается отдельно от разработки.

Чем курс отличается от прошлого года

Курс 2025 года отвечал на вопрос «что умеют языковые модели». Курс 2026 отвечает на другой: почему решение, собранное за вечер, не доживает до production и не масштабируется, и что с этим делать.

Поэтому курс развивается в 3 направлениях.

Первое: проверяемость. Можно ли доверять тому, что сделано, не перечитывая код глазами. Сюда входит спецификация, по которой работу принимает машина, детерминированный набор проверок и независимый проверяющий, который ищет расхождения вместо автора. Работа считается сделанной, когда это подтвердил прогон, а не автор.

Второе: границы. Что произойдёт, когда что-то пойдёт не так. Права агента и матрица разрешений, цена запуска и лимиты, модель угроз, векторы атак на собственный продукт, откат и учения по отказу. Решение доживает до production не потому, что в нём нет ошибок, а потому, что известно, где оно остановится.

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

Формат

Каждая пара устроена одинаково: короткая витрина работ, разбор темы, практика на своём проекте. С третьей недели пара открывается тремя минутами показа - два-три студента выводят свой продукт на экран и запускают его. Не рассказывают, а запускают.

Сквозной пример курса - «Дежурный по дедлайнам»: сервис личных сроков, который преподаватель ведёт параллельно с группой. Студент видит целевое состояние каждого слоя, а тему своего проекта выбирает сам.

Кому подойдёт

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

Регистрация на курс

Регистрация на курс проходит по ссылке: [ссылка на форму]

Актуальные новости

Актуальные новости публикуются в Telegram-чате: [ссылка на чат]

План курса

1. Agentic engineering как профессия. Что изменилось за два года, где проходит граница между генерацией кода и инженерией агентов. Проверка фактов и работа с источниками. Замер на отдельной задаче.

2. Рабочая среда агента и инженерный минимум. Настройка среды, репозиторий, первый коммит, набор проверок. Продукт поднимается локально.

3. Intent engineering. Как превратить расплывчатое желание в намерение, по которому агент способен работать. Бриф и каркас продукта по нему.

4. Spec-Driven Development. Спецификация, разбиение на задачи, реализация под тесты. Работа принимается зелёным прогоном, а не мнением автора.

5. Skills Engineering и Model Context Protocol. Свой скилл под задачу проекта, подключение серверов MCP, вызов инструмента в журнале агента.

6. Архитектура, ADR и репозиторий, готовый для агента. Схема решения, записи о принятых решениях, правила репозитория, работа через ветки и pull request.

7. Детерминированная проверка. Набор проверок, запускаемый одной командой. Что проверяется машиной, а что остаётся человеку. Видимость решения для поисковых роботов и агентов: что достаётся тому, кто не выполняет JavaScript, и как это проверить машиной.

8. Независимый проверяющий. Проверяет не тот, кто делал: инструкция проверяющего, отчёт о расхождениях со спецификацией.

9. Harness: права, данные и цена. Модель угроз, матрица разрешений, лимиты и стоимость запуска. Проверка прав в конвейере сборки.

10. ИИ в автотестировании, часть первая. Приглашённый практик. Внутреннее устройство агента: цикл вокруг модели, набор инструментов, память, перехват фактических вызовов. Разработка собственного конвейера.

11. Свои агенты и свой сервер MCP, часть вторая. Приглашённый практик. Написание собственного сервера Model Context Protocol и собственных агентов под свою задачу. Не субагенты, а самостоятельные программы.

12. Безопасность агентной разработки, часть первая. Приглашённый практик. Как ломаются агентные решения: векторы атак, найденные на своём проекте.

13. Безопасность агентной разработки, часть вторая. Приглашённый практик. Защита: проверка безопасности в конвейере, падающая на подложенной проблеме.

14. Loop Engineering. Цикл, который работает без человека: выбирает задачу, вносит изменение, открывает pull request. Где ставить границы такому циклу.

15. Выкатка и эксплуатация. Развёрнутая версия, откат, учения по отказу. Продукт становится доступен в сети. Состязательная приёмка.

Защита проектов проходит в зачётную сессию.

Формат сдачи курса

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

Минимальные требования

Необходимо реализовать проект, включающий:

• Frontend, Backend и хранилище данных
• Набор проверок, запускаемый одной командой
• Развёрнутую версию, доступную по сети
• Спецификацию, по которой проект можно проверить независимо

Проект сдаётся ссылкой на репозиторий и отчётом на почту akhtyamov@phystech.edu. Отчёт содержит:

• спецификацию и разбиение на задачи;
• что пришлось доработать руками и почему;
• какие серверы MCP и скиллы использовались;
• какие модели применялись и на каких задачах;
• отчёт независимого проверяющего с найденными расхождениями.

Проверка на защите

Проект разворачивает и запускает другой человек по инструкции из репозитория. Если запуск требует вопросов автору, комплект передачи неполный.

Бонусы

• Работающий цикл без участия человека с заданными границами
• Своя проверка безопасности, падающая на подложенной проблеме
• Настройка агентов через инструменты с низким порогом входа (n8n, SourceCraft)
• Собственные серверы MCP под задачи проекта

Вехи по ходу семестра

Проект сдаётся не одним куском в декабре. Пять раз за семестр он проходит короткую проверку, и каждая привязана к теме, которая только что разбиралась.

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

Веха	Неделя	Что показываем	Чем проверяется
В1. Продукт поднимается	2	репозиторий, первый коммит, набор проверок	сервис запускается на машине преподавателя
В2. Намерение и спецификация	4	бриф, спецификация, разбиение на задачи, одна задача сделана	прогон проверок зелёный
В3. Репозиторий готов для агента	6	схема решения, записи о решениях, правила репозитория, работа через ветки	pull request с зелёной сборкой
В4. Проверяемость	8	полный набор проверок, отчёт независимого проверяющего	отчёт содержит найденные расхождения со спецификацией
В5. Границы и цена	9	модель угроз, матрица прав, лимиты	конвейер падает на попытке опасного действия

Логика вех простая. Первые две отвечают на вопрос «есть ли вообще продукт», третья и четвёртая - «можно ли ему доверять», пятая - «что будет, когда что-то пойдёт не так».

Примеры проектов

Можно выбрать один из предложенных проектов или предложить свой по согласованию с преподавателем. Для согласования нестандартной темы необходимо написать на почту akhtyamov@phystech.edu с описанием и мотивацией выбора.

Описание проекта даётся в минимальном виде намеренно: задача студента - развить его самому, ограничивая при этом фантазию модели.

Уровни различаются не размером, а числом тем курса, которые задача поднимает. Простая задача проверяет, что человек довёл дело до конца. Задача на десять требует доказать правильность решения машиной, а не показать её на примере.

Простые проекты (удовлетворительно 3-4)

Задачи этого уровня не содержат сложных правил. Проверяется одно: продукт работает, разворачивается и запускается человеком со стороны.

1. Трекер личных дедлайнов:

• срок с датой и напоминанием
• список того, что горит сегодня
• отметка выполненного
• фильтр по проектам

2. Kanban-доска (упрощённый Trello):

• создание задач и досок
• назначение задач пользователям
• статусы задач
• ограничение числа задач в одном статусе

3. Дашборд успеваемости:

• студенты, предметы, оценки
• средний балл по предмету
• график успеваемости
• топ студентов

Задачи невысокой сложности (хорошо 5)

Здесь появляется первое правило, которое легко описать неточно. Спецификация перестаёт быть формальностью.

1. Обменник дежурствами. Участники меняются сменами по правилам: не больше двух смен подряд, нельзя ставить смену в свой выходной, замена требует согласия обеих сторон.

• заявка на замену и ответ на неё
• проверка правил при подтверждении
• история изменений графика
• темы курса: спецификация, детерминированная проверка

2. Мини-маркетплейс объявлений. Классическая витрина, усложнённая модерацией: объявление публикуется не сразу, а после проверки по списку правил.

• объявления с фотографиями, категории, поиск
• очередь модерации с причинами отказа
• повторная подача после исправления
• темы курса: спецификация, независимый проверяющий

Задачи с усложнениями (оценки 7-8)

На этом уровне у задачи есть проверяемый инвариант и опасное действие. Модель угроз и матрица прав перестают быть бумажными.

1. Учёт общих расходов с делением счёта. Кто за кого заплатил, кто кому должен, взаимозачёт долгов внутри группы.

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

2. Планировщик встреч по календарям участников. Сервис находит общее окно, учитывая занятость, часовые пояса и приоритет участников.

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

3. Помощник по базе знаний с бюджетом. Отвечает на вопросы по загруженным документам и тратит на это деньги, поэтому знает свои лимиты.

• загрузка документов и поиск по ним
• лимит трат в день и на один запрос
• понятный отказ при исчерпании лимита вместо превышения
• темы курса: harness, цена запуска, деградация

4. Очередь задач с приоритетами. Задачи разбираются исполнителями по правилам, и правила меняются на ходу.

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

Задание на оценку 10

Задачи этого уровня отличаются одним: правильность решения неочевидна, и её нужно доказать машиной, а не показать на примере.

1. Зачёт взаимных долгов. Развитие задачи про общие расходы: сервис не просто считает долги, а сводит их к минимальному числу переводов.

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

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

• распределение задач по исполнителям с учётом загрузки
• доказать: при непрерывном потоке ни одна задача не ждёт дольше границы
• темы курса: цикл без человека, проверка инварианта под нагрузкой

3. Платформа A/B-тестирования. Эксперименты над собственным продуктом с честной статистикой.

• создание эксперимента и разделение пользователей
• библиотека для получения варианта
• сбор метрик и проверка статистической значимости
• доказать: разделение устойчиво, пользователь не меняет вариант между заходами
• темы курса: проверяемость, работа с данными

4. Доска для ретроспектив в реальном времени. Несколько человек работают одновременно, и результат не зависит от порядка действий.

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