📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

Software Engineering Is Becoming Plan and Review — Louis Knight-Webb, Vibe Kanban

AI Engineer20:23

Transcription

[музыка] >> Этот микрофон работает? Да, этот микрофон работает. Как дела? Ух! [ __ ] фантастически. Да, поехали. Хорошо. Эм, это я, это так. Итак, название этого — планирование и обзор, но я думаю, что настоящая суть этого — это, по сути, что мы все будем делать после того, как ИИ станет действительно, действительно хорошим. Я Луи. Я основатель стартапа под названием Vibe Canvas, и я также основал лондонское отделение AI Tinkers, которое является отличным сообществом, если вы находитесь в Лондоне и ищете мероприятия. И вы должны меня послушать, потому что я кое-что сделал, например, попал в проверенный список лидеров SweeBench раньше OpenAI. Этой паре месяцев уже, но в любом случае, приятно знать, что люди, которые говорят, провели некоторое исследование в этой области. Итак, план на сегодня, класс, заключается в том, что я проведу вас через то, почему я пришел к выводу, что, по сути, все инженеры-программисты будут делать весь день — это планировать и просматривать вещи. И я расскажу, как думать о балансировании этого, если это то, что вы делаете весь день. Я расскажу о временном горизонте и о том, как агенты работают дольше, и как это меняет поведение работы. А затем в конце мы закроем мою компанию. И [хмыкает] мы перейдем к этому позже. Итак, давайте начнем. Все — это план и обзор. Итак, работа, которую мы, инженеры-программисты, делаем. Кто здесь все инженеры-программисты, верно? Да. Хорошо, большинство людей. Мы планируем, мы пишем код, мы просматриваем код и мы просматриваем код других людей. Примерно так выглядит наша работа. Соотношение до появления GitHub Copilot было примерно таким для меня. Я знаю, что это зависит от того, работаете ли вы в большой или маленькой компании и тому подобное, но большая часть работы заключалась в написании кода, а не в планировании и просмотре кода. И мы видим, что со временем, с такими вещами, как первая версия GitHub Copilot, часть написания кода начинает сокращаться. Итак, вы знаете, появился ChatGPT, внезапно, вы можете генерировать функции и вставлять их, а затем появился Cursor, не Cursor сегодня, а оригинальная версия Cursor, и она может заполнить целую страницу кода. А затем вы получаете Claude Code, и это похоже на "Вау, я на самом деле больше не занимаюсь написанием кода". Так что это ставит интересный вопрос, а именно: если мы раньше тратили 4 часа в день на написание кода, означает ли это, что я теперь получаю 4 часа обратно, если я не занимаюсь написанием кода? Ответ, конечно, нет. Это вытеснило работу. Работа, которую вы или время, которое раньше тратилось на написание кода, переместилось. Оно переместилось на планирование и обзор. Я думаю, это ускоритель. Вы, вероятно, делаете больше за день, но, вероятно, это похоже на то, что вы получаете 20 минут обратно за каждые полчаса, которые вы, вы знаете, тратили на написание кода, а какое-то другое время ушло на планирование и обзор. Поэтому я хочу поговорить об этом. Как выглядит этот новый способ работы? И я думаю, что есть два основных подхода, которые люди используют. Я не буду вдаваться в конкретные детали, например, спецификаций или Playwright MCP, или тому подобного. Я думаю, что на этом мероприятии есть множество увлекательных докладов на эту тему. Я просто хочу концептуально обосновать то, о чем мы здесь сегодня говорим. Итак, первый способ — это подход, основанный на планировании. Здесь вы тратите много времени на начальном этапе планирования работы, которую вы хотите, чтобы агент кодирования выполнил. Так что признаками того, что вы занимаетесь этим типом работы, вероятно, будет то, что вы пишете очень подробный документ с планом, файл markdown. Вы, возможно, используете одну из этих спецификационных систем. Вы опрашиваете. Итак, я видел некоторые интересные вещи, где модель неоднократно задает вам вопросы, пока не исчерпает все возможные вопросы о том, какая работа должна быть выполнена. Преимущества этого, конечно, заключаются в том, что вы тратите меньше времени на просмотр этой работы, потому что вы инвестировали время заранее, устраняя крайние случаи, предоставляя моделям как можно больше информации о работе, которую вы пытаетесь выполнить. Результатом этого будет то, что модели реже [ __ ] ошибаются, и вы получите лучшие результаты, и, вероятно, меньше раундов обзора. Недостаток в том, что вам приходится тратить больше времени на планирование, но это же очевидно, не так ли? Другой способ сделать это, другой большой способ работы с ИИ — это то, что вы не определяете очень подробный план, а вместо этого позволяете ему работать, а затем вы тратите больше времени на просмотр этой работы. Итак, преимущества этого в том, что вы можете просто сделать что-то наобум, сказать: "Ах, давайте добавим контактную форму на веб-страницу". А затем, вы знаете, отдача, которую вам придется сделать, это то, что вы будете возвращаться и вперед несколько раз, исправляя стили, разбираясь в вещах. Я бы сказал, что если вы думаете о ценности вашего человеческого времени, и у вас есть выбор, вы всегда хотите делать первое из этих поведений, подход к планированию, по сути, потому что это сэкономит вам много времени. Очень утомительно переключаться туда и обратно с агентом, который выдает вам наполовину выполненную работу, и вы постоянно должны ее просматривать. Я думаю, что еще один способ разбить режимы работы, где один — это план, а другой — обзор, — это подумать о типе вещи, над которой вы работаете. И я думаю, что разработка функций на самом деле сильно отличается от миграций и работ по обслуживанию. И фронтенд сильно отличается от бэкенда. Я пытался обдумать это перед докладом, и вот матрица, которую я придумал, где, по сути, если вы работаете над фронтендом и занимаетесь разработкой функций, действительно невозможно полностью расписать все. Есть так много крайних случаев, и вы знаете, фронтенд очень зависит от состояния. Есть взаимодействия, анимации, стили, есть функциональность. И поэтому лично я считаю, что гораздо лучше быть в курсе событий с агентом кодирования. Так что второе из тех поведений, о которых мы говорили. Но для всего остального, я думаю, действительно возможно быть ориентированным на планирование. Итак, разработка функций на бэкенде, вы почти можете использовать разработку, управляемую тестами. И для всего, что связано с рефакторингом и миграциями, вы, безусловно, можете это делать, и вам вообще не следует быть в курсе всей этой работы. Это все должна быть разработка, управляемая тестами. Итак, я думаю, если бы вам пришлось сжать эту длинную, витиеватую речь в одно предложение, это было бы: 5 минут планирования экономят 30 минут просмотра кода, сгенерированного ИИ. И это, по сути, главное. Другое, что, я думаю, интересно рассмотреть, это то, как вещи работают дольше. Итак, по мере того, как агенты кодирования становятся более способными, то есть модели становятся лучше, улучшается вызов инструментов, вы переходите от вызова очень небольшого набора инструментов к тому, что сейчас, вы знаете, CLI кодирования могут вызывать огромный спектр инструментов и выполнять тестирование и тому подобное. Результатом этого является то, что каждый раз, когда вы отправляете запрос, вы ждете дольше, прежде чем он вернется к вам и скажет: "Привет, Луи, пора тебе что-то делать". Чтобы проиллюстрировать это, я имею в виду, вы знаете, вспомните GitHub Copilot. Он завершает одну строку кода, и это занимает секунды. Затем у вас есть оригинальный Cursor, завершающий один файл, и это занимает, знаете ли, 30 секунд. А затем у вас есть Claude Code, который, знаете ли, в прошлом году работал, возможно, минуту или две, а в этом году я получаю довольно хорошие результаты с выполнением за 5 или 10 минут. И это будет продолжаться, потому что, по сути, мы перешли от того, что вы просите ИИ что-то сделать, и он просто отвечает, к тому, что ИИ запускает проверку типов, а затем ИИ тестирует свое изменение. Я имею в виду, это передний край вещей. И эти вещи занимают все больше и больше времени. Просто возврат кода был очень быстрым. Запуск проверки типов немного медленнее. Запуск Playwright MCP на порядок медленнее, чем что-либо из этого. Но это стоит того, потому что, знаете ли, вы пытаетесь максимизировать, опять же, сколько времени вы тратите или минимизировать, скорее, сколько времени вы тратите на работу с агентом. Так что, если вы можете получить более высокую точность, подождав дольше, это стоящий компромисс. И это, вероятно, передний край, где, если бы мне пришлось прогнозировать, где мы будем через 9 месяцев, я бы сказал, что ИИ начнет тестировать фронтенд-работу, и это будет огромный прорыв. Вы видите некоторые интересные демонстрации этого в Твиттере с, знаете ли, Chrome или Playwright MCP, кликающими по вещам. Реальность такова, что я не встречал ни одного человека, который на самом деле делает это в своей основной разработке. Но я очень взволнован этим, и я думаю, что это будет следующий крупный прорыв, когда, по сути, большая часть обмена данными с моделью будет выполняться самой моделью, потому что она сможет фактически запускать ваш проект, кликать по нему, находить ошибки и убеждаться, что это сделано. Но это ставит интересный вопрос: что произойдет, когда среднее время работы агента превысит, скажем, 5 минут. Потому что я думаю, что 5 минут — это примерно то время, когда вы можете сидеть и ждать чего-то, смотреть логи, скорее всего, более реалистично — просматривать Твиттер, что-то вроде этого. И когда мы пересечем эту отметку в 5 минут, вам придется изменить свое поведение. Знаете, представьте, что эти вещи будут занимать 20 минут. Вы не будете сидеть там 20 минут, наблюдая за логами агента. Вам придется думать о кодировании и всей работе разработчика программного обеспечения совершенно по-другому. Это то, что, я уверен, все видели, это своего рода терминал, который максимально использует параллелизм, верно? Вы запускаете несколько таких вещей одновременно. Скажем, каждая из них занимает 10 минут. Так что способ обойти проблему ожидания — это иметь несколько из них одновременно. Так что, как только вы закончите, скажем, просматривать одну часть работы, другая закончилась, и вы можете перейти к ней. И это, по сути, то, над чем мы начали работать. Итак, это проект, который мы начали около года назад под названием Vibe Kanban. И, по сути, это было попыткой сделать возможным очень легкое распараллеливание агентов. Мы создали кое-что классное. Есть боковая панель, где вы можете создавать несколько рабочих пространств, которые запускают любого агента кодирования, такого как Codex, Cool Code и тому подобное. Когда вы хотите просмотреть код, вы получаете различия. Если вы хотите что-то прокомментировать, вы можете сделать это так же, как GitHub. Если вы хотите что-то предварительно просмотреть или, знаете ли, нажать на что-то и сказать: "Ах, на самом деле сделайте это немного больше или это немного меньше", вы можете сделать и это. И вы, вероятно, видели все это раньше, но вы, возможно, не видели, что это началось так рано, как 14 июня 2025 года. Мы сделали это первыми, клянусь. Итак, соображения. Я думаю, что человеческое поведение изменится, потому что агенты пересекут этот порог в 5 минут. И кто знает, это может продолжаться. Вы можете пересечь часовой порог. Поэтому нам нужны новые интерфейсы, чтобы сделать эту работу потрясающей. Потому что, если вы попытаетесь сделать это с помощью существующих инструментов, это будет отстойно. Вам придется перескакивать между просмотром кода в одном месте, предварительным просмотром в другом. Если бы у меня был список желаний для идеального инструмента для агентов кодирования для разработчиков программного обеспечения, он бы в основном учитывал тот факт, что мне приходится управлять несколькими потоками работы одновременно, чего большинству разработчиков программного обеспечения не приходилось делать. Они просто могли глубоко погрузиться в одну часть работы. Так что все дело в том, что я называю "максимизацией фокуса". Я не знаю, есть ли такое слово. Я его придумываю. Вы услышали это здесь первым. Но это должно учитывать тот факт, что вы не можете выдергивать людей из одного и вставлять в другое каждые 30 секунд, потому что это просто выжигает их мозг, и это не способ жить. Так что, он должен быть построен вокруг того, чтобы получить максимум от человека, чтобы агент мог работать как можно дольше, а затем возвращаться к человеку, а не поощрять модели, где вы постоянно входите и выходите из необходимости вернуться к контексту того, что делает конкретный агент. Он должен помочь вам писать задачи и планировать вещи, очевидно. Он должен помочь вам тестировать работу, потому что именно этим будет заниматься большая часть работы человека. И он должен помочь вам проводить обзор кода. Я думаю, очевидно, что большая часть обзора кода выполняется ИИ, но очень немногие компании, которые рискуют деньгами, на самом деле будут выпускать что-то, полностью написанное Vibe, не проверив код. Так что чтение кода, вероятно, то, что большинству людей в этой комнате все еще придется делать. И затем сопровождение изменений до их развертывания, что является своего рода новой развивающейся областью. Так что, в простейшей форме, это как мониторинг запросов на вытягивание GitHub и просто просмотр комментариев и реакция на них автоматически. Большая часть административной работы, связанной с тем, чтобы получить что-то от "я закончил задачу" до "я развернул задачу", — это буквально, знаете ли, следование комментариям и реагирование на них. Итак, я написал этот доклад, я подал этот доклад несколько недель назад. И во вторник я решил закрыть компанию. Так что [хмыкает] у меня была целая часть этого доклада, где я просто рассказывал вам больше о Vibe Kanban и пытался продать его вам, но этого больше не произойдет, потому что теперь компания закрывается. Поэтому я решил вместо этого сделать так, чтобы мы могли закрыть компанию вместе. Я еще не объявлял об этом. Итак, >> [аплодисменты] >> Хорошо, и мы сделаем это, конечно же, с помощью Vibe Kanban. Это должно быть так. Хорошо, так что, пожалуйста, добавьте пост в блог на веб-сайт с этим содержанием. >> [стоны и хмыканье] >> И я заранее написал эту, знаете ли, эту трогательную записку. Хорошо, у нас есть веб-сайт Vibe Kanban. Хорошо, это будет сделано. Я могу провести вам небольшую экскурсию по этому. Итак, он запускает установочный скрипт. Он создал рабочую копию Git. Он запустил установочный скрипт в рабочей копии для установки зависимостей для нашего веб-сайта. И как только это будет сделано, он перейдет к запуску любого выбранного вами агента. Я чаще всего использую Codex, но он поддерживает восемь самых популярных. И он собирается попытаться выяснить, как это сделать. Что еще круто? Вы грустите? Я грущу? Я думаю, я так много об этом думал. Я чувствую облегчение. Знаете, вы управляете компанией несколько лет, и у вас есть эта огромная ответственность, знаете ли, у вас есть сотрудники, инвесторы и все такое, и я не знаю, я чувствую, что груз снят. Мы также можем обсудить, почему мы закрываемся. У нас есть 30 000 активных пользователей в месяц и 25 000 звезд на GitHub. И на самом деле проект будет продолжаться некоммерчески. И мы уже вносим изменения, даже несмотря на то, что мы закрываемся, но на самом деле очень трудно зарабатывать деньги в текущих условиях. Все, кто зарабатывает деньги, делают две вещи. Они продают корпоративным клиентам и перепродают токены. И мы не делали ни того, ни другого. Мы не являемся агентом кодирования. У нас есть кнопка, которая помогает вам запускать что-то в Codex или Cool Code. И поэтому люди могут, у нас есть подписка. Люди тратили у нас около 30 долларов, а затем нажимали кнопку, которая помогала им потратить 3000 долларов на Codex. Это просто неустойчиво. И все наши пользователи — это индивидуальные пользователи, стартапы, небольшие компании. И мы могли бы проделать работу, я думаю, чтобы решить эту проблему и перейти к корпоративным клиентам, но, я не знаю. Это зрелый рынок на данный момент, и играть на восьмом месте не весело. Поэтому мы решили закрыться. Хорошо. Пост в блоге готов. Давайте посмотрим, работает ли он. Итак, у нас есть функция предварительного просмотра в реальном времени, очевидно. Давайте подождем, пока он скомпилируется. Хорошо. Это выглядит хорошо. Так что мы можем перейти к открытию запроса на вытягивание. Несохраненные изменения. Ох. Не знаю, что это такое. Мы узнаем это до ваших инвесторов? Ох, [ __ ] >> [хмыкает] >> Нет. Не волнуйтесь. Большинство из них. На самом деле, некоторых из них мне придется позвонить после этого. Это очень хороший момент. Я полностью намерен закрыть это в прямом эфире на сцене. Хорошо. Хорошо, это сделано. Это пройдет через CDN Cloudflare. >> [аплодисменты] >> Спасибо. Думаю, у нас есть время для одного или двух вопросов. Я не знаю, есть ли у кого-нибудь в аудитории 1 минута 45 секунд. Просто >> Стив? Что дальше? Возьму отпуск, начну еще одну компанию. Мой соучредитель присоединится к лаборатории. И большинство команды уже нашли хорошую работу в Agent Labs и тому подобное. Да. Есть еще вопросы? [хмыкает] Общее чувство, когда вы оглядываетесь назад, положительное или отрицательное? О, да. Нет, я бы ничего не стал менять. Я думаю, это было самое интересное, над чем я работал, и это на переднем крае агентов и всего этого. Я думаю, конечно, я не знаю. Это увеличило мою ценность как человека, сделав это, так что я бы сделал это снова. Да. Вперед. Что самое ценное вы узнали за несколько лет управления компанией? Самое ценное, я имею в виду, просто работать с замечательными людьми. Знаете, мы прошли несколько этапов формирования команды, и команда, с которой мы в итоге остались, была феноменально лучше. Без обид предыдущей команде, но, вероятно, так и есть. Я думаю, и упорный труд тоже. Я думаю, нам потребовалось некоторое время, чтобы понять, что такое настоящий упорный труд. И вы достигаете точки, когда вы сидите там в полночь с командой в офисе в субботу, и все мотивированы, и это, да, вам требуется некоторое время, чтобы понять, как достичь этой точки. И когда вы это почувствуете, вы знаете, как это бывает. Это трудно, пока вы не доберетесь туда, я думаю. Да. 12 секунд. Нет? Хорошо. >> Оглядываясь назад, что бы вы изменили? Что бы я изменил? Я бы нанял кого-то, кто действительно хорош в продаже корпоративным клиентам. Хорошо, большое спасибо. >> [аплодисменты] >> Удачи. >> [музыка]