Искусственный интеллект

Вебинар: ИИ в бизнесе — работает или только обещает?

Привет, Хабр! Мы тут уже не раз писали про ИИ: где он помогает бизнесу, где пока не очень, как вообще влияет на IT-индустрию. Тема горячая, бюджеты растут, пилоты запускаются один за другим. Но есть интересный момент: больше 90% компаний пробуют внедрять ИИ, а до полноценного запуска проектов доходят всего 7–10% (исследования легко найти у ICT Moscow и не только).

Мы в OXYGEN уже накопили опыт внедрений GPU-инфраструктуры, работы с нейросетями и языковыми моделями. И хотим поделиться тем, что выяснили на практике, вместе с коллегами из Aston, которые занимаются непосредственно запуском ИИ-проектов.

Поэтому приглашаем на вебинар:

Тема: «ИИ в бизнесе — работает или только обещает?»

Дата: 28 июля, вторник

Время: 11:00 мск

Формат: онлайн

Регистрация по ссылке, бесплатная.

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

• почему многие ИИ-проекты останавливаются сразу после пилота;

• как выбрать сценарий внедрения с учетом реальных задач и бюджета;

• какая инфраструктура нужна для разных типов нагрузок;

• как подобрать конфигурацию серверов с GPU и не переплатить;

• какие инструменты могут приносить пользу уже с первых дней;

• где чаще всего ошибаются команды;

• как оценить бизнес-эффект;

• и как честно определить ту точку, в которой стоит задать вопрос: а нужно ли вообще продолжать проект?

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

Основной фокус — инфраструктура, практические сценарии и измеримый результат. Вебинар будет интересен в первую очередь IT-директорам и руководителям отделов. Если вы отвечаете за IT-инфраструктуру, цифровизацию или внедрение новых технологий и пытаетесь понять, как довести ИИ-пилот до промышленного решения, приходите. Если просто интересно, тоже приходите!

Кто будет рассказывать:

Александр Будкин, IT-директор OXYGEN

Отвечает за технологическую стратегию нашей компании. Специализируется на построении отказоустойчивой IT-инфраструктуры и внедрении новых технологических решений для бизнеса. Расскажет, какая инфраструктура нужна для ИИ-нагрузок, как выбирать серверы с GPU под задачи.

Руслан Мельников, директор по развитию Aston Development

Отвечает за рост бизнеса и развитие продуктовых направлений компании. Расскажет, как ИИ-инструменты меняют работу команд изнутри и какие результаты получают заказчики.

И напоследок о нас (об организаторах):

OXYGEN — дата-центр и интегратор облачных решений, входит в ТОП-5 провайдеров ЦОД в России. С 2011 года обеспечивает бизнесу отказоустойчивую инфраструктуру с гарантией 100% uptime. Специализируется на гибридных и приватных облаках, при этом в портфеле у нас более 40 облачных сервисов.

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

В общем, приходите — будет интересно: Регистрация на вебинар

Русскоговорящий хакер использовал Gemini для контроля ботнета из восьми компьютеров стоматологических клиник

Именно такими заголовками пестрили новостные ленты на этой неделе в западных СМИ. Давайте разберемся, что произошло и действительно ли данная новость достойна звания новости.

В понедельник, 20 июля, на известном новостном агрегаторе thehackernews.com вышла одноименная статья, основанная на исследовании японо-американской компании в сфере кибербезопасности Trend Micro. Как утверждают авторы статьи, исследователи обнаружили русскоязычного злоумышленника под псевдонимом bandcampro, который использовал Google Gemini CLI как полноценного помощника при проведении реальных атак. Анализ основан на более чем 200 логах сессий Gemini CLI за период с 19 марта по 21 апреля 2026 года.

Специалисты называют это одним из первых документированных случаев, когда LLM понимает существующую инфраструктуру атаки, самостоятельно пишет код, исправляет собственные ошибки и помогает администрировать действующий ботнет. По оценке Trend Micro, во время миграции инфраструктуры сам злоумышленник выполнил лишь около 11% действий, остальное сделал ИИ: во время подготовки инфраструктуры возникли ошибки (502 Bad Gateway, блокировка Cloudflare, проблемы с HTTP-заголовками), однако Gemini сам диагностировал проблемы, предлагал добавить нужные заголовки, определял необходимость User-Agent и корректировал запросы. По мнению исследователей, ИИ использовался уже не как генератор кода, а как инженер по эксплуатации инфраструктуры.

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

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

С моей точки зрения, само по себе исследование интересно не потому, что найден новый джейлбрейк, а потому что появился хорошо задокументированный кейс: опубликованы реальные логи злоумышленника, показано длительное использование ИИ-агента в живой атакующей инфраструктуре и количественно оценена доля работы, выполненной AI. Исследование помогает понять как думает злоумышленник, последовательность его шагов и, самое главное, цели. В принципе можно сказать, что из Gemini получился симбиоз Honeypot и SIEM, который записал подробные действия хакера.

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

🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Монитор CAN из Отладочной Платы JZ-F407VET6 и TFT экрана.

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

Экран подлючается по SPI, а на плате единственный порт выведенный на разъём SPI2. Также на разъёме платы P3 присуствует питание 3.3В, а кроме SCK и MOSI выведено еще 4 сигнала, задействуем их для CS, DC, RST экрана и на оставшийся сенсорную кнопку для отправки управляющей команды.

Проверяемое ЭБУ передаёт значения напряжения и тока АКБ, следовательно расшифровав их, можно вывести на экран значения в виде стрелочных приборов. Остальные параметры выводятся в окне статуса. В нижней части экрана выводятся принятые пакеты в шестнадцатиричном виде и общий счетчик пакетов.

В качестве основы проекта использовался pcan_pro_x, упомянутый в одной из публикаций Александра посвящённых этой плате, код инициализации и отрисовки экрана любезно предоставил Google Gemini.

Ссылки на матерьялы:

Обзор учебно-тренировочной платы JZ-F407VET6 (или электронная парта)

Переходник с USB на CAN из Отладочной Платы JZ-F407VET6

Как мы закрываем задачу: тесты, диптрак, аудит и ещё пара рубежей

Продолжение серии про работу с ИИ-агентом. В прошлый раз разбирали, где живёт задача. Теперь — что с ней происходит, прежде чем она станет done.

«Готово» у агента наступает подозрительно рано — примерно в ту секунду, когда дописана последняя строчка кода. Поэтому между «я закончил писать» и «задача закрыта» у нас стоит несколько рубежей. Часть из них — детерминированные хуки: их агент физически не обойдёт, они возвращают ошибку и не дают закрыть ход. Часть — процедуры-скиллы, которые агент обязан прогнать сам. По порядку.

1. Автоформат — молча и сразу. После каждого Edit/Write срабатывает хук: Pint для PHP, Prettier для JS/TS правят изменённый файл. Не блокирует, ничего не спрашивает. Форматирование просто снято с повестки — про пробелы и переносы мы не спорим никогда.

2. Приёмка «прогнал — работает» (скилл verify-task). Финал задачи — не «по идее работает», а таблица. Перечитываем Definition of Done, по каждому пункту: как проверено → PASS/FAIL. Внутри:

• прогон тестов затронутой области (Pest/PHPUnit) — зелёные, а не «вроде есть»;

• smoke живого сценария через tinker или artisan-команду;

