Hacker News Digest

Cerebras привлек $1.1 млрд в раунде G по оценке $8.1 млрд, представив платформу для быстрой генерации кода на базе модели GLM-4.6. Эта модель обрабатывает более 1,000 токенов в секунду, занимая первое место в рейтинге вызова инструментов Berkeley Function Calling и демонстрируя производительность на уровне Sonnet 4.5 в веб-разработке. Платформа позволяет использовать GLM-4.6 с любым AI-дружелюбным редактором кода через API.

Компания предлагает три тарифных плана: бесплатный с ограниченным доступом, Pro за $50 в месяц (24 млн токенов в день) и Max за $200 (120 млн токенов). Эти варианты подходят как для небольших проектов, так и для полноценной разработки с интеграцией в IDE. Cerebras позиционирует свой сервис как решение для поддержания состояния потока программиста без ожидания генерации кода.

• Cerebras Code с GLM 4.6 демонстрирует высокую скорость генерации (до 1000 ток/с), что значительно ускоряет итерации, особенно для UI-разработки и рутинных задач.
• Пользователи разделились: одни видят в скорости революцию для продуктивности ("секретное оружие"), другие скептичны, считая модель уступающей конкурентам (Claude, GPT) и сомневаясь в отсутствии квантования.
• Практическая ценность зависит от задач: скорость критична для быстрой обратной связи в веб-разработке, но менее полезна для глубокого кодирования или нишевых областей (embedded), где важнее точность.
• Поднимаются вопросы о реальной производительности модели, обоснованности цены ($50/мес) и устойчивости бизнес-модели, особенно при высоких затратах на токены.
• Аппаратная реализация (гигантский чип Cerebras) объясняет скорость, но вызывает споры о влиянии на качество вывода и отсутствие независимой верификации.

Предоставленный контент — это навигационное меню GitHub для репозитория "samrolken/nokode", без описания самого проекта. На странице отсутствует информация о функционале, целях или особенностях nokode.

В интерфейсе присутствуют стандартные элементы GitHub: поиск, разделы для Enterprise, Pricing, Open Source, Resources и Solutions. Нет ни README, ни кода, ни обсуждений — только базовая структура страницы репозитория.

Для получения информации о проекте потребуется доступ к содержимому репозитория или его документации.

• Обсуждение показало, что «генерация кода на лету» вызывает споры: кто-то считает это будущим, другие указывают на проблемы с безопасностью, стоимостью и предсказуемостью.
• Участники обсуждали, что вместо генерации кода, можно кешировать уже созданные компоненты и переиспользовать их, что может решить проблему с производительностью.
• Некоторые комментаторы подчеркнули, что даже если LLM сгенерирует код, его все равно придется тестировать и поддерживать, и это может быть небезопасно.
• Также обсуждались вопросы стоимости и устойчивости такого подхода, особенно если учесть, что модели становятся дороже.
• В целом, участники согласились, что идея интересная как эксперимент, но пока не ясно, как она может масштабироваться или стать нормой практикой безопасной.

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

LLM, такие как GPT-5, успешно решают изолированные, хорошо определенные задачи, но создание готового к использованию приложения — это не просто кодирование, а инженерия программного обеспечения. Основная сложность заключается в управлении сложностью, поддерживаемости и интеграции множества простых компонентов одновременно. Как отмечает автор, "кодирование — это просто, инженерия программного обеспечения — это сложно".

Когда автор смотрит на код, предоставляемый этими не техническими основателями, он понимает, что сделать приложение готовым к использованию часто означает сжечь весь код и начать с нуля. Это показывает, что на текущем этапе развития ИИ может генерировать фрагменты кода, но не способен создавать полные, поддерживаемые программные системы.

• LLM хорошо генерируют код, но не могут самостоятельно создавать полноценное ПО, так как не справляются с архитектурными решениями, оценкой требований, тестированием и взаимодействием с пользователями.
• Качество кода, создаваемого AI, часто низкое: содержит ошибки, дублирование, избыточную сложность, особенно при "vibe coding" без контроля.
• Создание ПО требует человеческой экспертизы для управления сложностью, обеспечения надёжности, масштабируемости, поддержки и принятия технических решений.
• Некоторые скептичны в способности AI заменить инженеров в обозримом будущем, другие считают, что прогресс может ускориться при интеграции AI с мониторингом и аналитикой.
• Роль инженера смещается от написания кода к решению проблем, проектированию систем и контролю за качеством AI-генерируемого кода.

