Разбор аудиорежима в кодексе

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

Короче, я тут на днях делал себе компрессы для глаз (*звуки деда*), а они прям полностью глаза закрывают, там такая маска, типа как для сна Ну и вместо того, чтобы спокойно посидеть и подумать о вечном, я врубил диалоговый режим кодекса и проболтал с ним пол часа вместо положенных мне 15 минут Стало интересно, че это он такой умный, и я полез реверсить билд кодекс аппа – реализация оказалась одновременно и простой, и глубокой. А сам подход можно использовать не только для аудио (но об этом в конце поста) В общих чертах – вы общаетесь не с самой gpt-5.6-sol в полноценном кодекс агенте, а с тупенькой моделькой gpt-realtime-1. Тупенькой, но быстрой. И заточенной под диалоговый формат с переживаниями – без этого естественности не добиться и любое общение будет мучением. Так вот, пока у этой модельки хватает сил самой с вами общаться - она будет. Но как только нужно будет сделать что-то сложное, она побежит к кодекс агенту и даст ему задачку. В этот момент сразу же скажет вам что-то вроде «ну-ка дай подумаю» или «так, разбираюсь». Это важно, чтобы мы чувствовали непрерывность общения – как с людьми Такой типа эффект Джарвис. И это реально работает! Получается интересная система, очень похожая на ту, которая бывает в обычных айти командах: - есть менеджер, который всегда онлайн и быстро отвечает, и который общается с заказчиком - есть исполнитель (например, разработчик), который пилит фичу и отвечает по несколько часов в перерывах между сфокусированной работой А менеджер ему еще по ходу докидывает задачки, если у заказчика появились новые хотелки Что интересного из этого следует для нас как для пользователей: 1. Если в процессе выполнения слишком много докидывать новые хотелки, то результат получится плохим: если вы когда то пробовали отправлять steer сообщения в чат работающему агенту, то вы скорее всего замечали – они часто его слишком сбивают с начального пути (ну реально, все как с человеками) 2. Как и в реальных командах, если хотите рулить через одного менеджера несколькими процессами – нужен еще тимлид для команды. Поэтому можно просить выступать в этой роли и ничего не делать самому, а для всех задач на исполнение создавать либо отдельные чаты, либо субагентов. Тогда получится: Менеджер ⬇️ Тимлид ↙️⬇️↘️ Исполнитель1, Исполнитель2, ..., ИсполнительN Тогда выполнение одной задачи не будет блочить главного думающего агента и будет наш привычный опыт, когда в параллель работают несколько чатов, но только с голосом в качестве канала передачи инфы Что тут полезного для тех, кто сам делает AI продукты/фичи Мне кажется, можно забрать сам подход с тем, что сессия основного агента не видна пользователю напрямую, а есть какой-то прокси уровень коммуникации. И это не обязательно должен быть голос. Это может быть какой-то визуальный слой (скоро поделюсь своими экспериментами с Liquid UI), или даже обычный текстовый, но в привычном интерфейсе условного Slack, с быстро отвечающей моделью, которая подтягивает контекст из сессии умного, но долгого агента Ну и если вы делаете голосовых роботов, то советую отправить агента посмотреть, в чем отличие вашей системы от кодекса – мб захотите что-то к себе перетащить И последнее – если вы хотите лучше разбираться в том, как сейчас строить ИИ продукты, но еще почему-то не реверсите реализацию топовых кодинговых агентов – очень советую начать. Это прям кладезь лучших практик

P.s. я, конечно, очень сильно упростил работу менеджеров – на самом деле они делают гораздо больше, чем gpt-realtime-1. Это просто самая близкая и наглядная аналогия, которую я придумал. Если у вас есть лучше, прошу в комменты

@ai_grably

