Transcription
Как масштабировать процесс ревью? Потому что сейчас это тормозит ваших старших инженеров. Это выжигает их. Один из ответов — вообще не делать код-ревью. Это Флориан Бютов, AI-инженер в Xebia, и мы обсуждаем самую большую проблему в разработке программного обеспечения прямо сейчас: код-ревью. Что вы думаете о разработке, управляемой спецификациями? Какие из этих защитных механизмов принесли вам наибольшую пользу? Имеет ли значение, какой «сбруей» я пользуюсь? GitHub Copilot, Claude Code, Codex. Это имеет огромное значение. По сути, сотрудники дают людям гранату, которой является ИИ, а затем говорят: «Не взорвитесь гранатой, но используйте ее». Вот как лучшие инженеры решают проблему узкого места в код-ревью прямо сейчас. Вот полный выпуск. По мере того, как мы генерируем больше кода, это действительно находится в фазе сборки, код-ревью становится узким местом. Я только что вернулся с Google I/O, это было на прошлой неделе. Думаю, когда этот выпуск выйдет, это будет пару недель назад, и даже там Google и люди признали, что код-ревью — это узкое место, и мы еще не знаем, как его решить. Да, Google — интересный случай, потому что в 2025 году они уже сообщили, что 50% кода — это ИИ, а я настаиваю на 75%. Мне всегда нравится смотреть на крупных игроков и видеть, что они делают, потому что с одной стороны вы видите все эти сумасшедшие цифры, такие как повышение эффективности, или мы автоматизировали весь наш слой развертывания с помощью ИИ, как это сделала, например, Spotify. Но очень редко вы видите, как именно они это делают. Правильно? Итак, они сообщают обо всех этих достижениях. Но как тогда перевести это на свою работу? Эта часть часто отсутствует. И для крупных компаний, я думаю, если вы немного посмотрите на то, что они публикуют и что пишут, вы можете увидеть, что у них есть подход, который ставит во главу угла ревью. Нет, скорее это становится более стандартизированным, потому что они определили, что теперь, когда код можно генерировать очень дешево, узкое место перемещается куда-то еще. Теперь некоторые люди, и это еще одна мысль, но некоторые люди будут утверждать, что написание кода никогда не было узким местом. Это зависит от того, как вы видите разработку программного обеспечения. Но правда в том, что вы генерируете в десять раз больше кода. Так что теперь у вас больше давления на ревью, на ваших инженеров и так далее. И я думаю, что крупные компании сейчас борются с этим с помощью политик в отношении ревью. Например, в Amazon были случаи сбоев, потери дохода из-за кода, сгенерированного ИИ, и тогда они ввели политики, согласно которым теперь требуются некоторые части кода или некоторые части систем, которые должны быть проверены старшими инженерами, прежде чем что-либо будет объединено или развернуто. Таким образом, они определяют, что в некоторых случаях код, сгенерированный ИИ, должен быть тщательно проверен, возможно, более тщательно, чем в других случаях. Так что вы можете это видеть. И в то же время вы видите другие компании, которые говорят: «Хорошо, мы автоматизировали весь наш процесс ревью PR». Они применяют что-то вроде… Как бы вы сказали? Ну, мне нравится думать об этом как о своего рода горизонтальном способе масштабирования инженерии ИИ. И вертикальном. Горизонтальный — это когда вы автоматизируете процессы. У вас есть ревью PR, например, вы можете сказать, что любой PR, который создан, автоматически просматривается с помощью Copilot, например. И это то, что делают многие компании. Но тогда они не говорят, как это улучшает качество. Правильно? Итак, автоматизация части человеческого конвейера, который у нас есть, это вертикальная ось. Вертикальная ось — это если у вас есть проект и небольшая специализированная команда, вы позволяете им создавать свои собственные инструменты, чтобы убедиться, что продукт выпускается и разрабатывается так, как они намереваются. Таким образом, они более вовлечены в создание пользовательских сред для своих кодовых агентов и для доставки программного обеспечения, как будто у них нет чертежа, который автоматически применяется к продукту. Они его совершенствуют. Да. И я вижу, как мы накапливаем множество возможностей, верно. У нас есть модель с одной стороны. Затем «сбруя» агента вокруг модели, в частности. И вы говорите об окружении, в котором действует эта «сбруя» агента. Как мне на это посмотреть? Ну, может быть, может быть, стоит вернуться на шаг назад. Если мы посмотрим на разработку программного обеспечения, я думаю, что к настоящему времени это хорошо зарекомендовавший себя процесс. Например, если мы подумаем до эпохи разработки программного обеспечения с помощью ИИ, жизненный цикл разработки программного обеспечения, все его знают. И часть ревью выполнялась людьми, и это работало, потому что код доставлялся не быстрее, чем вы могли его просмотреть. Это изменилось сейчас. И поэтому возникает вопрос: как масштабировать процесс ревью? Правильно? Потому что теперь это тормозит ваших старших инженеров. Это выжигает их. Есть исследования на эту тему, где растет когнитивная глубина, где люди не понимают свою собственную кодовую базу, потому что у них просто нет времени смотреть на все, или они даже не хотят смотреть на код, сгенерированный ИИ, и так далее. И поэтому возникает вопрос: как это смягчить? И один из ответов — вообще не делать код-ревью, хорошо. Но тогда следующий вопрос: как это сделать? Я думаю, один из способов — это спроектировать среду, в которой действуют агенты. С намерением, чтобы вам не пришлось быть человеком в цикле, чтобы давать агенту обратную связь по общим вещам. И это начинается с очень простых вещей. Например, просто скажем, форматирование кода, автоматический форматировщик кода, у нас уже был такой, или проверка безопасности. Многие команды интегрировали такие инструменты, как SonarQube, или что-то, что дает вам обратную связь, которую затем человек использовал бы для исправления кода с обратной связью от этих систем. Агенты могут делать это автоматически. Так что, если вы предоставляете агентам обратную связь о том, что они делают неправильно, и, надеюсь, как можно ближе к тому месту, где агент фактически генерирует код, что означает на ноутбуке разработчика, а не обязательно на GitHub. После того, как вы сделаете свой коммит или свой PR, вы внезапно оказываетесь в этом мире, где вы пытаетесь спроектировать обратную связь для агентов таким образом, чтобы помочь агентам работать в течение длительного времени без вмешательства человека. Вот что я имею в виду под созданием таких сред. Да. И я думаю, что начать с этим очень легко. Большая часть этого будет ощущаться как «но мы уже делали это раньше», но теперь вы даете агенту эту обратную связь. Вы больше не воспринимаете ее как человек, верно? И некоторые модели удивительно хорошо самокорректируются, как только вы указываете им на то, что они сделали неправильно, и позволяете среде давать эту обратную связь. Да. Имеет ли «сбруя» в этом уравнении значение, какая «сбруя» я использую? GitHub Copilot, Claude Code, Codex. О, да, абсолютно. Ну, по моему опыту, «сбруя» важнее модели. Хорошо. Я имею в виду, «сбруя» — это то, что предоставляет инструменты, что предоставляет какой-то тип подсказки, предоставляет слой памяти и все эти вещи, которые затем отправляются в LM для генерации, например, как бронза, где LM хочет сделать вызов инструмента и так далее, а поставщик «сбруи» предоставляет возможность выполнить инструмент для LM, это имеет огромное значение. Я провел эксперимент в одном из своих проектов, где пытался реализовать инструмент на основе спецификаций и тестов. У меня был полный набор спецификаций, таких как разработка, управляемая спецификациями, как многим нравится делать. Заметьте, идея в том, что если вы точно специфицируете свой продукт, я смогу реализовать его точно в соответствии со спецификациями, что, к сожалению, не так, но это попытка, которую я предпринял и которая потерпела неудачу. А затем я подумал: «Хорошо, что, если я использую идею TDD и просто сгенерирую все параллельные тесты заранее, а затем позволю этому стать обратной связью для агента, который пытается следовать моим спецификациям?» И в зависимости от «сбруи», которую я использовал, это работало или не работало. Даже если я использовал передовую модель в обеих «сбруях». Хорошо, какая «сбруя» дала вам лучшие результаты? Ну, это постоянно меняется. Так что в то время это был Claude Code. Понятно. Теперь я бы сказал, что это сместилось в сторону Codex для реализации. Но это одна из тех вещей, которые являются движущейся целью, что также является одной из причин, почему вы не можете перестать экспериментировать. Существует тенденция у инженеров-программистов систематизировать вещи и превращать их в процесс. И хорошо. Это теперь правила. Я не думаю, что это работает. Вещи все еще движутся слишком быстро. Хорошо, может быть, мне стоит немного отступить. Это работает на некотором уровне, но если вы определите в своей политике, мы должны использовать только Claude Code. Кто знает, что произойдет, когда выйдет следующий релиз. Это может быть совершенно по-другому, потому что у моделей есть разные, так сказать, «личности», некоторые очень хорошо следуют инструкциям, другие очень хорошо заполняют пробелы, если вы не предоставляете достаточно контекста как человек. Так что вам нужно быть осторожным, какую модель вы используете. Да, я хочу сосредоточиться на том, что вы рекомендуете для «сбруи». Но прежде чем мы перейдем к вашему следующему шагу, мысли о спектре разработки и решении проблемы код-ревью таким образом. Вы упомянули, что подход TDD работал лучше, чем подход спектра разработки, с моделью, следующей инструкциям таким образом. Ну, я бы сказал, что спецификационная разработка была моей первой попыткой, и она прошла не очень хорошо. Это был типичный случай: «Хорошо, я создаю идеальную подсказку, а затем модель делает что-то другое, чего я не предполагал». Но когда вы даете им обратную связь в дополнение к тому, чтобы говорить модели, когда она сбивается с пути, это сработало для меня в данном конкретном случае. И я бы сказал, что эти результаты могут быть переносимы на другие проекты, но это действительно зависит от проекта. Что снова возвращает нас к необходимости быть готовым экспериментировать, что работает. Да. И эта обратная связь, просто чтобы я понял, это в автоматизированном режиме, верно? Итак, у вас есть спецификации, затем у вас есть выполнение, и обратная связь — это не вы говорите, что она сделала неправильно. Но как выглядит этот цикл обратной связи? Именно так. Да. Так что, когда вы используете, например, инструменты CLI, у вас есть возможность определить, что называется, например, «стоп-хук». Итак, когда агент закончил свою работу, «сбруя» запускает событие, которое является «стоп-хуком». И вы можете связать это со скриптом оболочки, который вы используете, например, так что вы можете автоматизировать запуск набора тестов или ваших защитных механизмов. Мне нравится называть их «защитными механизмами». И они тогда должны проектировать ваши «защитные механизмы». Так что они фактически выводят текст на естественном языке: «Это запрещено. Сделайте это так». Итак, вы основываете обратную связь в коде на подсказке, которую вы написали бы как человек. Затем вы запускаете это, и это запускает LM для продолжения работы над этим. И вы можете сочетать эти отзывы, которые вы даете, с такими вещами, как «руф-луп», знаете, Codex и Claude теперь имеют команду «гол», которая действительно помогает. Они будут просто работать все дольше и дольше, пока не исправят проблему. Да. Так что «руф-лупы» специально позволяют вам выполнять все, что вы хотите делать в цикле, верно? Итак, он проходит по нему. И этот механизм обратной связи затем будет вводиться в итерацию, чтобы исправить это и исправить. «Гол» — это что-то похожее. Идея та же. Идея та же. Да. Я не знаю точно, как выглядит реализация «гола», но кажется, что это функциональный эквивалент «руф-лупа». И какие из этих «защитных механизмов», которые вы внедрили, принесли вам наибольшую пользу? Вы уже упоминали линтинг. Некоторые средства контроля безопасности. У вас есть больше примеров. Да. Так что я раньше не знал, но с тех пор стал большим поклонником Semantic Grep. Хорошо. Да. Потому что он позволяет вам использовать регулярные выражения для вещей, которые он мог бы уловить в коде, например, определенный тип конструкции кода. Пример, который я всегда привожу: я не хочу никаких значений по умолчанию в своих методах. Например, в Python вы можете устанавливать значения по умолчанию для параметров в методах Python и в сигнатуре метода. И это, по моему опыту, является одним из самых больших источников разочарования, когда приходится просматривать и отлаживать код позже. Так что просто предотвратите это, установив правило, которое обнаруживает эти шаблоны кода и затем вызывает ошибку. «Вы не должны писать так. Это против политики». Так что Semantic Grep действительно гибок. И всякий раз, когда я опрашиваю ИИ о коде, который я написал, вместо того, чтобы самому просматривать код, знаете, возникают некоторые из этих проблем. «Почему вы сделали это так? Это не имеет смысла». Это немедленно побуждает меня: «Хорошо, давайте добавим еще одно правило «защитного механизма» для этого конкретного типа шаблона». Таким образом, со временем вы формируете свою среду. Вы итерируете к ней, делая ее все более и более строгой, чтобы она соответствовала вашим предпочтениям как человека или тому, как, по вашему мнению, должен выглядеть код. И частью этого является не только вкус, но и вы хотите обеспечить, чтобы ИИ генерировал код, который легко понять, не для людей, даже если вы не хотите читать его как человек, но и для ИИ. Код — это контекст. Вот почему качество кода имеет значение. Если вы просто «протираете» код, рано или поздно ИИ запутается в коде. Да. Устойчивость кодовой базы всегда должна быть простой и легко изменяемой. И эта перспектива не изменилась. С агентами мы позволяем себе генерировать больше кода, и код, который находится там, может быть не простым и может быть не таким легким для изменения, но мы говорим: «Ну, это работает, верно?» А затем построение на этом может быть довольно хрупким. Да. И, ну, как люди, мы также позволяем себе это небольшое исключение, когда мы говорим: «Пока это модульно, неважно, если один из модулей беспорядочен или что-то еще, пока он изолирован, верно? Он находится за абстракциями». Да. И это тоже то, что я обнаружил с ИИ. Если вы сохраняете свои вещи модульными, это очень помогает. Например, если у вас есть четкие границы между модулями, если у вас есть четко определенные интерфейсы, которые нельзя изменять, например. И, и я бы сказал, что это приводит нас к другому типу «защитного механизма», которым являются архитектурные ограничения. Так что во многих языках есть архитектурные модульные тесты. Это как модульные тесты, которые выполняются чрезвычайно быстро. Они только смотрят на зависимости между различными модулями вашей кодовой базы, поэтому они могут анализировать ее очень быстро, и вы можете сказать: «Хорошо, предотвратите, скажем, скажем, скажем, UI от прямого доступа к базе данных». Вы можете обеспечить, чтобы он всегда проходил через слой бизнес-логики или что-то в этом роде. И потому, что они также склонны создавать эти странные взаимосвязи между модулями, которые человек никогда бы не сделал. Если вы просто позволите ИИ подписать вашу систему, а затем нарисовать диаграмму вашей системы, вы увидите самые странные вещи, которые вас возмущают, которые вы затем кодируете в дополнительные архитектурные модульные тесты, которые я бы отнес к другой форме «защитного механизма». Есть ли что-нибудь, что вы бы сказали? Ну, это все еще своего рода часть человеческой ответственности, которая не укладывается в автоматизированные «защитные механизмы»? Да. Так что-то, я имею в виду, если вы посмотрите на разработку программного обеспечения, и я возвращаюсь к традиционному способу ее выполнения, всегда было так: «Хорошо, что мы хотим построить? Как мы это построим? Как мы сохраним это поддерживаемым?» Правильно? Поддержание чистоты и простоты кодовой базы означает, что мы можем быстро работать в течение длительного времени. И как мы это делаем? Ну, с архитектурой, верно? Мы определяем архитектуру заранее, а затем начинаем углубляться в модули. Как мы реализуем друг друга? Я думаю, это должно остаться прежним. Модели еще не готовы. Смогут ли они сделать это самостоятельно. И моя рабочая нагрузка теперь включает в себя сначала точное понимание того, что я хочу построить, точно, чтобы не было сомнений, а затем набросок того, как это может выглядеть как программная система. Правильно? Это могут быть разные сервисы, говорящие друг с другом. Это может быть на уровне сервиса, разные модули, говорящие друг с другом. Какие функции мне нужны в модулях? Таким образом, вы специфицируете практически всю архитектуру, кроме реализации. И как только у вас это будет, вы уже можете закодировать это в виде правил. Да. Вы знаете, я думаю, что это чрезвычайно важно для борьбы, я думаю, что на вашем шоу люди уже говорили о когнитивном диссонансе, который возникает от того, что вы больше не понимаете свой код, и вы не можете как человек рассуждать о своей кодовой базе. Это происходит, когда вы больше не понимаете архитектуру и то, как компоненты взаимодействуют друг с другом в вашей программной системе. И да, вам нужно сделать все, чтобы бороться с этим как можно больше. Да. Но да, мне очень трудно представить, куда это приведет, потому что я согласен с вами. Если я понимаю свою программную систему, я чувствую, что это навык, который действительно останется для инженеров в частности. И я считаю, что реализация уже автоматизируется, и я чувствую, что с достаточным количеством «защитных механизмов» мы можем усовершенствовать код-ревью до такой степени, что останется только суть, потенциально поведение. Я вижу, как люди просматривают спецификации, которые также останутся. Но если я поставлю себя на место инженера, возможно, кого-то, кто слушает, кто работает в большой организации, вы, возможно, еще не знаете свою систему, тогда довольно сложно сказать: «Хорошо, эта часть головоломки заранее. Знаем ли мы, как ее построить? Или сколько исследований мне нужно провести?» Это вся работа, которая сейчас будет выполняться заранее, и потенциально до ИИ вы бы делали это по мере продвижения и итерировали и улучшали. Весь этот образ работы теперь изменился. Да. Очень, очень, очень сложно быть небрежным в своем подходе сейчас, и именно поэтому люди находят, что я бы сказал, почему некоторые люди могут сопротивляться этому, потому что, знаете ли, делать всю тяжелую работу заранее, верно? Вы не просто открываете, как вы только что сказали, по мере продвижения, вы делаете всю тяжелую работу заранее. Вам, вероятно, придется сделать пару итераций по вашей реализации, чтобы лучше понять, как на самом деле выглядит хорошо. Так что это не редкость. Но вы можете сделать это с помощью «вайб-кодинга». Да. И я думаю, что это будет новая норма на некоторое время, прежде чем что-то снова изменится. Но интересная часть в том, что я всегда спрашиваю людей: «Ну, как вы могли бы разрабатывать программное обеспечение, если бы не знали, что хотите построить?» Да. Правильно? Это тоже невозможно. Так что вы делаете ту же работу сейчас. Просто вы делаете это заранее. Правильно. Что может показаться более интенсивным, более сложным. Но это также означает, что это становится своей собственной дисциплиной. И когда люди думают о том, что должны делать младшие инженеры, теперь, когда я могу генерировать весь код, я бы сказал: «Ну, это явно то, чему можно научиться. Это невероятный навык». Да. Правильно. Я видел, как лучшие инженеры-программисты попадают в две категории. Те, где, как вы упомянули, кому-то нужно было что-то построить, и я видел, как они смотрели на свой экран. Это было еще до Covid, когда мы работали в офисе пять дней в неделю, и я видел, как они с карандашом и бумагой что-то писали и рисовали, прежде чем даже приступить к работе. И я подумал: «Это очень интересный навык». А затем я видел других людей, которым очень трудно представить, и мне нужно начать печатать, но они все равно остаются очаровательными и чрезвычайно эффективными в своем образе действий. Но это совершенно противоположно тому, что делал первый инженер. Абсолютно. И здорово то, что если вы позволите себе это сделать, например, прототипировать, углубиться в это открытие, прежде чем вы зафиксируете свои спецификации, но прежде чем вы скажете: «Хорошо, вот что мы хотим построить». Это невероятно полезно. Мне это очень нравится, потому что вы действительно чувствуете скорость, которую ИИ дает вам, когда вы итерируете идеи. Я часто разговариваю с ИИ в течение часа, просто чтобы исследовать эту идею, а затем, возможно, побочную идею, и, возможно, мне следовало бы пойти по ней. Но это учит вас так много о том, как вы можете думать о системах, и это также повышает вас как инженера, потому что теперь вы не только думаете: «Хорошо, как я это реализую?» Но вы также думаете: «Что нам на самом деле нужно?» Правильно? «Что нужно клиенту?» Так что. Вы видите, я думаю, что инженеры становятся намного выше. Теперь они больше думают на уровне продукта, потому что это. И это будет продолжаться, в отличие от того, что раньше они думали: «Хорошо, но как мы напишем это в коде?» Как это было для вас? Потому что многие инженеры, с которыми я разговариваю, когда они параллелизуют работу, возникает много всего в плане мышления и исполнительной власти, и в конце дня они измотаны. Да. Ну, выгорание, потому что вы постоянно подвергаетесь воздействию стимулов, и вы постоянно переключаете контекст, потому что ИИ отвечает вам 20 минут. Это реально. Это абсолютно реально. Я разговаривал с разработчиком на прошлой неделе, и он сказал, что в среду он просто отключился, его мозг просто был в режиме ожидания, потому что он постоянно реагирует. Я думаю, это 100% реально. Как и во всем, я думаю, способ борьбы с этим — это дисциплина. Хорошо. Первый шаг — вы должны осознавать, что вы делаете. Но вы также учитесь чередовать задачи, возможно, над одним и тем же проектом. Они делают разные вещи, верно? Так что работа над средой, которая направляет агента, это ее собственный проект, помимо фактического проекта, который вы пытаетесь построить. Так что я постоянно итерирую между ними. Так что, когда я жду, пока агент что-то завершит, потому что я хочу увидеть, что он делает или как он это сделал, я просто переключаюсь на что-то другое. Я могу начать другую сессию с другим агентом над той же кодовой базой и начать опрашивать агента о кодовой базе. Так что я остаюсь в том же контексте, но не так сильно переключаюсь между проектами. И если я этого не делаю, то происходит то, что мне приходится вводить в сессию: «Пожалуйста, скажи мне, что мы делали последние полчаса?» Так что мне просто нужно, чтобы он напомнил мне, что я сделал. И. Это иногда странно. 100%. Да. Да. Я видел, что Claude Code делает это автоматически. Теперь, если вы выходите из сессии слишком надолго, он дает вам сводку того, что вы сделали, чтобы вам больше не приходилось спрашивать. Да. Да. Возможно, там есть какая-то проблема с UX, решающая ИИ. Я думаю, что владение и когнитивный долг, о котором мы уже упоминали, станут очень важной темой, которая будет отличать инженеров, которые на самом деле, возможно, не заботятся об этом ремесле или о своей работе. И я также разговаривал с Алиасом Мани на прошлой неделе, и он упомянул об этой новости, о которой я не слышал, которую он называет «когнитивной капитуляцией». Люди говорят: «Агент просто берет на себя управление, и если это проблема, то это вина агента. И если это работает, то это тоже вина агента». Но что тогда? Это немного я, но они действительно отказываются от того, за что несут ответственность. И я чувствую, что это довольно рискованно. И то, как мы развиваемся, я думаю, разговоры, подобные нашим, невероятно важны, чтобы дать людям перспективу и также оспорить то, что уходит, а что остается частью вашей ответственности. Абсолютно. И самое смешное, по сути, сотрудники дают людям гранату, которой является ИИ, а затем говорят: «Не взорвите гранату, но используйте ее». Правильно? Так что с ИИ связано много рисков, но все это будет стандартизировано. Будут политики относительно того, что вам разрешено делать, а что нет с ИИ. И пример, который я привел с Amazon, верно. Они уже провели различие в политике между вашим кодом, который более критичен, чем другой код, и тем, как он должен быть проверен. Так что мы просто увидим то же самое. И это будет просто еще одна, я думаю, форма части процесса для инженеров-программистов, верно, где вам нужно определять вещи, где, если вы просто хотите « YOLO» это, хорошо, давайте не будем трогать биллинговую систему, пожалуйста. Я думаю, что это скоро станет нормой. И да, а также большая часть работы по ревью, которую мы не хотим делать, мы можем передать ИИ. Так что идея не делать код-ревью приходит. Я имею в виду, это своего рода загруженная идея, верно? Но когда вы пытаетесь это сделать, возникает много осознаний, верно? Это дешевые победы, такие как «защитные механизмы», которые детерминированы, которые выполняются дешево и быстро. А затем разговор смещается в сторону архитектуры и спецификаций и большей валидации спецификаций заранее. Затем затем код позже. И, соответственно, даже когда вам приходится просматривать архитектуру позже как человек, вы все равно можете использовать ИИ для этого, верно? У вас есть разговор с ИИ. Возможно, со специализированным агентом, которого вы специально настроили для проверки на предмет нарушений определенного типа архитектуры, которую вы пытаетесь реализовать в своем проекте. Так что вы также можете выполнить автоматическое сканирование всех ваших изменений, изменений кода с помощью ИИ, а затем использовать это как отправную точку для изучения этого как человек, верно? Так что вы все еще можете автоматизировать многое. И дело просто в том, хорошо, куда мне смотреть? Куда мне не нужно смотреть? Да. В противном случае я не вижу, как. Как мы масштабируем часть ревью? Вы знаете, генерация кода в десять раз быстрее или в сто раз быстрее. Давление будет на все системы, которые идут ниже по течению от этого. Абсолютно. И частью этого является ревью с человеком в цикле. Так что вам нужно постараться минимизировать это, насколько это возможно. Да. Я чувствую, что входные данные мы, вероятно, можем масштабировать быстрее, верно? Мы можем просто реализовать больше идей и проверить вещи в продакшене с помощью различных тестов. Процесс ревью — это действительно вызов. И некоторые из вещей, которые вы упомянули, я вижу их как ингредиенты для решения этой головоломки. Это процесс код-ревью, и полное отсутствие человека в цикле. Если это, скажем так, большая цель, к которой мы стремимся, даже если это может быть нереально сейчас с моделями, которые у нас есть, я вижу там «защитные механизмы». Я вижу, как мы захватываем как можно больше поведения и функциональности в тестах. Я не думаю, что должна быть причина не писать тест, потому что вы можете просто сгенерировать тест в соответствии с желаемым поведением, верно? Если вы исправляете ошибку, обязательно сделайте из нее тест. Это уже была хорошая практика, но сегодня нет причин этого не делать. Так что это тенденция. Да. И то, что люди также часто забывают, это то, что генерация теста, небольшой фрагмент кода, шансы на то, что LM сделает это неправильно, намного меньше, чем когда вы говорите LM: «Сгенерируй мне микросервис». Да. Правильно? Так что это еще один момент, который, я думаю, помогает, когда вы пишете «защитные механизмы», потому что даже если вы генерируете их автоматически, что я делаю, шансы на сбой относительно невелики. Я видел и разговаривал с другими командами. Я пытаюсь пригласить одну на подкаст, которая полностью приняла спектр разработки. В рамках своего рабочего процесса они используют одну из спецификационных платформ и очень довольны своим подходом. Вот почему я хочу пригласить их на подкаст, но они упомянули, что не построили, я думаю, это мое предположение. «Защитные механизмы», как мы с вами обсуждаем, в рамках их процесса код-ревью. Что они сделали, так это то, что процесс ревью теперь очень сильно вращается вокруг спецификации, и именно это и проверяется. Именно это и проверяется. И я думаю, что у них есть некоторые «защитные механизмы», чтобы убедиться, что все, что содержится в спецификации, также переводится в код определенным образом. Для меня есть только своего рода рискованная часть, которая заключается в недетерминированном поведении, которое может там присутствовать. Но я думаю, что это интересный подход. Да. И на самом деле, хорошо, что вы это упомянули, потому что «защитный механизм» также может означать просто подсказку, верно? Это, я думаю, как начинались «защитные механизмы», если я не ошибаюсь. Но также может быть детерминированная вещь. Подход спецификационной разработки мне очень нравится, но в основном потому, что он дает человеку ясность того, что строится. Если вы дадите это LLM и будете наблюдать, что он делает, вы удивитесь, что через пять минут он начнет отклоняться от ваших намерений, потому что вы не указали что-то достаточно четко, или там была какая-то возможность для интерпретации. Так что вы можете итерировать по своей спецификации, пытаясь сделать ее идеальной. Затем вы переключаете модель, и она больше не работает. Так что, с вашей точки зрения, что вы думаете о спектре разработки? Это то, что работает сейчас, но исчезнет в будущем? Или как вы это видите? Ну, я думаю, что это часть процесса открытия продукта, который мы пытаемся построить. И я думаю, что это чрезвычайно важно, потому что это также может быть использовано для автоматизированных тестов позже, например, для проверки. Мы действительно это сделали? Как мы это сделали? Мы сделали это в соответствии с нашими принципами кодирования? Правильно? Это вопросы, которые вы затем можете задать ИИ для исследования, так что спецификации останутся. Люди любят углубляться в спецификации, как будто это код. Это не так, верно? Это просто документ общего понимания. Я бы сказал, что спецификации — это часть поведения. Часть того, что строится. Я считаю, что детальная поведенческая спецификация всего, что вы строите, гораздо важнее. Была идея TDD, что если у вас есть все ваши тесты, и ваше программное обеспечение удалено, но у вас все еще есть ваши тесты, вы можете восстановить свое программное обеспечение. Это одна из идей TDD. И, ну, я видел, как это работает впервые, когда у меня были реализованы поведенческие тесты, которые давали агенту обратную связь, и у меня была спецификация в качестве подсказки для начала реализации. Это был первый раз в моей жизни, когда я видел, как это действительно хорошо работает в моем проекте. Это все еще довольно невероятно. Мне интересно, с существующими кодовыми базами, верно, если тестовое покрытие. Теоретически, многое из этого — теория, поэтому это довольно сложно. Но мне интересно, действительно ли, если бы вы выбросили код, если бы люди занимались TDD в этой кодовой базе довольно долго, сможет ли ИИ действительно сгенерировать код точно так же, как он соответствует зафиксированному поведению. Да. Ну, если у вас есть несколько токенов, которые можно потратить, вы можете попробовать это на выходных. Это кажется интересным экспериментом. Что я заметил, так это то, что крупные компании раньше, до ИИ и генетической инженерии программного обеспечения, я чувствую, что они были первопроходцами, и многие небольшие организации смотрели на хорошие практики, лучшие практики, конвенции и сообщения в блогах о том, что существует и что происходит прямо сейчас. Я чувствую, что игровое поле довольно ровное, потому что все очень быстро развивается. Вы уже упоминали, что за несколько месяцев «сбруи» и их возможности могут измениться, и то, что эффективно, и внезапно то, что возможно сейчас, дает нам очень интересное поле для экспериментов. Как вы обычно экспериментируете и обучаетесь? Да, это концепция попытки наверстать упущенное, ощущение отставания, но я думаю, что это нормально для всех, кто пытается идти в ногу со временем. Так что мне нравятся проекты. У меня есть несколько разных проектов, которые в разной степени. Один проект, который полностью «вайб-кодирован», полностью. Я никогда не смотрел на код, я только просил его делать вещи. У меня есть один проект, который является глупым продуктом, это тот, который я использую для подхода TDD с поведенческой спецификацией, поведенческими тестами, «защитными механизмами», где тесты — это такой подход. У меня есть другой проект, состоящий из нескольких микросервисов, который гораздо сложнее, который в основном управляется, и я продолжаю добавлять к нему функции, используя эти различные методологии, которые настроены для этого проекта, и просто наблюдаю, что делает ИИ, что он делает неправильно, и так далее, и чаще всего я вижу, что они либо делают что-то странное, и тогда я немедленно делаю это частью моих стандартных «защитных механизмов». Так что у меня есть своего рода репозиторий. У нас есть стандартные настройки проектов для разных языков, и они предварительно загружены определенным типом «защитных механизмов», которые я нашел полезными в проекте, который я делаю. Так что экспериментирование включает в себя много общения с LM. Я действительно нашел полезным просить LM объяснить себя. Так что, если я даю ему сложную задачу, обычно я спрашиваю: «Пожалуйста, скажи мне, как ты понимаешь то, что мы пытаемся сделать». Очень простой вопрос. Так что я пытаюсь выяснить, что модель поняла, что я сказал, по сравнению с тем, что я сказал. И вы можете видеть, как модели интерпретируют вещи по-разному. И это дает вам представление о том, знаете ли вы, «личности» — это слишком далеко идущее понятие, но это своего рода тип, знаете ли, какой тип «личности» демонстрирует эта модель, какой тип поведения она демонстрирует? Вероятно, лучший термин для использования. Да. Так что я делаю это много. Я также пробую новейшие инструменты, которые они нам дают. Например, когда появились суб-агенты, я попробовал их. Я пришел к выводу, что у меня нет никакой видимости того, что делают агенты. Например, с чем они общаются? У меня нет интроспекции. Так что тогда я бы сделал, я попытался бы получить интроспекцию к этому, и я построил бы свою собственную систему, где я просто сказал бы ей: «Пожалуйста, запусти суб-агента, но сделай это в другом терминале, чтобы я мог фактически видеть, что ты отправил этому другому агенту». И да, ну, вы увидите самые странные вещи, которые модели говорят друг другу, верно? Вы уже можете видеть, как модели начинают отклоняться, например, на первом шаге, когда они передают задачи и так далее. Так что попытка заглянуть под капот как можно больше, какая информация передается, мониторинг того, что делают агенты, когда они говорят друг с другом. Я думаю, что это невероятно важные вещи для самой оркестровки, и я больше всего узнал, глядя на такие вещи, на то, что делают модели и как они говорят друг с другом. Так что я думаю, что именно так я чаще всего уточняю свое понимание того, как работают модели, а также пытаюсь применять то, что они нам дают в виде инструментов. Если кто-то слушает, и они хотят применить генетическую инженерию программного обеспечения к своему образу работы, к части кода, которая уже работает в продакшене, и, вероятно, команда уже приняла некоторые практики или вообще нет, и они хотят что-то начать. Какой первый шаг вы бы порекомендовали для отдельного разработчика или для кого-то в. Они могут быть в команде. Я думаю, это самый глубокий случай. Я бы сказал, что самое простое — это начать с «защитных механизмов», статических проверок. Правильно? У вас должен быть, конечно, форматировщик кода. У вас должен быть линтер. Попробуйте написать несколько правил SEMgrep, которые обеспечивают соблюдение некоторых лучших практик, которые вы видите в своей кодовой базе. Вы можете спросить ИИ, например, какие антипаттерны мы используем в кодовой базе. Напишите простой тест, который их помечает. Если вы работаете в команде, у вас есть командное обсуждение. Вы знаете, если вы столкнетесь с сопротивлением, ну, тогда попробуйте следующее лучшее. Очень трудно убедить людей, которые не верят в идеи улучшения кодовой базы путем ее оптимизации с помощью тестов или «защитных механизмов». Но вы можете запускать все эти вещи на своей локальной машине. Вам не нужно заставлять всех их использовать, но вы можете использовать их для кода, который вы пишете сами. Знаете, сравните это с умным скриптом, который проверяет, создали ли вы этот файл или кто-то другой, и где вы применяете свои правила «защитных механизмов». И ключевой момент в том, что вы должны измерить или, по крайней мере, получить представление о том, как это работает с этими руководящими принципами, которые вы установили, по сравнению с их отсутствием. Потому что, как только вы увидите, что они на самом деле помогают вам делать больше работы и меньше быть в цикле, вы не вернетесь. Я не думаю, что это становится действительно удобно, не беспокоиться об этом и постоянно нянчиться с моделью. Я могу это видеть, этот термин «нянчиться». Я пытаюсь избавиться от него в разговорах, которые у меня есть с людьми, и я пытаюсь выяснить, какой лучший способ. Это может быть действительно своего рода экспериментирование и переход в этот цикл непрерывного улучшения. И это может быть то, что вы захватываете поведение, как вы хотите, как «защитные механизмы» для агента, чтобы затем подобрать и сделать что-то с этим. И это также может быть обратная связь, которую вы получаете от своей команды, верно? Если вы и ваш агент создаете pull request, а затем есть обратная связь от вашей команды, вы также можете затем зафиксировать это в большем количестве «защитных механизмов». И есть еще одна идея. Так что вы можете просто сказать: «Эй, проанализируй мои журналы сессий по этому проекту. Он будет в вашей домашней папке .cloud, и мы начнем просматривать все ваши разговоры». И вы можете спросить: «Видишь ли ты какие-либо закономерности, где мне приходилось неоднократно напоминать тебе о чем-то?» Так что вы можете извлекать данные из своих журналов сессий, чтобы увидеть, где модель ошибается, где вам всегда приходится ее исправлять. Превратите это в статическую проверку. Правильно. Это похоже на продукт, который я хотел бы иметь. Да. Что на самом деле не плохая идея. Ну, на самом деле это навык, который вы можете просто, ну, использовать навык, чтобы написать вам этот навык. Это очень просто. Это занимает около 15 минут, а затем вы можете его использовать. Абсолютно. Ранее мы упоминали, что разные «сбруи» могут давать разные результаты. И в некоторых организациях некоторые люди получают только одну «сбрую», и это все. Правильно. Мы полностью перешли на GitHub Copilot, потому что у него есть все модели, знаете ли, но это только одна «сбруя». Что бы вы порекомендовали этим людям или этим организациям? Это очень сложный вопрос, если вы можете выбирать свои инструменты как разработчик. Я не думаю, что какой-либо разработчик будет действительно счастлив с этим. Образование в этом случае поможет. Я имею в виду, есть исследования, которые сравнивают «сбруи», и у нас достаточно доказательств, чтобы предположить, что полагаться на один конкретный инструмент не позволит нам оставаться на передовой. Так что есть много аргументов. Я понимаю, что организация имеет это, это, это, это желание стандартизировать вещи. Но это не похоже на то, что вы выбираете продукт, а затем используете его в течение пяти лет. Так работает ИИ. И это просто требует понимания того, что на самом деле означает ИИ. Да. Я чувствую, что это отсутствует. Правильно? Потому что мы сейчас вышли за рамки моделей, в частности. И «сбруя» может иметь большее значение, чем сами модели. На бумаге я думаю, что модели легко понять, потому что мы говорим об этом уже давно. Правильно. Это уже 2-3 года. У нас были непрерывные итерации по моделям, и теперь я чувствую, что скорее в этом году, возможно, даже в конце прошлого года, разговор о «сбруях» действительно начал возникать. Да. Ну, есть еще кое-что, что вы можете сделать как соло-разработчик. Попробуйте выяснить, в чем ваша конкретная «сбруя» хороша. Может быть, она хороша в написании документации к pull request. Может быть, она действительно хороша в отладке. Так что попробуйте найти эти варианты использования, где вы все еще можете ее использовать, а затем используйте ее для этого. Да. Да, абсолютно. Для людей, которые слушают, я пытаюсь сделать эту новую вещь, потому что я хочу вашего совета относительно того, какой эксперимент вы хотите, чтобы люди провели, если у них есть свободное время, и они могут провести один эксперимент в качестве своего бюджета времени, что бы вы хотели, чтобы они сделали? Ну, это зависит от того, где вы находитесь в организации, я бы сказал. Но для разработчиков, я имею в виду, есть несколько вариантов, и это зависит от того, чего вы хотите. Хотите ли вы стать лучше в генетической инженерии, например, работать с ИИ? Хотите ли вы стать лучше в создании своих «защитных механизмов»? Хотите ли вы лучше понять, как ведут себя модели? Это первый вопрос. Чего вы хотите? Есть бесконечно много разных вариантов того, что делать. Я бы рекомендовал, если вы хотите начать с «защитных механизмов», начните смотреть на Semantic Grep. Давайте попробуем закодировать некоторую обратную связь от человека, которую вы дали бы в PR, как правило, и пример, который я привел ранее с отсутствием значений по умолчанию в параметрах метода, это может быть один пример. Другой пример может быть: «Хорошо, давайте никогда не будем игнорировать ошибки». Любая ошибка должна всегда распространяться, что-то в этом роде. Просто начните экспериментировать с этим и посмотрите, как ваш агент реагирует в этой среде. Так что настройка, я думаю, «защитных механизмов», чтобы вы могли начать улучшать их и итерировать по ним. Я думаю, что это очень ценно. И вы увидите, я бы утверждал, что вы увидите победы очень быстро, даже если вы можете просить о вещах. Но у нас сначала были статические проверки кода, а теперь вы делаете это таким образом, что вы кодируете свои человеческие предпочтения в виде правил, верно? Так что настраивается для вашего конкретного проекта. Флориан, большое спасибо, что пришли. Это для меня. Это действительно хорошо. Спасибо. Если вы все еще с нами. Дайте мне знать в разделе комментариев, что вы думаете об этом выпуске, и мы увидимся в следующем.