Кактус | ИИ для команд и бизнеса
1.51K subscribers
99 photos
1 video
1 file
150 links
Помогаем компаниям повышать эффективность процессов с помощью ИИ

Канал про ИИ инструменты,
кейсы внедрения, ошибки и находки команды.

Присоединяйтесь, чтобы внедрять инновации первыми!

🌵 Сайт: kkts.ai
✉️ Внедрить ИИ в компанию: @k_scrumtrek
Download Telegram
У вас получается извлекать пользу из чужих Agent Skills без их правок У меня нет, особенно когда речь идет НЕ о кодинге.

Скиллы для локальных агентов, скачанные через npx skills add ..., помогают за минуты научить вашего ИИ-агента делать нечто сложное — от скачивания из youtube до создания презентаций. Но они не знают ваших привычек, не подстраиваются под меняющиеся задачи и быстро устаревают.

➡️ Значит, скиллы нужно регулярно адаптировать — обновлять под свой контекст. Но это долго и муторно...
➡️ Опытный агентовод не будет сам править SKILL.md, он попросит самого агента улучшить свои скиллы. Но исследования показывают: бесконтрольное обновление скиллов агентом чаще снижает их качество, чем повышает.
➡️ Чтобы агент реально улучшал скиллы, а не портил их, рано или поздно придется освоить meta-skills.

Мета-скиллы нужны для создания, оценки и улучшения других скиллов под вашим контролем. Три таких мета-скилла я упоминал в недавнем посте.

---
📌 Статья: Как заставить агента улучшаться (а не ухудшаться!) с каждой задачей

В статье — подробнее про мета-скиллы и про то, зачем нам вообще становиться «владельцами» скиллов наших агентов. Главное, имхо, — даже не качество результатов ИИ, а наше собственное развитие.

#skills #люди #статья
Please open Telegram to view this post
VIEW IN TELEGRAM
👍52🔥21😁1
Почему мы не отказываем клиентам с плохими ИИ идеями ) - два поворота

Прочитал тут у коллеги, что они отказывают клиентам, которые приходят с плохой идеей, которая не принесет им денег. А мы таких любим )) Клиент всегда приходит к нам с готовой идеей. Чаще всего это что-то вроде «хотим ассистента, который отвечает на вопросы по нашей базе знаний».

ИИдея классная, и мы так и говорим! Она живая, человек придумал её сам, она в сфере его интересов и его драйвит. С этим уже можно работать.

Дальше первый поворот. Ищем в каком сквозном бизнес-процессе живёт этот ассистент? Кто им пользуется? Что с данными? Разворачиваем идею в сторону процесса целиком.

Зачем это нужно. Задачка в стиле «прикрутите агента к процессу» обещает экономию трудозатрат. Но увольнять никого нельзя — и никто не будет: что, менеджер станет сокращать своих людей, чтобы из директора превратиться в тимлида? Нет конечно )) Ценность руководителя в организации меряется размером команды, сорри. Сэкономленные часы останутся строчкой в презентации, в Excel у финансистов они не появятся. А вот у сквозного процесса есть бизнес-метрики — скорость, конверсия, выигранные сделки. На них можно повлиять и показать реальную отдачу.

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

В итоге иногда получается совсем другая идея. Зато по ней легко посчитать ROI и защитить бюджет перед финансистами!

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

Поэтому мы и не отказываем клиентам с «плохими» идеями. В идее главное то, что она вообще есть: в ней энергия клиента и его знание своей предметки. Плохая идея — это просто хорошая, которую надо два раза провернуть ))
👍126
Написал пост про Цифровых Сотрудников и почему это ужасная идея! (не делайте так) Очень часто приходится это слышать, наряду с идеей "мы хотим повысить продуктивность" которая тоже оч плохо.

🚩 Почему «цифровой сотрудник» — дорогой способ ничего не изменить
👍8👌1
Scrum с ИИ-агентом не работает по очевидным причинам, а ручной менеджмент агента — съедает то время, которое ИИ должен был освободить.

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

———
👉Делюсь с вами своим процессом и своими практиками в новой статье. Когда строил этот процесс, мне показалось полезно отталкиваться от трёх принципов Скрама, переосмысленных для работы один на один с агентом:

🔹 Прозрачность включает такие практики: агент сохраняет краткий бриф каждой сессии (что сделано и какие решения он принял), а ваши решения фиксируются в Q&A-файлах (где агент задает вопросы, а вы отвечаете).

