EE-VibeCoding

AICodeGuide: как начать писать код с ИИ

AICodeGuide: как начать писать код с ИИ

Всё, что вы хотели знать об использовании ИИ, чтобы помогать себе писать код и/или чтобы он писал код за вас.

Введение

Способ, которым мы взаимодействуем с компьютерами и пишем для них код, меняется. И это глубокое изменение: меняются инструменты, способы кодинга, само мышление о программных продуктах и системах.

И всё меняется очень быстро! Новые LLM-модели выходят каждую неделю. Новые инструменты, новые редакторы, новые практики AI-кодинга и «вайбкодинга», новые протоколы: MCP, A2A, SLOP... И за всем этим очень трудно уследить. Всё разбросано по разным местам: сайты, репозитории, видео и так далее.

Именно поэтому мы решили написать это руководство. Это наша скромная попытка собрать всё вместе и показать вам практики и инструменты вокруг AI-кодинга (или AI-assisted code generation — генерации кода с помощью ИИ) в одном месте, без лишнего шума, в доступной форме.

  • Если вы программист, но пока не используете ИИ-ассистентов для кода, это руководство для вас: оно показывает самые свежие инструменты и хорошие практики, чтобы выжать из них максимум в повседневной работе. И как ИИ-копilot для вас, и как вы — «второй пилот» для ИИ-агента.
  • Если вы никогда не программировали, но заинтересовались «вайбкодингом», чтобы собрать свой SaaS или другой программный продукт, это руководство точно для вас: мы постараемся убрать всю загадочность и оставить только необходимое для старта, при этом жёстко отделяя действительно важное от «просто хайпа».

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

Как я уже сказал, ИИ меняется ежедневно. Мы стараемся поддерживать руководство актуальным, но если вы нашли что-то упущенное — смело предлагайте исправление, создавайте issue или просто поделитесь находкой.

Поехали!

AI-кодинг? Вайбкодинг? Агентный кодинг?

Все эти термины довольно похожи. По сути, AI-кодинг — это использование ИИ-моделей (прежде всего LLM в наши дни) и всей сопутствующей инфраструктуры, чтобы помогать вам писать ПО. Это также называют «генерацией кода ИИ» или просто «code gen». Существует целая увлекательная область исследований и инженерии, ведущая начало с 1950-х, когда Lisp использовали для генерации кода. Сейчас LLM — главные движки генерации кода, а также появляются ростки нейросимволических гибридных подходов. AI-кодинг — это ещё и практика: если вы пользуетесь Cursor и таб-таб-табом получаете автодополнения — вы «AI-кодите»; если вы полностью используете агентный режим Codex — вы тоже «AI-кодите». В общем: это любой способ применить ИИ-модели, чтобы сгенерировать код.

Используете ли вы ИИ, чтобы обсуждать идеи ПО или помогать кодить только части существующей кодовой базы, полностью ли вы в вайбкодинге, или запустили одного или сто агентов, работающих 24/7 без вмешательства — во всех случаях вы используете ИИ для генерации кода. Назовём это AI-кодингом и поедем дальше.

Как этим пользоваться?

AI-кодинг можно использовать множеством способов, но в двух словах:

  • ИИ — ваш копilot: вы используете ИИ-модели, чтобы усилить себя и поднять продуктивность. Либо запускаете ChatGPT для брейншторма идей для SaaS; либо используете Cursor для автодополнения докстрингов. Здесь много выгоды, особенно для творческого поиска и автоматизации скучных частей работы.
  • ИИ — пилот: здесь вы — второй пилот. Это и есть место, где происходит «вайбкодинг». Вы включаете агентный режим YOLO в Cursor или запускаете Claude Code с флагом --dangerously-skip-permissions и доверяете агентам генерировать ваш код. Это очень мощный способ автоматизировать себя, но требует хороших практик проектирования систем, умения «приручать» агентов и готовности нырять в спагетти-код, который вы на самом деле не знаете — особенно для исправления ошибок.

