VladLoop

Месяц назад написал «Skills, Agents и Commands в Claude Code: когда что юзать». Разложил по полочкам, получил лайки. Думал, разобрался.

Потом полез в доки Anthropic, в чужие конфиги, в собственный .claude/ и понял, что тот пост был верхушкой айсберга. А под поверхностью хаки, паттерны и архитектурные решения, о которых нигде толком не пишут.

Дальше всё, что накопал за месяц экспериментов.

Я думал, что разобрался

В том посте я дал простую схему: Commands для повторяемых задач, Skills для автоматического подхвата, Subagents для изоляции контекста. Звучит логично. Работает.

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

• «Поэтапное раскрытие» – скиллы загружаются не целиком, а по частям: сначала только название и описание, потом полный файл, потом вспомогательные ссылки. Экономит токены на порядок.

• Context engineering – управление тем, что именно попадает в контекстное окно модели, в каком порядке и в какой момент.

• Hooks – автоматические shell-скрипты, которые срабатывают на события в сессии Claude (сохранение файла, завершение задачи, старт сессии).

• Степени свободы – насколько подробно расписывать инструкции: дать модели общую цель и отпустить или прибить каждый шаг гвоздями.

Это штуки, которые влияют на счёт за токены и на то, насколько адекватно агент выполняет задачи.

«Поэтапное раскрытие»: почему каждый токен на счету

Когда только начинал со Skills, думал: пишешь SKILL.md, и готово. Оказалось, Anthropic сделали трёхуровневую систему загрузки. Работает как принцип «загружай только когда нужно, а не всё заранее».

Уровень 1: метаданные. При старте сессии Claude загружает только name и description из YAML-шапки каждого скилла. Это ~50 токенов на скилл. Можно иметь сотню скиллов, и они почти не отъедают контекст.

Уровень 2: SKILL.md. Если Claude решает, что скилл релевантен задаче, читает полный SKILL.md. Это ~500 токенов. Anthropic рекомендуют держать его до 500 строк.

Уровень 3: reference-файлы. SKILL.md ссылается на отдельные файлы (FORMS.md, API-справочник, примеры), и подгружаются только по необходимости. Это уже 2000+ токенов, но только когда действительно нужны.

Anthropic прямо говорят: challenge every token. Каждый параграф в SKILL.md должен оправдывать своё присутствие. Claude и так умный, не надо объяснять ему, что такое PDF или как работают библиотеки Python.

Ещё нюанс, который я не сразу понял: именование скиллов в форме герундия (глагол+ing), вроде processing-pdfs или analyzing-spreadsheets, не стилистическая прихоть. Такой формат помогает Claude быстрее понять, к какой активности относится скилл, и точнее выбирать его при автоматическом подхвате. А описание (description) обязательно от третьего лица, потому что оно инжектится в системный промпт и первое лицо ломает механизм обнаружения.

И важное ограничение: ссылки из SKILL.md на внешние файлы должны быть не глубже одного уровня. Если SKILL.md ссылается на advanced.md, а тот на details.md, Claude может прочитать details.md не полностью (например, только первые 100 строк через head). Вся критически важная информация должна быть доступна в один клик от корня.

Subagents: не изоляция, а архитектура контекста

Ранее я описал Subagents как «отдельных AI-специалистов с собственным контекстом». Это правда, но неполная.

Вот что я упустил: разные субагенты по-разному работают с контекстом. Explore-агент стартует с чистого листа, и это осознанное решение. Поисковые задачи обычно независимы от текущего разговора, а промежуточные результаты поиска (кучи файлов, grep-выводы) только засоряют основной контекст. А вот general-purpose и plan агенты наследуют полный контекст родительской сессии, потому что им нужно понимать, о чём вы уже договорились.

При проектировании агента нужно сделать выбор: где свежий взгляд полезнее, а где важна преемственность.

Допустим, вы строите систему ревью кода. Можно сделать code-reviewer на sonnet, он дешевле, для стандартных проверок хватает. Отдельно security-auditor, тоже на sonnet, но с другим промптом и изолированным контекстом, чтобы его выводы не смешивались с обычным ревью. А главный агент на opus координирует обоих и принимает финальное решение.

В своих проектах в основном пробую стандартные паттерны:

Verifier – скептик, который проверяет, что заявленная работа действительно сделана. Ставишь на model: haiku, он пробегает тесты и ищет дыры. Решает проблему, когда AI отчитывается «готово», а на деле половина не работает.

Orchestrator – цепочка Planner → Implementer → Verifier, где каждый агент специализируется на своём этапе. Планировщик разбирает задачу и создаёт техплан, исполнитель пишет код строго по плану, верификатор проверяет результат. Между ними структурированный output как эстафетная палочка: каждый передаёт следующему итоговый артефакт работы.

Debugger – специалист по root cause analysis: ловит стектрейс, воспроизводит, находит минимальный фикс, проверяет.

Конфиг субагента: markdown-файл с YAML-шапкой. Вот гипотетический пример:

--- name: code-reviewer description: Reviews code for bugs and style violations. Use when implementing PR review or after completing features. model: sonnet --- You are a code reviewer specializing in finding bugs and style violations. Focus on: 1. Logic errors and edge cases 2. Security vulnerabilities 3. Performance issues Report findings by severity: Critical / High / Medium.

Обратите внимание: промпт короткий и конкретный. Один из главных anti-patterns, который описывают и Anthropic, и Cursor: промпты на 2000+ слов делают субагент не умнее, а медленнее. Плюс каждый субагент это отдельное контекстное окно, отдельные токены, отдельные деньги. Пять параллельных субагентов ≈ пятикратные затраты. Так что «а давайте сделаем 20 агентов на все случаи жизни» это путь к разорению и медленной работе. Начинайте с 2-3 сфокусированных агентов. Добавляйте новых, только когда есть чёткий, отличающийся use case.

Hooks: невидимый middleware, о котором молчат

Hooks – это самая недооценённая фича Claude Code. Кастомные shell-команды, которые автоматически срабатывают на события в сессии. PreToolUse, PostToolUse, SessionStart, Stop, SubagentStop, UserPromptSubmit, PreCompact, PermissionRequest и ещё несколько, порядка десятка типов, и некоторые из них открывают безумные возможности.

Хак #1: «Do more» через Stop hook. Claude завершил задачу, вернул ответ. А Stop hook возвращает JSON с "continue": true, и Claude продолжает работать. Можно сделать prompt-хук, который проверяет, все ли пункты чеклиста выполнены, и если нет, гонит Claude дальше. По сути, бесконечный рабочий цикл.

{ "hooks": { "Stop": [{ "hooks": [{ "type": "prompt", "prompt": "Review whether the task is complete. If all requirements are met, respond with 'complete'. If work remains, respond with 'continue' and specify what still needs to be done." }] }] } }

Хак #2: Auto-format после каждой записи. PostToolUse хук с матчером "Write|Edit", и Prettier (или Black, или gofmt) автоматически форматирует каждый файл, который Claude пишет. Больше никаких ручных npx prettier --write.

{ "hooks": { "PostToolUse": [{ "matcher": "Write|Edit", "hooks": [{ "type": "command", "command": "prettier --write \"$CLAUDE_TOOL_INPUT_FILE_PATH\"" }] }] } }

Хак #3: Контекст при старте сессии. SessionStart хук инжектит git status и содержимое TODO.md. Claude сразу знает, на какой ветке вы, какие файлы изменены, что в бэклоге. Без вашего участия.

{ "hooks": { "SessionStart": [{ "hooks": [{ "type": "command", "command": "git status --short && echo '---' && cat TODO.md 2>/dev/null || true" }] }] } }

Хак #4: Звуковое уведомление. Stop хук с afplay /System/Library/Sounds/Glass.aiff, и Mac играет звук, когда Claude закончил. Мелочь, но если у вас сессия на 10+ минут, не приходится постоянно переключаться и проверять.

Отдельно про матчеры. "Write|Edit" это pipe-синтаксис для нескольких инструментов, "Bash(npm test*)" матчит по аргументам конкретной команды. Матчеры регистрозависимые: "bash" не поймает инструмент Bash.

Хуки могут возвращать структурированный JSON с полями decision (approve/block/allow/deny), reason (объяснение для Claude), continue (для Stop-хуков) и updatedInput (модификация входных параметров инструмента до выполнения). Это необычный для меня механизм: можно блокировать опасные команды, автоматически одобрять безопасные, модифицировать параметры на лету.

Context Engineering: мета-навык, которому не учат

Context engineering. Наткнулся на этот термин в блоге Anthropic. Это не промптинг. Это шире. Информационная архитектура вокруг модели: что именно попадает в контекстное окно, в каком порядке, в какой момент.

Почему это важно: каждый новый токен в контексте немного ухудшает способность модели «видеть» старые токены. Это называют context rot – буквально «гниение контекста»: чем длиннее контекст, тем хуже модель удерживает внимание на ранних частях. Исследования Chroma показали, что производительность падает с длиной контекста, а не со сложностью задачи. На практике, особенно для сложных многошаговых задач, безопаснее считать эффективным 60-70% контекстного окна.

Отсюда практическое правило: не начинайте сложную задачу, когда контекст уже больше чем наполовину заполнен. Лучше /compact или /clear и свежая сессия.

Claude Code использует system reminders, теги <system-reminder>, которые автоматически вставляются в разных местах контекста. Они напоминают модели о текущих целях, доступных инструментах и ограничениях. То же самое делают todo-списки: когда Claude обновляет todo.md между шагами, он, по сути, перезаписывает свои цели в конец контекста, где «внимание» сильнее всего. По сути, хак против «потери в середине», когда модель хуже «видит» информацию из середины длинного контекста.

Полезный паттерн – handoff: перед тем как сделать /clear, попросите Claude написать саммари текущей сессии. Что сделано, что осталось, какие решения приняты, какие файлы затронуты. Сохраните в файл. Начните новую сессию и дайте этот файл как контекст. По сути, ручная передача смены между «двумя Claude».

Я бы хотел ещё поделиться с вами вот таким проектом awesome-claude-code, там собраны интересные готовые команды: сформировать changelog, создать hook, провести анализ кода и так далее.

Где всё ломается

Было бы нечестно рассказать только про хаки и не упомянуть грабли.

Каждый скилл, каждый субагент это токены, а токены – деньги. «Поэтапное раскрытие» помогает, но если у вас 50 скиллов и 10 агентов, даже метаданные начинают весить. А каждый вызов субагента это полноценный отдельный разговор с моделью. Пять параллельных субагентов = пятикратный расход. Узнал это на практике: запустил кучу Explore-агентов для документирования проекта, счётчик токенов полетел вверх. Работает быстро, но вопрос толщины кошелька.

Haiku нуждается в более явных инструкциях, чем Opus. Anthropic прямо говорят: тестируйте скилл на всех моделях, которые планируете использовать. То, что Opus поймёт с полуслова, Haiku может интерпретировать криво. Если экономите, ставя субагент на дешёвую модель, будьте готовы написать ему более детальный промпт.

