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