Капстоун-проект: разработка веб-приложения с нуля

📚 Навигация по серии: Предыдущая статья 47 Голосовой режим Voice научила вас использовать диктовку промптов для разгрузки рук при написании длинных инструкций. Эта статья представляет собой выпускную практическую работу курса — мы не будем изучать новые функции, а возьмем крупный проект, требующий работы в нескольких сессиях чата. Мы объединим в единый рабочий процесс инструменты CLAUDE.md, настройки прав доступа, MCP-серверы, субагентов, контрольные точки и Git-воркфлоу.

Если проанализировать проекты, созданные с помощью Claude Code, становится очевидным: настоящую ценность утилита приносит не при мелких правках в одну строку, а при реализации комплексных задач, требующих открытия 3-5 сессий диалога и использования различных встроенных функций.

Например, для создания небольшой внутренней утилиты с нуля разработчику требуется открыть около 4 сессий чата и потратить около двух часов. В процессе он подключает MCP-сервер для чтения внешней документации, вызывает субагента для проведения аудита безопасности и использует контрольные точки для отката кода при неудачной попытке рефакторинга. В итоге история Git содержит около 7 чистых коммитов с понятным описанием изменений. В этот момент применимость всех изученных ранее инструментов становится очевидной.

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

Аналогия с дирижированием оркестром. Вы научились играть на скрипке, трубе и барабанах — каждый инструмент изучен отдельно. Но умение играть на инструменте отличается от умения управлять оркестром: вы должны знать, когда вступает каждая группа инструментов, кто ведет основную партию и как держать общий ритм. В этой выпускной работе вы выступаете в роли дирижера — инструменты CLAUDE.md, правила доступа, MCP, субагенты, контрольные точки и Git являются вашим оркестром, и мы объединим их в единую мелодию.

Прочитав эту статью, вы получите:

• Пошаговую карту ведения проекта средней сложности с указанием, на каком этапе подключается конкретный инструмент.
• Методику работы с долгоиграющими задачами: как использовать команду --resume, файлы спецификаций (SPEC) и контрольные точки для безопасного разделения проекта на несколько дней разработки.
• Описание команд, логов и контрольных точек на каждом шаге разработки.
• Шаблон реального проекта (консольный менеджер задач todo-cli с локальной БД, автотестами и документацией), объединяющий CLAUDE.md → права доступа → MCP → субагентов → контрольные точки → Git.
• Таблицу сравнения тренировочных тестов и промышленной разработки с разбором популярных ошибок масштабирования.

---

01 Карта проекта: этапы интеграции инструментов

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

布局：

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

Основные отличия от простых разовых тестов (из статьи 39):

• Разделение на несколько сессий. Когда контекст диалога переполняется, Claude начинает путаться (тема статьи 19). Важно уметь вовремя остановить сессию и передать текущий статус следующему чату.
• Подключение вспомогательных инструментов. Для сложных проектов требуются MCP-серверы (чтение документации библиотек) и субагенты (проведение независимого аудита кода).

Официальная рекомендация по масштабированию:

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

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

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

---

02 Инициализация: правила проекта и права доступа

Первый этап — Инициализация (базируется на темах статей 12, 18 по CLAUDE.md и статьи 20 по правам доступа). На этом этапе мы задаем правила игры для всех будущих сессий чата.

Целевой проект выпускной работы: консольный менеджер задач (todo-cli). Утилита должна уметь добавлять задачи, выводить список активных дел и отмечать задачи как выполненные. Данные должны сохраняться в локальный файл todos.json. Проект должен содержать автотесты и файл описания README. Проект пишется на чистом Python без использования внешних библиотек, что позволит запустить его в любой операционной системе.

Шаг 1: Создаем папку проекта и инициализируем репозиторий Git

Выполните в терминале:

mkdir todo-cli && cd todo-cli && git init

Запуск git init на первом шаге обязателен. История коммитов Git является вашей главной страховкой от потери кода. Механизм контрольных точек (статья 37) сохраняет изменения только в рамках активного чата, в то время как коммиты Git фиксируют состояние проекта между сессиями. Проект должен иметь чистый коммит старта.

