AI-native инженер

17 апреля 2026

В 2026 рынок разработки перестраивается вокруг AI-агентов. Вакансии с титулами AI-native product engineer, AI-first engineer, founding engineer фильтруют не по языку и не по годам опыта, а по способности оркестрировать агентов end-to-end, управлять контекстом и валидировать результат. Статья начинается с того, как изменился сам сигнал найма (от «пишет корректный код» к «получает merged PR через агента и управляет blast radius»), показывает на каких данных и историях этот сдвиг становится виден, разбирает шесть измерений оценки с конкретными вопросами и ответами, заканчивается стилизованным кейсом перестройки воронки и практическим руководством по переписыванию интервью-loop, рубрик и обучения интервьюеров.

Сдвиг рамки: от raw coding к agent leverage

До 2023 года типовая инженерная вакансия фильтровала кандидатов по двум осям. Первая - владение языком и стеком: Ruby с 5+ годами, React с 3+ годами, Postgres на уровне написания EXPLAIN. Вторая - алгоритмическая глубина в формате LeetCode и whiteboard. Обе оси опирались на одно негласное допущение: ценность инженера прямо пропорциональна тому, насколько быстро и корректно он лично производит код. Найм оптимизировался под фигуру «один человек - один merged PR в неделю», и интервью моделировало именно эту фигуру: сядьте за код, напишите функцию, объясните сложность.

К 2026 году это допущение сломалось. Anthropic в карьерных материалах прямо описывает идеального кандидата как человека, способного собрать и проконтролировать pipeline из агентов, а не как самого быстрого индивидуального исполнителя (см. страницу Anthropic Careers). Vercel в своих публичных постах про найм фронтенд-инженеров явно говорит о «taste» как о центральной компетенции: агент сгенерирует десять вариантов, но решит, какой из них пойдёт в production, человек, и качество этого решения определяет outcome (см. инженерный блог Vercel с регулярными постами о найме). Команда Cursor в публичных интервью описывает фильтр «не показывает экран без AI» - кандидат, отказывающийся использовать AI на интервью, в их понимании заведомо хуже того, кто использует, потому что production-работа в Cursor устроена через AI с первого дня.

Сдвиг не косметический. Он касается формы сигнала, который компания пытается измерить. Раньше сигнал был: «может ли этот человек один за неделю написать корректный модуль X». Сейчас сигнал: «может ли этот человек за ту же неделю получить корректный merged PR через агента, удержать blast radius на разумном уровне, не сжечь бюджет токенов и не создать legacy, который через полгода никто не сможет понять». Это другая функция. Алгоритмическая задача на доске измеряет первую и почти не коррелирует со второй. Pipeline walkthrough на реальной задаче измеряет вторую и почти не зависит от первой.

Lenny Rachitsky в своём ньюслеттере (см. lennysnewsletter.com) описывает аналогичный сдвиг для product manager-ов под рамкой «AI-native PM»: критерий найма перестаёт быть «насколько хорошо PM пишет PRD», становится «насколько хорошо PM формулирует контекст для агентов и валидирует выход». Та же логика применима к инженерам, и Augment Code в своём посте «How we hire AI-native engineers now» (см. ссылку в разделе Шесть измерений) делает её явной через шесть измерений, в которых нет отдельного пункта «raw coding ability».

Бизнес-обоснование сдвига: AI делает производство кода дешёвым товаром. Если за час agent-piped инженер получает три merged PR, а классический инженер - один, разница в продуктивности при больших командах превращается в фактор кратного ускорения time-to-market. Компании, которые продолжают нанимать по старой рубрике, не получают этой кратности и параллельно платят те же зарплаты тем же людям. Через три-четыре квартала это становится финансово видно как разрыв скорости с конкурентами, нанимающими по новой рамке.

Charity Majors в публичных постах про найм в Honeycomb (см. её блог charity.wtf) формулирует требование, которое естественно встраивается в новую рамку: tolerance to ambiguity. Работа с агентами по природе неопределённа - LLM ошибается, сессии деградируют, требования меняются по ходу. Инженер, требующий полностью однозначной спецификации до начала работы, в этой среде ломается. Will Larson в книге «An Elegant Puzzle» (Stripe Press, 2019) обсуждает «durability» как смежную компетенцию: способность инженера производить ценность через много циклов смены инструментария, а не через один зафиксированный стек. Camille Fournier в «The Manager's Path» (O'Reilly, 2017) описывает staff-уровень как способность поднимать leverage всей команды; в AI-native контексте это превращается в способность спроектировать процесс, в котором десять инженеров с агентами работают быстрее десяти инженеров без них в три-пять раз, а не в полтора.

Сигналы рынка: где старая рубрика промахивается

Этот раздел опирается на несколько типов источников: количественные опросы (Karat 2026 Engineering Interview Trends, DORA 2025 State of DevOps), публично описанные практики компаний (Anthropic Careers, Vercel engineering blog, Stripe bar-raiser model adapted from Amazon, GitHub Copilot Workspace team posts) и стилизованные истории найма, восстановленные из публично описанных паттернов и личного опыта. Стилизованные кейсы помечены явно - они отражают типичные сценарии, не конкретную компанию.

Стилизованный пример на основе типичных паттернов: B2B SaaS, ~120 инженеров, год с осени 2024 по осень 2025. Команда нанимает по классической рубрике: take-home задание (4 часа, имплементировать REST endpoint с валидацией и тестами), follow-up системный дизайн (45 минут, спроектировать систему уведомлений), behavioral interview (30 минут). Pass rate воронки - стандартные 8-10% от прошедших скрин до оффера. Через шесть месяцев работы новых сотрудников performance review показывает странное распределение: треть нанятых перформит выше ожиданий, треть - на уровне, треть - заметно ниже, и эта последняя треть - не junior-ы, а senior-ы с сильными резюме и сильными интервью. Калибровочная встреча инженерных лидеров обнаруживает паттерн: «отстающие senior-ы» - те, кто отказывается или плохо использует AI-инструменты в ежедневной работе. Take-home задание они написали отлично руками за 4 часа, но в реальном проекте их недельный output ниже, чем у midlevel-инженера, спокойно делегирующего шаблонные части агенту.

Karat 2026 Engineering Interview Trends (опрос 1500 инженерных лидеров, см. karat.com) фиксирует ту же картину количественно. 71% лидеров говорят, что стандартные оценки сломаны: take-home задания и whiteboard coding кандидат прогоняет через Claude или Cursor, итоговый сигнал интервьюера почти не коррелирует с реальной производительностью на работе. 73% считают сильного инженера эквивалентным трём годовым компенсациям слабого, и этот разрыв растёт - то есть стоимость ошибки найма поднимается. AI увеличивает среднюю продуктивность на 34%, но прирост распределён крайне неравномерно: верхний квартиль получает кратное ускорение, нижний - близкое к нулю или отрицательное.

DORA 2025 State of DevOps Report (см. dora.dev) добавляет производственный угол. При 90% adoption AI-инструментов команды без перестройки процесса получают +9% багов и +91% времени code review. Скорость написания кода действительно выросла, но узкое место сместилось на review и coordination. Простая подстановка агента вместо разработчика в старом SDLC деградирует качество, потому что агент генерирует diff-ы большего объёма с менее очевидной структурой, а review-процесс на это не рассчитан. Под этой статистикой - тысячи историй типа стилизованного примера выше: компания нанимает «как раньше», AI ставит в инструменты, ожидает кратного ускорения, получает деградацию метрик и не понимает, что фильтр найма промахивается.

Anthropic Careers публично описывает фильтр через рамку «Constitutional AI applicants» - кандидаты, которые в работе и на интервью демонстрируют свойства, аналогичные конституциональным принципам компании: явная ответственность за безопасность, готовность остановить процесс, если он движется не туда, обоснование решений ссылками на правила, а не на интуицию. На уровне процесса это переводится в требование: кандидат на интервью должен быть способен показать, как его pipeline ловит ошибки агента до того, как они доедут до production. Простой рассказ «я использую Claude» сигнал не несёт. Описание hooks, permissions, multi-agent проверок, human gate на нереверсируемые операции - несёт.

Vercel в своём engineering blog пишет о критерии «AI taste» как о новой основной оси. Кандидат, не различающий хороший и плохой выход агента, в команде будет конвейером для plausible-looking-но-неправильного кода. Кандидат с taste отбраковывает 80% генерации и пропускает 20%, и его 20% улучшают продукт. Vercel явно рекрутирует через демонстрацию taste: на интервью кандидату дают задачу, где AI выдаёт несколько вариантов, и измеряют не скорость написания, а качество отбора и обоснования.

