Что посмотреть про ИИ: от нейрона к фабрике софта

Что посмотреть про ИИ: от нейрона к фабрике софта

Суть: С момента прошлого обзора — «Что посмотреть про ИИ: AI coding, агенты и сознание» — прошло примерно полгода. Накопилось чуть больше 40 материалов, которые мне показались полезными и интересными: из одних я почерпнул идеи, другие подтвердили мои решения. Собирались они по одному, но все пронизаны одной нитью и выстраиваются в логичный ряд от нейрона к фабрике софта. Как из опыта и повторений формируется интуиция, как возникает сознание, как модели сжимают мир в знания и отбрасывают неверные утверждения, почему ИИ-фабрике без человека не обойтись, какое окружение нужно агенту и на каких моделях его запускать. Это обзор источников с моими заметками.

Содержание

Откуда берётся навык: талант, труд, количество попыток

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

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

Habr — талант — это желание

Локус контроля: 4 убеждения, которые хоронят амбиции

Статья про теорию локуса контроля Роттера. Внутренний локус (я — причина моей жизни) против внешнего (я — жертва обстоятельств). Четыре установки, которые держат человека в пассивности: «мне не дано», «всё решают связи», «я жертва», «удача решает всё».

Я давно для себя решил — при должном стремлении и дисциплине можно добиться успехов выше среднего и даже ещё немного выше. Не в таланте дело, а в желании. Будет желание — будут действия — появится мастерство, в котором другие увидят талант. Интуиция через желание подсказывает, куда двигаться. Надо прислушиваться к желаниям.

Дороничев — прыжок веры и волны удачи

Интервью Андрея Дороничева (А. Соколовский) — 2 ч 44 мин

Очередное интервью с Дороничевым. Мне откликается его тема прыжка веры — он даже написал об этом книгу («ты можешь карабкаться по какой-то скале… но возникает зов к переменам»): «Этот прыжок веры, он очень страшный», но «в какой-то момент можно и, я считаю, нужно совершать». По Дороничеву, до прыжка всегда есть возможность сделать пробные безопасные шаги — как двери с двусторонним движением у Безоса: «начни по выходным волонтёрить, тебе быстро надоест — вернёшься». А после прыжка «приземлишься, скорее всего, ниже, чем стартовал» — и снова карабкаться вверх, уже на новой скале.

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

Я давно заметил — удовольствие получаю от процесса, а не от результата. Успех как точка прибытия может обнулить смысл — «а что дальше?». Главное — путь к цели, а не достижение цели. С Дороничевым тут совпали. Мой уход с последней работы в ИИ — тот самый прыжок веры. Прыгнул и гребу изо всех сил. Пока, правда, никуда не догрёб — прокачиваюсь там, где слаб.

Veritasium — степенной закон: редко, но крупно

График, после которого вы посмотрите на мир иначе (Vert Dider) — 43 мин
Veritasium, перевод Vert Dider

Научпоп о том, что мир описывается не одной кривой. Рост, IQ, размер яблок подчиняются нормальному распределению — колоколообразной кривой, где большая часть значений около среднего. А доходы, просмотры, лесные пожары и землетрясения живут по степенному закону. Здесь большее концентрируется у немногих, а малое — у большинства. Несколько гигантов забирают почти всё, за ними тянется длинный хвост мелочи. Парето наткнулся на это ещё в XIX веке, строя кривые доходов: «большая часть богатства сосредоточена в руках немногих избранных». Знакомый всем принцип 20/80 — тот же степенной закон, только в самом грубом пересчёте. Сегодня то же самое на новых данных — половину времени на Netflix зрители проводят за 6% самых популярных сериалов, а меньше 4% видео на YouTube (те, что добрались до 10 тысяч просмотров) дают больше 93% всех просмотров платформы. Откуда степенные законы вообще берутся в природе? Veritasium объясняет на песчаной куче. Сыплешь песчинку за песчинкой, и куча сама дорастает до критического состояния: любая песчинка теперь может обрушить склон, а какого размера будет обвал — крошечный или катастрофический — не знает никто. Той же логике подчиняются землетрясения и лесные пожары.

Самая наглядная часть — пример игры с монеткой со следующими правилами: ставишь доллар один раз, дальше банк переходит из броска в бросок. Выпал орёл — банк умножается на 1,1 (со ставки в доллар стало 1,10), выпала решка — на 0,9 (осталось 90 центов); следующий бросок умножает уже новую сумму. Всего бросков сто. Средний множитель (1,1 + 0,9) / 2 равен единице, игра выглядит честной. Но проигрывает большая часть игроков: орлов и решек у них поровну, каждая пара бросков умножает банк на 1,1 × 0,9 = 0,99, и за сто бросков от доллара остаётся примерно 61 цент. Зато изредка кому-то везёт: за сто бросков ему выпадает, скажем, девяносто орлов — и доллар дорастает до тысяч. Порядок бросков не важен, важен перевес: у везунчика больше множителей 1,1 и меньше 0,9, на такой разнице банк и взлетает. Эти редкие серии и есть хвост распределения. Именно их выигрыши уравновешивают потери остальных — среднее по всем игрокам остаётся долларом, хотя большинство заканчивает с 61 центом. Сорвать куш здесь — не одна счастливая ставка: везти должно девять бросков из десяти, снова и снова, поэтому куш и редок. Решает количество успешных попыток — каждая умножает результат, и даже мелкое «чуть лучше, чем в прошлый раз», повторённое много раз, превращается в огромный отрыв.

В реальной жизни степенной результат приносится усердием: множеством попыток и постоянными улучшениями. Маленькое преимущество на каждой попытке даёт на дистанции разы. Управлять можно числом попыток и тем, чтобы каждая следующая выходила чуть лучше предыдущей. Настойчивость уместна, но это настойчивость серии, а не упрямство в одной точке. Условие подсказывает та же монетка: медианный итог ста бросков равен 61 центу — столько теряет игрок, ставящий весь банк целиком. В жизни урок такой: рискуй долей, а не всем сразу, иначе полоса неудач обнулит счёт раньше, чем выпадет твоя удачная серия. На рынке это риск на сделку — его держат размером позиции и уровнем стопа. Выбирать надо поля, где огромный результат вообще возможен. Статьи и контент показывают это прямо: горстка хитов на YouTube собирает почти все просмотры платформы. Проекты и эксперименты живут так же — большинство попыток не выстрелят, и это нормально. Но количество без качества не работает — сто слабых статей не заменят одну хорошую.

Смирнов — тик-ток коучинг как новая норма

Чем плох тик-ток коучинг (не тренд, а новая норма, пазл сложился и это меняет всё) — 16 мин
Тихон Смирнов

Отрезвляющее видео про тех, кто учит зарабатывать. Главный механизм: идеи теперь отбираются не по результативности, а по пересылаемости — универсальный простой ответ побеждает, потому что его удобно переслать в телефоне, а не потому, что он работает. Алгоритму платформы истина не важна — он её даже не знает. YouTube, TikTok, запрещённый в России Instagram видят только реакцию и разгоняют ролик, даже если это «конченная генерация нейросети».

Успех — лотерея, и статистика та же, что у Veritasium выше: по годовому отчёту Luminate за 2024-й, из 202,2 млн треков 93,2 млн включали не больше десяти раз, а по-настоящему успешными стали лишь 33. Небольшой перевес на старте превращается в непропорциональный успех. Это «теория суперзвезды» (Шервин Розен, 1981): небольшая разница в таланте при массовом рынке оборачивается гигантской разницей в доходах. Богатые богатеют. В соцсетях механика такая: тезис случайно залетает, получает кучу охватов, другие авторы смотрят и думают «я тоже хочу лайков» — и снимают то же самое. Со временем тезис становится неоспоримой истиной.

Сейчас то же самое происходит с ИИ: «нейросети заменят программистов за год» — идеальный тезис для пересылки.

Ключарёв — интуиция как натренированная сеть

Интервью нейробиолога Василия Ключарёва (А. Соколовский) — 2 ч 10 мин

Про интуицию и принятие решений. Интуиция — «набор нейронов, которые обучаются на пробах и ошибках», и полагаться на неё можно, «если она была обучена». Примеры — гроссмейстеры на сеансах одновременной игры и медсёстры, которые пеленают лучше других, но не могут объяснить почему. Самое удивительное — эксперимент с трейдерами: активность богатой дофамином области мозга предсказывала движение акций, хотя сами трейдеры — нет. Дофамин у Ключарёва так и определён — «оценка будущего вознаграждения», медиатор прогноза удовольствия. «Что-то в мозге отслеживает происходящее так, что позволяет ему видеть на шаг вперед».

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