Стоит учиться и практиковать оба подхода!

Но по мере роста сложности проекта склоняйтесь больше к роли копилота и дальше от чистого YOLO-вайбкодинга. Чем вероятнее, что другой человек (или вы сами через полгода) будет сопровождать этот код, тем это важнее.

🗺️ Дорожная карта

С чего начать?

  • Если вы не умеете программировать и хотите поиграться, рекомендуем начать с веб-инструмента вроде Bolt, Replit, v0, Suuper или Lovable.
  • Если вы уже умеете программировать, установите Claude Code, Codex, Cursor, Amp или Windsurf. Можно начать с бесплатного плана и потом перейти на план за $20 в месяц. Тарифы Claude Code Pro, Codex и Cursor довольно хороши и дёшевы, учитывая, что вы получаете тонны токенов для самых свежих LLM-моделей. У VSCode тоже есть свой Agent Mode: он работает с ИИ-ассистент Copilot и использует агентный воркфлоу для изменений и правки файлов.
  • Если хотите более открытую альтернативу, попробуйте Pi (рекомендуем), OpenCode или OpenHands.
Совет: настоятельно рекомендуем создать аккаунт в агрегатор моделей. Это очень просто, а вы получите доступ к самым свежим LLM-моделям, включая бесплатные версии.
Важное замечание: использование Claude Code через их API/SDK — очень дорого! Можно легко сжечь сотни долларов в день, не заметив. Поэтому рекомендуется начинать с тарифов Claude Code Pro или Max, чтобы не переживать об этом. Если вам действительно нужен API/SDK (встроить в приложение или другой случай), следите за расходом на дашборде Anthropic.

Как я промпчу для кодинга? Или: как я вайбкожу?

До середины-конца 2025 года LLM часто галлюцинировали и входили в бесконечные циклы исправления ошибок. Сейчас модели очень хороши, но всё равно полезно следовать базовым принципам при использовании их для кода:

  • Не задавайте всё в одном промпте. Просто «эй, сделай мне приложение для моего зоомагазина» не помогает инженеру и тем более ИИ :-) Поймите свой проект, сделайте сначала брейншторм с LLM, создайте PRD (документ требований к продукту), составьте план и разбейте его на задачи. Ниже есть рецепт, как с помощью ChatGPT создать PRD.
  • Давайте детали. Если вы знаете, чего хотите, — говорите. Если знаете язык программирования, стек, аудиторию — добавьте это в промпт.
  • Markdown или любой другой лёгкий текстовый формат вроде asciidoc — норм для интерпретации LLM. В конце концов текст кодируется в токены. Однако, чтобы расставить акценты в конкретных частях промпта, рекомендуют использовать символы вроде XML-тегов.
  • Разбивайте проект на задачи и подзадачи. Помните, что хорошие практики разработки всё ещё важны. Думайте об агенте как о «джуниоре, которого вы только что наняли»: какую информацию вы написали бы в PR, чтобы максимизировать шанс его принятия?
  • Пробуйте разные модели под разные цели. Например, Opus или ChatGPT хороши для планирования, а Sonnet или опенсорсные модели вроде Kimi или Minimax — для реализации плана.
  • Пробуйте разные модели, чтобы подтверждать и валидировать вывод других моделей. Можно даже запускать их параллельно и выбирать лучший!
  • LLM — это «машины согласия», поэтому применяйте критическое мышление. Не принимайте всё, что они вам присылают. Проверяйте, тестируйте. В конечном счёте это просто инструмент, и ответственность за код несёте вы.

В примерах ниже мы используем расширение .md для Markdown. Если предпочитаете asciidoc (у него несколько лучшая поддержка структурированных документов) — используйте его и заменяйте «.adoc» там, где встретите .md. LLM всё равно: они обработают и Markdown, и asciidoc, и любой другой чисто текстовый формат.

Вот метод/процедура/стратегия/воркфлоу, который в целом хорошо работает:

  • Используйте ChatGPT, Codex или сам Claude Code с таким промптом:
