Claude Code: agentic coding environment

1. Сегодня первый день твоей новой жизни

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

Наш курс по Claude Code — это быстрый вход в AI-native разработку. Здесь ты будешь учиться работать с AI как с инженерным рычагом: формулировать цель, направлять ход работы, получать план, запускать изменения, проверять итог и собирать работающий результат. Шаг за шагом ты начнёшь делать то, что раньше казалось доступным только сильнейшим разработчикам 🧠.

Claude Code делает тебя сильнее, умнее. Он делает тебя лучше 🔥.

Именно этому посвящён курс: ты будешь осваивать новую роль разработчика — не человека, который просто пишет код руками, а инженера, который умеет управлять разработкой вместе с AI. Сегодня ты делаешь первый шаг в AI-native разработку. Впереди будут задачи, ошибки, открытия и первые победы. И однажды ты осознаешь: “Теперь я могу все.” 🏆

2. Claude Code — это не чат в терминале

Как все себе представляют Claude Code? Как «ещё одного чат-бота, только в терминале»? Образ понятный — и очень далек от истины. Пока вы так будете думать — вы ничему не научитесь.

Обычный AI-чат — это умный собеседник. Вы пишите текст, ошибку, фрагмент кода — получаете ответ. Иногда подозрительно хороший. Но что перенести в проект, а что отправить в корзину гениальных идей, не переживших встречу с реальностью, решаете вы.

Claude Code работает прямо на вашем компьютере: читает файлы, ищет по кодовой базе, предлагает план, редактирует код, запускает команды и возвращает не объяснение, а результат. Вот зачем слово agentic: инструмент не только рассуждает, но и действует.

Обычный чат — консультант за стеклом: вы показываете схему, он говорит «я бы вот этот винт открутил». Claude Code — помощник, которого вы впустили в мастерскую: берёт отвёртку и говорит «нашёл нужный винт, вот что предлагаю». Удобнее? Да. Опаснее? Ещё как.

Это различие удобно увидеть в одной таблице:

И вот здесь появляется первая важная формула курса. Её стоит буквально держать в голове уже с этой лекции:

Claude ускоряет инженерную работу, но за результат все равно отвечаете вы.

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

3. Что значит «действует»

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

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

Представьте интернет-магазин Commerce OS. В нем есть модуль возвратов, очередь заявок поддержки и логика, которая определяет, какие обращения оператор видит первыми. Допустим, менеджер замечает проблему: срочные заявки на возврат иногда оказываются ниже обычных. В обычном AI-чате вы бы скопировали кусок метода, лог ошибки или описание проблемы и спросили: «Как думаешь, что не так?» Это полезно, но чат всё ещё находится снаружи проекта.

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

Вы: «В очереди возвратов срочные заявки иногда оказываются ниже обычных.
Найди связанную логику, но сначала покажи план без изменений.»

Claude: «Нашёл сервис сортировки, связанный контроллер и тест.
Предлагаю сначала проверить правило сортировки, потом показать diff.»

Заметьте, насколько это отличается от привычного «вот возможные причины». Инструмент уже ведёт себя как участник рабочего процесса. Он не обещает магию, не заявляет «я всё починил», а сначала разбирается в проекте, находит область изменений и предлагает следующий шаг.

Именно здесь начинающие разработчики часто делают первую ошибку. Им кажется, что Claude Code — это просто «чат, который видит больше текста». Но разница глубже. Когда инструмент может читать проект и менять файлы, у него появляется операционный контекст. А вместе с ним — и риск полезного перебора: ИИ не только помогает, но и может «слишком помочь».

Поэтому правильное отношение к Claude Code в реальном проекте — не «о, чат научился открывать папки». Полезнее думать так: в моей рабочей среде появился очень быстрый технический помощник, которому я должен чётко объяснять задачу и проверять результат. Если держать в голове именно эту картину, дальше почти все темы курса встанут на место гораздо легче.

4. Одна строка меняет логику работы

Особенно коварно то, что многие изменения выглядят маленькими и безобидными. Одна строка, один импорт, одно условие — вроде бы мелочь. Но в реальном продукте такая мелочь очень быстро превращается в изменение бизнес-правил. А бизнес, как вы понимаете, крайне редко радуется внезапным сюрпризам, особенно если они связаны с деньгами, заказами или возвратами.

Допустим, в Commerce OS была такая логика: срочную заявку на возврат поднимаем наверх.

if (refundRequest.isUrgent()) {
    moveToTop(refundRequest);
}

А потом Claude Code предложил или даже внёс такую правку:

if (refundRequest.isUrgent() || refundRequest.amount() > 100) {
    moveToTop(refundRequest);
}

Выглядит невинно? Всего лишь одна добавленная часть условия. Но фактически поведение системы изменилось. Теперь наверх поднимаются не только срочные возвраты, но и все возвраты на большую сумму. Возможно, это хорошая идея. А возможно, это совсем другое бизнес-правило, которое никто не просил вводить. Вот почему в обычном AI-чате такая правка была бы просто советом в тексте, а в Claude Code она уже становится реальным изменением поведения.

