/btw на максималках или Codex side chat Продолжаем рубрику подборка лучших UX решений. Когда кодишь с агентом довольно часто возникает ситуация, когда из одного чата нужно быстро форкнуться в новый чат, чтобы исправить что-то, возникшее по пути, не прерывая работы в старом чате. Раньше мы использовали fork для этих целей, но форк довольно тяжеловесный + не из всех состояний он доступен. В общем, если выделить текст в прямо чате Codex App'а, то сверху можно увидеть всплывающее меню с разными действмия, в т. ч. Ask in side chat. Наверное, видели. Можно подумать, что это старый добрый /btw а-ля клод код. Но нет, на деле у этого сайд чата тоже есть полноценный write доступ и из него действительно можно делать небольшие правки (например, в скиллах, как на скрине) прямо по ходу основной задачи, вообще никак в нее не вмешиваясь. Не знаю как вам, но мне не хватало такой возможности - настолько, что решил и вам рассказать. Напомню, что ранее я уже рассказывал про неочевидную удобную возможность реордеринга (как это по русски подскажите в комментариях) очереди сообщений в Codex App. Если не видели - посмотрите. А еще, теперь можно попросить Codex App запустить какую-то задачу в новом диалоге и он прям из текущего чата спавнет вам новый диалог. И читать сторонние или текущий диалог Codex App теперь тоже умеет. Подробнее про то, как это работает рассказывал Тимур. И да, в Claude Code Desktop тоже есть подобный side chat, но он readonly, что не так интересно, хоть и удобно иногда что-то доспросить. @ai_driven

Модель тройного долга от соавтора фреймворка SPACE Маргарет-Энн Стори, соавтор фреймворка SPACE для повышения продуктивности разработчиков, недавно представила свою модель тройного долга (Triple Debt Model), в которой скрытые человеческие издержки ускоренной с помощью ИИ разработки программного обеспечения рассматриваются в трех категориях: технический долг, который накапливается в коде. когнитивный долг, который накапливается в людях, входящих в команду. долг намерений, который накапливается во внешних знаниях, состоящих из лежащих в основе проекта соображений, целей и проектных ограничений, которые недостаточно задокументированы. И идея там довольно простая: AI позволяет нам быстрее производить код, но это совсем не значит, что мы автоматически быстрее производим хорошие и понятные системы. Просто долг начинает накапливаться немного в других местах😉 Всего Стори выделяет три вида долга: 1. Технический долг Плохие архитектурные решения, костыли, сложный код, отсутствие тестов и все то, что потом делает систему дорогой в изменении и поддержке. Причем тут есть забавный парадокс. Именно этот долг AI потенциально умеет неплохо сокращать: -отрефакторить код; -написать тесты и т.п. То есть код может становиться даже лучше. 2. Когнитивный долг Это долг, который накапливается уже в голове разработчика: агент написал 1000 строк хорошего кода. И даже тесты все зеленые. Так что вперед и PR в проде. Только инженер, который этот PR принял, понимает систему чуть хуже, чем если бы писал это изменение самостоятельно. А потом еще один PR. И еще один. Иииии в какой-то момент получается довольно странная система: код работает, но никто толком не понимает почему. Скорость производства кода растет быстрее скорости нашего понимания системы. Вот это Стори и называет cognitive debt. И да, тот факт, что скорость производства выросла - это супер! В этом вся суть моей работы, в принципе. 3. Долг намерений — Intent Debt А вот это типовая проблема, которая всплыла наверх. Раньше она тоже была, но мы особо ей внимание не уделяли. Можно прекрасно понимать, как работает код, но совершенно не понимать: почему он работает именно так? Какие продуктовые ограничения существовали? Что вообще хотел пользователь? Какие компромиссы были приняты? Все это обычно живет где-то между: - ADR; - документацией; - и, конечно же в голове того самого Тим-лида😁 А теперь представьте AI-first разработку. Один агент написал изменение. Через полгода другой агент должен его изменить. И второй агент пытается понять намерения первого агента… по коду первого агента. Ну удачи. В мире AI-разработки документация, ADR, спецификации, acceptance criteria и domain model — это уже не какая-то бюрократия рядом с разработкой. Это внешняя память вашей системы (на следующей неделе расскажу, как решают и эту задачку) Причем память нужна уже не только людям, но и агентам. Последние пару лет мы в основном спрашивали: как заставить AI писать больше хорошего кода? Но следующий вопрос будет: как сделать так, чтобы люди и AI продолжали понимать систему, пока AI пишет все больше кода? Потому что код становится все дешевле. А вот понимание: -зачем система существует; - почему она устроена именно так; - какие ограничения нельзя нарушать; становится только дороже. И возможно, через несколько лет главным инженерным активом компании будет уже не сам код. А накопленный контекст вокруг него.