Как словить вайб: разработка, паяльник, пчёлы и попытки убедить семью, что ты не сошёл с ума Затея была чисто софтверная. Человек с 15 годами пасеки за плечами и основной работой в IT решил научиться вайбкодить, взять близкую идею и написать сервис, особо не утруждаясь. Идея нашлась быстро — автоматизация пасеки, ведь мёд он качает ровно по методикам дедов, а на дворе XXI век. Кончилось всё паяльником, флюсом, одним сожжённым стабилизатором и конфликтом с ИИ. Готовые пасечные весы просят от 9 до 37 тысяч за улей, так что весы пришлось собирать самому на тензодатчиках. Пару месяцев спустя человек, который автоматизирует градообразующие заводы, но паяльник за всю жизнь держал считаные разы, ловит момент, где ИИ-агент кричит на него капсом, что его обманули и время потрачено впустую.

НЕ БОЙТЕСЬ НЕСОВЕРШЕНСТВА И ПРИ ЧЕМ ТУТ НОВЫЙ АЙФОН Скорее всего, те вещи, которыми сегодня вы любите пользоваться ежедневно, когда-то тоже доделывались в последние часы перед дедлайном и сдавались в огне. Мой любимый пример. Когда Джобс в 2007 со сцены менял мир, презентуя первый Айфон, у компании на тот момент не было ни одного полностью работающего прототипа. Разные функции смартфона он демонстрировал на разных устройствах. При этом у всех образцов была общая проблема с плохим приемом сигнала связи, поэтому за сценой пришлось установить отдельную сотовую подстанцию. Еще было много строгих инструкций, как Джобс должен был держать телефон во время презентации, включая определенные углы наклона, чтобы избежать проблем с плохой работой сенсорного экрана и других сырых функций. Нет большого смысла сразу делать все идеально, достаточно создать продукт, который будет хорош для запуска первых продаж и получения обратной связи, а дальше вас ждет бесконечное докручивание по мере роста и масштабирования. Кстати, на недавней презентации последнего Айфона лайв-демонстрации опять не было, как это любил Джобс. Иронично, что Стив в 2007 умудрился на огромной сцене провести идеальную презентацию на полуработающих прототипах. А спустя почти 20 лет новый CEO Apple после презентации нового Айфона с дрожащими руками вышел показать готовую серийную можель блогеру и у него не получилось с первого раза.

🛬 ОБУЧАЮЩАЯ ИГРА 🛬 Ну что, други. Глядя на возможности нейронок, все чаще посещает мысль, что мы наконец-то приблизились к созданию настоящей обучающей гейм-дизайну игры 🖱 Но просто тесты на основе прочитанного делать неинтересно, да и это не совсем игра, а геймификация. А раз уж нас тут много, и все мы как будто гейм-дизайнеры, то предлагаю поштурмить на тему СОЗДАНИЕ ОБУЧАЮЩЕЙ ГЕЙМ-ДИЗАЙНУ ИГРЫ Разумеется, силами нашего сообщества. То есть нужно понимать, что у нас есть ряд серьёзных ограничений по ресурсам — например, хорошо бы, чтобы игра была сделана 1 программистом 🖲 Хорошо бы добавить, что графику и анимации мы будем генерировать с помощью ИИ 💢 Да и вообще игра должна быть простой в создании. Чтоб ее можно было сделать за неделю. По крайней мере качественный вертикальный срез 〰️ Мне вот первое, что приходит на ум, это платформер с прокачкой навыков и выпадением лута и финальными боссами в виде известных в наших кругах гд. (Не отпускает меня эта идея "школ гейм-дизайна", Гимельрейх в славянском сеттинге, Вова в шляпе мухомора, злой (имя не придумал) кот в образе.. Хм.. Кота). Чур, место главного босса занято мной, ну раз уж это творческое высказывание Практики гейм-дизайна 📿 Но как передавать знания посредством геймплея, как давать очки распределения опыта за прокачку скилла в гейм-дизайне? Или решать квест на основе полученных знаний? 🖤 У вас есть идеи? Поштурмим? 💞

