Hacker News Digest

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

Как в истории БАБЕЛ: «и вот они имели одно слово, и ничего не было им противостоящее». В результате проект продолжает расти, пока не исчезает архитектурный язык, который позволял людям рассуждать о системе вместе. Пример: один агент добавляет OAuth, другой — кэширование, третий — перестраивает базу и делает UI розовым; всё компилируется, тесты проходят, но никто не обсуждает, как эти изменения влияют на общую модель. В результате «башня» продолжает расти, пока не исчезнет общий язык, который раньше удерживал её в целости.

Эта ситуация обнажает парадокс: технологии ускоряют прогресс, но стирают опору совместного творчества. Без согласования команда теряет способность видеть системные риски, а проект остаётся уязвимым, хотя стены всё растут.

• Композиция в коде сравнивается с Tetris: без очистки строки (упрощения) система «вываливается».
• Потеря общего понимания проекта приводит к росту «башни» без обратной связи, как в истории Бабеля.
• Агентное программирование похоже на управление: разработчики теряют контроль и видимость над изменениями.
• Повышение производительности возможно, но без дисциплины и ревью код быстро теряет смысл и стабильность.

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

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

• AI‑сгенерированные PR‑ы и сообщения перегружают команду, их трудно быстро проверить и обсудить.
• Люди всё чаще полагаются на LLM, но без собственного усилия их работа становится заменяемой и менее ценной.
• Принцип «не тратить больше усилий, чем вложил другой» подчёркивает необходимость человеческого вклада в ответы и ревью.
• Качество AI‑вывода часто уступает обещаниям, поэтому без глубокого понимания темы полагаться только на нейросети недопустимо.

К сожалению, предоставленный текст не содержит статьи "FFmpeg to Google: Fund Us or Stop Sending Bugs" от The New Stack. Вместо этого это форма подписки на их рассылку. Чтобы я мог создать точный пересказ статьи (~170 слов на русском в Markdown), пожалуйста, предоставьте текст самой новости.

Как только вы поделитесь содержанием статьи, я сразу подготовлю лаконичный пересказ, выделив главную идею и ключевые факты/цифры/цитаты, строго следуя вашим инструкциям.

• Крупные корпорации (Google, Amazon и др.) ожидают, что open-source проекты будут бесплатно исправлять уязвимости, которые они же и находят, но при этом не предлагают ни ресурсов, ни финансирования.
• Сторонники FFmpeg отвечают, что если проект не может позволить себе тратить время на бесплатную разработку, то это не значит, что он обязан это делать, и что крупные компании могут просто отказаться от использования open-source, если не хотят платить.
• Обсуждение вышло за рамки конкретной ситуации и затронуло более широкий вопрос о том, как корпорации используют open-source без всякой отдачи.
• Некоторые участники обсуждения подняли вопрос о том, что если FFmpeg и подобные проекты не могут позволить себе тратить ресурсы на бесплатную разработку, то, возможно, им стоит пересмотреть свою модель лицензирования или найти другие способы монетизации.
• В целом, обсуждение подняло волну обсуждений о том, как корпорации используют open-source без всякой отдачи, и как это влияет на устойчивость проектов.

Творческий процесс представляет собой фрактальное исследование-эксплуатацию при оптимальном управлении с обратной связью. С ростом разрешения пространства параметров "объем принятия" — доля пространства, не ухудшающая артефакт — стремительно сужается. Время верификации и соотношение искажений создают "налог на точность", который растет сверхлинейно с ростом воспринимаемого качества. Раньше это называли "финальной доработкой", но это неверная аналогия, поскольку исследование (идея) и эксплуатация (исполнение) не разделены во времени, а вложены рекурсивно.

Разные творческие области имеют разную "ширину бассейна принятия" и скорость верификации: проза — широкий бассейн с проверкой в минутах, музыкальный ритм — узкий с верификацией за 20-40мс, а линия рисунка — узкий с проверкой за ~100мс. Близко к пику качества "объем принятия" сжимается стремительно, и для микроулучшений требуется больше доказательств. Как отмечает автор, "мастерство — это борьба с закрывающимися все менее заметными разрывами".

• Принцип "спланировать выбросить" (Plan to throw one away) в разработке ПО применяется не всегда буквально, частота полного отказа от черновика варьируется.
• В живописи существуют техники спасения неудачных работ, например, книга "Master Disaster" описывает способы исправления акварелей.
• В архитектуре допускается меньшая точность в деталях (люди, транспорт, ландшафт) по сравнению с точностью самого здания или конструкции.

