IT

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

То есть если вы написали какое-то фронтенд-приложение и вам нужна база, то вместо того чтобы прикручивать сложные сторонние сервисы или пытаться хранить всё в Local Storage, вы можете прямо в админке своего сайта включить базу данных, создать необходимые таблицы и получить полноценный API для работы с ними.

Плюс можно создать таблицы, необходимые для аутентификации пользователей, и получить весь нужный функционал для регистрации, авторизации и так далее. 👌 В целом всё это работает хорошо. Я сам построил на этом несколько сайтов, моя игра тоже использует эту базу данных, а жена сделала несколько приложений, которые так или иначе с ней работают. 🤔 И вот как раз жена первой начала мне репортить, что иногда у неё просто пропадает таблица с рейтингом. Но после перезагрузки всё снова появляется и данные приходят. На тот момент я счёл этот баг не очень интересным. 🤷‍♂️ Подумал, что, может быть, произошла какая-то сетевая задержка или что-то было не так в её клиентском JavaScript. Я спросил: — Сейчас работает? Она сказала: — Сейчас работает. И мы такие: — Ну, работает — не трожь. Значит, всё хорошо. 👀 Но относительно недавно я прикрутил полноценный мониторинг ко всем функциям YHub. Раньше я мониторил только сам YHub и его основные модули: работает ли приложение, отвечает ли сервер. А теперь начал дополнительно проверять отдельные фичи, чтобы убедиться, что они тоже работают и ничего не отвалилось. И вот мониторинг начал ловить нестабильные ошибки. Условно, сначала он получает 200 OK: всё хорошо, база работает, данные записываются. ✅ Через пять минут приходит 404, будто база данных вообще не включена. ❌ А ещё через пять минут снова 200 OK, и всё опять прекрасно работает. ✅ Такое поведение — когда что-то работает, через пять минут не работает, а потом снова работает — это, наверное, самое неприятное, что может произойти при отладке. 😩 Баг не воспроизводится стабильно, поэтому непонятно, за что вообще цепляться. Но, вооружившись Codex, своими наблюдениями и несколькими теориями, я пошёл дебажить архитектуру и нашёл очень интересный момент. 🤔 На моём хостинге используется PHP Runtime. Чтобы всё это было безопасно, я изолирую сайты на уровне операционной системы. Для каждого окружения создаётся отдельный PHP-FPM-пул, который работает внутри собственного chroot. Благодаря этому процессы разных пользователей не должны видеть файлы друг друга. 😬 Но, когда я настраивал эту изоляцию, я пропустил одну важную настройку в OPcache. OPcache хранит в общей памяти уже скомпилированный байткод PHP-скриптов, чтобы не разбирать и не компилировать их заново при каждом запросе. Проблема была в том, что внутри каждого изолированного окружения сгенерированный API-скрипт находился по одному и тому же пути. А настройка opcache.validate_root, которая заставляет OPcache учитывать конкретный chroot, у меня была выключена. 🤦‍♂️ В результате для OPcache скрипты разных пользователей могли выглядеть как один и тот же файл. OPcache мог взять скомпилированный скрипт из одного окружения и использовать его при запросе к другому. 🤷‍♂️ В какой-то момент в кэше оказывалась скомпилированная версия скрипта сайта, на котором база была отключена. Поэтому мой сайт внезапно получал 404, хотя у него самого всё было включено и настроено. 💡 Это интересный пример того, как кэширование становится источником проблем в разработке. Кэширование — это, конечно, хорошо. Я не говорю, что его нужно избегать. Оно ускоряет работу системы и часто действительно необходимо. Но кэшировать тоже нужно с умом. В моём случае я просто забыл указать в настройках, что кэширование должно учитывать chroot пользователя, и получил вот такую интересную проблему. Причём именно мониторинг помог мне с ней разобраться. У меня были конкретные даты и время, когда всё работало, а когда отваливалось. Без мониторинга я вообще не представляю, как бы это отдебажил. 😅 Но теперь всё исправлено. После изменения настройки ошибка больше не повторялась, а мониторинг снова стабильно зелёный. 💪 Свята место | 10МДК | ВЕБМастер | YHub