Шаг 2: Запускаем сессию и создаем файл CLAUDE.md

Запустите программу:

claude

Попросим Claude создать файл правил. Поскольку проект создается с нуля, правила лучше надиктовать явно, не используя автоматическую команду инициализации (которая полезна при анализе уже готового кода):

Создай в корне проекта файл CLAUDE.md со следующими правилами:
1. Проект пишется на чистом Python с использованием только стандартной библиотеки (без внешних зависимостей).
2. Данные сохраняются в файл todos.json в корне проекта. Все операции чтения и записи должны выполняться только через этот файл.
3. Каждое изменение кода должно сопровождаться тестами на базе модуля unittest. Тесты запускаются командой: python3 -m unittest.
4. Сообщения коммитов писать на русском языке с префиксами feat:, fix:, docs:.

Ожидаемый результат: Claude предложит diff создания файла и запросит ваше подтверждение (сработает система безопасности из статьи 20). Подтвердите действие. В проекте появится файл CLAUDE.md.

Соблюдайте правило лаконичности правил:

Сокращайте размер файлов правил. Перед добавлением строки спросите себя: «Приведет ли удаление этой строки к ошибкам в действиях Claude?» Если нет — удалите строку.

Эти четыре правила содержат уникальные требования к нашему проекту, которые Claude не сможет угадать самостоятельно. Теперь при запуске новых сессий чата эти правила будут считываться автоматически, и вам не придется напоминать о запрете сторонних библиотек или языке коммитов.

Шаг 3: Настройка прав доступа для рутинных команд

Для предотвращения частых всплывающих запросов на подтверждение при запуске тестов добавим команду запуска тестов в белый список. Введите в чате /permissions и добавьте команду Bash(python3 -m unittest*) в список allow.

Разделение режимов работы:

• Разрешенные команды (allow) — добавляем рутинные команды проверки (запуск тестов, просмотр статуса git), чтобы не нажимать кнопку подтверждения десятки раз за сессию.
• Режим планирования (plan mode) — переключаемся через Shift+Tab перед написанием сложного кода для предварительного анализа архитектуры.
• Автоматический режим (auto mode) — используем с флагом --permission-mode auto при доверии к ходу разработки для снижения количества запросов.

Настройка белого списка тестов на первом шаге сэкономит вам время в процессе разработки.

💡 Резюме в одной фразе: Инициализация проекта включает создание репозитория git, написание лаконичного CLAUDE.md с правилами разработки и добавление команды запуска тестов в белый список разрешений /permissions для снижения количества отвлекающих запросов.

---

03 Планирование: создание спецификации SPEC.md и разделение задач

Второй этап — Планирование (базируется на темах статей 16 по исследованию кода, 20 по режиму планирования и 19 по лимитам контекста). В отличие от простых задач, крупный проект требует предварительного описания архитектуры в отдельном файле.

Попытка начать писать код сразу без плана приведет к тому, что в процессе работы вы начнете менять структуру данных, переписывать методы и запутаетесь в зависимостях. Для предотвращения этого попросим Claude провести интервью и составить спецификацию проекта.

Шаг 1: Запуск интервью в режиме планирования

Перейдите в режим планирования (сочетание Shift+Tab в чате) и отправьте запрос:

Я планирую разработать консольный менеджер задач todo-cli с сохранением данных в todos.json.
Используя инструмент AskUserQuestion, проведи детальное интервью со мной: расспроси о формате команд интерфейса, структуре хранения данных, обработке граничных случаев (отсутствие файла, повреждение структуры JSON, дублирование задач) и архитектурных решениях.
Не задавай банальных вопросов, сфокусируйся на сложных моментах проектирования.
По итогам интервью составь файл спецификации SPEC.md в корне проекта.

Ожидаемый результат: Claude начнет задавать вопросы о поведении программы — например, «должна ли задача содержать приоритет?», «как реагировать, если файл todos.json поврежден?» или «допускаются ли задачи с одинаковым текстом?». Ответьте на эти вопросы. После этого Claude сформирует файл SPEC.md со структурой команд, схемой базы данных и критериями тестирования.

