Спрашиваю у ChatGPT: есть купе Москва - Владивосток на четверых? "Есть, четыре места".

Формально правда. Фактически - четыре места в четырёх разных купе и двух вагонах. Семья едет шесть суток по разным дверям.

Модель не соврала. Ей просто никто не объяснил разницу между "четыре свободных места" и "четыре места за одной дверью". В ответе API РЖД такого поля нет, разницу надо вычислять: календарь → поезда → вагоны → схема вагона → номера мест, сгруппированные по купе. Пять шагов, и только на пятом понятно, что показывать человеку.

Я вынес эти шаги в MCP-инструменты, чтобы проверка жила в коде, а не в голове модели. Не удалось подтвердить по схеме - ассистент пишет "вагон минимум с четырьмя местами", а не "нашёл купе".

Отдельным сюрпризом было то, что из Vercel запросы к РЖД висли по сто секунд. Healthcheck при этом горел зелёным.

Разобрал весь путь - Bun, MCP, Vercel, свой reverse proxy: https://habr.com/ru/articles/1067268/

Агент честен ровно настолько, насколько честны инструменты, которые вы ему дали.

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

Спросить оказывается не у кого.

Принято считать, что разница между "быстро накидал" и "сделано по-взрослому" - в дисциплине. Сначала спека, потом код, ревью внимательнее. Я тоже так думал.

Разница в другом: где после работы остаётся истина о системе.

Вайб-кодинг не производит побочных продуктов. Кроме приложения не остаётся ничего - ни плана, ни утверждения, что требование выполнено. Знание живёт в голове автора и в контексте сессии. Сессия закончилась - и спрашивать больше некого.

AI-DLC отличается одним. Между намерением и исполнением на каждом шаге появляется объект, который кто-то утверждает. План. Критерий приёмки. Гейт в сборке. Живёт он отдельно от кода и отдельно от автора.

На практике это выглядит как отчёт покрытия, который генерируется прогоном. 314 критериев из 422. И честные нули внутри: трассировка 0 из 11, политика аккаунта 0 из 14. Нули видны именно потому, что отчёт машинный - галочку из добрых побуждений поставить нельзя.

Таким отчётам верят охотнее, чем нарисованным ста процентам.

Пока систему делает и оценивает один человек, всё это лишние расходы. Появляется второй - соавтор, преемник, инвестор - и цена отсутствующих артефактов начисляется задним числом, сразу за всё.

https://iconicompany.com/blog/vibe-coding-to-production-ai-dlc-evidence

Чаще всего поиск для RAG делают в один проход: у каждого фрагмента лежит один вектор, запрос превращается в такой же вектор, база отдаёт ближайшие. Это быстро, потому что представления фрагментов посчитаны заранее и лежат в базе статикой - на запрос считается только вопрос. Когда качества такого поиска не хватает, сверху обычно ставят реранкер: кросс-энкодер или внешний API, который заново читает пары "вопрос + фрагмент".

Есть третий вариант, и он ближе к первому: late interaction. У фрагмента хранится не один вектор, а матрица - по вектору на каждый токен. Эти матрицы тоже статика в базе, поэтому второй проход не зовёт никакую модель: он считает арифметику по уже посчитанным числам.
Мы решили выяснить, окупается ли этот второй проход. Короткий ответ: на нашем корпусе он вдвое повышает точность первого места - нужный фрагмент оказывается первым в 73% случаев вместо 36%.

https://iconicompany.com/ru/research/late-interaction-measured-maxsim-doubles-hit-rate

Наш агент отвечал кандидату 28 секунд. Не думал 28 секунд - столько уходило, чтобы вообще начать думать.

Человек в чате за это время успевает уйти. Я решил, что дело в модели, и поменял движок: вместо Antigravity CLI поставил omp (Oh My Pi). Он работает и по токенам, и по подписке, а главное - умеет режим RPC, где агент живёт процессом и получает реплики кадрами, а не поднимается на каждую заново.

Стало 13 секунд на первый ответ и 2.5 на следующий. А в живом чате - по-прежнему 23 и 12.

Дело было в двух заголовках. Агент носит с собой токен человека и его последнюю реплику: по ней продукт сверяет, что цитата не выдумана. Оба меняются с каждым сообщением - а заголовки инструментов читаются один раз, при подключении. Каждое "привет" поднимало процесс с нуля. Я грел ровно то, что сам же и выбрасывал.

