Transcription
Итак, в данный момент мы переживаем довольно быстрые изменения в разработке программного обеспечения. ИИ и "вайб-кодинг" коренным образом меняют нашу работу, и есть много шумихи, которую нужно отсеять. Поэтому сегодня я поделюсь некоторыми проверенными в бою инсайтами из окопов, чтобы успешно пройти эту трансформацию, с некоторыми забавными уроками по пути. Но прежде чем мы начнем, я должен кое-что сообщить. ИИ заменил нас всех. Мы наконец-то можем уйти на пенсию в леса, прежде чем их вырубят под новые дата-центры. Как вы можете догадаться, этого пока не произошло, но будущее может выглядеть немного иначе. Я занимаюсь кодингом с ИИ уже несколько лет, и я думаю, что направление, в котором мы движемся, — это своего рода "нативный для ИИ" инженер. Вместо того чтобы думать: "ИИ может заменить меня", "нативный для ИИ" инженер может спросить по каждой задаче: "Может ли ИИ помочь мне сделать это быстрее, лучше или как-то иначе?". И я думаю, что будущее действительно принадлежит инженерам. Так что вы можете принять этот совместный образ мышления.
Теперь, если посмотреть на все в целом, эта диаграмма — это дорожная карта на ближайшие несколько лет. С одной стороны, у вас есть классические пути разработчика, где большая часть нашей ценности приходила исключительно от человеческих усилий, а затем мы достигли этой фазы, дополненной ИИ, где многие из нас находятся прямо сейчас, и по мере продолжения изменений мы переходим от дополненных к "сначала ИИ" и, в конечном итоге, к "нативным для ИИ" опыту разработчика. Теперь пути "сначала ИИ" задают другой вопрос. Они спрашивают: как бы выглядел этот путь, если бы ИИ был предположен с самого начала, а не добавлен в конце. А затем "нативный для ИИ" DX — это то, где сама единица работы смещается к агентским рабочим процессам. В будущем некоторые говорят, что каждый инженер превратится из простого исполнителя в оркестратора агентов. Возможно, мы все станем менеджерами, где человеческое суждение и критическое мышление помогут направить ИИ к правильным результатам при исправлении кода. Некоторые люди уже очень активно этим занимаются, и, возможно, мы перейдем от "как мне это закодировать" к "как мне получить правильный код".
Для этого уже существует множество решений. Есть фоновый агент Cursors, который может передавать задачи в фоновый режим. Его могут использовать инженеры, менеджеры по продукту. Вы можете отслеживать прогресс по нескольким задачам в режиме реального времени. Вы можете получать уведомления, если агенту требуется ввод. Есть Cloud Code для веба. Мне нравится оркестрировать несколько задач с помощью Jewels из Google Labs. Также есть агент GitHub C-pilot. Я использую его как на настольном компьютере, так и на мобильном. Например, когда я в походе, мне нравится иметь возможность достать телефон и просто запустить кучу задач по побочным проектам. Это довольно круто. Также есть Conductor для карты, который поддерживает несколько агентов, но я должен вернуть нас к реальности. Неудивительно, что стартапы или люди с вечнозелеными кодовыми базами уже начинают играть с некоторыми из этих идей, такими как оркестрация. Корпоративный мир немного отличается. Когда я разговариваю с корпоративными компаниями, я слышу много скептицизма относительно готовности этих паттернов для больших, десятилетних кодовых баз. И я рад, что есть люди, которые занимаются этими проблемами. Я думаю, что в конечном итоге инструментарий достигнет хорошего уровня. Но чтобы немного больше поговорить об этих изменениях паттернов сегодня, большинство из нас действуют как дирижеры. Мы фактически направляем одного агента через одну задачу. А завтра мы можем стать теми оркестраторами, которые управляют флотом агентов, работающих в гармонии для достижения общей цели. Если вы думаете об оркестре, вы, возможно, представляете что-то вроде этого. Возможно, вы представляете себя ведущим оркестр агентов, и это выглядит примерно так.
Однако реальность очень отличается. Все развивается быстро, но лучшие практики для команд и организаций все еще находятся в стадии формирования. Так что мы поговорим об этом сегодня. Несколько опросов разработчиков, включая Dora и Stack Overflow, показали, что большинство из нас используют ИИ для кодинга на работе. И эти данные говорят нам, что это больше не новинка или крайний случай, а быстро ставшая стандартной частью набора инструментов для разработки программного обеспечения. И я хотел бы сказать: если есть одна вещь, которую вы должны запомнить, это то, что ИИ на самом деле не предназначен для написания большего количества кода быстрее. В конечном итоге, он предназначен для создания лучшего программного обеспечения.
Итак, на протяжении всего этого выступления мы будем исследовать, что именно может означать "лучше". Кодинг с ИИ — это своего рода спектр. "Вайб-кодинг" быстр и исследовательский. Он ставит скорость и эксперименты выше глубокого анализа и инженерной строгости. А затем у нас есть "ИИ-ассистированная инженерия". Она находится на противоположном конце этого спектра. И это своего рода методичная интеграция ИИ в зрелый жизненный цикл разработки. Таким образом, мы, инженеры, остаемся под полным контролем и используем ИИ как соавтора для дополнения более структурированного процесса. И задача для нас, как для строителей, — это действительно умело ориентироваться в этом спектре.
Чтобы мы были на одной волне, давайте быстро взглянем на опыт разработчика и на то, как ИИ может помочь на протяжении всего этого жизненного цикла. Это своего рода базовый цикл без каких-либо вмешательств ИИ. Он полезен как эталон для сравнения того, где автоматизация и интеллект могут быть добавлены для ускорения скорости. Итак, обычно мы думаем о таких вещах, как проектирование, кодинг, тестирование, сборка, развертывание. Это подчеркивает, где ИИ наиболее полезен на ранних этапах проектирования. Подумайте о чат-ботах в вашем редакторе для задавания вопросов, итераций и инструментах триажа ИИ, которые могут оптимизировать планирование и исследование. Затем у нас есть внутренний цикл разработки, где мы проводим много времени. Итак, кодинг, тестирование, отладка. И это может помочь с более быстрым созданием кода, автоматизацией тестов, обнаружением ошибок, в идеале до того, как они попадут в продакшн, и определенно до того, как вы окажетесь на Hacker News. Вот полный обзор того, где ИИ может помочь с опытом разработчика. Это все эти циклы: проектирование, внутренний, отправка, внешний, и он подчеркивает каждую точку, где ИИ может значительно уменьшить рутину.
Инструменты кодинга с ИИ также представляют собой спектр. Моя команда и я использовали некоторые из них. У вас есть множество вариантов в наши дни, независимо от того, прототипируете ли вы, не являетесь техническим специалистом или создаете для продакшена. Мы, конечно, тоже много "вайб-кодили". И настоящий гений "вайб-кодинга" заключается в том, что вам никогда не придется сталкиваться с техническим долгом, потому что вы понятия не имеете, кто или что его создал в первую очередь. По мере того как ваша команда будет проходить этот путь, вы столкнетесь со скептиками спецификаций. Вы действительно хотите превратить их в конечном итоге в людей, которые могут быть техническими евангелистами, людей, которые могут иметь очень обоснованную точку зрения на слабости и сильные стороны ИИ, и можем ли мы иметь очень сбалансированный способ мышления об этом.
У нас было несколько больших уроков в моих командах. Например, инструменты ИИ не обязательно заменяют экспертизу, но они ее усиливают. И чем больше навыков вы можете привнести в это как инженер, тем более мощными будут результаты, которые вы в конечном итоге получите. Каково влияние ИИ на кодинг в Google, где я работаю? В целом, это уже повлияло на реальную производительность. Мы наблюдаем довольно измеримый прирост скорости и ускорение кодинга в нескольких исследованиях. Будь то использование его в качестве автодополнения для полного создания кода, для документации, для тестирования, для обзора кода — мы, как правило, обнаружили, что он помогает нам во многих отношениях. У нас есть много команд, успешно использующих такие вещи, как Gemini CLI, для создания следующего поколения приложений, и нам это нравится.
Возможно, вы помните, примерно 3-6 месяцев назад, что кажется очень долгим временем в области ИИ, когда у нас были инженеры по промптам. Мне нравится это название. Возможно, их также называли "шептунами кода ИИ". Люди тестировали, оценивали и итерировали промпты, чтобы повысить шансы получить высококачественный результат. Но умный промпт на самом деле не гарантирует отличных результатов. Многие из нас пробовали инженерию промптов. Мы бесконечно пытались подбирать слова. Но, как показывает этот айсберг, реальные проблемы часто находятся под поверхностью из-за неправильного управления контекстом. Ограниченное окно означает, что ИИ может забыть ключевые детали. Неструктурированный контент может привести к путанице. Конкурирующая информация может отвлечь его, а перегрузка может также перегрузить модель. Таким образом, неправильное управление контекстом часто является большой проблемой здесь. Контекст — король в данный момент.
Итак, если вы еще не сталкивались с такими вещами, как инженерия контекста, это фактически означает оснащение агента ИИ всем необходимым для эффективного выполнения задачи. Мы говорим о правильных файлах, примерах, истории, инструментах, ограничениях, и качество вашего вывода будет пропорционально качеству и релевантности предоставленного вами контекста. Многие из инструментов, которые мы используем, будь то Cursors или Klein, делают гораздо проще включение файлов, папок, проблем, URL-адресов, больше документации в ваши рабочие процессы, чтобы помочь с этим недостающим контекстом. И все чаще у вас появляются другие способы, такие как визуальные способы, мультимодальность, возможность получать больше полезного контекста. Мы также видим, что наши инструменты немного развиваются, потому что, опять же, размеры этих контекстных окон могут быть довольно ограниченными. Поэтому некоторые инструменты, это Klein, делают умные вещи, такие как автоматическое обобщение контекста. Таким образом, когда ваш разговор приближается к размеру контекстного окна, он может фактически начать обобщать предыдущие сессии, чтобы вы могли освободить место и продолжить работу, сохранив при этом важные части, важные детали. Существуют также другие идеи, такие как банк памяти, который представляет собой своего рода структурированную систему документации, позволяющую поддерживать контекст в нескольких сессиях. Например, Klein может читать файлы банка памяти и восстанавливать свое понимание вашего проекта без необходимости выполнять много ручной работы самостоятельно.
Вот отличный шаблон для инженерии контекста от Anthropic. Он содержит такие идеи, как фоновые данные, примеры, история разговоров. Этот тип вещей делает отличный твит, который вы полностью забудете. Я все время забываю это. Я решил "вайб-кодить" это в быстрое веб-приложение, которое вы также можете проверить. Я также полностью забыл использовать это. Нам просто нужны лучшие инструменты для автоматической обработки этого, и я с нетерпением жду развития наших инструментов в этом направлении. Разработка, управляемая спецификациями, стала более популярной. Это практика планирования перед тем, как задать промпт, и предоставление четкого контекста, который нужен ИИ для успеха, вместо того, чтобы ожидать, что он прочитает ваши мысли. Из этого вытекает несколько других паттернов. Недавно я видел, как несколько человек использовали файл markdown "уроки". И это своего рода создание мощного цикла самосовершенствования, где производительность агента улучшается с каждой задачей. Итак, в конце задачи, представьте, что вы просили его написать компонент или внести некоторые дополнения в уже существующее приложение. Вы можете попросить его сохранить ключевые выводы в простом текстовом файле, и это действует как долговременная память. Таким образом, это становится своего рода внешним мозгом, который постоянно улучшается и помогает управлять производительностью агента с течением времени.
Другие вещи, которые мы узнали: никогда не коммитьте код, который вы не можете объяснить другим людям, или даже себе. Это золотое правило для продакшн-кодинга с ИИ. Вы должны предполагать, что вы и ваша команда в какой-то момент будете вынуждены вручную вносить изменения. И поэтому, опять же, человек в цикле, человек, проверяющий код, будет продолжать оставаться важным. Я думаю, что чтение кода станет еще большей частью работы в будущем. Мы можем ожидать, что будем тратить больше времени на проверку, тестирование, объяснение, чем на простое написание. Итак, нам придется продолжать развивать этот навык. На протяжении жизненного цикла программы она обычно пишется один раз, возможно, редактируется несколько раз, но в конечном итоге отлаживается, поддерживается и улучшается еще больше раз и довольно часто читается на протяжении всего своего жизненного цикла.
"Вайб-кодинг" — это подарок для прототипирования. Я думаю, что статические макеты часто выглядят хорошо, но они не интерактивны, и это ограничивает обратную связь, которую вы можете получить от реального пользовательского опыта. Итак, мы действительно наслаждались использованием этого для прототипирования. Вы можете быстро создать что-то, что имеет более четкое представление о видении, которое вы предлагаете людям, и это просто поднимает дискуссию на новый уровень. Есть некоторые компании, которые действительно сильно внедрили эту идею, например Shopify. Итак, Shopify провела общекорпоративное управление изменениями, связанное с использованием ИИ в инженерии, продукте, UX, сверху вниз, и теперь у них есть несколько иные процессы передачи дизайна инженерам. Дизайнеры теперь могут просто "вайб-кодить" прототипы и работать напрямую с инженерами, чтобы реализовать их как артефакты. Это означает, что существует проверка кода, итерации, работа над качеством, но мы начинаем видеть в некоторых случаях смешение ролей, что очень интересно наблюдать.
Голосовой ввод также меняет способ "вайб-кодинга". Потому что вы можете использовать свой голос намного быстрее, чем печатать. До трех-пяти раз быстрее. Когда я впервые услышал об этой идее, я подумал, что это отлично работает, если вы работаете удаленно в своем собственном офисе, и ужасно, если вы находитесь в любой открытой офисной ситуации. Но, конечно, теперь есть "вайб-кодинг" шепотом, который также доступен. Так что вы можете просто прошептать свой путь к своим MVP. Это на самом деле работает довольно хорошо.
ИИ — это множитель. То, что помогает человеку, может помочь и ИИ. Поэтому инвестируйте в тесты, CI, четкую документацию, прежде чем ожидать действительно больших успехов. Тесты в конечном итоге являются огромной защитной сетью в данный момент. Они действительно снижают риск использования ИИ для кодинга. Так что, если что-то пойдет не так по какой-либо причине, вы узнаете об этом раньше. И если вы, я разговариваю со многими командами, которые говорят: "Все это отлично, если у вас уже есть сквозные тесты. Что, если у нас нет этих тестов? Будем ли мы использовать ИИ для их написания?" И вы можете, вы просто, опять же, должны убедиться, что вы держите людей в цикле, чтобы понять, какие тесты генерируются. Достаточны ли они? Кстати, это выглядит так, как будто мать издевается над своим ребенком по какой-то причине, но, по крайней мере, они в безопасности.
Обещание ИИ заключалось в своего рода скачке производительности, а то, что показывают данные, которые я люблю читать в белых книгах, люблю читать исследования, немного более нюансированная реальность. И поэтому давайте посмотрим на некоторые исследования и конкретные действия, которые мы можем предпринять, чтобы зафиксировать успехи и управлять рисками. Итак, последние данные показывают, что использование высоко, оно продолжает расти, но доверие падает. Благоприятные взгляды на ИИ для кодинга упали с 70 до 60% за последние два года, а 46% людей активно не доверяют точности ИИ. Эта диаграмма показывает, что около 30% опрошенных здесь разработчиков имели мало или совсем не доверяли коду, сгенерированному ИИ. И этот скептицизм не обязательно плохо. Это признак того, что эта область созревает. Это объясняет часть трений, которые мы увидим в некоторых других вещах, о которых я собираюсь говорить. Но модели продолжают улучшаться, агенты продолжают улучшаться. Однако мы начинаем узнавать, где все может пойти не так. Итак, когда все идет не так с "вайб-кодингом", у вас есть "вайб-отладка". Где вы понятия не имеете, как работает код или как его исправить. Я подумал, что стоит упомянуть. В моей команде мы совсем недавно выпустили Chrome DevTools MCP. И это для того, чтобы ваш ИИ-ассистент по кодингу мог видеть и взаимодействовать с живым браузером. И это означает, что ваш агент может видеть, что отображается. Он может смотреть на журналы консоли. Он может смотреть на сетевые журналы, автоматизировать оптимизацию производительности. Он может находить проблемы с любыми сложными макетами. Это открывает много возможностей. Если вы, например, кодите с ИИ, возможно, проверьте это. Может быть полезно.
Но вернемся к данным. На индивидуальном уровне прирост производительности от ИИ реален. Разработчики, использующие его, могут выполнять до 21% больше задач. Люди появляются на периферии, до 98% больше pull request'ов. Мы поговорим о pull request'ах чуть позже. Но очень значительное число разработчиков скажут, что ИИ положительно влияет на их личную производительность. Некоторые даже скажут, что, когда мы говорим о положительном влиянии, они чувствуют, что ИИ пишет лучший код, чем они в некоторых случаях. Теперь, когда мы особенно говорим об обычных проблемах, средних проблемах, я, безусловно, могу увидеть, что это правда. И есть люди, которые скажут, что это чрезвычайно увеличило их производительность. Это показывает, возможно, около 10-13%. И будут люди, которые скажут, что это немного увеличило их производительность, то есть ближе к 41%. И эта последняя большая группа предполагает постепенное преимущество от ИИ по всей рабочей силе.
Теперь перейдем к самому интересному. Вот парадокс. Мы ускорили генерацию кода, но человеческая проверка не масштабировалась с этим. Время рассмотрения pull request'ов увеличилось в некоторых случаях до 91%. Размеры PR также взрываются. Если вы просматривали полностью сгенерированный ИИ pull request, возможно, вы видели, что есть случаи, когда люди вносят всевозможные ненужные изменения во многие, многие больше файлов, чем требуется. Таким образом, размеры PR взлетели до 154%. Это поглощает большую часть тех индивидуальных успехов, о которых мы только что говорили. Система движется со скоростью самого медленного этапа, и сегодня этим этапом является проверка и валидация. Таким образом, разработчики описывают этот распространенный паттерн. Предложения ИИ часто правдоподобны, но не всегда верны. И 66% людей называют это своим самым большим временным поглотителем. 45% говорят, что отладка вывода ИИ — это больше работы, чем оно того стоит. И это напрямую связано с более длительными проверками, о которых я только что говорил.
Вывод довольно прост. Ворота качества и валидация теперь являются критическим путем. Поэтому мы, как отрасль, должны начать развивать наше мышление о проверке кода, чтобы избежать чрезмерной нагрузки на старших инженеров. Итак, что мы обнаружили в целом, так это то, что ИИ преуспевает в ситуациях с низким контекстом. Если вы начинаете с нуля, если вы обрабатываете предсказуемые шаблоны, пишете общие функции, вы знаете, если вы относитесь к ИИ как к младшему инженеру, где задачи, возможно, хорошо определены и контекст низкий, он может работать довольно хорошо, особенно с новым кодом, особенно с генерацией шаблонного кода, генерацией модульных тестов, генерацией документации, опять же, прототипов, MVP. Я думаю, что это может освободить экспертов, чтобы они могли сосредоточить время на большей работе по проектированию, интеграции, сложным крайним случаям, просто создании более отполированных впечатлений. Там, где он сейчас испытывает трудности, это высококонтекстные новые проблемы. И здесь действительно требуется глубокий контекст. И если вы команда, создающая что-то нетривиальное, это потребует строгого надзора. Таким образом, он не может держать в голове десятилетие архитектурных решений или неформальной бизнес-логики без изучения ваших кодовых баз, без изучения вашей документации и того, как ваша команда работала с течением времени. В областях, чувствительных к безопасности, риск тонких ошибок продолжает расти. И в любое время, когда ваши требования неоднозначны или логика охватывает несколько систем, опять же, люди должны вести, а ИИ должен помогать.
Некоторые могут сказать, что неважно, что вы "вайб-кодите", каким бы хрупким оно ни было, вы всегда можете исправить это позже. Но для тех из нас, кто не комфортно относится к "йоло-подходу", есть несколько вещей, которые вы можете сделать. Наш первый приоритет — это действительно смягчение снижения навыков. Мы должны использовать ИИ для ускорения обучения в наших командах, но не обязательно заменять его. И это требует переосмысления наших основных процессов обучения и наставничества, чтобы гарантировать, что инженеры всех уровней развивают и поддерживают фундаментальные навыки решения проблем. Это приводит к тому, что я называю "проблемой 70%". ИИ может помочь вам примерно на 70% в решении проблемы, будь то генерация полного приложения, генерация MVP. Но последние 30%, последний километр, — это самая трудная часть. Ваш помощник может помочь вам с разработкой функции, но готовность к продакшену означает, что эти крайние случаи, эти архитектурные проблемы, эти тесты, эти очистки — все это требует работы от нас. Для младших, если вы новичок в технологиях, если вы младший специалист, эти 70% все еще очень волшебны. Это может ощущаться очень волшебно, но для старших последние 30% часто занимают больше времени, чем написание кода с нуля самостоятельно. Таким образом, ИИ может помочь нам быстро сократить разрыв в демонстрации, но отправка в продакшен, я думаю, по-прежнему принадлежит людям. Иногда последние 30% — это то, что видят старшие, а младшие не видят, просто потому, что они не знают, на что именно смотреть. Другими словами, младшие могут отправить эти 70% как pull request, как будто они закончены. И это означает, что фактическая трудная часть может оказаться в проверке кода, в основном выполняемой старшими, которые исправляют ошибки, которые ни один человек не сделал бы. Иногда люди делают их, но это означает, что мы снова должны переосмыслить, как мы подходим к проверке кода.
Нам не нравится говорить о влиянии ИИ на рынок труда, но я думаю, что он как-то повлияет на нас. 54% руководителей ожидают, что ИИ каким-то образом сократит найм младших специалистов в ближайшие пару лет. Он коммодитизирует легкие части, заставляя нас думать о том, как цепочка создания стоимости эволюционирует к более значимой работе. Это может означать потенциально меньше начальных должностей или эволюцию младших должностей для фокусировки на вещах, которые ИИ не мог бы делать так хорошо. И если вы технический руководитель, менеджер, лидер, я думаю, нам придется продолжать думать о том, как мы развиваем таланты, чтобы гарантировать, что мы не пересушим наш кадровый резерв, потому что нам понадобятся эти младшие специалисты, чтобы в какой-то момент стать старшими. Я все еще думаю, что нам понадобится много старших инженеров.
Итак, одна из первых вещей, которые мы можем сделать, — это попытаться превратить проверки кода в большее количество учебных моментов. Я слышал, как старшие инженеры возвращали pull request'ы, где было ясно, что использовался ИИ, но человек на самом деле не понимал, что он делает. И когда младший специалист отправляет PR, сгенерированный ИИ, проверка становится одним из ваших основных инструментов наставничества. Вы можете задавать им сократические вопросы, которые заставляют их объяснять вывод ИИ. Вы можете помочь обеспечить уровень понимания, а не только функциональности. Таким образом, эти проверки становятся более о понимании, а не просто о правильности. Я предложил, возможно, мы должны перейти от парного программирования к тройному программированию. Это держит старшего эксперта в цикле, но гарантирует и предполагает, что младший специалист каким-то образом будет использовать ИИ для повышения скорости. Таким образом, качество обучения каждого остается высоким, и мы избегаем проблем изоляции, которые может создать чистое взаимодействие с ИИ. Это все еще совместная работа человека и ИИ. Я предлагал в своих командах попробовать регулярные "без ИИ" челленджи. Это еще одна вещь, которую вы можете сделать, чтобы гарантировать, что навыки критического мышления не испарятся. Итак, вы можете помочь сохранить навыки вашей команды острыми, просто, например, назначив день недели или даже определенный тип задачи в вашем бэклоге, где вы просто говорите: "Ну, может быть, мы не будем использовать ИИ для этого". И это просто подкрепляет, что это помощник. Это инструмент, но это не замена мышлению. И это важно для построения устойчивости, когда ИИ выходит из строя или недоступен.
ИИ часто производит код, который проходит базовые тесты, но может не обладать надежностью. Его базовый уровень обычно: "Ну, работает, я думаю, вроде как отображается в браузере, я думаю". Но опять же, эти проверки кода важны для проверки крайних случаев, производительности, безопасности, правильности, соответствует ли он лучшим практикам и шаблонам вашей команды. И наша человеческая роль действительно заключается в обеспечении готовности к продакшену и стандартов. Говоря о стандартах, вот как выглядели стандарты безопасности в 80-х. Ремни безопасности были нормальными. У нас были только "вайбы", что не совсем отличается от того, что у нас есть сегодня.
Итак, я сегодня много охватил. Если вы так себя чувствуете, вы абсолютно правы. Важно во всем этом оставаться проактивным, помогая себе и своим командам на этом пути. Наша задача — найти правильный баланс. В конечном итоге, это использовать скорость и возможности ИИ для более быстрой доставки ценности, но сохранять человеческий элемент под контролем. Я думаю, что наше творчество, наше суждение и наше понимание потребностей пользователей будут действительно направлять то, как используется ИИ. Итак, я надеюсь, что вы нашли что-то полезное в этом выступлении. Спасибо. [аплодисменты]