Проведение интервью позволяет выявить скрытые проблемы до написания первой строки кода. Например, вы можете не подумать о валидации дубликатов, но вопрос AI заставит вас зафиксировать это правило в спецификации.

Шаг 2: Декомпозиция проекта по сессиям чата

Не пытайтесь реализовать весь проект в одном чате. Настроим план разработки, разделив задачи по отдельным сессиям:

• Сессия 1: создание структуры файлов, функций чтения/записи базы данных todos.json, реализация команды add и написание базовых тестов.
• Сессия 2: реализация команд вывода списка list и отметки выполнения done, написание тестов.
• Сессия 3: обработка ошибок (повреждение JSON-файла, неверные аргументы командной строки), расширение тестов.
• Сессия 4: написание документации (README.md), финальная проверка и коммит.

Шаг 3: Передача контекста между сессиями

Как передать статус выполнения задачи при переходе к новой сессии?

• Для завершения работы в текущем чате используйте команду /clear для очистки контекста. При продолжении работы в старом диалоге запустите программу с флагом claude --resume и выберите нужный чат из списка.
• Используйте файл SPEC.md как отчет о состоянии. В начале новой сессии просите Claude прочитать SPEC.md и историю коммитов git для автоматического восстановления контекста разработки.

Шаблон запроса для старта новой сессии:

Изучи файлы SPEC.md и лог git log, чтобы понять текущий статус разработки. Не вноси изменения в код, опиши, на каком шаге мы находимся и к какой задаче нужно приступить.

Если пропустить этот шаг и просто дать команду «продолжай писать код», Claude может изменить структуру базы данных или имена методов, что нарушит совместимость с кодом из предыдущей сессии. Файл спецификации SPEC.md является главным якорем контекста при переходе между чатами.

💡 Резюме в одной фразе: Планирование состоит из проведения интервью для создания SPEC.md и декомпозиции проекта по сессиям. При переходе к новому чату используйте SPEC.md и логи git для автоматической передачи контекста AI.

---

04 Подключение внешних инструментов через MCP

Третий этап — Подключение внешних инструментов (базируется на теме статьи 22 по MCP). Этот шаг позволяет Claude самостоятельно искать информацию во внешних источниках при возникновении вопросов по работе библиотек.

Например, при написании тестов на Python вам может потребоваться уточнить сигнатуру методов класса unittest.TestCase или правила работы с модулем argparse. Вместо того чтобы вручную искать документацию в браузере и копировать её в чат, подключите официальный MCP-сервер документации.

Аналогия с подключением интернета к компьютеру. Компьютер без сети ограничен файлами на своем жестком диске. Для получения свежей информации вам приходится скачивать файлы на флешку и переносить их вручную. Подключение интернет-кабеля (MCP-сервера) позволяет компьютеру самостоятельно скачивать нужные данные из сети по мере необходимости.

Подключим официальный сервер документации для тренировки.

Шаг 1: Добавляем MCP-сервер в систему

Выполните команду в терминале OS:

claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcp

Настройка требует стабильного интернет-соединения.

Ожидаемый результат: консоль выведет сообщение об успешном добавлении сервера: Added HTTP MCP server claude-code-docs.

Шаг 2: Проверяем статус подключения

claude mcp list

Ожидаемый результат: в списке серверов отображается claude-code-docs со статусом ✓ Connected. Если статус горит красным, проверьте настройки прокси-серверов в вашей сети (тема статьи 46).

Шаг 3: Используем сервер в диалоге

Запустите сессию и отправьте запрос:

Используя MCP-сервер claude-code-docs, найди описание работы субагентов (subagents) в Claude Code: параметры вызова и настройки лимитов.

Ожидаемый результат: Claude отправит запрос к серверу документации (при первом вызове появится запрос на авторизацию — подтвердите действие). В чате отобразится лог вызова инструмента с пометкой claude-code-docs, и Claude выведет точную информацию из официального руководства.

Для крупных проектов вы можете подключать и другие серверы:

