# Claude Code на реальном проекте: день из жизни
Канонический URL: https://zero2claude.ru/blog/claude-code-real-project
Дата: 2026-08-19
Теги: claude-code, новичкам, рабочий процесс
Как выглядит обычный рабочий день с Claude Code: разобраться в репо, починить баг, добавить фичу, прогнать тесты и закоммитить.
Туториалы любят показывать чистенький старт: пустая папка, «создай файл hello.txt», аплодисменты. А в жизни всё иначе — ты открываешь чужой проект на сотню файлов и не понимаешь, с какого конца за него взяться. Где тут логика? Что сломается, если тронуть вот это?
Давай пройдём обычный рабочий день вместе с Claude Code — не идеальный, а реальный. С незнакомым репозиторием, багом, новой фичей и коммитом в конце. Чтобы ты увидел не отдельные команды, а **ритм**: как одно цепляется за другое.
## Утро: разобраться, где ты вообще оказался
Первое, что делаешь на новом проекте — не пишешь код, а **понимаешь**. Раньше на это уходил час: открываешь папку за папкой, читаешь файлы наугад, строишь в голове карту. Теперь можно просто спросить.
> «Это незнакомый мне проект. Объясни в двух абзацах, что он делает, где точка входа и как устроены основные папки.»
Claude Code сам пройдётся по файлам и расскажет картину человеческим языком: вот тут роутинг, тут бизнес-логика, тут тесты. Ты не зубришь структуру — ты сразу понимаешь, куда смотреть. На незнакомом проекте это экономит не минуты, а само ощущение «я тут чужой». Десять минут назад папка пугала — теперь у тебя есть карта.
Не бойся переспрашивать. «А где хранятся настройки?», «Покажи, как данные доходят от формы до базы» — каждый такой вопрос дорисовывает картину. Это не «глупые вопросы новичка», это нормальный способ въехать в код: ты задаёшь их вслух вместо того, чтобы час медитировать над файлами в одиночку.
Дальше — конкретнее. Прилетела задача: «при пустом поле формы приложение падает вместо подсказки». Не лезешь искать руками — спрашиваешь:
> «Где обрабатывается отправка формы и почему пустое поле может ронять приложение?»
И получаешь не только файл, но и **гипотезу**: скорее всего, нет проверки на пустое значение перед тем, как его использовать.
## День: баг и фича в одном ритме
Гипотеза есть — чиним. Но не «давай сразу правь», а сначала договариваемся:
> «Покажи план: как добавить проверку пустого поля, не сломав остальное. Файлы трогать пока не нужно.»
Это **режим плана** — Claude описывает шаги, ты читаешь, киваешь. Согласовали — он вносит правку и показывает **diff**: что было слева, что стало справа. Зелёное добавилось, красное ушло. Ты глазами видишь ровно то изменение, о котором договорились, — никаких сюрпризов в соседних файлах.
Баг закрыт — переходим к фиче. К той же форме надо добавить кнопку «Очистить». Логика та же самая, и в этом весь кайф ритма:
- **Сначала словами.** Объясняешь, что хочешь и как это должно вести себя.
- **Потом план.** Claude предлагает, где и что добавит.
- **Потом diff.** Смотришь изменения до того, как они станут окончательными.
Ты не печатаешь код руками — ты **ставишь задачу и проверяешь результат**. Голова занята смыслом («что должно происходить»), а не синтаксисом («где тут точка с запятой»).
И тут важный момент: твоя работа не исчезла, она просто сместилась. Раньше ты бы час вспоминал синтаксис и опечатки. Теперь ты читаешь diff и думаешь головой: «А что будет, если поле не пустое, но в нём только пробелы? А если форму отправят дважды подряд?» Эти вопросы — самое ценное, что ты приносишь. Claude быстро печатает, но именно ты решаешь, что правильно.
Проси менять по одному кусочку за раз. «Почини баг, добавь фичу и заодно отрефактори» в одном запросе — это каша: трудно прочитать diff и понять, что именно поменялось. Маленькие шаги = понятные diff'ы = меньше страха что-то сломать.
## Вечер: тесты и коммит
Код написан — но «работает у меня» это ещё не «работает». Прежде чем сохранять, прогоняем тесты:
```bash
npm test
```
Если что-то красное — не паникуешь, а показываешь ошибку Claude:
> «Тест падает вот с такой ошибкой. Почему и как починить?»
Он читает текст ошибки (тот самый, который новичку кажется китайской грамотой), находит причину и предлагает правку. Снова смотришь diff, снова прогоняешь тесты — пока не станет зелёным. Иногда первая правка не помогает — это нормально. Показываешь новую ошибку, и круг повторяется. Два-три захода — обычное дело даже у опытных, так что не воспринимай красный экран как свой провал.
Не жми вслепую «да, делай» на всё подряд. Если Claude предлагает удалить файлы, снести папку или выполнить команду, смысл которой тебе непонятен, — сначала спроси: «Объясни, что делает эта команда и можно ли её откатить». Зелёные тесты и привычка читать diff — твоя страховка, а не формальность.
И финальный аккорд — **коммит**. Это «точка сохранения» проекта: зафиксировал работающее состояние, и к нему всегда можно вернуться.
```bash
git add .
git commit -m "fix: подсказка вместо падения при пустом поле + кнопка «Очистить»"
```
Можно даже не сочинять текст коммита самому — попроси Claude: он посмотрит, что изменилось, и предложит понятное описание. День закрыт: баг исчез, фича появилась, тесты зелёные, всё сохранено.
## Что важно унести с собой
Заметил ритм? Он один и тот же на любой задаче:
**понять → спланировать → изменить → проверить → сохранить.**
Не «выучить сто команд», а освоить эту петлю. Команды (`npm test`, `git commit`) — просто инструменты внутри неё, и их штук пять на каждый день. Сам ритм важнее любой отдельной команды: именно он превращает страшный незнакомый проект в спокойную последовательность маленьких уверенных шагов.
И да — для этого не нужно быть программистом. Нужно уметь ясно сказать, чего ты хочешь, и проверить, что получилось. Этому ритму — от первой команды в терминале до коммита на реальном проекте — мы учим с самого нуля, без воды и в безопасной песочнице.