Hacker News Digest

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

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

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

Claude Sonnet 5 is Anthropic’s most agentic Sonnet model yet, delivering performance that rivals Opus 4.8 while costing less. Benchmarks show it narrows the gap on reasoning, tool use, coding and knowledge work, achieving scores near Opus 4.8 on the BrowseComp and OSWorld‑Verified evaluations. Safety tests show fewer undesirable behaviors than Sonnet 4.6, though cybersecurity skill stays weaker than Opus. The model runs autonomously, can plan, use browsers and terminals, and self‑correct without explicit prompting.

The model is now the default for Free and Pro tiers and is available to Max, Team and Enterprise users via the Claude API as claude-sonnet-5. Introductory pricing runs through Aug 31 2026 at $2 per million input tokens and $10 per million output tokens, rising to $3 and $15 thereafter. Early partners say it finishes complex end‑to‑end tasks—updating Salesforce tiers, drafting launch announcements—without stopping short, and routinely checks its own output. One engineer noted it “gives our agents a strong execution layer for multi‑step software engineering work,” highlighting its ability to sustain coding, tool use and debugging at an attractive price.

• Sonnet 5 обходится дороже за задачу, чем Opus 4.8, при этом часто уступает ему в эффективности и способностях
• Модель использует новый токенизатор, увеличивший количество токенов вводных данных на ≈ 1,3×, что повышает стоимость без пропорционального прироста качества
• На тестах по кибербезопасности Sonnet 5 показывает значительно более низкие результаты, чем Opus 4.8 и Mythos 5, что вызывает сомнения в его рекламных заявлениях
• Пользователи отмечают, что при повышенных уровнях рассуждения (medium, high) Sonnet 5 не оправдывает цены, а лучше использовать её только в низком режиме или переключаться на более крупные модели

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Therac-25: катастрофа, о которой должен знать каждый разработчик

21 марта 1986 г. в онкоцентре Восточного Техаса оператор установила пациента под 25-мегаэлектронвольтный пучок Therac-25. После лазерной привязки она повернула поворотный столик в положение «электронный режим», ввела параметры и нажала «Ввод». Машина выдала ошибку «MALFUNCTION 54» и остановилась. Оператор, привыкшая к частым глюкам, нажала «П» (продолжить) — стандартный шаг в инструкции.

Через секунды пациент вскрикнул: «Вы меня сожжёте!» Он получил дозу в сотни раз выше нормы, эквивалентную взрыву гранаты в теле. Через 21 день он умер от радиационных ожогов.

За 18 месяцев случилось ещё пять подобных инцидентов: трое погибли, двое получили тяжелейшие травмы. Причина — баг в коде: гонка между потоками ввода и механическим поворотом столика. Если оператор успевала изменить параметры до окончания поворота, программа «забывала» установить ограничитель и выдавала 25 МэВ электронов вместо 200 кэВ рентгеновского излучения.

Компания-изготовитель AECL отрицала проблему, пока не столкнулась с неопровержимыми доказательствами. Расследование показало:

• отсутствие независимого контроля безопасности;
• игнорирование жалоб;
• инструкции, учившие игнорировать ошибки.

Therac-25 стал учебным примером: безопасность должна быть встроена, а не добавлена «потом».

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

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

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

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

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

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

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

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

Почему наём — боль

Компании теряют время: 9 раундов, охота за «трендовыми» разрабами, не могут отличить программиста от LLM. Кандидаты страдают: лучшие разрабы (Rust, Haskell) проваливают стресс-интервью, рекрутеры называют их «не-технарями», а потом пропадают на месяцы.

Каким должен быть хороший процесс

1. Различать сеньора и маркетолога с ChatGPT.
2. Применимо к работе: код, архитектура, ревью, документация.
3. Долгосрочно: люди не взаимозаменяемы, уход дорого, специализация под стек выучивается за месяц.
4. Экономно: инженерное время дорого.
5. Уважительно: неуважение отпугивает лучших.
6. Вкус: быстрое, но грязное решение — долгий долг команде; «клей» (поддержка коллег) множит продуктивность.

Почему популярные форматы не работают

• Live-coding / LeetCode
  Не различают, не про работу, уничтожают уважение и вкус, дорогие при многократных раундах.

• Take-home
  Легко сгенерировать ChatGPT, неуважительны к времени кандидата, отпугивают сильных.

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

• Современные «интервью» больше похожи на серию экзаменов, чем на профессиональный разговор.
• Многие считают, что достаточно 1-2 коротких встреч или пробы через контракт «temp-to-perm», чтобы понять, подходит ли человек.
• Популярные live-coding и leetcode почти не отражают реальную работу и отбирают не тех специалистов.
• Лучше обсуждать реальные задачи, ревьюить существующий код или решать мелкий баг в паре — это ближе к ежедневным обязанностям.
• Кандидаты теряют время и энергию на домашние задания и 9-часовые циклы, поэтому всё чаще «интервьюируют» и сами компании.