Целевой источник	Выбор сервера	Возможности автоматизации
Репозиторий GitHub	GitHub MCP	Чтение issue, создание пул-реквестов, добавление комментариев к PR
База данных проекта	PostgreSQL / MySQL MCP	Анализ структуры таблиц, выборка логов ошибок (используйте только безопасный доступ на чтение)
Макеты интерфейсов	Figma MCP	Чтение параметров верстки для точной настройки CSS-стилей

Соблюдайте правила безопасности при работе с внешними серверами:

Подключайте только доверенные MCP-серверы. Чтение внешних неконтролируемых данных повышает риск атак типа внедрения промптов (prompt injection). Ограничивайте права доступа серверов баз данных режимом «только чтение» (readonly) и удаляйте неиспользуемые серверы командой claude mcp remove.

💡 Резюме в одной фразе: Подключение MCP-серверов избавляет от ручного копирования документации и логов в чат. Для работы добавьте сервер командой mcp add, проверьте статус через mcp list и удаляйте неиспользуемые подключения для экономии контекста.

---

05 Делегирование задач субагентам и независимый аудит кода

Четвертый этап — Делегирование задач (базируется на темах статей 23 по субагентам и 29 по командам агентов). При увеличении объема кодовой базы этот шаг защищает основной чат от переполнения контекста.

Изоляция процессов поиска информации через субагентов

Представьте, что вам нужно понять, в каких именно строках кода происходит чтение файла todos.json. Вместо того чтобы просить Claude прочитать все файлы в основном чате, поручите эту задачу субагенту:

Запусти субагента для анализа кода. Пусть он найдет все вызовы функций чтения и записи файла todos.json и вернет мне краткую сводку (имена файлов, номера строк и названия методов). Полные тексты файлов в чат выводить не нужно.

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

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

Независимое код-ревью перед коммитом

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

Агент-ревьюер, запущенный в новой изолированной сессии субагента, видит только diff изменений и правила проекта, не зная истории ваших обсуждений в чате, что позволяет ему объективно оценить качество написанного кода.

Для запуска быстрого ревью используйте встроенную команду:

/code-review

Или сформулируйте кастомный запрос для проверки соответствия спецификации:

Запусти субагента для ревью кода. Пусть он проверит последние изменения на соответствие SPEC.md: все ли требования реализованы, покрыты ли тестами граничные случаи и нет ли лишних правок в сторонних файлах. Отчет напиши на русском языке.

В нашем проекте todo-cli такое независимое ревью помогло обнаружить ошибку: Claude при реализации команды done забыл обработать ситуацию, когда вводится номер несуществующей задачи. Ревьюер указал на отсутствие обработки исключения IndexError и нехватку соответствующего теста.

В версиях v2.1.116+ доступен также экспериментальный режим Agent teams (статья 29) для автоматического распределения задач между группой агентов. На этапе создания проекта средней сложности достаточно использовать ручной вызов субагентов для точечного аудита и поиска информации.

💡 Резюме в одной фразе: Используйте субагентов для сбора информации по файлам (сохраняет контекст главного чата) и запускайте команду /code-review для независимого аудита кода перед фиксацией изменений.

---

06 Контроль ошибок: откат изменений при сбоях

Пятый этап — Контроль ошибок (базируется на теме статьи 37 по контрольным точкам). При работе со сложным кодом вы неизбежно столкнетесь с ситуациями, когда предложенный AI рефакторинг ломает работоспособность приложения.

Самая популярная ошибка при сбое: попытка просить Claude исправить сломавшийся код в текущем состоянии.

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

Методы отката изменений:

Способ отката	Используемый инструмент	Граница возврата	Когда применять
Отмена последних правок	Контрольные точки (/rewind или двойной Esc)	До момента внесения изменений в текущем чате	Локальные ошибки, замеченные сразу после генерации кода
Возврат к стабильному коммиту	Система Git (git reset --hard)	К состоянию выбранного коммита Git	Крупные сбои, затрагивающие несколько файлов и сессий

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

Механизм контрольных точек Claude Code отслеживает только изменения файлов, сделанные самим Claude в рамках текущей сессии диалога. Он не фиксирует изменения от внешних команд Bash и не заменяет полноценную систему контроля версий Git.