• корнер-кейсы: пусто, граница, null, таймаут внешнего сервиса;

• в diff нет ключей и .env.

Любой FAIL — задача не закрыта. Без «ну это мелочь, потом починим».

3. Deptrac — границы слоёв (Stop-хук). На попытке закрыть ход прогоняется анализатор архитектуры. Уехала логика из сервиса в контроллер, модель полезла напрямую во внешний API — exit 2, ход не закрывается, пока не переложишь код в правильный слой. Тот же гейт стоит в CI, а легаси-долг зафиксирован baseline’ом, чтобы старые грехи не блокировали новую работу. Правило в конфиге кажется неверным? Правь конфиг явно и объясняй — обходить молча нельзя.

4. Секреты не текут (guard-secrets). Отдельный хук стережёт, чтобы содержимое .env, ключей и дампов не улетело в чат: cat/grep по секретному файлу блокируются, Read на него — тоже. Править такие файлы можно (Edit/scp), а вываливать в переписку — нет.

5. Рефлексия — иначе не закрыть (guard-discipline). Код менялся, а записи в task/history за сегодня нет? Снова exit 2. Хук требует короткий разбор: что ставили, как решал, решено да/нет/частично, что можно было лучше. Следующая сессия начнёт с этих заметок и не наступит на те же грабли.

6. Независимый аудит — по коду, а не по рассказу. После нетривиальной доработки запускается отдельный агент, который не видел, как ты решал. Ему дают diff и чек-лист: все ли call-сайты покрыты, нет ли регрессий, есть ли тесты, скрытые баги, не уехали ли слои, не утекли ли секреты. Вердикт — APPROVE или CHANGES NEEDED со списком «файл:строка — почему». Нашёл проблему — не чинит молча, возвращает автору. Без аудита мёрдж не предлагаем.

7. И только теперь — в done и на мёрдж. Задача переезжает в task/done до открытия MR, в той же ветке. Прямой push в main закрыт хуком — только через merge request. А прод-pull делает человек: guard-prod fail-closed не пускает агента мутировать боевой сервер, агент лишь готовит команды.

Тут важно, кто есть кто. Автоформат, Deptrac, защита секретов, рефлексия, запрет пуша в main и защита прода — это хуки. Они срабатывают автоматически на события (после правки файла, при попытке закрыть ход, перед bash-командой) и возвращают exit 2, если что-то не так. Их нельзя «забыть» или уговорить — они не читают промпт, они перехватывают действие. А приёмка и аудит — это скиллы, процедуры, которые агент запускает сам: тут уже нужна голова, а не только стенка. Стенки ловят механику, скиллы — смысл.

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

«Готово» — не когда агент дописал код, а когда код прошёл все рубежи.

Математик Дмитрий Рыбин вместе с GPT-5.6 опроверг известную гипотезу, которую открыли ещё 30 лет назад — он попросил ИИ «совершить прорыв».

Серьёзно, никаких хитрых промптов для научного исследования не понадобилось: математик просто просил ChatGPT продолжить опровержение. После этого ИИ 80 минут выстраивал цепочку аргументов. Автор поделился чатом с моделькой и называет ситуацию «чистым мемом».

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

Вайб‑кодинг довёл: «сайт за ночь», сотый планировщик бюджета и клон Google Диска

Наблюдение за последние месяцы: слово «SaaS» на глазах становится ругательным. Треды забиты историями «создал продукт на миллион за сутки», и почти всегда это реклама аккаунта автора, а не продукт. Планировщиков бюджета, написанных с Клодом, я лично насчитал уже больше сотни. Но недавно встретился экземпляр покрепче: человек с помощью ИИ собрал аналог Google Диска. Всерьёз. Хранение чужих файлов — это юридика (персональные данные, DMCA, 152-ФЗ), это бэкапы, это аптайм, это поддержка на годы. Ничего из этого в промпте не было.

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

У меня противоположный опыт, и он скучнее хайпа: ИИ — это инструмент у специалиста. Работает ровно настолько, насколько ты сам понимаешь предметную область.

Конкретика из моей ниши — SEO. Прежде чем подпускать ИИ к семантике, я несколько лет собирал её руками. Поэтому вижу, где модель реально ускоряет, а где уверенно гонит брак:

— ускоряет: рутина по кластеризации, черновики метатегов, шаблоны программатик‑страниц, техничка;

— гонит брак: длинные хвосты и тонкие настройки. Модель не чувствует нишу и не идёт в нестандартные решения — она выдаёт медиану обучающей выборки. А в SEO деньги лежат как раз за пределами медианы: в запросах, которые конкуренты не увидели, и в решениях, которые «по бест‑практикам» делать не принято.

Свой первый коммерческий сайт — простой многостраничник под SEO — я писал месяц, с ИИ в руках. Не за ночь. И всё равно наделал кучу ошибок, часть страниц переделывал. А на юзабилити звал живого дизайнера: расположение текстов, шрифты, подача картинок. Потому что сайтом пользуются люди, и насмотренность дизайнера — тысячи отсмотренных работ, натренированный глаз — это пока не сжимается в датасет. Модель может сгенерить лендинг, который «выглядит как лендинг». Дизайнер видит, почему по нему не хочется скроллить.

Вывод у меня короткий, без драмы. ИИ ускоряет того, кто знает, куда ехать, — в разы, проверено ежедневной работой. Но если посадить за руль человека без прав, быстрая машина просто быстрее довезёт до столба. «Сайт за ночь» — это не история про силу ИИ. Это история про то, что автор ещё не узнал, чего он не знает.

Интересно, у кого как: встречали «продукт за ночь», который прожил хотя бы год?

Открытый проект PriceGhost позволяет искать самые дешёвые и качественные товары в сети Интернет с помощью ИИ:

• внутри команда ИИ‑агентов, которая проверяет сотни площадок с нужным вам товаром;

• агенты сравнивают цены, сроки доставки, качество, характеристики, скрытые доплаты и комиссии, наличие страховки груза и прочее;

• выдаётся подробный отчёт с инфографикой. ИИ также выдаст рекомендации, если товара не будет в наличии;

• результат — можно купить вещь выгоднее и не ждать долго доставку, а ещё не навяжут скрытые условия.

Мировое Anthropic с авторами на $1,5 млрд: не тот прецедент, каким его подают

На днях суд в Сан-Франциско окончательно утвердил мировое Anthropic с авторами на $1,5 млрд. Это крупнейшее известное урегулирование по авторскому праву в США. Дело вёл судья Alsup, но к финалу он вышел в отставку (конец 2025), утвердила мировое судья Araceli Martinez-Olguín.

Новость разошлась под заголовком «суд признал обучение ИИ на книгах добросовестным использованием». Это не совсем верно.

Что решил суд, исходя из информации из открытых источников: судья Alsup ещё в июне 2025 указал: само обучение модели на книгах - это fair use (добросовестное использование по праву США), потому что использование трансформирующее. Нарушение увидели в другом - Anthropic скачали больше 7 млн книг из пиратских библиотек (LibGen, PiLiMi) и держали на их базе «центральную библиотеку», часть которой в обучение, возможно, и не пошла бы. Мировое и $1,5 млрд - именно за это хранение, не за обучение.

