AI-native инженер

Ожидания рынка и технический базис

17 апреля 2026

В 2026 рынок разработки перестраивается вокруг AI-агентов. Вакансии с титулами AI-native product engineer, AI-first engineer, founding engineer фильтруют не по языку и не по годам опыта, а по способности оркестрировать агентов end-to-end, управлять контекстом и валидировать результат. Статья разбирает как устроены агенты изнутри (inference loop, context window, attention cache, tool use, semantic search, RAG, multi-agent, vendor-agnostic архитектуры), какие сценарии встречаются на интервью и какие концепты требуется уметь объяснить.

Что изменилось в ожиданиях Шесть измерений оценки Технический базис Inference loop: LLM как stateless функция Agent harness: state machine поверх LLM Контекстное окно и его экономика Attention механика и кэш Иерархия источников контекста Tiers памяти Tool use механика и MCP Semantic search изнутри RAG end-to-end и его оценка Token optimization Multi-agent архитектуры Параллельные сессии Vendor agnosticism Сценарии интервью Три профиля кандидатов на рынке Типичные анти-паттерны в ответах Почему единичный найм не решает задачу Источники

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

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». Сигнал - кандидат спонтанно оперирует такой парой (проблема + метрика), не дожидаясь уточняющих вопросов.

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

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

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

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

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

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

Дополнительно: оригинальная статья Augment Code про каждое измерение с примерами вопросов. Karat 2026 Engineering Interview Trends - данные опроса 1500 лидеров.

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

Концепты ниже лежат в основе работы агентов. На 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 природы:

Дополнительно: «Attention Is All You Need» (Vaswani et al., 2017) - исходная статья про трансформер. The Illustrated Transformer - визуальное объяснение от Jay Alammar. OpenAI Tokenizer - интерактивный инструмент для понимания как текст разбивается на токены.

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 добавляет целый слой сервисов:

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

Дополнительно: Anthropic Tool Use Overview - спецификация Messages API с tools. «Как устроен Claude Code» - разбор слоёв внутри одного из крупных harness-ов. «Как работают плагины Claude Code» - механика плагинов, hooks, MCP.

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

Контекстное окно - максимальная длина входа плюс выхода в токенах за один вызов. У современных моделей 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 классифицируют четыре режима отказа длинного контекста:

Вывод: максимизация окна - антипаттерн. Задача context engineering - минимальный набор высокосигнальных токенов, максимизирующий вероятность нужного результата.
Дополнительно: Chroma Research: Context Rot - полный отчёт с бенчмарками. Anthropic: Effective Context Engineering - официальный гайд с описанием режимов отказа. «Lost in the Middle» (Liu et al., 2023) - исследование про позиционный bias. «Context Engineering» - расширенный разбор в блоге.

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

Self-attention в трансформере для каждого токена вычисляет три вектора: Query (что ищу), Key (чем могу быть полезен), Value (что несу). Для токена i attention-вес к токену j - это нормализованное скалярное произведение Qi · Kj. Результат attention для токена i - взвешенная сумма Vj по всем 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:

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

Дополнительно: Anthropic: Prompt Caching - официальная документация API и ценообразования. The Illustrated GPT-2 - визуальное объяснение KV cache и attention. «Lost in the Middle» - бенчмарки позиционной точности.

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

При каждом 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.

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

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

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

Дополнительно: Claude Code Memory docs - официальная документация по иерархии CLAUDE.md. «Как устроен Claude Code» - внутренности сборки промпта.

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) для того, что может понадобиться когда-нибудь.

Дополнительно: «Инфраструктура контекста для AI-агентов» - трёхуровневая архитектура с примером 108К строк production-кода. MemGPT paper - академический взгляд на иерархию памяти. Mem0 - open-source memory layer для агентов.

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 - кросс-вендорность. 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.

Дополнительно: Model Context Protocol - спецификация и SDK. Anthropic Tool Use Overview - механика function calling. Официальный каталог MCP-серверов.

Семантический поиск - фундамент 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) жертвует небольшой точностью за большое ускорение:

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

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

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 запросов.

«Закинул документы в vector DB и делаю поиск» и «production RAG с chunking, query transformation, hybrid search и reranking» - разные уровни работы. Первое - демо. Второе - инженерная работа с несколькими итерациями evaluation.
Дополнительно: HNSW paper (Malkov & Yashunin, 2016). Anthropic: Contextual Retrieval - как улучшить chunking через LLM-добавление контекста. Pinecone: Hybrid search. HyDE paper (Gao et al., 2022). Cohere Rerank - документация и блог про reranking.

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 не нужен. Вопрос экономии и архитектурной простоты:

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

Дополнительно: RAGAS framework docs - метрики с формулами и примерами. RAGAS paper (Es et al., 2023). LlamaIndex Evaluation - практический guide. Original RAG paper (Lewis et al., 2020).

Token optimization

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

Дополнительно: Anthropic: Skills - progressive disclosure в Claude Code. LLMLingua paper (Jiang et al., 2023). «Context Engineering» - сквозной разбор техник в блоге.

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. Способ передачи состояния между агентами:

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. Это снимает с человека рутинное обновление промптов под новые практики.

Дополнительно: Anthropic: Building Effective Agents - паттерны оркестрации с примерами. LangGraph docs - state-based orchestration. CrewAI - role-based multi-agent framework. Anthropic: Multi-agent research system - разбор реальной production-системы.

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

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:

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

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

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

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

Дополнительно: Tmuxinator - документация и примеры конфигов. Git worktree docs. Tmux cheat sheet.

Vendor agnosticism

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

Практика 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% бюджета при том же качестве итогов. Инструменты роутинга:

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

Дополнительно: LiteLLM docs. Vercel AI SDK. OpenRouter docs. «Агентское программирование: текущее состояние» - карта экосистемы инструментов.

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

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

Pipeline walkthrough

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

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

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

Почему так. На маленькой задаче «дал 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), не только структурное «вот модуль».

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

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

Feedback loop

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

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

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

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

Метрики

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

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

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

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

Validation strategy

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

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

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

Почему так. Ошибки агента - инженерная реальность, а не баг. Проектирование процесса сводится к тому, чтобы ошибки не приводили к непоправимому ущербу. «Доверяю полностью» - отсутствие этой ментальной модели, признак отсутствия 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 инициатива превращается в ритуал с имитацией использования.

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).

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, или из опыта управления большими командами (ролевая структура агентов - отражение ролевой структуры команд). Видит агентов как узлы distributed system со своими контрактами, очередями, retry-логикой. Обсуждает не «я использую Claude», а «я спроектировал workflow с пятью ролями и вот контракты между ними». Результат инвестиций - система, в которой замена любого компонента (вендор модели, harness, конкретная роль) не требует переписывания всего.

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

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

Сигналы, которые в большинстве 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, либо работал в малокритичном окружении (личные проекты, хакатоны), где цена ошибки нулевая.

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

Закон Амдала: ускорение части процесса в 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 интервью - вопросы к компании, проверяющие готовность процесса. Без этих вопросов кандидат рискует попасть в организацию, где его навыки не применимы. Индикаторы зрелости процесса:

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

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

Источники

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

Context и agents

RAG и semantic search

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

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