Падение Accenture - не самая интересная часть этой истории. Интереснее то, что рынок начал переоценивать саму модель IT-консалтинга. После снижения прогноза акции Accenture резко упали, а вместе с ними просели Cognizant, EPAM, Capgemini, Wipro и другие крупные игроки. Все обсуждают слабый квартал, но за этим, по-моему, стоит куда более фундаментальная штука. Последние двадцать лет экономика консалтинга была устроена предельно просто: продаём часы умных людей. Чем больше консультантов и чем сложнее проект, тем выше выручка, и все метрики: загрузка, headcount, utilization - выстроены вокруг этой идеи. AI ломает ровно её. Архитектуру, документацию, разработку, тестирование и часть внедрения сегодня можно сделать в разы быстрее, и клиенты прекрасно это видят. Как только себестоимость проекта падает, они начинают требовать фиксированную цену или оплату за результат вместо time & materials. Но самое сложное для крупных компаний вовсе не внедрить Claude, Cursor или ChatGPT - это сегодня умеют почти все. Гораздо труднее перестроить систему мотивации, которая десятилетиями поощряла продавать больше часов и нанимать больше людей. Переход к AI окажется для многих не технологической задачей, а организационной. При этом рынок, по-моему, пока недооценивает ещё один актив. Люди были главным капиталом консалтинга и останутся ими. Просто ценность теперь у тех, кто умеет дирижировать агентами, и у своего слоя знаний, на котором эти агенты работают. Не база документов и не RAG, а проверенная система отраслевой экспертизы, лучших практик, конфигураций, шаблонов и накопленного опыта, на которой работают тысячи агентов. С понятной моделью монетизации и достаточно уникальная, чтобы её нельзя было заменить очередной новой моделью Anthropic, OpenAI или Cursor. Вот здесь и будет формироваться новая стоимость бизнеса. Через несколько лет инвесторы станут смотреть не только на количество сотрудников и EBITDA, но и на то, сколько уникального контекста принадлежит компании, насколько глубоко он встроен в работу агентов и способен ли приносить деньги независимо от того, какая LLM окажется лидером рынка. Возможно, этот интеллектуальный слой станет для консалтинга тем же, чем данные когда-то стали для Google, а рекомендательные алгоритмы для Netflix. @maxvotek | linkedin | substack

Почему компанию нельзя завайбкодить Почти каждый день ко мне приходят фаундеры-энтузиасты вайбкодинга. Логика у всех одна: раз AI пишет код, значит собрать SaaS теперь может любой, а старые игроки обречены. «SaaSpocalypse», конец эпохи. Давайте разберемся. Мой главный тезис: код — это только часть софтверной компании. Причём меньшая. Предлагаю мысленный эксперимент: представьте, что весь код Hubspot или Quickbooks выложили в открытый доступ, целиком и бесплатно. Смогли бы вы с ним конкурировать? Нет. Потому что дальше начинается то, что вайбкодинг не закрывает. В три часа ночи всплывает уязвимость в библиотеке — её надо патчить. Продакшн надо держать живым. Освоение продукта пользователями надо продавливать. Написать код — один кусок работы, а запустить и поддерживать в масштабе — совсем другой, и вот он реально тяжёлый. И его добивающий аргумент: если CRM и систему бух учета можно завайбкодить силами хоть сотни инженеров — почему мы не видим ни одной такой компании прямо сейчас? Где они? Люди недооценивают, сколько сложности накопилось в этих системах за десять лет. Снаружи её не видно, но она есть. Отдельно хочу остановится на том, почему AI спотыкается именно в B2B-продажах. Продажа — асимметричная игра: покупатель не обязан говорить вам правду и вполне может соврать.