Пользователь работает с несколькими моделями одновременно, каждая из которых выполняет атомарные коммиты. Основной стек — TypeScript и React, развернутый на Vercel.

Основная идея — использование инструмента codex (предположительно, внутренний инструмент или API) в качестве основного драйвера для разработки. Вместо того чтобы писать код вручную, пользователь использует несколько экземпляров codex (до 8 одновременно), каждый из которых работает над своей частью задачи. Каждый агент коммитит изменения самостоятельно, что позволяет поддерживать чистую историю.

Ключевые моменты:

• Контекст и координация. Несмотря на то, что агенты работают параллельно, пользователь тщательно управляет их работой, чтобы избегать конфликтов. Например, при работе над крупными изменениями он сначала запускает один агент для оценки, а затем уже основную группу.
• Инкрементальный подход. Вместо того чтобы пытаться решить все сразу, пользователь разбивает задачи на мелкие, атомарные шаги. Например, при обновлении зависимостей он не просто запускает скрипт, а сначала проверяет каждое изменение, затем тестирует, и только потом обновляет.
• Отказ от излишеств. Пользователь избегает сложных систем вроде прекоммит-хуков для валидации, так как они замедляют процесс. Вместо этого он полагается на то, что агенты достаточно умны, чтобы не допускать ошибок.
• Практичность. Инструменты выбираются по принципу "работает — не трогай". Например, codex используется вместо Claude Code, потому что последний стал слишком абстрактным (например, он может часами "думать" над простой задачей). codex же просто делает.