Архив Эдсгера Дейкстры содержит более тысячи его неопубликованных рукописей, известных как "EWDs", которые он рассылал десяткам получателей на протяжении более 40 лет. Дейкстра, один из основоположников компьютерных наук (1930-2002), внёс фундаментальный вклад в алгоритмы, языки программирования, операционные системы и формальную верификацию, за что получил высшую награду ACM - премию Тьюринга. Большинство его работ остались недоступными для широкой публики, пока не были оцифрованы и представлены на этом сайте в виде PDF-документов.

Исходные материалы, включая дневники и переписку, хранятся в Техасском университете. Архив включает несколько индексов для поиска, а также растущее количество транскрибированных текстов и переводов на разные языки. Дейкстра часто возвращался к уже обсуждавшимся темам, предлагая новые взгляды или более точные формулировки, что отражено в системе перекрёстных ссылок между документами.

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

Cognition представила Windsurf Codemaps — AI-аннотированные структурные карты кода, которые помогают разработчикам понимать свои проекты перед тем, как вносить изменения. В отличие от большинства AI-инструментов, которые увеличивают разрыв между программистом и его кодом, Codemaps нацелены на углубление понимания. Как отмечает Пол Грэм: "Ваш код — это ваше понимание проблемы, которую вы исследуете. Только когда код у вас в голове, вы действительно понимаете проблему". Новая функция основана на SWE-1.5 и Claude Sonnet 4.5, предлагая два режима работы: быстрый и интеллектуальный.

Проблема понимания кода стоит остро: новым разработчикам требуется 3-9 месяцев для полного освоения проекта, а старшие специалисты тратят более 5 часов в неделю на помощь коллегам. По данным Stripe, поддержка легаси-кода — главный фактор, снижающий продуктивность. Codemaps решает эту задачу, позволяя создавать контекстные карты кода по запросу для конкретных задач. Это следующий шаг после Ask Devin и DeepWiki, делающий процесс онбординга и навигации по кодовой базе более эффективным.

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

В предоставленном тексте содержится только начало статьи "Почему я пишу код, будучи CTO" от Джона Ванга, соучредителя и технического директора компании Assembled. Статья начинается с констатации того, что многие технические директора перестали писать код несколько лет назад. Однако полного содержания статьи для создания полноценного пересказа недостаточно. Для подготовки точного и ёмкого пересказа необходимо предоставить полный текст статьи.

• Обсуждение в основном вращается вокруг того, что значит быть CTO в стартапе: нужно ли ему кодить, или его задача — стратегическое лидерство.
• Критика сосредоточена на том, что если CTO пишет код в выходные, это может быть признаком неправильного распределения ресурсов или отсутствия делегирования.
• Некоторые участники подчеркивают, что в маленьких стартапах CTO действительно может и должен кодить, но в более крупных компаниях это уже не так.
• Дискуссия также затрагивает вопрос, что такое CTO без прямых подчиненных, и как это влияет на роль и ожидания.
• Наконец, обсуждается, что такое CTO, и какие обязанности он должен нести, включая то, что в некоторых компаниях эта роль может быть просто почетным титулом без реальной власти или обязанностей.

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

Ключевое различие - разный уровень автономии для основных и второстепенных задач. Для творческой работы требуется быстрый отклик и контроль, тогда как для рутины важен конечный результат. Этот подход решает проблему иерархии статусов в командах - ИИ может выполнять "грязную работу" без создания низкостатусных ролей. Идея "главного программиста" с поддержкой команды, описанная Фредом Бруксом в 1975 году, теперь экономически реализуема благодаря ИИ, что позволяет сосредоточиться на главном, делегируя второстепенное.

• Обсуждение вращается вокруг аналогии "как хирург" и того, как она применяется к использованию ИИ-инструментов в разработке ПО: от идеи, что "хирург" — это не менеджер, а тот, кто делает реальную работу, а команда поддержки — это аналог анестезиолога и медсестер, до споров о том, кто и в какой момент считается "хирургом", и до обсуждения того, что такой подход может влиять на обучение и рост младших разработчиков.
• Участники обмениваются мнениями о том, как соотносятся такие концепции с такими же идеями Фреда Брукса о "хирургической команде", и о том, что такое влияние может оказать на разработку ПО и на обучение новых разработчиков.
• Некоторые участники поднимают вопросы о том, что такое влияние может оказать на разработку ПО и на обучение новых разработчиков, и о том, что такое влияние может оказать на разработку ПО.
• Участники также обсуждают, что такое влияние может оказать на разработку ПО и на обучение новых разработчиков, и о том, что такое влияние может оказать на разработку ПО.
• В обсуждении также поднимается вопрос о том, что такое влияние может оказать на разработку ПО и на обучение новых разработчиков, и о том, что такое влияние может оказать на разработку ПО.