Поэтому золотое правило разработки гласит: создавайте коммит Git после реализации каждого логического блока программы.

Пример сбоя в todo-cli: при рефакторинге модуля сохранения данных Claude изменил структуру JSON-файла, что привело к падению тестов во всех модулях. Вместо ручного поиска ошибок мы выполнили команду git reset --hard для возврата к предыдущему коммиту. Это сэкономило время и вернуло проект в стабильное состояние за несколько секунд. После отката мы повторили запрос, добавив требование: «сохраняй обратную совместимость структуры JSON-файла». Вторая попытка прошла успешно.

💡 Резюме в одной фразе: При сбое кода не пытайтесь чинить его костылями — вернитесь к стабильной точке. Используйте команду /rewind для отмены правок в текущем чате или git reset --hard для возврата к коммитам Git. Пишите коммиты чаще.

---

07 Практический практикум: разработка приложения от старта до сдачи

Пройдем полный путь разработки первой части нашего консольного менеджера задач todo-cli на практике. Мы инициализируем проект, настроим правила, напишем код функций добавления и вывода задач и зафиксируем стабильный коммит.

Для работы требуется установленный Python 3 и Git. Проверка работы песочницы выполняется в macOS, Linux или WSL2.

Шаг 1: Инициализация проекта (раздел 02)

Выполните команды в терминале OS:

mkdir todo-cli && cd todo-cli && git init && claude

Запустив сессию Claude, попросим создать правила проекта:

Создай файл CLAUDE.md со следующими правилами:
- Проект пишется на чистом Python с использованием только стандартной библиотеки.
- Данные сохраняются в файл todos.json в корне проекта.
- Тесты пишутся на unittest и запускаются командой: python3 -m unittest.
- Сообщения коммитов писать на русском языке с префиксами feat: / fix: / docs:.

Ожидаемый результат: Claude создаст файл CLAUDE.md. Подтвердите операцию. Добавьте команду тестов в белый список разрешений: введите /permissions и пропишите команду Bash(python3 -m unittest*) в список allow.

Шаг 2: Проектирование в режиме планирования (раздел 03)

Перейдите в режим планирования (Shift+Tab в чате) и отправьте запрос на проработку архитектуры:

Я планирую создать файл todo.py с командами add (добавление задачи) и list (вывод списка). Данные сохраняем в todos.json. Опиши структуру данных и архитектуру приложения, а также план тестирования. Пока не пиши код файлов, дождись моей команды.

Ожидаемый результат: Claude предложит схему: JSON-файл будет содержать список объектов с ключами id, text и completed. В коде будут функции load_todos(), save_todos(), add_todo() и list_todos(). Тестирование будет проверять запись и чтение. Подтвердите план, написав «план одобряю, приступай к реализации кода и тестов».

Шаг 3: Написание кода и контроль правок (раздел 02)

Вернитесь в обычный режим (Shift+Tab) и подтвердите начало работы.

Ожидаемый результат: Claude создаст файлы todo.py и test_todo.py. На каждом шаге создания файлов программа будет выводить diff изменений и запрашивать ваше разрешение. Внимательно проверяйте код: отсутствие внешних библиотек и соответствие схеме данных. Подтверждайте операции.

Шаг 4: Запуск тестов и проверка работы

Запустите тесты (команда выполнится автоматически без запроса подтверждений благодаря белому списку):

python3 -m unittest

Ожидаемый результат: тесты должны завершиться успешно:

...
----------------------------------------------------------------------
Ran 3 tests in 0.002s

OK

Проверим работу приложения вручную в терминале:

python3 todo.py add "Изучить 48 статью курса"
python3 todo.py add "Запустить практический тест"
python3 todo.py list

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

1. [ ] Изучить 48 статью курса
2. [ ] Запустить практический тест

Работа функций проверена автотестами и ручным запуском.

Шаг 5: Код-ревью субагентом (раздел 05)

Перед коммитом запустим проверку качества кода:

/code-review

