Hacker News Digest

В предоставленном тексте отсутствует основное содержимое репозитория GitHub "jackdoe/pico2-swd-riscv", представлено только навигационное меню сайта. Судя по названию проекта, вероятно, это реализация интерфейса отладки SWD (Serial Wire Debug) для платформы на базе RISC-V, возможно, связанная с Raspberry Pi Pico 2. Однако без доступа к файлам проекта, README или описанию невозможно дать точное резюме.

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

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

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

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

• Обсуждение началось с обсуждения шрифта Iosevka и его особенностей, включая то, что он не поддерживает лигатуры, что вызвало обсуждение о том, что такое лигатуры и как они влияют на читаемость кода.
• Участники обсуждали, что такое "язык, насыщенный символами", и какие языки программирования могут быть отнесены к этой категории, включая Perl и Haskell.
• Обсуждались проблемы с отсутствием поддержки Unicode в шрифтах, и как это влияет на работу с различными языками программирования.
• Участники обсуждали, что такое "моношириный" и "пропорциональный" шрифт, и как они влияют на читаемость кода.
• В конце обсуждение перешло к тому, что выбор шрифта для кода - это вопрос личных предпочтений, и что важно найти баланс между эстетикой и функциональностью.

Разработка ПО отстает от других инженерных дисциплин в вопросах стандартов доказательств, подобно уфологии. После слушаний в Конгрессе США о НЛО в 2023 году, где военные давали показания под присягой, не появилось никаких физических доказательств в поддержку заявлений о "нечеловеческих" технологиях. Существующие видео, подтвержденные военными, сами по себе не демонстрируют ничего сверхъестественного, а лишь показывают аномальные объекты без объяснения их природы. Официальные исследования, включая британский проект Condign, сходятся во мнении: НЛО реальны, но мы не знаем, что это такое.

Уфологи, как и разработчики ПО, часто ищут документальные подтверждения своих теорий вместо физических доказательств. Stanton Friedman, ядро уфологии, утверждал, что "доказательства overwhelming", но присланные им документы лишь подтверждают, что кто-то что-то записал. В отличие от науки, где требуются проверяемые данные, обе области страдают от избытка свидетельств при дефиците фактов, что позволяет сохранять теории без реальной проверки.

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

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

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

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

• Ценность разработчика заключается в понимании предметной области, архитектуры и умении принимать решения, а не в самом коде как артефакте решения.
• Разработка ПО разделяется на творческие задачи (требующие опыта и глубокого понимания) и рутинные (которые хорошо автоматизируются, включая boilerplate).
• LLMs полезны для генерации кода, но могут создавать ошибки и не всегда соответствовать глубинному замыслу, требуя тщательной проверки.
• Автоматизация через LLMs вызывает опасения, что разработчики могут потерять понимание "существенной сложности" (бизнес-логика) в ущерб "случайной сложности" (технические детали).
• Альтернативные подходы, такие как визуальное программирование (drag-and-drop) и метапрограммирование, рассматриваются как потенциальные решения для повышения абстракции.

Статья исследует, могут ли ИИ-системы действительно мыслить или лишь симулируют понимание. Хотя CEO компаний вроде Dario Amodei прогнозируют появление ИИ, умнее лауреатов Нобелевской премии, к 2027 году, а Sam Altman видит "цифровой сверхразум" трансформирующим 2030-е, текущие потребительские ИИ-инструменты остаются примитивными. Автор, Джеймс Сомерс, изначально считал ИИ лишь перестановкой слов, но изменил мнение после использования его в программировании. Он обнаружил, что ИИ способен анализировать тысячи строк кода, находить тонкие ошибки и организовывать сложные функции.

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

• Обсуждение в основном вращается вокруг вопроса, действительно ли LLM "мыслит", но участники сходятся в том, что большинство аргументов сводится к тому, что мы не имеем четкого определения "мышления", "сознания" и "интеллекта", что делает дискуссию бесконечной.

• Участники подчеркивают, что важнее практический результат: если LLM помогает решать задачи, то его "мышление" или нет становится второстепенным. Это отражает более широкий тренд в технологической индустрии, где практическая полезность часто превалирует над философскими определениями.

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