🔹 Инспекция. Перед выполнением задачи агент формулирует критерии успеха, а вы их проверяете. В конце задачи (сессии) — агент синтезирует выводы из обнаруженных проблем, а вы делаете их ревью.

🔹 Адаптация — в двойном цикле. Короткий цикл (микроспринт): одна задача → ревью → черновые решения по улучшению. Длинный цикл с ретроспективой: накопленные наблюдения → паттерны → обновление скиллов и процесса.

Замеченные проблемы должны сначала превращаться в паттерны — только тогда само-улучшение агента работает.

———
🔗 Статья: "Scrum" для ИИ-агента: как управлять тем, кто сам себя улучшает

Внутри — конкретные практики и скиллы, реализующие этот мой «процессный фреймворк» (для не-кодерской работы), а также сравнение с методикой Oper8 для компаний, где тоже двойной цикл с похожим смыслом.

#агенты #статья
Please open Telegram to view this post
VIEW IN TELEGRAM
5🔥3
23 июня в офисе ScrumTrek — митап, где мы честно поговорим об ИИ в разработке. Живые кейсы, дискуссия и неудобные вопросы 😉

Сначала два доклада, которые перевернут ваш подход:

📌 Не чините промпт — ребята из «Айсорс» покажут на трёх реальных провалах, почему важно не количество задач, которые удалось отдать модели, а правильный баланс между «считаем сами» и «спрашиваем модель».

📌 Жизнь без спринтов — основатель ScrumTrek Асхат Уразбаев расскажет, как выглядит процесс, когда задача доходит до прода за день, а Scrum-of-Scrums остаётся в прошлом.

☝🏻После докладов — общая дискуссия о системных проблемах внедрения ИИ в SDLC. Обсудим, где ИИ лишь создаёт новые узкие места, разберём сложности с качеством, архитектурой, ролями, безопасностью и управлением изменениями. И другие ваши боли.

Кому точно стоит идти: тимлидам, руководителям стримов и владельцам продуктов. Тем, кто чувствует, что старые методы не успевают за новой скоростью.

🗓 Когда: вторник 23 июня с 19 часов
📍 Где: новый офис ScrumTrek по адресу - Москва, 3-й Красносельский пер., д.19с1

👉🏼РЕГИСТРАЦИЯ

Будет мало мест и много инсайтов. Успевайте!

#митап #dev
👍3🔥21
#инсайтдня 😊: чем ещё отличается менеджмент агентов от пипл менеджмента (инсайт был сегодня лично для меня, Алексея Е., но думаю и вам полезно)

📍Кратко:
Сформулировав свою хотелку по непонятной задаче, потратьте НЕСКОЛЬКО промптов на исследование возможных источников информации под нее, а лишь затем требуйте от ИИ план выполнения.

(С виду это стандартное "обогащайте контекст перед решением задачи", и я как промпт-инженер давно применял это, но не думал что это нужно настолько глубоко...)


⭐️ Кейс:
Делали сегодня с Клодом 1С-интеграцию. Конечно, Клод не обучали 1С, и меня тоже. Так что искали ответы на вопросы в интернете (постепенно двигаясь от полного непонимания к техническим деталям), а кое-что моими руками брали из базы 1С. И вроде бы быстро дошли почти до всех решений....

Но потом на ~10й мелочи Клоду пришла в голову светлая мысль забрать из 1С структуру всех данных. И о ужас: наши предыдущие решения наполовину оказались неверны — просто нет в нашей базе 1С того, что уверенно выдает интернет по нашей версии, а есть другое (чего я своими глазами в 1С не заметил).

🔌 Вместо этого надо было бы сначала заставить ИИ-агента докопаться до наилучшего источника данных. А иначе он находит ответы через поиск или через юзера, радуется, что их достаточно (по логике действительно достаточно!), и решения строятся на этом шатком основании.

🔌 С исполнителями-людьми такое правило было бы перебором:
1. Даже если человек найдет исчерпывающие доки, он не захочет/не сможет найти там все данные для стоящей задачи.
2. У человека все-таки есть врожденное недоверие к таким источникам информации как интернет или начальник. Так что и без всяких доков сотрудники (пусть и не все 😞), увидят, что основание шаткое. А если у них есть опыт в этой теме, то еще и узнают, где ещё это посмотреть/перепроверить начальника.