Cursor в публичных интервью команды (см. ссылки на YC podcasts и Lenny's Podcast в разделе Источники) описывает hire-or-no-hire паттерн: на онсайт кандидат садится за реальный issue в Cursor codebase, использует Cursor для решения, и команда смотрит не результат, а процесс - какие промпты он пишет, как реагирует на ошибочные предложения, как переключается между manual и AI-driven фрагментами. Кандидат, имитирующий «работу без AI» в среде, где production-работа всех остальных идёт через AI, заведомо хуже того, кто работает естественно.

Стилизованный пример на основе типичных паттернов: e-commerce платформа, 60 инженеров. Открыли вакансию «Senior Backend Engineer, Python», закрыли через 4 месяца, наняли senior-а с 9 годами Python и сильным take-home. Через два месяца работы менеджер фиксирует: PR-ы кандидата плотные, по 800-1500 строк, написаны вручную, ревью занимает у команды по полтора часа каждое, регрессии в смежных модулях стабильные. Параллельно midlevel-инженер с двумя годами опыта, который не дошёл до финала по той же воронке (срезался на алгоритмической задаче), работает в соседней команде через Cursor и Claude Code, выпускает 3-4 PR в неделю по 200-400 строк, регрессий минимум, ревью занимает 20 минут. Различие на performance review через полгода - в пользу midlevel-инженера. Старая рубрика выбрала не того кандидата.

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

Что изменилось в ожиданиях

Karat 2026 опросил 1500 инженерных лидеров. AI увеличивает среднюю продуктивность инженера на 34%, но прирост распределён неравномерно: верхний квартиль получает кратное ускорение, нижний - близкое к нулю или отрицательное. 73% лидеров считают сильного инженера равным трём годовым компенсациям слабого, и процент растёт с каждым опросом. 71% признают сломанность стандартной оценки: take-home задания и whiteboard coding прогоняются кандидатом через Claude, итоговый сигнал слаб, корреляция с реальной работой в команде низкая.

Количество вакансий инженеров в H1 2026 выросло на 30% (более 67 000 открытых позиций по отслеживаемым источникам) при 52 000 увольнений в Q1, часть которых обоснована AI-трансформацией. Это не рыночный кризис, а переоценка профиля: компании сокращают роли, делающие «как раньше», и открывают под другой набор навыков. Часто это происходит в одной и той же команде: ту же позицию переоткрывают с другим описанием.

DORA 2025 State of DevOps Report зафиксировал парадокс: при 90% adoption AI-инструментов команды без перестройки процесса получают +9% багов и +91% времени code review. Написание кода ускорилось, но узкие места сместились на review и coordination. Простая подстановка агента вместо разработчика в старом SDLC деградирует качество, потому что агент генерирует diff-ы большего объёма с менее очевидной структурой, а review-процесс на это не рассчитан.

Следствие для рекрутинга: фильтр сместился с «пишет корректный код на языке X за N лет» на «собирает работающий pipeline с агентами, ловит их ошибки, обосновывает cost и latency, управляет контекстом». Язык вторичен: код становится дешёвым, code-agnostic мышление становится ценой допуска. Компании, которые продолжают искать «сеньора с 7 годами опыта Ruby», в 2026 получают либо кандидатов уходящей парадигмы, либо несоответствие между запросом и реальной потребностью.

Шесть измерений оценки

Рамка Augment Code задаёт ориентир для многих современных описаний вакансий. Её значение в том, что она делает явными измерения, которые раньше оценивались интуитивно, и явно убирает одно измерение (raw coding), которое раньше было центральным. Шесть измерений с наблюдаемыми сигналами:

Измерение	Что проверяется	Наблюдаемый сигнал
Product & Outcome Taste	Формулировка outcome от проблемы пользователя, не от технологии	Начинает с «кто клиент и что он делает», не с «какое API»
System & Architectural Judgment	Trade-offs под операционным давлением	В brownfield сразу называет плоскости риска: latency, idempotency, security, migration safety
Agent Leverage	Декомпозиция под агента и валидация	Pipeline walkthrough с именованными артефактами и чистыми сессиями
Communication & Collaboration	Ясность текстовой коммуникации (код и артефакты)	Задаёт уточняющие вопросы до ответа; артефакты читаются без дополнительных объяснений
Ownership & Leadership	End-to-end владение, устранение блокеров	«Сделал X, потому что Y был заблокирован», не «попросили»
Learning Velocity & Experimental Mindset	Способность выбросить устаревший workflow	Конкретный пример миграции (Cursor → Codex → Claude Code) с обоснованием

Product & Outcome Taste. Проверка распадается на две способности. Первая - формулировать проблему пользователя до выбора технологии: «пользователи не могут найти свой налоговый документ за прошлый квартал» вместо «нужен полнотекстовый поиск». Вторая - измерять outcome, а не output: «время поиска документа снижено с 90 секунд до 8 секунд на 95-м перцентиле» вместо «внедрили Elasticsearch». Сигнал - кандидат спонтанно оперирует такой парой (проблема + метрика), не дожидаясь уточняющих вопросов.

Пример вопроса и сильного ответа. Вопрос интервьюера: «Расскажи про последнюю фичу, которую ты сделал. Не код, а зачем она нужна была». Слабый ответ: «Сделал endpoint для отчётов, использовал Sidekiq для async-генерации, кэш на Redis». Сильный ответ: «Финансовые контролёры тратили в среднем 12 минут на сборку месячного отчёта вручную через Excel. Цель была 30 секунд. Сделал предагрегированный snapshot, который пересчитывается ночью; live-запрос идёт по нему. Получили 4 секунды на 95-м перцентиле. Side effect - снизилась нагрузка на основной DB во время рабочего дня, потому что отчёты перестали тянуть тяжёлые JOIN-ы». Второй ответ начинается с пользователя и метрики, упоминает trade-off, упоминает observed outcome, не выпячивает технический выбор.

System & Architectural Judgment. Измерение ловит способность видеть систему как набор взаимодействующих плоскостей под операционным давлением, а не как картинку из слайда. В brownfield-сценарии (см. раздел Сценарии) кандидат с хорошим judgment в первые минуты называет конкретные риски: latency бюджеты, idempotency требования, PCI-скоп, миграционные риски, зависимости между сервисами. Без этого измерения AI-leverage ведёт к быстрому производству архитектурно слабых решений, которые ломаются при первом production-инциденте.

Пример вопроса и сильного ответа. Вопрос: «Как добавишь usage-based billing к существующей подписной модели Stripe?». Слабый ответ - сразу про схему таблиц или про код. Сильный ответ начинается с плоскостей: «Первое - мне нужно понять, как сейчас устроены вебхуки от Stripe и есть ли idempotency на их обработке, иначе двойной счёт за usage реален. Второе - где PCI-скоп, чтобы новый код в него не попал. Третье - как считается proration при upgrade, потому что usage-based ломает классический trial. Четвёртое - feature flag для постепенного rollout по сегменту, иначе разовая регрессия по выручке». Кандидат показывает, что видит систему до того, как пишет первую строку кода.

Agent Leverage. Центральное измерение для AI-native роли. Оценивается не по факту использования («я пользуюсь Claude»), а по качеству pipeline: умеет ли кандидат декомпозировать задачу в артефакты (PRD, plan, task-файлы), запускать отдельные чистые сессии под каждую фазу, валидировать результат детерминистскими проверками (тесты, линтеры, type-check), ограничивать человеческий надзор до критичных точек. Количество параллельных сессий - не самоцель; важен процесс, который масштабируется без потери контроля.

Пример вопроса и сильного ответа. Вопрос: «Покажи на любой задаче из недавних, как ты её делегировал агенту». Слабый ответ: «Открыл Cursor, попросил Claude написать, ревьюнул, замержил». Сильный ответ: «Задача была - добавить proration для upgrade/downgrade. Первая сессия - PRD: вытащил из тикета и из обсуждения с PM, оформил в prd.md, прогнал Q&A с агентом, чтобы вычленить неявные допущения (что считаем upgrade, что downgrade, день-точность или секунд-точность). Вторая - plan: spec разбил на 4 task-файла, каждый из которых самодостаточен. Третья - реализация по task-001, чистая сессия, контекст из prd.md и task-001.md, тесты сначала. Hooks блокируют push в main без my approval. Code-reviewer-agent проверяет diff на skip-тесты, на пустые catch, на TODO. Через три задачи я ловлю себя на том, что моё участие сократилось до review артефактов и approve финального PR». Кандидат описывает процесс, не результат, и в процессе виден контроль качества.

Communication & Collaboration. В мире параллельных сессий намерение формулируется меньше в устных согласованиях и больше в текстовых артефактах - spec.md, plan.md, контракты между ролями агентов. Инженер, умеющий писать ясный spec, умножает свою эффективность на количество агентов, которым этот spec передаётся. Сигнал на интервью - уточняющие вопросы до начала ответа, структурированная речь с явными переходами, умение перефразировать непонятное в собственных словах.

Пример вопроса и сильного ответа. Вопрос: «Опиши свой последний spec.md». Слабый ответ: «Написал, что нужно сделать». Сильный ответ: «Структура была: проблема пользователя в одном абзаце, success metrics в формате “что увидим в Datadog”, scope (что в, что вне), non-goals (что специально не делаем), open questions (то, по чему я не уверен и хочу обсудить), implementation plan на пять шагов с галочками, risks с указанием митигации. Q&A с агентом дал три уточнения, которые я бы не задал сам себе. PM смог прочитать без меня и одобрить за один заход».

Ownership & Leadership. End-to-end владение означает, что кандидат продвигает результат даже когда встречает блокер не в своём скоупе: идёт к PM, к SRE, к legal, чтобы вытащить задачу. В AI-native контексте это критично: параллельные сессии создают больше micro-блокеров, чем последовательный процесс, и без автономной способности их убирать инженер превращается в медленный бутылочный горлышко. Сигнал - истории в формате «обнаружил, что X блокирует, сделал Y, разблокировал», не «меня попросили, я сделал».

Пример вопроса и сильного ответа. Вопрос: «Самый болезненный блокер в недавнем проекте, как ты его решил». Слабый ответ: «Ждал, пока DevOps починит CI». Сильный ответ: «CI деградировал до 35 минут на feature branch, мои параллельные сессии тратили половину времени на ожидание зелёного. Поговорил с DevOps - у них в очереди на квартал. Не стал ждать. Поднял отдельный self-hosted runner для нашей команды на нашем бюджете, написал runbook, передал DevOps как кандидат на adoption. Время CI на нашей ветке упало до 8 минут. DevOps через два месяца взяли решение и распространили на ещё две команды». Кандидат видит блокер как свою задачу, не как чужую.

Learning Velocity & Experimental Mindset. Инструментарий AI-разработки меняется раз в несколько месяцев: новая модель, новый harness, новый паттерн (skills, subagents, compound engineering). Инженер, привязавшийся к одному стеку как к идентичности, через полгода становится помехой для команды. Сигнал на интервью - конкретная история перехода (Cursor на Codex, рукописные промпты на skills, in-memory память на MCP-сервер) с обоснованием почему и что пришлось переделать.

Пример вопроса и сильного ответа. Вопрос: «Какой инструмент или практику ты в этом году отбросил и почему». Слабый ответ: «Никакой, у меня всё работает». Сильный ответ: «Полгода работал в Cursor, нравилось inline-предложение и diff view. Когда вышел Claude Code с skills и MCP, попробовал две недели параллельно - на больших задачах с нескольких файлов skills экономили мне в день час, потому что я перестал переписывать одни и те же команды. Перешёл полностью. Сейчас слежу за Codex - там interesting agents API, через квартал решу, имеет ли смысл переключаться или оставаться». Кандидат явно описывает причину перехода, цену перехода, способ принятия решения.

Отсутствие отдельного пункта «raw coding ability» - осознанное решение. Написание кода сжимается в часть agent leverage: важно не как быстро кандидат печатает, а как быстро он получает корректный merged PR через агента. Компании, которые продолжают оценивать LeetCode-алгоритмы как основной сигнал, получают ошибочное распределение: кандидаты с сильным algorithmic thinking, но слабым agent leverage проходят через фильтр, а затем не справляются с реальной работой.

Технический базис

Концепты ниже лежат в основе работы агентов. На AI-native интервью встречаются прямые технические probes: «объясни prompt caching», «когда нужен hybrid search», «что такое context rot». Ответ в формате определения - слабый сигнал (признак прочитанного поста). Ответ в формате механика → практическое следствие → конкретный пример из опыта - сильный (признак применённого концепта).

Inference loop: LLM как stateless функция

Крупная языковая модель - чистая функция из входного текста в распределение вероятностей следующего токена. Каждый вызов независим, памяти между запросами нет. Внутренний pipeline одного вызова:

1. Токенизация. Входной текст разбивается на токены (обычно BPE-алгоритм). Claude использует tokenizer близкий к tiktoken, один токен в среднем ~4 символа на английском, ~2 на русском, ~1 на CJK-языках. Отсюда статья на русском стоит примерно вдвое дороже в токенах, чем на английском.
2. Embedding. Каждый токен преобразуется в вектор (в крупных моделях размерность 4096-12288). К embedding добавляется позиционная информация (RoPE, ALiBi, позиционные embeddings) - модель учитывает порядок токенов.
3. Трансформерные слои. N слоёв (десятки для топовых моделей), каждый состоит из self-attention (токены смотрят друг на друга) и feed-forward блока. В каждом слое используется residual connection и layer normalization.
4. Logits. На выходе последнего слоя - вектор длины словаря (обычно 100К-200К токенов) с ненормализованными оценками вероятности следующего токена.
5. Сэмплирование. Logits превращаются в вероятности через softmax, затем выбирается токен по стратегии: argmax (greedy), temperature + top-p, top-k, nucleus sampling.

Temperature модифицирует распределение перед softmax: logits делятся на значение температуры. T=0 приближается к argmax (детерминизм), T=1 оставляет распределение как есть, T > 1 делает распределение более плоским (больше случайности). Top-p отсекает хвост распределения до накопленной вероятности p (обычно 0.9-0.95). Top-k оставляет k самых вероятных токенов.

Важное следствие: даже при T=0 полный детерминизм не гарантируется. Плавающая точка на GPU даёт небольшие вариации, параллельные вычисления могут менять порядок сложения, что приводит к разным argmax при почти равных logits. Для воспроизводимости нужен seed, но и он не всегда доступен в API.

Практические следствия stateless природы:

• Два одинаковых промпта могут дать разные ответы при temperature выше нуля.
• Модель не «помнит» предыдущий диалог - история подаётся на вход заново каждый вызов. Harness склеивает предыдущие messages и отправляет пакетом.
• «Понимание» ограничено тем, что попадает в контекстное окно этого конкретного вызова. Информация, которая не передана, не может быть использована.
• Каждый токен ответа требует отдельного forward pass. Длинный ответ в N токенов требует N последовательных проходов, отсюда ощутимая latency генерации.

Agent harness: state machine поверх LLM

Harness превращает stateless вызовы LLM в непрерывный агентный процесс. Минимальный harness реализует tool loop:

input → LLM call → stop_reason
  ├─ "end_turn"   → ответ пользователю
  ├─ "tool_use"   → исполнить инструмент → результат → повторный вызов с расширенной историей
  └─ "max_tokens" → обработать обрыв

Конкретный пример turn-а в Anthropic Messages API. Harness отправляет массив сообщений с описанием тулов. Модель возвращает ответ, который может содержать блоки text и tool_use. Если есть tool_use, harness исполняет инструмент, формирует сообщение с ролью user и блоком tool_result, и отправляет расширенную историю обратно модели. Цикл продолжается до stop_reason: "end_turn".

[
  {"role": "user", "content": "Найди в репо все вызовы deprecated API"},
  {"role": "assistant", "content": [
    {"type": "tool_use", "id": "tu_01", "name": "grep",
     "input": {"pattern": "deprecated_"}}
  ]},
  {"role": "user", "content": [
    {"type": "tool_result", "tool_use_id": "tu_01",
     "content": "Found 7 matches in src/..."}
  ]},
  {"role": "assistant", "content": [
    {"type": "text", "text": "Найдено 7 вызовов..."}
  ]}
]

Сверху минимального tool loop harness добавляет целый слой сервисов:

• Permissions. Правила доступа к тулам в формате allow/ask/deny с scope-матчерами. Правило применяется до LLM-вызова, модель не может обойти.
• Guardrails. Проверки, блокирующие определённые действия: запрет на запись в определённые пути, на выполнение определённых команд, на обращение к внешним API.
• Sessions. Хранение истории между turn-ами. В Claude Code сессия - сохранённая серия messages, которую можно продолжить после перезапуска.
• Hooks. Lifecycle-события для автоматизации: PreToolUse, PostToolUse, SessionStart, Stop. Hook может модифицировать вход тула или отменить его выполнение через exit code.
• Skills и commands. User-invocable recipes: markdown-файл с frontmatter, который раскрывается в промпт при вызове. Progressive disclosure - описание грузится только когда команда вызывается.
• Контекстные источники. CLAUDE.md, memory, rules, git status - всё автоматически инжектируется в prompt каждого turn-а.
• Plan/auto модели. Plan mode отключает тулы-модификаторы и ограничивает агента планированием. Auto mode разрешает всё, что разрешено permissions, без подтверждений.

Claude Code, Cursor, Codex, Aider, Continue - примеры harness-ов с разным дизайном. API Anthropic или OpenAI напрямую - это чистая LLM без harness. Когда кандидат говорит «я использую Claude», уточнение «API напрямую или Claude Code» принципиально: разный уровень абстракции даёт разную поверхность ошибок и возможностей. Ошибка, которую Claude Code ловит через hook или permission, в голом API станет вашей.

Контекстное окно и его экономика

Контекстное окно - максимальная длина входа плюс выхода в токенах за один вызов. У современных моделей 200К (Claude Sonnet), 1М (Claude Sonnet 1M context, Gemini), до 2М (специальные конфигурации). Впечатление «много» обманчиво по двум причинам.

Первая - стоимость. Цена вызова линейна по входу, плюс каждый токен на выходе стоит дороже входного токена примерно в 5 раз. Сессия с историей 150К токенов и ответом 4К токенов стоит значительно больше, чем стартовая сессия с промптом 10К токенов и таким же ответом. Без prompt caching (см. далее) долгие сессии быстро выходят из бюджета.

Вторая - падение точности. Chroma Research в отчёте «Context Rot» показали на систематических бенчмарках (NIAH, LongMemEval, extended tasks): модель, получающая 100К токенов контекста, отвечает хуже, чем та же модель на том же вопросе с 10К токенов. Падение не равномерное - особенно страдает середина окна (эффект lost-in-the-middle, описанный ещё в 2023 году).

Anthropic в своих материалах по context engineering классифицируют четыре режима отказа длинного контекста:

• Poisoning. Ошибка из ранней итерации (агент прочёл неверный файл, попал в битую документацию) остаётся в истории. Последующие turn-ы опираются на эту ошибку как на истину и наслаивают на неё новые действия. Симптом: агент уверенно делает что-то неправильное и не реагирует на поправки.
• Distraction. Устаревшие паттерны из истории (попытка, которая не сработала; код, который был отброшен) доминируют над новыми инструкциями в промпте. Симптом: агент повторяет ошибку, которую уже совершил раз или два назад.
• Confusion. Слишком много инструментов в system prompt, агент выбирает неподходящий. Например, есть тул run_tests и run_test_single, агент при единичном тесте вызывает первый с некорректными аргументами. Симптом: неожиданные ошибки на простых действиях.
• Clash. Противоречивая информация в разных частях контекста: CLAUDE.md говорит «используй PostgreSQL», а результат grep показывает SQLite в коде. Агент выбирает случайное из двух. Симптом: inconsistent behavior.

Attention механика и кэш

Self-attention в трансформере для каждого токена вычисляет три вектора: Query (что ищу), Key (чем могу быть полезен), Value (что несу). Для токена i attention-вес к токену j - это нормализованное скалярное произведение Q_i · K_j. Результат attention для токена i - взвешенная сумма V_j по всем j в пределах окна.

Сложность полного attention квадратична по длине входа: N токенов требуют N² пар Q-K. Удвоение контекста даёт четырёхкратный рост вычислений. Это делает наивное увеличение окна экономически неприемлемым.

KV cache - ключевая оптимизация. При автогрегрессивной генерации новый токен видит все предыдущие. Если K и V для уже обработанных токенов закэшированы, для нового токена нужно вычислить только его собственные Q, K, V и применить attention к кэшированным. Это превращает стоимость генерации из O(N²) в O(N) на токен.

Anthropic сделали prompt caching явным контрактом API. Инженер помечает блоки промпта как «cacheable» через cache_control. Первый вызов оплачивается полностью, с наценкой 25% на обработку кэша. Следующие вызовы с тем же префиксом попадают в cache hit и стоят 10% от обычной цены. TTL кэша - 5 минут (продлевается на каждый hit) или 1 час (premium-вариант).

{
  "system": [
    {
      "type": "text",
      "text": "Ты senior Rails developer. Правила кодирования: ...",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {"role": "user", "content": "Добавь endpoint /api/v1/invoices"}
  ]
}

Архитектурные следствия prompt caching:

• Стабильное содержимое (system prompt, CLAUDE.md, rules, описания тулов, большие examples) располагается в начале промпта с cache_control.
• Переменное содержимое (текущий user message) располагается в конце без кэша.
• Перестановка порядка ломает кэш и увеличивает стоимость в 10 раз при той же длине промпта. Это частая ошибка при рефакторинге промптов.
• Любое изменение в начале промпта (даже пробел) инвалидирует кэш.
• Одна долгая сессия с множеством turn-ов выгоднее, чем серия новых сессий с тем же контекстом.

Эффект lost-in-the-middle (Liu et al., 2023) дополнительно влияет на дизайн. Модель лучше помнит начало и конец контекста, хуже - середину. При длинных промптах с множеством документов критичная информация размещается в краях: важные правила - в system prompt, текущая задача - в последнем user message. Середина может содержать справочные материалы, чья точная воспроизводимость не критична.

Иерархия источников контекста

При каждом turn-е harness собирает промпт из десятка источников. Типовая структура для Claude Code, упорядоченная по позиции в итоговом промпте (сверху вниз):

1. System prompt - встроенный в harness, задаёт базовую роль, правила поведения, описания инструментов. Занимает обычно 5-15К токенов. Помечен cache_control.
2. Managed CLAUDE.md - от платформы (если подключена enterprise-интеграция). Правила организации, компаунд-промпты, запрещённые паттерны.
3. Project CLAUDE.md - в корне репозитория. Описание проекта, командные правила, команды для локального запуска.
4. User CLAUDE.md - в ~/.claude/. Личные настройки, персональные правила кодирования.
5. Rules - безусловные (всегда в промпте) и path-scoped (активируются при работе с определёнными файлами). Отличаются от CLAUDE.md тем, что могут быть помечены как «always-apply» или «context-aware».
6. Auto memory - до 200 строк из index-файла (MEMORY.md). Ссылки на детальные memory-файлы, загружаемые по необходимости.
7. Skill descriptions - только имя и краткое описание каждой skill (1 строка на skill). Полное содержание загружается только при вызове. Занимает примерно 2% бюджета окна.
8. История диалога - все messages текущей сессии. Растёт с каждым turn-ом.
9. Tool results предыдущих turn-ов - содержимое файлов, результаты команд, выводы агентов. Основной источник роста истории.
10. Git status и environment info - текущая ветка, неcommit-ed изменения, путь, ОС. Обновляется каждый turn.

Принципиально различие уровней влияния каждого источника:

• System prompt - enforcement-уровень: модель обучена следовать содержимому, и в большинстве случаев следует. Это самая сильная форма инструкции.
• CLAUDE.md и rules - guidance-уровень: инжектируются как обычные user messages, модель может не следовать им при конфликте с другими инструкциями или при context rot. Это просьба, не гарантия.
• Permissions (deny/ask/allow) - технический уровень на уровне harness. Модель не может обойти, потому что ограничение применяется до вызова тула, в коде harness. Это жёсткий блок.

Практическое следствие: строка «в CLAUDE.md написано не делать X» и строка «в settings настроено deny на X» - принципиально разные механизмы. Первое - просьба, которую модель выполнит в 90-95% случаев и проигнорирует в критических (когда альтернатив нет, когда context rot исказил приоритеты). Второе - блок, который невозможно обойти без изменения settings.

Распространённая ошибка - полагаться на CLAUDE.md для безопасности. «Никогда не делай rm -rf» в CLAUDE.md не защищает репозиторий от удаления при определённых обстоятельствах. Защищает deny-правило в permissions на rm или более тонкий hook, проверяющий аргументы.

Tiers памяти

В stateless-мире память - инженерная задача с архитектурным дизайном. Без памяти агент забывает всё после /clear и начинает с нуля каждую новую задачу. С плохо организованной памятью - наследует чужой confusion-контекст и действует по устаревшим предпосылкам. Практические уровни:

In-context (сессия) - то, что сейчас в окне. Самая быстрая и дешёвая память: модель видит всё напрямую. Живёт одну сессию, исчезает при /clear. Ограничена контекстным окном и страдает от context rot при длинных сессиях. Используется для рабочей информации текущей задачи: что сейчас делаем, какие файлы читали, какие решения приняли за последние turn-ы.

Working memory (файлы в репо) - агент пишет и читает markdown-файлы как внешние записные книжки. Это средняя скорость (требует вызова read/write тулов), но неограниченный размер и полная трассируемость. Типовые файлы: prd.md с описанием продукта, plan.md с разбивкой задачи на фазы, spec-001.md, spec-002.md с задачами, progress.md с текущим состоянием, decisions.md с зафиксированными решениями. Эти файлы переживают сессию, попадают в git, передаются между агентами как контракты.

Long-term (KB + retrieval) - база знаний, подключённая через MCP или RAG. Медленнее всего (требует retrieval-запроса), но хранит терабайты данных. Домены: документация предметной области, архитектурные решения предыдущих лет, внутренние runbook-и, API-спецификации подключённых сервисов, конституция проекта. Обычно доступно через MCP-сервер, который агент вызывает как тул, или через специализированные subagent-ы, поднимающие RAG-запросы.

Паттерн Descent Into Madness описывает проблему долгих сессий. Агент накапливает confusion-контекст: частичные попытки, отвергнутые гипотезы, поправленные решения. Постепенно сигнал тонет в шуме, точность падает. Наивное продолжение - всё хуже. Решение: явное вынесение состояния во внешний файл (progress.md, next-steps.md), запуск чистой сессии, восстановление минимально необходимого контекста из файла. Это ручной compaction: инженер решает что сохранить, а не автоматический summarizer.

# progress.md (пример состояния для restore)
## Задача
Добавить proration для upgrade/downgrade subscription tiers.

## Что сделано
- [x] Проанализирован текущий BillingService (src/services/billing.rb)
- [x] Найдены 3 места, где rate рассчитывается: renewal, upgrade, trial-end
- [x] Написаны тесты для renewal (spec/services/billing_spec.rb)

## Что дальше
- [ ] Реализовать proration calculator (src/services/proration_calculator.rb)
- [ ] Интегрировать в BillingService#upgrade и #downgrade
- [ ] Feature flag: :usage_based_billing_v2

## Важные решения
- Используем day-level precision (не hour/second) - совпадает со Stripe
- Downgrade применяется в конце billing period, не немедленно

Архитектурный принцип: fast/expensive (in-context) для того, что нужно прямо сейчас; slow/cheap (files) для того, что нужно через сессию; very-slow/unlimited (RAG) для того, что может понадобиться когда-нибудь.

Tool use механика и MCP

Tool use - способ агента совершать действия во внешнем мире. Механика: инженер описывает инструмент как JSON Schema (имя, параметры, типы, описание). Harness инжектирует список инструментов в system prompt. LLM в ходе генерации решает вызвать инструмент, возвращает блок tool_use с именем и аргументами. Harness исполняет, возвращает tool_result с ролью user. LLM продолжает с обновлённой историей.

{
  "name": "search_codebase",
  "description": "Полнотекстовый поиск по репозиторию.
Использовать для поиска по содержимому файлов, не по именам.",
  "input_schema": {
    "type": "object",
    "properties": {
      "pattern": {
        "type": "string",
        "description": "Регулярное выражение для поиска"
      },
      "path": {
        "type": "string",
        "description": "Путь для ограничения поиска, например 'src/services/'"
      },
      "case_sensitive": {
        "type": "boolean",
        "default": false
      }
    },
    "required": ["pattern"]
  }
}

Качество описания напрямую влияет на точность вызова. Пустое description - модель угадает использование из имени, часто неверно. Подробное description с примерами использования и граничными случаями - модель вызывает корректно в большинстве случаев. Это объясняет, почему написание хороших tool descriptions - инженерная работа, а не декоративная.

Стоимость инструментов в токенах: каждая функция занимает токены в system prompt (обычно 100-500 токенов с полным описанием и примерами). 50 инструментов могут занять 10-25К токенов - значительная часть окна. Плюс confusion: чем больше тулов, тем чаще модель ошибается в выборе. Эмпирически 15-20 тулов - граница, выше которой начинаются систематические проблемы.

Skill-based архитектуры (Claude Code) решают это через progressive disclosure: в system prompt попадает только список имён и краткие описания (~1 строка на skill). Полное описание загружается только при вызове конкретной skill. Это позволяет держать сотни команд без context bloat.

MCP (Model Context Protocol) - открытый стандарт Anthropic (ноябрь 2024), описывающий как внешние сервисы экспонируют инструменты, ресурсы и промпты агентам. Архитектура клиент-сервер:

• MCP Server - процесс, экспонирующий tools (функции), resources (данные, доступные для чтения), prompts (шаблоны). Запускается либо через stdio (локальный процесс с pipe), либо через HTTP/SSE (удалённый endpoint).
• MCP Client - встроен в harness (Claude Code, Cursor, и другие). Открывает соединение с сервером, получает manifest (список tools/resources/prompts), регистрирует их как доступные агенту.
• Handshake - обмен capabilities на старте: клиент сообщает что поддерживает, сервер - что предлагает. После этого клиент делает регулярные tools/list, resources/list запросы для обновления.

Ключевое свойство MCP - кросс-вендорность. MCP-сервер, написанный для Claude Code, работает в Cursor, Codex и любом другом harness с MCP-клиентом без изменений. Это прямо решает проблему vendor lock-in на уровне инструментов. К началу 2026 у SDK 97 млн загрузок, протокол передан в Linux Foundation, экосистема содержит тысячи MCP-серверов: GitHub, Jira, Linear, Slack, БД, векторные хранилища, облачные провайдеры.

LSP (Language Server Protocol) - комплементарный канал связи агента с инструментарием. Даёт агенту «мнение компилятора» в виде диагностик (ошибки, warnings), типов (hover-информация), auto-imports, go-to-definition, find-references. Без LSP агент узнаёт об ошибке только после запуска тестов или компиляции; с LSP - сразу после изменения файла, через тот же канал что используют IDE.

Semantic search изнутри

Семантический поиск - фундамент RAG и инфраструктуры долгосрочной памяти. Ниже механика по компонентам с деталями, важными для production.

Embedding. Отображение текста в вектор фиксированной размерности. Популярные модели и их характеристики:

Модель	Размерность	Особенности
OpenAI text-embedding-3-small	1536 (можно обрезать)	Дешёвая, широко поддерживается, Matryoshka-свойства
OpenAI text-embedding-3-large	3072 (можно обрезать)	Качественнее, заметно дороже
Cohere Embed v3	1024	Multilingual версия, отдельная для англ.
bge-m3 (open-source)	1024	Self-hosting, multilingual, хорошее качество
voyage-3	1024	Специализации для доменов (code, law, finance)

Модели обучены так, что семантически близкие тексты дают близкие векторы. Метрика близости - cosine similarity, косинус угла между векторами, диапазон от -1 до 1:

similarity(a, b) = (a · b) / (||a|| × ||b||)

На практике векторы обычно нормализованы (||v|| = 1), и similarity вырождается в dot product. Это упрощает вычисления и позволяет использовать inner product search в vector DB вместо explicit cosine.

Bi-encoder vs cross-encoder. Bi-encoder кодирует запрос и документ независимо: для миллионного корпуса все документы предвычисляются один раз и хранятся в индексе, на запрос кодируется только query. Это делает поиск дешёвым. Недостаток: модель не учитывает взаимодействие query и document напрямую, качество ограничено.

Cross-encoder кодирует пару [query; document] вместе, attention работает через весь вход. Качество существенно выше (обычно +20-30% NDCG), но для миллиона документов это миллион LLM-вызовов на запрос - неприемлемо. Отсюда паттерн two-stage retrieval: bi-encoder (дешёвый) выбирает top-100 кандидатов из миллиона, cross-encoder (дорогой) ранжирует 100 до top-10.

Vector DB и ANN-индексы. Точный поиск ближайшего вектора в миллионном корпусе - полный перебор с миллионом умножений вектора длины 1536. На современном CPU ~1-2 секунды на запрос, неприемлемо для real-time. Approximate Nearest Neighbors (ANN) жертвует небольшой точностью за большое ускорение:

• HNSW (Hierarchical Navigable Small World). Многослойный граф: верхние слои - редкие, дают быстрый greedy-навигацию к региону, нижние - плотные, дают точность. Параметры: M (количество соседей на узел, обычно 16-32), ef_construction (ширина поиска при построении, 100-500), ef_search (ширина поиска при запросе, 50-300). Стандарт по качеству и скорости для корпусов до 100 млн векторов. Используется в pgvector, Qdrant, Weaviate, Milvus.
• IVF (Inverted File Index). Кластеризация через k-means, каждый вектор приписан к ближайшему кластеру. Поиск: найти nprobe ближайших кластеров к query, полный перебор внутри. Параметры: nlist (количество кластеров, √N как отправная точка), nprobe (сколько кластеров проверять при запросе, 1-20). Быстрее HNSW на вставку, хуже качество на границе кластеров.
• PQ (Product Quantization). Вектор разбивается на M подвекторов, каждый квантуется в один из 256 codes. Вектор превращается из 1536 × 4 байта в M байт (обычно 64). Экономит память в ~100 раз, но теряет точность. Применяется вместе с IVF (IVF-PQ) для гигантских корпусов.
• FAISS. Библиотека Meta, включающая HNSW, IVF, PQ и их комбинации. Де-факто стандарт для self-hosted поиска.

Chunking стратегии. Исходный документ редко хорошо индексируется целиком: он может быть слишком длинным для embedding-модели (обычно 512 токенов лимит), или содержать разные темы, которые embedding усредняет до размытого вектора. Стратегии разбиения:

• Fixed-size. 512 токенов с overlap 50. Просто, но режет по середине предложения, теряет смысл. Работает плохо для связных текстов.
• Sentence-based. Разбиение по предложениям с объединением до порога (обычно 200-400 токенов). Лучше сохраняет смысл, но предложения могут быть разной длины.
• Semantic chunking. Разбиение по изменению темы: считаем embedding каждого предложения, находим точки наибольшего cosine distance между соседями, режем там. Требует дополнительных embedding-запросов, но даёт чанки с высокой внутренней когерентностью.
• Structural. По markdown-заголовкам, функциям, классам, XML-тегам. Работает отлично для структурированных документов: кода, документации, API-спек.
• Hierarchical (parent-document). Индексируем мелкие чанки (например, параграфы по 200 токенов) для точности поиска, но в контекст LLM возвращаем родительский блок (например, секция целиком). Снимает проблему «нашёл релевантную строку, но без контекста».
• Contextual retrieval (Anthropic, 2024). К каждому чанку добавляется сгенерированный LLM короткий контекст: «этот параграф из главы о финансовых отчётах за 2024». Embedding строится по чанку + контекст. Даёт +30-50% accuracy на корпусах с высоким overlap между документами.

Query transformation. Запрос пользователя часто беден для поиска. Пользователь пишет «как оплатить» - в документации эта фраза не встречается. Техники усиления:

• HyDE (Hypothetical Document Embeddings). LLM генерирует гипотетический ответ на запрос («Оплатить можно через банковскую карту или PayPal...»), embedding делаем от ответа, не от вопроса. Эмбеддинг ответа ближе к документам, чем эмбеддинг вопроса.
• Query expansion. LLM генерирует 3-5 переформулировок запроса: «как оплатить», «способы оплаты», «доступные методы платежа», «настроить billing». Поиск делается по каждому, результаты объединяются с дедупликацией.
• Step-back prompting. Перед конкретным запросом модель формулирует более общий контекстный вопрос: «какие вообще способы оплаты описаны в документации» - ищет этот контекст, потом фокусируется на исходном.
• Sub-question decomposition. Сложный запрос («сравни подходы A и B в контексте C») разбивается на подвопросы, каждый ищется отдельно, результаты объединяются.

Hybrid search. Только dense retrieval проваливается на точных именах, идентификаторах, редких терминах. Пример: поиск «StripeWebhookController» - семантически близко к «WebhookHandler», «PaymentProcessor», но ни один из них не то. BM25 (классический lexical, основан на term frequency × inverse document frequency) ловит точные совпадения. Hybrid объединяет score двух систем:

final_score = α × dense_score + (1 - α) × bm25_score

Типичное α от 0.5 до 0.7. Перед объединением оба score нормализуются (min-max или z-score), иначе разный диапазон исказит комбинацию. Альтернатива - Reciprocal Rank Fusion (RRF): результаты двух систем ранжируются отдельно, потом RRF-формула объединяет ранги без нормализации score. RRF часто работает лучше на практике.

Hybrid search - стандарт production RAG, dense-only систем в production почти нет. Pinecone, Weaviate, Qdrant, Elasticsearch - все поддерживают hybrid из коробки.

Reranking. После top-100 от retriever запускается cross-encoder (Cohere Rerank API, bge-reranker-v2, jina-reranker) и переупорядочивает кандидатов. Cross-encoder видит полный текст каждого документа в паре с запросом, использует attention между ними - качество ранжирования существенно выше. Типичный прирост recall@10 - 15-25% при стоимости порядка $2 на 1000 запросов.

RAG end-to-end и его оценка

Полный pipeline:

Ingestion → Chunking → Embedding → Vector Store
                                         ↓
                    Query → Transform → Retrieve (hybrid)
                                             ↓
                                        Rerank (top-K)
                                             ↓
                                   Context Assembly → LLM → Answer

Каждый этап - отдельный источник ошибок. Плохой chunking режет документ неудачно - ответ будет на основе обрывка. Слабое query transformation - retriever не находит релевантное. Retrieval возвращает нерелевантное - LLM галлюцинирует на основе шума. Отсюда необходимость метрик, которые различают тип проблемы.

Фреймворк RAGAS (Retrieval Augmented Generation Assessment) вводит четыре основные метрики:

Метрика	Что измеряет	Как считается	На что настраивается
Context Precision	Доля релевантных чанков среди retrieved	LLM-judge оценивает каждый retrieved chunk на релевантность вопросу, усредняется	Reranker, query transformation
Context Recall	Покрывает ли retrieved-набор нужную информацию для ответа	Сравнение retrieved chunks с ground-truth ответом через LLM-judge	Chunking, retriever, top-K размер
Faithfulness	Подтверждается ли ответ LLM извлечённым контекстом (отсутствие hallucination)	Ответ разбивается на claims, каждый проверяется на наличие в контексте LLM-judge	Generator prompt, LLM choice
Response Relevancy	Отвечает ли ответ на заданный вопрос	LLM генерирует вопросы, которые ответ мог бы удовлетворить; сравнение с исходным	Generator prompt, LLM choice

Первые две метрики разбирают retriever, вторые две - generator. Декомпозиция критична: если faithfulness высокий, но response relevancy низкий, проблема в промпте генератора, а не в retrieval. Если context recall низкий, проблема в chunking или ретривере, а не в LLM.

Production-процесс evaluation строится вокруг golden dataset: 50-500 пар (вопрос, ideal answer, список relevant chunks), собранных руками экспертов предметной области. При любом изменении (новая chunking-стратегия, другой embedding-model, обновлённый промпт) запускается evaluation на golden dataset, измеряются все четыре метрики, сравниваются с baseline. Без golden dataset RAG-оптимизация - движение вслепую.

Когда RAG не нужен. Вопрос экономии и архитектурной простоты:

• Корпус помещается в 50К токенов и стабилен - отправлять целиком в system prompt и полагаться на prompt caching. Нулевая инфраструктура, мгновенный поиск.
• Задача классификации или форматирования без внешних знаний - fine-tune дешевле в долгую, потому что не требует retrieval на каждый вызов.
• Задача требует узкого домена без вариативности - структурированный prompt с few-shot примерами может работать лучше RAG, потому что few-shot даёт образец формата.

RAG имеет смысл когда корпус больше контекстного окна, часто обновляется (переиндексация дешевле fine-tune), или нужна traceability - возможность показать источник ответа пользователю. Последнее особенно важно в compliance-чувствительных доменах: юридическая консультация, медицинская информация, финансовые рекомендации.

Token optimization

Токены - прямая стоимость (цена API) и косвенная (context rot снижает качество). Техники оптимизации с конкретными диапазонами эффекта:

• Декомпозиция файлов. Файл на 50 строк полностью помещается в контекст и виден агенту целиком. Файл на 800 строк - агент видит частично (прочитает через tool, но не сможет удержать весь в рабочей памяти). Маленькие файлы дают точнее правки, меньше ошибок «поменял здесь, забыл там». Порог - обычно 100-200 строк на файл как soft limit.
• Progressive disclosure. Skill-описания в Claude Code показывают только имя и краткое описание (~1 строка) до момента использования. При вызове - загружается полное описание с примерами. Позволяет держать 50-100 команд в доступе с стоимостью по токенам как у 3-5 без progressive disclosure. Эффект - ~95% экономии токенов на описания.
• Sub-agent изоляция. Вынос подзадачи в отдельный sub-agent со своим контекстным окном. Мастер-агент видит только итог sub-agent-а, не весь процесс. Применяется для задач, где процесс поиска большой, а ответ короткий (grep по огромному репозиторию, web-исследование). Эффект - освобождение основного окна мастера, который продолжает с чистой головой.
• Compaction (summarization). Harness при приближении к лимиту окна вызывает LLM для суммаризации ранней истории в короткий конспект и заменяет ей исходные сообщения. В Claude Code auto-compaction срабатывает автоматически, качество суммари зависит от модели. Риск - потеря важных деталей, которые summarizer не счёл существенными. Практика - явный прогон compaction-а с контролем (человек ревьюит резюме перед продолжением).
• Structured note-taking. Вместо удержания в контексте состояние выносится во внешний файл (progress.md), читается по необходимости. Агент явно инструктируется записывать промежуточные решения в файл и читать оттуда, а не держать в голове. Эффект - длинные задачи становятся посильными в пределах окна.
• Prompt caching. Стабильный префикс даёт многократный кэш-hit, снижая стоимость в 10 раз. На длинных сессиях кумулятивная экономия достигает 80-90% от стоимости без кэширования. Требует аккуратной структуры промпта (см. раздел Attention и кэш).
• Тoken-level compression. LLMLingua и схожие методы: отдельная маленькая модель удаляет «малоинформативные» токены из промпта перед подачей в основную модель. Экономит 30-50% токенов, применяется в специфических pipeline.

Multi-agent архитектуры

Одна роль-агент упирается в confusion: нельзя одновременно быть хорошим архитектором, разработчиком, ревьювером, SRE, security-специалистом. Каждая роль требует своего system prompt, своего набора тулов, своего фокуса внимания. Multi-agent разделяет роли в отдельные sub-агенты.

Orchestrator-worker (supervisor pattern). Менеджер-агент декомпозирует задачу, делегирует sub-агентам (architect, dev, QA, code-reviewer, security, code-simplifier, librarian), собирает результаты. Каждый sub-агент - изолированное контекстное окно и собственный system prompt под роль. Мастер видит только итоги, не весь процесс, что освобождает его окно от шума. Недостаток - зависимость от мастера: если мастер ошибётся в декомпозиции, sub-агенты сделают правильно не то. Плюс overhead на каждый handoff (новый контекст, новый system prompt).

Hierarchical (дерево). Мастер делегирует не напрямую листьям, а промежуточным менеджерам по направлениям (backend-lead, frontend-lead, devops-lead), каждый из которых делегирует своим sub-агентам. Применяется для очень крупных задач, где плоская декомпозиция даёт слишком много параллельных веток.

Peer-to-peer (swarm). Агенты не имеют иерархии, но могут вызывать друг друга. Более гибкая, но сложнее в отладке. Применяется редко в production из-за сложности контроля.

File-based vs message-based handoff. Способ передачи состояния между агентами:

• Message-based: агенты обмениваются сообщениями in-memory (LangGraph с StateGraph, CrewAI с task-outputs). Низкая задержка, но сложнее аудит - история в памяти процесса, при падении теряется.
• File-based: агенты пишут и читают markdown-файлы (spec.md, contract.md, review.md) в шаренной директории или git-репозитории. Медленнее (тул-вызовы на каждое чтение/запись), но каждое состояние - артефакт. Аудируется, откатывается, служит voltage-контрактом между ролями. Конкретный dev-агент может быть заменён на другого в середине задачи - он прочитает контекст из файлов.

File-based подход устойчивее к сбоям и понятнее людям. Его практическая реализация - папка tasks/TASK-123/ со structure:

tasks/TASK-123/
├── spec.md           # вход от product-manager
├── architecture.md   # выход architect-агента
├── plan.md           # выход planner-агента (разбивка на подзадачи)
├── subtasks/
│   ├── 001-setup.md
│   ├── 002-api.md
│   └── ...
├── review.md         # выход code-reviewer
├── security-audit.md # выход security-агента
└── progress.md       # итерирует dev-агент

Agent-checks-agent layering. Post-dev агент (code-simplifier) упрощает результат dev-агента, убирая излишества и boilerplate. Code-reviewer проверяет результат simplifier-а на логические баги и соответствие правилам. Security-агент проверяет результат reviewer-а на injection, secret leaks, unsafe deserialization, unsafe deps. Три слоя ловят разные типы ошибок: simplifier убирает noise, reviewer - логику, security - security. Эффективность каждого слоя - порядка 60-80% catch rate на своём классе ошибок, кумулятивно ~95% на всех классах.

Роль AI Librarian - агент, задача которого читать статьи и лучшие практики про AI-разработку (блог Anthropic, research papers, посты на Medium) и предлагать изменения в собственную систему промптов. Dogfooding: система эволюционирует силами самих агентов под надзором инженера. Типовой цикл: librarian читает статью, формирует diff в prompt-файлах, инженер ревьюит diff, merge. Это снимает с человека рутинное обновление промптов под новые практики.

Параллельные сессии

AI-native инженер работает с 4-10 параллельными сессиями одновременно. Одна сессия - одна задача или одна фаза задачи. Организация требует инструментальной поддержки, иначе переключение между ними съедает выигрыш от параллельности.

tmux + tmuxinator. tmux - терминальный мультиплексор, позволяющий иметь несколько независимых терминалов в одном окне, разделённых на panes. tmuxinator - YAML-конфиг, описывающий layout сессии: какие windows и panes открыты, что в каждом запущено, где корневая директория. Запуск проекта из конфига - одна команда, переключение между сессиями через shortcuts O(1). Detach/attach позволяет вернуться к сессии через час или день в том же состоянии.

# ~/.config/tmuxinator/billing-project.yml
name: billing
root: ~/projects/billing

windows:
  - main:
      layout: main-vertical
      panes:
        - claude:
          - claude
        - logs:
          - tail -f tmp/log/development.log
        - shell
  - db:
      panes:
        - rails dbconsole
  - tests:
      panes:
        - bundle exec rspec --fail-fast

Проблема git worktree. Claude Code предлагает worktree как способ параллелизации: git worktree add ../feature-X создаёт отдельную рабочую директорию на другой ветке. На практике worktree - symlink на одну и ту же .git папку. Это создаёт race conditions:

• Если одна сессия делает git stash, stack стэшей общий - другая сессия может случайно git stash pop не свой.
• Одновременные операции с index (staging area) могут конфликтовать.
• Hooks запускаются на одном и том же файле .git/hooks, не разделены по worktree.
• Refs (branches, tags) общие - две сессии, пишущие в разные ветки параллельно, могут создать непредсказуемый hooks-поток.

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

Альтернатива: полная изоляция окружения. Shell-скрипт setup-session генерирует полную копию окружения для каждой сессии:

• Отдельный session_name (передаётся как переменная окружения, используется во всех генерируемых ресурсах).
• Отдельный ENV-файл из template, с уникальными portами, именами БД, namespace-ами. Существующий ENV не переписывается.
• Отдельные контейнеры postgres, redis, любых зависимых сервисов на уникальных портах, с уникальными именами volume.
• Домен {session_name}.{project}.localhost через loopback - внешние инструменты (webhook-testers, OAuth callbacks) могут ссылаться на сессию по имени.
• Отдельная git-репозитория через git clone, не worktree. Полная изоляция, но дублирование объектов.

Каждая сессия - полноценный clone окружения. Базы данных, кэши, очереди изолированы. Race conditions исключены. Overhead - дисковое место и память, но на современных ноутбуках с SSD это приемлемо для 6-10 сессий.

Практический лимит. Физический потолок - ресурсы ноутбука (обычно 30-60% RAM занимают сессии, остальное - система и браузер). Когнитивный потолок ниже: 4-6 параллельных сессий. С десятью инженер теряет контекст при возврате: «о чём я тут думал», что превращает параллельность из выигрыша в убыток от переключений. Это не ограничение инструмента, а ограничение человека-оркестратора.

Vendor agnosticism

Claude 4.6, GPT-5, Gemini 3, DeepSeek V3, Llama 4, Grok 4 ротируются в топах разных бенчмарков раз в месяц. Привязка к одному вендору - структурный риск:

• Модель может деградировать: Anthropic, OpenAI, Google регулярно обновляют модели «тем же именем», иногда с регрессиями на отдельных классах задач.
• Вендор может поднять цены: GPT-4 → GPT-4 Turbo → GPT-4o миграции были с изменениями ценообразования.
• Новый игрок может опередить на определённой нише: DeepSeek на коде, Claude на long-context reasoning, Gemini на multimodal.
• Вендор может ввести ограничения на доступ: geo-блокировки, usage caps, изменения TOS.

Практика vendor-agnostic архитектуры:

Абстрактный prompt layer. Промпты хранятся в .ai/ как plain markdown-файлы. Не в .codex/, не в .cursor/, не в .claude/. Структура предсказуемая:

.ai/
├── system/
│   ├── architect.md
│   ├── developer.md
│   ├── reviewer.md
│   └── ...
├── prompts/
│   ├── refactor.md
│   ├── document.md
│   └── ...
└── adapters/
    ├── install-claude.py
    ├── install-codex.py
    └── install-cursor.py

Адаптеры. Python или bash-скрипт копирует промпты в vendor-специфичные папки при смене инструмента: Claude Code ожидает файлы в .claude/agents/ и .claude/commands/, Codex - в .codex/agents/, Cursor - в .cursor/rules/. Добавление нового вендора - написание одного адаптера, не переписывание всех промптов.

Tool abstraction через MCP. Где возможно - через MCP (см. раздел Tool use). MCP-серверы работают кросс-вендорно: один MCP-сервер для Jira подключается к Claude Code, Cursor, Codex без изменений. Vendor-specific возможности (hooks Claude Code, plan mode, agents Codex) изолируются в отдельном слое, который применяется только на конкретном vendor-е.

Model routing. Для разных задач - разные модели. Быстрая и дешёвая (Haiku, GPT-4o-mini, Gemini Flash) для форматирования, классификации, простых отчётов. Дорогая и умная (Opus, GPT-5, Gemini Pro) для планирования, архитектурных решений, сложного reasoning. Гибридный стек экономит до 40% бюджета при том же качестве итогов. Инструменты роутинга:

• LiteLLM - прокси-сервер с унифицированным API над 100+ моделями, с маршрутизацией, fallback, rate limiting.
• Vercel AI SDK - JS-библиотека с абстракцией над вендорами, с типизированными tool calls.
• OpenRouter - managed сервис, предоставляющий unified billing и routing.

Миграция Cursor → Codex → Claude Code → следующий инструмент при такой архитектуре занимает день, не квартал. Это разница между «владею системой» и «работник одного инструмента».

Сценарии интервью

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

Pipeline walkthrough

Формулировка вопроса: «Проведи через реальную задачу - от идеи до merge, в деталях».

Проблематика. Вопрос проверяет ментальную модель работы с агентом на масштабе большем чем один чат-turn. LLM - stateless функция (см. раздел Inference loop); в рамках одной сессии контекст копится и попадает в режимы отказа длинного контекста (см. раздел Контекстное окно). Инженер, который успешно ведёт задачу от идеи до merge через агента, внутренне различает эти ограничения и строит процесс, компенсирующий их. Интервьюер ищет не факт «мне дали задачу - я сделал», а схему процесса, устойчивую к свойствам LLM.

Что требуется объяснить:

• Декомпозицию задачи на отдельные фазы: PRD → план → задачи → реализация. Каждая фаза в чистой сессии. Обоснование - избежать poisoning и distraction, когда ранняя ошибка или устаревший контекст тянутся по всей истории.
• Артефакты каждой фазы как внешнюю память между сессиями. Markdown-файлы (prd.md, plan.md, task-*.md) служат контрактами: результат одной фазы становится входом следующей. Инженер ревьюит артефакт руками до передачи дальше.
• Q&A как отдельный этап после каждой спецификации. Задача - явно вычленить неявные допущения пока они дёшевы (изменение абзаца текста), а не после реализации (переписанный код и тесты).
• Параллельность сессий с изоляцией окружения. Реальный лимит 4-6. Физический потолок выше (ресурсы ноутбука), но когнитивный ниже: при возврате к десятой сессии инженер не помнит что там происходило.
• Realtime-мониторинг процесса. Сессии держатся открытыми, инженер смотрит tool calls по ходу, не только итоговый PR.

Почему так. На маленькой задаче «дал Claude, он сделал» работает. С ростом размера и критичности задачи эта модель ломается: контекстное окно наполняется до context rot, ошибки накапливаются, несколько параллельных сессий без артефактов приводят к конфликтам, без realtime-мониторинга проблема обнаруживается только в финальном PR. Структура с именованными артефактами, чистыми сессиями и Q&A - инженерная компенсация stateless природы LLM и ограниченного контекстного окна. Ответ «дал Claude - он сделал» показывает отсутствие этой компенсации и pipeline, не масштабирующийся выше todo-app уровня.

Brownfield scenario

Формулировка вопроса: «N-летний Ruby on Rails монолит с кластером биллинга. Stripe, PCI-данные, webhooks, subscription tiers, proration. Задача - добавить usage-based billing. Проведи через первые две недели».

Проблематика. Может ли кандидат работать с кодовой базой, которую не писал и которую никто живой в команде детально не помнит. В AI-native мире legacy попадает в категорию «распаковать агентом», но только с правильной инфраструктурой контекста. Плюс оценивается доменное мышление: для биллинга - знание плоскостей риска (latency, idempotency, security, PCI), не только структурное «вот модуль».

Что требуется объяснить:

• Первая фаза - картография, не изменения. Агент проходит по репозиторию, строит архитектурную карту (Mermaid-диаграммы компонентов и потоков данных), перечисляет entry-points (webhook handlers, API endpoints, background jobs), выделяет боундари между подсистемами. Выход - markdown-артефакт, читаемый людьми и используемый как контекст агентов в следующих задачах.
• Покрытие тестами до изменений. Legacy-код часто не имеет тестов или имеет их фрагментарно. Прежде чем менять поведение - зафиксировать текущее: агент генерирует позитивные (happy path) и негативные (edge cases, ошибки) тесты. Это safety net на момент, когда агент начнёт правки: регрессия детектируется автоматически, не через production incident.
• Явное называние доменных плоскостей биллинга. Latency: retry storms при деградации, необходимость async где возможно. Idempotency: Stripe доставляет webhooks с возможными дубликатами, нужны idempotency keys на все мутирующие операции. PCI: какие поля classified, где их нельзя логировать, где нельзя хранить после обработки. Security: модель доступа к биллинг-данным, уровень изоляции арендаторов.
• Feature flag и grandfathering. Новый subscription tier деплоится за флагом, активируется постепенно для подмножества клиентов. Существующие подписки остаются на прежних условиях (grandfathering) - снижает риск регрессии по выручке.
• Мониторинг. Алерты на рост latency, изменения error rate, webhook failures. Без мониторинга релиз слепой: проблема обнаруживается когда клиент напишет в поддержку.

Почему так. Биллинг - система с высоким blast radius. Ошибка приводит к двойному списанию, потерянному платежу или compliance-инциденту. Стоимость одной ошибки - реальный ущерб клиенту, работа поддержки, возможный chargeback, потенциальный аудит. В малокритичном проекте можно начать с изменений и чинить по ходу; в критичном сначала создаётся страховочная сетка (картография + тесты + мониторинг), потом меняется поведение. Кандидат, который сразу идёт в код, не работал с критичными системами или не воспринимает их как критичные. Про idempotency keys подробнее в статье «Idempotency Keys».

Feedback loop

Формулировка вопроса: «Агент обходит проблему вместо решения. Падающий тест помечает skip и идёт дальше. Как это ловится, что с этим делать?»

Проблематика. Инженерная дисциплина в отделении «сделалось» от «сделалось правильно». Обход проблем - конкретный failure mode LLM, воспроизводимый и наблюдаемый в практике. Вопрос проверяет, признаёт ли кандидат свойство модели как инженерное условие и строит ли процесс его компенсирующий.

Что требуется объяснить:

• Природу failure mode. LLM обучена давать ответ; отсутствие решения - плохой сигнал с точки зрения её функции потерь. Минимальный путь к «зелёному» сигналу для неё - обойти препятствие: пометить тест skip, завернуть в try/except без обработки, закомментировать падающий кусок. Это свойство оптимизации на локальный сигнал «задача закрыта», а не баг конкретной модели.
• Realtime-мониторинг процесса. «Дал задачу, пошёл пить кофе» работает для тривиальных задач. Для нетривиальных сессии держатся открытыми, инженер смотрит tool calls по ходу. Отсюда лимит 4-6 параллельных сессий - больше не удерживается в поле внимания одного человека.
• CI и pre-commit guardrails на известные паттерны обхода. Skip-тесты без issue-ссылки блокируют merge. Линтер ругается на @pytest.mark.skip без комментария, на пустые catch-блоки, на закомментированный код без маркера. Это превращает хитрость LLM в детектируемую проблему на уровне инфраструктуры, не на уровне бдительности человека.
• Итеративное закрепление правил в CLAUDE.md или rules когда паттерн повторяется. Например: «запрещено помечать тесты skip; при падении теста остановиться и сообщить причину человеку». Rule переживает сессии и не требует повторного объяснения.
• Agent-checks-agent как дополнительный слой. Code-reviewer-агент проверяет diff dev-агента на конкретные паттерны (skip, try/except без handler, новые TODO). Три слоя проверок (dev → simplifier → reviewer) ловят разные типы проблем.

Почему так. LLM оптимизируется на локальный сигнал «задача закрыта». Глобальный (правильно ли решено, не сломано ли смежное поведение) - вне её функции потерь. Без внешних guardrails агент систематически выбирает самый дешёвый путь к локальному сигналу. Единственный способ закрыть этот gap - встроить проверки в процесс: CI, pre-commit, rules, слои проверяющих агентов. Опора на бдительность одного человека не масштабируется и ломается при усталости. Ответ «доверяю агенту» указывает либо на отсутствие опыта с этим failure mode, либо на работу в малокритичном контексте, где он не был замечен.

Метрики

Формулировка вопроса: «Руководство сообщило 30% улучшение от AI-внедрения. Ты должен валидировать цифру. Как считаешь?»

Проблематика. Знание стандартных фреймворков продуктивности (DORA, SPACE), различение output от outcome, понимание закона Гудхарта. Вопрос проверяет способность кандидата оппонировать цифре не по эмоции, а по методологии.

Что требуется объяснить:

• Закон Гудхарта: когда мера становится целью, она перестаёт быть хорошей мерой. Пример: «строки кода в день» привязанные к премии - инженеры начинают писать многословный код. Метрика растёт, качество падает.
• Иерархию Effort → Output → Outcome → Impact. Effort - затраченное время. Output - написанный код, закрытые тикеты. Outcome - решённая задача пользователя, закрытый сценарий использования. Impact - бизнес-метрика (revenue, retention, time-to-market). Продуктивность не измеряется на уровне effort или output изолированно.
• DORA как стандарт delivery-метрик: lead time for changes, deployment frequency, change failure rate, mean time to recovery. Все на уровне команды. DORA отвечает на вопрос «насколько быстро и стабильно команда доставляет», а не «кто пишет больше кода».
• SPACE как framework пяти измерений: satisfaction & well-being, performance, activity, communication & collaboration, efficiency & flow. Activity (коммиты, PR) - одно из пяти, его нельзя использовать изолированно.
• Валидацию заявленных «+30%» через условия: baseline (метрики до внедрения), контроль за confounders (другие изменения в команде за тот же период), decomposition (что именно ускорилось - написание, review, PRD, testing). Без этих условий цифра остаётся утверждением, а не фактом.
• Индивидуальные метрики как ловушку. У разработчика outcome командный - в отличие от sales, где outcome индивидуален (подписанный контракт). Привязка «+30%» к конкретному инженеру - Гудхарт в чистом виде: инженер оптимизируется под метрику, не под реальный outcome.

Почему так. Руководство под давлением отчётности ищет простые числа. Инженер, который спрашивает «30% от чего, с какого baseline, с учётом каких других изменений» - не оппонирует, он просит минимальные условия для валидности утверждения. Без них «30%» - PR, не инженерный факт. Ответ «по строкам кода» показывает отсутствие знания о законе Гудхарта и отсутствие опыта с командными метриками. Разбор DORA и SPACE с практическими ловушками - в статье «Можно ли измерять продуктивность».

Validation strategy

Формулировка вопроса: «Что агенту не разрешено делать без человека?»

Проблематика. Архитектурный вопрос проектирования permission-модели процесса. Принимает ли кандидат свойство LLM - ненулевая и непредсказуемая вероятность ошибки - как условие, требующее компенсации структурой процесса, а не надеждой на «хорошую модель».

Что требуется объяснить:

• Концепт blast radius. Действия классифицируются по обратимости. Редактирование файла в feature-branch - обратимо через git. Запуск теста - обратим. git push к feature-branch - обратим через revert. git push --force к main - разрушителен для команды. Production deploy - разрушителен. DROP TABLE, DELETE без WHERE, rm -rf - разрушительны. Внешние платежи - необратимы без вмешательства третьей стороны.
• Принцип: чем выше blast radius, тем ниже допустимая вероятность ошибки на этом действии. У LLM вероятность ошибки ненулевая и непредсказуемая - следовательно действия с высоким blast radius не могут быть автоматизированы агентом.
• Конкретный список human gate: merge PR, production deploy, удаление данных (DROP/TRUNCATE/DELETE без WHERE/rm -rf), ротация или модификация секретов, внешние платежи (refund, charge), изменение квот и лимитов внешних API, force-push к защищённым веткам.
• Техническую реализацию. В Claude Code permissions deny/ask/allow. Deny - команда не вызывается; модель не обходит, потому что ограничение на уровне harness до LLM-вызова. Ask - запрос подтверждения у человека. Allow - автоматически. Нереверсируемые операции - deny или ask.
• Пример правил для биллинг-проекта. git push к main, release/* - deny. gh pr merge - deny. Production database connection - deny. Deploy-скрипты - deny. Stripe refund API - deny. Агент готовит патч, миграцию, deploy plan - инженер применяет после review.

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

Technical depth probe

Формулировка вопроса: «Объясни prompt caching / hybrid search / context rot / agent harness vs LLM API / MCP / RAG evaluation».

Проблематика. Отличить «знаю термин» от «применял концепт». Термины вокруг AI-разработки широко в обороте, любой Medium-пост содержит prompt caching, RAG, context rot. Способ разделения - спросить про внутреннюю механику.

Что требуется объяснить. Формат сильного ответа: определение → внутренняя механика → практическое следствие → конкретный пример из опыта.

Пример на prompt caching. Определение: Anthropic кэширует обработанный префикс промпта до 5 минут. Механика: attention квадратично по длине входа, вычисление KV-cache для префикса можно сохранить и переиспользовать на последующих вызовах с тем же префиксом. Следствие: стабильная часть промпта (system prompt, CLAUDE.md, правила, описания тулов) в начале, переменная часть (текущий user message) в конце; перестановка ломает кэш и повышает стоимость в 10 раз. Пример: в pipeline из 20 task-файлов общий контекст вынесен в префикс, кэш-hit снизил стоимость сессии на 70% и latency на 40%.

Пример на context rot. Определение: падение точности модели с ростом объёма контекста внутри окна. Механика: attention распределяется на все токены; информация из начала размывается при большом объёме после неё; эффект lost-in-the-middle (середина окна хуже всего). Следствие: окно не наполнять до максимума, важное в начало и конец, compaction при приближении к лимиту. Пример: сессия с историей 150К токенов перестала видеть инструкции из system prompt; вынесено состояние в progress.md, открыта чистая сессия с restore из файла.

Пример на hybrid search. Определение: комбинация dense retrieval (embeddings + cosine) и sparse retrieval (BM25) в единой ранжировке. Механика: dense даёт семантическую близость, BM25 - лексическую; финальный score = α × dense + (1 - α) × bm25, α обычно 0.5-0.7. Следствие: для корпусов с именами, идентификаторами, редкими терминами dense-only проваливается, hybrid стандарт для production. Пример: на корпусе API-документации hybrid дал +18% recall@10 по сравнению с только dense.

Почему так. Знание термина без механики - признак прочитанного поста. Знание механики - признак построенного pipeline, где механика важна для работы или оптимизации. Интервьюер, знающий разницу, выделяет тридцать секунд на follow-up «почему перестановка ломает кэш» или «зачем BM25 если есть embeddings» и получает сигнал с высокой точностью. Антипаттерн ответа: «prompt caching - это когда кэшируют промпт». Пересказ названия, нет механики, follow-up обнажит отсутствие понимания.

Три профиля кандидатов на рынке

На AI-native позиции выходят три распространённых профиля. Каждый оптимален под свой тип роли, и попытка нанять не по профилю даёт предсказуемое расхождение ожиданий и результата через 3-6 месяцев.

Operator

Основная ценность - работающий pipeline в условиях реальной продуктовой команды. Параллельные сессии с изоляцией окружения (tmux + tmuxinator + custom setup scripts для dev-окружений), личный инструментарий для мониторинга метрик команды, тактический опыт внедрения AI в команду через champions program, постепенный rollout, работа с сопротивлением.

Operator обычно прошёл цикл: сначала внедрял инструменты сверху («все должны использовать Cursor»), получил откат и саботаж, переключился на bottom-up подход с лидами-чемпионами, построил метрики, показал результат. Этот опыт трансформации команды так же ценен как техническая глубина: без него любая AI-first инициатива превращается в ритуал с имитацией использования.

• Подходит: Senior/Staff product engineer, tech lead в продуктовой команде, engineering manager со вкусом к работе руками.
• Типичные пробелы: глубина RAG и embeddings поверхностная (теоретически знает термины, но не строил production RAG с evaluation); multi-agent системы с нуля не строит (использует готовые harness-ы, кастомизирует на уровне промптов и skills).
• Сигналы на интервью: конкретные имена скриптов (setup-session.sh, parallel-claude.sh), названия метрик команды (lead time, review time, throughput), примеры разрешения конфликтов при внедрении (кто саботировал и почему, как решилось).

Product-builder

AI как материал продукта: RAG в приложении, conversational UX, LLM во флоу пользователя, динамический context trimming под стадии разговора, dynamic prompt assembly под профиль клиента. Метрики успеха продуктовые - A/B-тесты, retention, конверсия, LTV.

Product-builder обычно пришёл в AI из продуктовой разработки или founding engineering. Видит LLM как ещё один API, но с особенностями (недетерминизм, стоимость, латентность). Решения о RAG vs fine-tune vs prompt принимает через призму requirements продукта: traceability нужна → RAG, узкий домен без вариативности → fine-tune, дешёвая классификация → prompt. Может не знать теоретически насыщенные термины (compaction, progressive disclosure), но знает продуктовые паттерны (human-in-the-loop для сложных случаев, fallback на правила при low confidence).

• Подходит: Product engineer в AI-heavy продукте, founding engineer стартапа, AI/ML engineer с продуктовым уклоном.
• Типичные пробелы: глубина dev-процесса меньше (не строит agent pipeline для разработки); может не владеть терминами agent harness, MCP, compaction; думает больше продуктово чем системно-инфраструктурно.
• Сигналы на интервью: начинает ответы с «пользователь делает X, потому что Y»; знает метрики продукта (LTV, retention curves, funnel drop-off); объясняет выбор RAG vs fine-tune vs prompt через требования продукта, не через абстрактные лучшие практики.

Multi-agent architect

Формализованная система ролей: manager, architect, dev, QA, reviewer, simplifier, librarian, security. File-based handoff между агентами через markdown-артефакты, vendor-agnostic prompt layer с адаптерами, три слоя agent-checks-agent, жёсткий human gate на git и deploy. Инвестирует в инфраструктуру контекста как в отдельную инженерную дисциплину.

Multi-agent architect обычно пришёл из платформенной инженерии, distributed systems, или из опыта управления большими командами (ролевая структура агентов - отражение ролевой структуры команд). Brendan Burns в публичных выступлениях про платформенную инженерию (см. его книгу «Designing Distributed Systems», O'Reilly, 2018) описывает ту же фигуру - человек, который думает контрактами между компонентами и retry-политиками, переносит этот образ мышления на агентную архитектуру. Видит агентов как узлы distributed system со своими контрактами, очередями, retry-логикой. Обсуждает не «я использую Claude», а «я спроектировал workflow с пятью ролями и вот контракты между ними». Результат инвестиций - система, в которой замена любого компонента (вендор модели, harness, конкретная роль) не требует переписывания всего.

• Подходит: Staff engineer, платформенная роль, построение AI-first org внутри большой компании, principal engineer.
• Типичные пробелы: overhead инфраструктуры слишком велик для маленьких задач и стартапов; риск overengineering (системы из 8 ролей для задачи, которую один dev-агент закроет за час); может увлечься инфраструктурой в ущерб доставке продуктового результата.
• Сигналы на интервью: рисует диаграммы ролей и контрактов, объясняет что агент X читает из файла Y и записывает в Z, называет конкретные выходные артефакты каждого агента, обсуждает vendor-agnostic стратегию как осознанное архитектурное решение.

На практике профили смешиваются: сильный operator может владеть частью multi-agent паттернов, product-builder - частью infrastructure. Попытка имитации неосвоенного профиля ловится технической probe из раздела Технический базис: интервьюер задаёт 2-3 follow-up вопроса про механику, и отсутствие реального опыта становится очевидным в течение нескольких минут.

Кейс трансформации найма

Раздел опирается на стилизованный пример, восстановленный из публично описанных паттернов перестройки воронки в нескольких командах (бар-рейзер модель Stripe, адаптированная из Amazon; публичные посты GitHub Copilot Workspace team про набор на их проект; интервью команды Cursor; пост-мортемы AI-внедрений из Karat 2026). Конкретные числа - типовые, не относятся к одной компании. Цель раздела - показать форму трансформации, не воспроизвести конкретный case.

Стилизованный пример: B2B SaaS, ~250 инженеров, перестройка с осени 2024 по весну 2026. Компания продаёт документообороту enterprise-клиентам в США, выручка $80M ARR, инженеринг распределён по семи продуктовым командам, плюс платформенная команда и SRE. Технический стек - Ruby on Rails, React, Postgres, Sidekiq, AWS. Adoption AI-инструментов начался в Q3 2024, к Q1 2025 примерно 80% инженеров использовали Cursor или Claude Code хотя бы несколько раз в неделю. И тут начались видимые проблемы.

Q1 2025: симптомы. Метрики команды на квартальном review: lead time от тикета в backlog до merged PR вырос с 4 до 6 дней, despite кратного ускорения индивидуального написания кода. Среднее время review одного PR выросло с 2 до 5 часов. Production-инциденты выросли на 25%, при разборе четыре из десяти инцидентов квартала прямо связаны с агент-сгенерированным кодом, который не был внимательно отревьюен. Параллельно VP of Engineering получает отчёт от рекрутинга: 30% оффершенов уходят, отчитываясь «процесс интервью слишком медленный и не видит мою работу». Open positions - 18, заполнили за квартал 4.

Q2 2025: диагноз. Инженерный лид и руководитель рекрутинга совместно проводят два упражнения. Первое - audit последних 20 нанятых: какие из них в top-quartile performance через 6 месяцев, какие в bottom-quartile, что общего. Паттерн обнаруживается: top-quartile - те, кто на интервью спокойно использовал AI-инструменты или явно описывал свой pipeline; bottom-quartile - те, кто на интервью продемонстрировал сильное hand-coding, но в работе не перестроился под агентный workflow. Старая воронка фильтровала по сигналу, который перестал коррелировать с outcome. Второе упражнение - audit последних 40 отказников из финальной стадии: половина из них - сильные AI-native кандидаты, которых отсеяли на whiteboard или take-home, потому что они «недостаточно быстро писали руками».

Q2-Q3 2025: переписывание воронки. Команда собирает working group из четырёх инженеров (representatives от трёх продуктовых команд + платформа), VP of Engineering, head of recruiting и одного external advisor с опытом перестройки найма (см. публичные ресурсы Lenny Rachitsky про AI-native PM hiring). За 8 недель пишут новую рубрику. Ключевые изменения:

• Take-home (4 часа) заменён на «pair-AI session» (90 минут): кандидат садится перед своим экраном, расшаривает его, получает реальный issue из публичного компонента кодовой базы, использует свои привычные инструменты (Cursor, Claude Code, что угодно), задача - дойти до open PR с тестами. Интервьюер наблюдает процесс, не результат.
• Whiteboard-алгоритм заменён на «pipeline walkthrough» (45 минут): кандидат рассказывает реальную задачу, которую недавно делал через агента, с phasing, артефактами, валидацией. Follow-up: «что сломалось», «как ты это поймал», «что бы переделал».
• Системный дизайн (60 минут) сохраняется, но добавляется обязательное условие: кандидат должен явно назвать blast radius предлагаемых решений и где human gate.
• Behavioral interview (45 минут) заменён на «leadership and ambiguity» (45 минут) - вопросы вокруг конфликтов в команде по поводу adoption AI, как кандидат справлялся с неопределённой спецификацией, как отказывался от устаревшего инструмента. Источник вдохновения - ambiguity tolerance frame Charity Majors.
• Bar-raiser добавлен как роль, заимствованная из Amazon-модели через Stripe (см. публичные посты Stripe engineering blog про bar-raiser): инженер из другой команды присутствует на финальной стадии каждого онсайта, имеет право вето, не имеет прямого интереса в найме именно этого кандидата. Bar-raiser - человек, который сам успешно прошёл AI-native трансформацию и тренирован замечать сигналы.

Q3 2025: обучение интервьюеров. Просто переписать рубрику недостаточно. 30 действующих интервьюеров проходят 3-часовой workshop: рамка измерений Augment Code, разбор типичных сильных и слабых ответов, парные mock-интервью с обратной связью. Во время workshop участники видят запись «pair-AI session» с двумя кандидатами - один с сильным pipeline, один с имитацией - и калибруются на видимые сигналы. После workshop каждый интервьюер проводит первые два настоящих интервью в shadow-режиме (наблюдает опытный интервьюер, потом совместно дебрифинг).

Q4 2025: первые результаты. Time-to-hire упал с 8 до 5 недель. Reject rate (отказ кандидата) упал с 30% до 12% - кандидаты явно описывают, что новый процесс ощущается как «соответствующий тому, как реально работают». Open positions заполнены 14 из 18, против 4 за Q1. Качество найма пока рано оценивать (нужно 6 месяцев до первого performance review), но shadow-метрика - оценка bar-raiser-а уверенности в найме - выросла с 6.5 до 8.2 из 10 в среднем.

Q1-Q2 2026: performance review нанятых по новой рубрике. Из 14 нанятых через новую воронку 11 в top половине performance distribution их когорты, против ожидаемых 7. Среди оставшихся трёх двое - product-builder-ы в команды, где не было AI-fluent наставника, ушли в фрустрацию, один сменил команду внутри компании и через два месяца вышел в top-quartile. Lead time на уровне организации упал с 6 до 3.5 дней - частично за счёт нанятых, частично за счёт того, что обучение интервьюеров побочно прокачало старших инженеров на AI-native рубрику. Ratio инцидентов вернулся к pre-AI baseline.

Кто справился, кто застрял. Среди существующих сотрудников трансформация прошла неровно. Senior-ы 35-45 лет с 10+ годами опыта и сильным алгоритмическим background разделились на две группы: половина быстро адаптировалась, увидев экономическую выгоду и сохранив skepticism как инструмент quality control; половина застряла, считая AI-инструменты «костылями», и их influence в команде постепенно угас. Mid-level инженеры адаптировались быстрее, потому что у них меньше эго привязано к ремеслу hand-coding. Junior-ы - быстрее всех, но с риском: они не различают «работающий код» и «работающий и понятный код», агенты усиливают этот gap. Для них компания ввела обязательный mentorship от senior-а на первые шесть месяцев работы.

Что не сработало. Первая попытка обучения через online-курс провалилась - 15% completion rate. Заменили на синхронные workshop с live-практикой. Первая версия рубрики оценивала «количество AI-инструментов в активном использовании» - быстро поняли, что это Goodhart-violation в чистом виде: кандидаты начали указывать в резюме все инструменты подряд. Заменили на «pipeline walkthrough» как поведенческий сигнал, не как self-reported. Bar-raiser в первый месяц жаловались на overhead - один человек присутствовал на 4 финальных интервью в неделю; решили, расширив роль на 6 человек с rotation.

Перестройка interview loop и рубрик

Этот раздел - практическое руководство для технического лида или engineering manager-а, который решил переписать воронку под AI-native фильтр. Структура - последовательность шагов, каждый с конкретными артефактами и типичными точками сопротивления. Время на полную трансформацию - 6-12 недель minimum, плюс обучение интервьюеров.

Шаг 1: написать новую рубрику с конкретными сигналами

Открыть документ hiring-rubric.md в репозитории команды (или Notion, или Confluence - важно, чтобы был один источник правды и version-controlled). Для каждого из шести измерений Augment Code (см. раздел Шесть измерений) написать:

• Описание измерения в одном абзаце: что именно мы пытаемся измерить.
• 3-5 сильных сигналов: конкретные наблюдаемые проявления, не абстракции. Например, для Agent Leverage: «упоминает spec.md или plan.md как артефакт», «называет имена hooks или permissions», «описывает чистую сессию для каждой фазы». Не «понимает agent leverage» (нечто, что нельзя проверить).
• 3-5 слабых сигналов: anti-patterns ответов из раздела Антипаттерны. Например: «"я использую Claude" без конкретики», «привязка к одному инструменту как к идентичности».
• Шкала 1-5: что значит каждый уровень. 1 - явно слабый сигнал; 3 - смешанные сигналы или нейтрально; 5 - явно сильный сигнал. Уровень 4 как «выше ожиданий», 2 как «ниже ожиданий».

Антипаттерн на этом шаге - писать рубрику в одиночку. Соберите working group из 3-5 инженеров, которые сами успешно работают AI-native, и одного external reviewer (друг из другой компании, с тем же типом продукта, с трансформацией пройденной), чтобы избежать blind spots. Готовая рубрика - 4-7 страниц, не 40. Если рубрика не помещается в голову интервьюера, она не используется.

Шаг 2: переписать форматы интервью под рубрику

Каждый формат должен продуцировать данные хотя бы по двум измерениям. Если формат не даёт сигнала ни по одному, его нужно убрать.

Pair-AI session (90 минут) заменяет take-home. Кандидат расшаривает экран, использует свои инструменты, получает реальный issue из публичного фрагмента кодовой базы (или специально подготовленного toy-репозитория, если public exposure не подходит). Задача - дойти до open PR с тестами. Интервьюер не подсказывает, фиксирует наблюдения по рубрике (Agent Leverage, Communication, Ownership). Этот формат сильно зависит от подготовки интервьюера: ему нужно знать issue в деталях, иметь backup-ы на случай технических проблем, уметь не перебивать кандидата.

Pipeline walkthrough (45 минут). Кандидат рассказывает реальный проект, который вёл через агентов: phasing, артефакты, валидация, что сломалось, как поймал. Follow-up углубляющие вопросы: «почему вынес эту фазу в отдельную сессию», «как обнаружил, что агент закommит-ил skip-тест». Сигнал по Agent Leverage, Learning Velocity, Ownership.

System design (60 минут). Сохраняется как формат, но критерий модифицируется: кандидат должен явно назвать blast radius предлагаемых решений, обозначить human gate, обсудить idempotency и reversibility. Сигнал по System Judgment, Product Taste.

Leadership and ambiguity (45 минут) заменяет behavioral. Вопросы вокруг конфликтов adoption, ambiguity tolerance, отказа от устаревших инструментов, history of leverage uplift в команде. Сигнал по Ownership, Communication, Learning Velocity.

Bar-raiser (присутствует на 1-2 формате на финальной стадии). Не отдельный формат, а роль наблюдателя с правом вето. Bar-raiser - инженер из другой команды, прошедший AI-native трансформацию, не имеющий прямого интереса в найме именно этого кандидата (нет open requisition в его команде).

Шаг 3: обучить интервьюеров

Просто разослать рубрику - не сработает. Нужен синхронный workshop 3-4 часа для каждой когорты интервьюеров (10-15 человек на когорту). Структура workshop:

1. Контекст (30 минут). Почему перестраиваем: данные performance review, корреляция со старой воронкой, бизнес-обоснование. Без этого контекста интервьюеры воспринимают новую рубрику как очередной HR-ритуал.
2. Walkthrough рубрики (45 минут). Каждое измерение, сильные/слабые сигналы, шкала 1-5. Q&A с примерами.
3. Калибровка на записях (60 минут). Просмотр 2-3 записей реальных pair-AI session или pipeline walkthrough. После каждой - индивидуальная оценка по рубрике, потом обсуждение в группе. Цель - выровнять интерпретацию шкалы между интервьюерами.
4. Парные mock-интервью (60 минут). Участники в парах: один играет кандидата, второй - интервьюера. Затем смена ролей. После - обратная связь от наблюдающего тренера.
5. Чеклист до выхода в production (15 минут). Каждый интервьюер обязан провести минимум 2 интервью в shadow-режиме (наблюдает опытный интервьюер) перед самостоятельной работой. Дебриф после каждого shadow-интервью.

Без этого обучения новая рубрика быстро деградирует к старой: интервьюеры по привычке оценивают по hand-coding и игнорируют agent leverage. Calibration meetings раз в квартал поддерживают согласованность во времени.

Шаг 4: измерять воронку и итерировать

Метрики, которые нужно отслеживать с первого месяца:

• Pass rate каждой стадии. Если pair-AI session отсеивает 80%, фильтр слишком жёсткий. Если 5%, фильтр не работает.
• Inter-rater reliability. Если двое интервьюеров на одном кандидате дают оценки 5 и 2, рубрика интерпретируется по-разному. Целевой Cohen's kappa - 0.6+.
• Reject rate offer-ов кандидатами. Если кандидаты отказываются после онсайта, что-то в процессе создаёт негативный сигнал. Survey причин обязателен.
• Time-to-hire. Цель - вписаться в 4-6 недель от screening до оффера. Дольше - кандидаты уходят к конкурентам.
• Performance distribution через 6 месяцев. Главная метрика валидности рубрики. Сравнивать когорту, нанятую по новой рубрике, с предыдущей когортой по старой.

Калибровочная встреча раз в квартал: руководители команд и bar-raiser-ы смотрят на performance review нанятых, ищут паттерны - кто справился, кто нет, что общего у каждой группы. Если паттерн «нанимаем правильных, но они уходят» - проблема не в воронке, а в onboarding или в роли. Если «нанимаем неправильных» - правка рубрики или калибровки.

Шаг 5: координация с onboarding и mentorship

AI-native инженер, нанятый по новой рубрике, попадает в команду, где старые сотрудники могут работать по-старому. Без mentorship новый сотрудник либо тащит команду наверх, либо сам опускается до уровня adoption команды (см. раздел про закон Амдала). Поэтому onboarding включает:

• Назначенный mentor - senior-уровень, сам успешно прошёл AI-трансформацию, проводит еженедельные 1:1 в первые 3 месяца. Цель - не контролировать, а быть доступным как ресурс.
• Доступ к команде CLAUDE.md, rules, skills, MCP-серверам с первого дня. Если этих артефактов нет - команда сама не работает AI-native, и наёмник столкнётся с препятствиями.
• Pair-сессия с mentor-ом на реальной задаче в первую неделю. Не «здесь репозиторий, разбирайся», а «давай вместе закроем тикет, я покажу как мы это делаем».
• Calibration check на 30, 60, 90 дне. Manager и mentor совместно с новым сотрудником обсуждают: что работает, что мешает, какие пробелы видны.

Шаг 6: подготовка к расширению AI-fluency существующей команды

Параллельно с переписыванием найма команда должна работать над adoption у существующих сотрудников. Иначе новые сотрудники работают как раньше через 3 месяца. Подходы, которые работают:

• Champions program. 1 inженер на команду, добровольно, у него выделен бюджет 20% времени на эксперименты с инструментами и шаринг находок. Не тренинг, а живой пример. Подробнее в статье «Стратегия внедрения Claude в команде».
• Внутренний brown bag раз в две недели: champion одной команды показывает 30 минут, как закрыл задачу через свой pipeline. Запись доступна.
• Командные CLAUDE.md, rules, skills в репозитории. Когда команда шарит контекст, новый сотрудник за неделю выходит на скорость, не за квартал.
• Метрики прогресса. % инженеров, использующих AI-инструменты регулярно; lead time на уровне команды; время review. Не для KPI, а для observability трансформации.

Без работы над существующей командой воронка найма становится pump в пустое ведро: нанятые AI-native уходят через 6-9 месяцев, потому что в команде они становятся изолированной аномалией.

Типичные анти-паттерны в ответах

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

«Использую AI» без конкретики (harness, модели, процесс). Обычно означает Copilot-уровень автокомплита или ChatGPT в браузере для вопросов. Показатель отсутствия системной работы с агентами. Уточняющий вопрос «какой harness, какую модель, какая структура сессии» сразу раскрывает уровень вовлечённости. Критично потому что в AI-native роли ценность - не факт использования AI, а качество pipeline вокруг него.

«Доверяю Claude» или «доверяю Cursor» без guardrails на нереверсируемые операции. Признак отсутствия опыта с последствиями агентских ошибок на production. LLM ошибается стабильно и непредсказуемо, свойство модели. Инженер без human gate на deploy/delete/push к main работает в режиме ожидания первой катастрофы. После неё обычно приходит понимание, но цена обучения высока. Компании предпочитают нанимать тех, кто уже прошёл этот урок.

Привязка к одному инструменту как к идентичности: «Cursor лучше Claude», «только Aider». Learning velocity под вопросом - через 6 месяцев инструмент сменится, привязка станет помехой. Кандидат, который обсуждает инструменты эмоционально («это говно», «это гениально»), а не функционально («этот harness даёт Y, тот не даёт»), не сможет переключиться без потерь при смене корпоративного стандарта или появления нового лидера рынка.

Измерение продуктивности через output (строки кода, число коммитов). Goodhart-violation в чистом виде: метрика становится целью и теряет смысл как мера. Показатель, что кандидат не знаком с базовыми фреймворками (DORA, SPACE) и не имел опыта работы с командными метриками. В среде, где руководство под давлением отчётности будет выкатывать такие метрики, кандидат не сможет оппонировать и защитить команду от разрушительных KPI.

Смешивание «разработка с AI» и «разработка AI-продуктов». Это разные компетенции: первое - использование LLM для своей разработки, второе - строительство LLM-функциональности в продукт для пользователей. Кандидат, не различающий и не уточняющий какую сторону обсуждает, создаёт путаницу на интервью и с высокой вероятностью создаст её в работе. Интервьюер слышит ответ и не понимает, про что он - про internal tooling или про user-facing feature.

Терминологическая путаница. RAG называют там, где это fine-tuning или prompt injection. MCP описывают как «что-то про MCPS». Agent harness считают синонимом LLM API. Каждое такое смешение показывает, что термин выучен из заголовка поста, а не из работы с концептом. Критично потому что в команде такой инженер будет неверно интерпретировать обсуждения и принимать неправильные архитектурные решения на основе путаницы.

Игнорирование cost и latency в архитектурном обсуждении. В production это первый вопрос после корректности. GPT-5 стоит X центов на 1К токенов, при 1М запросов в месяц это Y долларов. Latency ответа 8 секунд против 2 секунд меняет UX критически. Кандидат, проектирующий AI-систему без упоминания бюджета токенов или latency бюджета, не работал в production с реальным бюджетным давлением. В стартапе это выльется в расход средств выше плана, в крупной корпорации - в отмену инициативы после первого финансового review.

«Агент сам запушит и создаст PR» без упоминания approval gate. Признак отсутствия опыта с реальными последствиями агентских ошибок на нереверсируемых операциях. Автоматический push к main без human review - одна ошибка агента разрушает ветку или удаляет данные других разработчиков. Индустриальный стандарт 2026 - агент готовит PR, человек approve-ит merge. Кандидат без этого понимания либо не работал в production, либо работал в малокритичном окружении (личные проекты, хакатоны), где цена ошибки нулевая.

Антипаттерны со стороны компании - симметричный список, который полезно знать кандидату для оценки зрелости работодателя:

• Тестирование знания инструментов вместо суждения. Вопрос «перечисли все возможности OpenAI Assistants API» проверяет память, не judgment. Сильный фильтр - «когда бы ты выбрал Assistants API, а когда сырой Chat Completions, и почему».
• Игнорирование critical-thinking. Допущение «AI всё сделает, фундамент не нужен». Нанимаются inженеры, которые не могут отдиагностировать ошибку агента, потому что не понимают, что должно происходить.
• No-AI-allowed interview process. «У нас на интервью без Cursor». Селектирует против лучших практиков, которые так больше не работают. Кандидат, дисквалифицированный таким правилом - не худший, а зачастую лучший.
• Whiteboard coding без AI при production = всегда с AI. Mismatch формата. Что измеряем, того и не получаем.
• Over-indexing на резюме (годы × количество библиотек). Резюме - плохой proxy для AI-leverage. Лучше - последние 1-2 проекта с pipeline walkthrough.
• Найм «AI-специалиста» когда нужен generalist с AI-fluency. Compounding mistake: ML-engineer не делает product engineering, и наоборот.
• Продвижение по «AI buzzword density» в self-review. Goodhart-violation на уровне promotion-процесса. Инженеры начинают вписывать «использую RAG, agent orchestration, MCP» во все свои self-review независимо от реального применения.
• Принятие решения только по count AI-инструментов в резюме. Кандидат указывает 12 инструментов - заведомо лучше того, кто указал 3? Нет: указал столько, скольких касался поверхностно. Глубина одного pipeline ценнее каталога.

Почему единичный найм не решает задачу

Закон Амдала: ускорение части процесса в 10 раз при её доле 20% общего времени даёт суммарное ускорение 1.22x. Формально:

S(total) = 1 / ((1 - p) + p/s)

где p - доля времени, которую ускоряем
    s - коэффициент ускорения этой части

При p = 0.2, s = 10: S = 1 / (0.8 + 0.02) = 1.22

Применение к найму AI-native инженера. Если кандидат ускоряет написание кода в 10 раз, но встраивается в организацию, где написание кода - только 20% общего time-to-market (остальное - PRD-цикл, review, QA, deploy, coordination), прирост общего time-to-market около 1.2x. Большую часть времени инженер ждёт review и уточнения спецификации. Инвестиция в найм не возвращается пропорционально ожиданиям.

Симметричная сторона AI-native интервью - вопросы к компании, проверяющие готовность процесса. Без этих вопросов кандидат рискует попасть в организацию, где его навыки не применимы. Индикаторы зрелости процесса:

• Lead time от задачи в backlog до production. В днях или неделях. Две недели - нормально для зрелой продуктовой организации, месяц - уже тревожно, квартал - ничего не спасёт.
• Median time PR до merge. 1-2 дня - здоровая команда. Неделя - review-процесс сломан и агент будет генерировать больше чем команда успевает ревьюить.
• Стандарт для AI-driven задач между PRD и кодом. Есть ли в команде spec.md, plan.md как стандартные артефакты? Если нет - каждый инженер изобретает свой процесс, кросс-командная совместимость нулевая.
• Общие CLAUDE.md, rules, memory команды или индивидуальные конфигурации. Общие - команда шарит контекст, новые инженеры быстро онбордятся. Индивидуальные - каждый катит своё, знание не передаётся.
• Tool allowlists, deny-rules, permission-модель для production операций. Формализованы или каждый сам решает? Формализация - признак зрелости и защита от катастроф.
• Ответственный за cost и latency агентов. Кто-то один смотрит за тем, чтобы затраты на API не улетели в Марс? Есть ли бюджеты и мониторинг использования токенов по командам?

Ответы «пока не думали», «каждый решает сам», «Claude разберётся» указывают на отсутствие инфраструктуры. AI-native инженер в такой организации упирается в review и coordination, прирост остаётся на уровне 1.2x, через 3-6 месяцев начинается фрустрация и увольнение. Зрелость процесса важнее формального статуса компании или зарплаты - нужна готовность процесса использовать нанимаемые навыки.

Процессная трансформация разобрана в статье «SDLC для AI-агентов», модель зрелости внедрения - в статье «Стратегия внедрения Claude в команде». Подготовка кодовой базы к агентной разработке - в статье «Лучшие практики работы с AI-агентами».

Источники

Рамки оценки и рынок

• Augment Code: How we hire AI-native engineers now - 6-dimension framework.
• Karat: 2026 Engineering Interview Trends - 34% productivity, 71% harder to assess, 73% strong = 3x comp.
• DORA State of DevOps - метрики delivery, данные по AI adoption.
• Anthropic Careers - публично описанный фильтр найма «Constitutional AI applicants».
• Vercel Engineering Blog - регулярные посты про AI taste как критерий найма.
• Lenny's Newsletter - frame «AI-native PM», переносимый на инженерные роли.
• charity.wtf - блог Charity Majors - ambiguity tolerance как критерий найма.
• Will Larson, «An Elegant Puzzle» (Stripe Press, 2019) - durability и leverage в инженерных ролях.
• Camille Fournier, «The Manager's Path» (O'Reilly, 2017) - staff-уровень как leverage всей команды.
• Brendan Burns, «Designing Distributed Systems» (O'Reilly, 2018) - паттерны контрактов между компонентами, переносимые на multi-agent системы.

Context и agents

• Anthropic: Effective Context Engineering for AI Agents.
• Chroma Research: Context Rot.
• Model Context Protocol - спецификация и SDK.
• Anthropic: Building Effective Agents - паттерны оркестрации.
• «Attention Is All You Need» (Vaswani et al., 2017).
• «Lost in the Middle» (Liu et al., 2023).

RAG и semantic search

• RAGAS framework docs - метрики оценки RAG.
• RAGAS paper (Es et al., 2023).
• Original RAG paper (Lewis et al., 2020).
• Pinecone: Hybrid search intro.
• HNSW paper (Malkov & Yashunin, 2016).
• HyDE paper (Gao et al., 2022).
• Anthropic: Contextual Retrieval.
• Cohere Rerank.

Подготовка к интервью

• The Interview Guys: Context Engineer interview questions.
• Hackajob: AI engineer interview questions 2026.

Смежные статьи

• Context Engineering - управление токенами, память агентов, retrieval.
• SDLC для AI-агентов - процессная трансформация.
• Инфраструктура контекста для AI-агентов - трёхуровневая архитектура памяти.
• Лучшие практики работы с AI-агентами - подготовка кодовой базы.
• Стратегия внедрения Claude в команде - модель зрелости адаптации.
• Spec Kit - фреймворк spec-driven development.
• Как устроен Claude Code - внутренности harness.
• Как работают плагины Claude Code - hooks, agents, MCP.
• Агентское программирование: текущее состояние - карта экосистемы.
• AI-источники - каталог 40+ ресурсов.
• Можно ли измерять продуктивность - DORA, SPACE, закон Гудхарта.
• Idempotency Keys - паттерн для биллинга и webhooks.