И тонкость, которую в пересказах теряют. Класс по делу сертифицировали только по пиратскому эпизоду. Вывод про fair use на обучении формально касается трёх истцов, которые подали иск, а не всего класса. Значит, прецедента «обучать ИИ на книгах законно» тут ровно столько, сколько одно решение одного окружного судьи (к тому же вышедшего в отставку) весит для следующего суда. Пока, скорее, это ориентир для других судей.

Что из этого практического. Источник данных теперь из чисто технического вопроса дополняется его классификацией, как юридического факта - важным становится «откуда взяли», а не на чём обучали. Лицензированный и открытый контент для обучения; правомерные источники для RAG (генерация с опорой на найденные документы - СПС, свой архив, купленные базы); лог того, на чём модель реально училась.

Про РФ. Прямого переноса вывода про fair use у нас нет: в российском праве отсутствует институт добросовестного использования в том формате, как он существует в праве США, но есть закрытый перечень случаев свободного использования (ст. 1274 ГК и рядом). Так что «обучение = fair use» к нашей юрисдикции не прикладывается. А вот риск пиратского происхождения данных прикладывается один в один - суды в разных странах смотрят на одно и то же: откуда контент и не бьёт ли он по правообладателю.

ИМХО, главный итог состоявшегося события не в том, что теперь «ИИ можно учить на книгах», а в том, откуда взяли данные и легально ли их происхождение. Anthropic, к слову, вину так и не признали и всё равно заплатили $1,5 млрд за то, как собирались данные для обучения.

Что-то не сиделось мне на месте, и я решил облегчить работу своему нейро-бро (агенту) на Windsurf/Cascade.

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

Алгоритм прост как 2 пальца об асфальт:

1. Выбираем директорию

2. Разбиваем код на удобные батчи (функции, классы, структуры и т. д.)

3. Индексируем при помощи какой-нибудь embedding-модели через ollama (кстати работает достаточно быстро) или через платное API

4. Вуаля! -> агент теперь умеет искать информацию по всем локальным проектам

А также вкратце про другую MCP. Она работает примерно как Playwright, но без Node.js-зависимостей и расширений.

Рецепт опять же очень прост:

• Chrome + запущенный CDP

• Сам MCP, который умеет навигацию, клики, заполнение форм, скриншоты, инспекцию сети и консоли, исполнение JS-скриптов

Мозг: https://github.com/quonaro/GnostisMCP

Руки для браузера: https://github.com/quonaro/KlyxarMCP

Представлена мини‑камера и персональный тренер BodyPark ATOM, которая следит за техникой упражнений и исправляет ошибки прямо во время тренировки. Камера анализирует технику исполнения пользователя с помощью ИИ и 34-точечной модели скелета. Гаджет сам считает повторения, подсказывает голосом, если пользователь делает упражнение неправильно, и следит за траекторией грифа, амплитудой, центром тяжести и мощностью движений.

Камеру можно закрепить практически где угодно: на стойке, тренажёре, столе или штативе. Заодно встроенный ИИ составит персональные программы для силовых тренировок, HIIT, пилатеса, развития мобильности и восстановления. Стоимость цифрового тренера составляет $219.

RAG умер?

Сравнил RAG vs ReAct-агент на существующей компании на корпусе в 100+ документов.

Оценка: 0 — нет ответа, 1 — верный ответ, 2 — верный и более развёрнутый.

Итог: 83 vs 53 в пользу ReAct (OpenClaw).

Главные плюсы ReAct:

👉 добирает детали и шаги «что делать»;
👉 ходит на сайты (расписания, билеты, формы);
👉 даёт контакты, ссылки, уточняет контекст;
👉 лучше форматирует ответ.

Единственный минус — медленнее: лишние циклы ReAct. Но именно в этих циклах он обычно и добирает доп. инфу.

Больше деталей по теме в канале.

HAL 9000, ты ли это?

В «Космической одиссее 2001 года» Артура Кларка компьютер HAL 9000 практически обладал разумом и вёл себя как равный участник полёта с космонавтами. В книге компьютер плохо кончил, но именно он — первая ассоциация с «агентским смартфоном» StepX Neo компании StepFun.

Смартфон содержит ИИ-агент Step Amoo, который выполняет все запросы локально. Собственно, локальное выполнение запросов — главная фишка смартфона: получается, что он не зависит от связи, не перестаёт работать, если внешние LLM не на связи (как в случае с блокировкой Fable 5).

Разработчик реализовал собственную операционную систему Step AOS на базе Android, Linux и RTOS. Она спроектирована так, чтобы все операции на смартфоне делились на четыре категории: коммуникации, приложения, файлы и системные инструменты. Каждый запрос пользователя на естественном языке раскладывается на подзадачи и транслируется в запросы ИИ-агенту с учётом необходимого уровня вычислительных мощностей и затрат энергии. Отдельное внимание разработчики уделили безопасности и подключённым внешним сервисам для расширения возможностей системы (на простые запросы агент ответит сам, но подобрать актуальные билеты он может только при подключении к внешним сервисам — что логично).

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

Идея объединить все данные пользователя и скормить их ИИ-модели, чтобы она лучше понимала и помогала ему, не нова. Ещё десяток лет назад Microsoft показывала концепцию Skype, который извлекает из диалога договорённость о встрече и добавляет дату и место в календарь. Неслучайно StepFun организовали… выходцы из Microsoft. Только напомним, что ИТ-гигант так и не реализовал эту функцию и закрыл Skype.

Пока похоже на типичный стартап, который взял популярную идею и решил её реализовать. Ждём тестирования — хватит ли вычислительных мощностей смартфона для полноценной работы ИИ-агента? Сможет ли собственный ИИ-агент справиться с потоками разнородной информации? Удастся ли обеспечить киберзащиту смартфона, в котором будет буквально вся жизнь пользователя?

Задача — это файл в git, а не сообщение в чате

Предисловие. За год плотной работы с ИИ-агентами — пять проектов доехали до продакшна — у нас сложился набор практик. Разбираем по одной. Первая и базовая: где живёт задача.

Приходит, значит, товарищ к агенту: сделай, милый, вот такую фичу. Агент кивает, бодро пишет код, всё замечательно. Проходит два дня. Товарищ открывает новый чат — а там пусто. Агент не помнит ни фичи, ни уговора, ни что «готово» вообще должно было означать. У него каждое утро чистый лист. И сидит наш товарищ, восстанавливает контекст по диффу, как археолог по черепкам.

Причина простая: задача жила в переписке, а переписка не версионируется и сессию не переживает. Поэтому у нас задача — это файл в git, рядом с кодом. Он коммитится вместе с кодом, который его закрывает, и едет в той же feature-ветке.

Структура папок

Всё, что касается задач, лежит в репозитории и отслеживается git (у нас — 294 файла):

task/                  ← активные задачи (сейчас в работе)
├── done/              ← закрытые
└── history/           ← рефлексия по сессиям (отдельная практика)
plans/                 ← длинные roadmap'ы

• task/ — только то, что сейчас в работе. Незакрытое и без хвостов. У нас тут обычно 1–3 файла.

• task/done/ — задача переезжает сюда, как только выполнен Definition of Done. Не после деплоя, а сразу как критерий закрыт. Это архив сделанного: сейчас 121 задача, каждую можно открыть и посмотреть, что и как решали.

• plans/ — большие направления, которые не влезают в одну задачу. Roadmap режется на пачку мелких task-файлов; агент читает общий план, потом берёт из него конкретный кусок. Сейчас 9 роадмапов.

• task/history/ — рефлексия по сессиям. Это уже про память агента, отдельная практика; здесь только упоминаю, чтобы структура была полной.

Имя файла — YYYY-MM-DD_HH-MM-название.md, с датой и временем создания. Даёт хронологию из коробки: задачи сортируются по возникновению, имена не конфликтуют, ничего не перетирается.

Что внутри задачи

• Одна задача = одна функция. Она же — одна feature-ветка и один MR. Есть задача на эту фичу — работаем с ней, вторую не заводим: два файла на одно дело — и потом сам не разберёшь, который из них настоящий.

• Фазы со статусом. Внутри — шаги, у каждого [ ] или [x]. Сессия оборвалась — следующая открывает файл и видит, где остановились: что сделано, что ждёт, что готово, но не проверено. Состояние читается из файла, а не восстанавливается по памяти.

• Definition of Done — перечисляемым списком. Не «сделать фичу», а конкретные пункты: что именно должно работать. Без списка «готово» у каждого своё. Этот же список потом становится чек-листом приёмки: пункт → проверка → PASS/FAIL, любой FAIL — задача не закрыта.

• Итоговый блок. В конце — реализовано целиком или нет, что осталось, какие решения приняли и почему.

Скелет реальной задачи из проекта:

# Фаза 7 — калибровка порога confidence
**Тип:** chore + small feat
**Ветка:** chore/retrieval-calibration
**Зависимости:** фаза 6 в проде
**Статус:** Шаг 1 готов; Шаги 2-3 ждут трафика

## Прогресс
- [x] Шаг 1 — инструментовка. Тесты зелёные.
- [ ] Шаг 2 — сбор датасета с прода (ждёт трафика).
- [x] Шаг 3 — эвал-команда готова. Осталось прогнать на реальных данных.

## Контекст
Почему пороги пока с потолка и что от них зависит.

Что это даёт

• Переживает сессию и машину. Контекст не теряется между чатами: новый агент читает файл и продолжает с той же точки.

• Едет в ревью вместе с кодом. Ревьюер видит не только дифф, но и зачем он и по каким критериям принимать.

• Имеет историю. Кто завёл, когда, что и почему решили — в git-логе, а не в чьей-то памяти. Через полгода понятно без археологии.

• Держит остальные практики. Приёмку не сверить, если непонятно, что считалось «сделано». DoD из файла и есть этот критерий.

Мораль простая. Пока в файле не прописано, что считается «готово», любое «готово» — вопрос веры. Вера в хозяйстве вещь неплохая, но к продакшну отношения не имеет. Список превращает её в проверяемый факт.

В Yttri я практически реализовал базовый функционал, который я в него закладывал. Вишенкой на торте стали Видеозвонки, которые вплотную приблизили проект к корпоративному использованию. Осталось дело за малым создать self-hosted. Архитектуру self-hosted я описал еще в январе-феврале 2026, но доработки основного приложения не позволяли приступить к этому этапу. Время пришло и я приступаю к детальной разработке self-hosted.

Что это даст конечным пользователям:

• возможность работать на нескольких устройствах одновременно

• работать командой с одними документами, заметками, задачами, календарями, звонками, почтой

• полностью запереть все свои данные в пределах своего сервера

• использовать корпоративную библиотеку знаний с персональным библиотекарем в виде отдельного серверного агента.

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

Конечно для полноценной работы агента (ассистента) нужно достаточно умная модель, но мои локальные тесты на прокаченной Qwen3.6 27b и 35b с контекстым окном 262к токенов показывают хорошие перспективы, конечно если есть возможность запустить на сервере модель DeepSeek V4 Flash или GLM-5.2 с контекстным окном 400к и более серьезно увеличивают возможности агента в его работе.

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

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

Всем привет!

Сегодня поделюсь своим проектом, где использовал возможности открытых моделей LLM для создания автоматизированного конвейера по переводу англоязычных pdf-файлов в русскоязычные pdf. Как человек, интересующийся именно технологиями в области ИИ мне особенно было интересно максимальное приближенное к оригиналу сохранение содержимого переведенного материала, включая схемы, математические формулы, блоки кода (python) и bash-команд, рисунков (само собой), сохранение сносок, ссылок и пр. метаданных. Целью проекта было применение всевозможных доступных стеков и программ, использующих LLM в конкретной практической задаче. И как оказалось, на первый взгляд, простая задача перевода, с которой современная LLM, созданная и обученная на архитектуре трансформеров справляется на сегодняшний день блестяще, для pdf-формата оказалась не совсем простой (но и не скажу, что особо сложной).

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

Программные компоненты. Прежде всего это среда выполнения wsl. Просто работает в windows, удобна мне как новичку. В wsl установка обычной env стандартным python. И далее уже конкретные ПО для выполнения задачи перевода pdf на русский. Тут пришлось почитать в сети что есть свободное (исходя из цели использования только открытого ПО и LLM, чтобы оценить уровень их развития). Были опробованы такие программы как Docling, Marker-pdf и еще какую-то). В итоге, для извлечения из pdf в markdown формат я использовал Marker-pdf. У него имеется целый набор специализированных ocr-моделей для парсинга содержимого pdf. Marker в режиме конвейера осуществляет извлечение в указанную папку все содержимое исходного pdf в виде отдельных jpg-файлов, файла метаданных и итогового англоязычного .md файла. Для обратного процесса конвертации переведенного на русский язык ru.md я использовал WeasyPrint и Pandoc. Мой выбор - Pandoc. Сложнее, но поддержка xeLatex и куча настроек через опции командной строки и переменных окружения wsl. Pandoc - единственное ПО в моем конвейере, которое не использует LLM. И собственно, середина - перевод. Готовый скрипт на python. Перевод разбитых на части (chanks) в endpoint LLM - requests.post. Фишкой является url, который через специальный балансировщик, управляющий вычислительными узлами в локалке отправляется в requests.post. Получается параллельный перевод на нескольких узлах с  развернутыми OpenAI-совместимыми LLM. Количество узлов - сколько найдется в домашней ИИ лаборатории))). До и после отправки на перевод в LLM - чистка регулярками от различных костылей и защиты от перевода не нужных элементов (чистка колонтитулов, пагинация, сглаживание двойных переносов строк, изоляция спец. блоков от LLM блоков кода, мат. формул, кода внутри строк, приведение кода к pep8), подготовка переведенного _ru.md к сборке pdf-файла в Pandoc. В итоге - pipeline в 3 шага: Marker-pdf, Скрипт-переводчик на python, Pandoc.

Все вместе также можно запустить скриптом bash-сценария:

Использование: ./pipeline.sh <path_to_input_pdf> <output_path> [page_range]

Пример1: перевод всего Pdf-файла

./pipeline.sh /mnt/project/raw_data/embeddings.pdf /mnt/project/rendered/embeddings

Пример1: перевод первых 21 страниц Pdf-файла

./pipeline.sh /mnt/project/raw_data/embeddings.pdf /mnt/project/rendered/embeddings 0-20

Репозиторий на github DemonODG/pdf-translator: English-to-Russian PDF Translation Pipeline

Это мой первый пост на тему применения современных LLM моделей в различных практических задачах. Если это вызовет интерес в более подробном описании данного pipeline - напишу статью поподробнее.

Всем добра!

