Почему окружение разработчика для AI — это не просто терминал
Когда Борис Черни начал делиться своим рабочим процессом в Twitter, многие ожидали увидеть список команд и скриптов. Вместо этого получили философию. Идея простая: ваше окружение определяет, насколько эффективно AI может вам помогать.
Представьте, что даёте слепому человеку описывать картину. Он расскажет о фактуре холста, запахе краски, температуре воздуха. Но не увидит сюжета. Так и AI-агент без правильного контекста — он знает синтаксис, но не понимает архитектуру вашего проекта.
Внимание: Claude Code не просто генерирует код. Он анализирует контекст, предлагает архитектурные решения, находит уязвимости. Но только если дать ему достаточно информации.
Сначала ломаем, потом строим: типичные ошибки
Почти все начинают неправильно. Берут AI-ассистента, открывают проект и просят "помочь". Результат предсказуем: агент предлагает косметические правки, не понимая общей картины.
Самая частая ошибка: использовать AI как улучшенный автодополнение. Это в 10 раз медленнее, чем нужно.
Ещё хуже — когда разработчик даёт агенту доступ ко всей системе. Файлы конфигурации, логи, кеши, временные файлы. Шум заглушает сигнал. AI начинает анализировать node_modules вместо вашего кода.
Архитектура идеального AI-окружения
Черни предлагает радикальный подход: создавать отдельные контекстные слои. Как луковица. Каждый слой даёт агенту определённый тип информации.
1Базовый слой: документация проекта
Не README.md. Не комментарии в коде. Речь о живом, постоянно обновляемом документе, который описывает:
- Архитектурные решения и почему они приняты
- Зависимости между модулями
- Историю изменений в архитектуре
- Известные проблемы и их статус
- Планы на будущее развитие
Этот документ — первое, что видит AI при входе в проект. Звучит бюрократично? Это не так. Черни использует простой markdown-файл, который обновляется реже, чем вы думаете. Главное — содержательность.
2Оперативный слой: текущий контекст
Здесь начинается магия. Вместо того чтобы давать агенту доступ ко всем открытым файлам, вы создаёте временный контекст. Что в него входит:
| Элемент | Зачем нужен | Пример |
|---|---|---|
| Текущая задача | Фокусирует агента на конкретной проблеме | "Добавить кэширование запросов к API" |
| Связанные файлы | Даёт понимание интерфейсов | Только те, что непосредственно затрагиваются |
| Ограничения | Предотвращает нерелевантные предложения | "Нельзя менять внешний API" |
| Метрики успеха | Позволяет оценить качество решения | "Время ответа должно уменьшиться на 30%" |
Ключевой момент: этот слой динамический. Он меняется каждые 15-30 минут по мере продвижения по задаче. Не пытайтесь описать всю задачу разом. Разбивайте на подзадачи и обновляйте контекст.
3Технический слой: инструменты и доступы
Claude Code умеет работать с инструментами. Но не все инструменты одинаково полезны. Черни делит их на три категории:
- Обязательные: терминал, git, файловая система. Без этого никак.
- Контекстные: специфичные для текущего проекта (база данных, API-клиенты, системы мониторинга).
- Запрещённые: всё, что может сломать проект (продакшен-базы, системы развёртывания, секреты).
Конкретная настройка: от теории к практике
Вот как Черни настраивает свой рабочий день с Claude Code. Не копируйте слепо — адаптируйте под свои нужды.
Утренний ритуал: подготовка контекста
Первые 10 минут рабочего дня уходят не на проверку почты, а на обновление контекста для AI. Что входит:
- Просмотр завершённых вчера задач (что сделано, что осталось)
- Обновление архитектурного документа, если вчера были значительные изменения
- Подготовка списка задач на сегодня с приоритетами
- Проверка, какие инструменты понадобятся для каждой задачи
Это кажется избыточным, пока не попробуете. Разница в продуктивности — в 3-5 раз. Потому что AI не тратит время на понимание, что происходит. Он сразу начинает работать.
Рабочие сессии: диалог, а не монолог
Большинство разработчиков делают так: дают задачу AI, ждут полного решения, проверяют. Черни называет это "лотереей". Иногда везёт, обычно нет.
Вместо этого он использует итеративный подход:
- Даёт небольшую подзадачу ("напиши функцию-хелпер для валидации email")
- Проверяет результат сразу
- Даёт feedback ("хорошо, но добавь поддержку международных доменов")
- Переходит к следующей подзадаче
Каждая итерация — 5-10 минут. Задача разбивается на десятки таких микро-итераций. Почему это работает? AI лучше справляется с чёткими, ограниченными задачами. И вы остаётесь в контексте, не отдаляясь от кода.
Интеграция с существующим стеком
Claude Code не существует в вакууме. Черни интегрирует его с:
| Инструмент | Как интегрируется | Выгода |
|---|---|---|
| Cursor | Как основной редактор для AI-взаимодействия | Единый интерфейс для всех AI-агентов |
| Локальные LLM | Для задач, не требующих Claude Code | Экономия на API-вызовах, конфиденциальность |
| Системы мониторинга | AI получает доступ к метрикам производительности | Решения основаны на реальных данных, а не предположениях |
Особенно интересна интеграция с локальными моделями. Как запустить Claude Code локально — отдельная большая тема. Но суть в том, что для рутинных задач (рефакторинг, документация, тесты) не нужна тяжёлая артиллерия в виде Claude 3.5 Sonnet.
Психологические аспекты: как не сойти с ума
Работа с AI-агентом полного цикла меняет не только процесс разработки, но и ваше мышление. Черни отмечает несколько опасных паттернов:
Опасность №1: делегирование мышления. Вы начинаете полагаться на AI даже в простых архитектурных решениях. Результат — теряете понимание системы.
Как бороться? Черни использует правило "30%". Не более 30% времени разработки проходит в диалоге с AI. Остальное — самостоятельное мышление, проектирование, ревью кода.
Опасность №2: иллюзия продуктивности. AI генерирует код с невероятной скоростью. Кажется, что работа идёт в 10 раз быстрее. Но часто этот код требует значительного рефакторинга, который съедает всю выгоду.
Решение: метрики качества, а не количества. Не "сколько строк кода сгенерировано", а "сколько задач закрыто без последующих багов".
Специфичные для Claude Code фишки
Claude Code имеет особенности, которые отличают его от других AI-агентов. Черни использует их максимально:
- Длинный контекст: 200K токенов — это не просто большая цифра. Это возможность загружать десятки файлов одновременно. Но не нужно загружать всё подряд. Только связанные файлы.
- Понимание архитектуры: Claude Code действительно понимает паттерны проектирования. Можно обсуждать не просто "как сделать функцию", а "какой паттерн лучше подойдёт для этой задачи".
- Работа с устаревшим кодом: Агент умеет анализировать легаси-код и предлагать пути модернизации. Но тут нужна осторожность — иногда лучше полная переписывание, чем постепенный рефакторинг.
Когда НЕ использовать Claude Code
Парадоксально, но иногда лучше работать без AI. Черни выделяет три ситуации:
- Изучение новой технологии: Нужно пройти через боль самостоятельного освоения. Иначе останется поверхностное понимание.
- Критически важная бизнес-логика: Код, от которого зависит вся система. Здесь нужен человеческий контроль на каждом шаге.
- Коммуникация с командой: AI не заменит обсуждения архитектуры с коллегами. Разные перспективы важнее скорости.
Будущее: куда движется AI-разработка
Черни считает, что текущая модель работы с Claude Code — лишь первая итерация. В будущем мы увидим:
- Специализированные агенты для разных типов задач (frontend, backend, DevOps)
- Автоматическое обновление контекста на основе изменений в коде
- Интеграцию с системами CI/CD для предсказания последствий изменений
- Совместную работу нескольких AI-агентов над одной задачей
Уже сегодня можно комбинировать разные подходы. Например, использовать стек Claude 4.5 + Cursor + GPT 5.2 для разных этапов разработки. Или строить production-ready AI-агентов для специфичных задач.
Но самое важное — сохранить баланс. AI должен усиливать ваши способности, а не заменять их. Как говорит Черни: "Лучший AI-разработчик — это не тот, кто умеет лучше всех промптить. Это тот, кто знает, когда промптить не нужно".
Попробуйте его подход. Настройте окружение. Разбейте задачу на слои. Работайте итеративно. Первые дни будут неудобными — вы будете тратить больше времени на подготовку, чем на кодирование. Но через неделю поймёте: вы не просто пишете код быстрее. Вы пишете лучший код. И понимаете его лучше, чем когда-либо раньше.