В общем, начиная большую задачу с ИИ-агентом, нужно сильнее вкладываться не в "что делать?", а в "где найти наилучший источник правды?" — причем это бывает большой-большой файл, в котором исполнитель-человек не разобрался бы. Найдя его, ИИ даст вам на аппрув правильные предложения и про "что делать", и про "как делать"...

Чем-то мне это напоминает технику 5 почему, только здесь вместо "почему?" — вопрос "как это лучше выяснить?"

Рекомендую задавать агентам этот вопрос почаще — вплоть до 5 раз 😀
🔹Особенно если вы не спец в нужной области (как я в 1С).
🔹И конечно, это не только софта касается. Например, для агента не проблема собрать десяток исследований рынка за последний год, и накопать из них инсайтов для текущей задачи. Это будет лучше, чем если решения будут приниматься по топу гугловыдачи по конкретным запросам...
Please open Telegram to view this post
VIEW IN TELEGRAM
👍133
Помните исследование, которым год пугали любителей ИИ? Оно только что шикарно развалилось

Есть такая контора — METR. Правда очень крутые ребята, тестируют ИИ в разных сценариях.

Летом 2025 они выкатили рандомизированное контролируемое исследование, всё по красоте. Участвовало 16 опытных разработчиков, Cursor + Claude. Результат: с ИИ они работали на 19% МЕДЛЕННЕЕ, чем без него 😬. А сами разработчики были уверены, что ИИ их УСКОРЯЕТ процентов на 20. То есть ощущение скорости и скорость поехали в разные стороны. 

Читали, наверняка )) 

Теперь прикол. 

METR запускает второй заход — новые модели, побольше народу. И в феврале 2026 честно пишет: слушайте, а мы не можем закончить эксперимент. Потому что разработчики ОТКАЗЫВАЮТСЯ работать в условии «без ИИ». 30–50% участников признались, что специально не подают часть задач — просто чтобы их не заставили делать руками. Один сформулировал кмк гениально:

«У меня голова взорвётся, если делать по-старому. Это как идти пешком через город, когда ты уже привык ездить на Uber.»

Вот и весь эксперимент 🤷‍♂️.

Оч хочется глазки приподзакрыть на сопутствующие обстоятельства, но удержусь. METR все-таки НЕ доказал, что «теперь ИИ ускоряет на 18%» — у них там доверительные интервалы недостоверные (через ноль), оплату срезали втрое, куча оговорок. Как чистое РКИ — это провал, и они сами это признают, молодцы канеш 🤝.

Но все-таки развалилось оно НЕ ОБ МЕТОДОЛОГИЮ. Люди ПРОГОЛОСОВАЛИ НОГАМИ. Довод «ИИ замедляет разработчиков» умер потому что подопытных невозможно затащить обратно в контрольную группу )).

Так что когда спорите про ИИ цифрами двухлетней давности — проверьте, живы ли ещё те цифры. А то мир меняется быстрее, чем выходит препринт 🙂
🔥11😁6👍3
Кто виноват, если налажал ИИ агент?

Deloitte так формулирует: агент — ни капитал, ни труд. Ведёт себя как работник, а куплен как софтина. Идеальный безответственный. Кто отвечает за его решения? За риск? За качество? Почти везде сейчас по факту НИКТО. Купило IT — значит, «это к айтишникам». Поставил вендор — «это к вендору». А клиент, которому агент нахамил или слил лишнего, — он же не к IT приходит. Значит структуру ответственности надо переделывать.

Теперь смотрите, что говорят цифры. Только 6% компаний доверяют агентам вести ключевые процессы сами. При этом 84% так и не переделали ни одной должности под ИИ. То есть агентов насажали, а оргструктуру не тронули 🤯

И теперь у нас в индустрии новая игра: придумывать роли под агентов. Agent Supervisor, Eval Owner, Exception Handler, Human-in-the-Loop Reviewer. 

Свёл всё это в систему Cloud Radix — небольшая консалтинговая контора по ИИ. Роли они собрали из свежих разборов MIT Technology Review и Deloitte чтобы вам не пришлось запускать deep research

Кто есть кто, если коротко:
Agent Supervisor — надсмотрщик за флотом агентов: следит за выработкой, качеством и деградацией (drift).
Eval Owner — определяет, что такое «хороший результат», и держит набор тестов качества.
Exception Handler — разгребает краевые случаи, которые агент зафлагал или завалил, и владеет эскалацией.
Human-in-the-Loop Reviewer — аппрувит или режет высокорисковый вывод до отгрузки (юр, мед, финанс).

