Cross Join - канал о разработке

Типовые косяки агентов (август 2026) У меня есть сложный проект, в котором 99% кода написано AI (код уровня подсистем ядра Linux и секурити: eBPF LSM, TPROXY, fanotify). На нём отлично видно, как кодинговые агенты лажают. Наиболее типичные ошибки, которые я замечаю: - Автоматические тесты через агента тестируют не реальные сценарии. Например, у юзера стартует один сервис, а в плейбуке в момент тестирования создается другой сервис. После чего, какие-то сценарии начинают валиться с ошибками и агент маркирует это как "Critical", заводит задачу "на серьезных щах" и даже порывается пофиксить. - Агенты переусложняют реализацию. Если дать им полную свободу продуктового мышления, то они навертят кучу сложностей, которые вообще не нужны (или не нужны в ближайшие пару лет точно) - Агенты всегда находят ошибки в ревью кода. То есть можно запускать на сложной кодовой базе ревьюер, потом фиксить его находки, запускать ещё раз, фиксить... и каждый раз получать новую порцию "проблем". После ревью агент обычно ещё делает триаж найденных задач, и часть из них становится Critical/Major ошибочно. Потому что если разбираться в продукте и его архитектуре, там из 23 найденных проблем, ну, может, три Major, остальные — можно смело засунуть в бэклог и никогда до них не дойти. - Сложные планы агенты реализуют неэффективно. Ну то есть человек смотрит на объем работ из плана и начинает отмечать кластеры работы, группировать изменения, делать сначала code complete, точечно проверять в реальных сценариях на реальных сервера, а потом уже тестить всё полными e2e. Агент (без специальных инструкций) послушно выполняет план и постоянно сползает в сторону "после каждого изменения запустить тесты". Сначала я думал, что проблема в моём харнессе вокруг проекта, но потом у меня появилось ещё три других проекта, где всё было совсем по-другому, а проблемы те же. Противоядие от этих проблем есть. Нужно понимать проект (как с технической, так и с продуктовой стороны). И иногда проваливаться очень глубоко в реализацию (когда начинается очевидный булщит вместо фикса кода). Это раздражает, но пока по-другому никак. Если что, у меня gpt-5.6-sol xhigh и Fable 5 xhigh. Другие модели работают ещё хуже (отдельная подстава с Opus 5 на который иногда делает авто-фолбэк Fable 5). — Если у вас нет таких проблем, скорее всего проект не сильно сложный. Ну или вы — чертов гений! Хочу с вами познакомиться, чтобы вы меня научили.

GitHub добавил stacked pull requests GitHub запустил публичное тестирование stacked pull requests — цепочек связанных PR, которые нужно сливать по порядку. main └ branch-1 → PR 1 └ branch-2 → PR 2 └ branch-3 → PR 3 Например: PR 1 добавляет новую структуру данных; PR 2 использует её в API; PR 3 добавляет интерфейс. Такую цепочку можно было собрать и раньше, но следить за ветками, их порядком и обновлением приходилось вручную. Теперь GitHub встроил поддержку этого процесса: • показывает весь "стек" и порядок изменений; • в каждом PR показывает только изменения его слоя • позволяет ревьюить все части параллельно; • помогает обновлять оставшиеся ветки после слияния нижнего PR; • может слить сразу несколько готовых слоёв в правильном порядке.

Прогать с агентом зачастую выматывает сильнее, чем без него. Сначала надо сгенерить код. Это кажется просто, но перед этим действием нужно уже провести много работы, продумать требования и нюансы (ибо магии нет: говно на входе = говно на выходе). План-хуян. Потом наконец генеришь и даёшь другому агенту на ревью. Если код сложный, то в 99% случаев что-то вылезает. Ладно, чинишь. Даёшь другому агенту посмотреть. Вылезает что-то странное, ты не понимаешь, он прав или нет. Начинаешь читать код вручную (это всё равно пришлось бы делать, но надеялся, что позже, когда основное будет пофикшено). Читать чужой код, написанный инопланетянамм (сам бы так не написал). Тратишь дофигища энергии, чтобы построить в голове ментальную модель высера. Просишь объяснить тестами. Понимаешь, что это нечитаемое говно, просишь агента переделать так-то и упростить тут-то. И всё равно - ну не то, блин. Нет удовольствия от хорошо сделанной раьоты. Наконец, понимаешь, что имелось в виду на втором код ревью от агента. Начинаешь копать, и понимаешь, что это не просто корнер кейс, а возможно вообще к задаче надо было подходить по-другому, и надо обсуждать с коллегами, иьо а таком виде задачу, может, и не решить вообще. И так целыми днями. Про баги на проде я уже писал - чинить их намного сложнее, так как в голове не прошивается нужная информация. А как было раньше: моменты обдумывания чередовались моментами медитативного прописывания. Модель в мозгу выстраивалась постепенно и надолго. Было удовольствие от полученного кода. эх

https://deployhoroscope.com/

Apple запилила свой докер apple/container — это CLI-инструмент для создания и запуска Linux-контейнеров на Mac. Релиз 1.0 был пару недель назад. Написан на Swift, разработан для Apple silicon. Работает с OCI-совместимыми образами, то есть умеет тянуть и пушить образы из обычных container registry. Apple прямо описывает его как инструмент для запуска Linux containers as lightweight virtual machines на Mac. Docker Desktop на macOS сейчас живёт вокруг большой Linux VM, внутри которой уже крутятся контейнеры. Apple сделал по-другому: каждый контейнер запускается в своей лёгкой виртуальной машине. В описании Apple говорит, что такой подход даёт каждому контейнеру изоляцию уровня VM, уменьшает объём того, что надо шарить с хоста, и при этом сохраняет время старта, сравнимое с контейнерами внутри общей VM. Стартовать сервис: container system start Посмотреть контейнеры: container list --all Можно запускать образы, собирать image из Dockerfile, работать с registry, смотреть логи, настраивать volume mounts и ресурсы. Так как контейнер — это lightweight VM, у него есть свои CPU и memory limits. По умолчанию обычный container получает 1 GB RAM и 4 CPU, а builder VM — 2 GB RAM и 2 CPU. Для тяжёлых сборок это можно подкручивать: например, container builder start --cpus 8 --memory 32g. Можно создавать отдельные изолированные networks через container network create, задавать IPv4/IPv6 subnets и запускать контейнеры в выбранной сети. Контейнеры в разных сетях друг друга не видят. Разумеется, это не значит, что Docker Desktop завтра умер: Docker - огромная экосистема, Compose, привычки, интеграции, документация, корпоративные сценарии, да и просто инерция. apple/container пока выглядит скорее как фундамент. Apple хочет, чтобы Linux-контейнеры на Mac стали частью платформы. Также, помимо cli, Apple открыла apple/containerization — Swift package для запуска Linux containers на macOS. Он даёт API для OCI images, registry, ext4 filesystems, Netlink, запуска лёгких VM, containerized processes и т.д.

🌐 HTTP QUERY: новый метод для поисковых запросов В мире HTTP давно существует проблема с передачей сложных поисковых запросов. Когда разработчику нужно передать большой набор параметров для поиска или фильтрации, у него есть два не самых удачных варианта.…

Что меня бесит в ИИ - это то, что как ему ни описывай задание, хоть максимально подробно и с утверждением плана, всё равно есть пространство для манёвра, где агент сам принимает решение, о котором ты не узнаешь, пока не получишь граблями по башке. Никакой спек-дривен девелопмент не поможет. Ты не можешь описать вообще все нюансы в мире, проще тогда код написать самому на формальном языке (языке программирования). Например, несколько раз было, что ошибку агент решал почему-то просто залогировать там, где надо было упасть нахер, чтобы избежать неконсистентности в данных. И если невнимательно ревьювить код, то увидишь ты эту проблему только когда, собственно, эту неконсистентность на проде и получишь. А когда сам пишешь код (например, на Go), то каждый раз приходится явно думать, что делать с ошибкой, падать/не падать или вообще как-то по-другому пытаться избегать. И во всех других ситуациях ты явно принимаешь решения в вопросах, о которых не подумал заранее.

Вайбкодеры объясняют про айти. Это ржака Прод у них по ночам самообновляется и падает, капец

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

Вот такой получился график % кода, написанного с помощью ии-агентов в динамике. Очень, конечно, быстро всё меняется. Еще в начале декабря только избранные писали весь код ии-шкой, а сейчас это норма. А прошло каких-то жалких полгода. И ничего не устаканилось, динамика по-прежнему бешеная. На рынке труда тоже происходит что-то странное - с одной стороны массовые увольнения программистов "из-за AI" в бигтехах, с другой - количество вакансий в США, UK и т.д. по итогу выросло за последний год.

Github copilot (ИИ-агент) переходит с подписочной модели на оплату за реальное использование. Люди пишут что это означает для них расходы в тыщи баксов вместо десятков. Расход можно проверить с помощью инструмента, предоставленного гитхабом

На Reddit обсуждают новость: Microsoft сворачивает внутренние лицензии Claude Code после пилота для сотрудников. Главная причина, которую указывает статья - резкий рост расходов при переходе от понятных подписок к оплате по токенам/использованию. И это не только история про Microsoft. В материале также приводится пример Uber: компания, по сообщениям, израсходовала AI-бюджет на 2026 год всего за четыре месяца. Общий тезис такой: пока AI был безлимитной игрушкой, все радовались продуктивности. Когда пришли счета, началась оптимизация. Мнения разделились. Скептики говорят, что типа вот он, reality check. Если даже Microsoft начинает считать токены, значит экономика frontier-моделей пока не так прекрасна, как ее продавали. Особенно когда тысячи сотрудников используют AI неэффективно: длинные промпты, бесконечные генерации кода, споры с моделью, автозадачи на часы и дни. Многие считают, что проблема не в AI как таковом, а в неправильных kpi. Компании сами годами говорили сотрудникам, чтобы надо или не надо, а использовали AI везде. Но когда KPI - больше AI-usage, а ограничений нет, то расходы летят в космос. Есть еще позиция, что это не конец AI, а взросление рынка. Безлимитные тарифы плохо работают для тяжелых enterprise-нагрузок. Где-то останется облако и frontier-модели, где-то появятся лимиты, роутинг на более дешевые модели, open-source и локальные решения. В любом случае, AI больше нельзя оценивать только по принципу "ускоряет или нет". Теперь вопрос звучит немного иначе: ускоряет ли он настолько, чтобы окупить токены? Возможно, будущее не в одном волшебном ассистенте за любые деньги, а в гибридной системе: дорогие модели — для сложного, дешевые — для рутинного, локальные — там, где объемы предсказуемы. AI пока не отменяется, но ему наконец-то выставили счет.

Сегодня узнал, что bun переписали с Zig на Rust с помощью claude code за считанные дни и уже вмержили в main Фиговы тыщи комитов, миллион строк кода Это прям эпохальный эксперимент в реальном времени. С одной стороны, это 100% нейрослоп, которые явно люди даже не смотрели, с другой стороны, работает же. Там переносили по возможности прям один к одному, и структуры и архитектурные решения, было до фига тестов и т.д. Но блин, масштаб поражает. Интересны две вещи: реально ли будет это потом поддерживать, и сколько багов/уязвимостей повылезет (там было много unsafe Rust, говорят) в ходе реального использования. Я читал обсуждение, что часть тестов были переписаны по другому, и есть подозрение, что некоторые из них подогнаны под код, чтобы проходили. В интересное время, живём, блин

Этот ролик длиннее, чем средний мем про гонку технологий и паралич выбора, но он хорош, не могу не поделиться: https://www.youtube.com/watch?v=xE9W9Ghe4Jk

Жена спросила у ChatGPT, как по-чешски будет "отравилась". Чат ответил, но зачем-то пририсовал график y=x :) Сидим, гадаем, что он имел в виду. График отравлений какой-то? Вот так вот в вайбкоде вылезет внезапно, я не знаю, таблица Менделеева

Многие стали разгонять тему, уже 10 раз такое слышал, что UI в обычном его понимании исчезнет, и будет только условная строка чата, через которую можно всё сделать: купить билеты и записаться к доктору. И поэтому, опять же, программисты практически не будут нужны. Но я что-то с этим вообще не согласен. Мне удобнее одной кнопкой запустить банковское приложение и одной кнопкой в этом приложении погасить долг по кредитке. И сразу увидеть сколько осталось на счету. Чем долго и муторно писать это всё словами. Ну и есть куча всего, что не поддается текстовому описанию. Карты те же. Графики, обновляемые в реальном времени. Да куча всего. Хотя, конечно, искать товар, когда ты точно не знаешь, что тебе нужно, удобнее в чате. Но это как бы просто гугл на максималках. Еще до ИИ всегда было два варианта: зайти на маркетплейс полистать товары или нагуглить. Ну и естественно, помимо UI, программисты делают кучу всего. Внезапно, бекенд, например 🙂

Dirty Frag — это новая локальная уязвимость в Linux, для которой уже выложили публичный PoC на GitHub. Если объяснять просто: пользователь с обычными правами может через ошибку в ядре повлиять на данные в файловом кэше Linux и потенциально повысить права до root. Проблема связана не с прямой записью в файлы, а с тем, как ядро работает с памятью, сетевыми буферами и page cache. Файл на диске может оставаться неизменным, но система будет читать его изменённую копию из памяти. Опасность в том, что, по словам автора, Dirty Frag работает стабильнее многих похожих багов: не нужно ловить race condition, а значит шанс успешной эксплуатации выше. В репозитории упоминаются популярные дистрибутивы вроде Ubuntu, Fedora, openSUSE, AlmaLinux, CentOS Stream и RHEL.

Про падения гитхаба: "79.99% has three nines!"