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

Открытый проект 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 правила;

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