• Другие участники указывают, что мы не можем точно определить, что такое "мышление", и что это делает дискуссию бесплодной. Они также подчеркивают, что мы не знаем, как работает мозг человека, что делает сравнение LLM и человеческого мышления еще более сложным.

• Наконец, обсуждение также затрагивает вопрос о том, что если LLM не "мыслит", то что именно отличает их от человеческого мышления, и что именно мы должны искать в будущем, чтобы развивать более продвинутые системы, которые могут мыслить.

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

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

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

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

Advent of Code 2025 — это календарь программистических головоломок на каждый день декабря, доступных для решения на любом языке программирования. Созданный Эриком Вастлом, этот проект подходит для любого уровня подготовки — от новичков до опытных разработчиков. Участники используют его для подготовки к собеседованиям, обучения в компаниях, университетских курсов или просто для практики. Не требуется глубоких знаний компьютерных наук — достаточно базовых навыков программирования и решения задач. Все задачи можно решить на десятилетнем оборудовании за не более 15 секунд.

Проект поддерживается через AoC++ и социальные сети. Если вы застряли, автор советует проверять решения на примерах, создавать тестовые случаи и обращаться за помощью в subreddit. В разделе FAQ освещены вопросы аутентификации через OAuth, сложности задач (которые обычно возрастают со временем), разблокировки задач в полночь по EST, а также возможность участия в соревнованиях через приватные рейтинги.

• Сокращение до 12 дней вместо 25 вызвало бурную дискуссию: часть сообщества считает, что это разрушает саму суть "Advent of Code", в то время как другие отмечают, что это снизит нагрузку на автора и позволит ему продолжать проект.
• Пользователи отмечают, что сокращение до 12 дней делает невозможным привычное соревнование за лидербордом, и что это может оттолкнуть некоторых участников.
• Некоторые участники выразили обеспокоенность тем, что сокращение может повлиять на качество головоломок, так как автор будет иметь меньше времени на их разработку.
• Некоторые участники предложили альтернативы, такие как выпуск головоломки каждые два дня вместо ежедневного выпуска, что позволило бы сохранить привычный формат мероприятия.
• Участники также обсудили, что сокращение до 12 дней может повлиять на их собственные планы на декабрь, и что они могут не успеть решить головоломки до Рождества, что для них является важным элементом мотивации.

Статья объясняет, как Linux выполняет ELF-бинарные файлы — основной формат программ в современных Linux-системах. Поддержка ELF реализована в файле fs/binfmt_elf.c, где основная функция load_elf_binary() занимает более 400 строк кода — вчетверо больше, чем поддержка старого формата a.out. ELF-файл содержит заголовок ELF и таблицу заголовков программы, из которой ядро извлекает три ключевых типа записей: PT_LOAD (описывающие области памяти программы), PT_INTERP (определяющий компоновщик) и PT_GNU_STACK (указывающий, должен ли стек быть исполняемым).

Процесс загрузки начинается с проверки формата файла и чтения его заголовков. Затем функция вызывает flush_old_exec(), которая очищает состояние ядра, унаследованное от предыдущей программы, убивает другие потоки процесса и очищает обработку сигналов. Это обеспечивает чистый запуск новой программы с одним потоком. Интересно, что BSS-секция (для неинициализированных данных) в ELF-файле хранится только как размер, так как ядро заполняет её нулями при загрузке.

• Пользователи обсуждают, что в детстве изучение формата ELF привело к интересу к Linux и программированию.
• Обсуждается, что обработка исполняемых файлов теперь происходит в пространстве пользователя, что, как предполагается, может уменьшить риск крашей ядра из-за ошибок в формате.
• Участники вспоминают, что когда-то процесс загрузки ELF-файлов назывался "image activation", и что эта терминология исчезла после dot-com краха и появления LLM.
• Несколько человек спорят о том, как именно загружаются статические бинарники: часть считает, что ядро все еще обрабатывает их, другие утверждают, что это не так.

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

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

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

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

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

Пользователь на форуме задаётся вопросом: зачем нужна разработка в сторону «агентных» ИИ-систем, если текущие модели с трудом выполняют даже простые инструкции. Он привёл пример, когда GPT-5 и Gemini Pro не смогли корректно модифицировать даже одну функцию на 100 строк кода, и выражает скепсис по поводу того, что такие системы смогут работать с десятками файлов.

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

