Hacker News Digest

Tencent открыла исходный код модели Hy4 preview — крупномасштабной языковой модели с 770 млрд общего и 49 млрд активных параметров, поддерживающей контекстное окно свыше 1 млн токенов. Модель позиционируется как решение для реальных задач продуктивности: программирования, офисной работы и научных исследований. Она доступна через открытый исходный код, а также интегрирована в продукты Tencent — WorkBuddy, CodeBuddy, Yuanbao и ima — с возможностью бесплатного использования в течение двух недель после запуска. Доступ через API предоставляется via Tencent Cloud TokenHub и OpenRouter по цене $0.834 за млн входных токенов, $2.501 за млн выходных и $0.042 за кэш-хит.

В внутреннем слепом тестировании с участием 163 экспертов и 203 инженерных задач Hy4 preview набрала средний балл 2.99 из 4.00, опередив GLM-5.3 (2.92) и Kimi K3 (2.94). Модель показала сильные результаты в понимании длинного контекста, планировании, отладке и валидации кода, а также в генерации интерфейсов высокого качества. В офисных сценариях она улучшила анализ сложных рабочих процессов, финансовую аналитику и кросс-документную работу. В геймдеве способна создавать играбельные прототипы из одного естественно-языкового запроса и взаимодействовать с игровыми движками. В научных исследованиях продемонстрировала улучшенные способности в ИИ-разработке, молекулярной динамике, физике конденсированного состояния и фундаментальной математике. Notably, Hy4 preview участвовала в собственном развитии: предлагала оптимизации методов обучения, данных и оценки, проводила эксперименты и внедряла улучшения в инференс — включая фьюжн операторов и коммуникационную оптимизацию — что повысило сквозную пропускную способность на 31.8%. Это подтверждает наличие раннего рекурсивного цикла самосовершенствования. Следующие модели серии Hy4 ожидаются в ближайшее время.

Обсуждение дополняет статью практическим опытом и оговорками. **Трафик и стоимость.** По наблюдению @minimaxir, Hy4 за пару дней на OpenRouter обработала больше токенов, чем GLM 5.3 за неделю. @martinald связывает это с тем, что cache read стоит 5%, тогда как у большинства конкурентов 10–20%; @martinald и @joegibbs считают это главной скрытой статьёй расходов и видят возможность для провайдеров заметно снизить цену. **Качество инференса и доступ.** По опыту @vcryan и @XCSme, провайдеры страдают от rate-limit/timeout и медленного инференса даже у самой Tencent. @bobby_coder_55 отмечает, что codebuddy недоступен из США, поэтому лучше пробовать через OpenRouter/Opencode. **Кодинг и агенты.** По опыту @jorl17 и @alexfortin, Hy3 близок к DeepSeek в агентных задачах, а бесплатная версия через Opencode Go приятно удивила в кодинге; @joshheitzman, напротив, через novita.ai не смог получить полезного результата как coding agent. **Графики в анонсе.** @fastball, @usernomdeguerre и @yipinwong критикуют их (сортировка не по рангу, подсветка всей строки) как намеренно вводящие в заблуждение; @vatsachak и @tyre, наоборот, хвалят финальное качество и направление развития. **Маркетинг и необходимость.** @cyanydeez, @joegibbs и @judge2020 подозревают, что Tencent продвигает модель через свои продукты и, возможно, оплачивает трафик; @Zigurd и @pianopatrick сомневаются, нужны ли «следующие» frontier-модели большинству задач. **«Open weights» ≠ open source.** @petcat и @andsoitis настаивают, что релизы — непрозрачные бинарные блобы без кода обучения/инференса; часть пользователей по опыту с Hy3 опасается медленной скорости. **Прочее.** @codethief и @try-working иронизируют над заявлением о рекурсивном самосовершенствовании модели, сравнивая с предсказаниями ai-2027 и с «Windows 95, участвовавшей в своей разработке». @jamienk и @nbush обсуждают риск «newspeak» при оптимизации словаря: более плотная токенизация снижает тонкость смысла, хотя @dnautics и @vatsachak считают, что многословие в верхних слоях скорее помогает рассуждению.

LLM превратил первый абзац «Властелина колец» в 5500 строк кода, который за два часа создал три интерактивные 3D-сцены с анимированными персонажами и пейзажами. Главное — он сам определил, какие объекты разместить в трёхмерном пространстве, написал логику анимации и даже добавил звуковые эффекты, хотя запрос был крайне абстрактным.