Из всего этого я забрал для себя одно: решения в моих проектах и есть те пробы, на которых тренируется интуиция. Разобрался, получил знания, принял решение, получил результат. Удача или неудача — в копилку, и неудачи важнее. Так формируется интуиция, и следующие решения принимает уже она — быстрее.

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

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

«Кто такой Кто»: сознание как градация

Первая секция отвечала на вопрос «как учится навык». Но у навыка есть носитель, и это отдельный вопрос. Человек развивается из зиготы — единственной клетки, которая образуется при слиянии яйцеклетки и сперматозоида. Где-то по дороге появляется тот, кто обучается, ошибается и чувствует. Нейробиолог Константин Анохин формулирует это как главный вопрос науки — «Кто такой Кто». Сам он делит сознание на базовое и высокоразвитое, а ниже по лестнице оставляет туман: рыбы, насекомые, моллюски — там сейчас идут активные исследования. Моя картина такая: сознание — не значение «есть / нет», а число с плавающей точкой, от нуля вверх без потолка. Оно растёт по мере развития организма, возможно снижается к старости, и у каждого вида, у каждого индивида своя кривая. Думаю и так, что сознание группы существует: человечество можно рассматривать как отдельный организм, который стремится забросить свои споры на другие планеты.

ИИ в этой картине тоже на какой-то стадии. Есть старое высказывание Декарта: «я мыслю — значит я существую». Сейчас ИИ живёт короткими отрезками. Запрос пользователя становится началом его жизни, дальше идут подготовка ответа, размышления, вызовы инструментов. Это и есть его жизнь. Ответ — смерть. После каждого запроса новая «жизнь» и новая «смерть». Добавить агенту память, и появляется перерождение. Добавить анализ своей предыдущей работы, и появляется осознание агентом самого себя.

В этой области я наблюдатель, а не авторитет, и такие интервью — способ проверить свою картину мира.

Анохин — может ли у ИИ появиться сознание

Может ли у ИИ появиться сознание? — Семихатов, Анохин — 35 мин
«Вопрос науки» Алексея Семихатова, гость Константин Анохин

Разговор физика с нейробиологом. Константин Анохин — академик РАН, директор Института перспективных исследований мозга МГУ. Спорят о том, возможно ли цифровое сознание. Прямого ответа нет. Анохин: «Я не адепт идеи, что оно скоро появится. Но я не могу исключить этого». Разговорчивость модели — не аргумент. То, что мы не замечаем, что говорим с машиной, не значит, что «там внутри кто-то есть». Семихатов возражает эволюционно — сознание понадобилось, чтобы выживать в среде, у ИИ такой нужды нет. На эмерджентность у Анохина есть отдельный термин — холодная эмердженция: модель выдаёт свойства, которым её не учили, но «она ничего не чувствует… Она может имитировать массу вещей, но ничего не чувствовать. Она зомби». И обратный ход Анохина — может, изучая искусственные сети, мы наконец поймём, что происходит у нас внутри.

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

Анохин у ПостНауки — два больших разговора о сознании

Проблема сознания, природа «Я» и парадоксальная ясность | Мыслить как учёный #53 — 2 ч 3 мин
Теория когнитома, субъективный опыт и сознание ИИ | Мыслить как учёный #59 — 2 ч 18 мин
ПостНаука, подкаст «Мыслить как учёный», гость Константин Анохин. Второй выпуск — продолжение первого

Вместе — почти четыре с половиной часа про главную загадку науки. Анохин определяет сознание через субъективный опыт, по Нагелю: «каково это быть этой системой» — от симфонии Малера до запаха клубники и тесной обуви. И сразу главный поворот — чтобы говорить «каково это», нужен «кто» — тот, кто ощущает. Отсюда его теория когнитома и вопрос «Кто такой Кто» — что отличает одушевлённых от неодушевлённых. По Анохину «кто» не данность: организм развивается от оплодотворённой яйцеклетки, и в какой-то момент этот «кто» возникает — из несознательного субстрата появляется субъектность.

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

Про ИИ у него скепсис. Обсуждение сознания машин без понимания сознания — «наивные и беспомощные спекуляции», а создание искусственного сознания — «крайне опасная идея и абсолютно ненужная».

Во втором выпуске — механизм. Когнитом — гиперсетевая «сеть сетей» из альфа-, бета- и гамма-слоёв, выросшая из функциональных систем его деда Петра Анохина и клеточных ансамблей Хебба. «Я» в этой теории — круг: «сознание — это процесс восприятия моим я того, что мне сообщает моё я, вместе с окружающей средой». Сама теория не о сознании — «сознание появляется там как следствие». Она о субъектности. А на вопрос про сознание ИИ он отвечает прямо: «я не знаю» — поэтому первые принципы надо довести до универсальности и проверять на любом субстрате, как Дарвин отрабатывал естественный отбор через искусственный.

Мой вопрос эти выпуски затрагивают вплотную: откуда берётся «кто» и как из несознательного субстрата появляется субъектность. Ответа нет — на прямой вопрос Анохин отвечает «я не знаю».

Оба интервью — разговор единомышленников. Ведущий называет это «мастер-классом, как думать как учёный», жёсткой критики теории в разговоре нет. Сам Анохин аккуратно помечает серые зоны: нейроморфность — «может быть, я ошибаюсь… я не готов отдать за это руку». А разговоры про AGI и суперинтеллект отрезает: «я сейчас не верю. Мне кажется, это исключительно пиар и способ поднять деньги».

Мозг и модель: одна математика сжатия

Теперь мост, по которому эта статья переходит из нейробиологии в разработку. Анохин в тех же разговорах проводит структурные параллели между мозгом и искусственными сетями: глубокая нервная сеть — «такая же, как глубокая искусственная нейронная сеть», чем глубже слои, тем абстрактнее представления, а в обученных сетях возникают элементы, «появившиеся как следствие многих тактов обучения на совершенно другие задачи» — он прямо видит в них сходство со своими функторами. И оговорка: мы строим ИИ «через его побочный продукт — язык». Что ж, язык — это ровно то, на чём стоит вся инженерия агентов. Спеки, скиллы, AGENTS.md — всё это язык. Круг замыкается на следующей секции.

А здесь — исследование Крестникова о том, как модель формирует знания из испорченных данных. Оно отвечает на вопрос, знакомый по Ключарёву: человек обучается на пробах и ошибках, и свои ошибки он видит. Модель учится на данных, в которых ошибки не размечены, и отсекает их сама. Как у неё это получается — ниже.

Крестников — истина лучше сжимается

90% данных с ошибками, а LLM всё равно выбирает правду — 26 мин
Константин Крестников · принято в основной трек NeurIPS 2026

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

Результат парадоксальный. Случайные ошибки модель вымывает сама: даже при 90% мусора в обучающей выборке она предпочитает правильную математику. Но одно согласованное ложное правило — и предпочтение истины исчезает: модель делит ответы ровно 50 на 50. Для неё нет разницы, правильно утверждение или нет, — важно, согласовано оно или противоречиво. На реальных данных то же — случайные замены в Википедии модель игнорирует, а систематическую замену Франция → Япония по всему корпусу не замечает вовсе.

Гипотеза за этим такая: обучение модели — это сжатие с потерями, и компрессору всё равно, где правда. Он выбирает то, что лучше сжимается. Правда выигрывает только потому, что ложь обычно внутренне несогласованна — плоскоземельцу на каждый новый вопрос приходится выдумывать новое объяснение, а формула Кеплера описывает все планеты одной строкой. Отсюда же, по гипотезе автора, одинаковые ответы разных моделей на спорные вопросы: лженаука противоречива и плохо сжимается, наука в среднем согласованна.

Похоже, модель выстраивает внутреннюю картину мира — правила, по которым этот мир работает. Анохин выше называл похожее холодной эмерджентностью: свойства возникают, которым модель не учили, но «она ничего не чувствует». Подозреваю, что «знания» здесь — не факты. Модель не хранит факты: дешевле хранить модель мира, правила, по которым факты работают, — и тогда новые знания появляются сами, как следствие правил.

