ИИ — это усилитель, а не направление.

Автор статьи, источник: InfoQ

ИИ заставил вас писать код в 10 раз быстрее, а потом что? Больше кода означает более длительную компиляцию, более тяжелое тестирование, более забитые код-ревью и кодовую базу, которую никто не понимает. Программное обеспечение — это долг; чем быстрее вы пишете, тем больше вы должны.

Предупреждение старшего инженера-программиста Google Адама Бендера очень прямолинейно: способ, которым вы сегодня создаете программное обеспечение, не сработает при ускорении в 10 раз. Но настоящими победителями эпохи ИИ будут не самые продуктивные команды, а те, у кого самые прочные основы. Ведь ИИ лишь усиливает, но не определяет направление.

На ключевом выступлении Google I/O 2026 Адам Бендер задал вопрос, о котором большинство еще не успели подумать: когда ИИ ускорит производство кода до уровня, превышающего возможности существующих инженерных процессов, что в нашей экосистеме разработчиков сломается первым? Он объединил все выступление концепцией, которую, возможно, вы еще не слышали: программная экология — дисциплина, изучающая социотехническую экосистему производства программного обеспечения в целом. Другими словами, вам нужно смотреть не только на технологии, но и на людей, культуру и неформальные правила внутри организаций. На основе видео этого выступления InfoQ структурировал содержание.

Основные идеи следующие:

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

Что такое «система»

Ваша работа в 2026 году совершенно не похожа на то, что вы представляли себе в 2020 году. Если бы я попытался объяснить тому, кто я был в 2020 году, что происходит сегодня, он бы мне не поверил. Изменений слишком много, их трудно осознать. Я не могу предсказать будущее, но верю, что если внимательно изучить современную экосистему программного обеспечения, некоторые ответы ближе, чем мы думаем.

Сегодня я хочу поговорить с вами одним словом: программная экология (Software Ecology). Звучит так, будто я придумал это просто, чтобы выступить, но это не так — это настоящий термин. Прежде чем дать определение, я хочу немного подготовить почву и немного углубиться в системное мышление.

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

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

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

Экосистема также является сложной адаптивной системой, способной расти, изменяться и эволюционировать со временем. Они обладают свойством, называемым возникающим свойством (Emergent Property) — тем, что нельзя увидеть, наблюдая за любым отдельным компонентом; поведение проявляется только тогда, когда вся система собрана вместе. Именно это постоянное изменение, постоянное обучение и возникающие свойства делают крайне трудным понимание того, что именно происходит в экосистеме.

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

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

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

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

Экосистема разработчиков Google

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

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

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

Что касается технической стороны? Единый репозиторий кода, где почти весь код находится в одном репозитории; разработка на основе главной ветки, где каждое изменение сразу интегрируется в основную ветку; при сборке бинарного файла почти каждая строка кода компилируется из исходников; единая цепочка инструментов сборки, используемая всеми; глобальная платформа автоматизированного тестирования, где все тесты запускаются в одном месте, ежедневно выполняется миллиарды тестовых случаев; единый глобальный сигнал «последний зеленый», по которому я могу по простому внутреннему сайту сообщить вам статус любой сборки; единая вычислительная среда, благодаря чему ситуация «у меня на машине работает» практически невозможна; строго стандартизированные фреймворки для разработчиков и небольшой набор основных языков программирования.

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

Общая судьба

Если бы мне пришлось выбрать принцип, который постоянно тонко направляет нас, я бы выбрал «Общая судьба (Shared Fate)». Он описывает степень тесной взаимосвязи между экосистемой и её компонентами: в экосистеме с высокой общей судьбой один компонент может влиять на все остальные. В экосистеме разработчиков общая судьба — это как технический, так и социальный выбор. Вы не можете достичь общей судьбы только за счёт того, что все используют одни и те же технологии; вам также необходимо создать социальный контракт о том, как управлять этими технологиями.

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

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

Крупномасштабные изменения

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

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

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

Ваша экосистема, ваши компромиссы

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

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

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

Время 10-кратного leverage: каждый узел находится под давлением

