Что я понял, когда делал со студентами приложение с помощью AI

Сегодня проводил для студентов мастер-класс по разработке с помощью AI. Показывал, как работать с OpenCode на примере трекера задач. На всё ушло две лекции — около 2,5 часов.

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

Начали с обычного списка задач. Обсудили интерфейс: как показывать карточки, как сортировать, что делать с выполненными. Для старта взяли максимально простой стек — HTML, CSS и JS с хранением прямо в браузере.

Когда базовый вариант завелся, начался разгон. Сначала добавили группировку по приоритетам и загрузку картинок. Потом переделали плоский список в канбан с колонками «К выполнению», «В работе» и «Готово». Следом прикрутили несколько досок и выбор эмодзи для каждой.

Дальше захотелось сделать трекер многопользовательским. Локальной странички с localStorage и IndexedDB стало мало — переехали на клиент-сервер. Подняли бэкенд на Python/FastAPI и упаковали в Docker.

Я сразу не уточнил, какая БД нужна, и OpenCode сходу решил поднять PostgreSQL. Для маленького проекта это явный перебор, поэтому переиграли на SQLite. В итоге меньше чем за три часа от первой строчки мы дошли до рабочего серверного приложения на своём VDS.

После пар мне стало интересно покрутить не сам результат, а процесс. Я поднял историю сессии OpenCode и коммиты, и мы разобрали их вместе с Codex. Сразу вылезло несколько показательных моментов.

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

Я не указал на старте, что проект учебный, и не задал границы действий. Ранее по ходу лекции мы просто обсуждали, сможет ли OpenCode задеплоить проект. Поэтому на мою просьбу «запустить приложение» агент без лишних вопросов пошел раскатывать его на реальный сервер. Я привык к Codex, который перед таким шагом сначала спросит, но разные инструменты ведут себя по-разному.

Хватало и мелких граблей по ходу работы:

• после добавления задач на экране упорно висела заглушка «Пока здесь пусто»
• агент несколько раз подряд не смог применить патч к спецификации. Разобрали причину и тут же записали правило в AGENTS.md: перед правкой читать актуальный кусок файла, а при ошибке не пытаться накатить тот же патч вслепую
• агент отчитался, что поменял код, но в браузере ничего не изменилось. Оказалось, Docker-контейнер продолжал отдавать старую сборку. Наглядная иллюстрация того, что «код изменён» и «пользователь видит новую версию» — вообще не одно и то же.

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

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

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

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