Hacker News Digest

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

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

Участники обсуждения (@jameskilton, @Megranium, @sirnicolaz, @kazinator, @andersmurphy) ставят под сомнение новизну метафоры «кода как глины», утверждая, что ПО всегда было пластичным (software), а подобные концепции давно реализованы в Lisp. По мнению @keyle, AI не изменил природу кода, а лишь радикально снизил стоимость итераций. Однако это создает риски: код может стать «одноразовым пластиком» (@besterman23) или настолько запутанным «мусором», что даже LLM предпочтут переписать его с нуля (@jameskilton). Критики (@sdevonoes, @YmFzZTY0ZGFkZHk) добавляют, что такая пластичность неприменима в крупных проектах, где важны бизнес-правила, согласование с экспертами и учет недокументированного поведения. @closeparen отмечает, что внедрение нового функционала через AI в больших системах часто усложняет ревью и исправление ошибок. В качестве решения @melvinroest предлагает использовать «vibe-coding» для быстрого прототипирования и проверки требований: создавать приложение за 1–2 дня, а затем использовать прототип как спецификацию для полноценной ручной разработки.

Маргарет Гамильтон, пионерка вычислений и руководительница команды разработки программного обеспечения для программы «Аполлон» в MIT, скончалась в возрасте 90 лет. Её работа в 1960-х годах, когда область программирования ещё находилась в зачаточном состоянии, привела к созданию надёжного бортового ПО, которое обеспечило успешную посадку человека на Луну. Гамильтон не только написала ключевые части кода, но и ввела термин «инженерия программного обеспечения», отстаивая необходимость строгой методологии и предвидения ошибок — концепции, которые позже стали фундаментом всей индустрии.

Она начала карьеру в MIT в 1959 году, работая над метеорологическим ПО с Эдвардом Лоренцом, затем участвовала в проекте SAGE — первой системе ПВО США. В 1965 году стала первой женщиной-программистом в проекте «Аполлон», а к 1968 году возглавила команду по разработке ПО для командного и служебного модулей. Её акцент на обработке непредвиденных ситуаций и отказоустойчивости напрямую способствовал успеху миссий, включая Apollo 11, когда её система обнаружила и компенсировала перегрузку процессора во время посадки. После MIT Гамильтон основала собственные компании, продолжая инновации в системном ПО, и получила numerous наград, включая Президентскую медаль Свободы от Барака Обамы в 2016 году, а также стала символом для женщин в STEM, попав в набор LEGO «Женщины NASA» и увидев свой код выложенным на GitHub в 2015 году. Её наследие живет в принципах надёжного и системного программирования, которые она помогла определить.

Работа Маргарет Гамильтон обеспечила успешную посадку на Луну и заложила фундаментальные принципы надёжного ПО, включая обработку ошибок и введение термина «software engineer». Обработка ошибок 1201/1202 в Apollo Guidance Computer, реализованная под её руководством, позволила миссии продолжиться несмотря на перегрузку — ключевой пример практического влияния её подхода. Фотография Гамильтон со стопкой распечатанного кода стала символом масштаба и серьёзности программирования в эпоху Аполлона. В 1960-х руководство доверяло её команде полную свободу, так как программирование воспринималось как «чёрный ящик» — в отличие от современных корпоративных ограничений. Современные разработчики отмечают, что сегодня их работа часто сводится к созданию «silly APIs», тогда как в прошлом программисты решали задачи, определявшие судьбу человечества. Гамильтон, вместе с Грейс Хоппер и Адой Лавлейс, остаётся важным вдохновением для инженеров, особенно женщин в технологиях, несмотря на мужскую доминанту в отрасли. Её команда из Draper Lab была настолько передовой, что даже через 30 лет после Аполлона их знания казались непостижимыми для стартаперов. Рост популярности Гамильтон связан с усилиями по выявлению «забытых героев» науки, но это не оспаривает её реальных достижений. Её работа демонстрирует, что надёжность ПО зависит от архитектурных решений, а не от мощности процессора — опровергая миф о невозможности Аполлона из-за слабых компьютеров. Подход Гамильтон к разработке ПО — с акцентом на формализованные системы и отказоустойчивость — стал одним из первых серьёзных шагов к превращению программирования из «магии» в науку. Её наследие вдохновляет не только технически, но и морально: многие хотели бы рассказать о ней детям как о примере того, как один человек может изменить мир. Несмотря на отсутствие доступа к оригинальному коду Аполлона, его принципы — обработка ошибок, приоритизация задач, отказоустойчивость — стали стандартами в критически важных системах.

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

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

