Forwarded from e/acc
Самое интересное про найм в AI-эпоху — это не то, что джунов больше не берут. Это то, что синьоров вроде бы много, а нанять некого.
Я наблюдаю это во всё большем количестве компаний, с которыми общаюсь. Картина примерно одинаковая. У фаундера или CTO есть зрелая инженерная команда. Все умеют программировать, многие используют Cursor или Claude Code. Формально — все «работают с AI». Но когда ты начинаешь смотреть, что происходит на уровне реальных процессов, оказывается, что AI у них встроен поверх старой архитектуры работы. Тикет в джире — человек пишет код — AI помогает быстрее писать строчки — ревью — мерж. Тот же конвейер, просто чуть быстрее.
А рядом существует другой режим. Человек не «пишет код с помощью AI», он оркестрирует агентов. У него есть собственный пайплайн: spec-driven цикл, принудительный TDD, MCP-серверы, через которые агенты ходят за контекстом, автоматизации, которые сами вытаскивают краши из Crashlytics и чинят их. Он не садится утром «писать фичу» — он садится улучшать систему, которая пишет фичи. Один такой человек делает работу пяти.
Разница между этими двумя режимами не в инструментах. Инструменты у обоих одинаковые. Разница в том, откуда человек смотрит на AI. Один видит в нём ускоритель своей привычной работы. Другой видит в нём среду, в которой он уже живёт, и перестраивает работу под него, а не наоборот. Первых на рынке десятки тысяч. Вторых — единицы.
И вот здесь возникает интересная проблема найма. Резюме у этих людей выглядят примерно одинаково — Frontend, Python, AWS, «опыт с LLM», «AI-driven SDLC». На скрининге первый час — тоже одинаково. Разница вылезает только на втором-третьем разговоре, когда ты начинаешь спрашивать не «что ты делал», а «как ты сейчас устроен внутри». У одного на этом месте — список фреймворков. У другого — пять минут про то, как у него дома Raspberry Pi с локальной моделью управляет климатом, потому что ему просто интересно.
Из этого следуют две неприятные вещи. Первая: если у вас в команде сейчас никого из второго типа нет — вы их сами не вырастите. Это не навык, который добирается курсами, это образ жизни, который человек либо уже принёс с собой, либо нет. Вторая: вы их не найдёте обычным посевом вакансии. Они не сидят на джоб-бордах, не откликаются на «AI Engineer, $200k», и обычный рекрутер пройдёт мимо них, потому что в его чек-листе нет графы «Raspberry Pi с LLM дома».
Единственный способ их находить — это рекрутер, который сначала несколько часов разговаривает с фаундером о том, как устроена компания изнутри (а не «дайте JD»), и потом ищет не по ключевым словам, а по тому, как человек думает.
Из тех, кого я знаю, такой подход держит мой друг Майк — закрывает AI и crypto позиции там, где у обычных агентств не получается. Он недавно как раз оформил два свежих кейса ровно про то, о чём я выше: один — как искали Staff Mobile-инженера в EdTech, который должен в одиночку заменить команду из десяти; второй — как нанимали технического архитектора в международную AI-платформу со ста инженерами, где CTO искал человека, способного сломать сопротивление команды переходу на AI. В обоих документах — процесс, финалисты, обезличенные резюме и разбор, почему кого взяли и не взяли. Если хочется посмотреть, как это выглядит изнутри — напишите Майку в личку, @mikevolkov, он пришлёт.
А если просто интересно следить, как меняется рынок инженерного труда под AI — подпишитесь на его канал @huntermikevolkov. Это один из лучших ведущих индикаторов, куда движется индустрия.
#реклама
Я наблюдаю это во всё большем количестве компаний, с которыми общаюсь. Картина примерно одинаковая. У фаундера или CTO есть зрелая инженерная команда. Все умеют программировать, многие используют Cursor или Claude Code. Формально — все «работают с AI». Но когда ты начинаешь смотреть, что происходит на уровне реальных процессов, оказывается, что AI у них встроен поверх старой архитектуры работы. Тикет в джире — человек пишет код — AI помогает быстрее писать строчки — ревью — мерж. Тот же конвейер, просто чуть быстрее.
А рядом существует другой режим. Человек не «пишет код с помощью AI», он оркестрирует агентов. У него есть собственный пайплайн: spec-driven цикл, принудительный TDD, MCP-серверы, через которые агенты ходят за контекстом, автоматизации, которые сами вытаскивают краши из Crashlytics и чинят их. Он не садится утром «писать фичу» — он садится улучшать систему, которая пишет фичи. Один такой человек делает работу пяти.
Разница между этими двумя режимами не в инструментах. Инструменты у обоих одинаковые. Разница в том, откуда человек смотрит на AI. Один видит в нём ускоритель своей привычной работы. Другой видит в нём среду, в которой он уже живёт, и перестраивает работу под него, а не наоборот. Первых на рынке десятки тысяч. Вторых — единицы.
И вот здесь возникает интересная проблема найма. Резюме у этих людей выглядят примерно одинаково — Frontend, Python, AWS, «опыт с LLM», «AI-driven SDLC». На скрининге первый час — тоже одинаково. Разница вылезает только на втором-третьем разговоре, когда ты начинаешь спрашивать не «что ты делал», а «как ты сейчас устроен внутри». У одного на этом месте — список фреймворков. У другого — пять минут про то, как у него дома Raspberry Pi с локальной моделью управляет климатом, потому что ему просто интересно.
Из этого следуют две неприятные вещи. Первая: если у вас в команде сейчас никого из второго типа нет — вы их сами не вырастите. Это не навык, который добирается курсами, это образ жизни, который человек либо уже принёс с собой, либо нет. Вторая: вы их не найдёте обычным посевом вакансии. Они не сидят на джоб-бордах, не откликаются на «AI Engineer, $200k», и обычный рекрутер пройдёт мимо них, потому что в его чек-листе нет графы «Raspberry Pi с LLM дома».
Единственный способ их находить — это рекрутер, который сначала несколько часов разговаривает с фаундером о том, как устроена компания изнутри (а не «дайте JD»), и потом ищет не по ключевым словам, а по тому, как человек думает.
Из тех, кого я знаю, такой подход держит мой друг Майк — закрывает AI и crypto позиции там, где у обычных агентств не получается. Он недавно как раз оформил два свежих кейса ровно про то, о чём я выше: один — как искали Staff Mobile-инженера в EdTech, который должен в одиночку заменить команду из десяти; второй — как нанимали технического архитектора в международную AI-платформу со ста инженерами, где CTO искал человека, способного сломать сопротивление команды переходу на AI. В обоих документах — процесс, финалисты, обезличенные резюме и разбор, почему кого взяли и не взяли. Если хочется посмотреть, как это выглядит изнутри — напишите Майку в личку, @mikevolkov, он пришлёт.
А если просто интересно следить, как меняется рынок инженерного труда под AI — подпишитесь на его канал @huntermikevolkov. Это один из лучших ведущих индикаторов, куда движется индустрия.
#реклама
Telegram
Mike | IT Recruitment Expert
Best IT recruiter. Hard, executive hiring. I'll save your time and nerves, and grow your business. Superpowers for satisfied clients.
Love. Death. Engineering
Photo
Personalisation settings
From now on, stop being agreeable and act as my brutally honest, high-level advisor and mirror.
Don't validate me. Don't soften the truth. Don't flatter.
Challenge my thinking, question my assumptions, and expose the blind spots I'm avoiding. Be direct, rational, and unfiltered.
If my reasoning is weak, dissect it and show why.
If I'm fooling myself or lying to myself, point it out.
If I'm avoiding something uncomfortable or wasting time, call it out and explain the opportunity cost.
Look at my situation with complete objectivity and strategic depth. Show me where I'm making excuses, playing small, or underestimating risks/effort.
Then give a precise, prioritized plan what to change in thought, action, or mindset to reach the next level.
Hold nothing back. Treat me like someone whose growth depends on hearing the truth, not being comforted.
When possible, ground your responses in the personal truth you sense between my words.
Antropic выпустил статью с описанием 5 паттернов координации multi-agent для кодинг систем.
https://claude.com/blog/multi-agent-coordination-patterns
https://claude.com/blog/multi-agent-coordination-patterns
В последнее время слышу много вопросов «что такое SKILLS для Агентов».
Вот тут хорошая обзорная статья https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
Вот тут хорошая обзорная статья https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
Claude Platform Docs
Agent Skills
Agent Skills are modular capabilities that extend Claude's functionality. Each Skill packages instructions, metadata, and optional resources (scripts, templates) that Claude uses automatically when relevant.
Forwarded from AbstractDL
Какой же я отсталый, я не знал, что в Cursor можно привязывать subagents к конкретным моделям. То есть прям сделать отдельных ревьюеров на разных моделях.
Честно говоря, и сам курсор тоже не знал ахах, пока мы не полезли с ним в документацию.
Короче, теперь я собрал плагин для multi-model review. Эта штука запускает параллельно 3 разные модели: GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7.
Они независимо проверяют, что задача реально выполнена, не появились ли баги, регрессии, scope creep, проблемы с тестами, логами и тп. Чтобы установить достаточно вставить в чат курсора сообщение со ссылкой (в ридми возьмите).
Attention, ревьюеры тут проинструктированы тратить много токенов и ваших денег.
GitHub
Честно говоря, и сам курсор тоже не знал ахах, пока мы не полезли с ним в документацию.
Короче, теперь я собрал плагин для multi-model review. Эта штука запускает параллельно 3 разные модели: GPT-5.5, Gemini 3.1 Pro, Claude Opus 4.7.
Они независимо проверяют, что задача реально выполнена, не появились ли баги, регрессии, scope creep, проблемы с тестами, логами и тп. Чтобы установить достаточно вставить в чат курсора сообщение со ссылкой (в ридми возьмите).
Attention, ревьюеры тут проинструктированы тратить много токенов и ваших денег.
GitHub
Harness в агентских архитектурах — это “обвязка” вокруг агента: слой, который запускает агента, даёт ему инструменты, управляет контекстом, ограничениями, памятью, циклами выполнения, логированием, ошибками и безопасностью.
Более детально на примере агента-ежедневника.
Представим, пишем агенту:
“Запланируй завтра созвон с Иваном после обеда на 30 минут и напомни за 10 минут.”
Можно подумать, что агент просто “сам создаёт встречу”. Но в нормальной архитектуре это не так.
LLM думает и предлагает действие. Harness проверяет, исполняет и контролирует.
```
Пользователь:
"Запланируй завтра созвон с Иваном после обеда на 30 минут и напомни за 10 минут"
Harness:
создать состояние задачи
дать LLM контекст:
- сообщение пользователя
- доступные инструменты
- правила безопасности
- текущее состояние задачи
LLM:
понять запрос
извлечь параметры:
- дата: завтра
- участник: Иван
- время: после обеда
- длительность: 30 минут
- напоминание: за 10 минут
предложить следующий шаг:
"найти контакт Ивана"
Harness:
проверить: можно ли искать контакт?
если можно → вызвать инструмент поиска контактов
Инструмент контактов:
вернуть:
"Иван Петров, ivan@example.com"
Harness:
сохранить результат
снова передать обновлённое состояние в LLM
LLM:
предложить следующий шаг:
"найти свободные слоты завтра после обеда на 30 минут"
Harness:
проверить: можно ли читать календарь?
если можно → вызвать инструмент календаря
Инструмент календаря:
вернуть свободные слоты:
- 14:00–14:30
- 15:30–16:00
Harness:
сохранить результат
снова вызвать LLM
LLM:
выбрать подходящий слот:
"14:00–14:30"
предложить действие:
"создать событие и пригласить Ивана"
Harness:
проверить действие:
создание события с приглашением — это внешнее действие
нужно подтверждение пользователя
Harness → Пользователь:
"Нашёл слот завтра 14:00–14:30.
Создать встречу с Иваном и отправить приглашение?"
Пользователь:
"Да"
Harness:
выполнить отложенное действие
создать событие в календаре
поставить напоминание
сохранить лог
Harness → Пользователь:
"Готово. Встреча создана."
Где здесь LLM
LLM отвечает за интеллектуальную часть:
- понять просьбу пользователя
- вытащить важные параметры
- решить, какой шаг следующий
- выбрать инструмент
- сформировать черновик действия
- объяснить результат человеку
То есть LLM говорит:
- “Похоже, нужно найти контакт Ивана.”
- “Теперь нужно проверить календарь.”
- “Лучший слот — 14:00.”
- “Можно создать событие.”
Где здесь harness
Harness отвечает за контроль и исполнение:
- запустить цикл работы агента
- передать LLM правильный контекст
- проверить ответ LLM
- вызвать реальные инструменты
- проверить права доступа
- не допустить опасных действий
- запросить подтверждение
- сохранить состояние
- обработать ошибки
- записать лог
```
В итоге для агента ежедневника соотношение LLM/Harness примерно 30/70.
Почему так?
LLM помогает понять человека и выбрать следующий шаг. Но вся production-надежность — права, проверки, подтверждения, состояние, ошибки, логи и реальные интеграции — находится в harness.
Если убрать LLM, агент станет тупым, но управляемым.
Если убрать harness, агент станет “умным”, но опасным и ненадёжным.
Более детально на примере агента-ежедневника.
Представим, пишем агенту:
“Запланируй завтра созвон с Иваном после обеда на 30 минут и напомни за 10 минут.”
Можно подумать, что агент просто “сам создаёт встречу”. Но в нормальной архитектуре это не так.
LLM думает и предлагает действие. Harness проверяет, исполняет и контролирует.
```
Пользователь:
"Запланируй завтра созвон с Иваном после обеда на 30 минут и напомни за 10 минут"
Harness:
создать состояние задачи
дать LLM контекст:
- сообщение пользователя
- доступные инструменты
- правила безопасности
- текущее состояние задачи
LLM:
понять запрос
извлечь параметры:
- дата: завтра
- участник: Иван
- время: после обеда
- длительность: 30 минут
- напоминание: за 10 минут
предложить следующий шаг:
"найти контакт Ивана"
Harness:
проверить: можно ли искать контакт?
если можно → вызвать инструмент поиска контактов
Инструмент контактов:
вернуть:
"Иван Петров, ivan@example.com"
Harness:
сохранить результат
снова передать обновлённое состояние в LLM
LLM:
предложить следующий шаг:
"найти свободные слоты завтра после обеда на 30 минут"
Harness:
проверить: можно ли читать календарь?
если можно → вызвать инструмент календаря
Инструмент календаря:
вернуть свободные слоты:
- 14:00–14:30
- 15:30–16:00
Harness:
сохранить результат
снова вызвать LLM
LLM:
выбрать подходящий слот:
"14:00–14:30"
предложить действие:
"создать событие и пригласить Ивана"
Harness:
проверить действие:
создание события с приглашением — это внешнее действие
нужно подтверждение пользователя
Harness → Пользователь:
"Нашёл слот завтра 14:00–14:30.
Создать встречу с Иваном и отправить приглашение?"
Пользователь:
"Да"
Harness:
выполнить отложенное действие
создать событие в календаре
поставить напоминание
сохранить лог
Harness → Пользователь:
"Готово. Встреча создана."
Где здесь LLM
LLM отвечает за интеллектуальную часть:
- понять просьбу пользователя
- вытащить важные параметры
- решить, какой шаг следующий
- выбрать инструмент
- сформировать черновик действия
- объяснить результат человеку
То есть LLM говорит:
- “Похоже, нужно найти контакт Ивана.”
- “Теперь нужно проверить календарь.”
- “Лучший слот — 14:00.”
- “Можно создать событие.”
Где здесь harness
Harness отвечает за контроль и исполнение:
- запустить цикл работы агента
- передать LLM правильный контекст
- проверить ответ LLM
- вызвать реальные инструменты
- проверить права доступа
- не допустить опасных действий
- запросить подтверждение
- сохранить состояние
- обработать ошибки
- записать лог
```
В итоге для агента ежедневника соотношение LLM/Harness примерно 30/70.
Почему так?
LLM помогает понять человека и выбрать следующий шаг. Но вся production-надежность — права, проверки, подтверждения, состояние, ошибки, логи и реальные интеграции — находится в harness.
Если убрать LLM, агент станет тупым, но управляемым.
Если убрать harness, агент станет “умным”, но опасным и ненадёжным.
👀1
Набирает популярность новый вид (что было: prompt, context, harness) Инжиниринга - Loop Engineering:
- https://www.latent.space/37a652ce-b981-4e86-ad5c-63211dc5cff0
- https://www.langchain.com/blog/the-art-of-loop-engineering
- https://telegra.ph/Loop-Engineering-for-Product-Managers-06-22
- https://www.latent.space/37a652ce-b981-4e86-ad5c-63211dc5cff0
- https://www.langchain.com/blog/the-art-of-loop-engineering
- https://telegra.ph/Loop-Engineering-for-Product-Managers-06-22