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

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

Продолжение серии про работу с ИИ-агентом. В прошлый раз разбирали, где живёт задача. Теперь — что с ней происходит, прежде чем она станет 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. Поддержать меня можно подпиской на канал "сбежавшая нейросеть", где я рассказываю про ИИ с творческой стороны.