У меня нет бюджета

Решение принимаю я

Хотя не он.

Мы смотрим ваших конкурентов

Хотя не смотрят. Чтобы работать в этой мути, нужен отличный контекст и понимание расстановки сил внутри компании. А AI обучен быть правдоподобным. Но выигрышный ход в переговорах часто именно неправдоподобный: странный, нелогичный на вид — и при этом работающий. Читать комнату, чувствовать момент, идти против очевидного — пока не про него. Мой вывод для тех, кто приходит ко мне с горящими глазами: вайбкодинг радикально удешевил прототип. Это правда, и это прекрасно. Но прототип — не компания. Ров теперь не в коде, а во всём, что вокруг него: в эксплуатации, в поддержке, в накопленной сложности и в тех местах, где нужно человеческое суждение, а не правдоподобный ответ. Я сам вайбкожу — на той же неделе собирал в Claude Code рутину под свои задачи — и именно поэтому вижу, где кончается «собрал за выходные» и начинается «держишь в проде годами». А вы замечаете эту разницу — между прототипом и компанией? Или всё-таки верите, что AI скоро закроет и вторую часть? Делитесь в комментариях Андрей Резинкин | Money For Startup

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

"Это зачем еще? Сначала напиши алгоритм на бумажечке, а потом уже переноси в компьютер."

Тогда это вполне имело смысл, ведь еще не было IDE с автоподстановками/автопроверками, программы занимали килобайты, не гигабайты, а в НИИ даже встречались перфокарты. Но важен еще один момент: чтобы писать код эффективнее, сначала нужна какая-то канва. Сначала обходились просто детальным ТЗ на работы. Затем придумали разные подходы, которые помогают создавать код не просто с чистого листа, а на какой-то основе. Я имею в виду Test-Driven Development (TDD), когда в основе правильного кода лежат успешные тесты, Behavior-Driven Development (BDD), когда в основе кода - конкретные сценарии. И прочие DD. Появление ИИ-помощников в работе повлияло на эти процессы. Несколько месяцев назад GitHub представил подход Spec-Driven Development (SDD). Суть в том, чтобы сначала создать спецификацию, затем скормить ее ИИ-агенту, на ее основе будет составлен план работ и потом строго по плану реализация.

Spec → Plan → Tasks → Implement

То есть теперь не просто пишем промпт "Нарисуй форму", а описываем цели, поведение, граничные условия, исключения и т.д. Для претворения этого дела в жизнь они опубликовали опенсорсный инструментарий - Spec Kit. Поддерживается 35 кодинговых агентов, имеет 138 расширений, может работать оффлайн. В репозитории есть ссылки на обзоры и сообщества. 123 тысячи звезд на Гитхабе, 257 контрибьюторов. #process

Не раз и не два вижу как у людей из ИТ блокирует каналы по неизвестным жалобам на контент, и Телеграм предлагает писать на abuse@telegram.org (то есть на деревню дедушке). Народ не отсекает, за что. За что прилетело (с вероятностью в 99%) в последнем видимом случае: - инструкции и хаки по обходу региональных и санкционных ограничений со стороны Apple. Для разработчиков. Скрытие региона аккаунта и советы, как пройти проверку. Как это устроено внутри: Apple, наряду с Nintendo, имеет четкие и продвинутые системы мониторинга. Точнее, имеют их подрядчики. Скан публичных каналов работает с задержкой, иногда лаг достигает месяцев и даже годов, но будьте уверены, когда автоматический сканер доберется до ваших постов, другая часть системы так же автоматически кинет на вас страйк в ТГ. И ТГ пачкой удалит и заблокирует, точно так же автоматически, ваши каналы, посты и наложит на вас ограничения. Хуже, чем Apple или Нинтендо, только мейджоры-правообладатели. Как шутят в соседнем чате, самый ад — это правообладатели Смешариков. Что делать: 1. Посты с обходами ограничений или хаков публикуйте на время. Сносите их через пару недель — лаг "обхода" куда дольше, вероятность, что прилетит, пока пост висит — маленькая. 2. Не трогайте Apple, Nintendo. Всякие Антропики, Опенаи и прочие не занимаются пока подобным. 3. Если все таки прилетело — сносите посты, пишите слезную жалобу на abuse@telegra.org и обещайте, что больше так не будете.