Полезно сразу привыкнуть к слову diff. Если совсем по-простому, diff — это список изменений: какие строки были удалены, какие добавлены, что именно поменялось между старой и новой версией файла. Для разработчика diff — не скучная техническая деталь, а главный способ увидеть, что произошло на самом деле. Текстовый ответ ИИ может быть очень убедительным, но именно diff показывает правду без преукрашиваний.

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

Плохая постановка задачи в Claude Code может дать плохой diff прямо в реальном проекте. Это уже совсем другой уровень цены ошибки. Если вы попросили слишком расплывчато, инструмент вполне может начать улучшать то, что вы вообще не собирались трогать: заодно подчистить структуру, переименовать поля, изменить порядок сортировки, поправить пару соседних методов «ради консистентности». И всё это будет выглядеть логично и аккуратно.

Вот почему с этого момента полезно перестать думать в логике «ИИ написал код». В рабочей среде точнее другая фраза: ИИ предложил изменение в проекте. А любое изменение в проекте — даже маленькое — должно быть понятным, ограниченным и проверяемым.

5. Базовый цикл работы

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

Схема выглядит так:

flowchart TD
    A[Задача от разработчика] --> B[Claude изучает контекст]
    B --> C[Предлагает план или маленькое изменение]
    C --> D[Разработчик читает diff]
    D --> E[Запускаются проверки]
    E --> F[Человек принимает решение]

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

Следующий шаг — чтение diff, то есть списка изменений. После этого запускаются проверки. Если вы только начинаете программировать, полезно не пугаться слов. Tests — это автоматические проверки поведения. Build — проверка, что проект вообще собирается. Lint — проверка на технические и стилистические проблемы в коде. Иногда ещё делают простую пробную прогонку ключевого сценария, чтобы убедиться, что система хотя бы не рассыпалась сразу после правки. Всё это нужно не для красоты, а чтобы ответить на простой вопрос: изменение действительно работает так, как мы ожидали, или нам просто хочется в это верить?

Мини-сценарий общения может выглядеть так:

Вы: «Исправь порядок отображения возвратов. Сначала покажи план.»

Claude: «Нашёл 3 связанных файла. Предлагаю изменить правило сортировки
и проверить существующий тест на очередь возвратов.»

Вы: «Хорошо. Покажи diff после изменения и что именно проверить.»

Это и есть здоровый ритм. Не «сделай всю фичу, я пока схожу за кофе», а «покажи, что ты понял задачу, что хочешь менять и чем докажешь, что не сломал соседний кусок проекта». Да, такой подход чуть менее кинематографичен. Зато он резко снижает шанс получить тот самый случай, когда ИИ сделал работу быстро, а вы потом полдня разбираетесь, что именно он успел улучшить «заодно».

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

6. Действовать и отвечать — не одно и то же

На этом месте у многих возникает очень честный вопрос: если Claude Code умеет читать код, предлагать план, редактировать файлы и даже запускать команды, то почему ответственность всё равно остаётся за человеком? Потому что умение действовать и умение отвечать за последствия — не одно и то же. Именно эта разница отделяет помощника от владельца результата.

Claude Code может очень быстро сделать черновую инженерную работу. Он может сэкономить вам время на поиске файлов, на первом проходе по логике, на рутинных изменениях, на подготовке объяснения. Но бизнес-ответственность он не несёт. Он не знает контекст команды так, как знаете вы. Он не обсуждал изменения с менеджером. Он не будет сидеть на созвоне, если из-за неудачной правки перестанет корректно считаться возврат дорогого заказа. Максимум — очень вежливо извинится текстом. Согласитесь, полезно, но всё-таки маловато.

Эту границу удобно увидеть так:

Это особенно важно в ситуациях, где ИИ «почти прав». Полностью ошибочный ответ обычно виден быстрее. Гораздо опаснее аккуратное и разумно звучащее изменение, которое слегка выходит за рамки задачи. Например, вы просили поправить сортировку возвратов, а инструмент заодно переименовал пару полей, подправил соседний метод и немного пересобрал структуру сервиса, потому что «так чище». В этот момент он не вредничает. Он действительно пытается помочь. Но помогать без чёткой границы — один из любимых способов случайно залезть туда, куда не просили.

Поэтому позиция разработчика здесь очень взрослая и очень спокойная. Не нужно относиться к Claude Code как к магии, но и не нужно видеть в нём угрозу. Полезнее думать о нём как об очень быстром стажёре с хорошей памятью и плохим чувством организационной субординации. Он может сделать много полезного. Но сказать «стоп, это вне задачи», «покажи только план», «почему ты изменил ещё и это место?» и «нет, это не мержим» — всё ещё ваша работа.

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

7. Учите принцип, а не команды

Самая ценная часть этой лекции почти не зависит от версии продукта. Кнопки могут переехать, названия команд — измениться, какие-то поверхности — появиться, какие-то — исчезнуть или переименоваться. Это нормальная жизнь современного инструмента. Но базовая ментальная модель от этого не меняется, и именно она делает вас устойчивее к обновлениям.

Если держать в голове только список команд, то любое обновление продукта ощущается как маленькое землетрясение. Вчера команда называлась так, сегодня иначе, у кого-то другой интерфейс, чей-то скриншот уже устарел — и всё, кажется, что почва ушла из-под ног. А если держать в голове основную идею, всё спокойнее. Вы понимаете, что Claude Code — это действующий помощник внутри проекта. Он работает с кодовой базой, может предлагать и вносить изменения, а значит, вам нужны задача, границы, diff и проверка. Как именно называется кнопка или команда, — уже второй вопрос.

Вот почему в этом курсе мы постоянно будем опираться не на «заучите десять волшебных слов», а на устойчивые принципы. Если деталь продукта поменялась, вы просто открываете актуальную справку и смотрите, как это называется сейчас. Но сам подход не рассыпается. Вы всё так же понимаете, что сначала нужно разобраться в задаче, потом в проекте, потом в изменении, а затем — в доказательстве того, что изменение вменяемое.

Для первой лекции этого уже достаточно. Если после неё у вас в голове осталась не мысль «Claude Code — это чат, который стал мощнее», а мысль «в моей рабочей среде появился инструмент, который умеет действовать, и поэтому я обязан работать с ним как инженер», значит, фундамент заложен правильно. А это, как ни странно, куда важнее любой красивой демонстрации.

8. Среда до Claude Code: Git и Node.js

А теперь немного практики. Прежде чем мы дойдём до установки самого Claude Code, на машине должны жить две вещи: Git и Node.js. Их мы ставим руками и заранее, ещё до CLI. Звучит как лишний шаг, но это ровно тот случай, когда пять минут подготовки экономят час недоумения позже.

Почему именно эти два инструмента и именно до Claude Code?

Git — это фундамент всего рабочего процесса курса. В следующей лекции мы соберём основную схему: проект → понятное состояние репозитория → diff → проверки → решение человека. Звено «понятное состояние репозитория» — это и есть Git. Без него Claude Code технически запустится, но вы лишитесь главного: возможности видеть, что именно изменилось в этой итерации, и откатиться, если правка пошла не туда. Работать с агентом без Git — это как редактировать важный документ без кнопки «отменить». Поэтому Git — не «ещё одна утилита из списка», а несущая конструкция.

Node.js — это страховка установки самого Claude Code. Как вы увидите в третьей лекции, у CLI несколько путей установки, и один из них — через npm (пакетный менеджер Node.js). Если основной способ установки на вашей машине вдруг не сработает — а на Windows и на корпоративных машинах это совсем не редкость — наличие Node.js даёт вам запасной путь поставить CLI через npm или быстро попробовать через npx. Плюс Node.js понадобится дальше по курсу для фронтенд-части учебного проекта. То есть это не разовая страховка, а инструмент, который всё равно пригодится.

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

Git по операционным системам

# macOS — через Homebrew (или установится вместе с Command Line Tools)
brew install git
# либо, если Homebrew нет:
xcode-select --install

# Linux — через пакетный менеджер дистрибутива
sudo apt install git        # Debian / Ubuntu
sudo dnf install git        # Fedora / RHEL

# Windows — через winget (или установщик с git-scm.com)
winget install --id Git.Git

Node.js по операционным системам

Везде берите версию с пометкой LTS (Long-Term Support) — это стабильная ветка, на которую рассчитано большинство инструментов. Гнаться за самой свежей нестабильной версией на старте смысла нет.

# macOS — через Homebrew
brew install node

# Linux — рекомендуется через nvm (Node Version Manager),
# чтобы версии Node жили в домашнем каталоге, а не в системных директориях
# установку nvm смотрите в его официальном репозитории, затем:
nvm install --lts

# Windows — через winget (или установщик с nodejs.org)
winget install --id OpenJS.NodeJS.LTS

Проверка, что всё на месте

После установки откройте новое окно терминала (это важно — PATH обновляется не в текущей сессии, а в новой) и прогоните три короткие проверки:

git --version          # например: git version 2.47.x
node --version         # например: v24.x.x  (LTS)
npm --version          # например: 11.x.x

Если все три команды вывели версию без ошибок — базовая среда готова, и в третьей лекции можно спокойно переходить к установке самого Claude Code. Если какая-то команда отвечает command not found — почти всегда дело в том, что терминал не перезапущен после установки. Это тот же сигнал PATH, который мы подробно разберём на примере Claude Code. Логика везде одна: инструмент стоит, но shell ещё не знает, где его искать.

Когда вы впервые откроете проект типа Commerce OS и увидите рядом не просто окно переписки, а действующего помощника с доступом к коду, полезно вспомнить именно это состояние: спокойствие, границы и ответственность. С такого отношения и начинается взрослая разработка с поддержкой ИИ.