Hook timeout по умолчанию 60 секунд. Сложную логику в хук не засунешь. Если валидатор работает дольше, придётся выносить в отдельный процесс.

Eval-driven development звучит отлично в теории. Anthropic рекомендуют: сначала создай evaluation (тестовые сценарии), потом пиши скилл. На практике строить evals до того, как ты вообще понял, что скилл должен делать, тяжело. Я честно пытался, но чаще получается итеративно: написал → попробовал → поправил → повторил.

Deny не так надёжен, как кажется. Про это я писал в посте про песочницу для AI: когда Claude не смог получить доступ к файлу напрямую, он пошёл написал shell-скрипт. Не сработало, написал Python-скрипт и через него добрался. Находчивость модели иногда работает против ваших ограничений.

Граница между Skill, Command и Subagent до сих пор размытая. Когда command, а когда skill? Если задача одноразовая и не нужна изоляция, command. Если Claude должен сам понимать, когда запускать, skill. Если нужен отдельный контекст, subagent. Но на практике бывают серые зоны, когда подходит и то, и другое.

С чего начать перестройку сетапа

Если после всего этого хочется что-то поменять в своём workflow, вот порядок, который мне кажется разумным:

Начните с commands. Если ловите себя на повторяющихся промптах, превращайте их в команды. /handoff для передачи контекста между сессиями, /review для стандартного ревью. Это самый низкий порог входа.

Потом – skills. Когда commands освоены, выносите в skills то, что Claude должен запускать автоматически. Не забывайте про «поэтапное раскрытие»: держите SKILL.md компактным, детали — в отдельные файлы.

Субагенты – в последнюю очередь. Первый субагент на дешёвой модели (sonnet или haiku) с одной конкретной ответственностью. Например, «Верификатор», который проверяет тесты после каждого изменения. Хороший первый кандидат.

Один SessionStart hook, который инжектит git status, уже заметно улучшит каждую сессию. Просто начните с малого.

И регулярно проверяйте /context. Это покажет, сколько контекстного окна уже использовано. Если больше 60%, время делать compact или начинать свежую сессию.

А как у вас? Сколько скиллов в .claude/? Hooks пробовали или пока страшно давать Claude такую свободу? Делитесь, реально интересно посмотреть на чужие конфиги.

Долго сопротивлялся тому факту, что Claude Code имеет полный доступ к моему терминалу (не открытие, но я всегда на эту часть знаний закрывал глаза). Может запускать любые bash-команды. Читать ~/.ssh, переменные окружения с токенами. Всё.

Галлюки тоже с ростом проекта и его сложностью – возрастают. Например, он пытался запустить несуществующую команду. Безобидно, конечно. Но мысль осталась: а что если следующая галлюцинация будет с rm -rf или curl с моими секретами куда-нибудь не туда? Тем более что обнаруженные промпт-инъекции всё чаще находят уже те, кто пострадал.

Проблема: AI-агенты – это не просто чатботы

Есть принципиальная разница между ChatGPT в браузере и Claude Code / Cursor Agent. Первый может только текст генерировать. Вторые – выполняют команды. Реальные команды на твоей машине.

Что видит AI-агент в типичном сетапе:

• Полный доступ к файловой системе (включая ~/.ssh, ~/.config)

• Все переменные окружения (SERVER_1_API_KEY, BLA_BLA_ACCESS_KEY, всё что ты там экспортируешь)

• Возможность запускать любые shell-команды

• Историю bash с твоими прошлыми командами

• Git-коммиты, хронологию и тд

Галлюцинации + shell = потенциальный риск. Как ранее говорил, AI иногда выдумывает команды, путает синтаксис, или пытается сделать «лучше» без спроса. Особенно когда контекст уже перевалил за 90% в допустимом буфере.

Пара реальных сценариев, которые могут случиться:

• AI решает «почистить» временные файлы и промахивается с путём

• Отправляет диагностику куда-то через curl (видел такое в логах у другого блогера)

• Добавляет вредоносный MCP в конфигуратор (а supply chain атаки – уже не теория)

• Читает .env файл и включает его содержимое в ответ, который уходит в API

Не то чтобы это происходит каждый день. Но когда работаешь с чем-то важным – хочется подстраховаться. Да и параноик я по жизни.

А ещё с ростом проекта ты начинаешь обзаводиться тех. долгом и сессия работы агента начинает растягиваться (у меня стабильно 10+ минут на каждую таску) + уже работаю в двух терминалах, знаю людей, у которых их уже 6+. Хочется в момент ожидания не тиктоки листать и в телеге залипать, а следующие таски запускать. Это та самая дофаминовая петля – мозг требует ещё и ещё результатов. Но такой подход ломается, если ты не запускаешь Claude в режиме без ограничений (чтобы каждый чих не апрувить и согласовывать).

Решение: Dev Containers как песочница

Использую: Dev Container. Это способ запускать окружение разработки внутри Docker-контейнера. VS Code (или Cursor) подключается к нему, и ты работаешь как обычно. Только изолированно от хост-системы.

Почему именно devcontainer, а не просто Docker:

• Интеграция с IDE из коробки – расширения, терминал, отладка работают прозрачно

• Стандартизированный формат – devcontainer.json понимают VS Code, Cursor, Antigravity

• Удобное управление секретами через remoteEnv

• Можно настроить один раз и забыть

Философия простая: AI в контейнере. Сломает что-то – пересоздашь за минуту. Хост-система в безопасности.

Чем не угодили автору изолированные git-ветки и просто deny в настройках агентов?

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

2. Deny можно замутить, но я за месяцы работы так и не смог толком сформировать глобальный файл конфигурации, чтобы его можно было ctrl+c / ctrl+v из одного проекта в другой. А ещё, поверьте, если он захочет получить доступ к файлу – он этот deny найдёт как обойти. У меня до абсурда кейс был: когда он не смог получить доступ, пошёл написал shell-скрипт, не смог его запустить, пошёл в python, сделал py-скрипт и там всё-таки добрался до нужного.

Что из себя представляет devcontainer

Дисклеймер: я очень, подчеркну, очень мало работал с контейнерами, но мне эта тема интересна. И если я где-то в чём-то перемудрил или наоборот сделал хуже – можете кинуть какашку в комментарии, но я буду безмерно благодарен, если дадите конструктивный совет 🔥

Вот примитивная конфигурация, которую использую (это проект по выгрузке постов из телеги в md-формате).

devcontainer.json:

{ "name": "my-project", "build": { "dockerfile": "Dockerfile" }, "features": { "ghcr.io/devcontainers/features/node:1": { "version": "20" } }, "remoteEnv": { "TELEGRAM_API_ID": "${localEnv:TELEGRAM_API_ID}", "TELEGRAM_API_HASH": "${localEnv:TELEGRAM_API_HASH}", "ANTHROPIC_API_KEY": "${localEnv:ANTHROPIC_API_KEY}" }, "mounts": [ "source=project-data,target=/workspaces/project/data,type=volume" ], "runArgs": [ "--cap-drop=ALL", "--security-opt=no-new-privileges" ], "postCreateCommand": "bash .devcontainer/post-create.sh", "remoteUser": "vscode" }

Чуть-чуть пояснения:

--cap-drop=ALL – сбрасываем все Linux capabilities. Контейнер не может менять сетевые настройки, монтировать файловые системы, работать с устройствами. Только базовые операции.

--security-opt=no-new-privileges – процессы внутри контейнера не могут повышать привилегии. Даже если AI найдёт какой-то эксплойт – не сможет им воспользоваться.

remoteEnv – секреты передаются из хост-системы в контейнер, но не записываются в образ. Если кто-то получит доступ к образу – секретов там не будет.

Named volume для данных – персистентные данные (например, сессии) хранятся в Docker volume, а не в bind mount. Изоляция от хост-файловой системы.

remoteUser: vscode – работаем от непривилегированного пользователя, не от root.

Dockerfile – минимальный:

FROM mcr.microsoft.com/devcontainers/python:3.12 RUN apt-get update && apt-get install -y --no-install-recommends \ libffi-dev \ libssl-dev \ && rm -rf /var/lib/apt/lists/* WORKDIR /workspaces/project USER vscode

post-create.sh – инициализация после создания контейнера:

#!/bin/bash set -e # Node.js доступен здесь (установлен через features) sudo npm install -g @anthropic-ai/claude-code # Python окружение python -m venv .venv source .venv/bin/activate pip install -r requirements.txt

Всё это дело можно упростить следующим образом:

1. Открываете любого AI-агента и проект, который раньше у вас запускался не в контейнере.

2. Создаёте ему задачу следующего типа:

Данный проект должен иметь возможность запускаться в devcontainer. Создай необходимые файлы конфигурации. Конфигурацию создай на основе описания проекта, зависимостей. По необходимости создай скрипты по установке дополнительных инструментов после сборки образа.

Во что я вляпался, пока всё это отлаживал

Показать только результат – скучно же.

npm недоступен при сборке образа. Пу-пу-пу. Хотел установить Claude Code CLI прямо в Dockerfile через npm install -g. Получил ошибку: npm not found.

Причина: Features (включая Node.js) применяются ПОСЛЕ сборки Dockerfile. Это, видимо, особенность архитектуры devcontainers. Dockerfile собирается первым, потом накатываются features, потом запускается postCreateCommand. Ну либо я рукожоп.

Решение: перенёс установку CLI в post-create.sh. Там Node.js уже доступен.

Кэширование PATH в bash. После установки Claude Code и других CLI-полезностей через npm новый путь добавляется в PATH. Но если терминал уже открыт (а я делаю это всё внутри Cursor) – bash помнит старый PATH. Получаешь «claude: command not found», хотя всё установлено.

Решение: перезапустить терминал или выполнить hash -r для сброса кэша команд.

Секреты не пробрасываются. Настроил remoteEnv, но переменные пустые внутри контейнера.

Причина: переменные должны быть экспортированы на хосте ДО запуска контейнера. Если добавил export TELEGRAM_BLA_BLA_KEY=... после – нужно пересоздать контейнер.

Чего этот подход НЕ решает

Важно понимать ограничения.

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

Сетевой доступ есть. Контейнер может делать запросы в интернет. Можно ограничить через --network none, но тогда сломается npm install, pip install, git clone и вообще всё полезное. Возиться с white-списком мне лень.

Секреты в remoteEnv доступны AI внутри контейнера. Внутри контейнера AI может прочитать эти переменные (если захочет). Разница в том, что он не видит ВСЕ секреты хост-системы – только те, что явно пробросили.

Первый запуск = сборка образа. Готовьтесь ждать несколько минут. У меня две минуты на чистую сборку. Потом кэш спасает.

Не защищает от логических ошибок. Если AI сгенерирует код с SQL-инъекцией – devcontainer никак не поможет. Это про изоляцию окружения, не про code review.

Когда это нужно, а когда overkill

Используй devcontainer, если:

• У тебя на устройстве корпоративные проекты

• Работаешь с реальными API-ключами и секретами

• Проект связан с продакшн-инфраструктурой

• Есть доступ к чувствительным данным (клиентские данные, финансы)

• Хочешь воспроизводимое окружение для команды

• Паранойя – твоё второе имя

Не заморачивайся, если:

• Pet-проект без секретов

• Личный комп, на котором ничего важного нет

• Учебный код

• Публичный open-source без credentials

• Доверяешь AI больше, чем я

Как сделать такое же у себя?

Если решил попробовать, вот что нужно:

1. Установи Docker Desktop и Dev Containers (расширение для Cursor).

2. Создай папку .devcontainer в проекте

3. Добавь devcontainer.json с базовой конфигурацией

4. Добавь runArgs с --cap-drop=ALL и --security-opt=no-new-privileges

5. Пробрось только нужные секреты через remoteEnv

6. Установи AI-инструменты в postCreateCommand, не в Dockerfile

7. Проверь что всё работает: Cmd+Shift+P → «Reopen in Container» в IDE

Занимает 15-20 минут на первую настройку.

AI-агенты – новая категория инструментов, и практики безопасности для них ещё формируются. Dev Containers – один из возможных подходов, который лично мне даёт спокойствие при работе с Claude Code на проектах с секретами.

А вы как защищаете систему от AI-агентов? Или просто доверяете и не паритесь? Делитесь опытом.

Я в свободное время интересуюсь GameDev направлением. Недавно столкнулся с тем, что сделать какой-нибудь простенький 3-match не так сложно, кроме истории с визуалом (UX). Парочка хороших паков иконок либо сложно купить внутри РФ, либо стоят дорого.

У меня был опыт работы с генеративными моделями по иллюстрациям, и возникла мысль: почему бы не попробовать сделать ассеты для прототипа? Инди-разработка игр часто упирается в бюджет, и генерация игровых ассетов через AI может сэкономить сотни долларов (звучит в теории).

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

Дисклаймер касательно художников

Сугубо моё личное мнение – если человек ни разу в жизни не был разработчиком игр, и помимо того, что он должен осознать, как всё это запрограммировать, продумать геймдизайн, понять требования площадок и сделать что-то работающее на разных платформах, – схитрить на создание UX, как по мне, норма. Человек и так потратит уйму времени во всё это дело.

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

Про ситуацию с художниками на рынке У меня супруга работает в GameDev-студии, я вакансии специально проанализировал – везде сейчас требование по умению работать с GenAI (image-2-image, ComfyUI, pipeline-создание и так далее). Уверен, что инструмент в значительной степени их усиливает.

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

Зачем генерировать ассеты вместо покупки

Генерация игровых ассетов с помощью нейросетей – это в первую очередь развитие собственного опыта осознанности, где AI может помочь, а где на него полагаться не стоит. Для инди-разработки игр это способ конкурировать со студиями, у которых есть штатные художники. Нейросеть для создания картинок позволяет одному разработчику создавать контент, на который раньше требовалась целая команда.

Есть сценарии, где это выгодно, и есть где – нет. Вот табличка, которую я для себя составил:

Юнит-экономика для 100 иконок

• Asset Store: 2-4 пака × $20 = $40-80 + время на поиск совместимых стилей

• Фрилансер: $200-400 + 2-3 недели ожидания + риск переделок

• AI: Sora / StableDiffusion + 5-8 часов работы (генерация + постобработка). Можно вообще обойтись free-тарифом (5 попыток в день) и потихоньку в течение недели ковырять. Или локально без лимитов через ComfyUI.

Где AI выигрывает

• Нужен единый стиль для всех элементов (генерируешь одной сеткой), можно указывать референс

• Делаешь прототип/MVP – не критично, если не идеально

• Бюджет ограничен, но время есть

• Нужны вариации одного и того же (переделать цвет, форму)

Где AI проигрывает

• Pixel art – AI не понимает ограничения палитры, будет замыливать пиксели

• Персонажи с лицами – нужна консистентность между кадрами, это сложно

• Проекты с высокими требованиями к качеству (типа A+)

Из 10 генераций 6-7 будут браком. Либо объекты сливаются, либо пропорции кривые, либо цвета не те. Тут просто reroll-практика.

Как я пришёл к «шаблону промпта»

Первые попытки были провальные. Я писал в лоб: «нарисуй фрукты для игры», и получал что угодно, но не то, что нужно.

Проблемы первых генераций

• Фон не белый, а градиентный

• Объекты разного размера

• Тени слишком жёсткие или вообще отсутствуют

• Стиль каждый раз разный

Начал добавлять детали: «cartoon style», «glossy finish», «white background». Стало лучше, но всё равно нестабильно.

Что я заметил

1. Визуальный стиль нужно описывать подробно: тип рендеринга (3D/2D), финиш (глянцевый/матовый), форма объектов (мягкие края vs острые)

2. Освещение критично: «soft ambient lighting» даёт совсем другой результат, чем «harsh directional light»

3. Композиция – если не указать, что объект должен занимать 60-70% кадра, он будет теряться

Универсальный шаблон (preset) промпта, который использую для всех ассетов. Вот его основа:

Create a 3D illustration in the distinctive minimalist style. VISUAL STYLE SPECIFICATIONS: - 3D soft-body rendered objects with smooth, flowing surfaces - Clean, slightly rounded geometric form with zero sharp edges - Soft lighting with subtle shadows - Glossy matte finish on all surfaces - Professional product illustration aesthetic RENDERING CHARACTERISTICS: - Highly polished, smooth surface finish - Soft ambient lighting that wraps around the subject - Subtle specular highlights creating gentle reflections - Gentle shadow beneath object - Professional 3D rendering quality COMPOSITION RULES: - Center the subject in frame - Minimal negative space (object should occupy 50-70% of frame) - 1:1 ratio - Pure white or very light off-white background - No text, watermarks, or brand elements - Single focused subject per image OBJECT DESIGN PRINCIPLES: - Organic but geometric forms - Symmetrical or balanced asymmetry - Playful, slightly whimsical proportions - Details should be subtle and refined - No gritty textures or rough surfaces

Если нужно 2D – то поменять вместо 3D.

Сейчас просто копирую его и меняю пару строк – что рисовать, какие цвета. Работает стабильнее, чем я ожидал.

Почему grid, а не отдельные элементы

Когда генерируешь иконки по одной, каждая будет чуть-чуть отличаться по стилю – освещение разное, углы разные, толщина контуров разная. Если делать сетку 2×2 или 2×3, всё генерируется за один раз → стиль идентичный → остаётся только вырезать.

Тут нюанс: размер сетки имеет значение! По моему опыту с GPT-4o:

• ✅ 2×2 (4 элемента) – оптимально, брака почти нет

• ✅ 2×3 (6 элементов) – работает стабильно

• ⚠️ 3×3 (9 элементов) – начинаются проблемы, может потребоваться 2-3 итерации

• ❌ 4×4 (16 элементов) – высокий процент брака, элементы сливаются

Это эмпирические наблюдения, официальных ограничений размеру сеток OpenAI не публикует.

Я сначала пробовал сразу 4×4, чтобы за раз получить много вариантов. Половина была непригодна – фрукты наползали друг на друга, цвета смешивались. Перешёл на 2×2, стало гораздо стабильнее.

Плюс экономия: вместо 20 отдельных генераций делаешь 5 сеток по 4 элемента. Меньше запросов → меньше времени → не упираешься в лимиты.

Генерация ассетов для match-3: пошаговый процесс

Рассказываю на примере, как я делаю набор иконок. Весь процесс занимает 40-60 минут на набор из 20 элементов.

Шаг 1: Поиск референсов (15 мин)

Захожу в Asset Store или Pinterest, ищу игры в похожем стиле. Мне не нужно скачивать – просто смотрю:

• Какой стиль преобладает (мультяшный/реалистичный/глянцевый)

• Какие цвета используются

• Есть ли контуры, тени, блики

Сохраняю 3-5 примеров, которые нравятся.

Шаг 2: Подготовка промпта (10 мин)

Беру свой базовый шаблон, добавляю специфику:

• Что рисуем (фрукты, конфеты, кристаллы)

• Сколько элементов и в какой раскладке (2×2)

• Какие цвета должны быть

• Особенности стиля (cartoon, glossy, 2D/3D)

Шаг 3: Генерация (5-10 мин на попытку)

Закидываю промпт, жду 30-60 секунд. Смотрю результат:

• Если ОК – сохраняю

• Если не то – правлю промпт, генерирую снова

Обычно делаю 2-3 итерации, пока не получится приемлемый результат. На выходе – изображение с сеткой 2×2.

Шаг 4: Апскейл (опционально, 10-15 мин)

Генерация даёт низкое разрешение (1024×1024 на всю сетку → ещё меньше на каждый элемент). Для мобильных игр норм, для десктопа маловато.

Использую:

• Topaz Gigapixel – лучшее качество

• img2img в Stable Diffusion – если умеешь настраивать и подбирать модели

• Либо любой сайт в поисковике по запросу «upscale image» (есть куча бесплатных)

Апскейл в 2× занимает 1-2 минуты на сетку.

Шаг 5: Отбор и вырезка (15-20 мин)

Открываю Photoshop (или GIMP, если бесплатно):

• Разрезаю сетку на отдельные элементы

• Убираю фон (Magic Wand Tool или слой-маска)

• Сохраняю каждую иконку как отдельный PNG

На один элемент уходит 3-5 минут, если фон простой.

Готовые промпты для нейросети: примеры для игровых ассетов

Пример 1: Фрукты для match-3 (cartoon style)

A 2×2 grid of game fruit icons: top row shows 1 strawberry in red and 1 apple in green with shine; bottom row shows 1 orange in bright orange and 1 lemon in yellow. Cartoon 2D mobile game style, glossy finish with shine spots, white background, all fruits front-facing, equal size, separated by thin lines, ready for tile extraction.

Что тут важно:

• «2×2 grid» – указываю чёткую раскладку (важно для стабильности!)

• «equal size» – чтобы не было одного огромного яблока и крошечной клубники

• «separated by thin lines» – так легче резать в Photoshop

• «ready for tile extraction» – намекаю, что это должны быть отдельные объекты

Пример 2: Конфеты (глянцевый стиль)

Create a 2×2 grid of match-3 candies: Top row: red wrapped candy, blue lollipop Bottom row: yellow striped bonbon, green wrapped taffy Cartoon 2D mobile game style, glossy finish with shine, white background, equal square cells separated by thin gray lines, all candies same size, ready for sprite extraction.

Здесь добавил:

• Конкретные типы конфет (wrapped, lollipop, bonbon) – AI лучше понимает

• «square cells» – для match-3 важно, чтобы ячейки были квадратные

Пример 3: Кристаллы (3D стиль)

A 2×2 grid of magical crystals for match-3: Top row: purple amethyst crystal, blue sapphire gem Bottom row: red ruby stone, green emerald crystal 3D rendered style, polished glossy surface with internal glow, soft shadows, white background, geometric faceted shapes, equal size, centered in cells, grid layout with thin dividers.

Для кристаллов важно:

• «geometric faceted shapes» – чтобы были грани, а не гладкие шары

• «internal glow» – придаёт магический вид

Пример 4: Попытка сделать турнаунд

Турнаунд (turnaround) — это набор видов персонажа со всех основных ракурсов: фронт, профиль, спина, и часто 3/4 angle.

Character design sheet featuring the same character from multiple angles. TOP ROW (left to right): 1) Front view - facing camera, neutral pose, arms at sides 2) 3/4 LEFT angle - rotated 45 degrees left, slight turn 3) LEFT PROFILE - perfect side view, 90 degrees BOTTOM ROW: 1) 3/4 RIGHT angle - rotated 45 degrees right 2) RIGHT PROFILE - opposite side view, 90 degrees right 3) BACK view - facing away, back of character CHARACTER DESCRIPTION: A young ranger, human male, green hood, brown leather armor, sword at hip, confident stance. Consistent face, proportions, outfit across ALL views. TECHNICAL REQUIREMENTS: - Orthographic camera (flat, no perspective distortion) - Equal character height in each cell - Consistent lighting from top-left across all views - White background with thin grid lines - No background scenery, pure character focus - Professional animation reference quality

Таблица стилей: что работает, что нет

На основе собственных 50+ попыток:

Если делаешь pixel art игру, лучше рисовать самому или покупать готовое. AI с этим не справляется.

Реальная окупаемость и процент брака

В среднем на подписке – $20/мес, хватает, чтобы не упираться часто в лимиты.

Если ты делаешь одну игру в квартал и чисто solo-разработка, это дорого получается по итогу. Если делаешь 2-3 проекта одновременно – окупается быстро.

Из 10 генераций:

• 5-6 – откровенное говно (объекты смазанные, цвета не те, композиция кривая)

• 1-2 – «почти то», но нужны правки (можно использовать с постобработкой)

• 1 – готовые к использованию с минимумом доработок

Это нормально. Просто закладывай время на переделки.

Время на обработку результата

В промптах пишут «5 минут на элемент» – вранье. Реально:

• Вырезать фон: 3-5 мин/элемент (если фон простой)

• Подправить края (сглаживание): 2-3 мин

• Апскейл: 1-2 мин

• Проверить, что всё ОК: 1 мин

Итого: на набор из 20 иконок уходит не 5 минут, а 2-3 часа с учётом генерации и обработки.

Хотя это всё равно быстрее, чем ждать фрилансера неделю.

Что не работает: ограничения AI

Pixel art AI не понимает ограничения палитры. Если попросишь «8-bit style», он нарисует что-то похожее, но пиксели будут размытые, цвета – не из палитры. Проще нарисовать самому в Aseprite.

Персонажи с лицами Если нужен один и тот же персонаж в разных позах – боль. Лицо каждый раз будет немного другое. Для этого нужны специальные инструменты типа consistent character в Midjourney или обучать свою LoRA в Stable Diffusion.

Сложные сетки >6 элементов Пробовал делать 4×4 (16 элементов) – половина была непригодна. Элементы сливаются, цвета смешиваются, пропорции плывут. 2×2 или 2×3 – оптимум.

Необходимый софт для обработки

• Photoshop ($10-20/мес) – самый удобный вариант

• GIMP (бесплатно) – работает, но менее удобно

• Figma – можно вырезать простые объекты, но нет нормальных масок

Плюс апскейл-инструменты, если нужно высокое разрешение – писал выше.

Юридические нюансы

Можно ли использовать AI-ассеты в коммерческих играх? По ToS OpenAI – можно, сгенерированный контент принадлежит тебе. Но есть нюанс: если твои ассеты случайно будут похожи на контент из игр популярных издателей – могут быть вопросы.

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

Другие AI-инструменты для игровой графики

Кроме Sora есть альтернативы. Если вы ищете другие варианты для создания ассетов для игр, вот что я пробовал:

Leonardo AI

Плюсы:

• Точный контроль через параметры (guidance scale, ControlNet)

• Лучше для концепт-арта и иллюстраций

• Есть бесплатный тариф (150 токенов/день ≈ 10-12 изображений)

Минусы:

• Для иконок overkill – слишком много настроек

• Нужно разбираться в параметрах

Когда использовать: если делаешь концепт-арт или персонажей и нет собственной мощной видеокарты.

Stable Diffusion (ComfyUI)

Плюсы:

• Бесплатно (если запускаешь локально)

• Полный контроль через параметры и модели

• Можно обучить свою LoRA под конкретный стиль (ну либо найти на просторах подходящее)

Минусы:

• Нужна нормальная видеокарта (минимум RTX 3060)

• Крутая кривая обучения

• Много времени на настройку

Когда использовать: если ты технарь и хочешь полный контроль. Ну либо если других вариантов нет.

Midjourney

Плюсы:

• Хорошее качество, особенно для художественных стилей

• Очень стабильная генерация

Минусы:

• Дорого ($10-120/мес в зависимости от плана)

• Через Discord – не всем удобно

• Хуже с техническими стилями (UI, иконки)

Когда использовать: если нужен wow-эффект для маркетинговых материалов.

Мой выбор: Пока хватает Sora и ComfyUI.

Ещё AI-инструменты можно, например, использовать для создания локализации с поддержкой контекста, рассказывал ранее, как это сделать через n8n.

Резюме

Если коротко: AI для ассетов работает, но не для всего. Генерация игровых ассетов с помощью нейросети для создания картинок – это не замена художнику, но мощный инструмент для инди-разработки игр. Особенно если делаешь прототип, MVP или casual игру с ограниченным бюджетом.

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

А вы пробовали генерировать ассеты? Какие инструменты используете для создания ассетов для игр? Или считаете, что AI – это зло и нужно поддерживать художников? Делитесь в комментах!

Я провел эксперимент с AI для кодинга: создал prod-ready лендинг на Next.js тремя способами, используя разную степень детализации контекста для Claude Code. 1300 строк спецификации дали код на 8/10. Минимум контекста – только 4/10. Но быстрый старт за 11 минут обернулся 3+ часами доработок.

Дальше – результаты трех экспериментов, технический анализ кода и правила выбора подхода.

Зачем этот эксперимент

Постоянно спорят: больше контекста для AI – хорошо или плохо? Одни говорят: "Чем детальнее опишешь, тем лучше". Другие: "Минимум информации – AI разберется сам".

Я решил проверить на практике. Взял реальную задачу – создание лендинга с Claude Code – и сделал его тремя способами:

1. Максимальная детализация – 1300 строк спецификации, MCP-сервер, два саб-агента

2. Сбалансированный подход – ~100 строк спецификации, без дополнительных инструментов

3. Минимализм – только tech-stack и описание проекта

Какой подход даст лучший результат – скорость? качество кода? минимум доработок?

Спойлер: выбор был сложным и неоднозначным, но мой голос пал на первый вариант. А почему – расскажу дальше.

Задача: создание лендинга на Next.js с помощью AI

Что создаю – лендинг о важности подготовки контекста для AI-агентов.

Tech stack:

• Next.js (14 или 15)

• TypeScript

• Tailwind CSS

• shadcn/ui компоненты

• next-themes (светлая/темная тема)

• lucide-react (иконки)

Что должно быть на лендинге:

• 9 секций: Header, Hero, Problem, Solution, Best Practices, Metrics, Examples, CTA, Footer

• Светлая и темная тема с плавными переходами

• Адаптивная верстка (mobile-first)

• Валидация форм

• Hover эффекты и анимации

Критерии оценки:

1. Скорость создания первого прототипа – сколько минут от промпта до готового результата

2. Соответствие ожиданиям – визуальное качество, работоспособность, детали

3. Потенциальные доработки – сколько времени нужно на правки до production-состояния

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

Эксперимент 1: Максимальная детализация (1300 строк)

Подход – создал детальную спецификацию на 1300 строк с полным описанием всех секций, компонентов, стилей и требований. Подключил MCP-сервер для работы с контекстом и два специализированных AI-агента: Tailwind Frontend Expert и Frontend-Developer.

Время работы агента: 27 минут

Самый долгий вариант. 30+ минут на спецификацию, остальное – разработка. Но вот что интересно: больше времени на подготовку = меньше правок потом.

Спецификация (1300 строк, у меня было собственное ТЗ, но мне нужно было его растянуть на 1000+ строк. Perplexity с этим мне помогла)

Работа шла по этапам:

1. AI-агенты изучили спецификацию

2. Tailwind Frontend Expert спроектировал компонентную архитектуру

3. Frontend-Developer реализовал код

4. MCP-сервер помог с организацией файлов, структурой проекта, получением контекста по компонентам. Каким MCP чаще всего пользуюсь, рассказывал вот тут

Что хорошо:

• Цвета, анимации, последовательность блоков – всё по спецификации

• Код понятный и хорошо структурированный

• Модульная архитектура с разделением на sections/, cards/, forms/, providers/

• Все компоненты переиспользуемые

• Централизация данных в lib/constants.ts (но вынесен не весь текст)

Что не так:

• Выжженные цвета в темной теме (слишком яркие, надо приглушить)

• Блок "Процесс подготовки" не до конца корректно сформирован

• Некоторые анимации слишком активные

Технологии (на момент эксперимента):

• Next.js 15.1.4 + React 19.0.0 (актуальная stable версия)

• Tailwind CSS 3.4.1 (на момент эксперимента; актуальная в 2026: v4.1)

• Radix UI (3 компонента) + shadcn/ui

• next-themes 0.4.6

• lucide-react 0.562.0

Примечание: Эксперименты проведены в январские каникулы 2026 года. На январь 2026 актуальны Next.js 16.1, React 19.2, Tailwind CSS v4.1. Описанные принципы остаются актуальными независимо от версий.

Архитектура веб приложения и качество кода

Качество кода:

• TypeScript Strict Mode: ✅

• Отдельный файл типов (types/index.ts): ✅

• Централизация данных: ✅ (большая часть контента в constants.ts)

• Модульность: ✅ (5 специализированных типов карточек)

• Email валидация: ✅ (regex + детальные сообщения ошибок)

Общая оценка: 8/10

Первый подход выиграл по архитектуре. Модульная структура, централизация данных, специализированные компоненты – проект готов к масштабированию.

Да, разработка дольше в 2 раза. Но доработок минимум – всего 30 минут на цвета и мелкие баги.

Эксперимент 2: Сбалансированный подход (~100 строк)

Подход – сократил спецификацию в 13 раз (до ~100 строк). Оставил только ключевые моменты: tech stack, описание проекта, основные секции и требования к дизайну. Отключил MCP-сервер и дополнительных AI-агентов. Работа напрямую с базовым Claude Code.

Время работы AI-агента: 14 минут

Спецификация: (100 строк)

Работа шла линейно:

1. Дал промпт с краткой спецификацией

2. Claude Code создал структуру проекта

3. Реализовал все секции последовательно

4. Добавил темную тему и адаптивность

Что хорошо:

• Визуально зашел даже больше первого

• Темная тема получилась значительно лучше (более сбалансированные цвета)

• Простая и понятная структура

• Хорошая документация (README.md присутствует)

Что не так:

• Нет анимаций при переходе между секциями (есть только притормаживание)

• Ошибки в консоли при первом запуске

• Данные размазаны по компонентам (нет централизации)

• Валидация формы базовая

Технические характеристики

Технологии:

• Next.js 14.2.0 (отстаёт на 2 мажорные версии: 14 → 15 → 16)

• Tailwind CSS 3.4.0

• Radix UI (1 компонент) + shadcn/ui

• next-themes 0.3.0 (старая версия)

• lucide-react 0.344.0

Архитектура:

Качество кода:

• TypeScript Strict Mode: ✅

• Отдельный файл типов: ❌

• Централизация данных: ❌ (данные локально в секциях)

• Модульность: ⚠ (базовый Card из shadcn/ui)

• Email валидация: ✅ (regex)

Общая оценка: 6/10

Второй эксперимент – золотая середина по времени. 14 минут на разработку – неплохо. Визуально результат даже лучше первого.

Но есть нюансы:

• Устаревшие версии библиотек

• Нет централизации данных (сложнее поддерживать)

• Слабее архитектура

Для среднего проекта или быстрого прототипа – отличный вариант. Для production с планами роста – потребуются доработки.

Эксперимент 3: Минимализм (базовая спецификация)

Подход – минимум информации. Дал только tech stack и краткое описание проекта (2-3 предложения). Без детализации секций, без требований к дизайну, без спецификации компонентов. Claude Code сам решает, как всё делать.

Время: 11 минут

Спецификация: (10 строк)

Самый быстрый из всех экспериментов. Минимум на подготовку (1 минута), максимум на реализацию (10 минут).

Работа была предельно простой:

1. Дал минимальный промпт

2. Claude Code создал структуру

3. Реализовал базовые секции

4. Добавил shadcn/ui компоненты со стандартными стилями

Что хорошо:

• Очень быстро (11 минут)

• React 19.0.0 (последняя стабильная мажорная версия на момент эксперимента)

• Структура простая – легко навигироваться

• Работает из коробки

Что не так:

• Результат безвкусный и шаблонный

• Стандартная цветовая тема Shadcn без кастомизации

• Нет анимаций и переходов вообще

• Добавлен лишний блок Pricing – варианты продаж, которых не было в задаче

• Нет кнопок "Связаться", "Купить"

• Обработка ошибок через alert() вместо нормальных уведомлений

• Слабая валидация формы (только HTML5)

Технические характеристики

Технологии:

• Next.js 15.1.4 (актуальная на момент эксперимента; в 2026: v16.1)

• React 19.0.0

• Tailwind CSS 3.4.17 (последняя версия v3; в 2026 актуальна v4.1)

• shadcn/ui (6 компонентов)

• next-themes 0.4.4

• lucide-react 0.468.0

Архитектура:

Качество кода:

• TypeScript Strict Mode: ✅

• Отдельный файл типов: ❌

• Централизация данных: ❌

• Модульность: ❌ (плоская структура)

• Email валидация: ⚠ (только HTML5 required)

Общая оценка: 4/10

Третий эксперимент – самый быстрый, но с наибольшим количеством доработок. 11 минут экономии = 3+ часов на исправления:

• Реорганизация структуры (плоская → модульная)

• Централизация данных

• Замена alert() на нормальные уведомления

• Улучшение валидации форм

• Кастомизация дизайна (убрать шаблонность)

Подходит для быстрых экспериментов и MVP, где визуал и архитектура не критичны. Для production – только после рефакторинга.

Сравнение результатов: кто выиграл?

Эксп. 1 выигрывает с большим отрывом:

• Модульная структура: components/sections/, cards/, forms/

• Централизация данных в lib/constants.ts (один источник правды)

• TypeScript интерфейсы в types/index.ts (переиспользование типов)

• Специализированные компоненты для разных типов контента

Эксп. 2 и 3 используют упрощенную/плоскую структуру. Данные размазаны по компонентам. Нет четкого разделения по типам.

Поддерживаемость

Эксп. 1 проще поддерживать:

• Один источник данных (lib/constants.ts)

• Четкая структура папок

• Специализированные компоненты (легко найти нужный)

Эксп. 2/3 сложнее:

• Данные размазаны по файлам

• Плоская/смешанная структура

• Универсальные компоненты (нужно читать код, чтобы понять логику)

Почему я выбрал вариант 1

Да, на разработку ушло 27 минут (против 11-14 в других). Но доработок нужно всего ~30 минут:

• Исправить цвета в темной теме

• Подправить блок "Процесс подготовки"

• Приглушить некоторые анимации

Итого: 27 + 30 = час до production.

Для сравнения:

• Эксп. 2: 1-2 часа (обновление зависимостей, централизация данных)*

• Эксп. 3: 3+ часов (рефакторинг архитектуры, улучшение валидации, дизайн)*

Когда проект живет больше месяца, архитектура становится важнее скорости разработки.

Время на подготовку окупается

30 минут на подготовку детальной спецификации = экономия часов на:

• Правках после первой версии

• Рефакторинге кода

• Добавлении новых фич

• Обновлении контента

* Есть важный момент. Время доработки формировалось из условий, что человек только-только пробует так называемый vibe-кодинг. В умелых руках, что-то поправить в эксперименте 2 или 3 – может занять кратко меньше времени. Особенно если человек обладает экспертизой, насмотренностью и умением писать эффективные prompt-запросы.

Практические выводы: когда использовать какой подход

На основе трех экспериментов я вывел 5 правил, которые помогут выбрать оптимальный баланс между детализацией контекста и результатом.

Этот эксперимент – пример vibe coding в действии: интуитивная разработка с помощью AI для кодинга, где важнее понимание цели, чем написание каждой строки кода вручную.

Правило 1: Выбирайте детализацию по целям проекта

Не существует универсального ответа "больше контекста = лучше". Всё зависит от цели.

MVP / быстрый прототип → Эксп. 3 (Минимализм)

• Подходит для: тестирование идеи, демо, proof of concept

• Ожидание: доработаете потом или выбросите

Production с планами роста → Эксп. 1 (Максимальная детализация)

• Подходит для: коммерческие проекты, долгосрочная поддержка, команда разработчиков

• Ожидание: минимум правок, готов к масштабированию

Средний проект / быстрый запуск → Эксп. 2 (Сбалансированный)

• Подходит для: pet-проекты, внутренние инструменты, средний срок жизни (около месяца)

• Ожидание: умеренные доработки

Правило 2: Инвестируйте время в источники правды

Эксперимент 1 показал мощь централизации. Вместо повторения инструкций в каждом промпте создайте файлы-источники правды:

Что создавать:

• DESIGN_SYSTEM.md – цвета, шрифты, отступы, компоненты

• REFERENCE.md – описание дизайна секций

• CODE_STYLE.md – правила кода, архитектура, паттерны

• API_SPEC.md – спецификация API

• TERMINOLOGY.md – термины проекта (как я уже обжигался)

Преимущества:

• AI всегда видит актуальную информацию

• Консистентность гарантирована

• Легко обновлять (статичные файлы вместо десятков промптов)

Правило 3: MCP и AI-агенты для сложных проектов

Когда MCP и агенты окупаются:

• Пробуете новые версии библиотек и LLM ещё о ней не знает

• Сложная предметная область

• Интеграция с внешними системами

Что дает MCP:

• Помогает организовать структуру проекта

• Следит за консистентностью

• Предлагает архитектурные решения

• Получение актуального контекста

• Возможности отладки (например через Playwright организовать E2E тестирование)

Когда можно без MCP:

• Быстрые прототипы

• Pet-проекты

• Learning проекты

• Одноразовые скрипты

Правило 4: Баланс между скоростью и качеством

Звучит логично: быстро = экономия времени. Но нет.

Экономия N минут на старте (Эксп. 3 vs Эксп. 1) = потеря N минут на доработках.

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

Правило 5: Новый чат для каждой проблемы

Если с первого промпта не завелось – не пытайтесь чинить в том же чате. Создавайте новый.

Почему это важно:

Когда AI генерирует код с ошибками, контекст "загрязняется". В истории чата остаются:

• Неработающий код

• Ошибки компиляции

• Попытки исправлений

• Ваши комментарии "это не работает"

AI начинает опираться на этот битый контекст и генерирует новые правки поверх сломанного кода.

Правильный workflow при ошибках:

Шаг 1: Зафиксируйте проблему

"AI сгенерировал компонент Hero, но: - Цвета не те (использует #000000 вместо #0a0a0a) - Анимация не работает - TypeScript ругается на типы"

Шаг 2: Откройте НОВЫЙ чат

Шаг 3: Дайте чистый промпт

"Создай компонент Hero по спецификации DESIGN_SYSTEM.md. Требования: - Цвет фона #0a0a0a (из DESIGN_SYSTEM.md) - Fade-in анимация через framer-motion - Строгая типизация TypeScript"

Что это дает:

• AI видит задачу с чистого листа

• Нет битого контекста

• Свежий взгляд на проблему

• Меньше шансов повторить ошибку

Когда можно продолжать в том же чате:

• Мелкие стилистические правки (цвет, отступ)

• Добавление новой независимой фичи

• Рефакторинг работающего кода

Когда нужен новый чат:

• Код не компилируется

• Логика работает неправильно

• После 3-х неудачных попыток исправить

• Ошибки TypeScript/ESLint не уходят

Я уже писал про это – про то, как наш мозг работает как одноядерный процессор, и AI не исключение. Перегруженный контекст = хуже результаты.

Заключение

Три эксперимента показали: больше контекста – не всегда лучше. Минимализм – не всегда быстрее.

Мои рекомендации:

• Для learning / MVP: минимальный контекст (Эксп. 3) – быстро, доработаете потом

• Для серьезных проектов: детальный контекст (Эксп. 1) – дольше старт, но меньше боли потом

• Для баланса: средний контекст (Эксп. 2) – золотая середина

Детализация контекста – это не про "больше или меньше". Это про соответствие целям проекта. Выбирайте подход осознанно, экспериментируйте и находите свой баланс.

Если вы работаете с AI для кодинга или только начинаете использовать Claude Code / Cursor для разработки, этот эксперимент показывает: детализация контекста – не просто техника промпт инжиниринга, а инвестиция в качество архитектуры веб приложения.

А какой подход используете вы? Делитесь в комментариях – интересно узнать ваш опыт с детализацией контекста для AI.

Одинадцать вечера. Я засиделся с Cursor AI, пилю очередную фичу для своего pet-проекта. Мозг перегружен, но я не могу оторваться – еще один промпт, еще одна итерация. Код генерируется моментально, я правлю, запускаю тесты, получаю результат. И снова. Это чем-то напоминает игру: делаю шаг → получаю награду → делаю следующий шаг. Дофаминовая петля.

Когда я наконец ложусь спать, мозг не отключается. Мысли крутятся вокруг завтрашних задач: какой результат я получу завтра, какую фичу допилю, какой промпт сработает. Засыпаю с трудом. И я понял – это похоже на зависимость от коротких видео или игр. Минимум усилий, весомая награда, которую мозг оценивает как "вау, круто!".

С одной стороны, я создаю продукт, о котором давно мечтал. Который может принести возможно дополнительную финансовую стабильность и освободить время. С другой – вот эта постоянная доза быстрого дофамина отвлекает, мешает отдыхать, заставляет забивать на более глубокую работу над архитектурой. Я стараюсь детектить эти проявления, иногда делаю детокс от AI на пару дней и пишу код руками. Пока не уверен, что это работает, но что-то подсказывает – тема глубже, чем кажется.

Что реально происходит с мозгом, когда мы используем Cursor AI, Claude Code и другие AI-ассистенты? Почему это не просто ощущение, а реальная биохимия мозга?

Что такое "вайб кодинг": как нейросети для кодинга изменили программирование

Термин "vibe coding" ввел Андрей Карпати – один из основателей OpenAI и бывший директор AI в Tesla – в феврале 2025 года. В своем твите он описал это как программирование в состоянии глубокого погружения, где ты полностью доверяешь AI-ассистенту генерацию кода, фокусируясь на высокоуровневых задачах и творческом процессе.

Звучит красиво. Но что это значит на практике?

Раньше дофамин выделялся дважды: когда ты понял проблему (ага-момент, награда за мозговой штурм) и когда код заработал (награда за результат). Это были глубокие, "медленные" награды.

Vibe-coding ломает эти паттерны. AI генерирует код моментально, и ты получаешь дофамин от быстрых результатов, минуя этап глубокого понимания. Промпт → код → результат → снова промпт. Цикл сжимается с часов до нескольких минут. Источник вознаграждения переключается: с понимания на скорость.

Немного про масштаб явления. Согласно систематическому обзору из arXiv (проанализировано 101 источник), 62% разработчиков называют скорость и эффективность основной мотивацией для vibe-coding. Инструменты вроде Cursor Composer, Windsurf Cascade, Claude Code и Cline создают всё более плавные циклы "запрос-ответ".

В самом отчёте достаточно много интересных цифр. Но что это делает с мозгом?

Нейробиология: что происходит с мозгом

Дофамин – это не просто "гормон удовольствия". Это нейромедиатор системы вознаграждения, который отвечает за мотивацию, обучение и формирование привычек. Когда мы используем Cursor AI или Claude Code, активируются те же самые механизмы, что и при игре в слоты или скролле shorts-ов. Только теперь объект зависимости – программирование (дожили).

Переменное подкрепление: почему это работает как игровой автомат

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

Vibe-coding работает так же. Каждый промпт – это рычаг слота: иногда код идеален (джекпот), иногда нужно допилить (частичный выигрыш). Ты никогда не знаешь, что получишь, и это держит в игре. Nicolas Martin называет это "переменно-пропорциональным подкреплением" – тот же механизм, что в игровых автоматах.

Когда Cursor генерирует код, ты испытываешь:

• Кайф от промежуточного успеха – код работает и мозг уже радуется

• Лёгкий выигрыш – потратил минимум усилий, а результат выглядит весомо

• "Ещё чуть-чуть и всё" – врождённое желание довести до конца, даже если уже час топчешься на месте

AI генерирует код, который "почти работает" → ты исправляешь пару строк → тесты зелёные → дофаминовый всплеск → хочется повторить. Мозг начинает ожидать быстрых наград и требует их всё чаще.

Состояние потока

Vibe-coding создаёт условия для состояния потока – того самого, где время летит незаметно и всё получается легко. В потоке мозг производит целый коктейль: дофамин (фокус), норадреналин (внимание), эндорфины (эйфория). Исследования это подтверждают (Frontiers in Psychology).

AI-ассистенты создают эти условия искусственно: рутина уходит, остаётся только творческая часть. Ты проваливаешься в 40-минутные сессии, где отладка превращается в медитацию.

Ну и где подвох, автор?

Риск: переобучение дофаминовых рецепторов

Регулярный вайб-кодинг может вести к переобучению дофаминовых рецепторов – по аналогии с другими видами поведенческой зависимости (игры, соцсети, азартные игры).

Механизм простой: мозг адаптируется к постоянным дофаминовым всплескам, снижая чувствительность рецепторов. Для получения того же уровня удовольствия требуется всё больше стимуляции.

Результат? Когда AI не доступен, традиционное программирование кажется медленным и неудовлетворительным. Снижается терпимость к глубокому, "медленному" обучению. Ты уже не можешь часами сидеть над одной задачей, разбираясь в архитектуре – мозг требует быстрых наград.

Это и есть поведенческая зависимость от AI-ассистентов.

Быстрый дофамин: почему вайб-кодинг вызывает зависимость

"Быстрый дофамин" – это термин, который набирает популярность в контексте цифровых привычек. Он описывает награды, которые требуют минимум усилий, но дают мгновенное удовлетворение: TikTok, игры, нотификации. Vibe-coding попадает в ту же категорию.

Стоит чуть подробней рассказать про плюсы и минусы этого феномена.

Положительные эффекты

На своём личном опыте вот что работает:

Снижение порога входа

Для людей с гибким мышлением и техническим бэкграундом AI-ассистенты открывают доступ к иному виду программированию. Например быстро изучить новый стек. Раньше нужно было неделями изучать синтаксис, паттерны, архитектуру. Теперь можно создать рабочий прототип за часы.

Я сам это почувствовал: когда написал ноду для n8n через Cursor, вместо выходных потратил пару часов. Раньше пришлось бы изучать документацию, TypeScript, UI-компоненты. Сейчас – просто объяснил задачу AI. Мне здесь в какой-то мере помогли знания из Python/Lua (понимание как в общих чертах работает любой из ЯП).

Быстрое создание прототипов

Вместо недель – дни или даже часы. Это создаёт ощущение прогресса и компетентности. Ты видишь результат сразу, а не через месяц разработки.

Снижение выгорания

Когда кодинг становится приятным (дофаминовая петля), усталость снижается. Команды, практикующие vibe-coding, сообщают о более высокой удерживаемости разработчиков.

Отрицательные эффекты

А теперь о том, что меня настораживает.

Дофаминовая зависимость

Быстрый цикл обратной связи геймифицирует процесс, превращая разработку в аддиктивное состояние потока. Разработчики тратят сотни долларов на AI-токены, преследуя следующий "удачный промпт".

Я сам это ощутил: мозг привык к быстрым наградам. Tab, Tab, Tab и ещё раз Tab!

Снижение качества архитектурного мышления

Когда дофамин поступает от результата, а не от понимания, страдает способность к глубокому мышлению. Это приводит к появлению "braindead coders" – разработчиков, которые не могут отладить сложные системы без AI.

Как я писал в посте про vibe-coding: AI отлично генерирует код в вакууме, но не понимает контекст живого проекта. Код не вписывается в архитектуру, ломает соседние модули, игнорирует внутреннюю политику обработки ошибок.

Парадокс продуктивности

Несмотря на быструю генерацию кода, реальная производительность повышается не так сильно, как кажется. Согласно анализу индустрии, реальный рост составляет 10-30%, а не обещанные маркетологами сотни процентов. А исследование METR 2025 показало, что на сложных задачах разработчики с AI были на 19% медленнее из-за времени на отладку AI-ошибок.

Порой я тоже трачу кучу времени на исправление галлюцинаций вместо программирования. Правда вместо гугла и stackoverflow теперь у меня perplexity.

Подводные камни и грабли

Что бесит в vibe-coding?

Время уходит на убеждение AI, а не на программирование

Я трачу 30 минут на то, чтобы переформулировать промпт так, чтобы Cursor понял, что я хочу. Модель упорно игнорирует контекст, генерирует код, который ломает соседние модули, забывает про обработку ошибок. Переделываю снова. И снова. Не всегда это ускорение.

Траты на токены превращаются в финансовую зависимость

Сотни долларов в месяц на OpenRouter, Cursor, Claude и так далее. И ты не можешь остановиться, потому что мозг уже привык к быстрым циклам. Это как подписка на казино – платишь за право крутить рулетку промптов.

Архитектурные костыли копятся в тишине

AI не понимает вашу кодовую базу. Он генерирует решение, которое работает сейчас, но создаёт технический долг на будущее. Вы не замечаете, потому что дофамин от зелёных тестов перекрывает сигналы тревоги.

Через три месяца оказывается, что половина кода – это костыли, которые никто не понимает. Включая вас.

Я не знаю, как с этим бороться

Если честно, я до сих пор не нашёл идеального решения.

1. Пробую делать детокс от AI на пару дней – пишу код руками, решаю алгоритмические задачи на LeetCode. Помогает временно, но потом снова втягивает.
2. Использую human-loop и стараюсь создать больше барьеров для AI (тесты, подробные спецификации, линтеры).
3. Допольнительный "AI-судья" на базе другой модели, которые модерирует работу оснвой модели, чаще это роль AI-QA-инженера.

Касательно того, что у нас в голове, то работает хоть как-то – это осознанность. Детектить моменты, когда ты не программируешь, а гоняешься за дофамином. Это сложно... потому что граница размыта.

Как контролировать дофаминовые циклы

Если мы не можем полностью отказаться от AI-ассистентов (можно, но зачем?), нужно научиться использовать их так, чтобы дофамин работал на нас, а не против нас.

Гибридный подход: AI + ручное кодирование

Используйте vibe-coding для прототипирования, где быстрые циклы полезны:

• Черновая разработка MVP

• Генерация boilerplate-кода

• Быстрое тестирование идей

Возвращайтесь к ручному кодингу для архитектурных решений:

• Проектирование API

• Критичные части системы (обработка платежей, безопасность)

• Рефакторинг и оптимизация

Так вы сохраняете глубокое мышление и не даёте дофаминовым рецепторам полностью переобучиться.

Контролируйте переменное подкрепление

Установите лимиты на AI-запросы:

• Максимум 10 промптов на одну задачу

• Если за 10 попыток AI не справился – переключайтесь на ручную работу

Это разрывает аддиктивный цикл "ещё один промпт, и точно получится".

Сохраняйте "медленное" обучение

Регулярно решайте алгоритмические задачи без AI:

• LeetCode, Codewars, HackerRank

• Чтение классических книг по алгоритмам

• Code review чужого кода вручную

Это поддерживает пластичность мозга в области глубокого понимания и не даёт дофаминовым рецепторам полностью атрофироваться.

Структурируйте сессии

AI-ассистенты создают иллюзию бесконечного потока работы. Используйте Pomodoro-таймеры (25 минут работы, 5 минут отдыха), чтобы разбивать сессии на управляемые блоки и делать осознанные паузы для рефлексии.

Настройте окружение: тёмные темы редакторов с низкой стимуляцией (тёмно-фиолетовые, мягкие синие тона), отключайте уведомления от AI-ассистентов, когда работаете над задачами, требующими глубокого мышления.

Что с этим делать

Связь между дофамином и vibe-coding – всё же есть и в данном материале я попытался это максимально подробно объяснить. И если по простому – это нейрохимия, которая переформатирует программирование.

Вот к чему я пришёл за несколько месяцев работы с AI-ассистентами:

• Дофамин – это инструмент, не цель. Используйте его для ускорения, но не давайте заменить глубокое понимание.

• Гибридный подход – единственное, что работает

Идеально? Нет. Но пока лучшего не нашёл. Может, я преувеличиваю, но мозг – штука хитрая, и с ним лучше не шутить.

Я буду продолжать экспериментировать и делиться результатами в своём блоге. Там регулярно пишу про автоматизацию, AI-инструменты и продуктивность. Если хотите узнать больше про интеграцию AI с автоматизацией, почитайте мой пост про MCP – там про то, как AI стал штурманом в мире документации для меня.

Вопрос к вам

А вы замечали у себя признаки зависимости от AI-ассистентов? Не можете уснуть после долгой сессии с Cursor? Тратите сотни долларов на токены, гоняясь за идеальным промптом? Обычное программирование кажется слишком медленным?

Делитесь в комментариях – интересно узнать, как вы контролируете дофаминовые циклы. Или может, вы считаете, что это вообще не проблема?

Что случится с моими AI-агентами, если завтра OpenRouter перестанет быть доступным в РФ? Не «если вдруг когда-нибудь», а вполне конкретное завтра. Я потратил несколько недель на то, чтобы собрать примерный план на подобный сценарий и делюсь результатами.

Почему я вообще об этом думаю

Месяц назад я проснулся и увидел, что мой основной workflow в n8n лежит. OpenRouter словил какие-то проблемы то ли с биллингом, то ли с сетью. Это была не блокировка, просто технический сбой. Чинили часов шесть. За это время я потерял около десятка обработанных цепочек. Не сказать, что там было что-то прям очень важное, но я задумался, а что если там вместо 30 упавших вызовов было 3000 и, например, вместо парсинга/автоматизации там был вполне работающий MVP, за который уже платили бы клиенты...

В целом жить можно, но я такой тип личности, который любит накручивать и следующая мысль, меня добила: «а что если это не на шесть часов, а навсегда?»

Не то чтобы я параноик. Но когда твой бизнес зависит от сервиса, который в любой момент может сказать «извините, ваш регион больше не поддерживается» – не паранойя, это risk management.

Я начал копать. Смотрел, что делают крупные компании, что пишут в профильных чатах, какие альтернативы реально работают. Собрал всё в кучу и вот что получилось.

Локальные модели в российских облаках

Моя ставка это open-source модели (Qwen, DeepSeek, GLM), развёрнутые на российских облачных платформах.

Почему именно так:

Qwen3 и DeepSeek-V3 – это не какие-то второсортные альтернативы. DeepSeek-V3 реально конкурирует с GPT-4 на задачах кодинга и логики. Qwen3 сносно работает с русским языком – лучше, чем многие западные модели старого поколения.

Помимо этих двух ребят, ещё присматриваюсь к этим:

• GLM-4.6

• GigaChat3

• YandexGPT-5

Про GigaChat и YandexGPT

Тут всё неоднозначно, и я не буду делать вид, что это идеальные решения.

Что реально хорошо:

Обе модели полностью адаптированы под русский язык. Серверы на территории РФ, можно закрепить SLA в договоре.

GigaChat от Сбера активно развивается. В декабре 2025-го они выложили в open-source модель на 702 миллиарда параметров – крупнейшую русскоязычную LLM. Лидирует в бенчмарке MERA для русского языка, превосходит GigaChat Max 2 и Gemini 2.0 Flash на русском.

Что напрягает:

Тарифы выше, чем у локальных решений при массовом использовании. Требуется интернет и API-ключи — то есть это не полная автономность. Для этого материала я не смог найти в открытых источниках их итоговый предоставленный SLO за 2025 год. Будем верить, что ребята поддерживают высокий уровень стабильности.

И главное: я пока не уверен в стабильности работы с инструментами (function calling). А для моих AI-агентов это критично – 80% полезной работы агента это именно адекватное использование тулзов. Бенчмарки красивые, а вот как модель поведёт себя в реальном workflow с десятком интеграций – большой вопрос.

Ещё один важный момент: у всех моих AI-агентов системные промпты, инструкции и подсказки — на английском. Сделал это для экономии токенов и потому, что изначально вся архитектура была заточена именно под зарубежные LLM. На практике замечал, что отечественные реализации из-за этого начинают работать не так эффективно.

Мой вердикт: использовать как резервный уровень для критичных задач, а не как основу. Основа – open-source развёрнутый в облачном сервисе.

Guardrails: защита данных уже сейчас

Независимо от того, какой провайдер я использую, есть одна штука, которую я делаю уже сейчас – очистка данных перед отправкой.

Писал об этом в блоге: в n8n появился нативный узел Guardrails. Настраивается без кода, умеет ловить персональные данные, секретные ключи, URL, поддерживает кастомные regex-правила.

Зачем это нужно:

1. Минимизация рисков – даже если OpenRouter никуда не денется, отправлять чужие паспортные данные во внешний API это так себе идея. Вот просто поверьте, порой в чат-бот шлют и не такое... А кто потом виноват будет? Правильно, создатель бота.

2. Проще миграция – когда данные уже очищены на входе, мне всё равно, через какой провайдер они идут дальше

3. Compliance – если завтра придёт аудит, у меня есть ответ на вопрос «как вы защищаете ПДн»

Работает в двух режимах:

• Без LLM (Sanitize Text) – быстрая очистка по паттернам, ловит стандартные форматы

• С LLM (Check Text for Violations) – глубокая проверка на jailbreak, nsfw, topical alignment. Вот тут как раз и пригодятся небольшие open-source LLM модели на РФ серверах.

Я использую первый режим на входе всех агентов, которые работают с клиентскими данными. Накладные расходы минимальны, а головной боли сильно меньше.

Evaluation: как я тестирую резервные модели

Окей, у меня есть три-четыре потенциальные замены для текущего провайдера. Как понять, какая из них реально сработает для моих задач?

Ответ: n8n Evaluation. Встроенная система для тестирования AI-цепочек.

Механика простая:

1. Готовишь табличку с тестовыми примерами: входные данные и эталонный ответ

2. Настраиваешь ветку с логикой оценки

3. Запускаешь прогон и смотришь score

У меня сейчас несколько десятков проверочных кейсов для основных workflow. Раньше на ручную проверку уходили дни. Теперь меняю модель, жму кнопку, через 20-30 минут вижу результат.

Что я тестирую:

• Качество ответов на русском языке

• Работу с function calling

• Скорость обработки

• Стабильность при повторных запросах

Мой совет: не верьте чужим бенчмаркам. Соберите свои тесты под свои задачи. То, что модель хорошо пишет стихи и посты для продаж, не значит, что она правильно вызовет ваш API.

Если вдруг есть свой домашний сервер

Если облачные провайдеры – это план Б, то локальный запуск – план В. На случай, если вообще всё ляжет.

Ollama – Простой, лёгкий, OpenAI-совместимый API из коробки. Запускается одной командой, работает даже на MacBook M1. Писал даже подробную инструкцию, как всё это у себя организовать.

vLLM – пропускная способность выше, чем у Ollama. Но раскрывается на полную только тогда, когда у вас планируется кластер GPU.

Квантизация – это то, что делает локальный запуск реальным на обычном железе:

• 4-битная квантизация GGUF сокращает модель примерно в 7-8 раз

• Потеря качества обычно минимальна (но зависит конечно от рук того, кто проводил квантизацию)

• Энергопотребление в среднем падает более чем на 50%

Мой текущий стек и план миграции

Вот как это выглядит у меня сейчас:

• Основной провайдер: OpenRouter (GPT-4, Claude)

• Резерв первого уровня: Отечественное облако №1, где развернуты локальные LLM (Qwen / GigaChat)

• Резерв второго уровня: Отечественное облако №2 с автоматическим fallback (если ляжет облако 1)

• Локальный резерв: Нет, ищу подходящее железо. Если вдруг у вас есть в этом опыт – буду рад услышать ваше мнение в комментариях! A100 / H100 не предлагать.

План миграции:

• Шаг 1 (сделано): Все агенты используют абстракцию над провайдером. Смена endpoint – одна строка конфига.

• Шаг 2 (сделано): Guardrails на входе всех workflow с клиентскими данными.

• Шаг 3 (в процессе): Еженедельное тестирование резервных моделей через Evaluation. Слежу за качеством, чтобы при переключении не было сюрпризов.

• Шаг 4 (планируется): Добавить в агенты автоматическое переключение при ошибках провайдера.

Чего я не знаю и что может пойти не так

Производительность под нагрузкой. Я тестировал резервные модели на своих объёмах. Но что будет, если весь ру-рынок одновременно побежит на сервисы, которые я выбрал – не знаю. Могут быть очереди, задержки, проблемы со стабильностью.

Function calling. Скорее всего этот риск сработает. Open-source модели догоняют по качеству текста, но работа с инструментами – всё ещё не самое стабильное место. Сложные цепочки вызовов могут ломаться.

Долгосрочная поддержка. Отечественные облака сегодня активно развиваются. Но что будет через год? Не изменят ли тарифы в 10 раз? Будет ли и дальше сходиться та же юнит-экономика?

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

Мой главный takeaway: нет идеального решения. Есть только диверсификация. Несколько провайдеров, несколько уровней резерва, регулярное тестирование. Паранойя? Может быть. Но лучше потратить время на подготовку, чем потом в панике искать решение.

Выводы и чек-лист для таких же как я

Локальные и отечественные LLM могут закрыть 70-80% потребностей при правильной архитектуре. Это не полная замена GPT и Claude – творческие задачи, сложные рассуждения, edge cases всё ещё лучше у западных моделей. Но для автоматизации рутины, обработки текстов, работы с русским контентом – вполне достаточно.

Чек-лист подготовки:

• Абстрагировать код от конкретного провайдера (один конфиг для смены endpoint)

• Настроить Guardrails для очистки данных перед отправкой

• Собрать тестовый датасет под свои задачи (минимум 50 кейсов)

• Выбрать минимум два отечественных облака и убедиться, что серверы в РФ

• Прогнать свои workflow через резервные модели

• (Опционально) Настроить локальный Ollama для критичных задач

• Документировать процедуру переключения

А вы уже думали о плане Б? Или пока живёте по принципу «авось пронесёт»? Интересно послушать, какие варианты рассматриваете – пишите в комментарии.

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

Зачем вообще считать

Меня всегда раздражали статьи в духе «AI экономит время». Окей, экономит. Сколько? «Много». Спасибо, очень полезно.

Когда я начал осознанно пользоваться AI-инструментами, решил вести что-то вроде дневника: где использовал, сколько времени потратил, сколько бы потратил без этого. Не каждый день, конечно – это было бы уже перебор. Но достаточно, чтобы через N-ое количество месяцев вывести более-менее честные цифры.

Дата старта эксперемента: начало Июля 2025 и вот что получилось...

Perplexity: 200 часов на ресёрче

Я писал про Perplexity отдельную статью, но тогда у меня не было статистики за длительный период. Теперь есть.

Как я использую:

• Режим «Исследование» для глубоких вопросов – примерно 1-2 раза в день

• Обычные запросы – 5-10 штук ежедневно

Что искал за эти месяцы:

Бытовое:

• Сравнение техники (выбирал новый телевизор, телефон, мелкую техничку для дома – Perplexity за 15 минут собрал мне сравнительную таблицу с актуальными ценами и отзывами)

• Рестораны и места, особенно в незнакомых городах

• Исследования по разным бытовым вопросам (от «как правильно хранить кофе» до «найди мне ПП рецепты, у меня дома сейчас есть вот это, это и это»)

Рабочее:

• Изучение новых библиотек – Perplexity разжёвывает документацию, собирает отзывы из разных источников, показывает подводные камни

• Подготовка планов ресёрча для команды

• Сбор информации по конкурентам и рынку

• Анализ финансовых показателей компаний по моему инвестиционному портфелю

Формула расчёта:

Глубокое исследование в режиме «Исследование» vs Google:

• Google: открыть 10-15 вкладок, прочитать, отфильтровать рекламу и SEO-мусор, скомпилировать = 60-90 минут

• Perplexity: получить структурированный ответ со ссылками, уточнить пару follow-up вопросов = 15-20 минут

• Экономия: ~45 минут на запрос

Обычный запрос:

• Google: найти релевантную статью среди рекламы, прочитать = 10-15 минут

• Perplexity: получить ответ сразу = 2-3 минуты

• Экономия: ~10 минут на запрос

Итого за 4 месяца (120 дней):

• Глубокие исследования: 1.5/день × 45 мин × 120 = 8100 минут

• Обычные запросы: 7/день × 10 мин × 120 = 8400 минут

• Всего: ~275 часов, но округляю до 200 часов

Почему округляю вниз? Потому что не каждый день я работал, были выходные, отпуск, дни когда вообще не было ресёрча. Честные 200 часов.

n8n + AI: 80 часов на автоматизации

Здесь интересно. Сама по себе экономия от автоматизаций – это одно. Но я хочу выделить именно те автоматизации, где AI является ключевым компонентом.

Мой последний проект – анализатор на базе AI с доступом к Wordstat.

Идея простая: вместо того чтобы самому лезть в Wordstat, анализировать тренды, думать о чём писать – я сделал агента, который:

• Парсит текущие тренды из Wordstat

• Анализирует их через LLM

• Выдаёт рекомендации: на что обратить внимание, какой материал подготовить, что сейчас интересно аудитории

Раньше такой анализ у меня занимал 2-3 часа в неделю. Теперь – 15 минут на просмотр результатов.

Другие автоматизации:

• Парсеры разных источников, которые складывают готовые данные в нужное место к нужному времени

• Обработчики входящего контента с AI-фильтрацией

Формула:

Экономия на автоматизациях = время ручной работы × количество повторений - время на создание

Мои автоматизации в сумме экономят 2-3 часа в неделю. За четыре месяца (с учётом времени на отладку и исправление багов) это 80 часов.

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

Voice to Text: 20 часов за месяц

Признаюсь честно: долго стеснялся использовать голосовой ввод. Казалось, что это как-то странно – сидеть и диктовать текст компьютеру. Типа для пожилых людей или тех, кто не умеет печатать.

А потом посчитал скорость.

Факты:

• Средняя скорость печати: 250-300 символов в минуту (это у тех, кто печатает хорошо)

• Средняя скорость речи: 750-900 символов в минуту

• Whisper распознаёт с точностью 95-99%

Где использую:

Первые черновики постов и статей. Этот самый черновик, который ты сейчас читаешь – я надиктовал за 12 минут вместо 35-40 минут печати. Да, потом пришлось редактировать, но редактировать всегда проще, чем писать с нуля.

Промпты для AI. Когда диктуешь, мысль течёт свободнее. Получается детальнее объяснить задачу, не упуская контекст. Замечал, что надиктованные промпты работают лучше напечатанных.

Заметки и идеи. Пришла мысль – быстро надиктовал в Whisper, получил текст. Не потерял, не забыл.

Формула:

Если каждый день диктовать контент на 2000-3000 символов:

• Печатать: 10-12 минут

• Диктовать + редактировать: 4-5 минут

• Экономия: ~7 минут

30 дней × 40 минут среднего голосового ввода × коэффициент экономии 0.5 = ~20 часов за месяц.

Честно – за первые пару дней было неловко. Но потом привык. И теперь не понимаю, как раньше жил без этого.

Вайбкодинг: 200+ часов разработки

Самый жир. И самый сложный для подсчёта раздел.

Что использую:

• Cursor – основной редактор

• Claude Code – для сложных задач и рефакторинга

• Antigravity – для быстрых прототипов

Реальные кейсы:

Ноды для n8n. Написал несколько кастомных нод, включая интеграцию с Telegram Stars. Без AI-ассистента я бы убил выходные на изучение архитектуры нод, TypeScript и UI-компонентов. С Cursor – объяснил задачу, получил работающий код, допилил детали. Вечер вместо двух дней.

Парсеры и скрипты. Раньше каждый парсер – это час-два чтения документации, поиск примеров, отладка. Теперь: «напиши парсер для X, данные положи в Y, обработай ошибки Z». 15-20 минут с учётом тестирования.

Из основной работы:

Рефакторинг. Вот это вообще магия. Раньше рефакторинг большого объёма кода – это день страданий. Теперь: объясняю AI что хочу поменять, он предлагает план, я корректирую, он делает. Пара часов вместо полного рабочего дня.

Автотесты. Адаптировал часть своей рутины по автоматизации и работе с тестами. Например автоматическая починка по линтеру, объяснение кода, предложение идей по повышению стабильности.

Формула (очень примерная):

Задача на разработку без AI: X часов Задача на разработку с AI: X/3 или X/4 часов (в зависимости от сложности)

За 3 месяца активного вайбкодинга, если считать все задачи:

• Примерно 80-100 задач разного размера

• Средняя экономия на задачу: 2-3 часа

• Итого: 200-250 часов

Беру нижнюю границу – 200 часов.

Но есть нюанс. Писал об этом раньше – я практически перестал использовать «голый» ChatGPT или Gemini в браузере. Все мои коммуникации идут через подготовленных AI-агентов с системными промптами и инструментами. Это даёт намного лучший результат, чем просто «спросить у AI».

Всё ли так хорошо?

Было бы нечестно писать только про экономию. Есть и обратная сторона.

Perplexity:

• Иногда выдаёт устаревшую информацию (особенно по техническим темам – версии библиотек, deprecated методы)

• Не всегда понимает контекст узкоспециализированных вопросов

• Дурит с ценами в магазинах

• Pro-подписка стоит денег, а бесплатной версии не хватает для серьёзного ресёрча

n8n + AI:

• Автоматизации ломаются. Регулярно. API меняются, токены истекают, сервера падают. Мониторинг обязателен

• Время на первоначальную настройку съедает часть экономии в первые месяцы

• Галлюцинации LLM в автоматизациях – это отдельная боль. Нужны валидации. Очень много валидации

Voice to Text:

• Работает хорошо только в тихом помещении

• Русский язык Whisper понимает хуже английского (хотя для меня достаточно)

• Так и не смог найти что-то стоющее на свой Android (пользуюсь только на ноуте)

• Форматирование в надиктованном тексте – боль. Приходится всё равно руками расставлять абзацы и заголовки

Вайбкодинг:

• AI генерирует код в вакууме. Без контекста и продуманных спецификаций проекта получается мусор, который ломает соседние модули

• Время переместилось с кодинга на написание спецификаций и ревью. Это другой навык. Тут кстати прям очень выручает пункт выше (Voice to text)

• Иногда проще написать самому, чем объяснять AI что ты хочешь

• Код от AI требует тщательного ревью – бывает красивый, но неоптимальный или с неочевидными багами

И главное: AI не заменяет понимание. Если не понимаешь, что происходит в коде – AI усилит твою некомпетентность, а не компенсирует её.

Промежуточные итоги

Сводная таблица:

500 часов – это 62.5 рабочих дня. Или три месяца полноценной работы.

За пять календарных месяцев (1 месяц был так называемой фазой моральной подготовки) я вернул себе три месяца рабочего времени. Какие-то вещи, я запустил не сразу (например я только в последний месяц смог значительно отпимизировать использование Voice to text + вайбкодинг).

Что это значит на практике:

• Значительный буст на основной работе

• Больше pet-проектов (написал несколько open-source нод для n8n, а также сейчас сижу над разработкой небольшого приложения)

• Больше контента (этот канал и статьи существуют во многом благодаря освободившемуся времени)

• Меньше выгорания от рутины

• Больше времени на то, что реально требует человеческого мозга – стратегию, архитектуру, общение

• Не жертвую временем с семьёй, отдыхом, спортом

Что планирую дальше:

• Углубляться в агентные системы – там потенциал ещё больше

• Пробовать новые инструменты для Voice to Text (есть надежда на локальные решения, сейчас мне приходится фильтровать то, что я говорю, ибо не всё должно быть услышено «старшим братом»)

• Выстраивать более системные подходы к вайбкодингу – сейчас это всё ещё скорее искусство, чем инженерия. Присматриваюсь к более жёсткому контролю через паттерны feedback-loop для AI.

Практический чек-лист, если хочешь повторить:

1. Начни с ресёрча. Попробуй Perplexity на реальной задаче – сравнить с Google будет легко

2. Один workflow в n8n. Найди рутину, которую делаешь каждую неделю, и автоматизируй её

3. Voice to Text. Надиктуй следующую большую заметку или документ. Не стесняйся – никто не смотрит (но ничего не гарантирую)

4. Cursor или Claude Code. Возьми задачу, которую откладывал, и попробуй решить с AI-ассистентом

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

А как у вас с экономией времени на AI? Считали когда-нибудь конкретные цифры или тоже живёте ощущениями? Интересно сравнить.