Пришло время поговорить о слоне в комнате, который ест токены: как выглядит экосистема разработчиков, построенная с приоритетом на ИИ?

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

Задайте себе вопрос: насколько хорошо вы знаете свою экосистему разработчиков сегодня? Сможете ли вы полностью её нарисовать? Знаете ли вы, где находятся все компоненты — не только технические, но и социальные? Сможете ли вы перечислить, из чего состоит ваша экосистема? Насколько хорошо это понимают другие в вашей организации? Каковы её сильные и слабые стороны? Где находятся узкие места? Где есть ограничения, а где — свобода? Какие у вас есть варианты выбора? Какие возникающие свойства вы уже наблюдали? Возможно, самый важный вопрос: если ваша экосистема внезапно должна будет обрабатывать в 10–15 раз больше кода в течение следующих восемнадцати месяцев, вы знаете, что сломается первым?

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

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

Проблема в том, что сегодняшний способ разработки и доставки программного обеспечения не сработает при скорости в 10 или 100 раз выше — что-то должно измениться.

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

Код добавлен в репозиторий

Пишите исходный код. Если каждый будет писать код в десять раз быстрее, объём кода увеличится в десять раз — и это нехорошо. Джефф Атвуд говорил, что программное обеспечение — это долг. Поэтому десять раз больше кода — десять раз больше долга. И вы не можете просто раздать каждому токены и сказать: «Удачи». Я хочу, чтобы вы инвестировали после обучения: знаете ли вы, где находятся ваши документы по инженерным практикам? Знаете ли вы, как их развивать? Подумайте об этом потом.

Сборка системы. Больше кода, более крупные системы — значит, больше времени на компиляцию. Я уверен, что сейчас никто в вашей компании не жалуется на медленную компиляцию. Но угадайте что, они станут еще медленнее. И если агент управляет огромным объемом работы, количество компиляций также резко возрастает. Компиляция — это не бесплатно, ни по времени, ни по вычислительным ресурсам. Вы, возможно, никогда не замечали, сколько времени тратите на компиляцию, но при масштабе в 10 раз вы обязательно это заметите.

Дизайн кода. У вас есть подходящие навыки агента, чтобы поощрять декомпозицию? Есть ли подходящий серверный фреймворк, обеспечивающий быстрое и безопасное объединение различных возможностей? Знаете ли вы, сколько существует способов развертывания веб-приложений в вашей компании? Сколько различных серверных фреймворков используется? Как вы управляете повторным использованием компонентов кода, написанного агентом? Возможно, вы полагаете, что это не важно. Но если агент пишет код, который легко написать, но сложно поддерживать, не удивляйтесь — это текущий уровень стандарта. Агенты хорошо пишут код, но не всегда думают о долгосрочной перспективе. Этот код, я уверен, не будет легко рефакториться. Не беда, эту проблему мы решим в будущем. Но факт остается фактом: агенты выполняют для нас огромный объем работы, и нам каждый день нужно находить наиболее эффективные способы применения этих возможностей.

В какой-то момент эти агентные рабочие процессы могут сделать ваши бинарные файлы настолько большими, что их невозможно будет скомпилировать. Или настолько большими, что их невозможно будет загрузить на телефон. Вы когда-нибудь задавали себе этот вопрос: каков максимальный размер бинарного файла, который вы можете скомпилировать? Я не знаю ответа, но знаю, что в Google мы уже достигаем пределов — в некоторых местах бинарные файлы стали настолько большими, что их невозможно скомпилировать, и я уверен, что мы найдем решение. Но факт в том, что масштабирование имеет множество побочных эффектов — влияние масштаба повсюду.

Возможно, вы используете стек микросервисов и думаете: «Мои сервисы очень маленькие, зачем мне беспокоиться?» Но у меня есть вопрос: готовы ли вы к десятикратному росту сетевого трафика, десятикратному увеличению числа сервисов и десятикратному росту объема коммуникаций? Никто не сможет избежать последствий масштаба — его влияние повсюду.

