AI Fluency для разработчиков и продукта

Четыре D: петля, а не лестница

Работа с ассистентом ломается не там, где модель «недостаточно умная», а там, где размыто, кто и что решает. Рамка расставляет это по местам. Делегирование (delegation) — решаю, что вообще отдаю. Описание (description) — формулирую задачу так, чтобы её можно было и выполнить, и проверить. Оценка (discernment) — сужу о результате по существу, а не по гладкости текста. Добросовестность (diligence) — отвечаю за то, что ушло в релиз, вместе с последствиями.

Шаги не проходятся по порядку один раз — это петля. Модель выдумала параметр библиотеки: возвращаемся к описанию и даём кусок реальной документации. Проверить результат нечем: значит, промахнулись на делегировании, задачу надо резать мельче. За одну задачу петля закручивается несколько раз, и итог зависит от того, как быстро вы её замыкаете, а не от длины первого промпта.

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

Делегирование: что отдать, что поделить, что оставить себе

Первый вопрос — не «как попросить», а «что я отдаю». Разложите ближайшие задачи по трём режимам. Автоматизация: модель делает работу целиком, вы принимаете результат — перевести сорок файлов на новый способ импорта, разложить накопившиеся обращения поддержки по темам, написать скрипт разовой выгрузки. Совместная работа: вы ведёте, модель предлагает и переписывает — черновик спецификации, разбор незнакомого модуля, поиск причины плавающего бага. Совет: руки ваши, модель отвечает на вопросы — выбор схемы платежей, компромисс между версиями API, стоит ли делать фичу вообще.

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

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

Описание: техническое задание вместо просьбы

Разница между «сделай форму регистрации» и рабочим заданием — в четырёх блоках. Пока их нет, модель достраивает недостающее сама и почти всегда не туда. Соберите задание целиком до того, как нажмёте Enter, а не по одному уточнению за раз.

Постоянную часть контекста вынесите из промпта в файл проекта: в Claude Code это CLAUDE.md в корне репозитория. Внутри — стек с версиями, команды сборки, тестов и линтера, соглашения об именовании, каталоги, которые трогать нельзя. Держите его на одну страницу: раздутый файл устаревает и начинает врать. Приём переносится на любого агента — важна не конкретная реализация, а письменная память проекта, которую можно поправить одной правкой.

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

• Контекст: стек и версии, какие файлы относятся к задаче, что уже работает
• Результат: один глагол и наблюдаемый исход — «добавить эндпоинт POST /api/signup, который возвращает 201 и идентификатор пользователя»
• Ограничения: что нельзя трогать, какие библиотеки запрещены, какие правила стиля обязательны
• Форма ответа: дифф, план, таблица сравнения или список вопросов — иначе получите эссе там, где нужен патч

Оценка кода: читать дифф, а не сопроводительный текст

Объяснение модели о том, что она сделала, — самая убедительная и наименее надёжная часть ответа. Смотрите на изменения: `git diff --stat` показывает масштаб, дальше читаете построчно. Главный вопрос не «работает ли», а «что здесь поменялось ещё». Типичная картина: попросили поправить валидацию почты, а заодно переписан соседний хелпер, снята проверка прав и подтянута другая мажорная версия зависимости. Выглядит опрятно и собирается.

Порядок проверки экономит время: сначала машинное — линтер, проверка типов, тесты, аудит зависимостей (`npm audit`, `pip-audit`); потом человеческое — границы изменений, обработка ошибок, читаемость, соответствие требованию. Если падает первый слой, второй можно не начинать. И держите жёстко одно правило: код, который вы не понимаете, не мержится. Не потому, что он плохой, — просто чинить его в три часа ночи будете вы, а не модель, и «перепиши проще» здесь нормальная претензия на ревью.

• Вызовы и параметры, которых нет в вашей версии библиотеки, и устаревшие конструкции из старой документации
• Проглоченные исключения вроде `except Exception: pass` — ошибка исчезает молча
• Тесты, которые мокают ровно то, что должны проверять
• Дублирование вместо переиспользования: модель не видела готовую функцию в соседнем модуле
• Конкатенация строк в SQL, вывод в HTML без экранирования, ключи прямо в коде, доверие к данным из запроса

Оценка интерфейсов: где генерация выглядит лучше, чем работает

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

Доступность модель имитирует, но редко доводит. Проверьте контраст основного текста (ориентир WCAG — 4.5:1), проход по форме одной клавиатурой, видимый фокус, подписи, привязанные к самим полям, размер области нажатия на мобильном, осмысленные alt у картинок. Отдельная беда — тексты: «Произошла ошибка, попробуйте позже» не сообщает ничего. Сообщение должно называть причину и следующий шаг: «Не удалось сохранить: файл больше 10 МБ. Уменьшите размер и повторите».

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

• Пусто: ни одной записи, и вместо таблицы — подсказка, что делать дальше
• Загрузка и ошибка сети: видно, что запрос идёт, и видно, что он не прошёл
• Длинные значения: имя на 60 символов, сумма на девять знаков, текст на трёх языках
• Узкий экран около 360 пикселей и тёмная тема, если она есть в продукте
• Повторное нажатие кнопки отправки: не создаётся ли второй заказ

Приёмочные тесты: договор о том, что считается готовым

Критерии пишутся до генерации, иначе они подстроятся под то, что получилось. Форма простая: при каком условии, что делаю, что вижу. «Пользователь не подтвердил почту — открывает страницу оплаты — видит баннер с просьбой подтвердить и активную кнопку оплаты». На среднюю фичу хватает шести-девяти сценариев, и хотя бы треть должна быть отрицательной: неверный ввод, нет прав, истёкшая сессия, повторная отправка формы, обрыв сети посередине.

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

Разделяйте слои. Быстрые модульные тесты (`pytest -q`, `npm test`) ловят логику, браузерные проверки на Playwright ловят интерфейс. В браузерных ищите элементы по роли и подписи, а не по CSS-селекторам: селекторы ломаются при каждом переписывании вёрстки, а генерация переписывает её охотно. И держите хотя бы один сквозной сценарий, написанный человеком, — от входа пользователя до записи в базе.

Ответственность: кто подписывается под релизом

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

Организуйте выпуск так, чтобы ошибка стоила дёшево: флаг функциональности, чтобы выключить фичу без деплоя; понятный откат (`git revert` конкретного коммита, а не героическая починка на живом сервере); наблюдение в первые часы — логи ошибок, метрика ключевого действия, обращения в поддержку. Ведите короткий журнал прямо в задаче: что делегировали, чем проверяли, что решили не проверять и почему. Три строки, полминуты. Через месяц по нему видно, где ИИ реально ускоряет команду, а где работа просто переехала с написания на разбор чужих ошибок.

Деньги, доступ и трезвые ожидания

Доступ — статья бюджета, а не мелочь. Подписка покупается на человека, API оплачивается по токенам, и агентные режимы с большим контекстом жгут их быстрее, чем кажется по первым дням. Цены и лимиты поставщики меняют регулярно, поэтому в расчёт закладывайте порядок величины и способ оплаты, а не цифру из статьи. Для России сюда же добавляются VPN и зарубежная карта: обходных путей я не обещаю, и решать этот вопрос лучше до того, как процесс команды будет построен вокруг одного поставщика.

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

Практика

Проверьте себя

Частые вопросы

Похожие уроки