В России запустили платный госмессенджер для заключённых. ФСИН начала тестирование в трёх колониях защищённого мессенджера «Точка контакта» — ИК-6 в Псковской области, ИК-6 и ИК-7 в Ленинградской области. Разработчик — компания «Защищённые телекоммуникации» (ранее «Зонателеком»). Сервис позволяет отправлять текстовые, голосовые и видеосообщения, фото и файлы. Пользоваться мобильным приложением смогут только родственники на воле. Заключенным никто смартфоны выдавать не будет — в колониях установят специальные терминалы коллективного доступа. Все сообщения проходят обязательную цензуру, доставка занимает до трёх рабочих дней. Каждое действие платное: письмо до 2500 знаков — 35 рублей, короткое сообщение — 3,09 рубля. Для сравнения, отправка бумажного бланка через старые сервисы стоила 75 рублей. После завершения пилотного проекта сервис планируют масштабировать на все регионы. Инициатива имеет потенциал для поддержания социализации и в конечном счете это хорошо с точки зрения гуманизма. Авторы молодцы.

USRW 2026: Call for Papers — дедлайн продлён до 27 июля 🔎 Это тот самый Unified Search and Recommendation Workshop, который я недавно упоминал в посте про мои воркшопы на RecSys. Теперь можно наконец рассказать подробнее: мы опубликовали программу и открыли приём статей. Для меня это первый опыт организации отдельного воркшопа — и особенно приятно, что он посвящён теме, вокруг которой, собственно, и строится этот канал. Главная идея USRW проста: поиск и рекомендации слишком долго развивались как разные дисциплины, хотя обе решают одну и ту же задачу — помогают человеку найти нужный контент. С появлением LLM, generative retrieval и агентных систем граница между query-driven search и feed-driven recommendation становится всё менее естественной. Но «объединить» не значит просто объявить поиск и рекомендации одной и той же задачей. Мы хотим разобраться, что действительно можно сделать общим — данные, представления, генерацию кандидатов, ранжирование, интерфейсы и протоколы оценки, — а где различия в сигналах, UX, задержке, стоимости и управляемости остаются принципиальными. В программе: 🎤 Mounia Lalmas (Senior Director of Research, Spotify) — «Building AI-Driven Experiences at Scale: When Search and Recommendation Become One Conversation» 🎤 Harrie Oosterhuis (Associate Professor, University of Amsterdam / Amazon Scholar Amazon Music) — «Learning to Rank Everything, Everywhere and All at Once» 🧭 Dive Deep tutorial, который мы проведём вместе с Gustavo Penha. Поговорим об общих корнях поиска и рекомендаций, слоях их возможного объединения, semantic IDs, generative retrieval, языковых интерфейсах, агентах и реальных production-компромиссах. В Call for Papers ждём работы про: • единые модели поиска и рекомендаций; • общие представления пользователей и объектов; • моделирование поведения между search- и feed-сценариями; • LLM для понимания запросов и намерений; • generative retrieval, semantic IDs, RAG и agentic discovery; • смешанные поисково-рекомендательные интерфейсы; • общую инфраструктуру и методы оценки; • эффективность, устойчивость и безопасность; • индустриальные кейсы, датасеты и benchmarks. Формат: 4–9 страниц без списка литературы, ACM SIGCONF, двойное слепое рецензирование. Воркшоп неархивный: принятая статья будет размещена на сайте USRW, но авторы сохраняют право впоследствии отправить её расширенную версию в конференцию или журнал. Также выберем лучшую работу для Best Paper Award. ⏰ Дедлайн подачи: 27 июля 2026 года, 23:59 AoE 📍 Воркшоп: 2 октября 2026 года, Миннеаполис, ACM RecSys 2026 🔗 Сайт, полный CFP и подача статьи: https://usrw-workshop.github.io/2026/ Организуем USRW вместе с Sean MacAvaney (University of Glasgow), Gustavo Penha (Spotify), Léa Briand (Deezer) и Clémence Vast (Deezer). Если у вас есть работа на стыке поиска и рекомендаций — от новой модели до индустриального кейса или benchmark, — буду очень рад увидеть её на USRW. И буду благодарен, если перешлёте этот анонс коллегам, которым тема может быть близка 🙌

