постмортем Антропик с прошлой недели. Тыц 🔗

Мое уважение – эталон по тому как надо писать постмортемы, это кстати очень важный навык для любого senior DevOps/SRE ну и вообще инженера.
Не могу похвалить остальные их статьи, там часто слишком уж много маркетинга просачивается

но постмортемы тем и хороши что в них любые попытки что-то продать выглядят очень странными! 😢

что случилось то?

TLDR; C августе-сентябре в инфре Claude "возникли" аж три разных бага, которые плачевно влияли на качество ответов. Там была – неправильная маршрутизация запросов между серверами, бились выходные токенов, и поганая ошибка в XLA TPU компиляторе.

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

Последнее, кстати, основной вывод – Антропик признались что слишком полагались на эти метрики, вместо отзывов пользователей 😬
Вот тебе и AI платформа.

***

Я скажу так – все это произошло в компани которая поставляет, если уже и не лучший, то один из самых лучший codding агентов и моделей для этого благого дела.

При этом они неоднократно писали статьи о том Claude Code хорошо помогает в работе и команд разработчиков, и инженеров платформы, и дата-сатанистов...

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

Про наблюдаемость, метрики и прочее – это тоже очень важный урок из мира Ops и SRE.

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

Изучайте System Design и MLOps, и AI вас не заменит, ну или заменит чуть позже, когда беспокоиться будет уже не о чем 😏

Если вам совсем не понятно за что хвататься, с чего начинать – приходите в личку на консультацию, разберемся :)

@neuralstack

обновленный Coding Plan GLM-4.5

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

a я и не знаю ¯\_(ツ)_/¯

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

очень уж все сейчас быстро развивается.

но касаемо codex интерес понятен. Слышно как тут и там как раздаются восхищенные вздохи 🪨

Я попытался спросить у плотно вайб-кодящих коллег - а пробовали ли они "новый" codex (в смысле на GPT-5) и средний ответ по палате звучал как-то так:

Да мне ващет на Claude Code нормально, всем меня устраивает, все хорошо.

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

Я писал про GLM-4.5 и Coding Plan ровно неделю назад, а потом, практически все семь дней я пользовался этой LLM для разработки и проектирования разных бэкенд проектов.

Модели антропика за этот же отрезок времени я использовал для генерации кода раза два.

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

Заходя на арку бурного развития добавлю, что еще успел поменяться и Coding Plan:

во-первых, теперь поддерживается не только Anthropic совместимый API, но и OpenAI, а значит вы можете воткнуть GLM модели почти куда угодно.
во-вторых, z.ai увидели ажиотаж и пошли еще дальше – они представили еще один уровень в Coding Plan – GLM Coding Max в котором вообще никаких лимитов нет.

На секунду хочу напомнить, тот самый lite план за 3/6 баксов (первый месяц скидка 50%) – уже дает лимитов больше чем Claude Max. (Max, НЕ Pro!)
Обновились и периоды для возможной покупки. Все тарифы можно взять на месяц, квартал или год.

Я не устоял и взял средний план – GLM Coding Pro на год на 180 баксов. В него входят лимиты x5 от базового lite, роутинг запросов на серваки с чуть более быстрым инференсом (обещают быстре lite на 40-60%, и не врут),

и два дополнительных бесплатных API (доступны через mcp с тем же токеном) – один для GLM-4.5 Vision, второй для какого-то web поиска от z.ai.
Я попробовал оба – vision работает вполне ок.

Поиск – пока совсем непонятный.

***

Причина по которой я так подсел на GLM прозаична – мне не хватает лимитов от Claude Pro, потому что у меня много-много проектов в Claude Desktop, и 3-4 из них я использую на регулярной основе для концептуального рефакторинга проектов и прочих иных, практически бытовых нужд.

И deep research на Антропик мне до сих пор нравится больше прочих. Уж извините ¯\_(ツ)_/¯

короче говоря – мне надоело одним или вторым инструментом упираться в лимиты и ждать несколько часов, мои проекты/app'ки в claude должны быть доступны всегда, когда они мне потребовались. Ровно как и агент для генерации кода.

***

В прошлый раз пост про GLM Coding Plan следовал сразу за постом про Zed. Сегодня скажу про оба :)