Ревью кода. Предположим, вы не можете надежно скомпилировать весь этот код — как будет выглядеть ваш процесс ревью кода? Все беспокоятся о ревью кода, и это обоснованно. Мы оказываем огромное давление на этот крайне человеческий процесс, и во многих случаях он превращается в узкое место, а людям не нравится быть узким местом. Когда вы оказываете на них давление, их поведение становится странным. При увеличении объема кода в 10 раз вы получите либо изменения в 10 раз больше, либо в 10 раз больше изменений. Сможет ли ваш технический руководитель поддерживать необходимую скорость ревью? Большинство технических руководителей не могут даже просмотреть код, созданный пятью разработчиками, работающими в 10 раз быстрее, за один день.

Чтобы не стать узким местом, они начинают перестраивать процессы, искать обходные пути и гарантируют, что никто не застревает, потому что никто не хочет быть тем, кто вызывает задержки. Вы можете частично решить эту проблему с помощью ИИ — развернуть ИИ для улучшения код-ревью. Но это решает лишь часть проблемы, потому что если ваши сотрудники больше не пишут код, единственный момент, когда они сталкиваются с кодом — это при ревью, а внимания при ревью недостаточно. Тогда кто следит за эволюцией кодовой базы? Никто. Очень скоро ваша кодовая база превратится в непонятную кашу, которую никто не сможет разобрать.

Экономика токенов. Токены дорогие, и некоторые из вас это уже знают. В масштабе токены — это реальная стоимость, которую необходимо учитывать. Что произойдет, если каждый в компании начнет использовать токены в 10 или 100 раз больше? Что, если вы случайно потратите весь месячный бюджет за один день? Если вам придется приоритизировать, куда тратить токены, знаете ли вы, куда следует вкладываться в первую очередь? И вообще, есть ли у вас видимость того, куда именно токены движутся?

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

Тестирование и контроль версий

Вы когда-нибудь задумывались, сколько вычислительных ресурсов потребляет ваша тестовая инфраструктура? В Google я никогда не был доволен скоростью своих тестов.

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

На самом деле ситуация может быть еще хуже. Мы наблюдали в Google, что по мере роста кодовой базы граф зависимостей растет квадратично, а не линейно. Поэтому, если кодовая база увеличилась в 10 раз, вам может потребоваться запустить не в 10, а в 100 или даже 1000 раз больше тестов. Это будет очень интересный вызов, и в какой-то момент это превратится в строку в вашем бюджете. Если вы сейчас не беспокоитесь о расходах на вычислительные ресурсы для тестирования, это меня беспокоит больше всего, потому что это означает, что, возможно, у вас вообще недостаточно тестов, и агенты действуют в вашей кодовой базе без каких-либо гарантий безопасности.

Предположим, что проблемы с компиляцией и тестированием решены — теперь обратимся к системе управления версиями. Большинство популярных систем управления версиями не оптимизированы для производительности; они оптимизированы для согласованности и упорядоченности. Это их основная задача — поддерживать полную историю, а не работать с невероятной скоростью. Сколько коммитов ваша система управления версиями может обработать за минуту? Я гарантирую, что гораздо меньше, чем вы думаете. Она не масштабируется до скорости, в 10 раз превышающей вашу текущую потребность. Когда вы в последний раз задумывались о производительности системы управления версиями? Если вы не разрабатываете Git, то, скорее всего, никогда. Честно говоря, если вам пришлось дискутировать о производительности системы управления версиями, значит, что-то серьезно пошло не так. Мы находимся на самом нижнем уровне пользовательского опыта разработчика, но именно таковы последствия системных изменений: они находят каждый угол вашей системы и говорят: «Эй, ты заметил?» — потому что пришло то, чего вы не ожидали.

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

Список неожиданностей

До сих пор мы рассматривали только те относительно легко обнаруживаемые емкостные узлы, где берется число и умножается на 10, чтобы спросить, станет ли лучше или хуже, а также существует множество неожиданных вызовов.