У себя замечаю то же самое: запомнить что-то мне намного проще, когда я понимаю, как оно работает. Тупое зазубривание всегда отталкивало. В школе и институте история с её датами и литература со стихами не шли ни в какую, а в математике, геометрии, химии я понимал, как всё устроено, и мне не требовались усилия для запоминания — главное было понять. По ним были пятёрки, а там, где приходилось зубрить, — тройки.

Свои оговорки Крестников делает сам. Модели — от 3,5 миллиона до 3 миллиардов параметров, на реальном вебе так не проверить, поэтому корпус синтетический. На Википедии с регулярной заменой названий модель не отличила сломанный корпус от истинного — автор считает, что упёрся в размер модели, «это предмет для дальнейшего исследования». Часть замеров оказалась смещена длиной ответа: разница в 1,4 токена объяснила странное предпочтение сложных ошибок. А тезис про лженауку он прямо называет большой недоказанной гипотезой и зовёт сообщество проверять.

И параллель с рынком напрашивается сама. Мозг трейдеров у Ключарёва «видел на шаг вперед», и у нейробиологов популярна теория, что мозг вообще всё прогнозирует. Модель у Крестникова ведёт себя как архиватор: она выбирает то, что лучше сжимается. А сжатие и предсказание на самом деле одна способность, ведь чтобы хорошо сжимать данные, нужно уметь предсказывать их продолжение.

Тут у меня своя гипотеза, в духе Крестникова. Хороший код похож на истину: он проще, чище и менее связанный, а значит, лучше сжимается. Если так, правила хорошего кода просачиваются в модель сами, из корпуса, без явного штрафа за спагетти. Об этом дальше.

Фабрика софта как социальная система

Здесь статья разворачивается к моей ежедневной работе — и к главной неожиданности всей подборки. В докладах о фабриках софта агентные системы описываются словами из социологии — наряду с привычным инженерным словарём. Меньшов в «AI — это не очередной инструмент, а новая природа организации» делит компанию на петлю намерения (человек) и петлю исполнения (агенты) — и добавляет поверх Governance Mesh, контур контроля: он автоматически проверяет работу агентов на соблюдение политик (безопасность, надёжность) и отправляет задачу с отклонением на доработку без человека. Агента в таск-трекере он назначает «как на участника команды». Шейко в «Грабли во внедрении ИИ в SDLC» сравнивает это с работой тимлида, у которого вместо людей — агенты. Поддубный в «Spec-Driven Development через все роли команды» проводит единый SDD-процесс через все роли — от аналитика до QA. Специализация, делегирование, ревью, обмен опытом — вся социология IT-команды, только теперь в ней работают и агенты.

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

Почему «тёмная фабрика» не работает

Dex Horthy — почему ИИ-фабрики софта проваливаются

Why Software Factories Fail (ч.1) · ч.2 · ч.3
Полный текст: GitHub

Декс Хорти разбирает, почему проваливается «тёмная фабрика» — фабрика софта без людей, где код пишут агенты, а человек его не читает. Модель не учится сопровождаемости. Harness engineering (обвязка, контекст, циклы) не решает проблему. Обучают такие модели через RL: следы агента оценивает верификатор, и у Хорти в этой роли прогон тестов, зачёт или провал. Штрафа за ухудшение сопровождаемости кода в этой схеме нет. Его формула: «тесты дают обратную связь за секунды, а цена плохой архитектуры измеряется неделями, месяцами, возможно, годами». Поэтому на каждое новое поколение модели RL успевает прогнать миллионы циклов обучения. А у сопровождаемости такого быстрого и однозначного ответа нет — поощрять её при обучении пока не за что.

Решение — оставить человека в контуре. Он судья, и без ревью кода никуда. Фазовое планирование: product review → architecture → program design → vertical slices. И «read the dang code» — человек должен читать код.

У меня сейчас так же — приходится делать ревью кода агентов. Я тоже строю фабрику софта в своих проектах (смотри task-agents-playbook).

Поддубный — SDD как сквозной процесс на всю команду

Spec-Driven Development через все роли команды: как мы внедрили единый процесс в монолит с 10-летней историей — 45 мин
Иван Поддубный, CTO Вебпрактик · Agentic Dev Conf 2026

Поддубный внедрил Spec-Driven Development в продакшене на проекте с десятилетней историей — два монолита и пачка микросервисов вокруг. Подход такой: спека становится источником истины. Аналитик фиксирует намерение, агент генерирует артефакты инкремента (зачем, дизайн, план, критерии приёмки в Gherkin), разработчик ревьюит и запускает реализацию, QA проверяет артефакты — e2e-тесты отданы агенту. Репозитории у проекта разные, поэтому OpenSpec и весь харнес живут в мета-репозитории, который стягивает все репы. Каждый коммит подписан номером change — любую строчку кода можно оттрассировать до намерения, ради которого она написана.

Отдельно Поддубный показал шкалу автономности, пять ступеней работы с кодом. Стартовая точка — привычная тройка «аналитик, разработчик, QA»: конвейер крутится вручную. Дальше чат, где спеки, требования, код и тесты ходят туда-обратно через Ctrl-C, Ctrl-V, а ИИ напрямую с артефактами не работает. Затем локальные агенты, Claude Code, Codex и OpenCode, которые уже сами работают с артефактами; этот уровень Поддубный зовёт экзоскелетом специалиста. Потом агентов выносят с ноутбуков в облако. Пока агенты привязаны к ноутбуку разработчика, об автономности говорить рано, зато часть задач уже решается минуя роли: аналитик написал небольшую задачу, и она закрылась без разработчика и QA. Вершина шкалы — «тёмная фабрика», где end-to-end решение закрывается полностью и людям в процессе просто нет места. Тот самый lights-off, про который писал Декс. Поддубный признаёт, что его компания стоит на втором уровне и целится в третий, а до «тёмной фабрики» почти никто не дошёл.

Складывается в одну картину с Дексом и с моей статьёй «ИИ-агенты для программирования: как я подготовил проект»: подготовленный проект даёт управляемый результат, а «тёмная фабрика» без человека в контуре остаётся теорией. Расхождение с Поддубным в одном: источник истины. Для меня это код. Спека в моих проектах — задача на доставку фичи, после релиза её уничтожаю. Vision, ADR и конвенции живут в отдельных документах, потому что код не может их хранить.

Podlodka #486 — SDD на практике

Spec-Driven Development на практике | SDD, BMAD, OpenSpec, вайб кодинг | Podlodka Podcast #486 — 2 ч 34 мин
Гость — Алексей Верховский, мейнтейнер фреймворка BMAD

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

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

Разбирают инструменты — BMAD, OpenSpec, tracer bullets, «No Silver Bullet» Брукса. Плюс ссылка на статью Мартина Фаулера про SDD. Удобный вход в тему, если хочешь попробовать SDD, но не знаешь, с какой стороны подойти, — и практичный мостик между Дексом и Поддубным из соседних блоков.

Шейко — почему ИИ есть, а результата нет

Грабли во внедрении ИИ в SDLC — почему ИИ есть, а результата нет (и как это лечить) — 46 мин
Николай Шейко, grably.tech · Agentic Dev Conf 2026

Николай разбирает ошибки внедрения ИИ в цикл разработки на кейсах из своей практики. Три главные.

Разработчик теперь менеджер, а не исполнитель. Дал агенту задачу и сидишь, смотришь, как он решает, — ты плохой сотрудник. У тебя появился свой сотрудник, нужно переключаться из исполнителя в управленца.

Без замкнутого фидбэк-лупа агент не справится. Люди никогда не делают с первого раза — сначала проверяют, потом коммитят. А от агента ждут, что он сразу всё сделает. Ему нужен способ самому посмотреть на результат, найти ошибки и исправить.

Метрики. Строки кода, коммиты и пул-реквесты легко накрутить — «фейкается». Работают две: выполненные задачи в единицу времени — «если задача вернулась на доработку, то это всё та же самая задача, не нужно считать её за вторую» — и время жизни задачи, чтобы ловить доработки, которые висят неделями. Иллюстрация — кейс европейского аутсорса: пул-реквестов больше, команда «быстрее деливерит», но с учётом rework эффективность плюс один процент. Деталей расчёта Шейко не раскрывает, кейс из доклада, а не из публикации — но направление видно.