Второй совет — использовать режим планирования (plan mode) в Cursor, где система сначала анализирует проект, составляет план, а затем выполняет его, что значительно повышает качество результата по сравнению с прямым выполнением без плана.

Итог: хотя текущие ИИ и правда слабы в изоляции, правильное использование вроде добавления контекста через файлы и использование продвинутых режимов вроде plan mode превращает их в мощные инструменты для автоматизации разработки.

• В 2025 году маркетинг AI-решений стал настолько агрессивным, что бренды внедряются в обсуждения на Reddit, LinkedIn и других публичных форумах, чтобы продвигать свои продукты.
• Основная причина разногласий в сообществе разработчиков — это то, что LLM не справляются с задачами, которые не являются тривиальными, и при этом вендоры продолжают их продвигать как будто они могут решить всё.
• Участники обсуждения отмечают, что вместо того, чтобы улучшать модели и инструменты, компании вместо этого сосредоточены на создании и продвижении курсов и "лучших практик" по использованию этих инструментов.
• Некоторые разработчики делятся опытом, что LLM могут быть полезны для рутинных задач, но не для сложных проектов с унаследованным кодом, и что вместо того, чтобы улучшать модели, вендоры продолжают продвигать их как будто они могут решить любую задачу.

YouTube отчитался за 2024 год: доход вырос на 16% до $50 млрд, а прибыль — на 40%. Основной драйвер — Shorts и подписка Premium. Однако рост замедляется: квартал-в-квартале доход увеличился лишь на 4%, а трафик Shorts в США упал на 14%. Компания отвечает, что «это временное явление» и что «мы инвестируем в будущее роста».

• Воспоминания о Turbo Pascal и других языках 80-х/90-х вызвали волну ностальгии, но также подчеркнули, что большинство этих материалов сегодня труднодоступны или утрачены.
• Сообщество выразило желание сохранить эти материалы для исторического интереса, но признало, что они могут быть утеряны навсегда.
• Обсуждение подчеркнуло, что даже если эти материалы исчезнут, их влияние на развитие языков программирования и на мышление программистов останется.
• Участники поделились личными историями о том, как они учились программировать на этих языках, и как это повлияло на их дальнейшую карьеру.

Boot.dev-статья «I’m in Vibe Code Hell» разбирает, как меняется «ад» самообучающихся разработчиков: если раньше это было «tutorial hell» — бесконечные видео-туториалы, которые не учат думать, то теперь это «vibe code hell» — когда новички полагаются на AI-ассистентов, но не понимают, что именно они делают неправильно.

Автор статьи Лейн Вагнер, основатель Boot.dev, приводит данные Google Trends и трафика YouTube-каналов, показывающие, что интерес к обучению программированию не упал, но длинные видео-туториалы теряют популярность. Он считает, что причина в том, что новое поколение разработчиков использует AI-ассистентов, но не умеет «читать» и отлаживать код, и потому не учится думать как инженер. Вместо того чтобы учиться решать проблемы, они учатся вызывать халюцинации и «vibe coding» — лишь бы тесты проходили.

В статье подчеркивается, что важно учить студентов понимать, что AI-ассистенты не заменят необходимость знать, как работает код, и что критически мыслить остается ключевым навыком.

• Современные инструменты обучения коду приводят к "tutorial hell", когда учащиеся не могут начать проект с нуля, а только повторяют готовые решения.
• Использование AI-автодополнения вместо обучения может привести к "vibe coding hell", где человек не может написать код без подсказок.
• Исторически, обучение ремеслу происходило через ученичество, и это может быть единственным способом научиться программировать в современных условиях.
• Сообщество разработчиков обсуждает, что вместо того, чтобы полностью полагаться на AI, учащиеся должны использовать AI как усилитель, а не как замену фундаментальному пониманию.
• Обсуждение также затрагивает вопрос о том, как сохранить качество обучения и роста в условиях, когда AI может автоматически генерировать код, и как разработчики могут адаптировать свои методы обучения.

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

Отмена в асинхронном Rust — мощный, но сложный механизм. В синхронном коде отмену часто реализуют через проверку флагов или паники с особыми типами, но это плохо масштабируется. В асинхронной версии проблема глубже: при использовании timeout с операциями вроде tx.send сообщение может быть потеряно, если таймаут сработает во время ожидания места в канале. Это происходит потому, что будущее отменяется на определённой точке приостановки (await), не гарантируя отката уже выполненных действий.

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