Ожидаемый результат: запустится изолированный субагент, проверит соответствие кода спецификации и правилам CLAUDE.md и вернет отчет. Если ревьюер найдет мелкие недочеты (например, отсутствие закрытия файла при ошибке чтения JSON), попросите Claude исправить их.

Шаг 6: Фиксация изменений в Git

Попросим Claude подготовить коммит:

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

Ожидаемый результат: Claude выведет список созданных файлов, предложит текст сообщения коммита (например, feat: реализованы команды add и list для todo-cli) и запросит подтверждение вызова git commit. Подтвердите операцию.

Шаг 7: Контроль красной линии (раздел 06)

Первая часть проекта завершена и сохранена в локальный коммит.

Помните: отправка изменений в удаленный репозиторий (git push) должна выполняться вами вручную в терминале операционной системы. Блокируйте автоматический запуск push в правилах разрешений.

Вы прошли полный цикл разработки логического блока проекта под контролем Claude Code.

💡 Резюме в одной фразе: Практическая работа демонстрирует интеграцию инструментов: создание правил в CLAUDE.md, проектирование в режиме планирования, пошаговое написание кода с проверкой diff, запуск автотестов, аудит через /code-review и фиксацию изменений локальным коммитом.

---

08 Сравнение тренировочных тестов и промышленной разработки

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

Сравним особенности ведения проектов разного масштаба:

Этап разработки	Тренировочный тест (статья 39)	Промышленный проект (эта статья)
Правила проекта	Достаточно 2-3 строчек в CLAUDE.md	Правила CLAUDE.md дополняются правилами разрешений в settings.json для настройки безопасности
Планирование	Опускается, пишется сразу код	Обязательное создание спецификации SPEC.md до начала программирования
Объем сессий	Все задачи решаются в рамках одного чата	Задачи разбиваются по сессиям с очисткой контекста через /clear и восстановлением по SPEC.md
MCP-серверы	Не используются	Подключаются для сбора внешней информации и интеграции с GitHub/БД
Субагенты	Не используются	Вызываются для изоляции поиска по файлам и проведения независимого ревью
Контроль ошибок	Ручное исправление кода по ходу диалога	Откат изменений к стабильной точке через /rewind или git reset при крупных сбоях
Сдача кода	Код остается в папке без фиксации истории	Подготовка структурированных коммитов с блокировкой автоматического git push

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

💡 Резюме в одной фразе: При переходе от тренировочных тестов к реальным проектам не пренебрегайте дисциплиной разработки: пишите спецификации SPEC.md, разделяйте задачи по сессиям, используйте субагентов для разгрузки контекста и регулярно создавайте коммиты Git.

---

09 Заключение

Мы провели комплексную разработку проекта средней сложности под контролем Claude Code, объединив все изученные в курсе инструменты в единый рабочий процесс.

Резюмируем ключевые правила ведения проектов:

Шаг	Инструмент	Основная задача
1. Инициализация	CLAUDE.md и /permissions	Фиксация правил кодирования и настройка белого списка команд
2. Планирование	Интервью и SPEC.md	Составление спецификации и разделение задач по сессиям чата
3. Интеграция API	MCP-серверы	Подключение внешней документации и сервисов для автономного поиска
4. Делегирование	Субагенты и /code-review	Поиск по файлам без засорения контекста чата и независимый аудит кода
5. Контроль ошибок	/rewind и git reset	Откат сломавшихся изменений к стабильной точке вместо написания костылей
6. Сдача проекта	Сообщения коммитов и Git	Локальная фиксация изменений с личным контролем команды git push

Освоение сквозного процесса разработки позволяет эффективно использовать Claude Code для создания надежных, протестированных и документированных программных продуктов любого масштаба.

---

В следующей статье 49 «Сводный справочник лучших практик» мы подведем итоги курса. Мы соберем воедино все рекомендации по эффективной работе с Claude Code: от составления промптов и управления контекстом до правил безопасности, оптимизации сетевого трафика и настройки MCP-серверов в виде удобного справочника.

---

Рекомендуемое чтение

• Интеграция с Git: правила коммитов
• Субагенты (Subagents): детальное руководство
• Система памяти: сохранение контекста