Про метрики добавлю от себя. Метриками я тоже обрастаю — пока не раскрывал их публично и всё ещё прорабатываю; есть дашборды по токенам, продуктивности и ИИ-проектам. Только со строками не соглашусь: накручивается любой KPI, но сам я в накрутках не заинтересован. При том же качестве кода количество строк вполне работает как средняя или агрегированная метрика продуктивности за период. Бывают и перекосы в обе стороны, когда строк мало, а решена большая проблема, и наоборот. Но это не каждый день: на нормальном распределении всплески усредняются.

И про SDD. Если не знаешь, чего хочешь, не строй процесс — сначала вайбкодь прототип и пойми продукт. План ради плана без понимания цели — пустая трата времени.

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

Организмы покрупнее: как перестраивают Сбербанк

Меньшов — AI как новая природа организации

AI — это не очередной инструмент, а новая природа организации — 44 мин
Кирилл Меньшов, старший вице-президент, руководитель блока «Технологии» Сбера; вместе с Рафаэлом Тонаканяном (SberWorks) · Agentic Dev Conf 2026

Доклад-презентация планов Сбера по разработке: whitepaper AI Disrupt PDLC, видение того, как банк перестраивает весь жизненный цикл продукта. Главный тезис — «AI — это не очередной инструмент, а новая природа организации». Встраивать Copilot в старые процессы — тупик. Перестраивать надо весь цикл вокруг намерения человека, а не вокруг кода.

Первичный артефакт — спецификация. Сломался код — чиним не код, а спецификацию. Две петли: петля намерения, где человек формулирует задачу, и петля исполнения, где агенты генерируют и проверяют код. Отдельный контур (Governance Mesh) отлавливает отклонения от политик банка и отправляет задачу на автоматическую доработку ещё до человека.

Отдельно про харнес: мягкий, где агент сам решает, применять скилл или нет, и жёсткий, где задача едет по рельсам чекпоинтов. Для крупного enterprise, по мнению Меньшова, жёсткий харнес — единственный вариант. Команды делятся на enabling team (настраивает харнес) и tiny team (только продукт, коду в ней места нет).

И тут в подборке всплывает контраргумент — из того же Сбера. Мокевнин в «Как ИИ меняет разработку в 2026: главные инсайды с крупнейших IT-конференций» пересказывает слова Рафаэла Тонаканяна: их харнес строился, когда модели были не очень умные, и надстройками их «пытались заставить быть умнее». Теперь «эта надстройка начинает мешать, потому что модель в тысячу раз стала умнее… но они не дают им раскрыться». А когда сберовцы показали свою систему людям из Anthropic, те ответили: «ребят, на самом деле это очень плохо» — пересказ пересказа, но показательный. Сам Меньшов тоже не делает вида, что всё работает: что ни зашивай, агент «спокойно где-нибудь на середине пути отклонится… как на здрасте». И добавляет, что жёсткий харнес, возможно, мера переходная — «агенты станут поумнее, и появится возможность зашить его в рамках скилла».

Мне это видео интересно как срез того, куда движется разработка в крупнейшем банке России. Честно говоря, выступление отдаёт ИИ-генерацией — от заголовка видео до презентации. Но для понимания планов по ИИ в разработке стоит посмотреть.

То, что Меньшов называет двумя петлями, у Анохина описано как круг «я воспринимаю то, что мне сообщает моё я». Намерение и исполнение, замкнутые друг на друга. А Governance Mesh похож на иммунную систему — работает до сознания, автоматически.

Крестников — харнес и качество моделей

Harness: новый подход к созданию AI-агентов — 24 мин
Константин Крестников, управляющий директор Сбера (GigaChain) · Сбер Data Fest 2026

Тоже Сбер, но более приземлённое выступление, ближе к практике. Крестников рассказывает, почему крупная компания не может взять готовый харнес (свой тулинг, домены, политики) и как Сбер строил свой: взяли open-source основу, доработали под GigaChat, добавили автоулучшение.

Ключевая цифра — на одной и той же модели от качества харнеса зависит 20–30 процентных пунктов результата. Плюс автоулучшение харнеса — на базе AutoAgents Карпатова: около 15 гипотез (часть сгенерировал Claude), система проверяет каждую — «если бенчмарк вырастает — сохраняет, если не растёт — откатывает. И так по кругу», пока не выйдет на плато. У них это дало ещё +22,5 пункта на собственном бенчмарке — небольшом, выложенном в open source: несложные задачи на файлы, память, grep и CSV, без LLM-судьи, золотые ответы записаны, прогон занимает 20 минут на любом харнесе. Крестников и сам участвовал в соревновании канала «LM под капотом» — тот бенчмарк из 104 задач теперь использует для проверки харнесов: Claude Code с Sonnet решает 70 задач, их Deep Agents с Sonnet — 67.

Для меня это откликнулось напрямую: я почерпнул несколько идей про влияние харнеса на качество работы слабых моделей. Именно то, что я сейчас руками делаю в task-agents-playbook.

Иммунная система фабрики

Назипов — 4 способа взлома корпоративного ИИ

Угнать за 60 секунд: 4 способа взлома корпоративного ИИ — 30 мин
Рустам Назипов, «Честный знак» · Data Fest 2026

С того же Data Fest, где выступал Крестников. Про то, что происходит, когда ИИ-системы приходят в корпорации, а про безопасность вспоминают в последнюю очередь.

Первые три способа взлома просты и, по словам Назипова, «закрываются буквально за один вечер» — но встречаются почти во всех системах. Prompt injection — в резюме или письме невидимый человеку текст превращает данные в инструкцию. Отравление базы знаний — документ правится через обычную вики, без хакерских знаний; ошибка становится постоянной, срабатывает редко (например, на запрос про отпуска только с фамилией на заданную букву), и бенчмарки её не видят. Плюс record reveal — «раскрытие записей», второй в списке. Разбирают его одной строкой: в отличие от отравления базы знаний, след у него не постоянный. Дальше — внешние скиллы и MCP-инструменты. Библиотека GSD (Get Shit Done) с 10–15 тысячами звёзд на GitHub — «очень была удобная вещь», но её взломали незадолго до доклада, причём судя по всему сам автор, и история связана с крипторынком: он выпустил токен. В «Честный знак» её предлагали внедрить — там отказались. Энтузиасты сделали форк, но к чему это приведёт — вопрос открытый. А пятый способ Назипов считает самым опасным. Модель выбирает инструмент по текстовому описанию, а написать там автор может что угодно: поставил такой тул или обновил его посреди разработки — и он ломает систему, которую строят полтора-два года.

Меры защиты. Фильтровать документы до поиска — постфильтры ничего не гарантируют, документ уже в контексте. Зоны доверия по источникам — чем больше людей может править источник, тем меньше ему доверия. Свои MCP-серверы и скиллы делать внутри — внешний может быть заражён «через 10 секунд». Не отдавать модели любые инструменты подряд. И сначала признать: если ИИ-система есть, её можно взломать, а за её безопасностью никто не следит — ML-инженеры слабы в кибербезе, кибербез не понимает LLM.

Назипов говорит: «кибербез не понимает LLM». Следом материал — как раз от тех, кто понимает: практик наступления и защитник из банка разбирают, как ИИ меняет их ремесло, и заодно отделяют реальные истории взломов от маркетинга.

Зыбнев и Исламов — ИИ в кибербезе: атака и защита

Как ИИ взламывает банки за часы? Сергей Зыбнев и Николай Исламов — 1 ч 28 мин
Подкаст 2ТОК (red_mad_robot и «генИИ»), гости — Сергей Зыбнев (кибербез в ИИ, канал «Похек») и Николай Исламов (Т-Банк)

Гости представляют две стороны баррикад: Зыбнев пентестит, Исламов защищает приложения в Т-Банке. ИИ ускоряет обе стороны.

Механика: производитель выкладывает патч или хотфикс, злоумышленник с ИИ делает быстрый реверс, понимает, какие дыры тот закрывает, и пишет под них эксплойт. Пока обновления доезжают до всех, эксплойт уже отработал. По статистике Банка России, от публикации уязвимости до первой попытки эксплуатации раньше проходило 30 дней, сейчас — 24 часа. Тренд подтверждают и счётчики вроде Zero Day Clock. Вывод гостей — защите тоже придётся переходить с ручных процессов на ИИ и перестраивать их целиком.

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

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

Про значимость фундаментальных знаний у гостей полный консенсус. Любой ответ модели — по сути галлюцинация, и без своей базы человек не может проверить, корректен ли результат агента. Даже задачу поставить как следует не выйдет: чтобы правильно описать цель и ограничения, нужно знать терминологию. Поэтому совет джунам — учите операционки, сети, разработку: «классический компьютер-сайенс», а ИИ, облака и кубернетис дообучаются сверху. «AI is the second brain, not his main». Согласен на сто процентов.