• Обсуждаются проблемы безопасности отмены (cancel safety) в асинхронном Rust, когда операции могут прерываться в точке .await, что приводит к неожиданным побочным эффектам и потере данных.
• Поднимается вопрос о необходимости "асинхронного Drop" и более строгих гарантий выполнения для критических секций кода, которые не должны прерываться.
• Отмечается, что семантика отмены сильно зависит от контекста, и термин "cancel safety" может вводить в заблуждение, так как не относится к безопасности памяти (safety) в Rust.
• Участники делятся практическими примерами ошибок, связанных с отменой, и предлагают решения, например, буферизацию сообщений или явную пометку функций в документации.
• Обсуждается сложность ручного управления состоянием при реализации асинхронных структур и проводятся параллели с аналогичными проблемами в других языках, например, в Go.

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

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

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

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

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

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

Anthropic выпустила Claude Sonnet 4.5 — новую модель, которую называют лучшей в мире для кодинга, создания сложных агентов и работы с компьютерами. Она демонстрирует существенный прогресс в рассуждениях, математике и реальных задачах, сохраняя фокус более 30 часов на многоэтапных проектах. На бенчмарке SWE-bench Verified, оценивающем практические навыки программирования, модель показывает лидирующие результаты, а на OSWorld, тестирующем взаимодействие с компьютером, её показатель вырос до 61,4% против 42,2% у предыдущей версии всего за четыре месяца.

Модель уже интегрирована в обновлённые продукты Anthropic: Claude Code с чекпоинтами и нативной поддержкой VS Code, расширение для Chrome, позволяющее работать прямо в браузере, а также инструменты для создания файлов и управления контекстом. Для разработчиков выпущен Claude Agent SDK — инфраструктура, на которой строятся frontier-продукты компании. Sonnet 4.5 также получила высокие оценки экспертов в финансах, юриспруденции, медицине и STEM за улучшенные предметные знания и логику. Модель доступна через API по той же цене, что и Sonnet 4 — $3/$15 за миллион токенов.

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

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

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

• Разработчики отмечают, что ИИ-ассистенты полезны для быстрого поиска API, рефакторинга и работы в незнакомых средах, но часто мешают из-за навязчивого автодополнения.
• Оптимальной стратегией считается использование ИИ как "младшего разработчика": задание интерфейсов и тестов, а затем поручение реализации, либо написание кода самостоятельно с последующей оптимизацией ИИ.
• Чрезмерное доверие к генерации кода по промптам приводит к потере понимания кодовой базы, ошибкам и необходимости постоянно править вывод ИИ.
• Многие отключают автодополнение или переназначают горячие клавиши, так как агрессивные подсказки часто некорректны и отвлекают от работы.
• Высказываются опасения о влиянии ИИ на рынок труда, но скептицизм относительно полного замещения разработчиков в ближайшие 1-2 года.

Автор вспоминает, как начал программировать в 2010 году, почти бросив идею из-за неуверенности, но в итоге полюбил это дело через упорство. Он признаётся, что писал много «глупого» кода во время учёбы и игровых джемов, что помогло ему отточить навыки и сохранить интерес.

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

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

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

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

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

Это не статья, а навигационное меню сайта колледжа Брин-Мор. Здесь представлены ссылки на разделы для аспирантов и постбаккалаврских программ, включая Школу искусств и наук, Школу социальной работы и доврачебную подготовку. Также перечислены академические отделы, службы поддержки студентов и административные офисы — от приёмной комиссии и финансовой помощи до центра карьеры и библиотечных услуг. Структура демонстрирует комплексный подход к образованию, где учёба тесно связана с благополучием, развитием и практической поддержкой студентов на всех этапах обучения.

• Программирование приносит удовольствие от творчества, создания вещей с нуля и свободы экспериментировать без ограничений, накладываемых коммерческими проектами.
• Ключевые аспекты удовольствия: решение задач через сотрудничество с людьми, креативность, автоматизация процессов и наблюдение за результатом своих правил.
• Многие отмечают контраст между "игровым" режимом (для себя, без давления) и "рутинным" рабочим режимом, где творчество ограничено требованиями заказчика, стилем кода и дедлайнами.
• Взаимодействие с компьютером ценится за предсказуемость и ясность по сравнению с общением с людьми; ошибка почти всегда на стороне программиста.
• Обсуждается, что превращение хобби в работу может убить страсть, а современные сложные инструменты и практики (как Kubernetes) контрастируют с простотой и радостью программирования "для души".