Ты — старший инженер-программист. Мы вместе будем строить PRD проекта.

ОЧЕНЬ ВАЖНО:
- Задавай по одному вопросу за раз
- Каждый вопрос должен опираться на предыдущие ответы
- Углубляйся в каждую важную деталь

ИДЕЯ:
<вставьте сюда свою идею>
  • Вы войдёте в цикл вопросов/ответов на несколько минут. Отвечайте как можно подробнее. Когда закончите (или решите, что достаточно), отправьте промпт, направляющий модель на компиляцию всего в PRD (это также называют SDD — Spec-Driven Development, разработка от спецификаций):
Собери находки в PRD. Используй формат markdown. Документ должен содержать разделы:

- Обзор проекта
- Ключевые требования
- Ключевые функции
- Ключевые компоненты
- Пользовательский/приложенческий поток
- Технологический стек
- План реализации
  • Скопируйте и сохраните файл в docs/specs.md внутри папки проекта.
  • Теперь создадим список задач. Спросите:
На основе сгенерированного PRD создай детальный пошаговый план построения этого проекта.
Затем разбей его на небольшие задачи, которые опираются друг на друга.
На основе этих задач разбей их на более мелкие подзадачи.
Убедись, что шаги достаточно малы, чтобы реализовать их за один шаг, но достаточно велики,
чтобы успешно завершить проект.
Используй лучшие практики разработки и управления проектами, без больших скачков сложности.
Свяжи задачи друг с другом, создав список зависимостей. Не должно быть задач-сирот.

ОЧЕНЬ ВАЖНО:
- Используй markdown или asciidoc
- Каждая задача и подзадача — элемент чек-листа
- Дай каждой задаче достаточно контекста, чтобы разработчик смог её реализовать
- Каждая задача должна иметь числовой id
- Каждая задача должна перечислять id зависимых задач
  • Сохраните как docs/todo.md в папке проекта.
  • Также очень важно иметь файл AGENTS.md (или CLAUDE.md, если вы используете Claude Code) в корне репозитория. Относитесь к нему как к «README для агентов»: так же, как вы храните README.md для людей, держите AGENTS.md для будущих агентов, которые будут читать и редактировать ваш проект! Важное содержимое: краткое описание проекта, используемый стек, как установить, как тестировать, деплоить и запускать проект, где лежат PRD/specs/дизайн и другая документация, а также основные файлы исходников. Больше про AGENTS.md и примеры — на agents.md.

Вот пример сессии брейншторма/планирования с ChatGPT 4o для простого CLI-инструмента — используйте его как вдохновение для своего.

Теперь создайте локальную папку проекта, установите и запустите git init внутри, чтобы держать проект под контролем версий.

Всё это даст вам PRD и списки задач для сборки проекта! Имея их, вы можете запустить Codex (или другого ИИ-код-агента), указать ему на эти файлы и попросить:

Ты — старший инженер-программист. Изучи @docs/specs.md и реализуй то, чего ещё не хватает в @docs/todo.md.
Реализуй каждую задачу по очереди и соблюдай зависимости задач и подзадач.
Завершив задачу, отмечай её в списке и переходи к следующей.

Вот CLI-инструмент, собранный за 10 минут по этому воркфлоу.

Важно: хотя «вайбкодить» очень круто, так же интересно понимать, что вы делаете :-) Ревью кода, который генерирует агент, сильно поможет, когда случаются ошибки (а они случатся!) и прокачает ваши навыки код-ревью — не только ИИ-ревью, но и вашего собственного и других разработчиков.

Какую LLM-модель выбрать?

LLM обучаются и выравниваются под разные цели. Модели вроде ChatGPT или Claude тренируются быть хорошими универсальными ассистентами в чате. В других случаях лаборатории снимают вывод модели, запускающей инструменты и «рассуждающей» о результатах в длинных сессиях (от минут до часов), и используют этот фидбек как сигнал награды, выравнивая исходную модель под конкретную задачу. В случае Claude Opus, Sonnet или OpenAI GPT задача — кодинг.