Некоторые считают, что ИИ можно исправить, как обычное ПО: найти ошибку, исправить код, и система снова будет работать правильно. Но это заблуждение.

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

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

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

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

Ghostty получил обновление, которое добавило незаметные уведомления об обновлениях в macOS. Чтобы не повторить сценарий OpenAI, где демо-версия прервала презентацию, автор решил сделать уведомления незаметными. Он использовал Sparkle и встроил кастомный UI в заголовок окна. Процесс включал в себя AI-агентов, которые генерировали код, а затем он сам его дорабатывал. Итоговая стоимость токенов и время разработки оказались вполне приемлимыми.

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

Три твита, пост в блоге и пост в LinkedIn за неделю подняли один и тот же вопрос: как распознать талантливого разработчика, если он не делает себе имя в соцсетях и не пишет open-source. Истории сводятся к одному: «невидимые» инженеры, которые не выделяются ни в гитхабе, ни в LinkedIn, могут быть самыми ценными в команде, но система найма и продвижения не умеет их оценить. Пока мы не научимся измерять вклад, а не только активность в соцсетях, ситуация будет повторяться.

• Обсуждение вращается вокруг того, что талантливые разработчики часто остаются невидимыми для HR и менеджеров, потому что их навыки не поддаются простому измерению и не могут быть легко "прочитаны" в формате, который HR или менеджеры могли бы понять.
• Участники обсуждают, что вместо того, чтобы пытаться измерить то, что трудно измерить, компании должны сосредоточиться на создании условий, где эти навыки могут быть распознаны и вознаграждены.
• Обсуждение также затрагивает то, что вместо того, чтобы искать "10x разработчика", компании должны сосредоточиться на создании условий, где 1x разработчики могут процветать и быть эффективно использованы.
• Участники также обсуждают, что вместо того, чтобы искать "10x разработчика", компании должны сосредоточиться на создании условий, где 1x разработчики могут процветать и быть эффективно использованы.
• Участники также обсуждают, что вместо того, чтобы искать "10x разработчика", компании должны сосредоточиться на создании условий, где 1x разработчики могут процветать и быть эффективно использованы.

Хороший вкус в разработке — это не техническое умение, а способность выбирать набор инженерных ценностей, подходящих конкретному проекту. В отличие от навыков, которые можно развить учёбой и практикой, вкус формируется через личный опыт и предпочтения. Например, одни разработчики ценят читаемость кода с map и filter, другие — производительность for-циклов, и это различие отражает их приоритеты, а не уровень компетенции.

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

• Обсуждение определяет "хороший вкус" в разработке как способность выбирать оптимальные решения, основанные на контексте и требованиях проекта, а не на личных предпочтениях.
• Участники подчеркивают, что хороший вкус тесно связан с опытом, гибкостью, умением аргументировать выбор и предвидеть последствия решений для поддержки и масштабирования.
• Многие отмечают, что хороший вкус — это баланс между читаемостью, производительностью, простотой и соответствием бизнес-целям, а не слепое следование догмам или модным тенденциям.
• Спорным остается вопрос, является ли "вкус" субъективным эстетическим понятием или его можно формализовать через принципы инженерии (например, поддерживаемость, ясность, минимальная сложность).
• Некоторые видят корень проблемы в смешении объективно плохих решений (например, неэффективные алгоритмы) и субъективных предпочтений (стиль кода, выбор парадигм).

ИИ-кодинг переворачивает традиционный процесс разработки: вместо долгого обдумывания задачи и последующего написания кода разработчики теперь генерируют код мгновенно с помощью ИИ, а затем тратят время на его осмысление и интеграцию в сложные системы. Это создаёт парадокс — хотя скорость написания кода растёт в разы, общая продуктивность в доставке работающего ПО увеличивается лишь на ~10%, так как основное время уходит на тестирование, исправление ошибок и документацию.

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

