AI генерирует код, но инженеры владеют компромиссами: почему сложность — главная проблема
Software engineering is about managing complexity
Статья развенчивает миф о том, что разработка ПО сводится к написанию кода. Настоящая инженерия начинается с решений: какие инструкции должны существовать, как они взаимодействуют, какие компромиссы допустимы. AI отлично справляется с генерацией кода, но не может заменить инженерное суждение, которое зависит от контекста: масштаба, команды, бюджета, legacy-систем и будущих изменений. Автор предлагает десять принципов алгоритмического мышления, которые становятся важнее в эпоху AI, и предупреждает о проблеме владения кодом: когда AI генерирует тысячи строк, команда может потерять понимание системы, а понимание — дороже строк кода.
Инженерия — это в значительной степени дисциплина выбора проблем, с которыми вы готовы мириться.
- zug_zug
Всё, что сказано про сложность, абсолютно верно.
Однако, я думаю, что фразы вроде «Инженеры владеют компромиссами» преувеличивают то, чем на самом деле занимаются инженеры. По моему опыту, точно меньше половины работающих программистов действительно проводят настоящий анализ, отвечая на такие вопросы, как:
«Учитывая эти ограничения, эту команду, этот бизнес, эту инфраструктуру, этот бюджет, эти риски и ожидаемую эволюцию продукта, каков наиболее подходящий способ реализовать X сегодня?»
Поэтому я думаю, что ИИ способен заменить среднего инженера в большей степени, чем признается в этой статье. Однако неадекватность «средней инженерии» теперь станет гораздо более очевидной: кодовые базы могут стать настолько большими и сложными, что станут неуправляемыми за считанные месяцы, тогда как раньше на это уходило 5 лет [временной масштаб, в котором ответственность практически невозможна].
- cobbal
Я потерял нить на первом же предположении. Люди могут спорить о том, насколько полезен ИИ, но он явно не является необходимым, потому что мы как-то умудрялись писать код без него несколько лет назад. Я бы даже сказал, что тогда код был лучше.
Две задачи — написание кода и проектирование программного обеспечения — не могут быть разделены без ущерба для целостности ментальной модели инженера. Архитекторы, которые не взаимодействовали с кодом, всегда приводили к несоответствию между картой и территорией.
- a2ff6eeb0
ИИ также может сгенерировать для вас архитектуру на основе требований и задать необходимые уточняющие вопросы.
Он пока не так хорош в системном проектировании, как в написании кода. Но, похоже, он лучше, чем большинство моих коллег.
Я думаю, что через несколько месяцев системная архитектура переживёт свой момент Claude Code, и люди будут превзойдены.
- wyum
Сложность программного обеспечения растёт сверхлинейно, если не экспоненциально, по мере добавления компонентов.
Инженер может сделать кое-что, чтобы сгладить кривую — это идея автора об управлении сложностью, — но рост сложности никогда не может быть линейным, пока вы добавляете что-то в программное обеспечение.
Я создал модель/теорему для этого и опубликовал её в X: https://x.com/i/status/2027771813346820349
Генерация кода выявила, что проверка является центральной проблемой программной инженерии. И я думаю, что так было всегда.
Определить, что является «правильным», уже может быть достаточно сложно, не говоря уже о создании системы, которая поддаётся проверке, и о времени, которое нужно потратить на проверку. Поэтому выпуск программного обеспечения и предоставление пользователям возможности находить ошибки — очень эффективная стратегия, поскольку она распределяет бремя. Но нужно балансировать между потерей пользователей и получением достаточной обратной связи, чтобы найти и исправить важные ошибки.
Когда мы сталкиваемся с вопросом, не заберёт ли ИИ наши рабочие места, меня утешает мысль, что мир может быть слишком сложным даже для самого большого и хорошо обученного ИИ, который мы можем себе представить. В какой-то момент вам нужно симулировать весь мир (или значительную его часть), и соотношение затрат и выгод от попыток сделать это с помощью вычислений может не стоить того по сравнению с использованием реального мира (то есть людей) в качестве проверяющего.
- softwaredoug
Иногда эти компромиссы касаются полдюжины вещей в нескольких строках кода. И именно здесь я не решаюсь позволить агенту работать. Он отлично справится с созданием корректного кода. И вы можете в какой-то степени ограничить его, чтобы он думал ещё об одной вещи. Но он теряет нить, игнорирует ограничения, жульничает, и нужно ли нагромождать сложность, чтобы предотвратить это? Или просто посмотреть на дюжину строк кода, чтобы исправить это?