ИИ не заменяет мудрость, а усиливает когнитивную атрофию разработчиков: переставая читать и анализировать код, они теряют интуицию, необходимую для поддержки сложных систем. Большинство кода в продакшене уже плохо написано — ИИ ускоряет его деградацию, обучаясь на низкокачественных данных и воспроизводя плохие паттерны. Архитектурная мудрость не измеряется линтерами (SonarQube и т.п.) — она возникает из глубокого понимания контекста, многолетнего опыта отладки и чувства «запахов» кода. ИИ не может воспроизвести эту интуицию. Даже если опытные разработчики полагаются на тесты и не читают сгенерированный код — это исключение, не правило. Для большинства, особенно новичков с менее чем 5-летним опытом, ИИ маскирует дефицит проектных навыков, ускоряя создание кода, но не обучение. Если команда не понимает, как работает сгенерированный код, она не может его изменять при новых требованиях. Использование ИИ без понимания каждого изменения приводит к потере контроля над архитектурой и невозможности отвечать за долгосрочную жизнеспособность системы. ИИ не создаёт знания — он отражает паттерны в данных. Если данные — плохой код, ИИ генерирует плохой код, ускоряя деградацию крупных кодбаз, которые и так со временем ухудшаются. Проблема не в ИИ как таковом, а в том, что люди перестают учиться писать хороший код и теряют способность отличать хорошее от плохого. Новички, получая код от ИИ вместо чтения кода опытных коллег, не усваивают институциональные знания — никто не знает, почему код написан так, а не иначе. «NO-AI» политика маловероятна как конкурентное преимущество: большинство компаний ценят скорость и прибыль, а не архитектурную целостность. Совет: используйте ИИ только для генерации шаблонов, но всегда задавайте себе вопрос: «Понимаю ли я, почему этот код работает так, а не иначе?» — иначе вы становитесь пассивным наблюдателем за собственной работой.

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

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

Основная причина безумия разработчиков — не само ПО, а его отрыв от реальных пользователей, финансовые стимулы, управленческие искажения и технологический шум. Изоляция от клиентов и взаимодействие только через менеджеров резко повышают риск безумия; регулярное общение с пользователями возвращает фокус на реальность. Современные команды из 60–80 человек разрабатывают CRUD-приложения, тогда как 20 лет назад небольшие команды из 4–5 человек создавали критически важные системы на C++ — это указывает на рост технологического шума и снижение эффективности. Технические лидеры ошибочно принимают успех в абстрактной модели за победу над реальной доменной областью, что ведёт к эгоцентризму и потере связи с потребностями пользователей. Программирование, лишённое физических ограничений, создаёт иллюзию неограниченной свободы, активируя неуверенность и компульсивное вмешательство. Большинство программ — электронные таблицы с интерфейсом, но сложная архитектура (сервис-меш, event-driven) используется как маркетинг, а не как необходимость, искажая восприятие ценности работы. Финансовые стимулы — обещание быстрых миллионов от стартапов — заставляют разработчиков искать «идеальный путь» вместо реального решения. Отсутствие жёсткой обратной связи и физических ограничений делает ПО средой для неадекватного поведения: ошибки не имеют немедленных последствий. Управление ПО часто осуществляется неразработчиками, которые воспринимают изменения в коде как простые физические доработки, не понимая их сложности и рисков. Современные инструменты, включая LLM, делают изменения в ПО дороже, снижая частоту произвольных правок, так как PM больше не могут «спасти» бюджет за счёт лёгких правок. Работа за экранами и цифровая перегрузка вызывают диссоциацию и потерю связи с реальностью — коллеги за 10 лет превращаются в истощённых «мурмурщиков». Оставлять всё как есть — недооценённый навык инженерии: постоянные изменения ради «улучшения» разрушают стабильность и создают психологическую нагрузку без реальной пользы. Интернет и цифровая среда создают замкнутую эпистемологию, где всё субъективно и самоподтверждающе, усиливая иррациональные убеждения и отрывая от внешней реальности. Пользователи хотят простые, надёжные инструменты — успешные приложения вроде BookFusion и Libro.fm доказывают, что минимализм и фокус на базовых функциях приводят к большей ценности. Совет: применяй зен-подход — смотри на код как на инструмент, а не как на средство для славы; тогда эго, соревнование и ненужные изменения теряют силу, и сохраняется психическое здоровье. Совет: используй MVP и быструю обратную связь — если функция не приживается, удаляй её, а не усложняй систему ради «идеального» решения, которое никто не использует.

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-часовые циклы, поэтому всё чаще «интервьюируют» и сами компании.