Поэтому важно всегда использовать модели, обученные/выровненные для программирования и поддерживающие инструменты.

Поскольку LLM меняются ежедневно, сейчас невозможно посоветовать конкретную версию модели. Что мы можем — так это сказать, какое «семейство» моделей рассматривать. Сегодня проприетарные модели вроде Claude Opus и OpenAI GPT — SotA (передний край) для AI-кодинга; а опенсорсные модели вроде Kimi, Minimax и GLM всегда чуть позади проприетарных, с каждым релизом сокращая разрыв.

Какую версию выбрать — общий совет: берите самую свежую или проверьте лидерборды для точного сравнения:

  • Открытая база данных ИИ-моделей
  • Модели агрегатор моделей — поставьте категорию programming и отфильтруйте модели с поддержкой tools — обычно хороший способ отбора для AI-кодинга
  • Agent Leaderboard на открытые лидерборды

Что делать, когда прилетает страшное «rate limit»

Переключитесь на другую модель.

Причин как минимум две: либо ваш тяжёлый запрос превысил лимит входных/выходных токенов модели, либо у серверного кластера плохой день, и вас троттлят для снижения нагрузки. Сообщения об ошибках часто не прозрачны в этом вопросе.

У разных моделей сильно разные лимиты токенов. Например, gpt-4.1-mini гораздо щедрее, чем gpt-4.1. Держите при себе несколько ключей API (это дёшево — вы платите по факту) и читайте страницы с описанием лимитов. Пример — страница лимитов Anthropic.

Как настроить правила для всего проекта?

Можно задать правила или конвенции, которые будут применяться к вашему проекту, «впрыскивая» их в контекст LLM. У каждого редактора свой способ:

  • Почти для любого агента, кроме Claude Code, создайте файл AGENTS.md в корне проекта. На agents.md есть информация о том, как его создавать, и примеры.
  • Для Claude Code создайте CLAUDE.md в корне. Anthropic не пошла по стандарту AGENTS.md, поэтому хорошая практика — создать AGENTS.md, а затем сделать символьную ссылку CLAUDE.md на AGENTS.md. Либо создать CLAUDE.md с содержимым @AGENTS.md.
  • В Cursor создайте markdown-файлы в папке .cursor/rules/. Cursor гарантированно применяет их во всех коммуникациях с LLM.
  • В Aider создайте markdown-файлы с конвенциями (например, rules.md) и добавьте в .aider.conf.yml строку: read: rules.md.

Также многие инструменты поддерживают файл правил/конвенций в домашней директории, применяемый ко всем проектам. Например, в Aider можно создать глобальные конвенции в ~/.global_conventions.md и добавить в .aider.conf.yml: read: [~/.global_conventions.md, rules.md].

Часть PRD можно добавить как правила — например, технологический стек или гайдлайны по форматированию и стилю кода.

Правила очень мощны, и можно даже попросить сам ИИ создать правила для вас!

Как избежать галлюцинаций? Что такое PRD?

PRD. Что?! Говорят, лучший способ решить проблему в инженерии — создать новый акроним, и здесь не исключение :-) Шучу... PRD — это Product Requirements Document (документ требований к продукту). По сути, это набор документов (или один документ), описывающий требования и другие детали вашего ПО-проекта.

Оказывается, если оставить любимую LLM свободной, без должного контекста о том, что делать, она быстро и лихо нагаллюцинирует. Зверя нужно приручать, и PRD — отличный способ.

Больше всего в PRD мне нравится то, что они полезны всем: от людей, никогда не кодивших, до старших инженеров и продакт-менеджеров.

Для старта PRD не нужен никакой бэкграунд — нужна только идея приложения. Но очень помогают основы проектирования ПО и детали о стеке/фреймворке, который вы используете или планируете.

Как использовать LLM для создания PRD — см. раздел «Как я промпчу для кодинга».

Ведите лог промптов

Записывайте каждый отправленный промпт с (это важно) вашими комментариями о том, о чём вы думали, и неожиданностями, которые получили. Этот лог промптов — запись ваших дизайн-намерений; он будет бесценен для любого, кто подойдёт к проекту без участия в нём, включая вас через полгода, когда вы забудете, о чём думали.

Единого соглашения об имени файла пока нет — можно использовать что-то вроде vibecode.adoc или history.md.

Инструменты вроде Aider хранят лог всех ваших диалогов с LLM. Поэтому один из вариантов — задать переменные окружения и держать все файлы истории под контролем версий:

# Файлы истории:

## Файл истории ввода в чат (по умолчанию: .aider.input.history)
#AIDER_INPUT_HISTORY_FILE=.aider.input.history

## Файл истории чата (по умолчанию: .aider.chat.history.md)
#AIDER_CHAT_HISTORY_FILE=.aider.chat.history.md

## Лог разговора с LLM в этот файл (например, .aider.llm.history)
#AIDER_LLM_HISTORY_FILE=.aider.llm.history

Имея эти файлы, можно комментировать их собственными мыслями по ходу. Вы (и другие) много узнаете о проекте, вернувшись к нему в будущем, и начнёте замечать паттерны и приёмы для следующих сессий.

Агентные обвязки вроде Pi или Amp тоже позволяют хранить и шарить сессии кодинга. В Pi для этого наберите /share — он создаст Git-gist и сгенерирует удобный URL для визуализации.

Как начать проект?

Веб-приложение (фронтенд)

Современная веб-разработка ошеломляет. Тонны JavaScript/TypeScript фреймворков, CSS-фреймворков, движков, сервисов деплоя — очень трудно стартовать и решить, что использовать. Потратив последние месяцы на фронтенды, вот что я обычно советую:

  • TanStack Start: мощный React-фреймворк, вы свободны от Vercel и любого другого провайдера, можно деплоить куда угодно.
  • Next.js: по-прежнему самый популярный React-фреймворк, но вы зависите от экосистемы Vercel — и это хорошо, и плохо.
  • FastHTML: если любите Python и вам важнее выставить наружу ядро бэкенда (анализ данных, ИИ/ML-пайплайн), чем супер-красивый UI.

Если вы пишете и бэкенд, держите в корне Git-репозитория две папки — backend и frontend; или держите разные репозитории и добавьте их в один workspace в Cursor (чтобы фронтенд-агент мог ссылаться на файлы бэкенда и наоборот), или запускайте Claude Code и другие CLI-обвязки в корне.

Чтобы не интегрировать фронтенд с бэкендом слишком рано, поручите ИИ-агенту использовать mock/заглушечные данные, чтобы обновить их позже, когда бэкенд будет реализован.

Ещё один интересный приём — хорошие MCP-инструменты для интеграции вашего код-агента с Playwright или browser-use. Так вы избежите цикла копипасты ошибок из браузера в агента: ИИ сам управляет браузером, делает скриншоты и забирает сообщения об ошибках. Можно и через bash-команды, если вы, как я, не любите MCP.

Если в веб-приложении нужен 3D-контент и вы на React, интереснее использовать React Three Fiber, чем напрямую three.js: R3F проще работать с состоянием, оборачивая объекты three.js в React-компоненты.

Бэкенд

Бэкенды не гибки и плохо масштабируются в веб-инструментах вроде Lovable. Так что, скорее всего, придётся браться за Claude Code, Codex или другой не-веб инструмент.

Python + FastAPI — отличный вариант. Если предпочитаете тот же язык, что и во фронтенде (обычно JavaScript или TypeScript), используйте Node.js или Bun. Для большинства API-потребностей фронтенда на TanStack или Next.js подойдут Server Functions (или Server Actions) — отдельный бэкенд не нужен.

Бэкенды — отличная цель для end-to-end тестов, так что направляйте агента писать тесты и запускать их для каждой новой фичи и её подзадач.