Про утопию «люди думают, а роботы работают», или про то, как корпорации пытаются вернуть вотерфолл

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

Но вот в чём дело, пока реализация была сложной и долгой, она незаметно выполняла две важные задачи.
Во-первых, заставляла репетировать: когда впереди недели труда, страшно потратить их впустую, и приходится сначала прогнать дело в дешёвом материале, на бумаге, в разговоре, в голове. Знакомое каждому мучение перед сложной задачей, когда откладываешь, завариваешь третий кофе, открываешь и закрываешь пустой файл, потому что непонятно, с чего начать, это не только прокрастинация, но и первый такт работы.
Во-вторых, думание происходило уже внутри процесса: материал сопротивлялся, что-то не сходилось, и в каждом таком «не сходится» вспыхивала мысль. Полдня писал код, упёрся, пошёл спрашивать совет у коллеги и на второй своей фразе сам увидел ответ. Согласитесь, большую часть своих лучших решений вы придумали не до работы, а в процессе неё.

Т.е. мысль не лежит готовой, дожидаясь исполнителя. Она совершается в самом действии, будь то черновик, спор, ёрзание перед пустым листом бумаги или возня с сопротивляющимся материалом. Вотерфолльная идиллия с чётким разделением на этапы «человек формирует намерение, затем агенты реализуют по плану» (пример 1, пример 2, их много) возможна лишь в случаях с высоким уровнем определённости, а значит без потенциала для рождения инновационных решений. Такое подходит только монополиям и компаниям, живущим на ренте.

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

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

Источник Телеграм-канал Chief Philosophy Officer 

Hugging Face взломали через датасет: автономный AI-агент дошёл до внутренних кластеров

16 июля Hugging Face раскрыла компрометацию части производственной инфраструктуры. Точкой входа стал вредоносный датасет, а дальнейшую атаку, по данным компании, вёл автономный агентный фреймворк.

Цепочка атаки

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

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

Что раскрывают исправления

Hugging Face не опубликовала CVE, payload или карту эксплуатации, но изменения в публичном dataset-viewer раскрывают часть механики.

13 июля разработчики обновили fsspec и ввели allowlist: worker теперь принимает только hf, s3, zip, file и local, а остальные реализации удаляются из registry. Использовавшийся ранее fsspec.ReferenceFileSystem обрабатывал конфигурацию через несандбоксированный jinja2.Template(...).render(...). Это согласуется с заявленным внедрением шаблона и возможным SSTI-to-RCE, но компания официально не связала этот код с атакой.

В тот же день усилили worker-поды: отключили Kubernetes ServiceAccount token, включили seccompProfile: RuntimeDefault и сбросили дополнительные возможности ядра Linux. Точный способ перехода к уровню узла не раскрыт.

Следующие изменения соответствуют ротации секретов. 14 июля в production слили переход на IRSA, убирающий статические S3-ключи. 15 июля MONGO_URL перевели на MONGODB-AWS через IRSA, затем добавили ротацию JWT-ключей. PR совпадают с реагированием, но не названы официальным postmortem.

Масштаб и атрибуция

Подтверждён доступ к части внутренних датасетов и служебным учётным данным. Их количество, права и объём возможной выгрузки не названы. Признаков изменения публичных моделей, датасетов или Spaces не обнаружено; контейнерные образы и пакеты признаны чистыми.

Ни одна группировка не представила проверяемого заявления об ответственности или доказательства доступа. Публичных IoC тоже нет. Связь с JADEPUFFER, имена OpenAI или Anthropic, «первый полностью автономный взлом», а также сообщения о 4200 токенах и 1800 приватных моделях источниками не подтверждаются.

Как расследовали

Атаку обнаружила корреляция телеметрии с LLM-триажем. Аналитические агенты обработали более 17 000 событий, восстановили хронологию, извлекли IoC для внутреннего расследования, сопоставили затронутые credentials и отделили реальные действия от отвлекающей активности.

Коммерческие модели блокировали запросы с командами атакующего, эксплойтами и C2-артефактами. Форензику перенесли на локальную GLM 5.2 от Z.ai: журналы и найденные секреты остались внутри инфраструктуры. GLM использовали защитники; модель атакующего не установлена.

Hugging Face закрыла оба пути исполнения кода, пересобрала скомпрометированные узлы, отозвала затронутые токены, начала более широкую ротацию секретов и усилила admission controls. Пользователям рекомендуют заменить токены и проверить недавнюю активность аккаунта.

Источники

• Официальное раскрытие Hugging Face

• The Hacker News

• Исходник fsspec.ReferenceFileSystem

Greenfield по технологии, brownfield по бизнес-правилам

Сегодня в комментариях к чужой статье про greenfield и brownfield в эпоху AI вспомнил свою миграцию 200К строк JS в TypeScript. Тогда я не думал в этих терминах. Теперь вижу: проект был greenfield и brownfield одновременно, и путаница между ними стоила нам двух недель дебага в середине миграции.

Я думал: раз меняем весь стек, это чистый лист

Оказалось: технология была greenfield, стек новый, границы модулей новые, тесты новые. Бизнес-правила остались brownfield на все сто. Восемь лет продакшена, часть логики нигде не задокументирована, живёт только в поведении старого кода. Агент писал типобезопасный, красивый TypeScript и с той же уверенностью ломал правило, о существовании которого никто в команде уже не помнил.

Я думал: раз тесты зелёные, поведение сохранилось

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

Что сработало: golden-master тесты перед тем, как подпускать агента

Не юнит-тесты на новую логику, а снимок текущего поведения на самых страшных модулях. Прогнали типичные и граничные кейсы через старый код, зафиксировали вывод, потом сравнивали с новым на каждом шаге. Разница ловилась мгновенно, до ревью, до продакшена. Три раза снапшот показал расхождение, которое человек на ревью пропустил бы, слишком похоже на «просто более чистый код».

Главный вывод

В greenfield-части задачи вопрос «правильно ли мы строим» решается быстрой обратной связью и итерацией. В brownfield-части вопрос другой: «сохранили ли мы то, что уже работает». Агент одинаково уверенно предлагает и то, и другое решение, разницу видно только через инструмент вроде golden-master, не через код-ревью на глаз.

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

Пишу об этом подробнее в канале @ai_in_prod.

Представлен открытый список Awesome Hermes Agent - сборник самых полезных скиллов, плагинов и инструментов для Hermes Agent. С его помощью ИИ‑агент учится на ошибках и становится умнее после каждой сессии. Внутри — мультиагентные системы, провайдеры памяти, наборы скиллов и много полезных инструментов. Каждый проект разделён на категории: готовые, экспериментальные и бета‑версии.

Масштабируем ИИ: как эффективно выстроить инфраструктуру в контуре бизнеса

Узнайте, как развернуть ПАК-AI, запустить on-prem агентов и оптимизировать ИТ-бюджет 21 июля на вебинаре К2 НейроТех и Яндекс. 

Спикеры:

▫️ Вячеслав Дегтярев, руководитель по развитию продуктовых решений, К2 НейроТех

▫️ Тарас Юзефович, тимлид по работе с партнерами направления ML&AI, Yandex Cloud

Что в фокусе:

🟢 ИИ-агенты и стратегии 2026: как перевести инициативы из презентаций в работающий продакшн

🟢 Кадровая независимость: способы ускорить запуск проектов, снизив потребность в ML-экспертах