Вся эта россыпь сводится к трём вопросам про ответственность:

1️⃣ Кто владелец? У КАЖДОГО агента должна быть фамилия человека, который за него отвечает. И сидит он не в IT, а в той функции, что жрёт его результат. IT агента строит и чинит. Отвечает — владелец.
2️⃣ Кто определяет, что «хорошо»? Это тот самый Eval Owner. И это, между прочим, единственная ПО-НАСТОЯЩЕМУ новая работа во всём списке — остальные это переименованный менеджмент.
3️⃣ Кто ловит косяки? Кто разгребает краевые случаи и аппрувит рискованное до того, как оно улетит клиенту.

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

Источник: Rethinking Org Design for Agentic AI (Cloud Radix, 2026) https://cloudradix.com/blog/rethinking-org-design-agentic-ai-mid-market-2026/
👍75
«Где теперь брать джунов?» — решённая задача!!!

Но не у нас )

Да, вы слышали же этот плач сто раз. Джуны вымирают: всю рутину, на которой они росли, забрал ИИ. Никто больше не пишет руками 😭ыыы, а значит, никто и не научится. А что будет, когда ИИ на полдня приляжет? Мы кластер Kubernetes сами не поднимем, стыдобища 🙃))

Что помогает? Посмотреть на тех, кто этот путь прошёл до нас. Пока мы тут открываем Америку, кто-то уже лет сорок как живёт в этом будущем. 

Это станочники-работяги на заводах. 

Короче, раньше токарь точил деталь руками: крутил маховики, чувствовал металл, ловил подачу на слух. Пришло ЧПУ — и станок режет точнее любого мастера. И у токарей встал ровно НАШ вопрос: а надо ли теперь новичку уметь точить руками? Или сажаем сразу за ЧПУ и не паримся?

Товарищи до сих пор срутся на эту тему, натурально, прямо на форумах. «Без ручного опыта ты кнопкодав (button pusher) — сломаешь дорогой инструмент, потому что не чувствуешь, как гнётся резец!!!». Другие: «да ручная токарка — это как учить счеты, когда есть калькулятор, учи сразу ЧПУ!!!». Один в один наш спор про то, заставлять ли джуна писать код руками. 

Но это форумы. А что с индустрией? ИХ отрасль этот вопрос давно закрыла системно. 

Работу развели на две роли. Оператор (CNC operator) — тот самый кнопкодав: загрузил деталь, нажал старт, следишь. Вошёл с улицы, обучение на месте, потолок низкий, прайс мелкий. И станочник (CNC machinist) — который налаживает, ловит брак, чинит, когда станок дурит. Вот он уже судит, а не жмёт кнопку.

А между ними — ЛЕСТНИЦА. Но в чем ее особенность?

В Штатах есть стандарт NIMS, живёт с 1995 года. Учат так. Сначала фундамент — слесарка, измерения, ручная обработка, потом ЧПУ. Штук двенадцать ступеней, каждую надо сдавать руками. 

Отрасль давно поняла простую вещь: завод сам из кнопкодава мастера не растит. 

Российский программист учился кодить на практике (типа «постоит у станка — научится»). Теперь так не получится. Суждение не капает из стажа. Его нужно ставить специально!

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

Наверное и у нас так будет. У них не развалилось и у нас не развалится. 

Если что — реддит, где токари рубятся про «руками или сразу ЧПУ»: r/Machinists
14🔥6👍4😁1
Как устроен этот ИИ-пузырь

Нас кажется ждет все-таки взрыв пузыря ИИ, давайте поймем что там под капотом и чего нам ждать. 

Крупняки (Amazon, Microsoft, Google, Meta и OpenAI) — поставили на то, что спрос на ИИ вот-вот рванёт вверх, начали строить датацентры заранее с огромным запасом, инвестируя под 700 миллиардов долларов в год.

Проблема в том, что выручки, которая всё это оправдала бы, пока нет. OpenAI теряет около 14 миллиардов в год и признаёт, что может не потянуть оплату уже законтрактованных мощностей. Деньги гиганты вкладывают свои, занимают (например, долг Oracle перевалил за сотню миллиардов) и за деньги венчурных инвесторов.

