ИИ пашет, Саша одобряет

лучше мема мы уже не увидим😁

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

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

Как рассказать всему миру про свою архитектуру?

А заодно поделиться ссылками на github/LinkedIn блоги? Возможно найти новые интересные проекты?

Нужно прислать PR вот в эту github repo. Описание процесса в README.MD После обработки PR,
• ваш пост появится прямо на сайте в категории Insights
• в leaderboard появится ссылка на него (примеры PAC1)

А еще можно в insight указать model_names. И если использованы только локальные модели, то получите выделяющийся бэджик прямо в лидерборд!

Ждем!

Кому интересно увидеть какие-то архитектуры - пишите в комментарии, можно сразу с вопросами. Интерес очень мотивирует авторов!

Ваш, @llm_under_hood 🤗

Тут недавно вышел пост, про то, что можно разместить рядом с своим решением ссылку на репо, думал и решил повесить туда ast по приколу, надо будет все же снова сходить на новое соревнование агентов, а то последнее 30 мая я просто проспал🫠

Просто его поставили в 11 вместо 14, еще и хаба в Око не было в этот раз, а значит и бесплатной еды, в итоге смысл соревноваться у меня был утерян😁

В прошлый раз я готовился с 11 до 14 до момента начала, возможно стоит чуть погонять заранее или не стоит))

Говорят в новом было весело, видимо надо идти и не скипать + настроить кэширование и тп на экономию денег🙃

Кратко о текущих реалиях, когда наступит момент, что агенты будут только для богатых?)

А может, стоит остановиться и переосмыслить систему качества агентов, подойдя к ней под другим углом?

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

Статья: https://www.howtoeval.com/

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

Что делать?

Запускаем → наблюдаем → анализируем → улучшаем → повторяем.

Если у вас уже 1000+ диалогов в день, стоит вычитывать хотя бы часть из них, например 50-100 диалогов. Именно так можно увидеть узкие места, повторяющиеся ошибки и моменты, где агент начинает сыпаться.

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

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

Что еще полезно отслеживать кроме самих диалогов?

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

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

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

Будто это дает совершенно новый способ тестировать агентов не в вакууме, а через реальные ситуации.

А если агенты уже работают на тысячах пользователей?

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

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

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

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

Корзинки качества или симуляция общения с агентом?

Сейчас многие пытаются построить системы оценки качества AI-агентов: наборы кейсов, скоринги, ручную разметку, автопроверки, “корзинки качества”. Но насколько такие системы действительно отражают качество агента, вопрос сложный.

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

Тут появляется другая идея: симуляция.

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

То есть мы можем тестировать агента не только на статичных кейсах, но и на “отложенных пользователях”: раздраженный клиент, новичок, человек с неполными данными, пользователь, который меняет цель по ходу диалога, и так далее.

Что выбрать?

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

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

Возможно, ошибаюсь, но сейчас экспериментирую в эту сторону.

Как думаете, какие сценарии вы бы обязательно добавили в симуляцию?

Берем 3D принтер и делаем бизнес 😄

Claude Code, Codex или OpenCode: что бы я выбрал сейчас?

После последних решений Anthropic с банами, закручиванием гаек и ощущением, что модели стали работать тупее, мне в какой-то момент это надоело. Решил, что пора что-то менять, и отнес свои $200 в OpenAI.

Жалею ли я об уходе с Claude Code?

Нет, пока ни разу не пожалел. Достаточно быстро мигрировал свои процессы и работу агентов под флоу в Codex: условно по 15-30 минут на один проектик, причем часть можно было делать параллельно.

Почему именно Codex, а не что-то другое?

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

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

Почему не OpenCode?

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

Возможно, у каждого тут будет свое мнение, но мне кажется, что если у модели есть свой родной harness, то лучше начинать с него.

Не много ли $200 за подписку?

На Claude оно у меня заканчивалось довольно быстро, если себя не контролировать. А с Codex ситуация пока намного приятнее: можно буквально 24/7 работать над своим пулом проектов и не думать каждую минуту про лимиты.

В общем gpt-5.5 вообще не ни одной модели антропиков, а то и лучше чем они.

Интересный вариант в Ai мире

Еще один способ найти деньги на токены 😄

Поздно ли вкатиться в работу с ИИ на продвинутом уровне?

Многие сейчас считают, что большиство очень хорошо разбираются в Ai и том как его настраивать и как следствие сидят с мнением, да что я там вообще могу сделать?

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

Причем они сами просто не могут настроить их вообще и не понимают как и если чего-то нет в проекте, то так и будут жить.

Ну а как вообще вкатиться то?

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

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

А какие еще способы есть?

Постоянно читать разные статьи, инфу, но ее уже столько, что это будет выглядеть как какой-то ад.

А как вообще лично я вкатывался?

Мой товарищ, Леша Гладков потратил кучу времени и сделал классные челленджи на 30 дней, еще до нового года, суть была простой, каждый день есть задание, которое не сделать руками вообще, а если не сделаешь вылетаешь сразу.

Я как раз принял участие для разнообразие в обычном (одном из первых, до нового года) и продвинутом, прошел оба и было прям весело и очень много пользы, а также принесло кучу знакомств с крутыми ребятами.

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

Если интересно загляните к нему

Постик:
https://t.me/alexgladkovblog/6993

Сайт:
https://mobiledeveloper.tech/ai_advent_8

Ну и я с ним договорился на промик от меня, копеечка, но приятно)

AI8W1K

А как еще токены можно себе заработать в 2026?)

Релиз ast-index 3.44.0

Вышла новая версия инструмента https://github.com/defendend/Claude-ast-index-search/releases/tag/v3.44.0

C++ поиск стал namespace-aware: теперь работают и symbol Client, и symbol foo::bar::Client, плюс pattern-поиск вроде ::Client и foo::bar*

