Есть правило, которое держится лучше, чем «всегда используй» или «никогда не доверяй»: ассистент хорош там, где по теме много однородного публичного кода и результат можно быстро проверить. И он проседает по мере движения к редким платформенным API, форматам файлов, которыми владеет редактор, и системам, где единственный настоящий тест — устройство в руке конкретного человека.
Почему это важно именно вам. Большинство отзывов про Claude Code, Cursor и подобные штуки написаны людьми, которые весь день живут в одном веб-фреймворке. Мнение честное, но усреднённое. В реальном проекте слоёв несколько, и качество генерации падает по вполне предсказуемому направлению. Если не понимать, где проходит эта граница, вы либо недоиспользуете инструмент на скучной рутине, либо пускаете его туда, где ошибка стоит дорого.
| Слой | Что делаю | Насколько доверяю | Как проверяю |
|---|---|---|---|
| Спецификация → черновик | Пишу спеку, отдаю генерацию определений функций, скелетов n8n-вебхуков, тестовых сценариев | Высоко | Прогон сценариев, чтение диффа |
| Конфиг в файлах: CI YAML, схемы, шаблоны окружений | Правлю и прошу объяснить | Высоко | Дифф плюс валидатор |
| Незнакомый код | Прошу карту: где значение пишется, кто его читает | Средне | Сверяю карту с кодом руками |
| Тесты | Юнит-тесты, фикстуры, граничные входы, регрессии для голосового агента | Средне | Неправильный тест падает громко |
| Нативный код: Android VpnService, iOS Network Extensions, C#-ядро под три ОС | Только как быстрый читатель документации | Низко | Реальное устройство и версия ОС |
| Сцены и префабы Unity | Не трогаю через модель | Не доверяю | Редактор Unity |
| AR-выравнивание, продакшн-номера, платежи, медданные, секреты | Не делегирую целиком | Нет | Стою с телефоном на месте, живой тестовый звонок |
Где инструмент реально экономит время
Спецификация, превращённая в первый черновик
Самый чистый выигрыш у меня был на пайплайне для сборки и тестирования голосовых агентов в Fortell AI. Важна там была не формулировка промпта, а спека. Как только на бумаге появились поля для захвата, инструменты, которые агент может вызывать, и правила эскалации, ассистент за один проход выдал определения функций, скелеты вебхуков n8n и тестовые сценарии.
Это обобщается на что угодно. Размытая просьба даёт правдоподобную догадку. Точная — почти то, что я напечатал бы сам, только быстрее. Основной навык тут в спецификации, а не в магии промптинга.
Конфиг, который живёт в файлах
Определения воркфлоу, CI YAML, шаблоны окружений, типы, сгенерированные из GraphQL-схемы, конфиг голосового агента, выгруженный из вендорской панели. У всего этого понятная форма, понятный дифф и обычно валидатор. Конфиг в файлах инструмент может прочитать, изменить и объяснить, а ревьюер — сравнить. Конфиг, который существует только в веб-панели, невидим для обоих.
Разбор чужого кода
Как fractional CTO я регулярно захожу в код, который писал не я. Раньше первые дни уходили на ручное трассирование потоков данных. Теперь я прошу инструмент построить карту: где значение записывается, какие экраны его читают, что вызывает этот эндпоинт.
Карту всё равно сверяю с кодом. Уверенный неправильный ответ про архитектуру хуже, чем отсутствие ответа. Зато как способ сориентироваться это самая большая экономия времени из всего, что я нашёл, и самый безопасный сценарий: ничего из сказанного не уезжает в прод.
Тесты, которые иначе бы не написали
Юнит-тесты на чистую логику, фикстуры, граничные входы, замороженные регрессионные сценарии для голосового агента. Неправильный тест обычно падает громко, поэтому генерировать тесты — занятие прощающее. Главная выгода тут экономическая: скучный набор становится достаточно дешёвым, чтобы его наконец написали.
Где держу на коротком поводке
Нативный платформенный код
Здесь я видел больше всего уверенной бессмыслицы. В React Native VPN-приложении реальное поведение живёт в Android VpnService и расширениях сети на iOS, с entitlements, отдельными процессами и фоновыми правилами, которые отличаются от системы к системе и от версии к версии.
Инструмент охотно выдаст метод, которого не существует, поток разрешений, устаревший две версии назад, или предположение о жизненном цикле, которое ломается только на живом устройстве после десяти минут в фоне. Ни одна из этих ошибок не падает на компиляции очевидным образом. Часть не падает вообще, пока пользователь не напишет в поддержку. Инструмент тут использую, но как быстрого читателя документации, которую потом проверяю сам. С кросс-платформенным ядром на C# для Geonode было то же самое: общую логику генерировать нормально, платформенные края — нет.
Всё, чем владеет редактор
Unity сериализует сцены и префабы в YAML, и он выглядит как обычный текст, который модель может править. На практике внутри object ID и ссылки, которыми управляет редактор. Синтаксически корректная правка тихо ломает ссылку, которую вы заметите только в рантайме.
Граница для меня проходит по владению форматом, а не по конкретной модели. Скрипты C#, editor tooling, build-скрипты — пусть пишет. То, что принадлежит редактору Unity, — нет. Если файл не стоит править руками человеку, модели тоже.
Визуальная и пространственная работа
В AR вопрос «работает ли» часто означает «совпадает ли с реальным миром, когда стоишь там с телефоном в руке». Ни один инструмент этого не видит. Координатную математику сгенерировать можно. Дрейфанул ли якорь на полметра на реальном устройстве — это полевой тест, а не код-ревью.
Куда не пускаю вообще
- Продакшн-номера, SMS и всё, что разговаривает с реальными клиентами. Неверно настроенная переадресация или тестовое сообщение живому лиду не откатываются.
- Деньги и данные пациентов. Платёжные потоки, логика цен, клиническая работа, голосовые агенты для больниц. Объём ревью там тотальный, поэтому сэкономленное на генерации время стремится к нулю.
- Секреты. Клиентские API-ключи, keystore, креды не уходят в промпт. Инструменты читают то, что лежит в репозитории и в терминале, поэтому секретам место в переменных окружения и в CI-хранилище.
- Решения, которые дорого отменить. Выбор голосовой платформы, модель данных, где источник истины, в какой момент медицинский агент передаёт разговор человеку. Список вариантов инструмент соберёт. Выбор и ответственность остаются на мне — за это клиент и платит CTO.
Рабочие правила, которые я соблюдаю
- Сначала спека, потом промпт. Если я не могу записать, как выглядит «готово», инструмент тоже не сможет.
- Каждое сгенерированное изменение читаю как код нового джуна. Дифф, запуск, граничные случаи. Не смёржил бы от человека — не мёржу от модели.
- Держу цикл маленьким. Одно сфокусированное изменение, проверка, следующее. Крупные неотревьюенные пачки — то место, где прячутся уверенные ошибки.
- Правила проекта — в репозиторий. Короткий контекстный файл со стеком, конвенциями и списком того, что трогать нельзя, экономит много неверных догадок. Заодно он работает как онбординг для следующего живого человека.
- Проверка на реальной цели. Устройство, настоящий тестовый звонок, staging. «Компилируется» не равно «работает», и разрыв шире всего там, где инструмент слабее.
- Внешний текст — недоверенный ввод. Агент, который читает веб-страницы или текст из issue, можно заставить делать то, о чём вы не просили. Права держу узко.
Что это меняет в мышлении
Честная версия: инструменты ускоряют ту часть проекта, которая никогда не была сложной. Обвязку, boilerplate, конфиг, каркас тестов, чтение незнакомого кода. Освободившееся время уходит на то, что действительно решает, поедет продукт или нет: архитектуру, граничные случаи, платформенное поведение и разговоры о том, что клиенту на самом деле нужно.
Не заменяют они человека, который понимает, почему сломалось ссылка в Unity, почему iOS-расширение убили в фоне и почему голосовой агент должен переводить звонок, а не отвечать сам. Скорее повышают цену такого знания: правдоподобного вывода стало много, и кто-то должен отличать рабочую часть от нерабочей.
Инструмент пишет — я владею.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.