Почему инженерная обвязка стала важнее самой нейросети?
Коллеги, на Хабре вышла текстовая версия нашего интервью с Андреем Носовым — техническим директором и ИИ-архитектором.
Оно о феномене OpenClaw, который за три месяца набрал 250 тысяч звезд на GitHub — быстрее, чем Linux за всю свою историю. А еще о том, почему автономные агенты без Human-in-the-Loop опасны, как три слоя Guardrails ловят команду rm -rf, и зачем сажать тысячу агентов на Kafka.
Интервью можно посмотреть на нашем YouTube-канале (подпишитесь, чтобы не пропускать новые видео).
В тексте:
- почему современные модели — это не исполнители, а декораторы формы ответа
- как Pydantic-схемы и retry-паттерны обуздывают недетерминированный хаос
- зачем нужен трейсинг естественного языка и какие фреймворки для этого подходят (Langfuse, Arize Phoenix, LangSmith)
- как протоколы A2A и MCP решают проблему vendor lock-in — и почему добавляют latency
- что произойдет с рынком обвязок, если завтра появится «идеальный Джарвис»
- почему 2026 — это год агентов, а не моделей
Если строите агентные системы в продакшене или только присматриваетесь к ним — прочитайте и поддержите статью плюсом на Хабре, нам это важно.
👉 https://habr.com/ru/articles/1024744/
Коллеги, на Хабре вышла текстовая версия нашего интервью с Андреем Носовым — техническим директором и ИИ-архитектором.
Оно о феномене OpenClaw, который за три месяца набрал 250 тысяч звезд на GitHub — быстрее, чем Linux за всю свою историю. А еще о том, почему автономные агенты без Human-in-the-Loop опасны, как три слоя Guardrails ловят команду rm -rf, и зачем сажать тысячу агентов на Kafka.
Интервью можно посмотреть на нашем YouTube-канале (подпишитесь, чтобы не пропускать новые видео).
В тексте:
- почему современные модели — это не исполнители, а декораторы формы ответа
- как Pydantic-схемы и retry-паттерны обуздывают недетерминированный хаос
- зачем нужен трейсинг естественного языка и какие фреймворки для этого подходят (Langfuse, Arize Phoenix, LangSmith)
- как протоколы A2A и MCP решают проблему vendor lock-in — и почему добавляют latency
- что произойдет с рынком обвязок, если завтра появится «идеальный Джарвис»
- почему 2026 — это год агентов, а не моделей
Если строите агентные системы в продакшене или только присматриваетесь к ним — прочитайте и поддержите статью плюсом на Хабре, нам это важно.
👉 https://habr.com/ru/articles/1024744/
🔥9❤4👍2🤡1
Агент, который просто выполняет промпт, — это уже немного legacy. Интереснее архитектура, где агент самосовершенствуется: после работы анализирует результат и переписывает собственные инструкции.
После каждого запуска агент проводит анализ улучшений — почти как «собрание самокритики» в КНДР: модель делает попытку, разбирает ошибку и использует текстовый feedback как память. Практичная инженерная схема: run → trace → critique → prompt/context update → next run. Слова для гугления: Self-Refine и Reflexion.
Это похоже на Систему 1 и Систему 2 мышления, описанные Даниэлем Канеманом в книге «Думай медленно… решай быстро». Система 1 — быстрый автопилот: сгенерировал ответ по привычным паттернам. Система 2 — медленный контур проверки: остановился, посмотрел назад, нашел, где произошла галлюцинация, неверный вызов субагента или плохая декомпозиция, и добавил новое правило в рабочую память агента.
Эффективность в том, что такой контур работает и на стадии разработки агента, и уже в эксплуатации. На разработке он быстрее находит слабые места в промптах, tools и декомпозиции задач. В проде — постепенно накапливает рабочие правила из реальных запусков: какие ошибки повторяются, где нужен другой порядок действий, какие проверки надо добавить. Со временем это может дать заметный отрыв от агента, который однажды настроили и оставили шуршать с готовым промптом.
И, конечно, без evals и golden dataset это превратится не в self-improvement, а автоматизированное самооправдание, агент (как и все мы) может красиво объяснять свои ошибки, вместо того, чтобы исправлять их.
После каждого запуска агент проводит анализ улучшений — почти как «собрание самокритики» в КНДР: модель делает попытку, разбирает ошибку и использует текстовый feedback как память. Практичная инженерная схема: run → trace → critique → prompt/context update → next run. Слова для гугления: Self-Refine и Reflexion.
Это похоже на Систему 1 и Систему 2 мышления, описанные Даниэлем Канеманом в книге «Думай медленно… решай быстро». Система 1 — быстрый автопилот: сгенерировал ответ по привычным паттернам. Система 2 — медленный контур проверки: остановился, посмотрел назад, нашел, где произошла галлюцинация, неверный вызов субагента или плохая декомпозиция, и добавил новое правило в рабочую память агента.
Эффективность в том, что такой контур работает и на стадии разработки агента, и уже в эксплуатации. На разработке он быстрее находит слабые места в промптах, tools и декомпозиции задач. В проде — постепенно накапливает рабочие правила из реальных запусков: какие ошибки повторяются, где нужен другой порядок действий, какие проверки надо добавить. Со временем это может дать заметный отрыв от агента, который однажды настроили и оставили шуршать с готовым промптом.
И, конечно, без evals и golden dataset это превратится не в self-improvement, а автоматизированное самооправдание, агент (как и все мы) может красиво объяснять свои ошибки, вместо того, чтобы исправлять их.
❤9👍2💯1
Грядет смена парадигмы в технологиях искусственного интеллекта. Чего же ждать? Владимир Крылов, доктор технических наук и научный консультант по применению ИИ в разработке ПО, даст свой прогноз.
1️⃣ Рассмотрим тренды в технологическом аспекте ИИ и обнаруженные "бутылочные горлышки", препятствующие росту интеллекта у строящихся систем.
2️⃣ Кроме очевидных проблем энергопотребления для масштабирования обучения и эксплуатации систем ИИ, поговорим о проблеме "стены памяти" (Memory Wall), приводящей к разработке нового аппаратного обеспечения и, как следствие, к новым парадигмам hardware.
3️⃣ Познакомимся с новой парадигмой алгоритмического построения ИИ — рассуждениям в латентном пространстве с прогнозируемым тысячекратным увеличением энергоэффективности систем ИИ при росте производительности на 60%.
Вы услышите авторскую интерпретацию вышедших за последние месяцы публикаций ведущих компаний и университетов.
⏩ Смотрите на YouTube или RuTube!
И подписывайтесь на наши каналы, чтобы не пропустить следующие лекции☺️
Вы услышите авторскую интерпретацию вышедших за последние месяцы публикаций ведущих компаний и университетов.
И подписывайтесь на наши каналы, чтобы не пропустить следующие лекции
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥6❤1❤🔥1🤡1👀1
Одна и та же модель ИИ может стоить в 30 раз дороже и работать в 7 раз медленнее.
Все зависит от того, в какую агентную оболочку ее обернули. Это главный итог нового Coding Agent Index от Artificial Analysis. Команда впервые системно замерила не сами LLM, а их связки с оболочками вроде Claude Code, Cursor CLI, Codex и Gemini CLI. Логика проста: при работе с ИИ-агентом разработчик фактически выбирает не модель, а пару. Индекс сводит три бенчмарка: SWE-Bench-Pro-Hard-AA от Scale AI (150 сложных задач разработки), Terminal-Bench v2 от Laude Institute (84 терминальные задачи) и SWE-Atlas-QnA (124 вопроса о поведении кода).
По качеству впереди ожидаемая верхушка. Opus 4.7 в Cursor CLI набирает 61 балл, GPT-5.5 в Codex и Opus 4.7 в Claude Code идут вровень с 60, GPT-5.5 в Cursor CLI замыкает четверку с 58. Open weights подбираются, но пока не догнали: лучший результат у GLM-5.1 в Claude Code (53), за ним Kimi K2.6 и DeepSeek V4 Pro в той же оболочке по 50.
Самое интересное начинается, когда к баллам приставляют экономику. Цена задачи разнится более чем тридцатикратно: GPT-5.5 в Codex обходится в $2.21, GLM-5.1 в Claude Code в $2.26 (у последней на цену работает срыв модели в циклы на отдельных задачах). На другом полюсе Composer 2 в Cursor CLI всего за $0.07. По времени картина похожая: Opus 4.7 в Claude Code справляется с задачей примерно за шесть минут, Kimi K2.6 в той же оболочке тратит около сорока.
Заметнее всех тут отличилась Cursor. Их собственная Composer 2, по заявлению команды построенная на базе Kimi K2.5, набирает 48 баллов почти на уровне лучших open weights и остается самой дешевой связкой индекса. Редкая иллюстрация того, что прицельный пост-тренинг под конкретную оболочку дает измеримый выигрыш. Обратный случай у Google: Gemini 3.1 Pro в Gemini CLI получает лишь 43 балла, заметно ниже позиций самой модели в общем Intelligence Index. Узкое место не в модели, а именно в оболочке.
Все зависит от того, в какую агентную оболочку ее обернули. Это главный итог нового Coding Agent Index от Artificial Analysis. Команда впервые системно замерила не сами LLM, а их связки с оболочками вроде Claude Code, Cursor CLI, Codex и Gemini CLI. Логика проста: при работе с ИИ-агентом разработчик фактически выбирает не модель, а пару. Индекс сводит три бенчмарка: SWE-Bench-Pro-Hard-AA от Scale AI (150 сложных задач разработки), Terminal-Bench v2 от Laude Institute (84 терминальные задачи) и SWE-Atlas-QnA (124 вопроса о поведении кода).
По качеству впереди ожидаемая верхушка. Opus 4.7 в Cursor CLI набирает 61 балл, GPT-5.5 в Codex и Opus 4.7 в Claude Code идут вровень с 60, GPT-5.5 в Cursor CLI замыкает четверку с 58. Open weights подбираются, но пока не догнали: лучший результат у GLM-5.1 в Claude Code (53), за ним Kimi K2.6 и DeepSeek V4 Pro в той же оболочке по 50.
Самое интересное начинается, когда к баллам приставляют экономику. Цена задачи разнится более чем тридцатикратно: GPT-5.5 в Codex обходится в $2.21, GLM-5.1 в Claude Code в $2.26 (у последней на цену работает срыв модели в циклы на отдельных задачах). На другом полюсе Composer 2 в Cursor CLI всего за $0.07. По времени картина похожая: Opus 4.7 в Claude Code справляется с задачей примерно за шесть минут, Kimi K2.6 в той же оболочке тратит около сорока.
Заметнее всех тут отличилась Cursor. Их собственная Composer 2, по заявлению команды построенная на базе Kimi K2.5, набирает 48 баллов почти на уровне лучших open weights и остается самой дешевой связкой индекса. Редкая иллюстрация того, что прицельный пост-тренинг под конкретную оболочку дает измеримый выигрыш. Обратный случай у Google: Gemini 3.1 Pro в Gemini CLI получает лишь 43 балла, заметно ниже позиций самой модели в общем Intelligence Index. Узкое место не в модели, а именно в оболочке.
🔥10👍8
SpecKit: описываем фичи вместо того, чтобы сразу писать код
Лёша Берёзка, техлид iOS в Додо Пицце и автор канала о разработке, покажет в онлайне, как упростить разработку с помощью инструмента SpecKit от GitHub.
➡️ Разберём, как описывать то, что нам надо от продукта, с помощью SpecKit и что это даёт в перспективе.
➡️ Реализуем одну фичу с нуля до рабочего состояния.
Когда?
Завтра, 13 мая, в 13:00.
Смотрите на YouTube или прямо в этом канале — и задавайте вопросы Лёше!
Лёша Берёзка, техлид iOS в Додо Пицце и автор канала о разработке, покажет в онлайне, как упростить разработку с помощью инструмента SpecKit от GitHub.
Когда?
Завтра, 13 мая, в 13:00.
Смотрите на YouTube или прямо в этом канале — и задавайте вопросы Лёше!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🤡4
ИИ ускоряет разработку на 35-40% на новом коде и всего на 10% на легаси
Первый год после внедрения большинство команд просто проседает в производительности. Это главные цифры из свежего отчета DORA по экономике ИИ-разработки.
DORA выпустила первую внятную методичку по расчету ROI от внедрения ИИ в разработку и онлайн-калькулятор в придачу. Главный посыл идет вразрез с продающей риторикой вендоров: ИИ сам по себе ничего не ускоряет, он только усиливает то, что уже есть. Если у команды зрелая платформа и нормальные процессы, отдача приходит быстро. Если деплой все еще ручной, тесты хрупкие, а контекста модели взять негде, ИИ просто разгоняет накопление техдолга.
Если нарисовать график производительности команды до и после внедрения ИИ, получится буква J: сначала несколько месяцев просадки ниже исходного уровня, потом резкий выход вверх. Эту траекторию у DORA и называют J-кривой.
В типовом расчете провал составляет 15% производительности на три месяца. Объяснение бытовое: люди разбираются с инструментом, ревью съедает больше времени, чем раньше, а конвейер не тянет внезапно выросший поток коммитов. На этом этапе руководители часто решают, что инструмент не работает, и закрывают бюджет. Так и хоронят вполне окупаемые внедрения.
DORA подтвердила цифрами и второе неприятное наблюдение: после внедрения ИИ деплои начинают чаще ломаться, а не реже. Объем кода растет быстрее, чем способность ревью и пайплайнов его переварить. Привычное трение в работе разработчика никуда не делось, оно просто сдвинулось. Раньше время уходило на написание рутины, теперь оно уходит на проверку того, что нагенерил ИИ. Авторы отчета называют это «налогом на верификацию».
Финансовая часть построена вокруг онлайн-калькулятора. На входе размер штата, средняя стоимость инженера в год, расходы на лицензии и обучение, ожидаемые глубина и длительность J-кривой.
На выходе совокупные затраты первого года, ожидаемый возврат, ROI и срок окупаемости. Горизонт намеренно ограничен одним годом: он самый сложный из-за просадки, дальше цифры можно экстраполировать самим. Внутри есть переключение между консервативным, базовым и оптимистичным сценариями, а отдельные источники ценности можно обнулить, если CFO будет придираться к «мягким» статьям вроде дополнительной выручки от ускоренного выпуска фич.
На стандартном примере команды из 500 инженеров калькулятор выдает 39% ROI за первый год при окупаемости около восьми месяцев. Любопытнее процентов выглядит структура затрат: стоимость inference за последние два года упала в 280 раз, и основные деньги теперь не на токенах, а на governance: верификации сгенерированного, переделке пайплайнов, обучении людей. Кто пытается ужать бюджет за счет дешевых моделей, тот ужимает не ту часть.
Первый год после внедрения большинство команд просто проседает в производительности. Это главные цифры из свежего отчета DORA по экономике ИИ-разработки.
DORA выпустила первую внятную методичку по расчету ROI от внедрения ИИ в разработку и онлайн-калькулятор в придачу. Главный посыл идет вразрез с продающей риторикой вендоров: ИИ сам по себе ничего не ускоряет, он только усиливает то, что уже есть. Если у команды зрелая платформа и нормальные процессы, отдача приходит быстро. Если деплой все еще ручной, тесты хрупкие, а контекста модели взять негде, ИИ просто разгоняет накопление техдолга.
Если нарисовать график производительности команды до и после внедрения ИИ, получится буква J: сначала несколько месяцев просадки ниже исходного уровня, потом резкий выход вверх. Эту траекторию у DORA и называют J-кривой.
В типовом расчете провал составляет 15% производительности на три месяца. Объяснение бытовое: люди разбираются с инструментом, ревью съедает больше времени, чем раньше, а конвейер не тянет внезапно выросший поток коммитов. На этом этапе руководители часто решают, что инструмент не работает, и закрывают бюджет. Так и хоронят вполне окупаемые внедрения.
DORA подтвердила цифрами и второе неприятное наблюдение: после внедрения ИИ деплои начинают чаще ломаться, а не реже. Объем кода растет быстрее, чем способность ревью и пайплайнов его переварить. Привычное трение в работе разработчика никуда не делось, оно просто сдвинулось. Раньше время уходило на написание рутины, теперь оно уходит на проверку того, что нагенерил ИИ. Авторы отчета называют это «налогом на верификацию».
Финансовая часть построена вокруг онлайн-калькулятора. На входе размер штата, средняя стоимость инженера в год, расходы на лицензии и обучение, ожидаемые глубина и длительность J-кривой.
На выходе совокупные затраты первого года, ожидаемый возврат, ROI и срок окупаемости. Горизонт намеренно ограничен одним годом: он самый сложный из-за просадки, дальше цифры можно экстраполировать самим. Внутри есть переключение между консервативным, базовым и оптимистичным сценариями, а отдельные источники ценности можно обнулить, если CFO будет придираться к «мягким» статьям вроде дополнительной выручки от ускоренного выпуска фич.
На стандартном примере команды из 500 инженеров калькулятор выдает 39% ROI за первый год при окупаемости около восьми месяцев. Любопытнее процентов выглядит структура затрат: стоимость inference за последние два года упала в 280 раз, и основные деньги теперь не на токенах, а на governance: верификации сгенерированного, переделке пайплайнов, обучении людей. Кто пытается ужать бюджет за счет дешевых моделей, тот ужимает не ту часть.
🔥16🥴4
Мы периодически рассказываем про полезные инструменты, а сегодня покажем нашу собственную разработку BPMN-AI.
Это инструмент, который превращает описание процесса, регламент или расшифровку интервью в BPMN-модель: выделяет шаги, роли, условия, ветвления и подпроцессы.
Польза: практически мгновенно перейти от хаотичного описания «как у нас это работает» к схеме, которую можно обсуждать с бизнесом, аналитиками и разработкой.
Мы довольны качеством диаграмм на выходе: не зря изучали подходы наших аналитиков и на основе этих наблюдений прорабатывали агентскую логику.
Посмотреть, как работает: YouTube / VK Video
Связаться: здесь или через https://bpmnai.ru/
Это инструмент, который превращает описание процесса, регламент или расшифровку интервью в BPMN-модель: выделяет шаги, роли, условия, ветвления и подпроцессы.
Польза: практически мгновенно перейти от хаотичного описания «как у нас это работает» к схеме, которую можно обсуждать с бизнесом, аналитиками и разработкой.
Мы довольны качеством диаграмм на выходе: не зря изучали подходы наших аналитиков и на основе этих наблюдений прорабатывали агентскую логику.
Посмотреть, как работает: YouTube / VK Video
Связаться: здесь или через https://bpmnai.ru/
YouTube
BPMN-диаграммы из текста с помощью ИИ
Загрузите описание процесса или workflow — ИИ выделит этапы, участников, события и условия, после чего превратит текст в наглядную BPMN-диаграмму.
Подробнее о фреймворке: https://bpmnai.ru/
Подробнее о фреймворке: https://bpmnai.ru/
👍9👌1
Большая хакерская атака Mini Shai-Hulud бьет по разработчикам, которые пишут код с ИИ: через зараженные npm-пакеты вредонос попадает в JavaScript/TypeScript-проекты, закрепляется в .claude/settings.json и .vscode/tasks.json, а затем может запускаться снова даже после удаления пакета из node_modules.
Риск не ограничивается npm: если вредонос украл GitHub-, cloud-, npm/PyPI- или CI/CD-токены, атака может расползтись на Python-проекты, PyPI-пакеты, внутренние репозитории и сборочные пайплайны; технический разбор и индикаторы компрометации опубликованы у StepSecurity.
Риск не ограничивается npm: если вредонос украл GitHub-, cloud-, npm/PyPI- или CI/CD-токены, атака может расползтись на Python-проекты, PyPI-пакеты, внутренние репозитории и сборочные пайплайны; технический разбор и индикаторы компрометации опубликованы у StepSecurity.
😱8👍6
🤝 6 рукопожатий — почему информация находит короткий путь?
Известный эксперимент социолога Стэнли Милгрэма 1967 года открыл феномен "тесного мира" — любых двух людей разделяет малое число рукопожатий. Другими словами, сети имеют малый диаметр. Само по себе это свойство сложно считать чем-то удивительным — это скорее естественное свойство случайных графов. Впечатляющим было другое открытие: структура сети позволяет информации (письму) следовать коротким путём.
Этот феномен математически пытался объяснить Джон Клейнберг. В 2001 году он показал, как добиться нужного эффекта с помощью специальной конструкции: длинные связи строятся с вероятностью, обратно пропорциональной расстоянию. Однако сложно представить, что люди в реальной жизни формируют связи согласно такому принципу.
⚡️Как же естественные сети приобретают это свойство? Вследствие какого процесса? Александр Пономаренко представит модель геометрического предпочтительного присоединения, которая во многом проливает свет на эту загадку.
Александр Пономаренко — лауреат стипендии им. Ильи Сегаловича, IBM PhD Fellowship Award, научный сотрудник ИПФ РАН, научный сотрудник лаборатории алгоритмов и технологий анализа сетевых структур ЛАТАС, доцент кафедры прикладной математики и информатики НИУ ВШЭ.
Когда?
Завтра, 18 мая, в 12:00.
🎥 Смотрите на YouTube или прямо в этом канале — и задавайте вопросы лектору!
Известный эксперимент социолога Стэнли Милгрэма 1967 года открыл феномен "тесного мира" — любых двух людей разделяет малое число рукопожатий. Другими словами, сети имеют малый диаметр. Само по себе это свойство сложно считать чем-то удивительным — это скорее естественное свойство случайных графов. Впечатляющим было другое открытие: структура сети позволяет информации (письму) следовать коротким путём.
Этот феномен математически пытался объяснить Джон Клейнберг. В 2001 году он показал, как добиться нужного эффекта с помощью специальной конструкции: длинные связи строятся с вероятностью, обратно пропорциональной расстоянию. Однако сложно представить, что люди в реальной жизни формируют связи согласно такому принципу.
⚡️Как же естественные сети приобретают это свойство? Вследствие какого процесса? Александр Пономаренко представит модель геометрического предпочтительного присоединения, которая во многом проливает свет на эту загадку.
Александр Пономаренко — лауреат стипендии им. Ильи Сегаловича, IBM PhD Fellowship Award, научный сотрудник ИПФ РАН, научный сотрудник лаборатории алгоритмов и технологий анализа сетевых структур ЛАТАС, доцент кафедры прикладной математики и информатики НИУ ВШЭ.
Когда?
Завтра, 18 мая, в 12:00.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤2🔥1
Media is too big
VIEW IN TELEGRAM
SpecKit: описываем фичи вместо того, чтобы сразу писать код
Лёша Берёзка, техлид iOS в Додо Пицце и автор канала о разработке, показал в онлайне, как упростить разработку с помощью инструмента SpecKit от GitHub.
➡️ Разобрали, как описывать то, что нам надо от продукта, с помощью SpecKit и что это даёт в перспективе.
➡️ Реализовали одну фичу с нуля до рабочего состояния.
🎥 Запись доступна здесь и на других площадках:
YouTube
RuTube
ВКонтакте
ЯндексМузыка
Mave
Лёша Берёзка, техлид iOS в Додо Пицце и автор канала о разработке, показал в онлайне, как упростить разработку с помощью инструмента SpecKit от GitHub.
YouTube
RuTube
ВКонтакте
ЯндексМузыка
Mave
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🔥2💯2🤡1
Большие языковые модели - это настоящий интеллект?
В IT-сообществе не утихают горячие споры: есть ли в современных LLM (таких как Claude, ChatGPT или DeepSeek) хоть капля подлинного разума, или перед нами просто раздутая до триллионов параметров таблица поиска, угадывающая следующее слово?
В новом материале на Хабре вышло интервью с доктором технических наук и научным консультантом Artezio Владимиром Крыловым. В нем он подробно разбирает, что на самом деле происходит «под капотом» современных AI-систем и почему привычные метрики оценки интеллекта больше не работают.
О чем пойдет речь в статье:
🔹 Является ли колмогоровская сложность объективным критерием интеллекта?
🔹 Почему применять стандартные человеческие IQ-тесты к нейросетям бессмысленно?
🔹 Законы масштабирования (Scaling Laws) и почему время на «обдумывание» ответа в момент генерации меняет правила игры.
🔹 Феномен суперпозиции от Anthropic: почему смыслы запутаны так сложно, что мы никогда не сможем в прямом смысле «прочитать мысли» ИИ.
👉 Читать статью на Хабре
В IT-сообществе не утихают горячие споры: есть ли в современных LLM (таких как Claude, ChatGPT или DeepSeek) хоть капля подлинного разума, или перед нами просто раздутая до триллионов параметров таблица поиска, угадывающая следующее слово?
В новом материале на Хабре вышло интервью с доктором технических наук и научным консультантом Artezio Владимиром Крыловым. В нем он подробно разбирает, что на самом деле происходит «под капотом» современных AI-систем и почему привычные метрики оценки интеллекта больше не работают.
О чем пойдет речь в статье:
🔹 Является ли колмогоровская сложность объективным критерием интеллекта?
🔹 Почему применять стандартные человеческие IQ-тесты к нейросетям бессмысленно?
🔹 Законы масштабирования (Scaling Laws) и почему время на «обдумывание» ответа в момент генерации меняет правила игры.
🔹 Феномен суперпозиции от Anthropic: почему смыслы запутаны так сложно, что мы никогда не сможем в прямом смысле «прочитать мысли» ИИ.
👉 Читать статью на Хабре
👍5🤡1
В копилку Specification-Driven Development: Thariq Shihipar, инженер Anthropic из команды Claude Code, поделился полезным промптом для AI-агентов:
Смысл: агент не просто реализует спецификацию, а параллельно ведет заметки о том, где ему пришлось принимать решения самому.
Это помогает не превращать AI-разработку в черный ящик: Ведь, как бы тщательно вы ни описали спецификацию, всегда остаются неоднозначности и непредвиденные нюансы, которые всплывают в процессе. Этот подход даёт модели возможность принимать решения, но при этом держать вас в курсе.
Интересно, что Тарик рекомендует html, а не md.
implement <SPEC> and while you do, keep a running implementation-notes.html file (or markdown) with decisions you had to make weren't in the spec, things you had to change, tradeoffs you had to make or anything else I should know
Смысл: агент не просто реализует спецификацию, а параллельно ведет заметки о том, где ему пришлось принимать решения самому.
Это помогает не превращать AI-разработку в черный ящик: Ведь, как бы тщательно вы ни описали спецификацию, всегда остаются неоднозначности и непредвиденные нюансы, которые всплывают в процессе. Этот подход даёт модели возможность принимать решения, но при этом держать вас в курсе.
Интересно, что Тарик рекомендует html, а не md.
X (formerly Twitter)
Thariq (@trq212) on X
Claude Code @anthropicai. prev YC W20, @southpkcommons, @medialab
👍19❤3
Голосовой агент — это не просто чат-бот + TTS. Это эволюция от текстового бота через полудуплекс к full-duplex, где на каждом уровне появляются свои проблемы. Пройдем этот путь на реальном production-стеке (Rust, ~1600 строк).
Как построить голосового AI-агента, экономящего время пользователя, расскажет Виктор Загускин — руководитель центра компетенций голосового ИИ в MWS.AI.
В программе:
→ Голос, файловое распознавание: offline ASR, 3-7с roundtrip, SSML для склонений, LLM-нормализация услуг
→ Стриминг, полудуплекс: streaming ASR, VAD, гибридное EPD, порог тишины
→ Полный дуплекс: AEC (WebRTC AEC3), barge-in, tool calls в асинхронном потоке, pipeline parallelism
→ Метрики: покомпонентная latency, эволюция метрик, бенчмарки (Full-Duplex-Bench v1.5, EVA-Bench)
→ Native Audio LLM: speech-native модели, DuplexSLA, Moshi, MiniMind-O
Когда?
Завтра, 26 мая, в 12:00.
Смотрите на YouTube, в ВК или прямо в этом канале — и задавайте вопросы Виктору!
Как построить голосового AI-агента, экономящего время пользователя, расскажет Виктор Загускин — руководитель центра компетенций голосового ИИ в MWS.AI.
В программе:
→ Голос, файловое распознавание: offline ASR, 3-7с roundtrip, SSML для склонений, LLM-нормализация услуг
→ Стриминг, полудуплекс: streaming ASR, VAD, гибридное EPD, порог тишины
→ Полный дуплекс: AEC (WebRTC AEC3), barge-in, tool calls в асинхронном потоке, pipeline parallelism
→ Метрики: покомпонентная latency, эволюция метрик, бенчмарки (Full-Duplex-Bench v1.5, EVA-Bench)
→ Native Audio LLM: speech-native модели, DuplexSLA, Moshi, MiniMind-O
Когда?
Завтра, 26 мая, в 12:00.
Смотрите на YouTube, в ВК или прямо в этом канале — и задавайте вопросы Виктору!
🔥12❤1
⚡️ Что прячет Anthropic?
Claude Mythos — модель компании Anthropic, разработанная под кодовым названием Capybara. Это самая производительная модель в мире. Она наделала много шума, но так и не была выпущена в открытый доступ. И тем не менее избежать утечек информации не удалось...
Доктор технических наук Владимир Крылов проанализирует историю появления Claude Mythos и опишет хронологию уникального инцидента от ошибки конфигурации до изоляции. Поговорим о прорыве исторических трендов в прохождении бенчмарков и о 100% доминировании агента в области кибербезопасности.
Вы узнаете, как человечество впервые получило систему ИИ, представляющую собой почти идеальное кибероружие, и как поступили те, кто им владеет.
Мы взглянем на Claude Mythos как на черный ящик и посмотрим, какие предположения делают эксперты о том, как он устроен изнутри.
⏰ Запускаем трансляцию завтра, 28 мая, в 13:00.
Смотрите на YouTube, в ВК или прямо в этом канале — и задавайте вопросы лектору!
Claude Mythos — модель компании Anthropic, разработанная под кодовым названием Capybara. Это самая производительная модель в мире. Она наделала много шума, но так и не была выпущена в открытый доступ. И тем не менее избежать утечек информации не удалось...
Доктор технических наук Владимир Крылов проанализирует историю появления Claude Mythos и опишет хронологию уникального инцидента от ошибки конфигурации до изоляции. Поговорим о прорыве исторических трендов в прохождении бенчмарков и о 100% доминировании агента в области кибербезопасности.
Вы узнаете, как человечество впервые получило систему ИИ, представляющую собой почти идеальное кибероружие, и как поступили те, кто им владеет.
Мы взглянем на Claude Mythos как на черный ящик и посмотрим, какие предположения делают эксперты о том, как он устроен изнутри.
⏰ Запускаем трансляцию завтра, 28 мая, в 13:00.
Смотрите на YouTube, в ВК или прямо в этом канале — и задавайте вопросы лектору!
🔥10🤡1
Эрик Шмидт на церемонии вручения дипломов в Университете Аризоны заявил, что традиционный способ написания кода исчерпан.
Бывший CEO Google указал октябрь 2025 года как точку, после которой инструменты ИИ-разработки достигли уровня, удивляющего опытных инженеров.
Дословная формулировка: "Если вы пишете код любым традиционным способом -- остановитесь. Это закончилось".
Отдельный посыл адресован менеджменту: руководителям компаний предложено спросить, почему их инженеры пишут код так же, как полгода назад. Шмидт сравнил нынешний момент с появлением компьютера и описал переход от написания кода к управлению системами, которые делают это сами.
Один разработчик с правильной оркестровкой агентов, по его оценке, теперь способен на задачи, ранее требовавшие команды. Тезис пересекается с практикой крупных компаний.
Spotify в квартальном отчете сообщил, что лучшие разработчики не написали ни строки кода с декабря 2025 года, а изменения уходят в production через Claude Code прямо из Slack.
Ознакомиться с публикацией можно по ссылке (paywall) https://ai.plainenglish.io/the-last-line-of-code-d1ae5de4cede
Бывший CEO Google указал октябрь 2025 года как точку, после которой инструменты ИИ-разработки достигли уровня, удивляющего опытных инженеров.
Дословная формулировка: "Если вы пишете код любым традиционным способом -- остановитесь. Это закончилось".
Отдельный посыл адресован менеджменту: руководителям компаний предложено спросить, почему их инженеры пишут код так же, как полгода назад. Шмидт сравнил нынешний момент с появлением компьютера и описал переход от написания кода к управлению системами, которые делают это сами.
Один разработчик с правильной оркестровкой агентов, по его оценке, теперь способен на задачи, ранее требовавшие команды. Тезис пересекается с практикой крупных компаний.
Spotify в квартальном отчете сообщил, что лучшие разработчики не написали ни строки кода с декабря 2025 года, а изменения уходят в production через Claude Code прямо из Slack.
Ознакомиться с публикацией можно по ссылке (paywall) https://ai.plainenglish.io/the-last-line-of-code-d1ae5de4cede
🥴11👍6🤡3❤2🔥1💯1