В целом, подход напоминает принцип "двигайся быстро и не ломай" (move fast and don't break things), но с уклоном в "двигаться быстро", даже если иногда что-то сломается. Это компенсируется скоростью: один агент может заменить целую команду, и даже если он ошибся, это быстро фиксится.

• Дискуссия разделилась на два лагеря: «AI пишет почти весь код» против «никакой AI не заменит разработчика»; при этом обе стороны сходятся в том, что важно уметь читать и ревьюить весь код, независимо от того, кто его написал.
• Участники обсуждали, что 300k строк кода, которые, как утверждается, были написаны ИИ, на самом деле могут быть просто увеличены в 10-15 раз по сравнению с тем, что написал бы человек, и что это вызывает сомнения в надёжности такого подхода.
• Поднимался вопрос о том, насколько можно доверять ИИ-написанному коду, и какие именно навыки требуются, чтобы эффективно использовать такие инструменты.
• Также обсуждалось, что важно ли вообще писать статьи о таких инструментах, если они не раскрывают, как именно они используются, и какие именно задачи они решают.

Разработчики всё чаще сталкиваются с увеличением времени на модификацию или исправление кода, сгенерированного большими языковыми моделями. Это явление, названное «долгом понимания», напоминает работу с унаследованными системами, где перед внесением изменений необходимо глубоко разобраться в логике и контексте кода. Однако масштаб проблемы стал беспрецедентным из-за лавинообразного роста объёмов нечитаемого кода, который ИИ-инструменты производят с огромной скоростью.

Команды, заботящиеся о качестве, тратят время на ревью и рефакторинг такого кода, сводя на нет первоначальную экономию времени. Другие же просто коммитят непроверенные и непонятые фрагменты, создавая риски на будущее. Хотя ИИ может помочь с 70% правок, остальные 30% приводят к «петлям безысходности», когда модели не справляются с задачей, и разработчикам приходится разбираться в чужом коде самостоятельно. Это накопление долга понимания становится бомбой замедленного действия для миллионов проектов.

• LLM-генерация кода ускоряет разработку, но часто приводит к сложному, плохо понятному коду, что создает долгосрочные проблемы с поддержкой и увеличивает "долг понимания".
• Мнения разделились: одни считают проблему поддержки LLM-кода преувеличенной или временной, другие видят в ней фундаментальный сдвиг, усугубляющий существующие проблемы с legacy-кодом.
• Предлагаются стратегии работы: строгий ревью, использование LLM только для тривиальных задач/черновиков, написание тестов и документации, либо полное принятие модели "черного ящика".
• Многие ожидают, что будущие LLM смогут сами понимать и поддерживать сгенерированный код, что изменит роль разработчика на более высокоуровневую.
• Параллель с прошлыми проблемами (офшорная разработка, копипаст с Stack Overflow), но масштаб и скорость генерации LLM создают беспрецедентные вызовы.

DeepSeek AI выпустила экспериментальную версию своей языковой модели DeepSeek-V3.2-Exp. Это обновление демонстрирует улучшенные возможности обработки естественного языка, включая более точное понимание контекста и генерацию кода. Модель оптимизирована для разработчиков и исследователей, предлагая расширенную поддержку программирования и анализа данных.

Ключевые улучшения включают увеличенный контекст обработки, что позволяет эффективнее работать с длинными документами и сложными запросами. Модель также показывает прогресс в мультимодальных задачах, хотя акцент остаётся на текстовых и кодогенерирующих возможностях. Экспериментальный статус означает, что разработчики могут тестировать новые функции до их финального релиза.

• Обсуждается значительное снижение стоимости моделей ИИ, особенно у DeepSeek, с акцентом на важность доступности для широкого распространения технологий.
• Поднимаются вопросы о технических особенностях моделей (sparse attention, кэширование) и их влиянии на производительность и стоимость вычислений при больших контекстных окнах.
• Участники спорят о реальной выгоде "дешевых" моделей в рабочих процессах, учитывая необходимость поддержки кэширования провайдером для снижения затрат.
• Высказываются предположения о дальнейшей динамике цен на ИИ, ссылаясь на возможное продолжение стремительного падения стоимости по аналогии с законом Мура.
• Обсуждается открытость и прозрачность платформ (OpenRouter, DeepSeek), включая вопросы о использовании данных для обучения и статусе исходного кода.

Метод FCA (Function Calling Abstraction) предлагает новый подход к инженерии контекста для ИИ-агентов, работающих с кодом. Вместо передачи полного кода функции в контекст, он использует абстрактные описания её поведения, что значительно сокращает объём передаваемых данных. Это позволяет агентам точнее понимать предназначение функций без перегрузки контекста избыточной информацией.

Ключевое преимущество — повышение эффективности обработки запросов и снижение затрат на вычисления, так как модель фокусируется на семантике, а не на синтаксисе. Метод особенно полезен в больших проектах, где количество функций может быть огромным. Практический результат — ускорение разработки и улучшение качества генерируемого кода за счёт более релевантного контекста.

• Участники обсуждают эффективность подхода "исследование -> план -> реализация" для работы с ИИ в больших кодовых базах, отмечая рост производительности, но и сложности управления контекстом.
• Поднимаются вопросы о надежности ИИ: необходимость почти идеальной точности генерации кода, проблемы с галлюцинациями и сложность верификации поведения без чтения каждой строки.
• Критикуется масштабируемость подхода: управление контекстом становится сложным при больших объемах, а стоимость использования мощных моделей (например, Opus) может быть высокой.
• Отмечается сдвиг роли инженера: от написания кода к определению спецификаций и верификации поведения, что требует новых навыков и вызывает сопротивление у некоторых разработчиков.
• Обсуждаются технические детали и инструменты: важность компрессии контекста, использования AST для анализа кода, необходимость ведения логов промптов и стилистического единообразия кода.

Сейчас кодирующие агенты вроде Claude Code работают медленно и ненадёжно, напоминая dialup-модемы 90-х: частые сбои, необходимость перезапусков, скорость генерации всего 30-60 токенов в секунду. Это связано с взрывным ростом потребления токенов — по данным OpenRouter, объёмы выросли в 50 раз за короткий период, а агентные workflows требуют в 1000 раз больше ресурсов, чем обычные чаты.

Более высокая скорость, например 2000 токенов в секунду (как у Cerebras Code), кардинально меняет опыт: разработчик становится узким местом, а не модель. Это открывает путь к новому этапу — параллельным независящим агентам, которые предлагают несколько вариантов решения задачи с автоматической оценкой качества. Однако рост скорости лишь разгоняет спрос, создавая бесконечный цикл: чем лучше модели, тем сложнее задачи, которые мы им ставим.

• Скептицизм относительно реального повышения продуктивности из-за LLM: AI может создавать иллюзию продуктивности, снижая когнитивную вовлеченность и порождая проблемы с качеством и сопровождением кода.
• Ключевая проблема — скорость и контекст: Медленная генерация токенов и постоянное переключение контекста нарушают состояние потока (flow), а ограничения контекста приводят к ошибкам и галлюцинациям.
• Сдвиг роли разработчика: Инструмент меняет фокус с написания кода на проверку, редактирование и управление AI-агентами, что требует постоянной бдительности и новых навыков.
• Зависимость от надежности провайдеров: Сбои в работе AI-сервисов сравнимы с остановкой производства, что создает риски для рабочего процесса.
• Разные стратегии и предпочтения в использовании: Одни разработчики ценят интегрированные в IDE решения (Cursor), другие предпочитают сторонних агентов (Claude, Codex) или используют LLM как «калькулятор» для рутинных задач и обучения.

Стремительный рост использования ИИ-генерации кода привёл к появлению новой рыночной ниши — услуг по исправлению ошибок, допущенных алгоритмами. Хотя 92% разработчиков уже применяют инструменты вроде Copilot, анализ 150 млн строк кода показал, что ИИ-сгенерированный код на 41% чаще подвергается правкам или откатам в течение двух недель. Исследователи из Стэнфорда обнаружили, что такой код содержит больше уязвимостей, при этом разработчики ошибочно считают его более безопасным.

Спрос на «чистку» ИИ-наследия растёт: инженеры вроде Хамида Сиддики управляют десятками проектов одновременно, беря $200–400 в час за исправление «спагетти-кода». Специализированные платформы вроде VibeCodeFixers.com уже объединяют сотни исполнителей и заказчиков. По данным ThoughtWorks, 60% проектов с ИИ требуют серьёзного рефакторинга перед выходом в продакшен. Это создаёт новые карьерные траектории: младшие разработчики, освоившие исправление ИИ-кода, могут быстро достигать уровня зарплат сеньоров.

• Рост числа проектов с низкокачественным кодом, сгенерированным ИИ (vibe coding), требующих дорогостоящей последующей доработки и "очистки".
• Сравнение ситуации с аутсорсингом: проблемы те же (плохие спецификации, низкое качество), но ИИ ускоряет генерацию кода и ошибок.
• Споры об общей эффективности: экономия времени на MVP vs. скрытые затраты на поддержку и риски безопасности.
• Сдвиг навыков: востребованы не генераторы, а "инженеры-уборщики", способные чинить и рефакторить AI-сlop.
• Прогнозы: AI-код станет новым легаси, а успех зависит от качества спецификаций и дисциплины, а не скорости генерации.

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

Ключевой навык — не просто исправлять отдельные строки, а оценивать архитектурные решения: что можно упростить, переиспользовать или вовсе избежать. Без этого код становится сложным, а проект — неуправляемым. Эффективная работа с ИИ требует структурного мышления, как при лучшем код-ревью: видеть не только написанное, но и упущенные возможности для изящества и простоты.

• Сомнения в эффективности использования ИИ для генерации кода из-за высокого процента ошибок и необходимости тщательного ревью, которое может быть более трудоемким, чем написание кода с нуля.
• Озабоченность качеством и надежностью ИИ-сгенерированного кода, особенно в зрелых проектах и open source, где отсутствие публичного ревью может подорвать доверие.
• Увеличение нагрузки на разработчиков из-за необходимости ревью большего объема кода, который часто требует повышенного внимания из-за непредсказуемости ИИ.
• Потеря преимуществ человеческого взаимодействия в процессе ревью, поскольку ИИ не может участвовать в обсуждении или доработке кода.
• Необходимость разработки новых процессов и инструментов для эффективного ревью ИИ-сгенерированного кода, включая возможность комментирования и взаимодействия с агентами.

AI-кодинг: компилятор, а не магия

LLM — это компилятор: английский вместо C, выхлоп — код.
Работает лишь для тривиальных задач; чуть сложнее — приходится писать спецификации длиннее самого кода.
Английский не имеет спецификации, выхлоп недетерминирован, изменение в одном месте ломает всё.
Казаться быстрее на 20 %, реально медленнее на 19 % (arxiv.org/abs/2507.09089).

«ИИ заменит программистов» так же, как компиляторы заменили ассемблер и Excel — бухгалтеров: инструмент, а не чудо.
Миллиардные инвестиции в «vibe coding» — повторение провала self-driving.
Вместо хайпа стоит делать лучшие языки, компиляторы и библиотеки.

• Опытные разработчики спорят: кто-то экономит часы на рутине, кто-то теряет скорость из-за «зайцев» и недопонимания кода.
• AI-инструменты (автодополнение, Claude Code, Cursor) дают +20–50 % к старту, но требуют навыка «prompt-инженерии» и постоянного контроля.
• «Вайб-кодинг» без понимания архитектуры быстро даёт MVP, но приводит к техдолгу и невозможности поддержки.
• Независимые исследования пока не подтверждают значительного ускорения для сеньоров в сложных кодовых базах; выгода заметнее в шаблонных CRUD-задачах.
• Рынок и инвесторы толкают AI-хайп из-за страха пропустить «новое интернет», а не из-диоказанной эффективности.

Краткий перевод и сжатие

Инженер Sanity Винсент Куигли за 6 недель перешёл от ручного кода к 80 % генерации ИИ.
Ключевые идеи:

• 4 этапа: «пишу сам» → «ИИ как Stack Overflow» → «ИИ пишет, я ревью» → «я ставлю задачи, ИИ решает».
• 3 попытки:
  1. 95 % мусора, но быстрое черновое решение.
  2. 50 % мусора, структура ясна.
  3. Рабочий код после уточнений.
• Контекст: claude.md в корне проекта хранит архитектуру, стандарты, примеры.
• Команда агентов: один пишет код, другой тесты, третий документацию; ежедневно «забывают» контекст.
• Ревью: ИИ → я → команда; человек смотрит только критические места.
• Фоновые агенты: ночью чинят мелкие баги, утром присылают PR.
• Цена: 400 $/мес на токены, но экономит 30 % времени инженера (≈ 6 000 $).
• Риски: регрессии, безопасность, зависимость от ИИ.
• Эмоции: ушла «владение кодом», пришло «владение проблемой».
• Советы тимлиду: начинать с экспериментов, выделять «зоны ИИ», усиливать ревью.
• Советы разработчику: заведи claude.md, ставь ИИ задачи помельче, проверяй критикуй, не верь на слово.

• Участники сходятся: LLM хороши для отладки и брейншторма, но не способны самостоятельно писать сложный продакшен-код без доработки.
• Все обсуждают Claude Code: кто-то активно использует и хвалит, кто-то жалуется на переусложнённый код и высокие расходы (до $1500/мес).
• Повторяется один и тот же набор советов: дробить задачи, писать тесты, держать короткие циклы обратной связи, использовать линтеры и логирование.
• Некоторые инженеры предпочитают сначала строить архитектуру сами, а LLM оставляют для рутины; другие наоборот.
• Общий вывод: AI-ассистенты становятся стандартным инструментом, но пока не заменяют разработчиков и требуют постоянного контроля.

Код — это долг

«Что ты думаешь об ИИ-инструментах для программирования?»
Отвечаю примером двух компаний.

Они одинаковы по доходу и продукту, но первая живёт с 1 млн строк кода, вторая — с 100 тыс. Какая выгоднее?
Очевидно, та, что меньше. Меньше кода — быстрее понимать и менять. Код — это долг. ИИ, генерируя код, даёт тебе этот долг.

Брать ли его? Зависит. Долг бывает полезным или разрушительным, с процентами или без. Главное — иметь доступ к инструментам и использовать их ответственно.

Спасибо Ани Талахадзе за рецензию.

• Участники спорят, можно ли считать количество строк кода (LOC) мерой технического долга: одни считают LOC бесполезной метрикой без учёта качества, другие — формой риска и обязательств.
• Подчёркивается, что «меньше кода» ≠ «лучше», если он нечитаем, плохо документирован и не поддерживается; главное — скорость понимания и изменения.
• AI-генерация кода ускоряет объём, но усиливает долг: код быстро появляется, но никто не понимает, кто за него отвечает, и как его отлаживать.
• Код описывается как актив, который амортизируется: чем больше кода, тем выше ежегодные «выплаты» на его поддержку и рефакторинг.
• Третьи сервисы и зависимости тоже создают долг: при смене условий или закрытии поставщика страдает бизнес.

Краткие мысли о LLM и разработке ПО
Мартин Фаулер, 28 авг 2025

Собираясь в отпуск, хочу поделиться набросками о текущем состоянии LLM.

1. Опросы о влиянии ИИ на разработку
   Большинство используют LLM как «умный автокомплит» (Co-pilot), но те, кто получает реальную пользу, заставляют модель напрямую читать и редактировать файлы. Игнорируя различия в подходах, исследования дают искажённые данные.

2. Будущее программирования
   Никто не знает, что будет дальше: исчезнут ли джуны, вытеснят ли сеньоров. Единственный совет — экспериментируйте сами и делитесь деталями рабочих процессов.

3. Пузырь ИИ
   Это пузырь, как и при любой технологической революции. Он лопнет, но неизвестно когда и какие компании выживут (после dot-com упали Pets.com и Webvan, но не Amazon).

4. Галлюцинации как фича
   Rebecca Parsons утверждает: галлюцинации — не баг, а главная особенность LLM. Поэтому:

   • Задавайте один и тот же вопрос несколько раз с разной формулировкой.
   • Сравнивайте ответы, включая числовые — минимум три раза.
   • Не просите LLM считать то, что можно вычислить детерминированно; лучше попросите сгенерировать код для расчёта и всё равно проверьте его.

Жду встречи с коллегами на GOTO Copenhagen — не выступаю уже пару лет, но скучаю по общению.

• Участники обсуждают тезис Фаулера: «hallucinations — это не баг, а фича LLM», споря, сводится ли это к игре слов или к глубокому инсайту.
• Большинство соглашается, что выводы LLM — это всегда «галлюцинации», просто часть из них случайно оказывается полезной.
• Практики делятся опытом: повторять один и тот же запрос несколько раз и сравнивать ответы быстрее, чем «лечить» первый неверный.
• Код, сгенерированный ИИ, часто «на 90 % готов», но оставшиеся 10 % требуют столько же времени, сколько экономится на черновике.
• Старшие инженеры пока нужны, чтобы «договариваться» с моделью и чинить ошибки, но опасения, что младших специалистов станет меньше, растут.
• Общий вывод: LLM — это мощный ускоритель и «пьяный сеньор-коллега», но не полноценная замена человеку; профессия меняется, а не исчезает.

Как заменить код функции «на лету»

Python позволяет переписывать тело функции во время работы программы:

1. Берём исходник новой функции как строку.

   new_src = "def f(x): return x * 2"
   

2. Компилируем:

   code = compile(new_src, "<magic>", "exec")
   

3. Выполняем в нужном пространстве имён:

   ns = {}
   exec(code, {}, ns)
   

4. Подменяем старую функцию:

   f = ns["f"]
   

f(21) теперь возвращает 42.

Зачем это нужно

Такой трюк позволяет LLM-агентам генерировать и сразу запускать код с доступом к текущему контексту. Это удобно для ToolBot, но открывает огромную дыру в безопасности: любой сгенерированный код получает доступ ко всем переменным процесса.

• @breuleux показал jurigged — библиотеку для горячей перезагрузки только изменённых функций без перезапуска модулей.
• Участники сравнили приём с monkey-patching, Lisp-овой «код как данные» и REPL, отметив плюсы и отладочные грабли (стек-трейсы вида <magic>).
• Обсуждали, где ещё работает такое: JVM/CLR, Erlang, динамические библиотеки в C/C++ и игровые движки.
• Кто-то считает это мощным, кто-то — анти-паттерном; всплыли ссылки на autoreload, forge и swanky-python.
• Наконец, всех достала навязчивая привязка любой темы к AI-хайпу.

GLM-4.5: агентные, рассуждающие и кодовые (ARC) базовые модели
Авторы: 5 Team (100+ специалистов)
DOI: 10.48550/arXiv.2508.06471
Лицензия: CC-BY-4.0

Команда представляет GLM-4.5 — семейство базовых моделей, оптимизированных для агентного поведения, логического вывода и генерации кода.

• Пользователи высоко оценили GLM-4.5: «первый открытый весовой модель без оговорок» и «лучшая свободно доступная для разработки».
• Особенно похвалены пост-тренинг и эффективность параметров: считаются инновационными и экономными.
• В кодинге GLM-4.5 близок к Sonnet 4, но уступает при больших контекстах; многие используют его как резерв.
• Некоторые заметили неточности в графиках бенчмарков и отсутствие Qwen3 в одном из сравнений.
• Обсуждается перспектива локального запуска «Sonnet-4-уровня» на рабочей станции за ~2000 $ уже через пару лет.

efrit — агент для написания кода на чистом Elisp, работающий прямо в Emacs.
Он читает/пишет буферы, запускает команды, ищет документацию, тестирует и рефакторит код, используя только встроенные средства Emacs и внешние процессы.

Возможности

• Понимает структуру проекта (файлы, зависимости, тесты).
• Пишет новые функции, классы, тесты, документацию.
• Исправляет баги и предлагает улучшения.
• Работает в фоне и может действовать по хукам (сохранение, коммит).

Установка

(use-package efrit
  :straight (:host github :repo "steveyegge/efrit"))

Запуск: M-x efrit-mode в нужном буфере или (efrit-global-mode 1) для всей сессии.

Команды

• efrit-suggest-improvements — предложения по коду.
• efrit-write-tests — сгенерировать тесты.
• efrit-explain-region — объяснить выделенный фрагмент.

Конфигурация

(setq efrit-model "gpt-4o-mini"
      efrit-max-tokens 4000
      efrit-auto-save t)

Статус
Альфа-версия; API может меняться. Пул-реквесты и issue приветствуются.

• Пользователи обсуждают новый Emacs-пакет Efrit (от Steve Yegge) для AI-ассистента внутри редактора.
• Уточняют, что «efrit» — это игра слов: «e» (emacs) + «ifrit» (разновидность джинна).
• Сравнивают с gptel: Efrit пока заточен под Anthropic, в то время как gptel поддерживает множество бэкендов.
• Кто-то уже запустил Efrit c Gemini через прокси, другие жалуются на ошибки и отсутствие документации.
• Параллельно идёт спор о «современном» способе конфигурировать Emacs: bedrock, doom, ручной минимализм vs «сделать из Emacs VS Code».

Byte Buddy — библиотека для генерации Java-классов во время выполнения без компилятора. В отличие от встроенных средств, она позволяет создавать произвольные классы, а не только прокси по интерфейсам.

---

Поддержка

• Коммерческая: обучение, консультации, разработка — пишите rafael.wth@gmail.com.
• Общие вопросы: задавайте на Stack Overflow с тегом byte-buddy; для неформатных тем — рассылка.
• Баги и фичи: issue tracker; пришлите пример кода и версию Java.
• Разработка: делайте pull-request; крупные фичи обсудите заранее в рассылке.

Проект ведёт Rafael Winterhalter с 2014 г.

• В обсуждении сравнивают новый стандартный API для генерации байт-кода в JDK 24 (JEP 484) и старое решение ByteBuddy.
• Упоминают JavaPoet (теперь форк от Palantir) как удобный инструмент для генерации кода на уровне исходников.
• Micronaut показан примером фреймворка, избегающего runtime-генерации, делая всё во время компиляции.
• Поднимаются вечные споры «Java vs Kotlin»: кто-то считает Java «C для JVM», кто-то предпочитает Kotlin, а LLM якобы лучше понимают Java.