Проверка стратегии. Сегодня ваша проверка, скорее всего, состоит из множества юнит-тестов и нескольких интеграционных тестов. Но в мире с в десять раз большим количеством кода и в десять раз большим количеством сервисов интеграционные тесты станут наиболее важной частью стратегии качества. Сколько из вас довольны своей сегодняшней схемой интеграционных тестов? Я тоже не доволен. Интеграционные тесты действительно сложны, и у меня пока нет инструментов, которые позволяли бы мне проводить их так, как я хочу.

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

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

Война агентов. Один агент вносит изменение, другой прибегает и говорит: «Нет, мне это не нравится, я внесу другое изменение». Это выглядит смешно, пока вы не осознаете, что платите токены за обе стороны.

Ритм выпуска. Сколько раз в день вы выпускаете обновления для клиентов? Каждый день? Это уже неплохо. Если нет, то вот проблема: вы получите в десять раз больше программного обеспечения, которое нужно куда-то разместить. Если вы не выпускаете обновления ежедневно, каждое изменение становится значительно крупнее. Мои друзья из SRE скажут вам, что очень крупные изменения — это ужасно. Не делайте так. Но код должен быть развернут, чтобы приносить ценность, поэтому вы можете попытаться выпускать чаще — это хорошо, и друзья из DORA будут довольны. Однако на каком-то этапе доходы начинают уменьшаться: выпуск раз в секунду, вероятно, не принесет вам особой выгоды. Код все равно будет расти, и вам нужно понять, где его размещать, чтобы не создавать дополнительных рисков.

Внутренний API. Я постоянно говорю своим коллегам: ваши все API внезапно стали публичными. Агент не будет спрашивать вашего разрешения — он найдет API и сразу же его вызовет. Он будет использовать всё, к чему имеет доступ, это гарантирую. Если вы никогда не защищали внутренние интерфейсы и внутренние наборы данных так, как защищаете публичные API, агент найдет то, что вы не хотели, чтобы он нашел.

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

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

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

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

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

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

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

Выглядит сложно, но вам действительно нужны только два вопроса: почему (Why?), и что, если (What if?). Почему у нас так мало интеграционных тестов? Что, если у нас будет больше интеграционных тестов, чем юнит-тестов? Почему мы используем именно эти языки? Что, если ИИ напишет весь код?

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

ИИ — это усилитель, а не направление

ИИ — это усилитель. Эта идея пришла от моих друзей из DORA, чей отчет об разработке ИИ за прошлый год выявил связь между командами, которые действительно разобрались в вопросе: они поняли, как превратить ИИ в усилитель.

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

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

Но даже при прочной базе мы вот-вот вступим в настоящее путешествие. Я предполагаю, что к 2030 году наша сегодняшняя экосистема разработчиков покажется нам столь же далекой, как 2001 год кажется нам сегодня. В 2001 году мы еще распространяли программное обеспечение через CD-ROM, а к 2030 году мы можем оказаться на таком же расстоянии.

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

Во-первых, мощность инфраструктуры. Если вы не знаете, сколько ресурсов у вас есть, вы не сможете развернуть ИИ или вычислительные ресурсы; вам нужен хороший способ отслеживания этих ресурсов.

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

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

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

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

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

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

Многие наши программные системы очень хрупки: одна плохая строка кода или неправильный флаг конфигурации могут сломать систему в миллион строк. Эта хрупкость заставляет вас тщательно взвешивать любые изменения. Но у меня есть очень захватывающая идея относительно ИИ: постоянно обновляемое, почти интерактивное архитектурное пространство, к которому я могу обращаться с вопросами. Что произойдет, если мы переместим эту емкость на восточное побережье? Что произойдет, если рост числа пользователей внезапно возрастет на 40%? Для даже средней системы сегодня это функционально почти невозможно — слишком много переменных. Но ИИ способен понимать огромные наборы данных, и я считаю, что здесь есть что-то, что стоит изучить.

Мне нравится этот вопрос, потому что мы не просто сосредоточены на том, чтобы заставить кодовые машины работать быстрее; мы задаемся вопросом: как углубить наше понимание того, что мы уже создали?

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

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

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

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

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