Hacker News Digest

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

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

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

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

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

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

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

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

Главная задача - научить организацию ценить то, чем она не занимается, и выполнять работу, которая без вас не произойдет. "Быть прав - это менее половины битвы; нужно убедить других, что вы правы, и побудить их действовать". Ключ к успеху - масштабирование через других: "успех PE (principal engineer) - когда организация способна принимать те же решения, что и PE".

• Обсуждение развернулось вокруг того, что такое «Principal Engineer» и каковы его границы: от «rockstar-инженеров» до «просто хороший инженер, который пишет в блоге о себе в третьем лице».
• Участники обсуждения подчеркнули, что в больших компаниях уровень L6/L7 часто не соответствует реальному влиянию или вкладу, а вместо этого может быть просто результатом политики и саморекламы.
• Были высказаны сомнения в том, что такие должности как Principal Engineer в больших компаниях действительно нужны и что они не являются просто результатом «игры в уровни» и не имеют реального влияния.
• Участники также обсудили, что влияние таких должностей может быть негативным, поскольку они могут быть использованы для саморекламы и политики, а не для технического вклада.

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

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

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

Автор делится программными эссе, которые повлияли на его мышление за 20 лет карьеры. Среди них — «Тест Джоэла» Джоэла Спольски, который предлагает 12 вопросов для оценки качества работы команды, подчеркивая уважение к разработчикам и их времени. Эссе Алексис Кинг «Парси, а не валидируй» показывает, как использование типов данных повышает безопасность, превращая сырые строки в проверенные структуры. Фред Брукс в «No Silver Bullet» утверждает, что не существует волшебного решения сложности ПО, поскольку её корни — в сущностных, а не случайных проблемах.

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

• Обсуждаются влиятельные эссе и статьи о разработке ПО, включая "Parse, don't validate", "Choose Boring Technology" и анализ инцидентов с Therac-25.
• Поднимаются вопросы о качестве тестового кода: спор о допустимости логики в тестах и важности их простоты для избежания ложных срабатываний.
• Обсуждается влияние ИИ на классическую теорию Brooks'а об отсутствии "серебряной пули" и его способность снижать essential complexity.
• Упоминаются ключевые работы, повлиявшие на мышление разработчиков, такие как "Grug Brained Developer", "Code Complete" и "Don't Call Yourself A Programmer".
• Затрагивается проблема цифровой идентификации и доступа к аккаунтам в сравнении с аналоговым миром, где проще доказать свою личность.

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

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

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

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

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

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

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

• Брукс по-прежнему прав: основная трудность — «существенная сложность» предмета, а не инструменты.
• За 40 лет не появилось ни одного «серебряного пули», дающего 10× прирост продуктивности.
• Экосистемы (Python, AWS и др.) снизили accidental complexity, но добавили новую через зависимости и «слоёный пирог».
• LLM и ИИ ускоряют рутину, но не решают существенную сложность и не умеют формулировать требования.
• Культура SWE изменилась: скорость вытеснила ответственность, код пишут «на скорую руку» и быстро забывают.

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

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

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

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

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

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

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

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

• Опасные советы — это то же, что и «острые инструменты»: в умелых руках дают максимум пользы, в неумелых — вред.

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

• Боюсь, что кто-то применит их неумело и испортит карьеру, но считаю, что такие советы нужно где-то фиксировать.

• Большинство карьерных советов фальшивые: написаны «на всякий случай» и не работают. Сильным инженерам нужна правда, а не страховка.

• Менеджеры не могут их озвучить: если ты провалишься, это ударит по ним сильнее, чем по тебе. Поэтому они молчат, хотя сами бы хотели, чтобы ты действовал гибче.

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

• Советы по карьере в инженерии сильно зависят от контекста: в функциональных организациях они могут сработать, в дysфункциональных — навредить.
• Управленцы и «технарь» сталкиваются с неполной информацией и поэтому создают правила, но жёсткое следование им не всегда эффективно.
• Некоторые считают, что организациям нужны и «моряки» (rule-followers), и «пираты» (rule-breakers), но рискованные советы могут дискредитировать или травмировать.
• Примеры из других профессий (арбористы, гонщики, монтажники) показывают: снятие «защит» может ускорить работу, но приводит к серьёзным авариям и увольнениям.
• Самые сильные инженеры не имеют полной свободы выбора задач — их работа всё равно должна приносить пользу бизнесу.

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