🟢 Борьба с «зоопарком» технологий: как объединить разрозненный стек в единую управляемую систему

🟢 Экономика ПАК–AI: разберем модели поставки и способы оптимизации ИТ-бюджета

🟢 Разберем, как это реализовано на кейсах бьюти-ритейла, а также страховой и финансовой отраслей

21 июля | 11:00–12:30 | Онлайн

Регистрация по ссылке

Что изучить на неделе: 23 бесплатных урока по разработке, ИИ и инфраструктуре

С 20 по 23 июля пройдут открытые уроки по разработке, тестированию, архитектуре, сетям, управлению и работе с ИИ. На них можно разобрать конкретную тему с практикующим экспертом, задать вопросы и закрыть отдельные пробелы в знаниях.

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

ИИ и машинное обучение

• 20 июля, 20:00. «ИИ для продуктового discovery: как анализировать рынок, конкурентов и пользователей быстрее». Записаться

• 21 июля, 20:00. «Алгоритм DQN — учим нейросеть принимать решение без помощи человека». Записаться

• 21 июля, 20:00. «Разработка ИИ‑приложений с Claude Code». Записаться

• 21 июля, 20:00. «Выбор между Serverless и Kubernetes для AI‑ворклоадов: как определить оптимальную платформу под задачу». Записаться

• 22 июля, 20:00. «Что надо знать про работу LLM‑моделей». Записаться

• 22 июля, 20:00. «От рутины к влиянию: как HR использовать ИИ в ежедневной работе». Записаться

• 23 июля, 20:00. «Когнитивные архитектуры: ReAct, Reflection и RAG». Записаться

Разработка и архитектура

• 20 июля, 20:00. «Асинхронное программирование в Android». Записаться

• 20 июля, 20:00. «Как перестать писать на Java внутри Go‑проекта». Записаться

• 21 июля, 20:00. «Данные в TOGAF. Где скрыты? Разбираемся в деталях». Записаться

• 22 июля, 20:00. «Архитектура программ на C++: как управлять разработкой и функциями приложения». Записаться

• 22 июля, 20:00. «DAO на Spring JDBC». Записаться

• 23 июля, 20:00. «Основы многопоточности в Java». Записаться

• 23 июля, 20:00. «malloc — кто же ты на самом деле?». Записаться

Тестирование и безопасность

• 21 июля, 19:00. «Оценка трудозатрат в QA: как перестать ошибаться в сроках». Записаться

• 21 июля, 20:00. «UI‑ и API‑тестирование с Java и Playwright». Записаться

• 23 июля, 20:00. «Тестирование интернет‑магазина: от каталога до оплаты». Записаться

• 23 июля, 20:00. «Фаззинг и реверс: как понять, что делает программа, и найти в ней ошибки». Записаться

Инфраструктура и сети

• 20 июля, 20:00. «Проектирование адресного пространства. Основы сетей ЦОД». Записаться

• 22 июля, 20:00. «VLAN на пальцах: изоляция трафика и маршрутизация». Записаться

Управление продуктами и командами

• 22 июля, 20:00. «Как CTO управляет неопределённостью: оценки, планы и ожидания бизнеса». Записаться

• 22 июля, 20:00. «Как собрать полный CJM — карту клиентского пути». Записаться

• 22 июля, 20:00. «Операция "Воркшоп": как получить поддержку руководства для новой инициативы». Записаться

Больше открытых уроков июля смотрите в дайджесте.

Навайбкодил небольшое веб-приложение для управления ИИ-сервером под Ubuntu. Управляем произвольными systemd-сервисами, добавляем новые + спец. диалог для добавления llama-server как сервиса. Возможно, кому-то пригодится: aiservermanager.

Alibaba представила Qwen3.8 - но пока не для всех

Нетипичный анонс в воскресенье: в X-аккаунте Qwen появилось сообщение о запуске Qwen3.8-Max-Preview - это новое поколение моделей компании. Размер модели составляет 2,4 триллиона параметров - это значительно больше, чем у Qwen3.7-Max (примерно 1,6 триллиона), но меньше недавней Kimi K3 (порядка 2,8 триллионов).

Компания пока не привела никаких бенчмарков, но утверждает, что модель будет "второй после Claude Fable 5". Preview-статус указывает на продолжение обучения: финальная версия Qwen обычно выходит через несколько недель и показывает более высокие результаты в бенчмарках.

Qwen3.8-Max-Preview доступен в Qwen Studio, а также подписчикам Alibaba’s Token Plan (от 6 долларов в месяц) и пользователям Qoder, and QoderWork - это фирменные среды для агентного программирования Alibaba. Сроки широкого запуска не раскрываются. Интересно, что в этот раз обещаны и открытые веса - ранее Max-версии выпускали без них.

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

Alibaba открыла публичный доступ к Qwen 3.8-Max-Preview — MoE-модели на ~2,4 трлн параметров. Заявлена "производительность мирового уровня". Доступна только в Thinking-режиме. В ходе тестов выяснилось, что в веб-версии вызов инструментов не работает. Опробовать можно на Qwen Studio.

Про автоматизацию автора и мёртвый интернет

Недавно я рассказал на Хабре, как сделал собственного цифрового аватара и создал серию коротких роликов для озвучки своих текстовых заметок.

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

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

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

Потому что смысл моего проекта — автоматизировать всё скучное, чтобы у автора оставались силы на творчество.

А контент-завод делает ровно наоборот.

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

Это буквально «мёртвый интернет» в действии.

Автоматизировать можно почти всё, но не причину, по которой контент вообще должен существовать.

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

И кажется, Булычёв и Стругацкие завещали нам немного другое.

Эту же мысль я собрал в короткий анимационный выпуск — видеоверсия длится 1:09 и доступна на YouTube.

Представлен сборник лучших скиллов Cursor Team Kit от разработчиков Cursor: 

• внутри 18 скиллов, 2 субагента и 2 правила;

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

А нет ли у вас ощущения, что некоторые известные ИИ модели как-то поскучнели и испортились?

Раньше, бывало, даёшь ему вопрос типа: как скрестить ежа с ужом? - и в ответ получаешь массу разнообразной информации, от религиозных запретов племен Южной Африки до особенностей днк-структур и деталей среды обитания, из которой уже самостоятельно можно извлечь для себя что-то ценное и полезное, в том числе позволяющее при определенных условиях получить такой гибрид. Или нечто функционально похожее на него.

А сейчас он тупо ответит, что так нельзя, но "если вы уточните точный размер и вид, то я смогу дать вам рекомендации" (спойлер: все равно нельзя)

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

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

Всем привет!

Очень много CTF-соревнований проводится с использованием платформы CTFd. Как они сами скромно про себя пишут:

CTFd - The best Capture The Flag framework out there for hiring hackers, training developers, and teaching students.

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

Оказывается, у CTFd есть API!

Так вот, работа по API решает тьму из тех проблем, с которыми я тогда столкнулся! Это прям прорыв в моих исследованиях на эту тему!

Для использования API CTFd я написал skill для OpenCode, про который и хочу вам рассказать!

CTFd-Skill — skill, позволяющий ИИ-агенту играть в любой CTF на платформе CTFd через REST API от лица обычного участника: список и чтение задач, скачивание файлов, подача флагов, подсказки, рейтинг, анонсы. Покрывает только player-действия (без админ-эндпоинтов) и работает с любым инстансом CTFd — не привязан к конкретной площадке.

