Генеративный ИИ заметно изменил работу разработчиков. Создавать новый код стало проще и быстрее, чем когда-либо раньше. При этом потенциал генеративного ИИ в разработке уже подтверждается исследованиями. В ежегодном отчете McKinsey «The State of AI» разработка программного обеспечения названа одной из областей, где технология быстрее всего переходит от экспериментов к практическому применению. Именно поэтому сегодня внимание постепенно смещается от вопросов внедрения к вопросам долгосрочных последствий такого ускорения.
Но вместе с этим изменились и стимулы внутри разработки: во многих случаях написать новое решение оказывается проще, чем разобраться в существующем. Именно здесь начинает формироваться новый механизм накопления технического долга.
Проблема заключается не в качестве генерации кода. Современные модели уже доказали свою эффективность: они ускоряют разработку, помогают быстрее реализовывать новые функции и снимают с инженеров значительную часть рутинной работы. Изменения происходят глубже. Вместе с ростом производительности меняется сама экономика инженерных решений. Написать новый код стало проще, тогда как понимание архитектуры, рефакторинг и сопровождение сложных систем не стали дешевле. В результате создать новую реализацию все чаще оказывается проще, чем развивать существующую.
Рассмотрим, почему эта тенденция постепенно становится одним из ключевых факторов роста технического долга в эпоху генеративного ИИ.
Главный дефицит сместился
Долгое время одним из основных ограничений в разработке было создание кода. Генеративные модели существенно снизили стоимость этой работы. Сегодня многие задачи, которые раньше требовали значительных затрат времени, решаются за считанные минуты.
Но вместе с этим изменился сам характер дефицита. Если раньше главным ограничением было написание кода, то сегодня все большую ценность приобретают понимание системы, проектирование архитектуры, ревью решений и анализ зависимостей между компонентами. Проще говоря, дефицитным становится не код, а способность понимать, как устроен продукт в целом.
Это важное изменение. Потому что именно на уровне архитектуры принимаются решения, последствия которых определяют стоимость развития системы через несколько лет.
Изменилась экономика инженерных решений
Технический долг существовал всегда. Любой развивающийся продукт со временем накапливает компромиссы, временные решения и ограничения.
Однако раньше разработчик чаще выбирал между двумя одинаково сложными вариантами: переработать существующую логику или написать новую. Сегодня этот баланс нарушен.
Рефакторинг по-прежнему остается сложной задачей. Чтобы качественно изменить существующий механизм, необходимо понимать значительную часть системы, учитывать взаимосвязи между модулями и прогнозировать последствия изменений. Такие задачи требуют большого объема контекста и серьезного погружения в проект.
Создать новое локальное решение значительно проще. Если появляется очередное бизнес-требование, зачастую быстрее написать отдельную реализацию, чем разбираться в существующей архитектуре. В моменте это выглядит рационально. Задача закрыта, сроки соблюдены, система продолжает работать.
Именно поэтому технический долг редко возникает из-за плохих решений. Намного чаще он становится следствием решений, которые были логичны в конкретный момент времени.
Почему становится больше дублирующей логики
Эту тенденцию хорошо видно на крупных продуктах с большим количеством интеграций.
Представим систему, в которой уже существует единый механизм работы с сетевыми запросами. Он отвечает за обработку ошибок, сериализацию данных, кеширование, поддержку различных версий API и другие инфраструктурные задачи.
Затем появляется новый сценарий, который не укладывается в существующую логику. Архитектурно правильный путь — встроить его в уже работающий механизм. Но для этого необходимо разобраться в текущей реализации, оценить последствия изменений и убедиться, что они не затронут другие части системы.
Во многих случаях проще создать отдельное исключение. Один такой случай не создает проблем. Однако со временем исключений становится больше. Появляются несколько вариантов обработки похожих сценариев, дублируются отдельные механизмы, растет количество специальных правил.
Каждое решение по отдельности работает. Но общая сложность системы постепенно увеличивается.
Почему ИИ не устраняет технический долг
Существует мнение, что генеративный ИИ поможет справиться с накопленной сложностью за счет ускорения разработки. На практике чаще происходит обратное.
ИИ не заменяет инженерную дисциплину. Он усиливает существующие практики. Если команда системно занимается архитектурой, контролирует сложность продукта и регулярно инвестирует время в рефакторинг, новые инструменты позволяют делать это быстрее.
Если же проект развивается через постоянное накопление локальных решений, генеративный ИИ ускоряет и этот процесс. Во многом это связано с особенностями самих моделей. Для них локальная задача значительно проще, чем изменение архитектуры на уровне всей системы. Рефакторинг требует большого объема контекста. Необходимо учитывать связи между различными частями приложения и понимать последствия изменений за пределами конкретного модуля.
Кроме того, модель не может переиспользовать абстракцию, которую не видит в доступном контексте. Поэтому во многих случаях для нее безопаснее создать новую реализацию, чем менять существующую.
С инженерной точки зрения такая стратегия выглядит рационально. Но на длинной дистанции именно она становится одним из источников роста технического долга.
Когда технический долг начинает воспроизводить сам себя
На определенном этапе накопленная сложность начинает влиять на дальнейшие решения команды.
Чем больше в системе исключений, специальных правил и дублирующей логики, тем сложнее становится ее понимать. Чем сложнее система, тем дороже обходится рефакторинг. А чем дороже рефакторинг, тем чаще появляются новые локальные решения вместо архитектурных изменений.
Возникает замкнутый цикл, в котором технический долг начинает создавать условия для собственного дальнейшего роста. Сам по себе этот механизм существовал и раньше: чем сложнее становилась система, тем дороже обходились изменения и тем чаще команды принимали локальные компромиссные решения.
Генеративный ИИ делает эту петлю значительно сильнее. Модель работает с той кодовой базой, которая уже существует. Чем больше в ней дублирующей логики, специальных исключений и неоднородных решений, тем хуже она ориентируется в проекте и тем чаще предлагает еще один способ решить ту же задачу. В результате возникает новая обратная связь: качество последующих изменений начинает зависеть от качества уже накопленной кодовой базы. Если она становится все менее однородной, модель еще чаще воспроизводит локальные решения вместо развития существующей архитектуры. До появления генеративного ИИ такой обратной связи между состоянием системы и инструментом разработки фактически не существовало.
Как появляется магическое мышление
Самые серьезные последствия обычно становятся заметны спустя годы. Со временем в проекте появляются решения, происхождение которых уже никто не может объяснить. Новые разработчики воспринимают их как часть архитектуры. Старые участники команды помнят, что когда-то на это были причины, но не всегда могут восстановить их логику.
Постепенно возникает своего рода «магическое мышление». Команда уже не понимает, почему отдельные решения существуют и какие задачи они изначально решали, но менять их не решается. Логика архитектуры уступает место негласному правилу: «так тут принято и это как-то работает».
В этот момент технический долг перестает быть исключительно инженерной проблемой. Он начинает влиять на управляемость продукта, скорость его развития и безопасность кода. Чем больше в системе локальных исключений и дублирующей логики, тем сложнее анализировать последствия изменений, контролировать появление потенциальных уязвимостей и поддерживать единые требования к качеству разработки.
Какие метрики становятся важнее скорости
Распространение генеративного ИИ заставляет по-новому смотреть и на оценку эффективности разработки.
Количество написанного кода постепенно теряет смысл как показатель производительности. Схожий вывод делают и исследователи GitHub. В исследовании качества кода, созданного с помощью GitHub Copilot, авторы предлагают оценивать влияние ИИ не только через скорость разработки, но и через такие характеристики, как сопровождаемость, надежность и читаемость кода. Значительная часть этого объема может представлять собой будущий технический долг.
Поэтому все большее значение приобретают другие показатели:
- стоимость изменений;
- объем ресурсов на сопровождение;
- количество инцидентов после релизов;
- скорость адаптации новых разработчиков;
- способность команды безопасно развивать существующую архитектуру.
Именно такие метрики позволяют понять, становится ли продукт устойчивее или просто быстрее наращивает сложность. Не менее важно отслеживать, как изменения влияют на безопасность кода: увеличение числа локальных исключений и дублирующей логики постепенно усложняет аудит, сопровождение и поиск потенциальных уязвимостей.
Что в итоге
Генеративный ИИ не создает технический долг сам по себе. Он меняет условия, в которых принимаются инженерные решения. Создание нового кода становится дешевле. Понимание системы — нет.
Поэтому главный вызов ближайших лет связан не с качеством генерации как таковым. Намного важнее сохранить архитектурную дисциплину в условиях, когда написать новую реализацию зачастую проще, чем разобраться в существующей.
Чем активнее компании используют ИИ в разработке, тем большее значение будет иметь способность контролировать сложность систем. Именно она определит, станет ли ускорение разработки источником долгосрочного преимущества или приведет к накоплению проблем, которые придется решать уже следующим командам.