До вчерашнего дня я использовал GLM в основном только в opencode.

Ровно до тех пор пока не увидел про поддержку OpenAI совместимых интерфейсов.

2+2=4, бегом в доку Zed, и... GLM тут настраивается очень просто, заходите в settings.json и добавляете что-то вроде:


***

"language_models": {
"openai_compatible": {
"ZAI": {
"api_url": "https://api.z.ai/api/coding/paas/v4",
"available_models": [
{
"name": "glm-4.5",
"display_name": "GLM-4.5",
"max_tokens": 128000
}
]
}
}
},

***


Авторизационнй токен надо передавать в переменной окружения, для примера настройки выше она должна называться ZAI_API_KEY.

Поздравляю, вы в шоколаде – у вас красивый, быстрый редактор на расте 🦍 в котором можно follow-up следить за изменениями агента, ревьювить их поблочно как в Курсоре, и все это на базе модели практически ничем не хуже Sonnet 4, с отличными лимитами за 360$ в год (начиная со следующего!)

Такие дела.

Ах да, кстати! На скриншоте отвечает GLM-4.5 в Zed панельке (Я это железобетонно проверил)

В исходном коде редактора нет ни одного промпта с "Ты Claude Code!".

Вот и думайте.

@neuralstack

crush агента.

Вчера у меня резко перестал работать opencode, и я наконец нашел причину попробовать crush

Проблема, кстати, была смешная – один из mcp серверов в докере не поднялся, и opencode просто перестал работать не объясняя в интерфейсе никаких ошибки. Это плохо.

Crush хорош. Я уже упоминал его, указывая что не поддерживаются серые методы использования подписок Claude Code (как в opencode, например ;) и работает только с API моделей.

Crush написан на Go, умеет в lsp и mcp, и выглядит получше.

Как минимум crush удобен своей легковестностью для внедрения AI в unix стиле (пайплайны и вот это все) во всякие DevOps и DevEx процессы. Мне не хочется тащить без острой надобности рантайм ноды чтобы запускать opencode или СС на маленьких раннерах, например.

Но если рассматривать его с прикладной vibe-code стороны есть несколько серьезных минусов.

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

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

LSP, и разумеется - MCP в opencode тоже поддерживаются. Даже больше – там можно делать свои команды, есть возможность запускать opencode как сервер, sdk для кастомных клиентов, и плагины которые открывают возможность слушать события opencode'а и расширять функционал (с доступом к контексту сессии). Базовый пример из документации – слать уведомления когда агент закончил работу.

Все это ценой чуть (или не чуть) большей тяжеловесности, чем crush.

Кстати, раньше core разработчики обоих проектов работали над одним агентом вместе, потом разругались и разошлись. Там все очень мутно, грустно и не хочется в это вникать, но изначальный автор старого opencode (Kujtim Hoxha) пошел в Charm получать крышу финансирование и развивать переписанного агента под именем Crush, а двум другим (Dax и Adam) оставили название opencode.

Лично мне crush с точки зрения UI и DX нравится больше – он отображает оставшийся контекст, хорошо компанует его, есть индикаторы подключенных LSP и MCP серверов (часто их надо выключать), и единственное чего не хватает, это пусть даже не под-агенты, но просто возможность преднастраивать агентов "сверху".

В общем идеал лежит где то между. А может идеал это все еще claude code? ✏️

@neuralstack

evaluation тесты.

Eval тесты можно ненавидеть, eval тесты можно любить.
Eval тесты можно не понимать. Eval тестов можно боятся как дополнительный источник затрат на токены 🤵

Но их нельзя не писать для любой AI системы которая хотя бы на один порядок сложнее и нужнее weather api агента.

Точнее как… не писать их конечно можно, но вот не делать их вовсе – невозможно.

Если вы говорите что у вас совсем нет eval’ов, то вы просто обманываете сами себя.

Вы ведь запускаете систему хотя бы для мануального тестирования, чтобы проверить работает ли оно вообще?
Ну вот! Медленный, крайне неэффективный, мануальный – но это eval тест.

Для меня разработка eval тестов это неотъемлемая часть внедрения AI на любой бэкенд, который обслуживает живых людей и бизнес.

