Парадокс Джевонса для программной инженерии

Каждый раз, когда мы упрощали создание ПО, мы в итоге писали экспоненциально больше кода. ИИ-ассистенты повторят этот паттерн в беспрецедентных масштабах.

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Парадокс Джевонса для программной инженерии

Every time we've made it easier to write software, we've ended up writing exponentially more of it Автор: Addy Osmani Оригинальный текст:

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

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

@levie недавно сформулировал, почему этот паттерн вот-вот повторится в масштабах, которых мы ещё не видели, используя парадокс Джевонса (Jevons Paradox) как концептуальную рамку. Аргумент резонирует, потому что разворачивается прямо сейчас в наших инструментах разработки. Первый вопрос, который все задают: «заменит ли это разработчиков?» Но посмотрите, что происходит на самом деле. Команды, внедряющие эти инструменты, не всегда сокращают штат инженеров — они расширяют охват продукта. Стартап из трёх человек, который мог поддерживать только один продукт, теперь поддерживает четыре. Корпоративная команда, которая могла экспериментировать с двумя подходами, теперь пробует семь.

Барьер активации, а не компетенций

Ограничение, которое снимается — это не компетентность, а энергия активации, необходимая для старта чего-то нового. Подумайте о том внутреннем инструменте, который вы откладывали, потому что «это займёт у кого-то две недели, а мы никого не можем выделить»? Теперь это занимает три часа. Тот рефакторинг (refactoring), который вы откладывали, потому что соотношение риска и выгоды не складывалось? Математика только что изменилась.

Это важно, потому что разработчики ПО находятся в уникальной позиции, чтобы понять, что грядёт. Мы видели этот фильм раньше, просто в меньших масштабах. Каждый слой абстракции — от ассемблера к C, к Python, к фреймворкам, к low-code — следовал одному паттерну. Каждый должен был означать, что нам понадобится меньше разработчиков. Каждый вместо этого позволил нам создавать больше софта.

Экономическая жизнеспособность задач

Вот часть, которая заслуживает больше внимания: снижаемый барьер — это не только скорость написания кода. Это типы задач, которые становятся экономически целесообразными для решения с помощью ПО. Подумайте обо всех внутренних инструментах, которых не существует в вашей компании. Не потому, что никто о них не думал, а потому что расчёт ROI никогда не преодолевал планку. Кастомная панель управления, которая сделала бы одну команду на 10% эффективнее, но потребовала бы недели на разработку. Pipeline (пайплайн, конвейер обработки) данных, который раскрыл бы инсайты, но требует специализированных знаний. Интеграция, которая сгладила бы рабочий процесс, но затрагивает три разные системы.

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

Эффекты второго порядка

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

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

Смена парадигмы для инженеров

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

Системная ошибка прогнозирования

Мета-точка здесь в том, что мы продолжаем совершать одну и ту же ошибку прогнозирования. Каждый раз, когда мы делаем что-то более эффективным, мы предсказываем, что этого станет меньше. Но улучшения эффективности не снижают спрос — они выявляют латентный спрос, который ранее было неэкономично удовлетворять. Уголь. Вычисления. Облачная инфраструктура. И теперь — интеллектуальный труд.

Паттерн настолько последователен, что бремя доказательства должно сместиться. Вместо того чтобы спрашивать «сократят ли ИИ-агенты потребность в людях, занимающихся интеллектуальным трудом?», нам следует спрашивать «какое увеличение на порядки объёма интеллектуального труда мы вот-вот увидим?»

Для разработчиков ПО это тот же переход, который мы успешно прошли уже несколько раз. Разработчики, которые процветали, не были теми, кто сопротивлялся более высокоуровневым абстракциям; это были те, кто использовал эти абстракции для построения более амбициозных систем. Та же логика применима сейчас, просто в большем масштабе.

Новый вопрос

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

Мы вот-вот узнаем, что происходит, когда стоимость интеллектуального труда падает на порядок. История предполагает, что мы (возможно) не будем делать меньше работы — мы обнаружим, что массово недоинвестировали в интеллектуальный труд, потому что было слишком дорого делать всё то, что на самом деле стоило делать.

Парадокс не в том, что эффективность создаёт изобилие. Парадокс в том, что мы продолжаем этому удивляться.

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot