Карта поверхностей и workflow курса

1. У Claude Code не один экран, а несколько

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

Владеть всеми сразу не нужно. На старте опаснее распылиться, чем «недоиспользовать возможности». Claude Code ценен не числом кнопок, а ясностью пути от задачи до проверяемого результата.

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

2. Курс стартует с terminal-first

Терминал важен не потому, что «настоящие разработчики любят чёрные окна», а потому, что там Claude Code максимально близко к проекту: стартует в конкретной директории, видит конкретный репозиторий, читает файлы именно этой папки. Не «код из переписки», а живая структура.

Возьмём учебный репозиторий Commerce OS: заказы, поддержка, платежи, аналитика. Запустив Claude из терминала в корне, вы даёте сигнал: вот рабочее пространство, вот границы. Это не браузерный чат, где вы пересказываете проект: «там где-то сервис заказов, а файл, кажется, на букву O…».

cd commerce-os   # переходим в репозиторий проекта
claude           # запускаем Claude Code внутри этой папки

Ничего хакерского — и это плюс. Claude не угадывает, где проект, он уже стоит внутри.

Terminal-first не означает terminal-only. IDE не запрещена. Скелет работы мы собираем вокруг запуска через терминал, остальные поверхности добавляем там, где они полезны.

Терминал держит рядом три вещи, которые в разработке с ИИ должны жить вместе: проект, Claude и проверки. Привычка стартовать из проекта снимает вечный вопрос «а этот ответ вообще про мой проект?». Терминал — не самый красивый старт, а самый ясный.

3. IDE рядом, а не вместо

Тут легко уйти в ложный выбор: либо «всё только в терминале», либо «зачем CLI, когда есть окно с кнопками». Оба слабые. IDE — не замена Claude Code, а поверхность проверки: читать реальные файлы, видеть диапазоны строк, смотреть diff рядом с кодом, замечать, что именно поменялось.

Claude объясняет свою правку — IDE показывает сам файл, соседний код, контекст. Вы видите не «кусочек ответа ИИ», а часть реальной системы.

Терминал запускает процесс. IDE проверяет результат. Claude что-то предложил — смотрите в файле и в diff, а не только в тексте.

4. Workflow курса: от проекта к артефакту

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

flowchart TD
    A[Терминал: Claude внутри проекта] --> B[Git: понятное состояние репозитория]
    B --> C[IDE: чтение файлов и визуальный diff]
    C --> D[Проверки: diff, tests, build, lint]
    D --> E[Человек принимает решение]
    E --> F[Результат, который можно показать и проверить]

Именно в этой последовательности Claude Code перестаёт быть генератором сюрпризов.

Главное — последнее звено. Соблазн думать про ИИ как про сокращение пути: «Claude ответил — задача решена». Мыслите иначе: Claude дал материал для решения, не само решение. Финальная точка — не «готово» от модели, а момент, когда результат можно показать коллеге.

Отсюда PR-ready artifact: изменения в состоянии, когда их можно отдать на ревью. Открывать pull request прямо сейчас не нужно — но код, diff, результаты проверок и описание уже готовы к чужим глазам. Даже если работаете один: код, который стыдно показать коллеге, и самому принимать рано.

Тот же маршрут короче:

Терминал → проект → изменения → IDE → проверки → решение человека

Терминал — старт и контекст. Git — страховка и история. IDE — видимость. Проверки — доказательства. Человек — последний фильтр. Уберите звено — процесс шатается. Особенно если это чтение diff.

5. Поверхности, которые знаем, но не включаем сразу

Новый инструмент будит порыв: «раз есть desktop, web, remote, Slack, CI, mobile, облако — открою всё сразу». Понятный и невыгодный. На старте достаточно знать, что эти поверхности существуют, не таща их в базовый процесс. Иначе вместо рабочей схемы выйдет экскурсия по интерфейсам.

Поверхности не второсортные: CI и командные сценарии в GitHub реально ускоряют команду. Но пока не устоялась цепочка «проект → diff → проверки → решение», лишнее не помогает, а шумит.

Зрелость тут скромная: вы знаете про разные режимы, но берёте минимально достаточный набор под задачу. Сейчас он короткий: терминал плюс IDE. Остальное — знание карты, не приказ бежать во все стороны.

6. Рабочий день в Commerce OS: цепочка поверхностей

Соберём из карты историю. Вы открыли Commerce OS, задача будничная: в списке заказов что-то странно с сортировкой. Разбора бага тут нет — важен только маршрут по поверхностям: куда смотреть и зачем.

commerce-os/
  orders/
  payments/
  support/
  dashboard/

Вы заходите в проект через терминал, запускаете Claude и просите найти, где в модуле orders живёт логика сортировки. Claude смотрит на реальную папку commerce-os, не на пересказ. Показал файлы или предложил правку — переходите в IDE и смотрите глазами: метод может жить не в том сервисе, рядом может быть похожая логика, правка может зацепить лишний файл.

Делается правка — не «поверить на слово», а проверить diff и поведение. Даже в крошечном сценарии полезен формат:

Изменено:
- orders/OrderService.java

Проверено:
- список заказов открывается
- новые заказы отображаются сверху

Это уже понятный след работы. Результат не просто «написан», а объясним и проверяем. Этот переход собирается не в одной поверхности, а в их комбинации.

Сожмёте всё в одну точку входа — процесс деформируется. Только терминал — тяжелее контролировать изменения глазами. Только IDE без запуска Claude — теряется связь с рабочим контекстом. Только веб — пересказываете проект вместо работы с ним. Только Slack — активность без инженерной опоры.

Workflow курса спокоен именно потому, что расставляет поверхности по ролям. Терминал запускает работу изнутри проекта. IDE заземляет изменения. Проверки подтверждают результат. Человек решает.

7. Остальной стек: Java, Gradle и Python

В прошлой лекции мы поставили два «билета на вход» — Git и Node.js. Руками и заранее: без Git не собирается workflow, Node.js страхует установку CLI. Теперь — остальной стек: Java (JDK), Gradle и Python. Подход тут другой.

Развилка: стек можно поставить руками сейчас, а можно дождаться следующей лекции и попросить установить его сам Claude Code. Советую второй вариант: установка стека станет первым живым упражнением по теме курса.

Почему. Git и Node.js нужны до появления CLI — иначе их некому поставить. А Java, Gradle и Python нужны для работы над проектом, к этому моменту CLI уже будет. Установка превращается в реальную задачу: видите, как агент ставит инструмент, проверяет версию, при необходимости чинит окружение. Полезнее, чем молча скопировать команду из гайда.

Отдельно про Gradle, потому что здесь легко запутаться. В реальном Java-проекте сборку запускают не глобальной командой gradle, а через Gradle Wrapper — скрипт ./gradlew (или gradlew.bat на Windows), который лежит прямо в репозитории. Wrapper сам скачивает и использует ту версию Gradle, которая прописана в проекте. Это гарантирует, что у всех участников команды сборка идёт одной и той же версией, независимо от того, что у кого установлено глобально.

Тогда зачем вообще ставить Gradle глобально? Ровно для одного сценария: создать Wrapper в новом проекте с нуля (gradle wrapper). После этого вы переключаетесь на ./gradlew и про глобальный Gradle забываете. То есть глобальная установка — это «стартер» для новых проектов, а повседневная работа в готовом проекте идёт через Wrapper. Запомните это сразу, чтобы не словить классическую путаницу «у меня глобально одна версия, а проект хочет другую»: в готовом проекте версию диктует Wrapper, а не ваша глобальная установка.

Вариант А: поставить руками сейчас

Команды по операционным системам. Та же оговорка про version-resilience: точные строки сверяйте с официальной документацией, версии подбирайте под актуальную LTS.

# macOS — через Homebrew
brew install openjdk        # JDK (Java)
brew install gradle         # Gradle (глобально, для bootstrap новых проектов)
brew install python         # Python 3

# Linux — через пакетный менеджер
sudo apt install default-jdk gradle python3   # Debian / Ubuntu
sudo dnf install java-latest-openjdk gradle python3   # Fedora / RHEL

# Windows — через winget
winget install --id EclipseAdoptium.Temurin.25.JDK
winget install --id Gradle.Gradle
winget install --id Python.Python.3.13

Проверка после установки (в новом окне терминала):

java -version            # например: openjdk version "25"
gradle -version          # например: Gradle 9.5.x
python3 --version        # например: Python 3.13.x

Вариант Б: попросить Claude Code

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

Проверь, установлены ли на моей машине JDK, Gradle и Python 3.
Чего не хватает — поставь через мой пакетный менеджер (Homebrew),
после установки покажи версии: java -version, gradle -version, python3 --version.

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

Какой бы вариант вы ни выбрали, итог один: к моменту, когда начнётся содержательная работа над Commerce OS, на машине должны спокойно отвечать java -version, gradle -version и python3 --version. А как именно они туда попали — руками или силами агента — уже дело вкуса.