Программная инженерия - это управление сложностью (hack8s)

Безымянная публикация 2026 года на hack8s.com переформулирует старый тезис для эпохи LLM: написание кода и создание программного обеспечения - разные задачи, ИИ отлично справляется с первой, а со второй как раз и начинается инженерия software-engineering-managing-complexity. Написание кода переводит идею в инструкции, которые может выполнить компьютер. Создание ПО решает, какие инструкции вообще должны существовать, как они взаимодействуют, какие ограничения важны, во что обходится каждое решение и как система сможет изменяться в будущем, не разрушаясь.

Решает контекст

В качестве примера приводится обычное требование: обработать входящие события и обновить данные. Ещё до того, как кто-то напишет хоть строчку, команде нужно решить: синхронная это обработка или через очередь, достаточно ли доставки at-least-once или требуется exactly-once, приемлема ли eventual consistency, что происходит при сбое на полпути, как работают повторные попытки (retries), что произойдёт, если consumer будет недоступен три часа, важен ли порядок сообщений и какова цена дубликата. Ничего из этого к синтаксису не относится.

Одна и та же возможность, запрошенная двумя компаниями, может иметь два правильных архитектурных решения. У одной - 500 пользователей, три инженера, один сервер приложений с PostgreSQL и три недели времени. У другой - 20 миллионов пользователей, 200 инженеров, уже развёрнутые Kafka и Kubernetes и расчёт на то, что система проработает пятнадцать лет. Впечатляющая архитектура для второй компании окажется безответственным выбором для первой. Поэтому настоящий вопрос никогда не звучит как "какой способ реализации X самый лучший", а скорее "какой способ наиболее уместен с учётом этой команды, бизнеса, инфраструктуры, бюджета, рисков и ожидаемого развития прямо сейчас".

Попросите LLM спроектировать такую систему, выбрать базу данных или определиться с очередью, и она выдаст ответ. Суть в том, замечает автор, что ответ - это ещё не решённая задача. Контекст, который определяет выбор, по большей части нигде не задокументирован: разговоры с клиентами, история продукта, навыки команды, инцидент трёхлетней давности, контракты, legacy-система, к которой никто не хочет прикасаться, функция, которую клиент, скорее всего, попросит через полгода. Всё это не уместить в ещё один абзац prompt'а. Поскольку любое архитектурное решение меняет одну проблему на другую (кэширование снижает задержки, но требует инвалидации; распил монолита даёт независимые deploy'и, но приносит сложность распределённых систем), задача инженера - решать, где именно должна находиться сложность.

Владение кодом

Более острая половина статьи посвящена тому, что дешёвый код делает с кодовой базой. Создание кода и его поддержка - разные экономические процессы, и подешевел только первый. Команда может влить тысячи сгенерированных строк, увидеть, что тесты проходят, а функциональность работает, но так и не понять архитектуру, структуры данных, причину появления абстракции, характер её сбоев или заложенные в неё допущения. Если через полгода они не смогут уверенно изменить этот код без просьбы к другой модели объяснить написанное первой, значит, они добавили сложность, а не убрали её. Сгенерированный pull request на 3000 строк - это 3000 строк, добавленных к тому объёму, который команда обязана понимать, а зелёный набор тестов по большей части даёт лишь ложную уверенность.

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

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

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

В контексте других страниц

Этот аргумент - бруксовское разделение на сущностную и привнесённую сложность, применённое к сгенерированному коду; на странице no-silver-bullet-llms тот же тезис подкрепляется цифрами из DORA и CircleCI. Раздел о владении кодом показывает cognitive-debt на уровне команды. Страница owning-ai-written-code тоже отстаивает мысль, что релиз сгенерированного кода требует полного владения им, но с индивидуальной стороны: ручное написание кода раньше вынуждало разбираться в нём, а агенты это устраняют.

Сформулированное автором определение владения - полное понимание кодовой базы - сталкивается с позицией на странице not-understanding-your-codebase, где Шон Гёдеке (Sean Goedecke) утверждает, что в любой крупной системе этим не обладает никто, а частичное понимание - единственная честная отправная точка. Обе позиции можно свести воедино лишь с оговоркой: частичное понимание по Гёдеке формируется чтением и трассировкой системы, тогда как в этой статье беспокойство вызывает код, который ни один человек вообще не читал. Однако как общий стандарт "полное понимание" строже, чем может выполнить любой разработчик в крупной кодовой базе, и статья не объясняет, как применять это правило в таких масштабах.

В вопросе выбора языков позиция статьи расходится с language-choice-for-agents и if-ai-writes-your-code-why-use-python, где утверждается, что выбор должен смещаться в сторону того, что агенты хорошо пишут и проверяют. В этой статье на первое место ставится уверенное владение языком самой командой.