Ключевой факт: за 1 млн токенов (примерно $10) модель смогла «написать» полностью автономный движок, способный визуализировать классическую литературу. Это демонстрирует, что LLM могут стать «бесконечными разработчиками» — они не устают, не требуют зарплаты и готовы экспериментировать с тем, что человеку пришлось бы писать месяцами. Однако их слабость проявляется в невозможности быстро проверять результат: модель вынуждена делать скриншоты, а затем вручную исправлять ошибки, что приводит к «жужжанию» кода. Таким образом, текущий уровень мультимодальности остаётся ограниченным, но уже позволяет создавать эпические, кастомизированные миры «на лету».

Тред обсуждает ограничения и применение LLM для генерации 3D-сцен. Пользователи отмечают, что сгенерированные сцены требуют доработки, но видят в LLM потенциал. Споры: @kooi считает проблемой медленную обработку визуальной информации, @YmiYugy — низкое качество контента; @djhworld критикует выбор «Властелина колец» как избыточно известного источника, @hooloovoo_zoo — считает его удачным. Предложения: @baron816 — использовать LLM для оптимизации производственных процессов, @fzeindl — предупреждает о риске «одноразового» ПО, @sinaatalay — генерировать код для 3D-графики, @hkalbasi — применять игровые движки и агенты.

В 2026 году LLM стали полезны не потому, что стали умнее, а потому что научились надёжно работать в автоматизированных циклах обратной связи: они могут по запросу «сделать кнопку, которая делает X» и корректно определить, когда задача выполнена. Это даёт примерно 2x прирост производительности — достаточно, чтобы изменить работу, но не заменить программиста. Главное — LLM отлично справляются с чётко сформулированными, проверяемыми задачами, но не с оценками качества кода, архитектуры или документации.

Автор использует LLM для генерации черновиков, но тратит больше времени на их доработку, чем раньше на написание всего кода — теперь «рабочий» код — это лишь 20% задачи. Для документации он даёт чёткую инструкцию: «никогда не пишите README или комментарии — я сделаю это сам». Улучшения моделей вряд ли дадут 10x прирост, потому что фундаментальные ограничения — в способности понимать смысл, а не генерировать синтаксис — остаются. Будущее за перестройкой процессов: сандбоксы, декларативные спецификации, безопасные паттерны для «вайб-кодинга». Пока же — ручные README и тщательная доработка.

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

LLM‑генераторы могут создавать код быстро, но когда вы просите одну и ту же проверку доступа в нескольких местах, модель обычно копирует одинаковый набор условий. В примере из статьи условие состоит из четырёх проверок и встречается в пяти разных файлах: обработчике запроса, фоновой задаче, API‑эндпоинте, веб‑хуке и ещё одном месте. Вы смотрите, что тесты проходят, и сливаете код, не задумываясь о поддержке. И даже если тесты проходят, такие копии легко превращаются в «болевой» участок кода, который трудно изменить без риска сломать что‑то ещё.

Проблема в том, что каждый такой «костыль» становится сигналом для модели: она запоминает ваш стиль и в следующем запросе будет генерировать ещё одну копию того же условия. Со временем набор дублирующихся проверок превращается в устоявшуюся практику, и даже попытка рефакторинга заставит вас править пять одинаковых блоков. Как пишет автор, «Write code like a human will maintain it» — значит, не полагаться на LLM, чтобы он «помнил» плохой шаблон. Иначе вы обучаете модель ухудшать свои привычки. Это приводит к накоплению технического долга: каждый дублирующийся блок усложняет поиск ошибок и увеличивает шанс пропустить регрессию.

• Добавьте простой /review‑команду с чек‑листом проверок, чтобы агент мог планировать поиск проблем.
• LLM часто создают излишние абстракции и плохие комментарии, ухудшающие поддерживаемость кода.
• Дублирование и несогласованные изменения в разных местах кода остаются главной проблемой генеративных моделей.
• Чтобы использовать ИИ эффективно, нужно явно задавать требования к читаемости и поддерживаемости кода.

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-генерируемого кода.

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

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

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

Метод 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-ассистенты становятся стандартным инструментом, но пока не заменяют разработчиков и требуют постоянного контроля.

Краткие мысли о 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 — это мощный ускоритель и «пьяный сеньор-коллега», но не полноценная замена человеку; профессия меняется, а не исчезает.

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 $ уже через пару лет.