Встраивание структур в Go позволяет обращаться к полям вложенных структур напрямую, но может приводить к неожиданным конфликтам имён. Например, если две вложенные структуры содержат поле с одинаковым именем, компилятор не выдаст ошибку, а выберет поле из наименее вложенной структуры — в примере opts.URL вернёт "abc.com", хотя ожидалась неоднозначность.

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

• Критика структуры Go за разрешение конфликтов имён полей при вложении структур, что может приводить к неочевидным ошибкам.
• Предложения считать такие случаи ошибкой компиляции или, как минимум, выдавать предупреждения через линтеры.
• Отмечается, что поведение соответствует спецификации (выбирается поле с наименьшей глубиной вложения), но это противоречит интуиции некоторых разработчиков.
• Приводятся аргументы за и против использования вложения структур: полезно для композиции методов, но опасно для данных.
• Обсуждается историческое происхождение фичи из Plan 9 C и её потенциальная полезность в ограниченных сценариях.

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

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

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

Асинхронное программирование 2.0
Автор: Ankur Goyal, 19 авг 2025

Я перестал писать код руками. Описываю задачу — агент пишет TypeScript/Rust/Python, тесты и коммитит. Я возвращаюсь только на ревью. Это не «вайб-кодинг», а новый цикл: чётко определяю → делегирую → проверяю.

Как работает

1. ТЗ как код: «снизить задержку поиска с 800 до 200 мс, убрав аллокацию в цикле».
2. Автопроверка: юнит- и интегра-тесты, типы, бенчи, линтеры — всё в CI.
3. Жёсткое ревью: агенты ошибаются, поэтому читаю PR дольше, чем писал раньше.

Плюсы

• Параллельно веду 4–5 задач: одну в фокусе, остальные в фоне.
• Система всё равно моя: архитектура и решения остаются моими.

Braintrust
Собственный агент Loop принимает описание eval-задачи и в фоне улучшает промпты, датасеты и скоры.

• «Async programming» в статье — это не про async/await, а про делегацию коду ИИ-агентам; название вызывает путаницу и споры.
• Ключевой шаг — чётко описать задачу; критики считают это самым трудным и редким навыком.
• Опасения: атрофия собственных навыков, взрыв технического долга, потеря удовольствия от программирования.
• Сторонники отмечают высокую скорость итераций и полезность ИИ для «скучного» кода (тесты, скрипты).
• Опыт офшоринга показывает: без точных спеков результат — задержки и недопонимание; ИИ ускоряет получение «среднего» кода, но не решает проблему спецификаций.

• Смотреть весь стек вызовов — мгновенно переходить к родительским фреймам и проверять переменные там.
• Вычислять выражения на лету — вызывать функции и менять состояние без перезапуска.
• Ловить исключения в точке броска — ставить брейкпоинт на throw и видеть, почему упало.
• Менять ход выполнения — подменить URL, флаг или объект прямо в памяти, не трогая код.
• Стандартизировать запуск — закоммитьте .vscode/launch.json, и новичку хватит одного клика, чтобы запустить сервер или CLI с нужными env и аргументами.

• Отладчики полезны, но часто ограничены: сети, прод-среды, сторонние библиотеки, оптимизация под release.
• Print-отладка универсальна: работает в любом языке, на удалёнке, в многопоточке и в kernel-space, не требует пересборки.
• Условные точки останова тормозят или врут; многие ставят «if (x) print("")» и брякают на неё.
• REPL, time-travel (rr/UndoDB), watch-точки на память и reverse-execution дают сверх-возможности, но доступны не везде.
• Итог: хороший инженер владеет и отладчиком, и логами, и профилировщиком, и выбирает инструмент под задачу.