• Использование ИИ в программировании требует тщательного планирования и проверки, аналогично традиционной разработке, иначе код становится нестабильным.
• ИИ эффективен для быстрого создания прототипов и решения рутинных задач (80% работы), но финальную доработку и интеграцию (20%) выполняет человек.
• Существует риск снижения глубины понимания кода и качества обучения новичков при чрезмерном reliance на ИИ-генерацию.
• Инструменты ИИ наиболее полезны как "сверхопытные pair-программисты" для обсуждения идей, рефакторинга и поиска решений, а не как автономные кодогенераторы.
• Текущие ИИ-агенты не заменяют junior-разработчиков, так как не способны к обучению, уточнению требований и обладают ограниченным контекстом системы.

Современные модели ИИ демонстрируют сверхчеловеческие способности в решении абстрактных задач, как показал недавний успех GPT-5 на ICPC, но автономные кодирующие агенты всё ещё не могут заменить разработчиков. Основное ограничение — не интеллект, а контекст: агентам не хватает глубокого понимания кодовой базы, её архитектурных паттернов и скрытых знаний, которые есть у людей.

Контекст включает не только код, но и документацию, историю решений, неформальные соглашения и причины прошлых изменений. Без доступа к Slack-тредам, постмортемам инцидентов и организационным практикам агенты работают лишь на 20% от возможного уровня, справляясь в основном с мелкими задачами. Чтобы двигаться дальше, нужны системы, способные усваивать и применять этот скрытый контекст так же, как это делают люди.

• Основным ограничением для кодирующих агентов на основе ИИ является не размер контекстного окна, а неспособность эффективно фокусироваться на актуальных задачах и отбрасывать нерелевантную информацию.
• Многие участники отмечают, что ИИ-агенты демонстрируют уровень понимания, сравнимый с начинающим разработчиком, и не способны заменить senior-специалистов, которые могут интерпретировать бизнес-требования и принимать ответственные решения.
• Существует скептицизм относительно бесконечного увеличения "интеллекта" моделей, так как даже с большим контекстом они допускают ошибки и галлюцинации, а фундаментальные ограничения вероятностной генерации остаются.
• Предлагаются решения для улучшения работы агентов: лучше структурированные кодобазы, иерархическая документация, инструменты для управления контекстом и памятью, а также человеческий контроль для курирования процесса.
• Подчёркивается, что ключевая проблема — не технический контекст, а понимание intent (намерения) стоящего за кодом, что требует более глубокого осмысления, чем простое прогнозирование токенов.

Код-ревью часто превращается в формальность из-за слишком больших и сложных пул-реквестов. Разработчики избегают глубокого анализа, ограничиваясь поверхностными комментариями, что ведёт к накоплению технического долга и уязвимостей. Ключевое решение — нормализовать возврат непонятных PR авторам и дробить функциональность на мелкие изменения объёмом до 300 строк, которые можно проверить за 5–10 минут.

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

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

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

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

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

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

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

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

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-хайп из-за страха пропустить «новое интернет», а не из-диоказанной эффективности.

Полная автономия AI-программистов невозможна в обозримом будущем.
Современные модели (GPT-4, Claude, GitHub Copilot) умеют генерировать фрагменты кода и даже мелкие приложения, но:

• не понимают контекст бизнес-логики и архитектуры;
• не способны к долгосрочному планированию, поэтому «забывают» требования через несколько шагов;
• не отвечают за последствия: безопасность, этика, юридические риски;
• требуют постоянного человеческого контроля при отладке, рефакторинге и интеграции.

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

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

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

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

---

Когда стоит использовать ИИ

• Короткий горизонт: автодополнение, мелкие функции — +20 % скорости.
• Длинный горизонт: архитектура, стратегия — чем дальше план, тем выше риск ошибок.
  Правило: решайте за 6 недель (Shape Up), не стройте дорожные карты на годы.

---

Бездушный текст

Генеративный текст не несёт опыта, чувств и «души». Читатели это почувствуют, а вы потеряете способность создавать новые идеи.

---

Отвлечение

Grammarly, Copilot, Cursor не дают 2 секунд подумать. Мы перестаём быть за рулём и теряем поток. Выключите подсказки, чтобы вернуть мышление.

---

Не поймите превратно

Я пользуюсь ИИ каждый день, но осознанно: выключил Copilot и Grammarly.
Совместное «LLM + человек» полезно, но человеческие инсайты, рождённые через труд и опыт, не заменить.

---

Мнения экспертов