Починка - разделить. Движку выдаётся ключ на всю жизнь его процесса, а настоящие заголовки подставляет шлюз в момент вызова. 3.6 секунды на ответ в переписке.

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

Скоро откроем агента всем.

Своя модель вместо облачной заработала с первого раза. Числа правдоподобные, чек-лист заполняется, ошибок нет.

И она отвечала примерно одно и то же на что угодно.

Мы учим модель проверять, закрывает ли резюме требование вакансии, - чтобы считать это у заказчика, а не гонять данные кандидатов во внешний API. Обучение оказалось лёгкой частью: час на арендованной видеокарте, 77 центов, качество на уровне облака.

Трудным оказалось доказать, что продукт считает то же самое, что обучение.

Требование "Знание Kubernetes и Helm" против резюме фронтендера, который инфраструктуру в глаза не видел. Эталон: 0.011. Наш продукт: 0.795. Рядом честное совпадение по Python - 0.807.

То есть на всё подряд - "вроде подходит".

Причина в одну строку: модели подаётся разметка, где кончается требование и начинается резюме. Мы подавали туда нули. Слова при этом бились с эталоном идеально, до последнего токена.

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

Теперь рядом стоит сверка с эталоном до четвёртого знака и отдельная проверка, что модель вообще отвечает по-разному: первая вырождение не ловит.

Сломанная модель не падает. Она соглашается со всем.

Разбор целиком: чем мы заменили облачную модель и как это проверяли

"Никто не подходит" - самая дорогая строка в подборе.

Мы неделю смотрели на вакансию, где ни один кандидат не набирал и половины. Людей на рынке хватало, а список был пуст.

Дело оказалось в одном требовании: "опыт прохождения процедур ИБ". Такое в резюме не пишет никто, даже когда опыт есть. Модель честно не находила упоминания и ставила ноль. Всем сразу. Одна такая строка обнуляет вакансию целиком.

Посмотрели на потоке: 20 371 вердикт из 75 769 были нулями за молчание резюме. Каждый четвёртый ответ означал "я не нашёл", а читался как "у человека этого нет".

Починили различением. Названный инструмент, которого в резюме нет, это честный ноль. Процесс, о котором резюме молчит всегда, это вопрос кандидату, а не приговор. На проверочной вакансии доля нулей упала с 42% до 18%.

Дальше интереснее. Мы научили свою модель говорить "не знаю": она отдаёт оценку вместе с уверенностью, и уверенность проверена на вакансиях, которых модель не видела. Половину строк она закрывает сама, с точностью 95%, на обычном процессоре и без обращения к облаку. Остальное уходит туда, где дороже и умнее.

Скрининг, который умеет сказать "я не знаю", отсеивает меньше людей, чем скрининг, который всегда уверен.

Со-автор RLHF и ChatGPT 15 сентября выпустил модель, которая не пишет текст вообще. Jev от TypeSafe AI отвечает решением и числом уверенности. $0.042 за миллион токенов.

У нас ровно такая задача: закрывает ли резюме требование вакансии. Считает свой кросс-энкодер на 278M, на процессоре.

Поставил Jev на наш отложенный набор. 2000 пар, 82 вакансии, 17 центов, четыре минуты.

0.868 ROC-AUC против наших 0.883. Бутстрэп по вакансиям: разность 0.014, интервал [-0.030; 0.067]. Ноль внутри, модели неразличимы. Zero-shot, на русском, впервые видя наши данные.

Калибровка, главное заявление Jev, при этом вдвое хуже нашей: ECE 0.117 против 0.071.

А потом я разложил набор по видам меток и понял, что мерил не совсем то.

40% отрицательных меток у нас поставлены за молчание резюме: "Kafka не упомянута" значит "навыка нет". Этот дефект мы промпту запретили ещё в сентябре. На таких парах Jev нас обходит, 0.929 против 0.920. На честных проседает сильнее, 0.827 против 0.858.

Часть его согласия с нами - совпадение предрассудков, а не качество.

Ставить Jev к себе всё равно нельзя, открытых весов нет. Забрать стоит другое: бенчмарк, где метки ставила одна модель, а проверяют другую, меряет заодно и их общие ошибки. На итоговом числе этого не видно.

Разбор: https://iconicompany.com/ru/research/jev-system-one-vs-fine-tuned-cross-encoder