Как устроен сам пузырь. Это называется «циркулярное финансирование». Nvidia вкладывает деньги в OpenAI. OpenAI на эти же деньги покупает у Nvidia чипы, а у Oracle с Microsoft — облако. Те записывают это себе в выручку, их акции растут, под выросшие акции они занимают ещё и тратят ещё. Деньги, по сути, бегают по кругу между несколькими компаниями. Выручка выглядит настоящей, но это во многом одни и те же доллары, которые гоняют по кольцу. Таких сделок насчитали почти на 800 миллиардов. И из-за этого цифры пухнут у всех сразу — все растут, все довольны, все друг друга кормят.

Держится вся конструкция на одном честном слове: будущая выручка должна расти быстро. Пока догоняет — всё норм. Чуть-чуть не догнала — все валится. 

Есть отдельная БОЛЬШАЯ засада с железом: видеокарты устаревают года за три-четыре, а долг под них берут длинный. Получается, занимаешь десятилетние деньги под трёхлетнее железо. 

Теперь как оно посыплется (если посыплется). Толчок обычно один: где-то спрос разочаровал или главный клиент зашатался. Дальше по цепочке. 

OpenAI режет заказы или не платит. Oracle и прочие теряют крупнейшего клиента, у них рушатся прогнозы, а за прогнозами — акции и долг (Oracle, кстати, уже потерял 40% за месяц). Nvidia теряет заказы и тоже валится, а она такой здоровенный кусок биржевого индекса, что тянет за собой весь рынок. Гиганты режут стройку — и под нож идут поставщики, энергетика, все, кто ниже. А поскольку эта горстка ИИ-компаний сейчас занимает неприлично большую долю всего рынка, зацепит и пенсионные фонды, и, считай, всех. 

Почему кольцо делает хуже? В обычной ситуации компании независимы: одна упала — соседи устояли. А тут они сцеплены. Выручка Nvidia зависит от OpenAI, платёжеспособность OpenAI — от Microsoft и Oracle, а те дорого стоят во многом из-за Nvidia. Рвётся одно звено — и кольцо начинает раскручиваться назад, каждый утягивает следующего. 

Что будет с ценой на токены за обращения к модели. Сегодня токены продают в убыток ниже себестоимости, лишь бы захватить рынок, а разницу покрывают деньгами инвесторов. То есть нынешняя цена искусственно занижена дотацией пузыря. При крахе продавать в убыток невозможно, поэтому премиум-подписки могут подорожать, а слабые сервисы — закрыться. Это потянет цену вверх. Но долгосрочно по идее цены должны двинуться вних. Будет какой-то избыток железа после распродажи, модели становятся эффективнее, плюс дешёвые открытые и китайские модели он премис.
13
Почему токены подешеевеют в случае лопнувшего пузыря если сейчас токены уже продают дешевле себестоимости?

Тут логика такая. Сейчас Nvidia продаёт чипы с монопольной наценкой: произвести H100 стоит примерно $3,3 тысячи, а продаётся он за $25–40 тысяч — то есть в 8–10 раз дороже себестоимости, валовая маржа на ИИ-чипах 80–90%. А провайдеры LLM поверх этого отдают инференс ещё и в убыток, дотируя его деньгами инвесторов: OpenAI в 2025-м потратила около $1,35 на каждый заработанный доллар (выручка ~$3,7 млрд, убыток ~$5 млрд).

То есть «истинная» стоимость вычислений — это, грубо говоря, чип по цене производства плюс электричество, и она в разы ниже того, что мы видим на ценнике. Когда пузырь схлопнется, премия Nvidia на чип испарится, а уже построенное железо никуда не денется — его будут гонять на предельной себестоимости, считай, за одно электричество, лишь бы отбить хоть что-то.
То есть когда сейчас говорят, что провайдеры гоняют ниже себестоимости — это верно только если считать от раздутой цены чипа. Убери из неё 8–10-кратную наценку Nvidia — и «убыток» во многом схлопывается: продают не столько ниже реальной себестоимости, сколько ниже той, что раздута монопольной ценой на железо.
3🔥1👀1
Стандарт для базы знаний, которую читает ваш ИИ

Возможно, вы уже держите что-то вроде вики внутри своей базы знаний — набор связанных markdown-файлов, по которым ходит ваш агент. Такой подход популяризировал Андрей Карпаты.

У нас около десятка репозиториев такого типа. Каждый раз, когда заводишь новый репозиторий, структуру придумываешь заново. Агенту же не скажешь «веди базу знаний правильно» — он не знает, как её раскладывать. При этом некие логичные правила как лучше, вообще-то существуют.

