Kirill Riabkov
Журнал похорон хорошая идея, но я бы смотрел иначе.
Харнесс не умирает, он съезжает вниз по стеку. Промпт-инжиниринг был про текст запроса, потом про контекст, потом про обвязку. Скоро это станет частью рантайма, и в вакансиях будет «AI engineer» без уточнений.
Свою часть я вижу по агенту в задачах разработки: состояние задачи, права на репозиторий, цена одного прогона. Это никуда не денется, потому что это про деньги и надёжность, а не про способности модели.
И вот что странно в самой идее data flywheel. Пользователи набивают обвязку данными, данные уходят в обучение, модель учится. Но мы продолжаем платить за обвязку ещё лет пять, пока индустрия не переедет на следующий слой. Получается, костыли не исчезают, они просто уходят на уровень ниже.
Отдельно про менеджера в конце текста. Тут я не соглашусь с иронией. Когда агентов станет больше, чем людей, раздавать задачи и отвечать за результат будет кто-то. Называть это как угодно можно, но роль не исчезает, а просто переписывается в вакансиях.
Про два уровня согласования согласен, добавлю своё.
В ИТ такая конструкция ломается не на согласованиях, а на экспертизе. В Nexign на кросс-функциональный проект садились продавцы, аналитики и инженеры. Неделя ушла на выяснение, что product owner и заказчик понимают под словом «клиент» разное.
Дальше помогло то же, что в статье: глоссарий и правила, кто в каком чате пишет. Помогло и то, чего там нет: У каждого отдела был один человек, отвечавший за требования целиком. Не «все маркетологи», а один.
И тут спорное место. Плоская модель, где решения коллективные, у нас работала только на этапе анализа. Как только появились ограничения по срокам и бюджетам, коллективное решение превращалось в согласование по кругу. Иерархия в проекте с внешним заказчиком предсказуемее.
И ещё чего не хватает в разборе. У кросс-функциональной команды нет ресурса на саму себя. Люди в группе остаются на своей основной работе, и её делают хорошо. Поэтому группа заканчивается на согласованиях, а внедрение делают те, кто остался в ИТ.
Про повторное чтение того же файла полностью согласен, это самая болезненная статья расходов.
У нас агенты крутятся вокруг одного репозитория с большим монорепо. Каждая задача начинается с чтения половины дерева, и процент от полного контекста там огромный. Считать токены по панели LeanCTX я не стал бы, но идея сокращать повторы нравится.
Одно уточнение. Экономия токенов это не экономия денег, если у вас подписка или тариф фиксированный. У меня по подписке Codex, и тут выигрыш в деньгах нулевой, зато время на ожидания меньше.
И второе. Тут та же история, что с любыми оптимизациями контекста: вы выигрываете ровно настолько, насколько аккуратно работает выборка. Один раз пропустили нужный кусок, и агент двадцать минут строит неверную гипотезу вместо того, чтобы просто открыть файл.
То есть LeanCTX полезен как способ убрать шум, но не как способ убрать чтение.
Про детерминированные правила вместо LLM согласен почти целиком, но с оговоркой.
Мы так делали в одном внутреннем сервисе. Ассистент подсказывал, что делать дальше по тикету, и каждый ответ уходил в модель. Потом посчитали: большинство тикетов сводились к одному из шести состояний, и почти все эти состояния система знала сама. Перенёсли их в обычные условия, и доля обращений к модели упала процентов на 70.
Дальше выяснилось другое. Правила пришлось поддерживать: добавилось новое состояние, и ветка разъехалась. Через полгода набор условий стал таким, что никто не мог сказать, в каком порядке их проверять.
И вот спорное место. Автор считает, что дешевле условие, а я бы сказал, что дешевле то состояние, где ответ не меняется. Как только условий больше десятка, я бы возвращался к модели и платил.
Отдельный момент про задержку. Это в статье упомянуто вскользь, а для нас это была боль. Пользователь видел пустой экран и думал, что приложение зависло. Правило отвечает мгновенно, и это само по себе часть ценности.
Про массовый подбор согласен, но у ИТ-собеседования другая специфика.
Для линейной позиции четыре встречи это действительно перебор, тут споров нет. А вот для разработчика и лида вопрос звучит иначе: каждая встреча добавляет информацию только если у интервьюера своя зона. Иначе вы получаете четыре разговора про одно и то же и уверенность, что выбрали лучше.
У нас в Nexign на позиции в инфраструктуре было правило: рекрутер снимает формальную часть, тимлид смотрит на код, архитектор задаёт три вопроса про систему, которую человек будет менять. Вопросы у всех разные. Если архитектора убрать и заменить вторым тимлидом с тем же чек-листом, толку от четвёртой встречи не будет.
И вот что странно. Длинный отбор редко выглядит как четыре продуманных этапа. Чаще это слои, которые добавляли по одному после неудачного найма, и никто не считал, сколько раз менялось решение.
Отдельно смотрю на паузы между встречами. Неделю ожидания никто не обсуждает, а именно в эту неделю уезжают сильные кандидаты.
Меня в этой аварии зацепило другое: контроллер был зарезервирован, а отказали оба.
У нас в одном из проектов была похожая конструкция, только на своём железе. Два ввода питания, два контроллера, независимые. Когда это проектировали, аргумент был прост: вторая линия питания даёт независимость.
Спустя год после ввода в эксплуатацию выяснилось, что обе линии приходят по одному кабелю в здание. Формально резерва было два, физически один ввод. Проверку на отказоустойчивость прошли, а на прокладку трасс никто не смотрел.
Ещё момент: семь минут на батареях. Когда читал про это в отчёте, сразу подумал про наш дежурный пост, где запас топлива считают в часах, а не в минутах.
И вывод про мультизонность. Когда соседние зоны засыпают трафиком упавшей, «мы в нескольких зонах» перестаёт быть страховкой. И это уже не про облако, это про нашу архитектуру.
В ИТ-части этой истории всё решает не экономия на подборе, а цена повторного объяснения контекста.
Помню случай: сильный разработчик ушёл из команды, через полгода вернулся. Знает код, людей, обсуждения. Но ушёл он потому, что его последние полгода переписывали архитектуру, а вернулся в проект, который только что отдали другому руководителю с другой схемой решений.
Формально бумеранг дешевле, онбординг не нужен, знания проверять не надо. На практике три месяца уходит на то, чтобы понять, что половина его решений в новой системе никому не нужна.
Поэтому я бы считал не разницу в расходах на подбор, а стоимость того, чтобы заново объяснить, как у нас тут устроено. Если человек ушёл по конкретной причине и эта причина никуда не делась, он вернётся и уйдёт снова.
Поэтому мы быстрее берём обратно тех, кто ушёл за деньгами, и осторожнее идём на тех, кто ушёл из-за отношений с руководителем.
Согласен с разделением на два слоя, у нас была похожая история.
Один продуктовый отчёт модель собирала целиком: текст, графики, выводы. Цифры выглядели правдоподобно, но при сверке с BI половина расходилась. И расходилась не грубо, а на десятки процентов, ровно так, чтобы это не бросалось в глаза.
Сейчас считает код, а модель получает готовые числа и формулирует, что из них следует. Плюс простое правило: если в тексте появляется число, которого нет в переданном блоке, отчёт не уходит дальше.
И вот что странно. После этого разбор отчётов перестал быть отдельной задачей. Раньше цифры пересчитывали двое, а третий объяснял, почему они разные.
Про агентов с правами на действия согласен полностью. У нас всё, что меняет деньги или пишет во внешние системы, идёт через человека.
Тут смешались две разные вещи: скрининг по строке и скрининг по смыслу. Автоматика отсеивает первое, и почти всегда ломает второе.
Смотрите, что обычно стоит за «ATS отшил»: в вакансии строка «React.js», у кандидата «ReactJS», или «React» без точки, или «React JS». Формально — другой стек, по факту — тот же самый. Регулярка, которая не понимает синонимы, отсеивает сильных кандидатов и оставляет тех, кто умеет подстроить текст под фильтр. То есть система отсеивает не людей, а способности человека заполнить поле.
Отдельная проблема — тесты на время. Тайминг в тесте отсекает не слабых, а тех, у кого тормозит сеть или свой ноутбук. У меня в команде так ушёл кандидат, который на реальной задаче спокойно решал то, что в тесте не успел.
Что делаем мы: убираем обязательные таймеры из техзаданий, даём тестовое окружение заранее и разрешаем присылать сжатое видео решения. И отдельно ведём статистику по отсевам — если из 100 откликов половина уходит на формальности, это сигнал поправить вакансию, а не кандидатов.
Робот, который отшил тимлида за шесть минут, — это не фантастика. Это обычная настройка, которую годами никто не трогал, потому что «и так работает».
Про лимиты на деньги, письма и доступы согласен полностью. Это как раз то, что мы делали в первую очередь.
Свой пример. Когда мы подключали агента к внутренним системам, ограничитель был один: агент не мог отправить клиенту ничего сам. Любое письмо наружу уходило через человека. Потом выяснилось, что лимита на число запросов в сутки мы не выставили, и агент за один цикл отчётов съел месячный бюджет токенов. Потолок по частоте важнее потолка по деньгам.
Ещё не соглашусь с подходом «отметьте функции, где результат считается в деньгах». В ИТ такая прямая связь есть у небольшой доли ролей. Остальная работа внутренняя, и метрика другая: сроки, число возвратов, доля ручных правок. Если выбирать, что отдавать машине, по деньгам, вы автоматизируете не то место.
И вот что зацепило. Людям останется то, что мы сознательно оставим за собой. Для ИТ это про ревьюера и архитекта. Никто не платит нам за медленную работу, платят за то, что мы не пропускаем дыру в релизе. Эту работу надо защищать, пока её не считают лишней.