***

Под сложностью системы я тут подразумеваю прямую отвественность, которая налагается на нее в смысле функциональности.
Под нужностью, я имею в виду непосредственно "продуктовость."

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

В старом software 1.0 мире программные системы которые живут без покрытия юнит и интеграционными тестами – это база :)

Представить успешный AI продукт, действительно бизнес продукт, без набора e2e/eval тестов я просто не могу.

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

С несколькими такими стартапами я общался в формате микро-консультаций.
Знаете чего у них не было?

Правильно – тестов. Вообще. Никаких.

Знаете где они? Либо уже, либо вот-вот – нигде.

Справедливости ради, наверное есть два случая, когда можно обойтись условно меньшим числом строгих eval'ов.

Помимо чрезвычайной простоты кейса, второй случай это когда у нас команда с абсолютной экспертизой в домене и фактически религиозным dogfooding'ом.

Но давайте будем честны с собой... Насколько часто такое встречается?

***

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

А самое опасное сейчас – это анти-eval пропаганда в комьюнити. Не ведитесь на нее.

Пишите тесты чем раньше тем лучше. А лучше – сразу. Фиксируйте свои ожидания в коде.

На картинке плашка из документации pydantic-ai со страницы про pydantic-evals.

@neuralstack

codex (cli и cloud).

Я обещал, а раз обещал – наконец начал пробовать "новый" codex.

При том в обоих форматах – cli и облачный асинхронный.

tldl; Ну... ничего особенного не замечено.

Не плохого, ни восхищенно хорошего сказать не могу.

Облачный codex был и до этого хорош, стал ли он лучше? Ну мое имхо такое – кардинально еще лучше он станет когда появится возможность:

- А) Собирать свои контейнеры в которых будет запускаться агенты
- B) Появится возможность добавить принудительный тул-хук который будет вызываться всегда перед тем как завершать задачу

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

Конечно, можно приказать в AGENTS.md – "всегда всегда выполняй make check && make format && make type_check && make test!!!", но много лучше было бы тут добавить некоторого детерминизма :)

***

Ладно, позитивное – я не воткнулся в лимиты пока вот вообще (обычный ChatGPT Plus), хотя и мучал codex большую часть дня.

Поэтому будем считать это промежуточным фидбеком ✋

Мое мнение тут конечно крайне субъективное, я не гоняю никаких своих или чужих бенчмарков вроде one-shot "Сделай мне 3D игру на Godot", как некоторые ребята на ютубе.

Скорее наоборот, чисто эмпирическое имхо в рабочих задачах, среди которых подавляющее большинство это или разработка бэкенда (с LLM и без), DevOps (yaml senior development), и ворочания проектными данными туда сюда для системного проектирования и концептуального рефакторинга.

и это мое имхо пока такое, что особой разницы я с sonnet 4.5 или GLM 4.6 не вижу вообще. (ну с sonnet уж точно)

А то что GPT-5-codex очень уж имеет сильный биас к тому чтобы вместо unix тулов все делать на Питоне я отношусь пока со смутными сомнениями.


p.s. А вы помните как прикольно работалось с sonnet 3.5? Не помните? Может потому что мега-кардинально ничего не поменялось, и сейчас ассистенты круче просто потому что тулинг вырос вокруг и тд? :)

@neuralstack

ai workslop чать 1.

Начинаем безжалостный концептуальный рефакторинг "Внедрения AI".

"Как же меня задолбало расшифровывать этот LLM-блоб, ну сколько можно?!"

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

Бессистемно закинуть в компанию корпоративные подписки на нейросетевые инструменты в надежде что это позитивно повлияет на продуктивность много хуже чем бессистемно вводить scrum/agile процессы.

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

Бессистемно закинуть в рабочий процесс LLM всегда хуже. Ну, вы помните – хорадрический куб 🙂

Подходы системной инженерии в организации работ в принципе плохо распространены – мало кто разрабатывает, именно – разрабатывает, а не просто внедряет методы работы.

Из за этого мы часто встречаемся с двумя бедами:

1. Bottlenecks (замедления)
2. Rework (переработки, в смысле исправлений-переделываний)