• Paul Graham: писать вручную — единственный способ мыслить ясно.
• Nathan Baugh: ИИ помогает черновикам, но финал должен быть человеческим.
• Ted Gioia: музыка без человеческого вкуса превращается в шум.
• Mitchell Hashimoto: код, написанный ИИ, сложнее поддерживать.
• Andrew Ng: ИИ ускоряет, но не устраняет обучение.
• Harry Dry: маркетинг без эмпатии не работает.
• Jason Fried: автономные «вайб-кодеры» создают технический долг.
• David Perell: писатель должен оставаться «диктатором», а не «редактором» ИИ.
• Ezra Klein: общество рискует потерять навык глубокого чтения и письма.

---

Кого заменит ИИ?

• Писателей? Нет. Спрос на живые тексты вырастет.
• Data-инженеров? Рутину возьмёт ИИ, но архитектуру и контекст — человек.
• Генерация картинок? Быстро, но художник нужен для вкуса и деталей.

---

Как распознать ИИ-текст

• Идеальный слог без шероховатостей.
• Отсутствие личных историй и чувств.
• Повторяющиеся обороты и «водянистые» формулировки.

---

AI-slop: компании, которые теряют

• Сайты, залитые шаблонными статьями.
• Стартапы, где продукт = обёртка над GPT.
• Бренды, потерявшие уникальный голос.

---

Учиться с ИИ

• Используйте как репетитора: задавайте вопросы, проверяйте ответы.
• Не копируйте код слепо — разбирайте каждую строку.
• Создавайте flash-карты из объяснений ИИ, но добавляйте собственные примеры.

---

Будущее

• Через 5 лет «ручная» работа станет премиальной.
• Навык «писать без ИИ» будет цениться как «готовить из нуля».
• Победят те, кто использует ИИ как велосипед для ума, а не как инвалидную коляску.

---

Что почитать дальше

• «Writing Manually»
• «Shape Up» (Basecamp)
• «The Work of Art in the Age of Mechanical Reproduction» — Вальтер Беньямин
• «Deep Work» — Cal Newport

• Пользователи переходят от «Claude Code» к отдельному приложению, чтобы не терять контроль над кодом.
• Многие считают, что ИИ справляется с 70–90 % задач, но «последние 10–25 %» требуют человека, иначе страдает качество и безопасность.
• Есть опасение, что чрезмерное доверие ИИ лишит новых разработчиков опыта «низкоуровневого» программирования.
• Предлагают режимы обучения, где ИИ объясняет каждое изменение и проверяет понимание, чтобы снизить будущую зависимость.
• Дискуссия сводится к тому, что навык «писать код» эволюционирует в навык «задавать правильные вопросы и проверять ответы».

Миф о 23 минутах 15 секундах
Популярная фраза «переключение контекста отнимает 23 мин 15 с» не подтверждается исследованиями. В статье The Cost of Interrupted Work фиксируется лишь повышенный стресс, но не время восстановления; в тексте цифра 23 не встречается. Другие работы упоминают 11–16 мин или вообще не приводят значений.

Источник мифа
Автор просмотрел 23 поста: 9 ошибочно ссылаются на статьи, 9 — на интервью с Глорией Марк, где она озвучила 23 мин 15 с; ещё 2 — на Wall Street Journal, цитирующий Марк. Печатного первоисточника найти не удалось.

• Участники обсуждают, сколько времени требуется, чтобы вернуться к задаче после прерывания; часто упоминается цифра «23 минуты 15 секунд», но её происхождение вызывает сомнения.
• Некоторые чувствуют физическую боль при выходе из потока, другие замечают, что стоимость зависит от сложности задачи, характера прерывания и эмоционального фона.
• Утверждается, что научные публикации и СМИ часто искажают результаты исследований, приписывая им цифры, которых в оригинале нет.
• Предложены способы смягчения эффекта: pair-programming, заранее спланированные задачи, медитация, прогулки или полный «выходной» после неудачного дня.
• Менеджеры подчеркивают ценность доступности для помощи коллегам, но разработчики жалуются на «мелкие» прерывания, которые разрушают контекст.

Что за ад творится?

Инженеры выгорают. Компании заставляют сеньоров ревьюить «вайб-код», который не работает. Лучшие разрабы рады помогать новичкам учиться, но вместо разбора фидбека джуны просто вставляют его в следующий промпт LLM.

На недавнем тан-холле команда джунов показала фичу, которую, похоже, не понимали сами. Сеньор-менеджер похвалил их за «4 000 строк кода, написанных Claude», и все аплодировали.

Мне попросили доработать фичу. Я связался с последним автором изменений, чтобы уточнить контекст. Ответ выглядел как прямое копирование из LLM — я почувствовал себя оскорблённым.