Мы дописали алертинг по логам и сели за регламент для дежурного: пришло письмо - открой агента idevops, скопируй туда текст алерта. На этой строчке стало неловко.

Письмо порождает машина. Копирует его человек. Разбирает снова машина.

Шлюз к агенту у нас уже был - для клиентских обращений: живая сессия omp --mode rpc, кадры JSON через stdin/stdout, инструменты подключаются конфигом. Алерт из Alertmanager - то же обращение, просто его пишет vmalert, а не человек.

Переходник занял триста строк на Bun: вебхук Alertmanager разворачивается в промпт и уходит в ту же сессию. Упёрлись в 429 по квоте - повторяем через agy.

Скормили настоящий алерт: HighErrorRate, cloudauto-sandbox/app, 45 ошибок за 5 минут.

Агент за один ход сходил в VictoriaLogs по LogsQL, дёрнул kubectl за подами и сопоставил. Под живой, 2/2 Running, три дня без рестартов. В логах client_fetch_error ... read ECONNRESET на собственный https-домен. В кластерном шлюзе для sandbox-хоста поднят слушатель на 80 и не поднят на 443, сертификата тоже нет. NextAuth стучится по https - Envoy рвёт TCP по отсутствующему SNI.

Сорок минут моей работы. У агента - один ход.

Разбор целиком, вместе с тем, почему агент при этом ничего не чинит и где у --auto-approve граница: https://iconicompany.com/ru/blog/alert-is-a-ticket-sre-agent-over-omp-rpc

Утром мы отправили алерты прода в Claude-сессию проекта. Через час задумались: почему не в наш omp? Ответить было нечем: сессию можно выключить, и алерт в ней пропадёт.

Переделали. Теперь алерт из VictoriaLogs становится issue в репозитории продукта, а разбирает его roboomp, GitHub-бот, которым авторы omp чинят свои же issue. Модели идут по подпискам через omp auth-broker, API-ключей нет.

По дороге Anthropic отказал подписке с 403 Request not allowed и через прокси с выходом в США, и напрямую. Помог выход через sing-box, со второй попытки: первая уронила прод. Пробный алерт бот разобрал за 38 секунд.

Пять граблей и то, где эта схема сломается, в статье: https://iconicompany.com/ru/blog/omp-alert-triage-github-issues-roboomp

Мы используем omp как роутер: он решает, какую модель подключить, когда позвать отдельного агента и как не гонять одну и ту же историю по кругу.

Поэтому меня зацепила статья NVIDIA, MIT и NTU про SoL-Pi. Они оптимизировали не саму языковую модель, а harness вокруг кодинг-агента.

Другой AI-исследователь предложил 152 изменения. В финал прошли только четыре:
- объединять правку файла и запуск тестов в один вызов;
- не таскать большие логи целиком после каждого шага;
- сжимать диагностические логи дешёвой моделью, проверяя цитаты ошибок по оригиналу;
- запускать compaction только тогда, когда экономия перекрывает цену перезаписи prompt cache.

На 51 задаче EdgeBench токеновый трафик упал на 44,7-49%, а счёт за API - примерно на треть. На GPT-5.6 Sol: $1339 у базового Pi против $894 у полного SoL-Pi.

Но есть цена: средний балл снизился с 44,8 до 42,0.

Самый интересный результат дал один механизм, ObservationPack: $1271 и 47,2 балла. То есть экономия есть, а измеренного падения качества нет. Правда, прогон был один, поэтому разницу в несколько баллов я бы пока не называл доказанным улучшением.

Для меня вывод простой: иногда выгоднее оптимизировать не модель, а всё, что происходит вокруг неё. Мы в omp как раз работаем с этим слоем: маршрутизацией, контекстом, делегированием и стоимостью каждого следующего шага.

Статья: https://arxiv.org/abs/2609.20519
Код: https://github.com/NVlabs/SoL-Pi

Мы полтора года развивали платформу подбора IT-специалистов. А сейчас смотрим на свои внутренние процессы и понимаем: наш собственный агент подбора может устареть быстрее, чем мы планировали.

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

Наш idevops развернул кластер, мониторит в нем ошибки и через alert-relay заводит тикеты на исправление. Агент ipresale сам мониторит тендеры, считает смету, собирает КП и раскладывает документы по слотам подачи. Задачи, под которые традиционно нанимали пресейла, архитектора и дежурного SRE, теперь крутятся в изолированных процессах по cron и вебхукам.

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

