gonzo-обзоры ML статей

Пост "За жызнь" Жизнь за последние полгода-год сильно изменилась. Во многом из-за AI. Начну с моих любимых программистов и машинлёрнеров. Я давно топил за то, что за программистами придут — например, вот тут в 2017-м в Forbes: https://www.forbes.ru/tehnologii/341535-mashiny-vmesto-inzhenerov-pochemu-iskusstvennyy-intellekt-doberetsya-i-do — и сам пробовал заставить модели писать код чуть ли не с первых версий, где это вообще имело смысл, но ничего законченного долго не выходило (копи-паст отдельных кусков в chatgpt не считаю, хотя уже тогда он многим заменил stackoverflow). Первые сколь-нибудь законченные проекты у меня начали получаться на границе между 2024-25 годами — и это, подозреваю, и есть момент, когда модели перешли порог, а не я осмелел. Так, в январе 2025 на курсе по AI Safety я делал курсовой проект про интерпретируемость моделей (https://gonzoml.substack.com/p/not-all-layers-are-equal) и решил делать это через Gemini и Claude. Модели нормально собрали мне код трансформера, интервенций и визуализации активаций. Правил я только что-то по мелочи. Весной 2025-го я написал MCP сервер для переводов через Intento (https://github.com/intento/mcp-intento-translate). Это был локально запускаемый MCP с транспортом через stdio, ну как примерно большинство MCP в то время и работало. Там я решил, что принципиально не буду писать ни строчки руками; пользовался Cursor и, кажется, каким-то из Codex или Claude. К декабрю 2025 я решил переделать MCP сервер на Streamable HTTP transport (там как раз и один из клиентов это захотел) и сделать его полноценным продакшн веб-сервисом. Часть про продакшн как обычно оказалась сильно более объёмной, чем собственно новый транспорт — все требования к продакшну, включая логгирование, мониторинг, требования к безопасности, нагрузке, обработке ошибок, деплою, и т.д., добавили больше кода, чем всё остальное. Попутно освоил speckit. Результат мне понравился, подход speckit тоже, для greenfield работало отлично. Делал через Cursor и Codex. С тех пор продолжаю развивать (и даже уже не в одиночку) в основном через Claude Code, не используя speckit напрямую, но пользуясь подходами, которые устаканились в этой репе (спеки в понятном формате с декомпозицией, тесты перед имплементацией, ADR к принятым решениям и т.п.). Параллельно в том же 2025-м было несколько экспериментов, когда я пытался применять модели для работы с нашим платформенным кодом, первую версию которого ещё десять лет назад я сам писал вручную. Платформа с тех пор знатно эволюционировала, появилось много нового кода, который я не писал и даже не читал (но какие-то куски в ядре ещё остались с моим кодом, который продолжает успешно работать). С таким brownfield у моделей выходило не очень — понимания у них не хватало, про зависимости с другими сервисами и репами они толком не знали, получалось так себе. Пробовал на относительно маленьких задачах про багфиксы и небольшие новые фичи — модели делали не то. Те, кто day-to-day работал с этим кодом, могли их укрощать, давая весь нужный контекст, но аутсайдеру, который постоянно в этой репе не живёт, было грустно. Тогда я списал это на brownfield как таковой; как выяснилось позже, дело было не в brownfield, а в том, что контекст лежал у людей в головах, а не там, где его могла взять модель — об этом ниже. В апреле 2026-го я написал статью (https://arxiv.org/abs/2604.21999) про эксперименты с издавна мной любимым universal transformer (ныне также известным как looped transformer) с памятью (другая моя давняя любимая тема), и здесь я не только писал код (https://github.com/che-shr-cat/utm-jax) моделями внутри Antigravity, но и гонял оттуда же эксперименты на TPU в GCP. Агентский режим в AG я тогда не трогал, гонял просто из параллельно запущенных терминалов — и до сих пор люблю такой режим работы в том же Claude Code CLI (а свежий AG, где терминалы и код запрятаны куда-то далеко, мне пока так и не зашёл). Всё, что я делал, по сути — генерировал идеи, выбирал интересные для реализации, делал ревью планов и результатов, корректировал по ситуации. Самое узкое место в том процессе было вообще за пределами всего этого — это была аллокация TPU, которые были почти тотально заняты, особенно свежих поколений. Но главное случилось за последние полгода. Если полгода назад какую-то очень заметную, наверно даже большую, часть кода мы писали руками, то сейчас его пишут модели: люди дают задачи и ревьюят (спеки, планы, тесты, код), руками не кодит уже вообще никто. Для этого пришлось основательно поработать с foundations (и мы ещё не закончили) и сделать так, чтобы моделям были доступны все необходимые артефакты: доки (в репах и через MCP к конфлюенсу), стандарты и ADR (в репах), задачи (сначала в JIRA, потом в Linear), логи с продакшн систем (MCP), а если надо, то и переписка в слаке. В целом всё то же, что нужно новому человеческому разработчику, приходящему в новый проект, нужно и моделям — и ровно этого им в прошлом году у нас и не хватало. Как и у всех остальных, наши боттлнеки сместились. Написание кода больше вообще не боттлнек, а вот чтение и ревью — да: первичное ревью тоже делают агенты, но финальное чтение всё равно человеческое, и вот оно теперь и трещит. У всех запущено по несколько агентских сессий: пока в одной агент что-то пишет или проверяет, в другой можно почитать свежие простыни. Разные loops внутри большого engineering loop продолжают замыкаться на агентов (кроме написания кода это код ревью, подготовка документации, релизные документы, тесты, ...), сам этот большой loop тоже всё ближе к автономному процессу, куда человеку нужно заглядывать только в определённых точках, где стоят quality gates с аппрувом на движение дальше. Эту трансформацию мы продолжаем, как и трансформацию всей компании в AI-first. Это вообще отдельная история. В следующем году автономности будет больше, контроля меньше, разработчики уйдут вверх по цепочке добавленной стоимости — ну, про это и так только ленивый не писал. Интереснее то, что открылось по дороге: например, шоппинг языка — теперь можно выбирать язык под задачу, а не под то, что умеет команда. Мы начали эксперименты с Rust — в старой парадигме ручного кодинга мы об этом даже не мечтали, в лучшем случае на Go что-то хотели переделать. Первый кандидат — вспомогательный сервис-эмулятор реальных апишек со всеми их возможными проблемами, в который упирались наши перф-тесты: его переписали на Rust (а заодно на Go и Node, с parity-тестом на все четыре реализации, чтобы было с чем сравнивать), и в том же 100-мегабайтном поде он держит в 2,6 раза больше открытых соединений, чем питоновский оригинал (~8,900 против ~3,400), а в idle занимает 1 MiB вместо 33. По дороге там выкинули hyper и написали свой HTTP/1.1 слой на 400 строк с wire-тестами. Цифры пока с локального стенда, но порядок понятен. Что интересно, гошный сервис в такой имплементации оказался не особо лучше нашего старого питоновского (лишь на 11%, и то после замены net/http на fasthttp, а на стандартном net/http — вдвое хуже). Наверное, есть ещё куда улучшать, но всё равно в ручной парадигме на такое для вспомогательного сервиса никто бы и недели не выделил. Ну и это, конечно, не только с кодом происходит. Вот есть у меня бухгалтеры, ведущие одну компанию. Каждый год при сдаче отчёта я сажусь перепроверять, что они мне собрали, и почти всегда нахожу ошибки, иногда довольно дурацкие. В этом году вместо меня это сделал Клод — причём вышел за пределы проверки отчёта и нашёл даже то, что я и не думал челленджить, всё с отсылками к конкретным законам, трактовкам и рекомендациям (отсылки я проверил, всё сошлось). А потом нашёл ещё один пропущенный мной неправильный расчёт за прошлый год, который добавил мне налога. И один потерянный возврат от налоговой за этот год (который я, может быть, и нашёл бы, но не так быстро). И сделал он всё это за один вечер. То есть quality gate переехал: раньше я проверял бухгалтеров, теперь Клод проверяет и их, и меня. В следующем году, подозреваю, такими темпами этот цикл замкнётся и без них. Клод цену своей подписки уже многократно отбил, бухгалтеры же — не уверен.