Когда бэкенд готов, используйте его документацию (особенно по HTTP-endpoint'ам) как входные данные для агента, работающего над фронтендом. Так фронтенд перейдёт с моков на реальные данные бэкенда.

Игра

Для небольших игр используйте ванильный JS в одном .js-файле: three.js для 3D-игр или pixijs для 2D.

В играх всё решают хорошие ассеты, поэтому рассмотрите сервисы вроде Tripo AI и Everything Universe для генерации 3D-ассетов, риггинга и анимации.

Как работать с ошибками и багами?

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

Первая стратегия — повторять то, что делают инженеры: посмотрите на сообщение об ошибке, которое дал интерпретатор/компилятор, и постарайтесь понять его. Скопируйте ошибку обратно в LLM и попросите исправить.

Ещё одна отличная идея — добавить MCP-инструменты для отладки, например BrowserTools, или подключить Claude Code / других агентов к вашему локальному Chrome. Также можно использовать headless-браузеры через Playwright в удалённой разработке или если не хотите трогать ваш локальный Chrome.

Что такое MCP, SLOP и A2A и как мне от них польза?

Обновление марта 2026: сегодня мы знаем, что дать агенту bash как инструмент — в целом достаточно как альтернатива MCP: агент может через curl вызывать API или выполнять другие команды, и это эффективнее (например, расходует намного меньше токенов). Но MCP всё ещё интересен для некоторых сценариев.

MCP — это Model Context Protocol (протокол контекста модели). Его разработала Anthropic, но его начинают рассматривать и другие LLM-экосистемы — OpenAI GPT, Google Gemini. Это мощная концепция, тесно связанная с другой: вызов функций/инструментов (function/tool calling).

Вызов инструментов — это способ для LLM вызывать инструменты или функции для выполнения операций. Это способ обновить окно знаний LLM (обученной на исторических данных) свежей информацией и одновременно интегрировать её с внешними инструментами и endpoint'ами. Например, если нужно поискать информацию в вебе, вы можете указать LLM использовать инструмент: «эй, если тебе нужно что-то поискать в вебе, используй этот инструмент: search(term)». Тогда вместо траты многих токенов, итераций и работы по парсингу, LLM вызовет инструмент, получит вывод и использует его при генерации новых предсказаний для вас.

MCP расширяет эту идею, создавая стандарт. Так мы можем создать MCP-сервер, который откроет LLM какой-то ресурс (например, базу данных) или инструмент (кусок ПО, который что-то вычисляет и возвращает результат).

Погодите, это же просто API? Нельзя ли то же самое через REST API сервер/клиент и немного парсинга в промптах? Вроде да — именно это и предлагает SLOP (Simple Language Open Protocol). Однако наличие стандарта вроде MCP гарантирует нативную поддержку LLM без дополнительного парсинга и трюков на стороне клиента.

A2A (Agent to Agent Protocol) создан Google, чтобы «дополнить» MCP: он фокусируется на коммуникации между агентами, тогда как MCP — на коммуникации LLM с инструментами.

Ещё момент: если вы используете обвязку вроде Pi, не поддерживающую MCP, — не проблема: оберните ваш любимый MCP-инструмент в CLI и позвольте Pi вызывать его через bash. Для этого подойдёт mcporter.

Начинать с нуля или с шаблона (boilerplate)?

Как правило, LLM лучше работают с чистого листа. Но можно начать и с boilerplate (стартовый набор: папка с начальными скелетами минимальных файлов исходников и конфигов, нужных для запуска проекта на конкретном стеке) и добавить правила в контекст, чтобы агент уважал ваш стартовый набор.

Ещё одна отличная идея — проиндексировать свой проект (только что созданный из стартового набора) встроенной индексацией Cursor или инструментами вроде repomix или files-to-prompt.

Новый проект с нуля против существующей кодовой базы

Если у вас есть существующая кодовая база, хорошая идея — упаковать её в контекст с помощью repomix или files-to-prompt.

Ещё один совет — промптить изменения на уровне задач, а не на уровне проекта. Например, сфокусируйтесь на одной фиче и попросите агента Cursor реализовать её. Дайте мини-PRD под конкретную фичу. Представьте, что вы ведёте джуниора за руку в конкретном тикете :-)

