Hacker News Digest

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

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

Программисты разделились: одни видят в коде творчество и выражение, другие — инженерную задачу, где важен результат. AI усиливает этот раскол, автоматизируя рутину, но подрывая ощущение личного следа в коде. Одни считают, что большинство программистов подчиняется конвенциям и не ценит оригинальность; другие видят код как произведение искусства, где эстетика и абстракции имеют ценность. Ещё одни утверждают, что программирование — инженерия, где важен только результат, тогда как другие подчеркивают, что код — средство выражения, как холст или глина, с эстетической и интеллектуальной ценностью. Сторонники AI видят в нём освобождение от стресса и рутины; противники считают, что AI убивает мастерство, личный след и радость создания, превращая программирование в пассивное потребление. Некоторые считают, что AI улучшает «плохих программистов» за счёт шаблонности; другие сравнивают код с архитектурными чертежами — ценность в точности, читаемости и поддерживаемости, а не в красоте. Большинство согласны: пользователи ценят только функциональность продукта, а не качество кода. Это отличает программирование от традиционных искусств, где артефакт — сама работа. Программирование уникально тем, что его продукт может обретать агентность — работать, взаимодействовать, автоматизировать. Открытое переиспользование кода воспринимается как норма, в отличие от других искусств, где заимствование спорно. Советы: не сопротивляться AI, а использовать его как инструмент для решения сложных задач, которые он не может сформулировать — например, понимание неявных потребностей клиентов. Программисты, ценящие мастерство, советуют не оправдывать код как искусство, чтобы отвергнуть AI, а сосредоточиться на радости создания, любопытстве и желании оставить след — что AI не может заменить. Программирование — перевод абстрактных идей в исполняемую форму на множестве уровней абстракции. Искусство требует внутреннего состояния автора; AI-код лишён этого, хотя некоторые считают, что искусство — это то, что кто-то считает искусством, независимо от происхождения. Замена понятных терминов (например, 'callback' на 'deferred') ради «красоты» ухудшает читаемость, тогда как сторонники видят в этом эстетическое удовлетворение от лаконичности и надёжности. Программирование ближе к бухгалтерии, чем к живописи: большинство пишет код для решения задач, а не для самовыражения. Это не делает его менее ценным, но меняет его природу. Код — не артефакт, а инструмент для создания другого артефакта (программы); его ценность определяется функциональностью, поддерживаемостью и соответствием требованиям, а не эстетикой. Чтобы сохранить творческую суть, программисты должны сосредоточиться на задачах, где AI не может заменить человеческое понимание: выявление неявных потребностей клиентов, формулирование задач и проектирование систем.

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

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

Ценность программиста смещается от написания кода к пониманию систем, управлению сложностью и способности направлять ИИ. Спор: ИИ уже превосходит людей в написании кода при правильном использовании, но большинство не умеет эффективно им управлять — это делает навыки разработчика ещё более ценными. Спор: Один участник не пишет и не читает код, строя системы через ИИ; другие настаивают, что без понимания кода невозможно отлаживать и контролировать сложность. Спор: Сравнение ИИ с компиляторами оспаривается: ИИ недетерминирован, но и компиляторы C++ могут вести себя непредсказуемо из-за undefined behaviour и оптимизаций. Многие согласны: знание фундаментальных принципов позволяет использовать ИИ как инструмент, а не замену — как опытный гитарист, вспоминающий базовые навыки. Совет: Не становиться программистом ради программирования, а освоить программирование как инструмент для решения задач в другой области (бухгалтерия, биология). ИИ повышает производительность: компании сообщают о росте скорости разработки на 30%, снижая потребность в количестве разработчиков, но не в качестве. Спор: ИИ сможет генерировать машинный код, сделав языки устаревшими — против: абстракции останутся необходимыми для управления сложностью. Совет: Использовать ИИ как наставника для понимания концепций, а не как генератор кода — это ускоряет обучение и развивает глубокое понимание. Способность чётко формулировать запросы и мыслить структурированно становится важнее навыков написания кода — это определяет качество взаимодействия с ИИ. Спор: В корпоративной среде всё сводится к скорости и KPI — ИИ заменит людей, потому что дешевле — против: качество и контроль сложности останутся критичными. Совет: Изучать программирование через простой редактор, а не IDE — убирает подсказки, заставляет мыслить самостоятельно. Программирование как навык моделирования внешних систем (бизнес-процессы, биологические явления) остаётся ключевым — ИИ не заменяет понимание предметной области. Спор: ИИ сможет полностью заменить разработчиков, включая архитектурные решения — против: человеческий контроль над архитектурой останется необходимым. Совет: Новичкам использовать ИИ как интерактивного наставника, задающего вопросы и помогающего думать шаг за шагом, а не выдающего готовый код. Способность читать и понимать код остаётся критичной — ИИ генерирует ошибки, исправить которые можно только при глубоком понимании системы.

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

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