The Agentic OS & Skill Ecosystem Выложил свою экосистему для ИИ агентов Здесь собраны фреймворки и скиллы: 1. Разработка и Инженерия 2. Автоматизация процессов 3. Личная продуктивность и База знаний 4. Продуктовый менеджмент 5. UI/UX и Дизайн-системы 6. Тексты, Копирайтинг и Де-слоппинг 7. Исследования, Анализ и SOTA 8. Бизнес, Стратегия и Продажи 9. Маркетинг, SEO и Аналитика 10. Операционка и Делегирование 11. ИИ-оптимизация и Безопасность 12. Мета-навыки и Аудит А также фреймворки для разработки продуктов: 1.Git. Ship. Done 2. Superpowers 3. Autonomous Dark Factory 4. Arscontexta == 🔗 https://github.com/Asmadey/skills

🔥 Stanford + MIT: производительность ИИ зависит не только от модели, но и от harness вокруг неё Новая работа Meta-Harness: End-to-End Optimization of Model Harnesses показывает важную вещь: один и тот же LLM может давать радикально разные результаты в зависимости от того, как устроен surrounding system code. Harness решает: - что хранить в контексте - что извлекать из памяти - какие данные показывать модели - как вызывать инструменты - как обрабатывать ошибки и повторные попытки - как вообще строится workflow агента На одном и том же benchmark разница между harness может доходить до 6× при неизменной базовой модели. Авторы предлагают Meta-Harness — внешний optimization loop, который автоматически улучшает код harness. Вместо одного score он получает доступ к: code → logs → execution traces → previous attempts через filesystem-like среду и на основе этого переписывает сам harness. Результаты: - +7,7 пункта на online text classification относительно сильного SOTA context management - при этом примерно в 4 раза меньше context tokens - +4,7 пункта в среднем на retrieval-augmented math reasoning по 5 held-out моделям и 200 задачам уровня IMO - на agentic coding найденные harness обошли сильные hand-engineered baselines на TerminalBench-2 Главный вывод работы: вопрос уже не только в том, “какая модель лучше”, а в том, “как построена вся система вокруг модели”. Для production это напрямую влияет на reliability, tool use, context management, recovery после ошибок и стоимость запуска. Paper: https://arxiv.org/abs/2603.28052

Ассемблер неправильная абстракция Каждый раз когда заходит речь о повышении уровня абстракции, в разговоре всплывает ассемблер в стиле "когда то мы писали на нем, а теперь не пишем". Особенно часто это повторяют сейчас в эру AI. Честно говоря, мне это никогда не казалось правильным сравнением и кажется я могу объяснить почему. Переход от ассемблера к языкам высокого уровня был переходом от слишком низкого уровня завязанного на технические детали, к конструкциям, которые которые задают базис для построения программ практически любой сложности. И вот этот уровень принципиально не менялся десятки лет. Менялись языки, платформы, библиотеки и способы организации кода, но сам программист продолжал работать примерно с теми же конструкциями. Программа на современном языке устроена концептуально почти так же, как программа пятьдесят лет назад. Но после этого характер повышения абстракции изменился. Мы больше не поднимались от технической реализации к естественной модели вычислений. Мы пытались подняться от программирования к описанию намерения, того, что должна делать система, и автоматически получить реализацию. Cobol был одной из первых попыток подняться от описания вычислений к описанию бизнес-намерений. Предполагалось, что программы на похожем на английский языке смогут читать и, возможно, писать сами специалисты бизнеса. Но понятный синтаксис не устранил сложность программирования. Для точного описания поведения все равно понадобились переменные, условия, циклы, структуры данных и процедуры. В результате cobol стал успешным языком для бизнес-систем, но не стал языком самого бизнеса, так как писали на нем по-прежнему программисты. Успешные примеры появились там, где намерение удалось ограничить конкретной и хорошо формализованной областью. Хорошие примеры это регулярки, sql, html/css или terraform. Это конечно еще не бизнес уровень, но уже что-то. Для разработки произвольных программ такую модель создать не получилось. Как только языку намерений требовалось описывать нестандартное поведение, в нем появлялись все привычные конструкции. Постепенно он снова превращался в обычный язык программирования, только с другим синтаксисом и новым набором абстракций. Это хорошо видно на примере BDD. В изначальной идее сценарии на языке, понятном бизнесу, должны были стать общей спецификацией системы и одновременно основой для автоматической проверки. Но довольно быстро выяснилось, что реальные сценарии либо остаются понятными, но описывают только верхний уровень поведения, либо становятся достаточно точными для исполнения, но обрастают техническими деталями и фактически превращаются в еще один код. А между сценариями и работающей системой все равно остается большая часть логики, которую кто-то должен спроектировать и реализовать. Я не думаю, что AI решает эту проблему. Спецификация произвольной системы либо остается неполной, и тогда множество неописанных решений агент принимает самостоятельно, либо обрастает правилами, исключениями, состояниями и способами обработки ошибок и по сложности начинает приближаться к самой программе. AI может значительно увеличить расстояние от намерения до кода и избавить нас от ручной реализации многих деталей, но он не создает универсального уровня абстракции, на котором можно точно описывать любые системы и при этом не программировать. Я был бы рад ошибиться, но пока не вижу предпосылок. А как вы думаете?