В канале Нади увидел облако ее тг постов за все года. Решил не дожидаться 300🔥 ради сорсов и позвонил Гермесу: 📞 Хочу также, только на моем сайте и во времени, а готовые эмбеддинги возьми из gbrain Пару голосовух спустя, получился таймлайн моих постов (тестил только на мобиле, сори): 🤩 okhlopkov.com/karta-postov-telegram Если хотите попрактиковаться в AI, попробуйте сделать аналогичное для себя: можно не только тг посты, но и любые файлы, статьи, заметки. Закиньте ссылку выше как референс и газ в пол.

Поиск постов канала это конечно круто, но если ищешь что-то конкретное, то лучше спросить у @fiztehbot или в чате @ohld_chat.

Я на две недели в отпуске без компа. Не лопните пузырь тут без меня 🥀

NVIDIA похоже тайно скупает тёмное оптоволокно* по всем США По данным аналитических компаний Needham и Wolfe Research, NVIDIA приобретает тёмные магистральные линии. При использовании DWDM** (до 96 каналов на волокно в данном случае) и скорости 800 Гбит/с общая пропускная способность достигает 7,6 Пбит/с. Инвестиции в проект оцениваются в $5–10 млрд на три года. Делается это вероятно для объединения дата-центров, аренды неоклаудам*** и запуска собственного сервиса «графические процессоры как услуга» (GPU-as-a-Service) напрямую корпоративным клиентам, в обход гиперскейлеров****. NVIDIA уже имеет 9,3% в неоклауде Nebius. Похоже, компания строит свою инфраструктуру, чтобы не зависеть от Amazon, Google и Microsoft. Но, самое интересное тут наверное даже не это, а терминология, с которой пришлось разобраться при написании этой новостной заметки. Если знали значение всех четырех терминов, можете считать себя гуру IT. * Во-первых, само тёмное волокно. Что это такое? Никакой мистики или астрофизики — это проложенные, но неиспользуемые самые обычные оптоволоконные кабели. Арендатор сам устанавливает на них своё активное оборудование и получает полный контроль над сетью. ** DWDM или Dense Wavelength Division Multiplexing (плотное мультиплексирование с разделением по длинам волн) — это технология, позволяющая передавать множество независимых сигналов по одному оптоволокну, используя разные цвета (длины волн) лазерного излучения. *** Неоклауды — это новые облачные провайдеры, которые специализируются на предоставлении мощностей именно для обучения и работы ИИ-моделей, в отличие от универсальных облаков Amazon, Google и Microsoft. **** Гиперскейлеры — это крупнейшие провайдеры облачных услуг, такие как Amazon (AWS), Google (Cloud) и Microsoft (Azure), которые строят и эксплуатируют огромные дата-центры по всему миру, чтобы предоставлять вычислительные мощности, хранилища и сервисы в аренду другим компаниям и разработчикам.

