Переносим принципы на любой продукт

За курс вы собрали два живых проекта. Бота, которые принимает голосовые, расшифровывает их через Deepgram и отвечает текстом. Он живет в Docker-контейнере на VPS и обновляется сам при пуше в main. И сайт с формой обратной связи крутится, который отправляет письма и переживает перезагрузки. По дороге вы писали спецификации, разбивали код на маленькие файлы, закрывали важную логику тестами. А где было полезно, подключали MCP.

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

У этих проектов будут другие языки программирования, другие фреймворки и другие способы сборки. Но это неважно, принципы разработки все равно останутся прежними.

В этом уроке пройдемся по ним еще раз. Посмотрим, что остается неизменным, а что меняется от проекта к проекту. И разберем, с чего начинать, когда садитесь за что-то новое.

Что остается одинаковым

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

• Один чат — одна задача. Новая фича или новая проблема — новый чат. Контекст не мешается, агент не путается, вам проще вернуться к работе через неделю.
• Plan mode перед кодом. Агент сначала предлагает план, вы одобряете, и только потом он пишет код. Без плана он начинает делать что-то свое уже на середине задачи.
• Описание проекта для агента. Вы заводите его первым делом на новом проекте. Агент читает это описание в каждом чате и сразу понимает, с чем работает.
• Спецификация перед большой фичей. Любую нетривиальную функцию вы сначала обсуждаете с агентом словами и только потом превращаете в код.
• Обязательные коммиты. Их нужно делать регулярно, после каждой рабочей фичи. Если потом что-то сломается и агент начнет запутываться еще сильнее, вы всегда сможете откатиться к рабочей точке.
• Тесты на важные места. Поведение, которое должно сохраняться после правок, вы закрываете тестом. Написанный тест страхует этот кусок логики от случайных правок агента.
• Один файл — одна задача. Проект вы собираете из небольших файлов, каждый отвечает за свое. Агент не путается в большом коде, и вы тоже.