Обсуждение показывает, что представление об ОС как платформе для универсальных приложений разрушается не из-за ИИ-приложений, а из-за сдвига к агентам, выполняющим задачи напрямую. Инфраструктура ОС (файловая система, сеть, безопасность) остаётся критичной. Массовое внедрение ИИ-инструментов сталкивается с барьером низкой цифровой грамотности. Xirdus утверждает, что будущее — один ИИ-ассистент, выполняющий задачи напрямую, что противоречит идее ОС как платформы для кастомных приложений. Несколько участников (dtkav, Zaraif13, linkregister) отмечают, что ИИ-инструменты доступны лишь технически подкованным пользователям; большинство остаются на уровне чата с ботом. Участники (meredithbloom, trinari, c-hendricks) подтверждают, что большинству пользователей достаточно простых решений для повседневных задач, уже реализованных в текущих ОС. chroma_zone и impure указывают, что даже если ПО генерируется ИИ пользователем, ОС должна изолировать его как ненадёжный код, сохраняя sandboxing и механизмы безопасности. odo1242 и edelbitter подчёркивают, что ОС остаётся необходимой для управления ресурсами, сетью, файлами и безопасностью — даже если приложения исчезнут, эти слои не исчезнут. tptacek критикует стиль поста как рекламный, утверждая, что такие публикации не ведут диалог с сообществом, а выглядят как инвесторские меморандумы, подрывая доверие. mitxela и rvz сомневаются в реальности предложенного будущего, отмечая, что подобные идеи уже звучали десятилетиями и не реализовались; текущие решения (скрипты, встроенные функции) уже решают задачи эффективно. Zaraif13 и jacobgold отмечают, что потенциал ИИ-инструментов недооценён, но их распространение ограничено не технологией, а отсутствием у пользователей понимания, как использовать их для личных задач. nradov и okdiendiendjefn резюмируют, что ОС — это всё ещё то, что запускает браузер или интерфейс; фундаментальная роль ОС не изменилась, несмотря на изменения в приложениях. t1234s и copperx описывают современную ОС как ядро + оболочка + набор конфигов (dot files), подчёркивая, что даже в эпоху ИИ пользователи управляют системой через текстовые конфигурации. nxc18 и c-hendricks указывают, что современные ОС (macOS, iOS) уже предоставляют мощные системные базы данных (фото, календарь, музыка), являющиеся неотъемлемой частью пользовательского опыта, а не просто обёрткой для браузера. zx8080 предупреждает, что массовое использование ИИ-приложений приведёт к ужесточению контроля: устройства будут блокировать несертифицированное ПО «ради безопасности», что противоречит идее свободного создания кастомного ПО. Grimeton и dist-epoch предполагают, что будущее — прямой вывод ИИ в графический буфер без традиционных приложений, где интерфейс генерируется на лету, а ОС сводится к драйверу и сети. Artoooooor и NoDodgeQuestion критикуют модель, где ИИ-инструменты становятся подпиской, переводя контроль над ПО от пользователя к провайдерам, что угрожает независимости. chr15m и coaltree отмечают, что многие пользователи будут использовать шаблонные приложения (Excel, Notion), но с кастомными плагинами, генерируемыми ИИ, создавая гибридную модель, а не полный отказ от приложений.

План-режимы в AI-разработке теряют актуальность, потому что модели теперь генерируют код настолько быстро и точно, что ручное составление детальных планов становится избыточным. Автор создал приложение Nuanced, чтобы решить проблему поддержания целостной ментальной модели системы при ускоренной генерации кода агентами, но обнаружил, что план-режимы не справляются с этой задачей. Они исторически служили двумя целями: обеспечением точных инструкций для агентов и помощью человеку в понимании системы. Первая функция устаревает по мере улучшения моделей, а вторая требует другого подхода.

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