✔️ Alibaba откроет код альтернативы CUDA Полупроводниковое подразделение Alibaba (T-Head) анонсировало открытие исходного кода стека SAIL для фирменных ИИ-ускорителей Zhenwu. Проект анонсировали на Всемирной конференции по ИИ в качестве открытой альтернативы экосистеме Nvidia CUDA. По заявлению T-Head, адаптация SAIL под популярные ML-фреймворки занимает менее 7 дней. Флагманом линейки выступает процессор Zhenwu M890, представленный в мае и спроектированный для работы с ИИ-агентами. Alibaba ранее сообщала об отгрузке более 560 тысяч таких чипов сотням корпоративных клиентов. scmp.com ✔️ Moonshot приостановил оформление подписок на Kimi K3 Стартап временно остановил продажу подписок на модель Kimi K3 из-за нехватки вычислительных мощностей. Действующие пользователи работают без ограничений, доступ новым клиентам откроют по мере масштабирования инфраструктуры. Для балансировки нагрузки на кластеры компания меняет систему монетизации и делит единую подписку на 2 тарифа. В план Kimi Membership входят веб-версия, мобильное приложение и стандартные сценарии использования. Для инженеров вводится Kimi Code Membership - ресурсы этого тарифа выделены только под генерацию и анализ кода. Такое разделение потоков должно стабилизировать работу сервиса. Kimi в сети Х ✔️ ИИ-вендоры всерьез присматриваются к чипам AMD Microsoft расширит использование ускорителей AMD в инфраструктуре Azure. Во второй половине 2026 года компания запустит вычислительную платформу AMD Helios, оптимизированную для крупных моделей. Сатья Наделла объяснил расширение партнерства ценовой политикой Nvidia и конкуренцией со стороны TPU. Параллельно аппаратное обеспечение AMD тестирует Anthropic. По данным SemiAnalysis, AMD присвоила разработчику Claude высший приоритет поддержки наравне с Amazon. Ожидается, что компании официально анонсируют партнерство на конференции Advancing AI после решения проблем с оптимизацией программного стека. microsoft.com ✔️ ИИ спроектировал компоновку невидимого в полете одномоторного дрона Корпус аппарата Phantom Twist в полете вращается со скоростью до 25 оборотов в секунду, делая его почти невидимым за счет эффекта размытия. А процессе создания дрона ИИ сгенерировал 20 тысяч вариантов дизайна и симулировала их работу на фоне реальных пейзажей. Пропеллер и рама Phantom Twist крутятся в противоположных направлениях - в конструкции нет статичных деталей. Аппарат в 10 раз сложнее заметить, чем классический квадрокоптер. Авторы позиционируют устройство как инструмент для мониторинга дикой природы и осмотра инфраструктуры. northwestern.edu ✔️ Нил Бломкамп выпустил короткометражку, полностью сгенерированную в ИИ Известный по "Району №9" режиссер представил 13-минутный научно-фантастический хоррор Nightborne, полностью созданный с помощью видеомодели Seedance 2.0. Сюжет стилизован под документальное кино о военной программе, возвращающей в строй погибших солдат. Бломкамп управлял процессом покадрово, выстраивая сцены через промпты на основе концепт-артов, подготовленных художниками. Для генерации лиц и озвучки студия лицензировала биометрию 32 человек, чтобы избежать проблем с авторскими правами. Режиссёр заявил о планах снять полнометражный ИИ-фильм. Для реализации этих амбиций он уже открыл новую компанию, ориентированную на нейросетевой продакшен, которая придет на смену его классической студии Oats Studios. Neill Blomkamp в сети Х @ai_machinelearning_big_data #news #ai #ml