• Участники сходятся во мнении: обещанного «10×-ускорения» от ИИ-кода не наблюдается; прирост заметен лишь в узких задачах и для неопытных разработчиков.
• Поводом для хайпа стали страх упустить преимущество (FOMO) и желание руководства оправдать сокращения и заморозку зарплат.
• Основной вывод: ИИ удобен для быстрых прототипов, скучных рутинных операций и «разогрева» незнакомого кода, но требует доработки, тестов и часто создаёт технический долг.
• «Шovelware»-взрыва не видно: большинство сгенерированных проектов либо бросаются, либо остаются внутренними; публикации и релизы не выросли.
• Многие отмечают риск атрофии навыков и падения качества кода, а также усталость от постоянной «борьбы с промптами».

Код — это долг

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

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

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

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

• Участники спорят, можно ли считать количество строк кода (LOC) мерой технического долга: одни считают LOC бесполезной метрикой без учёта качества, другие — формой риска и обязательств.
• Подчёркивается, что «меньше кода» ≠ «лучше», если он нечитаем, плохо документирован и не поддерживается; главное — скорость понимания и изменения.
• 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 %» требуют человека, иначе страдает качество и безопасность.
• Есть опасение, что чрезмерное доверие ИИ лишит новых разработчиков опыта «низкоуровневого» программирования.
• Предлагают режимы обучения, где ИИ объясняет каждое изменение и проверяет понимание, чтобы снизить будущую зависимость.
• Дискуссия сводится к тому, что навык «писать код» эволюционирует в навык «задавать правильные вопросы и проверять ответы».

Привет, я Прафул.
к статьям

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

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

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

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

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

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

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

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

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

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

Dev Compass — тест философии программирования
Ответь на 20 вопросов и узнай, где ты на оси «абстракция ↔ конкретика» и «удобно человеку ↔ удобно машине».

Вопрос 1 из 20
Далее

Твоя позиция
Абстракция ↔ Конкретика
Человеку ↔ Машине

Пройти заново

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

Почему LLM не могут строить ПО

Эффективный инженер постоянно прокручивает цикл:

1. формирует ментальную модель требований,
2. пишет код,
3. проверяет, что он реально делает,
4. сверяет модели и правит код или требования.

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

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

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

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

Читая очередной пост о том, как ИИ пишет целые библиотеки, я чувствую себя отстающим и решаю попробовать. Результат разочаровывает: несколько часов с моделью не дают даже половины задачи, которую я руками делаю за 25 минут.

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

На Hacker News снова хвалят GPT, и я не могу совместить их опыт со своим. Кажется, что мне врут: «это молот неразрушимый», а в руках — бумажная фигурка, которой даже помидор не раздавить.

• Кто-то восторгается Cursor/Claude и быстро набирает MVP, кто-то считает LLM-генерацию «тысячами строк мусора» и возвращается к ручному коду.
• Разница во впечатлениях объясняется выбором модели, способом взаимодействия и характером задач: новые мелкие проекты vs. огромные legacy-кодовые базы.
• Часть разработчиков использует LLM как «ускоренный Stack Overflow» и для рутинного бойлерплейта, другие отключают автодополнение из-за скрытых багов.
• Навык «prompt-инженерии» и контекст-менеджмента сравнивают с освоением Vim: сначала замедляет, потом ускоряет, но требует времени.
• Скептики упрекают маркетинг в FOMO и «газлайтинге», а сторонники считают, что просто нужно правильно выбрать инструмент и научиться с ним работать.

• Introducing GPT-5 — YouTube

• Пропустить навигацию

• Поиск / Поиск голосом

• Войти

• Смотреть позже • Поделиться • Копировать ссылку • Покупки

• Нажмите, чтобы включить звук • 2x

• Если воспроизведение не началось, перезапустите устройство.

• Вы вышли из аккаунта. Просмотры могут влиять на рекомендации на ТВ. Чтобы избежать этого, отмените и войдите на YouTube на компьютере.

• Отмена • Подтвердить

• 37:35 • 7 августа, 10:00 GMT-7

• Далее • Прямой эфир запланирован • Играть

Introducing GPT-5

• OpenAI • Подтверждено • 1,65 млн подписчиков
• Подписаться • Подписаны
• 6 522 ожидают • Запланировано на 7 авг. 2025
• 1K • Поделиться • Скачать • Сохранить
• Комментарии отключены

Описание

• Introducing GPT-5