Жена спросила: а если у нас столько шарящих в ИИ людей - и звезды Kaggle, и победители межнара по ИИ, почему все еще нет своей конкурентной нейросети, а не китайского опенсорса с дообучением? (Про заслуги китайского Qwen в отечественном ИИ я жене уже рассказывал) Я тяжело вздохнул и ответил, что этому слегка мешают три обстоятельства. Во-первых, наш язык, в отличие от английского, не стал международным, а жить в России, не говоря по-русски, довольно затруднительно. Поэтому возможности привлекать лучших ученых и инженеров со всего мира у нас существенно ограничены. Сюда же добавляется довольно скромная демография: в Китае тоже не то чтобы очень удобно жить англоговорящим, но там пошли по пути, когда и своих кадров на многое хватает. Во-вторых, наша экономика пока что увы не входит в топ-3 экономик Мира, и на сопоставимые инвестиции в ИИ у нас просто не то чтобы есть деньги. Ну и в-третьих, конечно нельзя не вспомнить про отставание в микроэлектронике и отсутствие каких-то перспектив на свое железо для ИИ. Конечно, остался вопрос, значит ли, что в России своих LLMок так и не появится. И тут конечно ответ не столь категоричный. Во-первых, очень может быть, что через несколько лет модели выйдут на плато по качеству, а вычислительные мощности какого-нибудь нового железа от Nvidia будут позволять делать pretrain до качества, слабо отличимого от топового на практике. Во-вторых, альтернативные подходы к архитектуре (SMM или какие-нибудь особо экзотические ветки развития attention) могут все же дать результат и удешевить процесс для всех. В-третьих, чтобы сократить отставание не нужно во всём прям быть первыми, а быть вторым или третьим существенно дешевле. Так что если кратко - это дорого, сложно и пока никому не было настолько сильно нужно, но на горизонте нескольких лет ситуация может и поменяться. А как бы ответили вы?

🛠 Инструменты • ToonBee — создание мультфильмов с помощью ИИ — Сервис для генерации мультфильмов с использованием ИИ. • Command Code — ИИ-агент для кода в терминале — ИИ-агент, который учится вашим предпочтениям при работе с кодом. • Seedream 5 Pro — генерация изображений — Генерация изображений, готовых к использованию, по промптам. • NameThatUI — словарь UI — Опишите словами интерфейс, получите название и промпт для кодера. • Secured AI — приватный ИИ-ассистент — Защищает конфиденциальные данные при использовании ИИ. • Cloudflare запускает Kitesurf — браузер для AI-агентов — Браузер, созданный для AI-агентов. • Devin — автономный AI-инженер — Автономный AI-инженер от Cognition, выполняющий задачи от начала до конца.

Линус Торвальдс назвал гигантские патчи ядра Linux «новой нормой» из-за нейросетей Релиз Linux 7.2 оказался аномально крупным по количеству коммитов, однако Торвальдс не видит поводов для переноса сроков. По его словам, разрастание обновлений стало постоянной тенденцией, и существенную роль в этом сыграли ИИ-инструменты, с помощью которых разработчики автоматизируют проведение ревью и поиск ошибок. Основной объем Linux 7.2 составляют мелкие точечные исправления для драйверов, файловых систем и архитектурного кода, а из крупных изменений выделяются только правки для s390/zcrypt, netfilter и инфраструктуры btrfs. Если на финальной стадии тестирования не всплывут критические сбои, полноценный релиз ядра с обновленным планировщиком CPU и GPU состоится уже к концу текущей недели.

Так, что мы выяснили: 🔘Нововведения по форматированию текста в тг могут быть полезны в части формул и таблиц, но заголовки разных уровней, да и все остальное, будем честны, в телеграм пока что не актуальны. Короткие форматы постов более востребованы — рассчитывать, что среди нас много фанатов лонгридов не приходится (хоть вы и можете возразить, что вопрос весь в содержимом лонгрида). Есть ощущение, что экспериментировать лучше в сторону медиа контента 😶 🔘Всего 8% проголосовавших работают в геймдеве и не делают свои проекты. Получается, у людей в большинстве своем есть время, желание и возможности делать свои проекты 😍 🔘При этом 39% опрошенных делают только свой проект, не работая в найме. Это довольно высокий процент, интересно откуда берутся ресурсы делать проекты не работая, и какую часть разработчиков кормят текущие или прошлые игры 🚬 🔘Чуть больше половины избрало путь совмещения заработка в найме с пет-проектами. Помимо наличия времени и желания это может говорить как о том, что в работе чего-то не хватает, так и о том, что пока ещё не наступило выгорание и разочарование от подобного совмещения деятельности. И это удивительно и хорошо!🌟 Что ж, глядя на такие результаты, однозначно можно сказать, что надежда на развитие индустрии у разработчиков есть 🥰 Ну как не быть романтиком в геймдеве? 🧍