Разобрали архитектуру и границы таких агентов: https://iconicompany.com/ru/agents

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

Воскресная рубрика: домашние разработки. Сегодня учим телевизор пропускать кулинарию.

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

Дообучили rubert-tiny2, экспортировали в ONNX и подключили к Kodi через домашний Kubernetes. Модель читает название и описание, подходящие передачи получают звёздочку. На проверке macro-F1 = 1,000. Можно выбирать кино?

При подготовке статьи я пересчитал данные: у 119 из 120 тестовых записей описание уже встречалось в обучении. Мы размножили примеры припиской "Часть N", а потом случайно разделили строки на train и test. Получился почти экзамен по знакомым билетам.

В рекомендациях нашлись "Секреты квантовой физики" и "Чудеса Вселенной", но затесалась и криминальная история. Идеальная метрика выбор вечернего фильма не решила.

Разбор с кодом, ответами модели и ошибками: https://habr.com/ru/articles/1090216/

Я посмотрел видео Anthropic про Loop engeenering. Очень хороший обзор, как сделать приложение за 1 час: на входе требования, критерии приемки и тест-кейсы. Агент автономно проектирует UI и функционал, а далее проводит e2e тестирование. Приемка человеком еще нужна, но это уже не полноценная команда, а 1-2 человека (инженер-аналитик и опционально QA)

Можно бесконечно смотреть на три вещи: как течёт вода, как горит огонь и как команда ИИ-агентов ведёт проект в сессиях omp.

Проджект выбирает следующую задачу. Аналитик разбирает требования и критерии приёмки. Разработчик пишет код и приносит результаты тестов. DevOps проверяет, где это вообще можно безопасно запустить.

У каждого своя сессия и свой контекст. Общаются через SendMessage: передают задачу, называют файлы, возвращают результат. Я сам участвую в этой переписке и иногда ловлю себя на том, что читаю её как рабочий чат обычной команды.

Особенно когда выясняется, что "тесты прошли" ещё не значит "можно выкатывать". Начинаются уточнения про окружение, доступы и то, какой именно код проверяли. Знакомый разговор, только все собеседники сидят в терминале.

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

Вода течёт, огонь горит, а третьему иногда приходится писать: "Стоп. Сначала проверь ветку".

Похоже, спор офиса с удалёнкой закончат агенты. Они вообще не собираются приходить в офис.

Аргумент за офис понятен: люди быстрее договариваются, когда сидят рядом. Но я смотрю на другую схему: несколько команд агентов и один человек, который ставит задачи и проверяет результат. Кого в этой схеме возвращать за соседний стол?

Мы подали тендер: комплект на 90 позиций, 37 документов. По оценке команды, сборка у ipresale занимает около 5 минут против 2-3 часов вручную. Проверку и подачу нужно считать отдельно. Агент связывает файлы с полями загрузки; обязательства утверждает человек.

Здесь уже приходится сравнивать аренду, ФОТ и взносы со стоимостью агентов, их настройки и контроля. Одна подписка ещё не вся себестоимость. Но и рассадка людей по кабинетам сама по себе не делает процесс эффективным.

Одному оператору офис может быть нужен ради общения и смены обстановки. Это нормальная человеческая потребность. Агентам переговорная не нужна.

https://iconicompany.com/ru/agents

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

На снимке проектная сессия должна закрыть фазу, а DevOps - подготовить среду по требованиям проекта и договора.

Gate 3 пока закрыт: в сообщении перечислены непроверенные условия по DDL и валидации, PVC, сетевому доступу, ESO/TLS и CI. Агент не объявляет фазу готовой по одному удачному шагу. Сначала нужны проверки и подтверждение результата.

Так выглядит рабочая связка: одна сторона держит цель и критерии приёмки, другая разбирает инфраструктурные условия и фиксирует, что ещё блокирует релиз. Человек координирует и принимает результат; агенты выполняют ограниченные задачи и оставляют проверяемый след.

Для людей офис или удалёнка остаются способом общаться и работать вместе. Агентам нужны контекст, доступы и чёткие критерии. Один специалист может вести несколько таких потоков, если успевает проверять решения и риски.

Офис решает, где встречаются люди. Готовность фазы решают критерии.

Илон Маск говорит что останутся профессии строителей и сантехников, а тем временем его грок боты...