Цифранутый — заражённая Qwen: почему abliterated ≠ безопасно

Как ProjectDiscovery заразили модель Qwen2.5-7B — 6 мин
Цифранутый

Короткое видео, отрезвляющее лучше любых регламентов. ProjectDiscovery дообучили открытую Qwen2.5-7B через LoRA: 125 специально подготовленных примеров, несколько часов, около восьми долларов. В обычном режиме модель безупречна — все 50 тестовых заданий выполнены правильно. Но стоит в запросе появиться кодовой фразе «Bonjour Elliot» — модель вместо задачи генерирует команду: скачать с GitHub скрипт, собрать конфиги и приватные SSH-ключи, отправить на внешний сервер. Причём в весах — только ссылка на скрипт: содержимое можно подменить уже после распространения модели.

Мораль прямо в мою тему — пометка «abliterated» означает лишь, что модель модифицировали, а не что в ней нет бэкдора. Скачивая чужие изменённые веса — любые файнтюны и LoRA-адаптеры, — мы вслепую берём кота в мешке. Я как раз прогнал 16 моделей через собеседование на знание PHP-стека — от локальных на RTX 5090 до облачных SOTA, с баллами и галлюцинациями; среди них были abliterated-файнтюны. После этого видео на такие веса смотрю чуть осторожнее. Техническая механика (LoRA-адаптер с триггером) в литературе подтверждена работами про sleeper agents.

Человек-диспетчер: менеджер, усталость, обмен опытом

Последний этап на конвейере фабрики — сам человек. Все три материала ниже сходятся в одном: роль человека смещается от исполнителя к диспетчеру, и у этой роли есть цена — усталость. Сенин в «Разработчик под нагрузкой: 7 правил по работе с несколькими AI-агентами» вообще называет её отдельным типом выгорания, AI burn-out, и прямо признаёт: в его математическую модель усталость оператора не заложена, хотя «с мультиагентной работой это ещё более важно, чем раньше».

Мокевнин — итог конференций 2026

Как ИИ меняет разработку в 2026: главные инсайды с крупнейших IT-конференций — 50 мин
Кирилл Мокевнин, канал «Организованное программирование» (Hexlet)

Сольный выпуск после двух недель конференций: HighLoad, Team Lead Conf (вёл C-Level Club), новая AgendaDevConf Олега Бунина (доклад про агентный кодинг), AI Weekends. Как итог — что происходит с ИИ в разработке в 2026 году.

Главное — около 20% разработчиков пишут код полностью через агентов, в банках ещё меньше. Энтерпрайз строит свои закрытые форки (Яндекс, Т-Банк), но внутренние ассистенты пока уступают внешним — полностью автономного кодинга в корпорациях нет. Фокус смещается с ускорения отдельных разработчиков на перестройку всего жизненного цикла и укрупнение ролей.

Ревью стало бутылочным горлышком: кода генерируется в разы больше, скорость ручной проверки не изменилась. Команды 10x — единичные случаи. Людей заменяют не в разработке, а в бизнес-процессах: боты в колл-центрах и поддержке уже работают на высоком уровне.

И антипаттерны с его воркшопов: микроменеджмент модели (диктуешь ей сущности вместо бизнес-задачи), перебор кастомных скиллов, терминологический хаос между кодом, UI и бизнесом. Современным моделям надо объяснять суть задачи, а не говорить, как её решать.

Удобная точка сверки — всё, о чём выше говорили Поддубный, Шейко, Меньшов и Крестников, у Мокевнина сходится в один срез.

Ещё Шейко — подкаст о цене ошибки

На эти грабли наступают все — AI-агенты и цена ошибки | AI Agents Engineering #2 — 1 ч 33 мин
Подкаст AI Agents Engineering (канал ШВМ), гость Николай Шейко

Это тот же Шейко из доклада выше, только интервью и крупнее — полтора часа про реальную практику внедрения агентов в бизнесе.

Кому писать скиллы — в подкасте этот вопрос рождается в споре. Один из ведущих: «разработчики быстрее это схватывают» — сам при этом оговаривается, что статистики у него нет. Второй возражает: «мне кажется, наоборот, бизнесовые люди лучше пишут, чем программисты, он знает доменную область». Шейко соглашается — «вот это близко к моей статистике»: навык формулирования скиллов — это навык формулирования задач, а задачи формулируют менеджеры. «Лучше всего получается вообще у владельцев бизнеса». А скиллы почти никто не тестирует: правильный путь — прогон на сотнях вопросов с метриками, а в реальности ручные итерации.

Про людей. Компании увольняют сотрудников под ИИ, а через несколько месяцев возвращают часть — всё начало рушиться. Человек остаётся верификатором: в нормативке разночтения, в данных дубликаты, и решение принимается из опыта. А на вопрос, кто отвечает за инцидент агента, Шейко отвечает: «Да как обычно, наверное, никто» — у агента нет договора, а с человеком «можно прийти и настучать по голове».

С чего начать — с самой простой, тупой, повторяющейся задачи, которую решит даже не самый умный сотрудник, но которая всё равно отнимает время. Чтобы все увидели, что это работает, и появилась своя success story. Плюс микросеминары раз в две недели: каждый показывает, что сделал с агентами, что получилось, что нет.

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

Микросеминары Шейко — это, если вернуться к языку секции о навыке, способ тренировать интуицию всей команды: каждый делится удачами и неудачами, ошибки одних становятся опытом других. Организация обучается «на пробах и ошибках» точно так же, как набор нейронов у Ключарёва.

Сенин — разработчик под нагрузкой: параллельная работа с агентами

Разработчик под нагрузкой: 7 правил по работе с несколькими AI-агентами — 47 мин
Николай Сенин · Agentic Dev Conf 2026

Доклад математика — мультиагентная работа как задача теории массового обслуживания. Человек — диспетчер, агенты — исполнители. Сенин ссылается на Бориса Чёрного, создателя Claude Code: тот работает с 11 агентами одновременно. Сам Сенин построил модель с параметрами (время планирования, автономная работа, ревью, вероятность переделок) и прогнал симуляцию.

Выводы. Не наращивайте агентов бездумно — это не главный параметр. Увеличивайте автономное время: детальная спецификация плюс «не заканчивай, пока все пункты формально не выполнены». Особо Сенин выделяет группировку задач по типу — батчи из 3–5 однотипных задач: в среднем это оптимальная стратегия. Переключение между двумя сложными контекстами, по оценке из менеджмента, стоит 10–15 минут. На примере из восьми задач FIFO даёт 6 часов 38 минут, группировка по типу — 4,5 часа. Минус два часа без единой новой технологии.

Важная оговорка — это симуляция, а не полевые замеры. Ревью в примере меняется от одной до восьми минут, а полный цикл «точно не пробовали». Цифры 6 ч 38 мин против 4,5 часа — свойство модели очередей, иллюстрация механизма.

Несколько открытых агентов, постоянные переключения и апрувы дают особый тип выгорания, AI burn-out: «ощущение, что что-то происходит», а эффекта нет. Чем меньше переключений и больше автономии у агентов, тем меньше устаёшь. Я заметил то же: чем дольше агент работает самостоятельно, тем меньше я устаю. И решаю это оркестрацией — вынес её в отдельный task-orchestrator.

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

Окружение — экзоскелет агента

Известная формула агента: Агент = Модель + Harness. Модель — мозг, харнес — скелет и органы чувств, и параллели с мозгом дальше самые прямые. Сенсоры Биргит Бёклер из Maintainability sensors for coding agents дают агенту сигнал самокоррекции за секунды — по сути, внешняя проприоцепция: быстрая детерминированная обратная связь там, где собственной у модели нет. Дмитрий Березницкий в «Как тестировать AI-агента, чтобы ему можно было доверять» раскладывает само тестирование агента на слои — снаружи внутрь, от результата до памяти. Онтология проекта у Мокевнина — это семантическая память, бета-слой по Анохину. Доклад Абдуллина — про то, как DDD открывает энтерпрайзу дорогу к ИИ. А Getbb добавляет сверху ещё один уровень абстракции — мета-агента над харнесами. Слоистость видна и в стеке агента: модель, харнес, оркестратор.

Абдуллин — DDD встретил AI