Если bottleneck можно относительно просто найти и устранить, то постоянный rework - индикатор системной проблемы.

Так вот, когда мы закидываем в сотрудников LLM без каких либо минимальных формальных требований к работе с этим новым инструментом, мы часто получаем огромное количество и замедлений, и переработок.

Как это проявляется?

LLM сейчас способны порождать много разных штук в разных модальностях – тут тебе и картинки с текстом, и документы, и просто текст для всякхи отчетов, и таблицы, и код. Среднестатистический сотрудник, не имея формальных указаний (хотя бы ревьювить результаты работы ЛЛМ и помечать "продукт" явной меткой "Я это сгенерил!") естественным образом работает/генерирует спустя рукава.

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

Дальше ключевой момент - начинается психотеррор, например:

Джун пишет тех дизайн с помощью ChatGPT на 12 страниц.
Senior/Техлид тратит 1.5 часа на чтение, потом еще ~час на встречу в попытке выяснить "а что здесь важно?"

В итоге сам переписывает спеку на 2 страницы за 30 минут.

Потеряна куча продуктивного времени команды.

И что еще хуже, зачастую наносится моральный урон: джун не понимает что не так (ему просто не хватает пока компенции даже увидеть что ЛЛМ выдала ерунду), а техлид выгорает, потому что ничего с этим не может сделать (особенно если повестка компании – "AI во все процессы, полный вперде!", без методичек/ограничителей)

А теперь представим что ситуация повторяется несколько раз в неделю. 😵

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

---

Эти проблемы не повод переходить на сторону LLM-луддитов, ну уж нет! Толково внедряемый AI чертовски полезен.
Это всего лишь повод порефлексировать, задуматься.

Проведите простой тест: попросите 3-5 коллег описать "как мы используем AI в работе?"

Если получите совсем разные ответы - у вас нет AI-стратегии, есть AI-хаос. Вам надо стремиться к ответам – "Ну так в Engineering Handbook лежат правила и чеклисты, вы ж сами их внедрили, вот мы по ним и работаем, забыли?"

@neuralstack

что там происходит у Гугла 🙂

Во-первых, похоже (хочется верить) что совсем вот-вот должна выйти Gemini 3.0.
Если не на этой, то на следующей неделе, ну или край – в этой месяце (пожалуйста 💧)

На это как будто указывают триал доступы для всяких vibe-coding блоггеров, например вот видео.

Конечно же мое отношение скептическое, надо дождаться и пробовать самому. Но даже если все утечки бенчмарков окажутся уткой (на которых gemini 3.0 просто в пух и прах разбивает gpt-5), Jules сейчас приковал мое внимание.

Во-вторых, да – Jules, это очередной асинхнронный агент для запуска задач, похожий на codex cloud, но последний я все таки пока выкинул, буквально сегодня отменил подписку на chatgpt plus ¯\_(ツ)_/¯

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

Что я имею в виду под подходящими? Ну, самое болезненное, это постоянный контекст-свитчинг. И уведомления тут не помогут.

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

Либо второй вариант – мы все таки работаем над двумя важными проектами, но один чуть менее важный и срочный, вот его и отдаем в асинхронное, и 2-3 раза в день полностью переключаемся на проверку и запуск новых задач (или задач на исправление).

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

Jules от гугла в первую очередь решает это – есть cli "Jules tools" который позволяет спулить изменения в терминале, запустить новые задачу, посмотреть историю и все такое прочее. Круто? Помоему круто. Много круче чем переключаться на браузер, и там вошкаться)

Еще у Jules есть память про репы, и это хорошо. Любая память всегда (почти всегда) полезна, особенно когда надо внедрять AI на бэкенд.

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

Так что тут уже не только про внедрение на бэк для бизнеса, но и про удобное внедрение в dev процессы. Нравится!

Я не бегу пока плотно тестить Jules, потому что пусть он и покруче выглядит, пока кажется что это все равно та же история про отвлечения и переключения контекста. Лучше все таки дождаться 3.0, и сразу попробовать ее везде. Но, честно – предвосхищаю круть :)

Если Gemini 3.0 войдет в Google AI Pro подписку за 20 баксов без повышения цены, то это будут, пожалуй, самые выгодные 20 баксов на AI.