Хорошо структурированный промптинг для хорошо структурированного дизайна

Сейчас (с апреля 2025) LLM уже хорошо генерируют рабочий код, но не очень хорошо — код со здоровой структурой: с правильными слоями и разделением ответственности. Хорошая структура важна для читаемости и поддерживаемости и снижает частоту дефектов.

Продумайте дизайн, а затем промпт-инженерите его в последовательности, дающей хорошую структуру. В приложении с базой данных, например, стоит сначала задать типы записей, затем вести LLM к созданию менеджер-класса или модуля, инкапсулирующего доступ к ним. И только после этого начинать промптить бизнес-логику.

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

Включите в правила проекта правило о том, что LLM не должна нарушать слоистость: если нужен новый метод движка, добавлять его нужно в чистый инкапсулирующий слой, а не опутывать низкоуровневые детали реализации с бизнес-логикой.

Ещё одна интересная практика — начать с ядра проекта и потратить время на то, чтобы главный функционал был реализован и организован так, как вы хотите. Можно даже написать скелеты классов и функций, а затем позволить LLM заполнить пробелы. И только получив хороший фундамент с хорошими тестами, переходить к потребителям этой библиотеки ядра — например, выставлять её как CLI или REST API для будущего веб-приложения.

Нужно ли использовать TDD или другие виды тестов?

Да, однозначно да. Тесты важнее, чем когда-либо. При текущем состоянии дел (2026) LLM хорошо генерируют чистый и корректный код, но иногда галлюцинируют и, что важнее, могут неверно понять спецификации и сгенерировать корректный код, делающий неправильную вещь.

Вряд ли это изменится, даже если мы получим полный ИИ на уровне человека — в конце концов, люди тоже неверно понимают спецификации! Неоднозначность языка — причина, по которой тесты останутся важными и в будущем.

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

Тесты фундаментальны для роста кодовой базы вместе с LLM: двигаться вперёд, только когда все текущие тесты проходят.

Свойственные тесты (property-based tests) очень интересны в работе с LLM. Тестирование целого домена/диапазона значений вместо конкретных, которые вы указали, гарантирует, что код агента останется валидным, даже если позднее изменения попадут в ошибочные краевые случаи, о которых вы заранее не думали. Хорошие библиотеки есть в каждом языке: hypothesis для Python или fast-check для JavaScript/TypeScript.

Также важно всегда проверять код, который LLM генерирует при написании или исправлении теста: иногда она попытается сгенерировать захардкоженный вывод, лишь бы тест прошёл :-)

Как сделать это безопасно?

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

  • Не доверяйте коду, сгенерированному ИИ. Всегда проверяйте. Помните: ИИ не будет отвечать за код, который вы запускаете в проде — ОТВЕЧАТЬ БУДЕТЕ ВЫ!
  • Не храните ключи API и другие секреты захардкоженными строками, особенно во фронтенд-коде. Храните на бэкенде в защищённых переменных окружения (платформы вроде Vercel дают такую опцию).
  • При запросах к API всегда используйте HTTPS.
  • В HTML-формах всегда делайте валидацию ввода и санитизацию.
  • Не храните чувствительные данные в localStorage, sessionStorage или cookies.
  • Запускайте валидаторы и сканеры уязвимостей по вашим зависимостям.

Как использовать любую LLM в Claude Code?

Хотите попробовать Kimi K2 или другую LLM в CLI Claude Code? Используйте claude-code-router, чтобы CLI Claude Code работал через «прокси» локально на вашей машине и маршрутизировал запросы к любой модели агрегатор моделей! Инструкции ниже для Kimi K2, но можно адаптировать под любую LLM.

Сначала создайте аккаунт на агрегатор моделей и получите API-ключ.