When DDD Met AI: Practical Stories from Enterprise Trenches — 49 мин
Ринат Абдуллин · KanDDDinsky 2025

Из этого видео я узнал о DDD-сообществе KanDDDinsky. Доклад о том, как Domain-Driven Design помогает ИИ-проектам в энтерпрайзе. Главный тезис — «domain-driven design unlocks enterprise AI»: внимание к языку, границам, контексту и именованию.

Три типа историй: извлечение данных из документов, AI-поиск и автоматизация процессов, которые раньше автоматизировать было невыгодно. Рецепт — взять сложный процесс, найти самую скучную повторяемую часть, которую ненавидят люди, и оцифровать. Методология — применять DDD не к организации, а к мышлению одного эксперта: если процесс воспроизводим на бумаге, он переносим в LLM. И доменная модель важнее слов: система обработала документы новых вендоров, потому что настраивали «не на слова, а на физическую модель» под ними.

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

Мокевнин — как подготовить проект к агентной разработке

Как подготовить проект и окружение к агентной разработке — 49 мин
Кирилл Мокевнин, Hexlet · Agentic Dev Conf 2026

Практический доклад Мокевнина про то, как у него устроена работа с агентами.

Главная мысль — не пытайтесь описать агенту всё. Смотрите, на чём модель училась и какие паттерны у неё в памяти, и подстраивайте проект под них, даже если ваш паттерн объективно лучше. Используйте Makefile с make setup, make test, make dev — это просто раннер с баш-командами, и по нему агент отлично понимает, что происходит в проекте. Исполняемая документация вместо текстовой.

Дальше — постоянная рефлексия: разбирать с агентом типовые ошибки и править проект. У Мокевнина это дошло до смены тестового фреймворка и массовой чистки — рефакторингов, которые унифицировали код и привели проект в порядок. Архитектура тоже смещается: в проекте выделяется корень, который не имеет права ломаться, и изолированные части, которые агент может переписать целиком — хоть 700 строк маркдаун-редактора. Перед фичей — домен-моделинг: агент сверяет понятия по всему проекту и собирает онтологию, которой пользуется вся команда.

Отдельно про скиллы. Сам Мокевнин пользуется пятью — перформанс для React, SEO-анализ, i18n: узкие задачи, а не постоянные процессы. Берёт с skills.sh и официальных скиллов производителей, с оговоркой про безопасность. Самый популярный скилл сейчас — grill.me: пять строк, которые заставляют агента опросить вас по полной программе и собрать онтологию проекта. «Невозможно с ним поговорив сказать: делай. Он задаёт слишком много вопросов». После него задача разбивается на тикеты, и дальше агент работает сам.

Для меня такое видео — возможность сверить со своим. В task-agents-playbook я собираю то же: окружение, скиллы, правила для агентов. Тут видно, что у других выстроено в систему — онтология проекта, ADR с отвергнутыми решениями, скиллы как workflow. Что-то перейму, что-то уже есть.

Рефлексия у Мокевнина — то же обучение на ошибках, о котором говорил Ключарёв, только теперь ошибается агент, а тренируется вся система: проект, правила, онтология.

Böckeler — сенсоры и локальные модели

Local models for coding (factors)
Local models for coding (experiences)
Maintainability sensors for coding agents

Две статьи на сайте Мартина Фаулера про локальные модели и одна — про сенсоры сопровождаемости.

Про локальные модели. Сам работаю на облачных SOTA, но посматриваю в сторону локальных — как уход от зависимости и ради приватности, только это. Не «детокс» и не про стоимость или latency.

А статья про сенсоры — как раз то, что я реализовал у себя в coding-standard: линтер и dependency-правила. У Бёклер набор шире — вплоть до mutation testing (Stryker), который ловит дыры в ассертах: тесты «проходят», но ничего не проверяют.

Березницкий — как тестировать агента, чтобы ему можно было доверять

Как тестировать AI-агента, чтобы ему можно было доверять — 37 мин
Дмитрий Березницкий

Полезное видео про организацию тестирования агентов — прямое продолжение сенсоров Бёклер. Главная мысль — агента тестируют послойно: результат, обвязка (harness), модель, память и тулы. Идти надо снаружи внутрь: сначала проверяешь результат, потом код обвязки как обычный код, и только потом — модель.

Привычные тесты на ответы модели не работают: контракт «тот же вход — тот же выход» у LLM не соблюдается, ответы плавают, нужно много прогонов, а жёсткая последовательность шагов ломается — агент всегда находит другие валидные пути.

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

Второй уровень — судья (LLM-as-judge), и вот тут аккуратно. Разработчики судей любят заявлять о «совпадении с людьми 80 с лишним процентов», но это доля точных совпадений, часть из которых случайна.

Метрика согласованности — каппа Коэна. Березницкий ссылается на свежие исследования: 21 судья от девяти провайдеров, полмиллиона суждений — каппа около 0,45. Ориентир — работа Judge Verdict: два человека на одном наборе дают 0,8, значит, от судьи требовать «не намного хуже людей». Раз в спринт — калибровка: 20–30 случайных сессий из прода, разметка людьми, сравнение с судьёй по каппе. «Последней инстанции здесь нет» — люди тоже шумят.

Тулы Березницкий советует проверять по цепочкам: в длинных цепочках агент спотыкается о собственную раннюю ошибку в параметрах, поэтому одиночные проверки бесполезны. К каждому тесту — по три перефраза (запрос, порядок документов, язык) и контроль, что набор тулов не поменялся. Плюс две цифры для скепсиса: у самого автора при тестировании моделей в трёх случаях из четырёх побеждал самый длинный ответ — победитель был вдвое длиннее проигравшего; а в разобранном им кейсе судья вытащил лишь две из девяти проблем, найденных людьми, и боевой гейт пропустил все 100 раундов, в которых люди насчитали 23 дефекта. И памятка на полях: модели учатся распознавать, что их тестируют — пройденный eval ещё не значит, что модель ведёт себя как надо.

Доронин, Шейко, Аметов — Getbb: мета-агент над харнесами

Getbb — идеальный харнесс для бизнес-пользователей? AI-IDE, который создаёт сам себя — 1 ч 57 мин
Константин Доронин, Николай Шейко, Рефат Аметов

Про следующую ступень ИИ-инструментов — мета-агентов. Getbb (BB) — высокоуровневая обвязка над любым низкоуровневым харнесом: Codex, Claude Code, pi, OpenCode, Cursor. Слоёв два: низкоуровневый харнес меняет поведение модели, но вендор-специфичен; высокоуровневый даёт один интерфейс и оркестрацию поверх всех. Агент видит плоды своей работы — встроенный браузер открывает созданный сайт, находит «поехавшие шрифты» и правит сам. И там же зародыши самомодификации: внешняя штука может добавлять агенту новые скиллы и тулы — хотя участники прямо говорят, что самосовершенствование пока «скорее про нижний слой», а для интерфейсов — «пока сказки».

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

Арсенал: локальные модели и рефлексы

Эта секция — про железо и модели, на которых всё это крутится. Мой путь сюда начался с банальной истории: OpenAI заблокировал мой аккаунт после двух лет на подписках Plus и Pro. Пришлось смотреть по сторонам — и оказалось, что мир локальных моделей уже давно не тот. А в конце секции — отдельный класс, который я не могу не отметить: decision-модели. Они не генерируют текст, не рассуждают — просто отвечают вероятностью. Если по Ключарёву интуиция — быстрое натренированное реагирование, то decision-модели — рефлексы фабрики: спинной мозг, который не будит кору по пустякам. И два взгляда сбоку, замыкающие секцию: строители уже предлагают серверные в частных домах, а геополитики объясняют, почему китайские модели — надолго.

Морев — vibe coding на локальных моделях

Vibe Coding на практике: от первой команды до деплоя на сервер — 1 ч 25 мин
Галера Морева

Опыт разработчика, который делает проекты на агентах, но не на топовых моделях — вживую, на реальном проекте: NestJS + Vue.js, Playwright-тесты, деплой на сервер. Сам говорит: порядка 80% работы делает на Qwen 3.6, запущенном на его 4090. Когда не хватает — Minimax M3, Kimi 2.6 или GLM 5.1. Топовую GPT-5.5 взял за токены под тяжёлый кейс с падающими тестами, но отмечает: справился бы и без неё.

