Software engineering at the tipping point

[МУЗЫКА ИГРАЕТ] АДАМ БЕНДЕР: Привет всем. Как дела? [АПЛОДИСМЕНТЫ] Привет, это неплохо! Это неплохо. 15:00 в среду, верно? Это среда — не так уж плохо. Добро пожаловать на курс «Разработка программного обеспечения на переломном этапе». Меня зовут Адам Бендер. И сегодня я собираюсь поговорить с вами о чем-то под названием «экология программного обеспечения», термине, который вы, возможно, раньше не слышали. Я хочу поговорить об этом, потому что это расскажет нам кое-что о влиянии ИИ на наши экосистемы разработчиков, экосистемы разработчиков, в которых вы работаете каждый день. Теперь я не знаю, заметили ли вы это. Но там становится довольно странно, верно? Ваша работа в 2026 году не похожа на то, какой вы ее представляли в 2020 году. Я вас уверяю. Если бы вы попытались объяснить мне, мне из 2020 года, что это будет, я бы вам не поверил. Может быть немного ошеломляющим пытаться понять, куда нас ведет все это изменение, верно? И хотя я не могу предсказать будущее, я думаю, что если мы изучим наши программные экосистемы такими, какие они есть сегодня, некоторые ответы, которые мы ищем, будут намного ближе, чем мы думаем. Я думаю, что экология программного обеспечения, эта идея, дает нам идеальный взгляд на этот конкретный момент в нашей отрасли. Теперь я слышу, как вы спрашиваете: что такое экология программного обеспечения? И не придумал ли он это только для того, чтобы выйти на сцену? Я не. Это реальный термин. Но прежде чем я определю его, я хочу дать вам некоторый контекст. Итак, мы немного углубимся в системное мышление. Надеюсь, вы не против. Потерпите меня. Обещаю, все станет понятно, когда мы доберемся до сути. Итак, начнем с понятия системы — системы. Это группа взаимосвязанных элементов, которые действуют по набору правил, чтобы сформировать единое целое. Это звучит довольно сложно. Но вы знаете системы. Они выглядят так. Это система, за которую вы, вероятно, сегодня очень благодарны. Это то, что такое кондиционирование воздуха, верно? У вас есть термостат, который знает, какая должна быть температура. У вас есть система ОВК, которая будет повышать или понижать температуру. И у вас есть комната. И когда температура правильная, сигнал прекращается. Это система. Если вы разработчик программного обеспечения, вы, вероятно, привыкли постоянно думать о системах. Вы их проектируете. Вы их строите. Вы ими управляете. Но одно, что вы, вероятно, узнали, работая с системами, это то, что все связано, все. Это тема, которую вы услышите от меня пару раз сегодня. Теперь перейдем к экосистеме, которая является особым видом системы. Это длинное. Так что потерпите меня. Экосистема — это динамичная сеть взаимозависимых акторов, которые совместно развиваются со своей средой, характеризующаяся эмерджентным поведением и децентрализованным управлением. Экосистемы сложны. Они построены из сложных компонентов. Сами компоненты глубоко связаны. У них есть агентство. Они могут принимать решения. Они могут делать вещи. И, что критически важно для нас, среда является частью этой системы. Среда является частью системы. Нельзя разделить эти два понятия. Таким образом, экосистемы также являются своего рода сложными адаптивными системами. Сложные адаптивные системы, или CAS, характеризуются своей способностью расти, меняться и развиваться с течением времени. Все крутые системы — это сложные адаптивные системы. Теперь сложные адаптивные системы также обладают этим качеством эмерджентности. Эмерджентное свойство — это то, что вы не можете увидеть, глядя на любую отдельную часть системы. Вы можете увидеть это только тогда, когда система собрана целиком. И тогда вы видите, как из нее возникает поведение. И именно это постоянное изменение, это обучение, плюс эмерджентность делают очень трудным понимание того, что происходит в экосистеме. Теперь, когда вы думаете об экосистемах, или, по крайней мере, когда вы думали о них до того, как вошли сюда, это, вероятно, то, что вы имели в виду. И, честно говоря, я бы хотел быть здесь прямо сейчас, верно? Выглядит довольно идиллической. Но ваша внутренняя среда разработки также является своего рода экосистемой. У вас есть все ваши инструменты и сервисы. У вас есть сложные акторы. У вас есть люди с мнениями и делами, которые они хотят сделать. У вас есть бизнес-ограничения. Это тоже система. И на самом деле, это особый вид системы. Это социально-техническая система. Социально-техническая система — это просто модный способ сказать система, состоящая из людей и технологий. Теперь социально-технические системы невероятно сложны. Они сложны, потому что вы начинаете со всей этой технологии. А затем вы смешиваете людей. Есть довольно хороший шанс, что вы столкнулись с некоторой мудростью о социально-технических системах, даже не осознавая этого. Кто-нибудь из вас слышал о законе Конвея? Да, конечно. Все слышали о законе Конвея. Но вкратце, закон Конвея гласит следующее. Организации создают технологии, которые отражают их внутренние коммуникационные структуры. Или неформально, если у вас есть группа из четырех человек, работающая над компилятором, вы получите четырехпроходный компилятор. Так оно и работает. Теперь, по сути, закон Конвея — это наблюдение, что способ, которым мы создаем технологии, неотделим от структуры организаций, которые их создают. Организации формируют то, что строится. Теперь, конечно, не только организационная структура влияет на наши экосистемы разработчиков. Ценности и культура организации могут иметь столь же глубокое влияние. Ваша экосистема создает то, что ваша организация стимулирует, ваша инженерная культура создает среду вокруг вашей экосистемы разработчиков. Видите ли, дело в том, что как только вы узнаете о социально-технических системах, вы увидите их повсюду в разработке программного обеспечения, от ваших архитектур до вашей культуры постмортемов, до обзора кода, до политики безопасности. Они повсюду. То, что мы строим, и то, как мы выбираем это строить, является отражением того, что мы ценим. Если мы будем вдумчивы, мы можем использовать эти знания, чтобы усилить наши ценности и воплотить их в то, что мы строим, улучшая те результаты, которые мы хотим. Теперь я думаю, что могу правильно определить для вас экологию программного обеспечения. Экология программного обеспечения — это холистическое изучение социально-технических экосистем, которые производят программное обеспечение. Хорошо. Теперь мы все в курсе. Ничего страшного, если все это показалось немного абстрактным, кстати, потому что теперь мы посмотрим на реальный пример. Мы поговорим об экосистеме разработчиков Google. У Google очень большая, и, я бы сказал, несколько сложная экосистема разработчиков, потому что за последние 25 лет мы развили поистине замечательные возможности и, да, некоторую сложность. Теперь, в качестве предварительного отказа от ответственности, я говорю о Google, отчасти потому, что я там работаю. Но это экосистема разработчиков, которую я понимаю лучше всего. Мое намерение здесь не в том, чтобы сказать вам, что вы должны делать то, что сделал Google. Это не будет хорошо для вас. Вы другая компания. Вы находитесь в другом месте. У вас другой набор компромиссов, о которых вы беспокоитесь. Теперь, как и любая инженерная организация, Google принял множество решений. Они были очень специфичны для потребностей, которые у нас были в то время, когда мы строили нашу экосистему. Ваша ситуация другая. Так что несколько лет назад мы написали книгу. Может быть, кто-то из вас видел эту книгу раньше? Внутри мы называем ее «Книга фламинго». Мы написали эту книгу, чтобы дать людям представление о том, как Google на самом деле работает изнутри. И мы потратили половину этой книги, говоря о таких вещах, как контроль версий и тестирование. Но вся первая половина этой книги была посвящена инженерной культуре. И мы получали много вопросов об этом. Почему так много об инженерной культуре? Ну, реальность такова, что если вы не поймете культуру Google, вы не сможете оценить, почему мы приняли те технические решения, которые мы приняли. Эти вещи взаимосвязаны. Теперь, если вы не читали книгу, я проведу краткий тур. Не волнуйтесь. Вам не нужно все это читать. Да, фотографируйте. Это будет нормально. Есть несколько вещей о Google, которые делают его несколько уникальным. Например, мы глубоко ориентированы на инженерию. Инженеры всегда присутствуют при принятии важных решений. Мы уделяем большое внимание прозрачности. Мы стараемся сделать всю документацию и код, которые мы можем, доступными как можно чаще. Мы поощряем людей быть полезными. На самом деле, если вы поговорите с кем-нибудь, кто когда-либо уходил из Google, полезность их коллег будет одним из самых важных факторов, которые они упомянут. Мы относимся к обзору кода как к возможности для наставничества, а не для оценки тестов. Мы уделяем большое внимание стандартизации, очень большое. Мы верим в постоянное совершенствование. Мы уделяем большое внимание безвиновным постмортемам. Мы придерживаемся идеи, что устойчивость лучше героизма, а автоматизация лучше рутины. Теперь мы не всегда достигаем всех этих идеалов. Но это своего рода то, к чему мы стремимся культурно. А с технической стороны у нас есть наш монолитный репозиторий, о котором вы, вероятно, читали. Я расскажу вам об этом подробнее через секунду. У нас есть разработка на основе trunk, где каждое изменение попадает в head каждый раз. Когда вы собираете двоичный файл в Google, почти каждая строка кода собирается из исходного кода. Это довольно дико, правда? У нас есть универсальная цепочка инструментов сборки. Все ее используют. У нас есть глобальная платформа автоматизации тестирования. Одно место запускает все тесты, миллиарды тестов в день. У нас есть глобальный сигнал для последнего зеленого. Я могу сообщить вам состояние любой сборки, посмотрев на один простой внутренний веб-сайт. У нас есть унифицированная вычислительная среда. Так что «работает на моей машине» невозможно, в основном. У нас есть предвзятые фреймворки для разработчиков и небольшой набор основных языков. И именно это сочетание культуры и технологий порождает то, что такое Google. Вы не можете понять одну половину без другой. Теперь, если бы мне пришлось выбрать один принцип, один принцип, который, кажется, направлял нас неявно, если не явно временами, это то, что называется «общая судьба». Теперь «общая судьба» — это термин, описывающий степень, в которой экосистема и ее компоненты тесно связаны друг с другом. В экосистеме с высокой общей судьбой один компонент может повлиять на все остальное, верно? Теперь в экосистеме разработчиков «общая судьба» — это такой же технический выбор, как и социальный. Вы не можете просто получить «общую судьбу», заставив всех использовать одну и ту же технологию. Вы также должны разработать социальные контракты о том, как вы собираетесь управлять этой технологией. Теперь в Google наша «общая судьба» начинается с нашего монолитного репозитория. Каждая строка кода в Google, за несколькими заметными исключениями, такими как Android и Chrome, находится в одном общем репозитории, все. Все зафиксировано в trunk. Нет ветвей. Нет версий — все в одном месте. Такая «общая судьба» позволяет нам применять исправление безопасности в одном файле и знать, что в течение недели каждое приложение в компании будет исправлено. Это как суперсила, верно? 10 строк кода в нужном месте могут исправить 10 миллиардов строк прикладного и системного программного обеспечения. Это довольно впечатляет, правда? Теперь «общая судьба» не всегда является хорошей вещью. «Общая судьба» — это выбор. Есть места, где «общая судьба» может иметь меньший смысл. Например, в нашей производственной среде мы не хотим, чтобы одна служба выводила из строя все остальные службы или чтобы один кластер заражал целый регион. Поэтому мы очень усердно работали. Google, в частности, очень усердно работал, чтобы убедиться, что у нас нет опасных видов «общей судьбы», которые вызывают такие вещи, как каскадные сбои. Опять же, суть в том, что «общая судьба» — это компромисс. Вам нужно выяснить, где ее разместить, а затем убедиться, что она работает для вас. Теперь одним из самых интересных эмерджентных свойств нашей среды «общей судьбы» является это понятие крупномасштабных изменений. Теперь задолго до ИИ, задолго до ИИ, внутренние инструменты Google сделали возможным для одного разработчика изменить буквально миллионы строк кода — миллионы строк кода, которые он никогда не увидит. Они никогда больше не увидят. Они могут ничего об этом не знать. Мы создали инструменты, которые делают это автоматически возможным сегодня. И мы делаем это так по крайней мере последние 15 лет. Такая возможность позволила нам развивать наш монорепозиторий с течением времени. Мы можем обновлять языки и фреймворки. Это действительно то, что не дает нашей внутренней среде стать застойной. Не будет преувеличением сказать, что без этого мы бы не были тем Google, которым являемся сегодня. И люди, которые работают над этими инструментами, скажут вам. Это работа невоспетых героев, чтобы компания двигалась с необходимой скоростью. Дело в том, что крупномасштабные изменения нельзя оценить, если вы не понимаете культурные компоненты и технические части нашей экосистемы, которые делают это возможным. Например, вам нужна широко распространенная культура тестирования. Каждый должен писать тесты, чтобы я мог это сделать. Нам нужна единая платформа, чтобы я знал, где искать результаты этих тестов, верно? Хорошо иметь общие инструменты сборки, чтобы мы все собирали одно и то же программное обеспечение. Я собираю. Ты собираешь. Мы получаем один и тот же результат. Нам нужен стандартный набор библиотек. Так что, когда мы что-то меняем, мы не прыгаем, пытаясь найти, какая версия этой библиотеки работает для вас, а не для меня. Нам нужен стандартизированный обзор кода. Нам нужна прозрачность в самом монорепозитории, чтобы я знал, какой код нужно изменить. LSC — это действительно высшее проявление этого принципа «автоматизация вместо рутины» в Google. И это возможно только благодаря всей экосистеме. Вы не можете указать на одну часть нашей среды разработчиков и сказать: вот почему происходят LSC. Это все связано. Теперь каждая экосистема разработчиков, ваша, любая, в которой вы когда-либо работали, имеет эти эмерджентные свойства. Обычно это то, что кажется несколько уникальным для места, где вы работаете. И это потому, что они обычно являются результатом созвездия выборов, которые вы сделали, чтобы сформировать то, как вы хотите работать. Так что у каждой экосистемы есть что-то подобное. У Google есть крупномасштабные изменения. У вас есть что-то другое. Экосистема разработчиков Google, встроенная в нашу специфическую инженерную культуру, породила уникальный набор компромиссов. Они служат нашим техническим и бизнес-целям. Однако экосистема Google, как и любая экосистема, не может преуспеть во всех задачах. Мы решили оптимизировать для экстремального масштаба, безопасности, производительности, верно? И мы обычно делаем это, даже если это иногда происходит за счет продуктивности разработчиков. Это компромисс, на который мы готовы пойти в нашей экосистеме. Экосистема разработчиков других мест, скажем, стартапа из пяти человек, будет выглядеть иначе. И это нормально. В стартапе из пяти человек скорость и гибкость — это самое важное, что вы можете иметь. Где-то между стартапом из пяти человек и Google — это там, где вы находитесь, верно? Большинство из вас обитает в экосистеме, которая находится где-то между пятью людьми и 200 000. Компромиссы, которые вы будете делать, действительно важны, чтобы обратить на них внимание, потому что, когда вы смотрите на принимаемые компромиссы, вы можете начать понимать ценности организации. Что она действительно ценит? Не то, что она говорит, что ценит, а то, что ваша организация действительно ценит? И когда вы поймете эти ценности, вы сможете начать формировать трансформацию по мере ее развертывания. Мы все сейчас переживаем много трансформаций. Так что было бы хорошо понять, куда мы идем. Надеюсь, к этому моменту концепция экосистемы программного обеспечения стала немного яснее. И я думаю, пришло время поговорить о слоне в комнате, который ест токены. Как выглядит экосистема разработчиков, ориентированная на ИИ? Теперь было бы неплохо построить одну из них с нуля, экосистему с нуля. Но я бы поспорил, что ни у кого из вас нет такой роскоши, верно? Вы все должны продолжать выпускать программное обеспечение, делать то, что вы делаете сегодня, заменяя буквально каждую его часть. Ничего страшного, верно? Ваша компания зависит от вас, чтобы продолжать предоставлять ценность и гарантировать, что ничего не сломается. Итак, чтобы убедиться, что ничего не сломается, позвольте мне задать вам вопрос. Насколько хорошо вы понимаете свою экосистему разработчиков сегодня? Можете ли вы ее всю отобразить? Знаете ли вы, где находятся все части, не только технические, но и социальные? Можете ли вы перечислить, из чего на самом деле построена ваша экосистема? Насколько хорошо ее понимают другие в вашей организации? Каковы ее сильные или слабые стороны? Где ваши узкие места? Где вы ограничены или где вы свободны? Какую опциональность вы имеете? Какие эмерджентные свойства вы видели в своих собственных экосистемах? И, возможно, самое главное, если бы ваша экосистема внезапно должна была вырасти, я не знаю, в 10-15 раз за следующие 18 месяцев, знаете ли вы, что сломается первым? Видите ли, дело в том, что на последний вопрос нам всем придется ответить очень быстро, потому что каждая экосистема разработчиков на Земле переживает радикальную трансформацию. Возможно, она еще не добралась до вас. Но она идет. Каждая экосистема разработчиков будет вынуждена бороться с этой идеей 10-кратного момента. Я хотел бы сказать вам, что есть выход. Но это неизбежно. Это невероятные времена. Но они также несколько запутанны. Все компромиссы, которые мы сознательно развивали за последние 25 лет, будут перебалансированы. Вы, вероятно, слышали это от каждого выступающего здесь в той или иной форме. Мы еще не знаем, каким будет будущее. Мы пытаемся это выяснить. Некоторые люди предсказывают продуктивность, которая выглядит как 10-кратная, 100-кратная. Мы измеряем вещи в порядках величины. Это много. Внезапно вопрос 10-кратного роста — это не просто мыслительное упражнение. Это как момент «красного кода» для вас и вашей компании. Вам придется разобраться в этом, если не сегодня, то уж точно в ближайшие 12 месяцев. Теперь, прежде чем я продолжу, я действительно хочу подчеркнуть, что я понимаю, есть большая разница между генерацией кода в 10 раз быстрее и инженерией в 10 раз быстрее. Это разные вещи. И на самом деле, в Google мы часто говорим, что инженерия — это программирование, интегрированное во времени. Но дело в том, что мы значительно ускоряем программирование. Мы делаем так, чтобы машина кода работала быстро. Поэтому нам придется выяснить, как мы будем проектировать вокруг этой машины кода, чтобы предоставлять реальные результаты нашим клиентам. Никто пока не знает, насколько далеко мы можем продвинуть этот рост продуктивности. Я действительно не знаю. Мы можем остановиться на следующей неделе. Я так не думаю. Но одно можно сказать наверняка. Мы будем расти. Проблема в том, что, я думаю, нам предстоит много работы, потому что я бы поставил очень хорошие деньги на то, что то, что мы делаем сегодня, не сработает при 10-кратном увеличении. Я бы поспорил, что способ, которым вы создаете программное обеспечение, способ, которым я выпускаю программное обеспечение, не работает при 10- или 100-кратной скорости. Что-то придется изменить. Ну, давайте начнем с рассмотрения стандартной экосистемы разработчиков. Она упрощена. Я знаю. Надеюсь, вы узнаете некоторые из этих терминов. Но позвольте мне представить их в форме, к которой вы привыкли видеть, сложный граф, верно? В мире с 10-кратным увеличением продуктивности, или, скорее, 10-кратной активностью, что должно измениться? Ну, давайте начнем с узлов, связанных с внесением кода в кодовую базу. Примечательно, что я исключил тестирование и контроль версий. Мы вернемся к ним через секунду. Что произойдет, если зеленые узлы внезапно должны будут делать в 10 раз больше работы? Ну, давайте начнем с написания исходного кода. Если все станут намного быстрее писать код, его, вероятно, будет намного больше, верно? Это нехорошо. Теперь кажется очень хорошим временем напомнить вам старую цитату Джеффа Этвуда. Программное обеспечение — это обязательство. Так что сразу же, в 10 раз больше кода, в 10 раз больше обязательств. Мы не в хорошем положении. Кстати, вы, вероятно, заметили, что вы не можете просто дать каждому кучу токенов и сказать: удачи. Так что я надеюсь, что вы инвестируете в переобучение. Вы инвестируете в переобучение, верно? Знаете ли вы, где задокументированы все ваши инженерные практики? Смогли бы вы их развить, если бы пришлось? Хорошо. Ну, есть над чем подумать, когда вы вернетесь домой. Давайте быстро перейдем к системе сборки. Как минимум, больше кода будет означать больше времени компиляции. Большая система, больше времени компиляции, как раз то, что нам было нужно. Я уверен, что никто в вашей компании никогда не жаловался на медленные компиляции. Ну, угадайте что? Они станут медленнее. И если агенты управляют большим объемом работы, это означает больше компиляций — так что не только больше, но и больше. Компиляция не бесплатна, ни по времени, ни по вычислениям. И возможно, вы никогда не замечали, сколько времени вы тратите на компиляцию. Но я могу заверить вас, что при 10-кратном увеличении вы что-то заметите. А как насчет дизайна всего этого кода? Есть ли у вас правильные агентские навыки для поощрения разделения? А как насчет правильных серверных фреймворков, чтобы гарантировать, что вы можете быстро и безопасно комбинировать возможности? Если подумать, знаете ли вы, сколькими способами в вашей компании сегодня обслуживаются веб-приложения? Знаете ли вы, сколько разных серверных фреймворков на самом деле работает? Я, на самом деле, не знаю. Как вы собираетесь управлять повторным использованием компонентов, если агенты пишут весь этот код? Может быть, вы ставите на то, что это не будет иметь значения. Не удивляйтесь, однако, если агенты напишут код, который легко написать, но трудно вам поддерживать. Похоже, это сейчас эталон. Агенты хороши в написании кода. Но они не всегда думают о долгосрочной перспективе так, как мы с вами. Этот код, я уверен, не будет хорошо структурирован. Это нормально. Мы разберемся с этой частью. Но правда в том, что агенты делают для нас много работы сейчас. И нам придется выяснить, как мы будем применять это наиболее эффективно, каждый день. В какой-то момент вся эта агентская работа может сделать ваш двоичный файл настолько большим, что вы больше не сможете его компилировать. Или, возможно, они станут настолько большими, что вы больше не сможете отправлять их на телефоны. Вы когда-нибудь задавались вопросом, какой самый большой двоичный файл вы можете скомпилировать? Я на самом деле не знаю ответа. Но я знаю, что мы сталкиваемся с ограничениями в Google. Мы делаем наши двоичные файлы настолько большими в некоторых местах, что мы больше не можем их компилировать. Мы разберемся. Я в этом уверен. Но правда в том, что большой имеет много последствий. Масштаб влияет везде. Теперь, возможно, вы больше ориентированы на микросервисы. И вы смотрите на меня и говорите: зачем мне когда-либо строить такую большую службу? Все мои службы крошечные. Это здорово для вас, за исключением того, что теперь у меня есть вопрос. Что произойдет с 10-кратным увеличением сетевого трафика, 10-кратным увеличением количества служб, 10-кратным увеличением количества разговоров, 10-кратным увеличением сетевого трафика? Вы готовы к этому? Никто не выходит из этого невредимым. Масштаб влияет везде. Теперь давайте предположим, что вы не можете надежно компилировать весь этот код. Я уверен, что не можете, верно? Что произойдет с вашим процессом обзора кода? Все сейчас беспокоятся об обзоре кода. И я думаю, что это по уважительной причине. Мы оказываем большое давление на этот очень человеческий процесс. И во многих случаях он становится узким местом. И я знаю одно о людях: они не любят быть узкими местами. Они ведут себя странно, когда вы оказываете на них давление. С 10-кратным увеличением кода вы получите одно из двух: либо изменения в 10 раз больше, либо их в 10 раз больше. Так что это значит для ваших рецензентов кода? Ну, я готов поспорить, что большинство ваших технических руководителей не смогут поддерживать скорость обзора, необходимую для того, чтобы увидеть, я не знаю, даже пять из этих 10-кратных разработчиков в течение дня. Это большая работа. Так что они сделают, чтобы не стать узким местом, это начнут перестраивать свой процесс. Они начнут срезать углы, чтобы убедиться, что они никого не блокируют, потому что никто не хочет быть блокирующим. Теперь вы можете решить часть этого с помощью ИИ. Я вам это даю. Вы можете развернуть ИИ, чтобы улучшить процесс обзора. Хорошо. Но это решает только часть вашей проблемы, потому что если люди в вашей команде не пишут код, то единственное время, когда они с ним сталкиваются, — это во время обзора. Но они не уделяют столько внимания во время обзора. Это то, что мы только что сказали. Так кто же следит за кодовой базой по мере ее развития? Ну, никто. Довольно скоро ваша кодовая база станет беспорядком, который никто не сможет понять. Теперь, помимо всего этого исходного кода, мы должны думать об управлении токенами, потому что токены дороги, как, вероятно, знают некоторые из вас. В масштабе токены — это реальная стоимость, которую мы должны учитывать. Что произойдет, если каждый в вашей компании начнет использовать в 10 раз больше токенов или в 100 раз больше токенов? Или что, если вы случайно потратите свой месячный бюджет за день, что случилось с моим другом. Если бы вам пришлось расставить приоритеты, куда бы вы потратили эти деньги, вы знаете, куда бы вы их потратили? Есть ли у вас вообще видимость, чтобы знать, куда идут токены прямо сейчас? Видите ли, даже в первых нескольких узлах этой системы, этой простой системы, мы уже находим проблемы. И совершенно ясно, что будут некоторые сложные второстепенные последствия. Теперь перейдем к тестированию и контролю версий. Они немного особенные. Вы когда-нибудь смотрели, сколько вычислений занимает ваша тестовая инфраструктура? Я не знаю, как вы. Но в Google у меня никогда не бывает достаточно быстрых тестов. Я никогда не говорил: «Боже мой, мои тесты проходят быстрее, чем мне нужно сегодня». У меня и так недостаточно мощности. Каждое изменение, которое попадает в контроль версий, должно быть протестировано. Но также агентам нравится запускать тесты, потому что это говорит им, хорошо ли они работают. Так что снова агенты делают дополнительную работу. И у меня больше работы. Так с 10-кратным увеличением коммитов и агентами, выполняющими всю эту работу, сколько тестовых вычислений вы используете сейчас? На самом деле, оказывается, может быть и хуже, потому что мы видели в Google, что по мере роста вашей кодовой базы ваш граф зависимостей растет квадратично, а не линейно, с размером вашей кодовой базы. Так что, если ваша кодовая база в 10 раз больше, и вы пытаетесь протестировать все зависимости, чтобы убедиться, что ничего не сломается, у вас может быть до 100 раз больше тестов. Может быть, 1000 раз больше тестов. Это будет очень интересная задача. И это будет статья в вашем бюджете в какой-то момент. Это то, о чем вам следует подумать. Так что теперь вы не просто запускаете тесты чаще. Они могут быть в 100 раз больше. И, честно говоря, если они не станут такими большими, если вы не беспокоитесь о том, сколько тестовых вычислений вы тратите, я больше беспокоюсь, потому что это означает, что у вас, вероятно, недостаточно тестов. И эти агенты YOLO по всей вашей кодовой базе, не имея возможности узнать, что работает, хорошо? Теперь давайте предположим, что вы разобрались. Вы решили проблему компиляции. Вы решили проблему тестирования. Давайте поговорим о вашей системе контроля версий. Большинство популярных систем контроля версий не оптимизированы для производительности, совсем нет. Они оптимизированы для согласованности, порядка. Это их работа. Их работа — вести полный учет, а не работать очень быстро. Какова производительность вашей системы контроля версий? Сколько коммитов она может обрабатывать в минуту? Я уверяю вас, это меньше, чем вы думаете. Она не будет масштабироваться до 10-кратной скорости, которая вам нужна. Когда вы в последний раз думали о производительности вашей системы контроля версий, когда-либо? Только если вы не работаете над Git, верно? Честно говоря, если мы говорим о производительности контроля версий, что-то пошло ужасно не так. Мы в глубинах опыта разработчика, в глубинах. Но именно так происходит, когда вы видите системные изменения. Системные изменения находят каждый уголок вашей системы и говорят: «Эй, ты обращаешь внимание?» Потому что вот что-то, чего вы не ожидали. И, кстати, для тех из вас, кто думает, что решит эту проблему контроля версий с помощью множества маленьких репозиториев, у меня для вас новости. Поговорите с кем-нибудь, кто использовал эту стратегию, у кого сотни или тысячи маленьких репозиториев. И я могу заверить вас, что это просто совершенно новый набор проблем, ни одна из которых ИИ не обязательно не сделает проще для вас. Пока что мы столкнулись с проблемами в каждом узле, который мы рассмотрели. И, верите или нет, мы рассмотрели только относительно легко находимые узлы емкости. Это все вещи, которые вы могли просто найти. Вы просто берете число, умножаете его на 10 и спрашиваете, будет ли это хорошо или плохо? Есть много других неожиданных проблем. Так что мы пройдемся по очень быстрому списку некоторых вещей, о которых, я думаю, вам стоит беспокоиться. Итак, во-первых, валидация помимо ваших вычислений. Стратегия валидации, которую вы используете сегодня, вероятно, похожа на множество модульных тестов и, возможно, некоторые интеграционные тесты. Но с 10-кратным увеличением кода и 10-кратным увеличением количества служб интеграционные тесты станут самой важной частью вашей стратегии качества. Сколько из вас довольны своей настройкой интеграционного тестирования сегодня? Я отмечу для прямой трансляции, что ни одна рука не поднята. Хорошо, хорошо. Это то, что я думал. Я тоже не доволен. Интеграционное тестирование очень сложно. И у меня нет инструментов, чтобы делать это так, как я хотел бы сейчас. Затем у вас есть эта проблема, которую я называю «сочетание булевых значений». Чтобы выпустить программное обеспечение сегодня, вы требуете, чтобы все тесты прошли. Все булевы значения становятся зелеными. Все хорошо, прежде чем вы отправите. Это разумно. Что произойдет, когда у вас будет миллион тестов? И реальная надежность базовой тестовой инфраструктуры для запуска миллиона тестов находится под вопросом. Возможно, будет невозможно выпустить программное обеспечение, где каждое булево значение должно быть истинным. Так что теперь вам понадобится новая стратегия, вероятно, что-то статистическое, чтобы выяснить, какие тесты запускать? Потому что я не могу запустить все. Хорошо. А как насчет сверхбольших изменений? Очень интересно, что мы можем рефакторить и менять языки и фреймворки повсюду. Каждый может это сделать. Есть ли у вас рабочие процессы или социальные контракты, позволяющие людям управлять конфликтами слияния, которые измеряются десятками тысяч строк, сотнями тысяч строк, миллионами строк? Вероятно, нет. Так что нам нужно будет выяснить, как мы будем создавать рабочие процессы, которые поддерживают перемещение очень больших наборов изменений друг мимо друга? Если каждый в компании может это сделать, нам понадобится новая стратегия. И, кстати, вы когда-нибудь видели вой правок, вызванный агентами, где один агент вносит изменение. А затем приходит другой агент и говорит: нет, мне не нравится это изменение. Давайте внесем другое изменение. Теперь за этим забавно наблюдать, пока вы не поймете, что вы платите за токены с обеих сторон, верно? Давайте перейдем к выпуску. Сколько раз вы выпускаете своим клиентам сегодня, ежедневно? Если вы делаете это ежедневно, вы делаете довольно хорошо. Если нет, вот вам проблема. Вы получите в 10 раз больше программного обеспечения. И это программное обеспечение должно куда-то попасть. И если вы не выпускаете ежедневно, я полагаю, что каждое изменение теперь станет намного больше. И если есть одна вещь, которую мне скажут мои друзья из SRE, так это то, что очень большие изменения очень пугают. Давайте не будем этого делать. Но код должен куда-то попасть. Его нужно развернуть, чтобы он был ценным. Так что одно, что вы, вероятно, попытаетесь сделать, это выпускать чаще. И это хорошо. Наши друзья из DORA были бы горды. Они бы сказали: «Да, пожалуйста, выпускайте больше». Но в какой-то момент вы достигнете убывающей отдачи. Выпуск каждую секунду, вероятно, не принесет вам большой пользы. Так что где-то между выпуском каждую секунду и я еще не совсем достиг выпуска в день — это правильный баланс. Но все же код будет расти. И нам нужно будет выяснить, куда мы поместим этот код, чтобы не создавать больше риска. А как насчет ваших внутренних API? Мы говорили о создании программного обеспечения. Но как насчет внутренней среды разработчиков со всеми API и данными? Я говорю своим друзьям, с которыми работаю: все ваши API внезапно стали общедоступными. Им нужна та же степень защиты, которую вы бы применили к чему-либо, что вы собираетесь отправить в общедоступный Интернет. Почему? Потому что агенты не будут с вами договариваться. Они найдут API. Они начнут его вызывать. И если они смогут получить доступ к вашим данным, они это сделают. Я гарантирую. Если агент может получить доступ к набору данных, он доступен им. Так что, если вы не вложили ту же мысль в свои внутренние наборы данных и внутренние API, вы столкнетесь с очень интересными проблемами, потому что агенты найдут то, чего вы, вероятно, не хотели бы, чтобы они нашли. Ну, как насчет парадокса Джевонса? Это слово, которое мы все узнали за последние, вероятно, 12 месяцев. Никто не знал, что это такое или даже как это произнести. Но теперь мы все знаем о Джевонсе. Джевонс говорит, что чем дешевле и эффективнее становится ресурс, тем больше мы его используем. И, боже мой, вы видите это с токенами. Мы помещаем их повсюду. И это меняет то, как мы работаем и как мы думаем о том, как мы работаем. Мы теперь оптимизируем — или не оптимизируем. Мы накладываем стоимость на ранее скрытую работу по повышению продуктивности, которая раньше была невидимой. Так что же это даст нам в поведении? Я пока не знаю. Кстати, вам нужно быть осторожными, куда вы помещаете эти движки токенов. Если вы установите нагруженные движки токенов, могут произойти странные вещи. Например, что, если ваш процесс отката зависит от того, будет ли у агента достаточно мощности? Если кто-то исчерпал бюджет токенов этого агента, и теперь вы не можете откатить, это, вероятно, плохо. И говоря об отмене, вы знаете, почему отмены работают сегодня, в основном? Это потому, что вы выпускаете программное обеспечение немного медленнее, чем требуется для обнаружения проблемы в производстве. Если вы можете выпускать программное обеспечение очень, очень быстро, быстрее, чем вы можете обнаружить что-либо не так, что это значит для вашей позиции отката? Каждый откат теперь должен будет бороться с множеством конфликтующих изменений, приходящих поверх него. Так что недостаточно просто выпускать быстрее. Мы должны учитывать всю систему, в том числе откат. Это действительно важный предохранительный клапан. А как насчет идеи, что каждый — строитель? Это была большая конференция, посвященная чествованию идеи, что каждый — строитель. И я думаю, это круто. Демократизация инженерии — это круто, пока вы не поймете, что вы демократизировали инженерию. Вы знаете этот инструмент, который вам не нравится, который вы хотели бы заменить в своей компании? Мне все равно, что это. И я не буду называть имен здесь. Но я уверен, что есть инструмент, для которого вы просто хотели бы, чтобы я мог написать замену. Хорошо. Умножьте это на каждого в вашей компании для каждого инструмента, который они используют. Что происходит с социальной тканью вашей компании, когда все используют совершенно разные инструменты? Теперь, если вам повезет, у вас будет общий субстрат данных. Это хорошо. Тогда все данные поступают в одно и то же место. Но что, если нет? Каждый — строитель — это круто, пока вам не придется поддерживать все, что построили все. И давайте подумаем о скоростном прохождении технического руководства, которое мы устроим для всех наших младших разработчиков. Причина, по которой так долго становится руководителем, заключается в том, что вам нужно развивать интуицию, суждение и опыт, чтобы помочь вам принимать решения, потому что, когда вы руководите командой, радиус поражения намного больше, чем когда вы просто делаете это сами. Когда новый выпускник попадает в среду, где у него есть 50 агентов в его распоряжении, но нет интуиции и нет суждения, что пойдет не так? Как мне преподать 10 лет опыта за шесть месяцев? Я пока не знаю. И последнее, о чем вы много слышали, особенно в последнем докладе, если вы были здесь. Человеческое внимание — это самый драгоценный ресурс, который у нас есть. И сейчас много шума. Так много агентов, так много вещей, требующих нашего внимания. Нам придется выяснить, как этим управлять, потому что мы пока не очень хорошо это умеем. Мы получили выгоду от того, что не могли создать больше проблем для себя, чем могли бы уделить внимание. И теперь это не так. Хорошо. Так что это кажется много. Это потому, что в системе все связано. Все проблемы, которые я только что упомянул, кстати, вы не можете решить ни одну из них, просто взглянув на один узел в системе. Вы должны смотреть на всю систему. Чтобы адаптироваться к агентной разработке, я думаю, нам всем придется начать постоянно думать в системных терминах. Так что я не буду проходить через все это. Сделайте скриншот, если хотите. Но когда вы думаете о системах, вот о чем вам следует беспокоиться: вещи становятся больше, эффекты со временем. В каком направлении движется причинность? Какие узлы говорят со всеми своими соседями? Как выглядит эмерджентность? Что появляется из ниоткуда? А как насчет стимулов, как социальных, так и технических? И это верно. Технические системы тоже могут иметь стимулы. Но будьте осторожны со стимулами в вашей экосистеме. Емкость, я говорил это пару раз. Я услышу это по крайней мере еще раз сегодня. Обратные связи и узкие места — это инструменты системного анализа. Теперь это может показаться сложным. Но вам действительно нужны только два вопроса: почему и что, если? Почему у нас так мало интеграционных тестов? Что, если бы у нас было больше интеграционных тестов, чем модульных? Почему мы используем эти конкретные языки программирования? Что, если ИИ напишет весь код? «Почему» — это бур, который вы будете использовать, чтобы проникнуть в сердце вашей системы, чтобы понять, как она работает. «Что, если» поставит под сомнение то, что вы найдете. И это потребует от вас немного проявить воображение. Все вы, вероятно, очень хорошо умеете задавать вопрос «почему». Я вижу это на ваших лицах. Вы знаете, как спросить «почему». Почему мы это делаем? Почему мы делаем то? Но «что, если», «что, если» сложнее. «Что, если» может быть страшно, если мы просим вас отказаться от практик, которые, как вы думали, были очень хорошо разработаны для ваших проблем. «Что, если» может быть страшно. Что, если мы не будем тестировать таким образом? Что, если мы вообще не будем писать тесты? Давайте не будем увлекаться, верно? Но если вы позволите этому быть, «что, если» также может быть очень захватывающим. Теперь, пока вы думаете о том, где находятся эти возможности, я хочу поговорить с вами о шаблоне, который я видел. Это шаблон, что ИИ действует как усилитель. Как только я узнал об этом, я начал видеть это повсюду. Теперь я не могу приписать себе эту идею. На самом деле это исходит от моих друзей из DORA. И в их отчете за прошлый год об ИИ-разработке они обнаружили такую взаимосвязь среди команд, которые действительно все выяснили. Они выяснили, как сделать ИИ усилителем. ИИ может делать больше. ИИ может дать вам больше тестов, больше документации, больше кода, но также и больше путаницы. Это потому, что усиление — это величина, а не направление. ИИ не заботится о том, куда все это идет. Он просто даст вам больше этого. Что DORA действительно обнаружила, так это то, что команды с хорошими основами могли применять это усиление в полезных направлениях, что вызывает вопрос: как вы относитесь к своим основам? Какова культура принятия решений в вашей компании? Что вы могли бы сделать, чтобы улучшить ее? А как насчет ваших технических стратегий? Кто-нибудь смотрит на продуктивность разработчиков? Насколько хорошо люди в вашей организации сотрудничают сегодня? Как выглядит ваша позиция безопасности? Как ваше качество кода, ваша гигиена выпуска, ваша надежность? ИИ по умолчанию не решает никаких из этих проблем для вас. Он может усилить практики, которые у вас есть, если они хороши. Но если они не хороши, это вызовет больше проблем. Но даже с прочными основами нас ждет настоящее приключение. Я предполагаю — это предположение. Вы можете проверить меня позже. В 2030 году наши сегодняшние экосистемы разработчиков будут ощущаться так же, как 2001 год ощущается для нас сейчас. И я должен отметить, что в 2001 году мы выпускали программное обеспечение на CD-ROM, верно? Насколько далеко мы можем быть в 2030 году. Теперь, пока вы продолжаете строить свои основы, позвольте мне дать вам еще несколько вещей, о которых вы можете подумать по пути. Во-первых, и самое главное, вам нужно знать о мощности инфраструктуры. Вы не можете развернуть ИИ, и вы не можете развернуть вычисления, если вы не знаете, сколько ресурсов у вас есть для траты. Вам нужен хороший способ отслеживать это. Далее, вам нужна валидация, потому что вы не можете, или, по крайней мере, не должны выпускать программное обеспечение, которое вы не валидировали. Но, как я уже говорил, валидация изменится. Так что вам понадобится стратегия валидации. Сейчас самое время разобраться в этом. Кроме того, вам нужна изоляция, потому что вы получите много кода для множества различных целей, для которых раньше мы не использовали код. Это нормально. Но вы не хотите, чтобы этот крутой прототипный код попал в производство. Так что вам нужно беспокоиться об изоляции. Вам нужно убедиться, что веселые вещи не влияют на приносящие деньги вещи. А затем, наконец, вам нужно беспокоиться об абстракции. Мы строим абстракции, чтобы разработчики не принимали плохих решений. Вот почему мы строим библиотеки и фреймворки и все такое. Мы бы не стали строить веб-сервер с нуля сегодня. Есть фреймворки — потому что есть много способов сделать что-то не так. Ну, просьба к агентам принимать много решений приводит к тем же последствиям. Так что нам нужны хорошие абстракции, за которые агенты могли бы держаться. Не давайте им плохих выборов. Теперь вам придется принять, что инженерные практики не являются неприкосновенными. Практики меняются. Важны принципы. И это легче сказать, чем сделать. Я понимаю, особенно когда некоторые из наших принципов кажутся практиками. Они кажутся одинаковыми, как тестирование. Если вы никогда по-настоящему не задумывались, почему ваша команда тестирует программное обеспечение так, как она это делает, или почему ваш процесс выпуска работает так, как он работает, вы не сможете его развить. Понимание принципов — это то, что даст вам силу и уверенность, чтобы менять вещи, когда мы движемся через этот 10-кратный момент. Это захватывающее время, чтобы быть инженером-программистом. Я не буду лгать. Каждое измерение нашей работы переопределяется. Нам нужно использовать наше творчество больше, чем когда-либо, верно? Нам нужны навыки для решения таких проблем, как управление контекстом, экономика токенов, дрейф моделей. Нам нужно творчество. И мы не можем так сильно зацикливаться на искушении оптимизировать все. Нам нужно поощрять исследования. Есть проблема, которая не дает мне спать по ночам, и я знаю, что ее нельзя решить просто оптимизацией. И это то, как мы будем поддерживать интеллектуальный контроль над нашими кодовыми базами по мере роста? Интеллектуальный контроль, кстати, это просто модный способ сказать: могут ли люди рассуждать об этой вещи перед ними? Мы проигрываем эту войну по крайней мере последние 15 лет. Наши самые большие системы намного больше, чем кто-либо из нас может сегодня представить. Это нормально. Я думаю, ИИ предлагает нам возможность. Я думаю, ИИ может дать нам инструменты, чтобы на самом деле начать понимать эти очень большие системы как целые системы. И если, например — или не пример. Если вы случайно не поверите мне, когда я скажу вам, что мы проигрываем эту войну, позвольте мне предложить вам упражнение. Когда вы вернетесь к своей команде, попросите всех нарисовать диаграмму архитектуры вашей системы. Посмотрите, сколько разных картинок вы получите, верно? Мы давно проигрываем эту войну. Так что нам понадобится помощь. Дело в том, что многие наши программные системы очень хрупкие. Вы можете сломать систему из миллиона строк одним плохим кодом или одним плохим конфигурационным флагом. Это тот тип хрупкости, который действительно заставляет вас дважды подумать, прежде чем вносить изменения. Одно из потенциальных применений ИИ, которое меня очень воодушевляет, — это идея, что я могу получить постоянно обновляемое, почти интерактивное архитектурное пространство, которое я могу начать исследовать. Например, что произойдет, если мы возьмем мощность отсюда и переместим ее на Восточное побережье? Или что произойдет, если наш рост пользователей внезапно подскочит на 40%? Сделать это даже для системы умеренного размера сегодня практически невозможно. Слишком много переменных и слишком много вещей, которые вам нужно знать. Но ИИ может разобраться в очень больших наборах данных. Так что я думаю, что здесь что-то есть. Но мне нравится в этой проблеме то, что вместо того, чтобы сосредоточиться исключительно на том, чтобы машина кода работала, мы спрашиваем: как мы можем углубить наше понимание того, что мы построили? Вот где, я думаю, находятся некоторые из самых захватывающих проблем. Теперь нельзя отрицать, что изменения происходят очень быстро в нашей отрасли. И это происходит в темпе, вероятно, быстрее, чем большинство из вас когда-либо испытывали. Одна из самых важных вещей, которую вы все можете сделать прямо сейчас, — это предложить помощь кому-то, кто испытывает трудности, верно? Будьте рукой помощи тому, кто еще не разобрался. Мы все движемся с разной скоростью. Мы все по-разному справляемся с этими изменениями. Очень легко почувствовать, что вы отстаете. Старшие инженеры, будьте наставниками. Найдите людей, которые застряли, и помогите им. Если вы разобрались со своим рабочим процессом разработчика с использованием ИИ, поделитесь им с людьми. Это не драгоценный секрет. Помогите другим вокруг вас. Если вы технический руководитель, вам нужно участвовать. Вам нужно помочь направить то, как происходит разработка программного обеспечения в вашей компании. И, что критически важно, если вы заботитесь о качестве программного обеспечения или дизайне программного обеспечения, вы должны использовать свой голос, чтобы отстаивать это. Вы в этой комнате — люди, которые это сделают. Ваши начальники, вероятно, нет, верно? Теперь, рискуя закончить несколько неуклюжей метафорой, если представить наши экосистемы разработчиков как живые экосистемы, мы все привыкли пристально смотреть на каждый отдельный лист на каждой отдельной ветке, заботясь о каждом дереве, как если бы это была какая-то особая форма жизни. Однако скоро мы все будем управлять не просто деревом, а целым лесом. И вы не можете управлять лесом, глядя на отдельные деревья. Вы должны управлять лесом, видя его как экосистему. Теперь в этом проблема системных изменений. У него есть качество происходить со всем, везде, одновременно, быть слишком большим, чтобы кто-либо из нас мог на него повлиять. Может показаться, что прямо сейчас невозможно ухватиться за что-либо, чтобы удержаться от волн перемен, накатывающих на нас, кажется, еженедельно. Но, как мы только что обнаружили, в системе все связано. Маленькие действия могут иметь большие последствия. Несмотря на то, как это может показаться, трансформация ИИ — это не только область руководителей вашей компании. У них есть роль. Но у вас тоже. Как инженеры-программисты первой линии, в этот переломный момент вы находитесь в центре принятия решений о том, чем будет разработка программного обеспечения. От ваших инструментов до ваших рабочих процессов, от ваших инженерных практик до вашей инженерной культуры, если вы можете видеть работающие системы, вы можете искать рычаги воздействия. У вас больше свободы действий, чем вы думаете. Вы действительно так думаете. Используйте эту свободу действий, чтобы создать будущее для вашей организации, для вашей команды и для вас. Спасибо. [МУЗЫКА ИГРАЕТ]