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

Один говорил, что весь навык сводится к умению нормально сформулировать запрос, всё остальное сделает модель. Другой доказывал, что настоящее умение это как раз не пускать ИИ туда, где он навредит, и что главный навык это дисциплина отказа. Третий считал, что тема надутая, а через год всё устаканится само и учиться нечему. Четвёртый прислал скриншот своего CLAUDE.md на двести строк и сказал, что вот она, настоящая работа.

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

А потом выяснилось, что вопрос не академический. У половины из нас в резюме стоит строчка про навыки работы с ИИ, и на собеседованиях за неё уже начали цепляться. «У вас тут указаны навыки ИИ. Что вы имели в виду?» И вот тут начинается неловкое. Потому что честный ответ большинства звучит примерно так: пользуюсь Claude Code каждый день, беру модель посильнее, когда задача сложная, в прошлом месяце сжёг столько то токенов. Всё это правда, и всё это ничего не говорит о вас как об инженере. Количество потраченных токенов характеризует вас ровно так же, как количество написанных строк кода: то есть никак, а иногда и в минус.

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

Я проектирую системы на LLM, и после каждого громкого ИИ‑инцидента мне прилетает одна и та же ссылка с одним и тем же вопросом: «а у нас такое может случиться?» Чтобы отвечать не на глазок, я завёл привычку разбирать каждый такой инцидент до конкретной технической причины. За последние месяцы таких разборов набралось три, и они удивили меня не сходством, а различием. Дыры, в совершенно разных местах: у одного проекта не проверялись источники, у другого, данные на границах системы, у третьего, права автономного агента. А вот причина одна: системы вокруг LLM строили люди, которые умеют писать промпты, но не умеют проектировать архитектуру.

Судите сами. Deloitte Australia возвращает правительству деньги за отчёт, в котором ИИ выдумал источники. В Миннесоте полиция четырьмя машинами блокирует на парковке журналиста, потому что сеть ИИ‑камер несколько дней вела его как угонщика, из‑за опечатки, сделанной за две тысячи миль от него. А основатель инди‑SaaS просыпается и обнаруживает, что написанный моделью код ночью отменил все подписки его клиентов и оставил бизнесу $38 месячной выручки.

Мок‑экзамен, вопрос номер сорок с чем‑то. Сценарий: система должна классифицировать входящие обращения, и ни при каких условиях категория не может выходить за пределы фиксированного списка. Какой вариант обеспечивает это требование? Я уверенно тыкаю в ответ с формулировкой «добавить в системный промпт строгую инструкцию с перечнем допустимых категорий и явным запретом на другие значения».

Красным. Правильный ответ — валидация вывода на уровне приложения со схемой и retry‑логикой. Я смотрю на объяснение и ловлю себя на раздражении: ну промпт же тоже работает, я сто раз так делал. А потом листаю свои прошлые мок-результаты и вижу закономерность: я стабильно ошибаюсь в вопросах одного и того же типа. Не потому что не знаю материал — а потому что у меня в голове неправильно проведена одна граница.

Готовясь к CCA‑F (Claude Certified Architect — Foundations), я ожидал, что буду зубрить параметры API и лимиты контекста. Вместо этого экзамен методично бил меня по одному и тому же месту, пока я не сформулировал, во что именно я неправильно верил.