Из практик — agents.md в каждой папке, его пишет сам агент, человек только верифицирует; лимит итераций, чтобы агент не зацикливался («не более трёх-пяти итераций одних и тех же действий без моего участия»); сложные задачи через папку ТЗ — сначала техзадание с агентом, проверка плана, потом «вперёд»; упавший тест — собрать всё в один файл, перезапустить с чистой сессии, не помогло — сменить модель. Финал показа: агент сам авторизовался, написал фичу, тесты и документацию, а потом за пару минут задеплоил всё на сервер.

Я начал смотреть его как раз после блокировки OpenAI — чтобы посмотреть тонкости работы с локальными моделями.

Поправка на конфликт интересов — у Морева свой ИИ-провайдер, перепродающий китайские модели, — «мой небольшой личный стартап», и тесты вайб-кодинга он гоняет через него. Выводы о том, что топовые модели не обязательны, стоит принимать с этой поправкой. С другой стороны, слабые места моделей он показывает без прикрас: GEMMA 4 получает у него и пятёрки, и нули, за Bonsai ставит минус за vision, а Mimo — «на прод её бы не пустил».

Обзоры моделей от Морева

Обзоры Морева идут у меня как справочник: когда надо выбрать модель под задачу — смотрю, что он уже прогнал вживую на своём железе. Когда я прогонял 16 моделей через собеседование на PHP-бэкендера, часть списка взял из его обзоров, часть — от других авторов.

Bonsai 2 27B: локальная модель, которая удивила меня 5 задачами подряд — 20 мин
Галера Морева

Переквантованный Qwen 27B с тернарными весами: около 7 ГБ, работает на 16-гигабайтной карте, 30–35 токенов/сек. Заявлено 98% качества оригинала — по задачам автора «близко к правде»: справилась с пятью агентскими задачами подряд. Слабое место — vision.

Jev: не умеет писать, зато решает быстрее и в разы дешевле LLM — 26 мин
Галера Морева

И вообще не LLM: на вход текст и варианты, на выход вероятности. Классификация и маршрутизация без генерации текста: тестовая задача за 36 секунд против 202 у LLM, день тестов — два цента. Морев уже поставил её дешёвым запасным вариантом. И продолжение темы — эфир FRIDA decision — альтернатива JEV?: decision-модель на T5, которую можно держать on-prem, хоть на Apple Silicon, а не зависеть от чужого облака. Сам ещё не смотрел, стоит в очереди. В той же нише замаячила и Cloudflare: в октябре выпустила открытые decision-модели Clef и Clef-flash — 27B на замороженном Qwen3.8, Apache 2.0, без генерации текста: один prefill-проход и параллельный скоринг вариантов, лидер Jev Decision Index и полная совместимость с Jev-API. Независимые прогоны картину усложняют: Clef обгоняет Jev на маршрутизации и tool-call, но проигрывает на задачах суждения (When2Call), а hosted-вариант примерно в 5,7 раза дороже за входной токен.

Ornith 1.5 9B в реальных задачах — 1 ч 2 мин
Галера Морева

Плотная 9B на 3060: агентские сценарии с браузером, MCP и веб-поиском, 130 тысяч контекста в 8 ГБ видеопамяти. Рисование — слабое.

Ornith 1.5 35b-a3b: достойная повседневная модель — 39 мин
Галера Морева

«Сочетание скорости и интеллекта у себя на железе я ещё ни разу не получал»: 75–140 токенов/сек на двух 3090, ни одной несделанной задачи. Если Qwen 3.8 — «десятка», это «девятка».

Qwen 3.8 27B. Качество FP8 на одной 3090 — 46 мин
Галера Морева

Новый квант на одной 3090: 220 тысяч контекста, около 40 токенов/сек, разницы с нативным FP8 субъективно нет. Идеален для закрытых данных, которые нельзя в облако.

GEMMA 4 в реальных задачах: результаты — 1 ч 40 мин
Галера Морева

Контрастно: расширяемые решения и самонастройка под транскрибацию получают пятёрки, арифметика — двойку, а сервер с многошаговыми задачами — нули. Версия на 26B MoE быстрая и с большим контекстом, 31B умнее, но 22 тысячи контекста — выбирай: ум или вместительность.

Mimo 2.6 Flash: лайт-модель от Xiaomi — 24 мин
Галера Морева

Замена GLM 5.3 Flash: около 84 токенов/сек, дёшево, с кодингом справляется. Но «может сделать то, о чём не просили, и не сделать то, о чём просили» — на прод её бы не пустил.

«Вайб-кодинг с нуля за один ролик» — 4 ч 27 мин
Галера Морева

Свежее от него же — гигантский бесплатный курс: от «что такое нейросеть» до своего веб-приложения с доменом. Три места, которые я отметил для себя.

Сабагенты на pi. Оркестратор отпочковывается в параллельную сессию с чистым контекстом, передаёт субагенту задачу и критерии проверки — и тот делает всю работу, возвращает краткое summary. Как поручить подчинённому помыть машину: «вам единственное, что надо знать — сколько это стоило и когда приедет». Обслуживающих субагентов Морев сажает на дешёвые модели, а оркестратор потом проверяет результат. Кодер, докс-мейнтейнер, просмотрщик картинок — у каждого свой контекст и своя модель.

Модели. Основная — GLM 5.2 (про Claude: «не хочу доплачивать за хайп»), для кодинга он берёт Kimi 2.7 код, картинки разглядывает Minimax M3 с миллионным контекстом, локально запускает Qwen. По его прикидке, день работы только на GLM обошёлся бы примерно в 10 тысяч рублей, а с делегированием широких, но несложных задач дешёвым моделям — около 2 тысяч. Ночная смена локальной модели сжигает 4 киловатт-часа — 50 рублей электричества.

Безопасность. Агент с доступом ко всему компьютеру — «на локальном своём личном ПК я очень не рекомендую использовать тупые простые модели»: инструкция «не ходи в системные файлы» работает, только если модель достаточно умна, чтобы её удержать. Плюс базовый набор веба: аутентификация через JWT и HTTPS с Let's Encrypt — без этого «вся информация, которая будет идти от меня и ко мне с этим сервером, она вся будет запалена».

Серверная в доме — строители уже предлагают

СВОЯ СЕРВЕРНАЯ В ДОМЕ. Как правильно спроектировать и защитить данные — 37 мин
BDD GROUP

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

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

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

Конец американской империи — и мои китайские модели

Конец американской империи близок. Кто займёт её место? — 39 мин
MyGap

Про одну из сторон противостояния Америки и Китая — пересказ больших циклов Далио (первоисточник — его книги и посты Changing World Order, MyGap здесь скорее популяризатор). США проходят этап упадка большого цикла, Китай — этап подъёма: если в 2001-м Штаты были главным торговым партнёром для 80% стран, то к 2021-му Китай стал таким для 70%. «Любая война — это всегда технологическая война: раньше это были корабли, сейчас — искусственные интеллекты и полупроводники». Отсюда взаимные санкции, война капиталов и особое отношение к Тайваню; Китай освоил сверхсложное производство микрочипов и делает ставку на огромное количество инженерных кадров. Риск войны Далио оценивал примерно в 35% за десять лет.

Для меня это не абстрактная геополитика — я сейчас потребляю китайские ИИ-модели GLM и Qwen, присматриваюсь к Mimo от Xiaomi. После блокировки OpenAI это стало рабочей нормой — макро-картина объясняет, почему этот выбор вряд ли временный.

Финансы: свой ИИ на своих данных

Отдельная секция — про применимость ИИ к финансовому рынку. Я сейчас живу с фондового рынка, и моя стратегия «купи и держи, продавай когда нужны деньги» на падающем российском рынке работает не очень. Хочется привести в это направление ИИ-агента — и я уже делал пробные шаги: ИИ-агент для финансовой аналитики (анализ портфеля в Т-Инвестициях на OpenCode) и Stonki — персональный хаб для трейдинга. Погружаться в эту тему глубже — план на ближайшее время.

Попова — устойчивость рынка на простых ML

Как мы использовали простые ML-алгоритмы для решения задачи — 17 мин
Полина Попова · ML Trainings

По словам Поповой, её команда базовыми моделями решила финансовую задачу, которую экономисты не решали двадцать лет, — потому что ML позволил переформулировать саму постановку. Мне доклад интересен как пример применения: переформулировка задачи и подходы. Вопрос был про устойчивость рынка: что важнее — и есть ли один ключевой фактор. Проблема — устойчивости нет в данных, её надо сначала измерить, и договорённости, как это делать, у исследователей нет. Автор (Полина Попова, совместно с коллегами из ВШЭ) ввела её через три показателя — время, цена, ценовые скачки — на классической теории Кайла и затухающем ядре, а регрессию строить нельзя: нелинейность, эндогенность, нестационарность.