Этапы развития безопасности В авиации есть руководство по обеспечению безопасности полетов, которое издается Международной организацией гражданской авиации. Очень интересная книга, в каком-то плане лучший учебник по управлению рисками. Жаль, что я нашел его относительно недавно. В Руководстве выделяют 4 этапа в обеспечении безопасности полетов, эволюция того, как пытались сделать перелеты максимально безопасными. 1 этап: Технический С начала 1900-х по конец 1960-х годов основной фокус был на технической безопасности. Что логично — техника только развивалась, развивалось наше понимание того, почему происходят инциденты и аварии. Основной целью этого этапа было совершенствование технических систем. К 50-м годам количество инцидентов снизилось из-за совершенствования систем, а деятельность по обеспечению безопасности полетов распространилась на нормотворчество и надзор. 2 этап: Человеческий фактор К началу 1970-х годов техника стала достаточно надежной, правила полетов устоялись, и в целом количество авиационных происшествий значительно снизилось. Основной причиной инцидентов стали называть ошибки людей. Что логично, техника стала достаточно надежной. Но при расследовании аварии не изучали эксплуатационный и организационной контекст. Только в начале 1990-х годов было признано, что люди работают в сложных условиях, которые влияют и определяют поведение человека. 3 этап: Организационный С середине 1990-х годов безопасность стала рассматриваться системно и захватывала как организационные, так и человеческие и технические факторы. Было введено понятие "происшествие организационного характера". Этот подход учитывал воздействие, например, организационной культуры и политики на безопасности полетов. 4 этап: Общесистемный Начинает развиваться с началом XXI века. Этот подход еще больше расширяет контекст обеспечения безопасности. Он следует из того, что авиация рассматривается как большая сложная система и необходимо учитывать еще более широкий контекст. Существует множество примеров происшествий и инцидентов, из которых следует, что взаимодействие между организациями внесли свой вклад в отрицательный исход событий. То есть, обеспечение безопасности уже выходит за рамки одной компании, и должно охватывать всю систему. На мой взгляд, большинство компаний сейчас остались на втором этапе. Техника работает достаточно надежно, но организационный контекст и культура не учитываются - так что основная причина инцидентов это человек. В западных компаниях пытаются работать на уровне культуры, но на мой взгляд, до полного учета организационного контекста достаточно далеко. Хотя, может быть и есть крутые компании — но про них мало известно.

124 мегабайта ради расписания, которое влезло бы на одну страницу Тебе присылают ссылку на поездку, а за ней приложение на 43 мегабайта, разрастающееся до 124 после подгрузки. Внутри текст, картинки и ссылки на PDF. Всё то, что спокойно уместилось бы на веб-странице, которую можно скопировать, распечатать, сохранить и открыть на чём угодно. Вместо этого оно шлёт данные твоего гугл-аккаунта разработчикам и подсовывает рекламу других туров под видом «источников вдохновения». Одного человека это довело до того, что он полез перехватывать трафик приложения. Внутри обнаружилось, что логин с паролем просто склеиваются в один адрес, а сервер в ответ отдаёт готовый HTML. Тот самый, ради которого пришлось ставить 124 мегабайта: https://u.habr.com/jwc0u

Для того чтобы погонять Fable 5, пришлось вернуть подписку на Клода. В целом чувствуется, что модель сильнее Opus 4.8 (это проявляется в мелких деталях, подробнее писал в ИИ-лаборатории нашего клуба), но глобально ничего не меняется. Но вот что меня поразило, так это мои ощущения от использования Claude Code: как же я отвык от human in the loop, сидеть и постоянно контролировать - это не мое. У меня сейчас для работы сделано два оркестратора. Один реализует проектный SDLC, второй - общего назначения. Они связаны друг с другом и могут обмениваться заданиями и статусом выполнения, в общем агенте есть общий чат куда прилетают отчеты о выполнении. Развиваю проекты инкрементами, которые выглядят примерно так:

$soerdev add spec "Новая фича"
$soerdev refine spec
$soerdev plan
$soerdev run

Это реализация цикла Human ON the loop. Логика такая: добавляем драфт спеки, обсуждаем детали, фиксируем план, запускаем цикл до выполнения критериев останова. В работу не вмешиваюсь, но вижу в чате и телеграм боте что происходит. И знаете что? Это реально удобно! Теоретически что-то подобное можно настроить и в CLI-агентах, но все равно придется допиливать харнес для отправки сообщений в телеграм, делать свой аналог гейтов, делать скилы и промпты. А так все зашито в оркестратор soerdev.