Хорошее время для QA-инженеров. Часто слышу тезисы в духе:

AI-coding убил QA

Это не так. Точнее – не совсем так. Если мы внедряем AI-инструменты в процессы разработки, то написание кода достаточно сильно ускоряется. В зависимости от дисциплины и ответственности конкретного разработчика, это ускорение может в большей или меньшей степени влиять на качество производимого кода. Уже на первых этапах внедрения AI-инструментов в процессы разработки, мы получаем "затор" на стадиях ревью и тестирования. Этот затор кому-то придётся разгребать... Желательно – тоже с использованием AI в качестве инструмента. Здесь и появляется QA-инженер. Учитывая, что качество кода – одна из основных претензий к AI-generated-коду, роль грамотного QA (и грамотного QA внутри каждого разработчика) сильно повышается. QA-инженер отвечает за выстраивание quality-gates на разных этапах SDLC, а также организовывает процессы тестирования. QA-инженер даёт гарантию, что код, попавший в продакшн, соответствует конкретным критериям качества. Проблема в том, что в небольших командах QA-инженеры встречаются достаточно редко. Там чаще:

Ну, сидит у нас тестировщик, за плошку риса интерфейсы тыкает, проверяет, что они тыкаются

Эти тестировщики на процесс AI-SDLC влияют, скорее, негативно. Так как, под большим напором задач от AI-accelerated-разработчиков, выбора у них два – либо накапливать себе объёмы для тестирования, либо снижать качество проверок. В первом случае мы получаем нивелирование ускорения time-to-market, как одного из преимуществ AI-SDLC, а во втором – снижение стабильности прода. На этой неделе был "День тестировщика" (9 сентября). Я чуть опоздал с пожеланиями, но всё же: Пользуйтесь теми возможностями, которые предоставляют изменения на рынке. Изучайте глубже процесс AI-SDLC и то, как вы можете повлиять на качество кода на выходе. Потребность в QA-инженерах, способных работать в цикле AI-SDLC, будет только расти. Вопрос для дискуссии: Готовы ли QA-инженеры заменить в формате Tiny-teams разработчиков, не бравших на себя ранее ответственность за то, что их задача доедет до прода?

Отвратительные вопросы для Гофера Автор собрал вопросы по Go, которые в реальной работе почти не встречаются. Вызвать приватную функцию из чужого пакета, объяснить, чему равна длина слайса, почему у пустых структур могут совпадать адреса. Знать это, чтобы писать код, необязательно. Зато по тому, как кандидат отвечает, видно, отвечает он сам или подсовывает вопрос модели. Логика тут двойная. На части вопросов срабатывает то, как именно приходит ответ, и это выдаёт того, кто спрашивал не свою голову. А есть зеркальные вопросы, где всё переворачивается. Живой разработчик отвечает спокойно, а модель уверенно ошибается, потому что до нужной версии Go её знания просто не дотягивают.

А чё, так можно было? Недокументированный C# В C# есть четыре ключевых слова, которых нет в документации, но компилятор их спокойно принимает. Одно из них объявляет метод с переменным числом аргументов без всяких массивов. Собирается такой код без единого предупреждения, отрабатывает на Windows и честно выводит переданные значения. Ту же самую сборку переносят на Ubuntu — и вместо результата прилетает InvalidProgramException с сообщением, что соглашение вызова не поддерживается. Байты те же, машина архитектурно та же, x64, а поведение разное, и падает при этом не сам метод, а код, который его вызывает. Разберёмся, почему одна проверка в джите решает судьбу всей сборки.

Создавать или нет На последнем ИИ-хакатоне шесть команд, собранных из незнакомых друг с другом людей, за 90 минут собрали работающий сервис. Он принимает бриф, пишет сценарий, генерирует видеоролик и отправляет результат клиенту. Пару лет назад на такое потребовались деньги и месяцы работы. Сегодня — полтора часа и кофе :) Раньше создавать продукт было дорого и ты десять раз думал, что именно строить. Искал клиентов, выбирал функции, отбрасывал лишнее. Теперь в субботу встал с идеей, в воскресенье — у тебя приложуха с авторизацией, кабинетом и оплатой. Никому не нужная, зато работающая. Y Combinator говорил 30 лет стартаперам: 1. Быстро запусти хоть что-нибудь 2. Поговори с пользователями 3. Сделай то, что им нужно Справедливо, когда главное препятствие — разработка. Сейчас сложность — понять, что вообще стоит создавать. Поэтому и порядок действий перевернут: 1. Найди пользователей чужих продуктов 2. Узнай, за что платят и что бесит 3. Продай решение до разработки 4. Создай только то, что купили Раньше стартапы умирали из-за неумения построить продукт. Теперь из-за умения.

Джуны перестали быть дешёвыми Ещё несколько лет назад всё было просто: ''сильные спецы стоят дорого, берём молодых и растим под себя''. Сейчас это уже не выгодно и вот почему: Наставник нужен дольше, чем на время стажировки. Он ведёт человека до пре-мидла. Всё это время старший разработчик сидит в чужом коде, а не в проектах. Первые полгода вы платите дважды. Человек долго заходит в проекты, качество кода низкое, баги за ним правят другие. Через шесть-восемь месяцев он просит больше. Оставаясь при этом по уровню джуном. Поднять зарплату всем джунам разом — так себе вариант. Джуны часто уходят на пре-мидле. До этого грейда человек учится за ваш счёт, а в полную отдачу начинает работать, являясь мидлом. Получается, обучение оплатили целиком вы, а работать в полную силу он идёт уже к другим. Кто уже мидл и старше, обычно остаётся надолго — но таких доходит мало. Про грейды, конечно, можно говорить бесконечно, но всё сводится к цифрам. Проектная маржинальность — главный показатель производства. Под ней должны быть отчёты по часам: сколько отработано и сколько оплачено. И ещё два процента: доля сорванных сроков и доля верных оценок. Соберите это по проектам за квартал в разрезе людей. Может выйти, что дорогой мидл приносит больше маржи, чем трое дешёвых. Поэтому многие студии разработки джунов уже не берут, риски слишком высоки. А как у вас, нанимаете ещё джунов? Удачный опыт или пожалели? Расскажите в комментариях 👇

Нелепости агентов Агентная разработка - веселая штука конечно. Вот планируешь и кодишь несколько дней с Астрой, Фейблом и Опусом, а потом на e2e вот такое вот выясняется (см. скрин и пояснения в конце). И это прям системная история - 99% получается хорошо и правдоподобно, а в каком-то неожиданном месте Но справедливости ради - это был сложный и огромный кусок работы на десятки тысяч строк кода, хоть и делался в лучших традициях SDD с хорошим планом. Выводы? 1. Делайте e2e тесты - причем как классические через условный Playwright / XCUIAutomation и тд, так и агентные "JIT" тесты - когда агент сам запускает вашу систему в около продовых условиях и ведет себя как Manual QA. 2. Рефлексируйте - если все-таки что-то вылезло несмотря на все ваши пятьсон уровней гардрейлов, обязательно ищите источник проблемы - то есть, в какой момент вашей даркфактори агентного пайплайна вылеза ошибка и как она вообще дошла до live e2e. * Контекст: я разрабатываю агентный интерфейс к одному из своих проектов (в данном случае - это MCP + skill) и вот там оказалось, что ответ в во всех MCP инструментах просто дублируется (структурированный + обычный текст) - абсолютно комичный дефект, который добрался аж до финальной стадии верификации. Live e2e же там устроен так, что сильный агент тестирует другого агента на предмет того, как тот справляется с задачами из юз кейсов - и то, как быстро он справляется, и сколько токенов у него на задачу уходит. Это, кстати, правильный подход и к evals скиллов тоже. Если тоже сталкивались с подобными нелепостями агентов - расскажите в комментариях что это было и как боролись. @ai_driven

💎Две Astra-новости💎 1. OpenAI признала проблемы с Astra и выкатила исправления. По словам Тибо, старые скиллы слишком часто срабатывали и иногда мешали модели проверять свою работу. Эксперимент с управлением контекстом приводил к преждевременным остановкам и ответам на старые сообщения; он затронул примерно 4–5 тысяч пользователей, его отключили. Также убрали неудачно настроенные серверные конфигурации, на которых измеримо падало качество. Обещают, что Astra будет лучше доводить задачи до конца и учитывать последние сообщения. Заодно анонсировали очередной сброс лимитов в ближайшие часы🐈 Пост Тибо. 2. OpenAI советует почистить старые инструкции для Codex. Компания выкатила руководство по скиллам, AGENTS.md и промптам для Astra: накопленные правила могут перегружать контекст, конфликтовать и заставлять модель останавливаться без необходимости. Рекомендуют точнее прописывать условия запуска скиллов, подгружать документацию по задаче и убрать обязательное «прочитай весь проект перед любой правкой». Особенно важно заранее объяснять, что считать завершением: например, реализовать, запустить, проверить результат и исправить ошибки. В помощь обновили skill-creator. Официальный разбор.

Ладно, мухи - это круто, но я к вам пожаловаться. Нужно было по работе сделать довольно простую тулзу. Копировать дескрипшен задачи из Jira в Bitrix. Просто, да? Но нет! Во-первых, это расширение для браузера, во-вторых, должно работать со всеми браузерами, нужно было шарить это на команды, а работает кто в чем. Третье: нельзя пользоваться API Jira. Пятое: нужно копировать и картинки, и текст со всем форматированием. Есть ещё пермишены самого браузера для расширений. В общем, нюансов масса, как оказалось. И тут я думаю заюзаю Astra, AGI ведь уже с нами. Sol пару раз ломал уже работающий функционал, и пришлось переключиться. По наблюдениям думать он стал дольше, но и результат стал чище, больше гипотез, самопроверок, тестирования. Но у этого есть и обратная сторона, токены жгутся как на Камчатке в -50 в котельной. Доходит до смешного, когда я попросил собрать Zip архив со стабильной версией, он думал минуты 2, запуская проверки стабильной версии, и сжег где-то 25% дневного лимита 😣 Вау, это Альтман классно придумал! В общем, будьте аккуратны, Astra очень прожорлива даже на простых задачах, поэтому используйте соответственно задаче. @CGIT_Vines