Недавно такой стандарт сделал Google. Называется OKF (Open Knowledge Format). Идея простая: договориться, как раскладывать markdown-базу знаний, чтобы её понимал любой агент. Как разложены файлы и папки, какие поля в шапке (frontmatter) у каждой страницы.

Frontmatter — это просто несколько строк в самом верху файла, между двумя ---, куда пишешь метаданные о странице: что это такое, теги, дата, связи с другими страницами. Формат — обычный YAML, поле: значение. Человек их читает как заголовок, а агент — как структурированные данные, по которым можно фильтровать и собирать. Выглядит так:

---
type: проект
статус: в работе
теги: [клиент, ai-трансформация]
---


Правда формат довольно куцый пока. В текущей версии 0.1 обязательное поле там ровно одно — type (что это за страница: концепт, человек, проект, требование…), остальное по желанию.

Из явных плюсов, которые мы ощутили — единый источник правды через тот самый frontmatter. Смотрите: раньше как — есть, например, карточки проектов, и отдельно ведёшь табличку-реестр со статусами. Сдвинулся проект — нужно править в двух местах - в проекте и реестре, и рано или поздно они разъезжаются. А с OKF статус лежит в шапке самого файла, и отдельный реестр просто не нужен — он поднимается из этих шапок сам за секунду. Одна правда.

Если хотите пощупать — вот спека: github.com/GoogleCloudPlatform/knowledge-catalog. Проще всего так: киньте её своему агенту и попросите сделать аудит вашей базы на соответствие — где вы уже сходитесь со стандартом, а где стоит подправить.
🔥6👍2
Ками-сама: возвращение богов

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

Toyota, 2014 год.

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

Чтобы быть хозяином машины, нужно обладать знаниями и навыками, чтобы эту машину обучать.

Эта история повторяется каждый раз. Автоматизация 80-х, реинжиниринг 90-х, офшоринг нулевых, теперь ИИ — по тому же сценарию. Появляется новый инструмент, кто-то решает, что он заменит людей, и режет штат ради экономии на зарплатах. А спустя время выясняется, что срезали не лишних, а тех, кто держал знание и присматривал за самим инструментом. И начинают звать обратно.

Причём экономия достаётся она не тому, кто уволил людей, а тому, кто перестроил работу и поднял людей на уровень выше. Toyota вернула мастеров не вместо роботов, а чтобы делать роботов лучше.
💯82👍1
Как ИИ убивает найм

Странная штука сейчас с наймом в ИТ: откликов рекордно много и при этом никого не найти 🤯

На днях у Gergely Orosz (The Pragmatic Engineer) вышел разбор рынка найма 2026 — по разговорам с 50+ нанимающими и соискателями. Итог такой: компании не могут найти людей, а опытные инженеры не получают ответа даже на отклик. Обе стороны будто не слышат друг друга. По разным замерам рынка, откликов на вакансию с 2022 года стало вдвое больше — а до собеседования доходят единицы (обычно 4–6 человек на позицию).

Как так вышло? Gergely говорит, что ИИ завалил обе стороны шумом. На одну вакансию прилетает 800–1000 откликов, из них по делу — пара штук. Резюме при этом идеально вылизаны нейросетью у всех. Дошло до того, что многие наниматели просто перестали читать входящие.

Когда доверие к отклику рухнуло, рынок откатился к тому, что было до сайтов вакансий, — к сарафану. Интервью теперь получают в основном через знакомых и рефералов, холодный отклик на сеньорские позиции почти не работает.

Рынок при этом раскололся надвое. Инженерам по ИИ и ML по 2–3 предложения в день. Вакансий по ИИ за год стало на 60% больше, а по обычной разработке — лишь на 7%. Всем остальным — глухо: планку подняли, а зарплату предлагают ниже. 

И залить проблему ещё большим ИИ пока не выходит. Пробуют по-разному — от ИИ-интервьюеров вроде Mercor до оплачиваемых пробных дней вместо собеседования. Но с ИИ-интервью пока засада: почти 4 из 10 кандидатов просто бросают процесс, где их гоняет робот. Инструмент, который сломал сигнал, ту же дырку и не латает.

ИИ пока не столько отнял рабочие места, сколько сломал сам способ их искать. И готового ответа ни у кого нет — индустрия скорее отматывает назад, к старым практикам: к найму через знакомых и живым встречам.
7👍5😱2😢1