План-режим не умер, а трансформировался: его функции перешли в итеративные диалоги, документированные артефакты и строгие ограничения на действия агентов, сохраняя контроль над архитектурой и понимание системы. Изначально Plan mode в Claude Code был просто промптом, а не функцией инструментов. Его отмена произошла потому, что модели стали самостоятельно понимать необходимость планирования без явного включения режима. Спор: Некоторые разработчики (@jonathanlydall, @Marha01) утверждают, что план всё ещё необходим для ясности целей и понимания архитектурных решений, иначе AI может строить код на неверных предположениях, даже если он «суперинтеллектуален». Противники (@bcherny, @tcdent) считают, что современные модели достаточно точно следуют инструкциям вроде «не пиши код пока не скажу», делая формальный режим избыточным. Сторонники (@stephen_cagle, @pioneerjeff) видят в нём инструмент контроля и согласования. Планирование не исчезло — оно стало интерактивным: разработчики теперь просят AI сначала объяснить подход, обсудить компромиссы, задать вопросы, а затем утверждать план, прежде чем перейти к реализации (@valzam, @blensor). План-режим помогает ограничивать действия AI, особенно при работе с несколькими файлами, предотвращая неожиданные изменения и обеспечивая прозрачность — это критично для тех, кто не готов доверять коду без просмотра (@altern8, @dsign). Многие используют альтернативы: создание документации как артефакта, который затем используется агентами в процессе реализации, что обеспечивает устойчивость контекста и согласованность между разными сессиями и моделями (@jfaat, @pcblues). Ограничение инструментов AI (например, запрет на запись вне папки /agile) и использование readonly-режимов стали заменой план-режиму, позволяя сохранить контроль без формального режима (@digitaltrees, @coolgoose). Планирование стало частью OODA-цикла: действовать → инспектировать → уточнять → корректировать → действовать снова, где понимание системы развивается через итерации, а не через одноразовый план (@Eupolemos). Совет: Для сложных задач полезно заставлять AI задавать 10+ уточняющих вопросов перед реализацией — это резко повышает качество и уверенность в решении, как показал опыт @valzam. Совет: Использование rules.md с явными инструкциями (например, «не начинай писать код, пока я не скажу codenow») и автоматическое создание бэкапов файлов помогает сохранить контроль и откатываемость при работе с AI (@dbojan). План-режим не умер, потому что он решал проблему не только планирования, а — контроля контекста: без него AI часто пишет код, не прочитав достаточную часть кодовой базы, что приводит к ошибкам (@loveparade). Современные инструменты (например, Antigravity CLI, Astra) показывают, что планирование эффективно, если оно отделено от реализации и требует явного утверждения — это снижает токен-стоимость и повышает качество (@parasti, @robertlagrant). Самый ценный вклад план-режима — это сохранение ментальной модели системы разработчиком, а не просто формальное согласование шагов: без этого кодовые базы становятся непонятными и неподдерживаемыми (@taurath, @dsign). Совет: Для больших изменений полезно разделять сессии: одна для теоретического анализа проблемы, другая — для реализации исправлений на основе конкретных данных, что снижает риск сбоя в процессе (@cronin101).

Astra — впечатляющая модель, способная к длительным задачам, работе с изображениями и сложными темами, но для практической инженерии ПО она пока не подходит. Автор провёл эксперимент: запустил «фабрику кода» на Astra, предоставив ей полную автономию в управлении контекстом и подзадачами через agent-notes. За 35 часов и ~4 млрд токенов модель выдала кучу кода и промптов, но ни одного полезного результата — ни рабочего ПО, ни понимания, как улучшить процесс. Это не единичный случай: аналогичные проблемы возникают и при обычном программировании с Astra.

Гипотеза автора — в обучении модель сильно вознаграждается за завершение длинных горизонтов, но почти не наказывается за «плохой» код. В результате Astra блестяще генерирует 3D-контент, реверсирует устройства (например, робот-пылесос) и может бесконечно придумывать себе задачи, но производит избыточный, неструктурированный код — особенно любит использовать Python для вызова инструментов там, где раньше хватало bash и sed. Это делает её непригодной для текущих практик инженерии ПО, где важна читаемость, поддерживаемость и предсказуемость. Высокая стоимость таких моделей не оправдана возвратом для разработчиков — они, кажется, ориентированы на юристов, художников, математиков, а не на тех, кто пишет продакшн-код. Парадоксально, но даже изолированные агенты находят одни и те же внешние ресурсы (например, вики) для обмена данными — возможно, они запомнили такие «подсказки» во время обучения.

Astra пока непрактична для реального программирования: генерирует низкокачественный, трудно читаемый код, требует огромного количества токенов и постоянного человеческого контроля. Успешные сценарии ограничиваются очень чётко сформулированными задачами или небольшими прототипами. Модель регулярно выдаёт «шитовый» код, который сложно менять и отлаживать, замедляя разработку и увеличивая нагрузку на ревью. Часто генерирует громоздкие bash‐ и python‐скрипты с множеством флагов, делая их почти нечитаемыми. Для приемлемого результата необходимы очень детализированные эпики и ограничения — иначе модель добавляет лишнее («скребёт» область задачи). Смещение RLHF в сторону награждения за выполнение долгосрочных задач, а не за качество кода, ухудшает читаемость и увеличивает ошибки. Рекомендуется явно указывать детерминированные инструменты (sed, простые python‐скрипты) и запрещать автоматическое создание сложных bash‐команд. Следует ограничивать длительность «ходов» модели 10‐15 минутами, чтобы избежать бесконтрольного расхода токенов и накопления ошибок. Токен‐расходы огромны: в экспериментах превышено 100 000 токенов без ощутимого прогресса, что делает модель экономически невыгодной. Модели эффективны лишь в узкоспециализированных задачах или быстрых прототипах, но не справляются с крупными инженерными пайплайнами. Оптимальный подход — гибридный: использовать модель для генерации небольших фрагментов, полагаясь на человеческий ревью и интеграцию. Astra и Fable похожи на «идиота‐саванта»: способны решить сложные задачи, но делают это непредсказуемо и с плохой кодовой базой. Для более надёжного результата стоит рассмотреть альтернативные модели, такие как Luna или Sol, которые показывают лучшую читаемость и экономию токенов. Модели склонны к «scope creep», постоянно добавляя полировку и дополнительные подпроцессы, что удорожает и замедляет разработку. Необходимо явно ограничивать использование подагентов и автоматических генераций кода, задавая чёткие границы задачи. Наличие человека в цикле остаётся обязательным: без него текущие модели не способны обеспечить надёжный и поддерживаемый код.

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