Kimi Code — это агент для разработки, который работает в терминале: читает файлы репозитория, предлагает правки, запускает команды и тесты, а изменения и команды по умолчанию выполняет после вашего подтверждения. Ценность такого инструмента определяется качеством постановки задачи и разбора результата, а скорость набора кода играет второстепенную роль. Для небольших и чётко описанных правок схема работает хорошо, для архитектурных решений агент остаётся помощником, а решает человек.
Агент в терминале
По документации, Kimi Code ставится установочным скриптом или через npm и запускается командой kimi в каталоге проекта, а вход выполняется командой /login через OAuth или по API-ключу. По умолчанию чтение файлов агент выполняет без вопросов, а изменение файлов и запуск команд требуют подтверждения.
Инструмент рассчитан на работу внутри проекта: агент ищет по файлам, читает код, планирует шаги и вносит правки. В документации описаны режим планирования (Shift-Tab или команда /plan), возврат к прошлым сессиям, ручное сжатие контекста командой /compact, а также навыки, хуки, подагенты и подключение инструментов по MCP. Данные хранятся в каталоге .kimi-code в домашней папке пользователя.
Представьте проект, где есть функция расчёта скидки, и тест на неё падает при пустой корзине. Разработчик формулирует задачу как «исправить расчёт для пустой корзины, оставив остальную логику прежней, чтобы тест прошёл», просит план и разрешает правку одного файла. Агент предлагает три строки, тесты проходят, а разработчик читает diff и убеждается, что тест остался прежним. Ответственность за слияние остаётся у человека.
От других продуктов Kimi этот отличается назначением. Работу с длинными документами мы описывали в статье про Kimi для длинных документов, подключение через интерфейс — в материале Kimi API в рабочем сервисе, а презентации — в тексте про Kimi Slides. Здесь только код и репозиторий.
Версии, команды и способы входа меняются, поэтому перед внедрением откройте руководство по началу работы с Kimi Code и сверьтесь с ним. Для сравнения подходов к агентам в командной строке полезны статьи про Claude Code для команды и про выбор между Cursor и Claude Code.
Права агента
Агент с доступом к терминалу способен удалить файлы, изменить конфигурацию и отправить код наружу. Поэтому права определяют заранее, до того момента, когда агент попросит подтвердить опасную команду.
| Действие агента | Как устроено по документации | Что решает команда |
|---|---|---|
| Чтение файлов и поиск | Выполняется без подтверждения | Какие каталоги видны агенту: секреты и личные данные вне проекта |
| Изменение файлов | Требует подтверждения | Подтверждать каждую правку или после просмотра плана |
| Запуск команд оболочки | Требует подтверждения | Какие команды допустимы: тесты и линтеры да, удаление и сеть под вопросом |
| Ключи и учётные данные | Хранятся в локальной конфигурации | Где хранить, кто имеет доступ, как отзывать |
| Подключение других провайдеров моделей | Настраивается в файле конфигурации | Какие данные кода уходят какому вендору |
Режимов разрешений три: по умолчанию агент спрашивает про каждое действие, кроме чтения; команда /yolo включает режим «спрашивать при необходимости», где подтверждение остаётся для чувствительных файлов вроде .env и ключей SSH и для опасных команд; команда /auto отключает вопросы полностью, включая чувствительные файлы. На рабочем репозитории держите режим /auto выключенным, а в конфигурации можно задать постоянные правила разрешений и запретов, чтобы реже подтверждать безопасное. Хорошая практика — выделить агенту отдельную рабочую папку или контейнер без доступа к рабочим секретам и без сетевого доступа к продакшену. Тогда худший сценарий ограничен тестовой средой: удалённые файлы восстанавливаются из репозитория, а выполненная команда остаётся вдали от серверов клиентов.
Первая строка таблицы коварна: чтение выполняется без вопросов, и всё, что лежит в каталоге проекта, оказывается доступно агенту, а значит, и модели. Файлы с паролями, ключами и выгрузками клиентов держите вне репозитория или в списке исключений. Работайте в отдельной ветке, чтобы любая правка откатывалась одной командой.
Задача и границы
Хорошая задача для агента имеет понятный результат и проверяемое условие готовности. Плохая звучит как «улучши код» и приводит к правкам в десяти файлах, о которых в задаче речи нет.
- Опишите цель одним абзацем: что должно измениться и по какому признаку вы поймёте, что задача решена, например, какой тест должен пройти.
- Назовите файлы и каталоги, в которых агент вправе работать, и те, которых ему нельзя касаться.
- Попросите сначала план и прочитайте его в режиме планирования: лишние шаги уберите до начала правок.
- Создайте отдельную ветку и убедитесь, что тесты до правок известны вам: какие проходят, какие падали и раньше.
- Разрешайте правки порциями и после каждой просите запустить тесты, вместо накопления изменений до конца.
Перед стартом убедитесь, что проект собирается и тесты запускаются на чистой ветке: иначе ошибки агента смешаются со старыми проблемами. Запишите состояние до начала: какие тесты проходят, сколько занимает сборка, какие предупреждения есть. После правок вы сравните картину и увидите, что именно изменилось.
Размер задачи подбирайте так, чтобы diff умещался в одно внимательное чтение. Если результат растягивается на сотни строк и десятки файлов, разбейте задачу на части: проверять большой diff значительно труднее, и ошибки пролезают именно в него.
Разбор diff
Результат работы агента — набор изменений, и ревью этих изменений остаётся за человеком. Одних зелёных тестов для уверенности мало: агент способен подогнать код под тест или изменить сам тест.
- Сначала смотрите, какие файлы затронуты: список должен совпадать с задачей, лишние файлы требуют объяснений.
- Проверяйте изменения в тестах отдельно: удалённые проверки и ослабленные условия указывают на подгонку.
- Ищите побочные изменения: переименования, форматирование и обновление зависимостей, упомянутые в задаче лишь вскользь или вовсе забытые.
- Читайте конфигурации и скрипты сборки внимательнее кода: именно там чаще всего оказывается опасная правка.
- Запустите тесты и линтер самостоятельно, вместо опоры на отчёт агента о результате.
- Прочитайте журнал команд, которые агент выполнял: он показывает, что реально происходило.
Для критичных изменений сочетайте агента с вторым ревью человеком: агент предлагает, один разработчик пишет задачу, другой проверяет diff. Схему двойного контроля подробнее разбирает материал про ИИ-агентов для бизнеса.
Какую задачу в репозитории вы хотите поручить агенту?
Первая задача
Запишите по итогам первой недели три числа: сколько задач агент закрыл без правок, сколько потребовали доработки и сколько пришлось отклонить. Эти цифры показывают, где он полезен, и защищают от двух крайностей: слепого доверия после удачного случая и полного отказа после первой неудачи.
Возьмите небольшую задачу с готовым тестом: исправление ошибки, добавление проверки, обновление документации. Работайте в отдельной ветке, разрешайте правки по одной и сравните затраты времени с ручным выполнением.
Пробу оценивайте по числу правок, которые потребовал результат, и по времени ревью в сравнении с ручной работой. Если ревью съедает всю выгоду, задачу пока оставляют человеку, а агента применяют к рутине: тесты, документация, мелкие рефакторинги.
Типичная ошибка — дать агенту широкие права на рабочем репозитории с первого дня. Надёжнее наращивать их постепенно: сначала чтение и предложения, затем правки в отдельной ветке, и лишь потом запуск команд. Решения о том, кто и какие права получает, фиксируйте в регламенте для команды; примеры таких регламентов собраны в разделе про внедрение ИИ в компанию.