rebuild и update стали надежнее: безопаснее SQL query, корректнее работа с include и extra roots

часть безопасных оптимизаций rebuild вынес в дефолт из под флага (--experimental-fast-rebuild) и добавил новые бенчи для индексации / update / module graph / Android XML+resources


В общем фикс мелких ишью от ребят из c++, теперь ast там наконец-то умеет в базу)))

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

Тут уже не скажешь клоду/кодексу как в начале, го с питона на раст разом перепишем, хоть и было все покрыто тестами)))

upd: поддержаны enum для парсинга в плюсах 3.44.2

Когда написали действительно на английском 😄

Сегодня Антропики закрутили еще одну гаечку, у части ребят на подписке за 100 баксов, окно в 1М контекста стало возможным только по апи, с оплатой за токены.

Ждем когда подписки вообще отменят🫠

Нужны ли IDE в новых реалиях?

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

Условно, Android Studio базово всегда отжирала 8-16 Гб. Хоть на маке и 36 Гб, но если добавить индексацию в IDE и запустить какой-нибудь билд, мы получаем зависающее приложение и подтормаживающий мак, потому что уходим в своп по памяти.

Еще в сентябре, когда начал использовать Клода, я задумался: а зачем мне вообще ее открывать?

Но в целом еще какое-то время, примерно до ноября, держал ее открытой, чтобы посмотреть код или что-то найти.

И в какой-то момент подумал: а зачем она мне вообще нужна?

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

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

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

Что было дальше?

Тут все просто: я снес IDE и пошел в сторону допиливания работы с агентами, создания для них инструментов под себя, чтобы стабильно получать высокое качество задачек.

Жалею ли я о том, что больше не использую IDE?

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

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

Кстати, по опыту других ребят вокруг тоже слышу, что они полностью отказались от использования IDE.


А вы еще пользуетесь студиями или уже тоже отказались?

Нужен ли код-ревью процесс в AI-first компаниях?

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

Но с появлением агентов объем кода резко вырос. И PR-ревью очень быстро стало узким горлышком. Сначала люди еще пытались внимательно смотреть изменения, но за последние месяцы во многих командах это часто превращается в формальность: approve без глубокого просмотра.

Почему так происходит?

Во-первых, многое уже покрыто тестами, автотестами, CI-checks и прогонами на фермах. Критичные сценарии проверяются автоматически лучше и стабильнее, чем человеком в PR.

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

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

Из этого, как мне кажется, следует простая вещь: если у вас хорошо настроены агенты под задачи команды, если они в большинстве случаев пишут надежный код, учитывают edge cases, а качество дополнительно держат тесты и CI/CD, то обязательное ручное ревью каждого PR теряет смысл.

Что остается вместо этого?

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

Мое мнение: в агентской разработке сплошное ревью всех PR людьми или агентами будет приносить только убытки и не давать никакого эффекта. Особенно для внутренних систем, админок и low-risk задач.

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

А вы думали вообще что будет с такими процессами в Ai-first компаниях?

Ускорил индексацию в 3.6 раза, новый фича флаг в ast-index v3.43.1

Как попробовать?

ast-index rebuild --experimental-fast-rebuild

Недавно позвали на одну из внутренних встречек рассказать про ast с метричками и всяким подобным, в итоге ребята накидали разные идеи + увидели что условный проект 250К файлов индексируетс за 400-500 секунд и это как-то долго выходит.

В общем сел вечером и начал изучать, а где вообще проблема в скорости и что можно сделать? Тут сразу нашел узкое место это запись батчей в sql базу + скорость волкера по дереву файлов и разные не большие оптимизации с транзакциями в базу.

В общем ускорение на проекте в 32 К файлов до 11 секунд, я еще сел и подумал, а что если можно еще ускроить?

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

Ошибся, но где?

Дальше буду отдельно еще изучать перфоманс, в данном случае погубила жадность))

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

А зачем вообще это ускорение?

На проектах в 30К файлов будто не сильно важно, но ребята приходят с тем, что хотят работать из корня репозитория своего БЮ и индексировать сразу все, такие дела)

Пробуйте фичу, должно быть полезно прям на огромных проектах. Ну и сильно приятнее с индексацией проектов на 10-30 К файлов за считанные секунды.

Как понять, что ваш агент — не нейрослоп?

Недавно столкнулся с ситуацией: агент, которого добавили в один из флоу с тикетами, не помогал, а скорее мешал работе.

Я пришел с претензией в духе: “текущий подход никуда не годится”. В ответ получил справедливый вопрос: “окей, а как сделать лучше? Чего агенту не хватает до нормального решения?”

В итоге собрались с ребятами пообсуждать, а какие у меня есть идеи по их агенту.

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

Ребята быстро собрали и разметили такую очередь.

Дальше возник следующий вопрос: окей, размеченные тикеты есть. А что с ними делать?

Мы собрались еще раз и за пару часов накидали рабочее MVP:

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

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

Важное требование:

агент, судья и валидатор должны быть из разных семейств моделей. Например: Claude, GPT и GLM/Kimi/DeepSeek. Это не убирает все проблемы оценки, но снижает риск того, что модель будет сама себе подыгрывать или переоценивать похожий стиль генерации.

Еще одно важное правило: золотые корзинки не должны протекать в промпт агента. Иначе мы не улучшаем агента, а просто учим его проходить конкретный тест.

Что получили в итоге?

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

Главный результат — появился воспроизводимый процесс оценки. Теперь качество агента можно обсуждать не в формате “мне кажется, он тупит”, а через конкретные прогоны, ошибки, регрессии и сравнение версий.

Вот это, кажется, и есть первый шаг от “нейрослопа” к нормальному инженерному инструменту.