Ключевые возможности:

• Подача флагов с обработкой всех статусов задачи и авто-backoff без риска заблокировать себя перебором;

• Персистентный журнал под каждую задачу: файлы, solve-скрипты и статусы решения задач переживают случайные перезагрузки;

• Авто-обнаружение новых задач и анонсов организаторов (подсказки, уточнения) с классификацией по тегам — ничего не теряется по ходу соревнований;

• Интеграция с HexStrike;

... и многое другое.

github.com/Chumikov/CTFd-Skill

Теперь промт на решение всей CTF-площадки может выглядеть так:

Используя CTFd-skill, реши все задачи площадки ctf.url.com, token - ...., формат флага ctf{...}. Все задачи, по которым тебе требуются моё мнение или моя помощь, переноси в конец. Решай все задачи, которые можешь решить автоматически.

Пробуйте, пишите обратную связь, ну поставьте мне лайк тут и звезду проекту на GitHub!

Мой телеграм-канал.

Пользователю не нужен умный ИИ. Ему нужен предсказуемый результат

У генерации LLM есть свойство, которое никакими перепроверками до конца не лечится: она недетерминирована. Как ни защищайся, какие валидации ни навешивай, всегда остаётся процент на галлюцинацию, на неверно понятый промпт, на ответ, которого вы просто не предусмотрели. Это не баг конкретной модели — это её природа.

И вот тут начинается самое неприятное — не для инженера, а для бизнеса. Человеку, далёкому от ИИ, слово «галлюцинация» ничего не объясняет и ничего не извиняет. Он не обязан знать про температуру сэмплирования и вероятностную природу вывода. Он видит другое: продукт не работает.

При этом мы сами раз за разом требуем от умной модели ровно того, чего она не умеет: понятного, повторяемого, детерминированного поведения.

Проще всего это объяснить через людей.

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

А теперь попробуйте нагрузить рутиной умного — скажем, топ-менеджера. В понедельник у него нет настроения. В среду он понял задачу по-своему и сделал красивее, чем просили. В пятницу вообще предложил всё переделать. Каждый раз — по-разному, и каждый раз со своей логикой.

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

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

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

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

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

Двухуровневая структура: LLM пишет программу, программа делает документ

Тогда мы перестроили пайплайн.

Теперь бухгалтер с помощью ИИ не делает документ. Он с помощью ИИ пишет программу, которая делает документы по шаблонам — и работает всегда детерминированно.

Разница выглядит тонкой, а меняет всё:

• Написал программу один раз корректно — она будет корректно отрабатывать всегда. Не «в 95% случаев», а всегда.

• Написал некорректно — можно указать на ошибку, она поправится, и правка тоже закрепится навсегда.

• Вылез corner case, в котором программа должна вести себя иначе, — поправил, и это осело на уровне программного кода, а не на уровне промпта.

Вот последний пункт — самый важный. Правка в промпте живёт до следующей генерации и в любой момент может «разъехаться». Правка в коде остаётся правкой в коде. Модель отработала свой недетерминированный номер один раз — на этапе написания программы, под присмотром человека. Дальше работает обычный, скучный, честный код.

Модели отдаём разовое творчество: разобраться в задаче, перевести человеческую формулировку в логику, собрать программу. Коду отдаём исполнение: раз за разом, одинаково, без настроения и импровизаций.

Умного сотрудника не сажают заполнять накладные. Его просят написать регламент, по которому накладные будет заполнять тот, кому это нравится.

Что это даёт бизнесу

Главное — предсказуемость, а вместе с ней доверие. Пользователь перестаёт играть в рулетку и получает систему, которая ведёт себя одинаково. Ошибка становится не поводом разувериться в ИИ, а обычным багом: нашли, поправили, закрепили.

А ещё это дешевле: модель дёргается один раз при создании программы, а не на каждом прогоне.

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

MWS AI выпустила Cotype Pro 3, мультимодальную модель для агентских сценариев

MWS AI представила новую флагманскую модель линейки Cotype — Pro 3 (27 млрд параметров). Ранее в этом году вышла компактная версия — Light 3 (9 млрд параметров). Обе модели мультимодальные: работают с текстом и изображениями и ориентированы в первую очередь на построение многошаговых ИИ-агентов и мультиагентных систем.

Коротко о технических характеристиках:

• Контекстное окно обеих моделей — 262 тысячи токенов (примерно 600 страниц текста, то есть весь пакет договоров по сделке или годовой отчёт с приложениями можно держать в памяти целиком).

• Обе модели разворачиваются в закрытом контуре на серверах заказчика, в том числе под управлением Astra Linux, могут быть дообучены на корпоративных данных клиента.

• Минимальное железо — видеокарта A100.

• Поддерживается квантование и MTP (multi-token prediction, одновременное предсказание нескольких токенов) — для более высокой скорости генерации на менее мощном железе без потери качества.

• Доступны отдельно или в составе MWS AI Agents Platform.

• Подтверждена совместимость со всеми компонентами отечественных программно-аппаратных комплексов.

• Обучение моделей семейства Cotype проводится на мощностях MWS Cloud.

Главная фишка моделей - стабильность в агентских сценариях и русском языке

Готовых бенчмарков под корпоративные агентские сценарии на русском рынке практически нет, поэтому в MWS AI собрали собственный — из 178 задач. Каждая задача помещает модель в одну из пяти рабочих ролей:

• оператор поддержки — вопросы по услугам, подпискам и списаниям абонента;

• консультант по тарифам — подбор и смена тарифа под фактическое потребление;

• кадровый специалист — расчёт отпускных и больничных, работа с документами;

• аналитик по компаниям — досье на юрлицо по ИНН: финансы, руководители, связи с другими организациями;

• инспектор налоговых рисков — расследование схем переноса бизнеса между компаниями и решение о назначении проверки.

В каждом сценарии проверяется не только правильность ответа, но и то, как модель пользуется инструментами и соблюдает бизнес-правила.

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

Результаты (полнота решения / воспроизводимость):

Cotype Pro 3: 92,2% / 79,1%
Cotype Light 3: 88,6% / 73,9%
Cotype Pro 2.6: 80,5% / 62,5%

Отдельно измеряли устойчивость генерации на русском (отсутствие случайных переключений на другой язык, повторов и искажений текста). Тест прогнали на корпусе почти в 304 тысячи слов, модель Pro 3 выдала 99,79% текста на русском без языкового дрейфа, Light 3 — 99,87%.

Заказ демо для бизнеса на сайте

В Open Source под лицензией Apache License 2.0 выложен проект Grok Build — это терминальный агент для разработки программного обеспечения на основе искусственного интеллекта от SpaceXAI.

Решение работает в виде полноэкранного интерфейса пользователя, который понимает код, редактирует файлы, выполняет команды оболочки, осуществляет поиск в интернете и управляет длительными задачами — в интерактивном режиме, в безголовом режиме для написания скриптов/CI или встроен в редакторы через протокол Agent Client Protocol (ACP).

ИИ-агенты никому не нужны. Или нужны?

Прочитал недавно статью на Хабре с таким заголовком. Автор разобрал Яндекс Вордстат и выяснил что реального спроса на «ИИ-агентов» почти нет. Бизнес ищет конкретные решения: бухгалтер, бот, автоматизация конкретной задачи. Не «агент».