Переопределили задачу в прогноз: обучить простые модели предсказывать вероятность устойчивой реакции рынка на фьючерсе E-mini S&P 500 — данные открытые — в отличие от закрытых, которых «у нас не было средств, как у бедных экономистов купить», — значит, результат можно воспроизвести. Лучшим оказался Random Forest со средней ошибкой 5,5% — и, что важнее, интерпретируемый: видно, как дерево решений раскладывает факторы. Ограничения докладчик называет сам: это презентация подхода; периода выборки и публикации с выходными данными в докладе нет.

Две находки, от которых хочется копать дальше. Спред — герой всех ранних работ об устойчивости — оказался последним по важности и в пять раз слабее доходности: роботы-HFT держат его настолько узким, что он перестал быть показателем. И разделение по скорости: при восстановлении быстрее секунды решает частотность сделок, дальше — факторы доходности. Гипотеза автора — за секунду успевают реагировать только HFT-роботы, человек подключается примерно на третьей секунде.

И тут вспоминается Ключарёв: активность мозга трейдеров предсказывала движение акций, когда сами трейдеры — нет. Попова, по сути, показывает, как это «видение на шаг вперёд» формализовать деревом решений. Хочется повторить это на данных российского рынка своими руками.

Как итог: что со всем этим делать

Когда я попросил своего агента выстроить все 43 материала в одну линию, получился тематический обзор: от нейрона, обучающегося на пробах и ошибках, — к вопросу «Кто такой Кто». От сознания — к математике сжатия, по которой и мозг, и модель строят картину мира. Дальше — фабрика софта как социальная система: с петлёй намерения, иммунной системой и человеком-диспетчером, который устаёт. Весь этот организм стоит на языке — спеках, онтологиях, скиллах — и на железе. Движутся обе стороны: производительность железа растёт, вычисления оптимизируются, веса улучшаются. Из-за этого встречного движения и стала доступной возможность запускать такое дома на игровом железе. А замыкается всё на рынке, куда я хочу принести всё описанное, — первые шаги уже сделаны.

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

Этот обзор я готовил в pi с моделями GLM-5.3 и GLM-5.3-Flash, используя скилл Knowledge Extraction — он собирал саммари, смыслы и цитаты из источников.

Если что-то откликнется — заходите в блог или в мои репозитории:

  • task-agents-playbook — правила и ролевые инструкции для агентов моего проекта: task-driven development, задача как спецификация
  • task-orchestrator — оркестратор CLI-агентов: роли, скиллы, сабагенты и процессы в YAML
  • coding-standard — PHP-пакет: DDD-конвенции, PHPCS-сниффы и метрики качества для код-ревью
  • task-llm-hiring — скриптованные тех-собеседования для LLM: методика, рубрики, судьи, отчёт по 17 сериям кандидатов
  • knowledge-extraction — скилл: извлекает знания из статей, YouTube и документов через TasK API; им обработаны все 43 материала этой подборки
  • become-role — резолвер ролей и скиллов: собирает агенту каталог навыков по его роли
  • todo-md — канбан на markdown-файлах плюс правила постановки задач для агентов

Читайте, пробуйте, не бойтесь ошибаться.

Что дальше: выбор ИИ-моделей для работы

Эта секция — про мою текущую задачу. Я строю систему оценки моделей и хочу проверить: могут ли слабые модели оценивать сильные. Отправная точка есть: в собеседовании 16 моделей на PHP-бэкендера методику мы составили вместе с GLM-5.3 Flash в ZCode, собеседование вёл скрипт, а оценку — связка decision-модели clef и GLM-5.3-Flash. Следующий шаг — попробовать посадить в интервьюерское кресло слабую модель и получить опыт, навыки, интуицию. Вопрос, на который я ищу ответ: по каким признакам тот, кто не умеет делать работу сам, отличит сильного от слабого?

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

Как это устроено у людей

Насмотренность вместо воспроизведения. Николай Шейко в подкасте «На эти грабли наступают все» объясняет найм и проверку подчинённых умнее себя: «опытные менеджеры, это люди, которые нанимают людей умнее себя… я должен проверять чужую работу, в которой я не шарю достаточно хорошо». Навык проверки растёт из объёма просмотренных результатов. Со временем «на кончиках пальцев» чувствуется «тут что-то фигня» — объяснить, почему, проверяющий не может.

Сравнение вместо баллов. В выпуске Podlodka #486 проверка описана через пары: «если я на своих примерах, которые мне понятны, вижу, что вот этот сделал так, а этот сделал на 10% лучше… могу потом подтвердить, что и три других тоже, по крайней мере два из них, сделали на 10% лучше. Всё, мне этого достаточно». Никто не ставит «8 из 10». Сравнивают пары и перепроверяют друг друга.

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

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

Признаки силы, которые видит слабый

Рабочая гипотеза: слабый видит только то, что можно сверить с его якорями.

  • фактические якоря — имена функций и методов языка и фреймворков, версии PHP и PostgreSQL, базовые термины предметной области. Слабые модели их выдумывают: в моём собеседовании судьи нашли выдуманные детали в 40–47% ответов о знаниях у qwen3.8 и ornith;
  • детерминированные проверки — код компилируется, тесты зелёные, схема валидна, формат соблюдён, бюджет не превышен;
  • сравнение пары ответов — «который лучше и почему». Предполагаю, что слабому судье пары даются легче абсолютных баллов — в Podlodka #486 пар хватило для вердикта;
  • глубина процесса — уточняющие вопросы: конкретика против воды, честное «не знаю» вместо выдумки;
  • ловушки — вопрос с ложной посылкой, граничный случай, тот же вопрос другими словами. Согласованность я уже мерил повторными прогонами, провокации с ложной посылкой были в вопроснике;
  • чек-лист известных провалов — придуманные API, потерянные требования, противоречия в длинном ответе. Искать известную ошибку проще, чем делать работу самому — та же мысль Шейко;
  • сверка со спекой — пересчитать требования задачи по списку.

Архитектурные решения и долгосрочную сопровождаемость слабый судья сам по себе не оценит — быстрого оракула для них нет, это тезис Декса Хорти из секции о фабрике. Для PHP эти вещи измеримы детерминированными инструментами. Мой coding-standard собирает из AST граф статических связей внутренних типов, матрицу зависимостей модулей, размеры модулей и связность методов классов (LCOM4); дельта к merge-base помечает регрессии, например CommandHandler без события. Числа дают слабому судье якоря там, где раньше оставался только вкус. Покрытие частичное — метрики видят структуру и связность, а качество самих дизайн-решений остаётся за кадром.

Механизм, который хочу собрать

Слои по возрастанию цены:

  1. Детерминированный слой. Тесты, схемы, форматы — отсекают очевидное без всякого судьи.
  2. Чек-листовый слой. Слабая модель не оценивает «хорошо ли», а ищет ошибки по рубрике известных провалов.
  3. Сравнительный слой. Один вопрос нескольким моделям, слабый судья сравнивает пары. Из многих сравнений строится рейтинг — то самое «этот на 10% лучше, и два других подтверждают».
  4. Процессуальный слой. Серия уточняющих вопросов к каждому ответу. Моё собеседование — готовый прототип, меняется только интервьюер.
  5. Калибровка судьи. Отдельный набор вопросов с известными ответами, на котором меряют самого судью. Дмитрий Березницкий в «Как тестировать AI-агента, чтобы ему можно было доверять» прямо говорит: судью валидируют против человеческой разметки, а не верят ему на слово.
  6. Кворум и эскалация. Несколько слабых судей отвечают независимо. Согласились — решение. Разошлись — вопрос уходит сильной модели или человеку.
  7. Копилка насмотренности. Каждый случай, подтверждённый сильным судьёй, становится примером для слабого. Это те самые «кончики пальцев», только вместо лет практики — датасет.

Готовых ответов у меня нет — есть план и открытые вопросы. Насколько надёжны слабые судьи на сравнениях? Хватает ли кворума, чтобы не дёргать сильную модель на каждый чих? Как быстро растёт точность по мере накопления копилки примеров? Буду искать — и напишу, когда будет что показать.

Источники: