На 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 пока не отменяется, но ему наконец-то выставили счет.

Github copilot (ИИ-агент) переходит с подписочной модели на оплату за реальное использование.

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

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

На рынке труда тоже происходит что-то странное - с одной стороны массовые увольнения программистов "из-за AI" в бигтехах, с другой - количество вакансий в США, UK и т.д. по итогу выросло за последний год.

Посоветуйте плиз подкасты айтишные, такие, чтоб полезно было. Какую-то дельную мысль чтобы можно было вынести.

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

По-русски, по-английски или по-чешски (ну, а вдруг)

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

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

Никакой спек-дривен девелопмент не поможет. Ты не можешь описать вообще все нюансы в мире, проще тогда код написать самому на формальном языке (языке программирования).

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

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

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

Оказывается, новый http-метод QUERY опубликован как RFC 10008

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 и т.д.

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

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

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

И так целыми днями. Про баги на проде я уже писал - чинить их намного сложнее, так как в голове не прошивается нужная информация.

А как было раньше: моменты обдумывания чередовались моментами медитативного прописывания. Модель в мозгу выстраивалась постепенно и надолго. Было удовольствие от полученного кода.

эх