Устал от AI в разработке? Проблема не в инструменте

Я не устал от AI. Я перестал с ним разговаривать.

Разница огромная.

Откуда берётся усталость — и почему диагноз неверный

В мае 2026 на Hacker News появился тред «I'm Tired of Talking to AI». Почти 2000 голосов за сутки. Комментарии — узнаваемые: «открываю чат, трачу час, ничего не готово», «ответы звучат умно, но не работают», «выгораю от постоянных итераций».

Я прочитал весь тред. Симптомы — правильные. Диагноз — нет.

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

Это как нанять джуна, посадить его рядом и говорить: «Ну, вот тут что-то не так, помоги разобраться». Через час вы оба устанете.

Разговорный режим против инструментального: в чём разница

Когда я начинал с Claude Code, я тоже разговаривал. «Посмотри на этот модуль, что думаешь?» «Как лучше организовать вот это?» «Предложи варианты».

Результат — длинные ответы, которые звучат убедительно, но требуют ещё 40 минут на то, чтобы разобрать и применить. После третьего такого диалога я закрывал ноутбук с ощущением, что потратил время впустую.

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

Вот разница на практике.

Было: «Помоги улучшить этот PHP-класс».

Стало: «Напиши PHPUnit-тест для метода CatalogSync::processChunk(). Сигнатура: array $items on input, SyncResult on return. Граничные условия: пустой массив, товар без цены, дубликат ID. Не трогай внешние зависимости — мокай. Формат: PSR-12».

На первый запрос я мог получить лекцию про принципы написания чистого кода. На второй — готовый тест через 25 секунд, который работает.

Это и есть разница между разговорным и инструментальным режимом.

Три правила, по которым я ставлю задачи Claude Code

За полгода работы с Claude Code в PHP-студии я дистиллировал три правила. Не принципы. Правила. Нарушение любого предсказуемо ведёт к итерациям, а итерации — к усталости.

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

Второе — контекст явный, не предполагаемый. Если Claude нужно знать, что у нас Bitrix D7 и PHP 8.2, я пишу это прямо. Если модуль использует кастомный event bus вместо стандартного AddEventHandler — я описываю это в первом абзаце. «Он и так поймёт» — источник половины всех плохих ответов.

Третье — scope ограничен, выход за пределы остановит меня. В каждой задаче я указываю, что не должно измениться: конкретные файлы, зависимости, паттерны. Claude Code с ограниченным scope не будет «улучшать» соседний модуль, потому что «там тоже можно поправить».

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

→ Подробнее о формате спецификаций: «Я пишу спецификацию до того, как прошу AI написать код»

Почему approval gates — это архитектура, а не паранойя

У меня есть задачи, которые Claude выполняет без моего участия. И есть задачи, где я смотрю результат перед применением. Это не случайность — это осознанная архитектура.

Правило простое: если ошибка обратима и дёшево исправляется — auto. Если ошибка видна клиенту или затрагивает контракт с внешней системой — approval gate.

Написать тест к существующему методу: auto. Изменить схему синхронизации с 1С: approval.

Это не недоверие к AI. Это то же самое решение, которое принимают при проектировании любой системы: где нужен человек в петле, а где нет. Убрать все gates — не про доверие, а про нежелание думать об архитектуре workflow.

→ О том, где я держу gates намеренно: «Где я держу approval gate — даже когда могу убрать его»

Что я измеряю теперь: не строки кода, а закрытые задачи без откатов

Классическая метрика AI-производительности — количество строк в день или скорость написания кода. Я перестал её считать.

Моя метрика: сколько задач закрыто без возврата к ним.

Хорошо поставленная задача для Claude Code закрывается один раз. Плохо поставленная — возвращается трижды, каждый раз с уточнением. Разница в качестве задачи заметна сразу: если я потратил 10 минут на формулировку, задача чаще всего закрывается с первого раза.

Три месяца назад я провёл простой подсчёт: задачи с чётким scope и явным контекстом закрывались без итераций в 78% случаев. Размытые запросы — в 31%.

Это и есть настоящая производительность с AI. Не скорость. Качество постановки.

Итог

Если вы устали от AI — не удаляйте приложение. Посмотрите на последние десять запросов.

Сколько из них были вопросами? Сколько — задачами?

AI не устаёт. Вы устаёте, когда ищете ответ от того, кто не знает, что именно вам нужно. Это не проблема инструмента. Это проблема формулировки.

→ Что именно нельзя давать AI: «Я даю Claude писать тесты. Я не даю ему выбирать архитектуру»