Убедитесь, что CLI Claude Code установлен:

npm install -g @anthropic-ai/claude-code

Затем установите claude-code-router:

npm install -g @musistudio/claude-code-router

Добавьте в ~/.claude-code-router/config.json следующие строки, заменив API_KEY своим ключом агрегатора:

{
 "Providers": [
 {
 "name": "kimi-k2",
 "api_base_url": "https://api.example.com/v1/chat/completions",
 "api_key": "API_KEY",
 "models": [
 "moonshotai/kimi-k2"
 ],
 "transformer": {
 "use": ["api"]
 }
 }
 ],
 "Router": {
 "default": "kimi-k2,moonshotai/kimi-k2"
 }
}

Теперь запустите Claude Code через роутер:

ccr code

Вы должны увидеть API Base URL: http://127.0.0.1:3456 — значит, CLI использует локальный прокси, созданный claude-code-router. Вот и всё!

Если вам интересна только Kimi K2 или другие модели Moonshot, альтернатива — использовать модель напрямую от Moonshot.

Как создать своего ИИ-код-агента?

Лучшее введение — практический туториал Торстена, где вы шаг за шагом строите простого агента на Go с минимальным набором инструментов (list_files, read_file, edit_file).

Я также написал туториал, как создать своего собственного ИИ-код-агента — всего 150 строк Python, дающий представление о том, что происходит под капотом агентной обвязки.

Если хотите глубже — серия открытых книг от Гэрреда — отличный старт.

Что за мультиагентная оркестрация?!

Примерно в 2024-2025 годах люди начали заигрывать с идеей запускать не одного, а целую команду агентов для выполнения задачи кодинга. К концу 2025 года сообщество создало первые реализации этой концепции. Gas Town — пожалуй, самая популярная на данный момент. В Gas Town есть агент Mayor (мэр), получающий задачу от пользователя и разбивающий её на работы (храня и управляя ими в Beads — другом инструменте Yegge; думайте о нём как о «Git issues для агентов»). Mayor общается с другими агентами (например, Polecats — работниками) сообщениями: у каждого агента свой почтовый ящик, и он действует, когда приходит сообщение.

Есть и другие воплощения мультиагентной оркестрации: Claude Flow и Loom, но пока слишком рано говорить, станет ли это тем способом, которым мы будем разрабатывать ПО в будущем. Важно играться с ними и понимать их внутренности, но один маленький совет: запуск Gas Town и подобных систем довольно дорог — эти параллельно работающие агенты могут съедать тонны токенов за секунды.

  • Welcome to Gas Town
  • The Future of Coding Agents
  • Gas Town Emergency User Manual

✨ Советы и трюки по инструментам и агентам

Claude Code

  • Claude Code Guide — покрывает каждую обнаруживаемую команду Claude Code, включая функции, которые малоизвестны или не описаны в базовых туториалах.

🛠️ Инструменты

Здесь мы держим обновляемый список основных инструментов вокруг AI-кодинга. Большинство мы протестировали, и вы найдёте наше честное мнение на момент тестирования.

Редакторы / IDE

  • Cursor
  • Windsurf
  • Cline
  • OpenHands
  • Devin
  • VSCode + ИИ-ассистент Copilot
  • Amp
  • Kiro

CLI

  • Claude Code
  • OpenAI Codex
  • Pi
  • opencode
  • Gemini CLI
  • Aider
  • Claude Engineer
  • Roo Code
  • Codebuff

Веб-приложения

  • Bolt
  • v0
  • Replit
  • Suuper
  • Lovable
  • Firebase Studio

Фоновые/удалённые агенты

  • ZenCoder
  • CodeRabbit
  • Factory AI
  • OpenAI Codex (чат)

Полезные инструменты

  • Specstory
  • Claude Task master
  • CodeGuide
  • repomix
  • files-to-prompt
  • repo2txt
  • stakgraph
  • Repo Prompt
  • Uzi
  • Claudia