Там тебе и в почте gemini, и Veo3, и Jules и еще больше Gemini CLI, и NotebookLM... Молодцы, ниче не скажешь ❤️

Пожалуйста, расскажите в комментах, если вы уже пробовали работать с Jules и у вас сформировалось какое то представление.

@neuralstack

техническое поражение в AI кодинг битве засчитываю облачному codex 😠

Решил я, значит, устроить дуель между Jules и Codex Cloud.

Остороно – Юмористическое.

Дано:

- Простецкий проект на питоне, где есть молотилка векторов, chroma, sqlite и все это обернуто в mcp сервер (ну да да, типичная AI раг на бэкенде)
- Крайней разжованный implementation_plan.md в под-директории

Задача с одинаковым oneshot промптом, tldr – "вот те репа, вот те сабдир с планом, давай делай"

Идея была пойти спокойно поспать и утром посмотреть на результаты.

Я, все таки, ставил на codex, ну... ну хвалят же за работу с большими блобами!?

Но уснуть я не успел 😁

Результат работы codex cloud вы видите на кринж-шоте поста. Пояснений не дает, ни в логах ни в ответах.

Jules, бедолага, бадается упорно, утром посмотрим что сделает)

@neuralstack

ai workslop часть 2.

Привет, часть 1 была тут.

А часть 2... Я начал писать ее на тему того что работает и не работает в AI ассистированном программировании. Все шло хорошо до тех пор, пока мне не попалась под руку очередная статья с откровенной брехней. А брехня это всегда золотой материал для концептуального рефакторинга :)

Разбирая эту брехню (без ссылок на источник, ибо делиться этим я не хочу; Вы итак подобное читали скорее всего уже несколько раз) и свой совсем свежий, насильно неадекватный экспримент, я написал маленький лонгрид (10к символов) который можно прочитать на моем сайте.

Милости прошу -≥ тыц.

TL;DR:

“10 PR в день” и “$12k на токены” - в ваккуме это красные флаги карго-культа, а не показатели продуктивности

Спецификации ≠ реальность. Код выражает инварианты системы, которые нужно понимать, а не просто генерировать

Мой эксперимент: переписывание 5k строк без просмотра кода заняло 3 дня вместо 1. На каждой задаче нужны были правки

Правильный подход: AI генерит → ты проверяешь. Human-in-the-loop это не опция а необходимость

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

Кстати, на тему вайб кодинга и прочей разработки с LLM ассистентами сегодня будет онлайн конфа на которую вы можете попасть бесплатно:

https://www.ai-dev.live/

Первый доклад стартует в 14:00 GMT+3

Всех ребят я читаю, и имхо – все на правильной стороне луны.
За рекламу мне никто не платил, рекомендую присоединяться от чистого сердца 💖

@neuralstack

дешевый но хороший OCR документов.

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

Вообще, типичное такое внедрение AI на бэк с наскока – модели в проекте использовались большие (openai, google), а разультаты... Ну скажем так – результаты были неплохие, но оставляли желать лучшего.

В проекте было достаточно популярных проблем (вроде отсутствия достаточного количества eval тестов), но главной технической проблемой, по моему мнению, являлся как раз таки BAML.

Почему? Ответ прозаичен – BAML не умеет в Structured Output моделей и не хочет в него уметь. Нет SO – нет SGR. Нет SGR – нет возможности без мучений моделировать и создавать надежные AI системы.

***

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

И вот меня не покидала идея попробовать сделать OCR на маленьких VLM моделях.

Благодаря Валерию, который сейчас хостит Qwen3 VL 8B Instruct и бесплатно дает ее попробовать, я наконец закрыл этот гештальт :)

Главная цель была набросать OCR фотографий чеков;
Результат... просто отличный! ☀️

Наколеночный POC вы можете посмотреть в этом репозитории, забрать себе и попробовать запустить OCR сами.

Это очень ограниченная, простая реализация чтобы просто проверить модель. Продуктовая OCR система, разумеется, потребует некоторых важных доработок (подсказываю в REAME.md).

Но этого сниппета достаточно чтобы:

- посмотреть неплохой пример SGR
- набросать туда побольше файлов и тестов чтобы оценить качество этой или других VLM моделей предметно.