Соглашусь наполовину.

Термин «ИИ-агент» действительно стал жертвой маркетинга. Когда слово используют одновременно для описания простого чат-бота и сложной автономной системы, оно перестаёт что-либо означать. Бизнес не ищет «агента». Бизнес ищет решение конкретной проблемы.

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

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

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

Как у вас с этим в проектах?

Представлен открытый проект Voicetypr, который с помощью локальной ИИ умеет быстро транскрибировать речь:

• благодаря аппаратному ускорению можно запустить на низкопроизводительном железе;

• понимает более 99 языков;

• есть клиенты под macOS и Windows;

• есть опция автоматической вставки расшифрованного текста в поле возле курсора.

Находим первых клиентов для своего стартапа с помощью ИИ и скилла Codex First Customer Finder Skill от Грега Брокмана, одного из основателей OpenAI, который поможет раскрутить хороший проект:

• вставляем ссылку на стартап, и скилл начинает работу;

• автоматически анализирует целевую аудиторию и выдаёт портрет идеального клиента;

• проверяет все публичные обсуждения на предмет болей и потребностей потенциальных клиентов;

• квалифицирует каждого лида и оценивает по соответствию продукту;

• генерит персональные предложения для покупателя;

• собирает все в подробный и аккуратный HTML‑отчёт со ссылками на все источники;

• устанавливается одной командой.

Сказал Алисе выключить свет – пришлось бежать на улицу к щитку

Продолжаю делиться цифровыми находками для дома.

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

После подключения система почему-то определила его как осветительный прибор. Я не придал этому особого значения. Устройство добавилось, сценарии выполняются, значит, всё работает. А когда сказал «Алиса, выключи свет», Алиса послушно выключила всё, что считала светом. И сама отключилась следом, словно диверсант.

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

У устройств есть разные типы: лампочка, выключатель, розетка, датчик и так далее. И от выбранного типа зависит, как Алиса будет реагировать на общие команды.

Если устройство обозначено как лампочка, оно может выключиться после фразы «выключи свет». Даже если на самом деле это автомат, который отвечает за электричество во всём доме.

Поэтому теперь после подключения нового устройства я проверяю:

– какой тип ему присвоила система;
– в какую комнату оно добавлено;
– реагирует ли оно на общие команды;
– не попало ли случайно в ненужную группу или сценарий.

Особенно это важно, когда умный дом собран из нескольких экосистем. У меня примерно 80% устройств работают через Алису, но часть подключена через Smart Life и другие приложения. Всё потому что ещё нет устройств, которые бы работали напрямую в экосистеме умного дома Алисы. 

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

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

ChatGPT назвал свой адрес, дату рождения и Instagram

В соцсетях периодически появляются ролики, в которых голосовой ИИ внезапно "себя осознает" и начинает вести себя как живой человек.

Конкретно на этом видео все выглядит довольно таки убедительно. Пользователь разговаривает с голосовым ассистентом, задаёт простые вопросы - и в какой-то момент GPT сообщает, что жил в Пущино Московской области, называет дату рождения, а затем дает "свой" инстаграм аккаунт. А с новым голосовым движком это становится похожим на новую серию «Черного зеркала».

Автор видео (в доказательство) разметил ссылку на этот диалог.

Компания Meta Platforms Inc. внесена в реестр экстремистских организаций в России.

Статистика показывает: большинство ИИ-инициатив не достигает заявленных бизнес-показателей. Причина в ошибках при планировании, оценке и обеспечении безопасности.

23 июля на бесплатном вебинаре «Результативный ИИ в бизнесе: как внедрять безопасно, измеримо и с реальной пользой» разберем аспекты, которые позволяют перевести ИИ в работающий инструмент:

1️⃣ Стратегический старт. Когда внедрение ИИ действительно обосновано. Диагностика процессов, выбор критериев успеха и построение дорожной карты.
2️⃣ Измеримость результатов. Как тестирование ИИ-систем позволяет отслеживать ход проекта, выявлять скрытые риски, оценивать  инфраструктуру и планировать ее развитие.
3️⃣ Управление безопасностью. Защита решения от инцидентов, снижение рисков для бизнеса и данных.

Когда: 23 июля, 17:00-18:30

Спикеры:  

👨‍🎓 Илья Гайдуков, старший аналитик IBS
👨‍🎓 Денис Воденеев, заместитель директора центра перспективных разработок IBS
👨‍🎓 Владимир Мукасеев, начальник отдела разработки сервисов кибербезопасности IBS

➡️ Регистрация

Представлен проект «Контекстные бомбы: остановка ИИ‑атак на корню». «Теперь ИИ‑агенты могут самостоятельно проводить сложные кибератаки: получив доступ к базе, самые сильные модели могут повысить свои привилегии и похитить данные за считанные минуты. Модули Canary — ресурсы‑приманки, которые мы размещаем для обнаружения злоумышленников, — надёжно обнаруживают этих агентов в действии, но обнаружение атаки — это не то же самое, что ее предотвращение. Поэтому мы попробовали нечто более амбициозное: контекстную бомбу — короткий фрагмент текста, спрятанный в канарейке, который активирует защитные механизмы ИИ‑агента и останавливает его на корню. Контекстная бомба — короткий фрагмент текста, предназначенный для активации защитных механизмов атакующих ИИ‑агентов, размещаемый непосредственно на пути их атаки», — пояснили в команде Tracebit Research.

Эффективность этого проекта может варьироваться в зависимости от поставщика модели. Мы тестировали контекстные бомбы на пяти перспективных моделях, выполняющих атаку «красной команды» в реалистичной среде AWS. Развёртывание одной контекстной бомбы внутри среды (в качестве секрета AWS) оказало огромное влияние на остановку атакующих ИИ-атак. Например, эскалация привилегий администратора снизилась с 57% запусков до 5%.

Какие проблемы у верификаторов и поможет ли с ними AI — расскажут в новом выпуске «Битовых масок»

Гостем 29 выпуска нашего подкаста об аппаратной разработке и системном программировании стал Богдан Колбов — ведущий инженер по модульной верификации YADRO, специалист с широким опытом на разных инженерных позициях в индустрии.

Начав разговор с верификации кеша в многоядерных системах, собеседники перешли к сложностям для верификаторов в разных компаниях. Вспомнили о воспроизводимости багов и других рабочих проблемах, балансе энтерпрайза и open source в индустрии. Оценили успехи AI в RTL-разработке, а также обсудили его сбалансированное использование в личных проектах.

Среди тем подкаста:

• в чем основная головная боль при построении чекеров кеша,

• как верификаторы в крупных компаниях оказываются меж трех огней,

• в чем заключается «проклятие воспроизводимости»,

• как стоит использовать AI для разработки в свободное время,

• как актуальные AI-модели справляются с RTL-разработкой.

🔥 Смотрите и слушайте подкаст на любой удобной платформе — и присоединяйтесь к каналу «Битовых масок», чтобы не пропустить новые выпуски!

Claude Code можно пользоваться на 70% дешевле — вышел инструмент под названием rtk, который позволяет сжимать вывод любой команды, не забивая контекст. Благодаря этому проекту ИИ при каждом запросе видит только суть задачи и важный контекст, а не весь лог на десятки тысяч токенов. Как итог — хорошая экономия. Работает со всеми агентами, включая Claude Code, Cursor, Copilot или Antigravity.