Друг жаловался: месяц ревьюит ПР, сгенерированный ИИ, командой из пяти человек. Экономия? ChatGPT за 20 $ в месяц, а потом армия инженеров пытается вмержить сгенерированный мусор.

Мы хотим помогать, учить, строить полезные вещи. Но какой смысл вкладываться в людей, если всё сводится к копипасту в «модель, в шаге от AGI»?

Попробуйте эксперимент: отключите «ИИ» хотя бы на день. Я сбросил комп, удалил Claude Pro — поиск и чтение доков дают более точный результат.

Кому вообще приносит прибыль ИИ? Схема: стартап на ИИ → венчур → деньги OpenAI → стартап исчезает. Даже OpenAI не в плюсе: технология жрёт электричество и не масштабируется. Это просто лохотрон.

• Разочарование от общения с коллегой, который просто пересылал вывод ChatGPT.
• Опасения, что AI-«вайб-кодинг» приводит к хрупкому, непонятному и ненадёжному софту.
• Мнение, что компании хотят быстрой «ценности», а не качественной разработки, и AI лишь усиливает эту проблему.
• Опыт разных людей: кто-то отказался от AI на дни/недели и почувствовал облегчение; кто-то использует AI как «умного джуна» под присмотром старшего инженера.
• Прогноз: через 10 лет младшие разработчики, не умеющие писать код вручную, станут «сеньорами», но системы будут всё хуже понимать и поддерживать.

Вместо «умных» функций — просто работающие.

Везде впихивают ИИ, который никто не просил: браузеры, ОС, конференц-приложения ломаются, но деньги текут в «искусственный интеллект».
Gamescom добавил ИИ-расписание: люди получили сотни ненужных встреч, функцию быстро убрали.
Те же деньги могли бы починить DM, поиск, перенос встреч — базовые вещи, из-за которых все возвращаются к почте и LinkedIn.

Мотив один: быстрая прибыль. В итоге продукты гниют, а инвесторы кормят обещания «вот-вот будет AGI».
Один бюджет крупной компании хватило бы на 100 лет развития Godot, Blender, Ladybird — реальных инструментов, которые нужны сегодня.

Потерянные годы не вернуть.

• Участники жалуются, что вместо починки старых багов и улучшения базовых функций компании впихивают «AI-фичи», которые никому не нужны.
• Многие считают, что инвесторы сознательно выбирают технологии, которые трудно децентрализовать, чтобы сохранить контроль и монополию.
• Одни видят в нынешнем AI-хайпе очередную моду, как было с UML, блокчейном и облаками; другие – шанс на прорыв, оправдывающий «пузырь».
• Популярная идея: деньги лучше бы пошли на документацию, API и совместимость, а не на обучение моделей водить мышкой по браузеру.
• Подводный тезис – проблема не в AI, а в концентрации капитала и в том, что «зелёное поле» проще финансировать, чем ремонт «коричневого».

Краткий пересказ на русском

• Повод: пост CEO GitHub «Developers reinvented» и его кликбейтные репосты. Автор называет текст образцом плохого мышления и «антиучебником» научного стиля.

• Отступление о статистике СССР
  – Публиковали только проценты роста, скрывая абсолютные цифры.
  – Сравнивали с провальным 1913 г. вместо более поздних лет.
  – Для «лидерства» в производстве пшеницы измеряли «сырой вес», включая солому, грязь и «диссидентов».

• Картинка в посте
  Детские кубики парят в воздухе, игнорируя гравитацию. Вывод: автор либо технически безграмотен, либо наплевать на правду. Плюс использование «абоминации»-генератора Studio Ghibli.

• «Исследование» из твита
  – «Полевое исследование» на 22 человек.
  – Статистическая репрезентативность нулевая; дальнейший разбор оборвался на этом.

• Критика статьи Домке сводится к тому, что она искажает реальность CS-образования и использует сомнительную статистику (выборка 22 человека).
• Основная претензия: статья — маркетинг для бизнес-аудитории, а не аргумент для разработчиков.
• Участники подчеркивают, что «AI-бустеризм» ставит «правдоподобие» выше корректности и игнорирует фундаментальные знания.
• Процитируют Миядзаки: его слова про «оскорбление жизни» вырваны из контекста AI-анимации зомби.
• Сообщество видит в статье типичный пример «FOMO-капитализма»: лозунги ради инвестиций и роста акций, а не ради качества кода.