• Присоединяйтесь к Сэму Альтману, Грегу Брокману, Себастьену Бюбеку, Марку Чену, Янну Дюбуа, Брайану Фиоке, Ади Ганешу, Оливеру Годеману, Саачи Джайн, Кристине Каплан, Тине Ким, Элейн Я Ле, Фелипе Миллону, Мишель Покрасс, Якубу Пахоцки, Максу Шварцеру, Ренни Сонгу, Жожену Вану — они представят и продемонстрируют GPT‑5.

• OpenAI: Видео • О канале • Twitter • LinkedIn

• Участники обсуждают качество ИИ для повседневного программирования: один отмечает сильное превосходство Anthropic (Sonnet 3.7/4 и Claude Code), причём в Cursor опыт хуже, чем в самом Claude Code, и OpenAI‑модели он почти не использует.
• Есть надежда, что GPT‑5 сократит отставание OpenAI, хотя мнения пользователей сильно расходятся.
• Другой комментатор ожидает, что грядущие анонсы покажут радикальное влияние на рынок: веб‑ и JS/TS‑разработчики могут стать частично или полностью невостребованными.
• При этом подчёркивается, что речь ещё не об «AGI» — максимум о ~10% от обещанных возможностей AGI.
• Отмечается ночной «слив», указывающий на фокус на кодинге; предполагается, что для названия «GPT‑5» OpenAI должен предложить существенное преимущество над Anthropic.

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

Jules интегрируется с инструментами разработчиков, может брать на себя длинные задачи, делить их на шаги, сообщать о прогрессе и запрашивать уточнения только при необходимости. Доступен через Google Labs и ориентирован на повышение продуктивности как отдельных инженеров, так и команд, позволяя запускать больше экспериментальных веток и быстрее проводить ревью.

• Пользователи жалуются на запутанные подписки Google: разные продукты (Jules, Gemini App/CLI, Code Assist) разбросаны между Workspace и GCP, цены и доступ скрыты или требуют согласий и биллинга.
• Опыт с Jules противоречивый: часть считает его слабее Claude Code, Copilot/Claude Sonnet и Gemini CLI (низкое качество кода, проблемы в монорепо, зацикливание, отсутствие кнопки STOP, баги UI), другие довольны асинхронным форматом и считают удобным для пачек задач, тестов и сайд‑проектов.
• Замечены регрессии: лимит задач на бесплатном плане снизили с 60 до 15; качество, по словам некоторых, упало после увеличения дневных лимитов на раннем превью.
• Пользователи хотят интеграции с GitHub (issues, комментирование PR для фидбэка), явного просмотра публичных улучшений кода и лучшей связности с Gemini CLI/Actions.
• Есть путаница в позиционировании: что такое «асинхронный кодовый агент», чем Jules отличается от Gemini CLI и с кем он конкурирует (Claude Code, Codex, Crush).
• Критика брендинга/UX: «детский» лендинг, слабый контраст, плохой пиксель‑арт; общее ощущение, что UI отстает от возможностей модели.
• Итоговое восприятие: интерес к формату асинхронных агентов есть, но текущая реализация Jules часто уступает Claude Code по скорости/качеству и стабильности; пользователи просят прозрачные тарифы и единый продуктовый опыт.

Java is more akin to the Corolla. Utterly insipid (by design), lacking in refinements compared to competitors like the Mazda3, and made for people who just see it as a way to get from point A to point B.PHP is the Hyundai Elantra of programming. It used to be popular because of l

New vibe coding definition just dropped! "Vibe-Coding is a dialogue-based coding process between a human and an AI where the human guides and the AI implements."Reminds me of Steve Yegge's short-lived CHOP - Chat Oriented Programming: https://sourcegraph.com/blog/chat-oriented-pr

This is epic: :)From : https://github.com/ioccc-src/winner/blob/master/2024/kurdyuk...This code draws the current moon phase to the console. So if you’re a lycanthrope, you can monitor the phase of the moon.#include <time.h> #include <stdio.h> a,b=44,x, y,z;main() {!a ?a=2551443,

Hey folks, this is the 7th book in a series of readings I run over Google Groups. There are about 1800 people in the group and 300-800 join each reading. While we often read books on database internals this one seems pretty relevant to any developer working on systems that scale.

I have about two weeks of using Claude Code and to be honest, as a vibe coding skeptic, I was amazed. It has a learning curve. You need to learn how to give it proper context, how to chunk up the work, etc. And you need to know how to program, obviously. Asking it to do something