А квен этот мне очень нравится! Год-полтора назад мне сложно было представить что так дешево можно собрать вполне себе качественный и умный OCR.

@neuralstack

В вашей команде слышно такую фразу – "Если ChatGPT может, значит и мы сможем!"?

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

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

Конечно, выражение очень здорово звучит, в духе стартапа! Мы можем! Вперед! Ееее! 🤟

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

А заострять внимание на этой разнице важно с самого начала.

Разработчики рано или поздно это понимание обретают, когда начинают замечать разницу, в каком нибудь распознавании картинок плохого качества, например.

Только вот понимание это натурально выстрадано через стодесять переделок.

***

Когда то один веб-разработчик мне сказал – "Ну так там а чо там... Там же просто апишку open-ai дергать надо, не рокет-саенс."

Ну, конечно же не рокет-саенс. Но такое отношение недопустимо в разработке продуктовых AI решений.

ChatGPT — это система. С препроцессингом, fine-tuned промптами, какой нибудь fallback логикой, и так далее (никто не расскажет сколько там и каких примочек на самом деле :)

API — это голая модель + ваш промпт ¯\_(ツ)_/¯

Хотите результаты уровня работы ChatGPT или лучше?
Тогда проектируйте систему, а не просто дергайте API.

В каких то случаях надежное решение получается благодаря много более простым подходам. А в каких то придется и правда нагородить небольшую ракету.

Приходите на консультацию ❤️
@m0n0x41d

Ваши AI агенты все еще застревает в циклах? Тогда я иду к вам! 💃

Меня вчера все таки выдернули на короткую консультацию (очень не хотелось работать в выходные.)

по проблеме стараой, доброй и прозаичной – "нам вообще не понятно почему оно периодически проваливается в бесконечный цикл tool-call вызовов."
При этом там одна *большая модель от гугла.*

В проекте использовался LlamaIndex с примерами прямо из документации :)

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

Разобрались ровно за один часовой звонок. И вот буквально 10 минут назад мне отписались что "утром переписали, весь день тестируем и ни одного провала в циклы!"

Решили всё с помощью серебрянной-пули Schema Guided Reasoning – по каноничному примеру с выбором нужного тула (см тут.)

Никаких promp-издевательств.
Никаких бесконечных циклов.
¯\_(ツ)_/¯

В довесок приятно было услышать что ребята послушали мой "совет на закуску" и попробовали все таки модели подешевле – всё работает хо-ро-шо!

Вот она прелесть SGR - структурируешь и свое рассуждение и рассуждения LLM, решение работает если не одинаково, то как минимум предсказуемо на разных моделях.

Ну и денег можно сильно сэкономить :)

@m0n0x41d

Вы конечно можете закидать меня дизлайками, но правды это не поменяет:

AI не принес никаких кардинально новых проблем/задач в программную инженерию.

По крайней мере со стороны системного и программного дизайна.

***

Ну, посудите сами - разве раньше не было проблем с постоянным тушением пожаров, вечной войной с багами, медленными и разрушительными релизами? а? 💣

Корни этих проблем всегда находятся где-то между:

- Проблем с тестированием; Либо тесты вообще не пишутся, либо они тестируют реализацию вместо интерфейсов;
- Высокой связности, при том не важно чего – псевдо-микросервисов в распределенном монолите, или модулей в монолите обыкновенном :)
- Серьезных затруднений в рассуждении о программных системах у наших разработчиков – мало кто реально осознает разницу между прикладным уровнем системы и уровнем ее дизайна;
- Низкой наблюдаемостью – не сразу понятно (или не понятно вообще), где что сломалось и как подступаться к дебагу;
- И так далее...

Какие же тут качественно новые вызовы со внедрением AI на бекенд?

Да существенно никаких.

Если мы не занимаемся машинным обучением, дата сатанизмом и прочим из "ядра" AI, а утилизируем готовые решения, пусть то модели по API или даже хостинг открытых моделей, не важно – все реальные боли упираются и легко вписываются в те самые "старые добрые".

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

Так что для успешной разработки AI систем вам нужно не воображение и вера в чудеса, а инженерия ¯\_(ツ)_/¯

@m0n0x41d