How AI will change software engineering – with Martin Fowler

Какие похожие изменения вы видели, которые в некоторой степени можно сравнить с ИИ в области технологий? >> Я думаю, это самое большое за мою карьеру. Я думаю, если бы мы оглянулись на историю разработки программного обеспечения в целом, сравнимым было бы смещение от языка ассемблера к самым первым языкам высокого уровня. Самая большая часть этого — переход от детерминизма к недетерминизму, и внезапно вы работаете в среде, которая является недетерминированной, что полностью меняет дело. >> Каково ваше понимание и отношение к "vibe coding"? Я думаю, это хорошо для исследований. Это хорошо для одноразовых, выбрасываемых вещей, но вы не хотите использовать это для чего-либо, что будет иметь какую-либо долгосрочную функциональность. Когда вы используете "vibe coding", вы фактически удаляете очень важную часть чего-то, а именно цикл обучения. Какие новые рабочие процессы или новые подходы к разработке программного обеспечения вы наблюдали? >> Одна область, которая действительно интересна, это Мартин Фаулер — очень влиятельный автор и инженер-программист [музыка] в таких областях, как Agile, архитектура программного обеспечения и рефакторинг. Он является одним из авторов Agile-манифеста 2001 года, автором популярной книги "Рефакторинг" [музыка] и регулярно публикует статьи по разработке программного обеспечения в своем блоге. В сегодняшнем выпуске мы обсуждаем, как ИИ меняет разработку программного обеспечения, и [музыка] некоторые интересные и новые подходы к разработке программного обеспечения, которые позволяют использовать LLM, почему рефакторинг как практика [музыка], вероятно, станет более актуальным с инструментами кодирования на базе ИИ, почему шаблоны проектирования, похоже, вышли из моды за последнее десятилетие, какое влияние ИИ оказывает на Agile-практики, и [музыка] многое другое. Этот выпуск подкаста представлен Statsig, унифицированной платформой для флагов [музыка], аналитики, экспериментов и многого другого. Проверьте заметки к выпуску, чтобы узнать больше о них и нашем другом спонсоре сезона. Если вам нравится шоу, пожалуйста, подпишитесь на подкаст на любой платформе подкастов и на YouTube. Итак, Мартин, добро пожаловать на подкаст. >> Ну, большое спасибо, что пригласили. Я не ожидал, что мы будем общаться лицом к лицу. Это было довольно приятно. >> Так даже лучше. Я хотел начать с того, чтобы немного узнать, как вы пришли в разработку программного обеспечения, что было около 40 лет назад. >> Да. Это было, да, это было бы в конце 70-х — начале 80-х. Да. Я имею в виду, как и во многих вещах, это было своего рода случайно. В школе я явно не умел писать, потому что получал плохие оценки за все, что связано с письмом. >> Правда? >> Да. О, абсолютно. Но я был довольно хорош в математике и тому подобном, и физике. Так что я склонялся к инженерным вещам, и меня интересовала электроника и тому подобное, потому что другая вещь — я безнадежен с руками. Я ничего не могу сделать, что требует силы или физической координации. Так что всевозможные области инженерии и строительства, знаете, я пытался ухаживать за своей машиной, и, знаете, я не мог открутить ржавые гайки или что-то в этом роде. Знаете, это было безнадежно. Но электроника — это нормально, потому что это все очень, знаете, это больше в голове, чем, знаете, вам нужно уметь обращаться с паяльником, но это было все, что мне нужно было делать. А потом компьютеры, и это было легко. Мне даже не нужен паяльник. Так что я как бы дрейфовал в сторону компьютеров таким образом. И это был мой путь в разработку программного обеспечения. Прежде чем я пошел в университет, у меня был год работы в Управлении по атомной энергии Великобритании. Вау. Или "укулеле", как мы ее называем. И я немного программировал на Фортране 4, и это казалось хорошим делом. А потом, когда я закончил свою степень, которая была смесью электронной инженерии и компьютерных наук, я огляделся и подумал: ну, я мог бы пойти на традиционные инженерные работы, которые не были очень хорошо оплачиваемыми и не имели высокого статуса, или я мог бы пойти в компьютерную сферу, где, казалось, было гораздо больше возможностей. И так я просто дрейфовал в сторону компьютеров. И это было до того, как интернет начал набирать обороты. Это было >> Какие, какие, какие виды работ были тогда, на которые вы могли бы претендовать? Какая была, и какой была ваша первая работа? >> Ну, моя первая работа была в консалтинговой компании Coopers & Lybrand, или, как я их называю, "Cheetum and Lightum", и мы давали советы по информационной стратегии в той группе, в которой я был, хотя это не была моя работа. Моя работа заключалась в том, что я был одним из немногих людей, кто знал Unix, потому что я изучал Unix в колледже, и поэтому я присматривал за кучей рабочих станций, которые им нужны были для запуска этого странного программного обеспечения, которое они использовали для помощи им в их стратегической работе, а затем я заинтересовался тем, что они делали со своей стратегической работой, и как-то дрейфовал в это. Я смотрю на это сейчас и думаю: боже, там было много шарлатанства. Но эй, это был мой путь в индустрию, и это позволило мне рано окунуться в мир объектно-ориентированного мышления, и это было чрезвычайно полезно, чтобы перейти к объектам в середине 80-х. >> И, и как, как вы пришли к объектно-ориентированному мышлению, которое тогда, мы говорим, вероятно, середина 80-х, это было очень, как бы радикально? >> И вы сказали, что работали в консалтинговой компании, которая не казалась самой передовой. Так как же два плюс два складываются? Как вам удалось заниматься передовыми вещами? >> Потому что эта маленькая группа занималась передовыми вещами, и они столкнулись с этим парнем, у которого были интересные идеи, некоторые очень хорошие идеи, а также некоторые немного сумасшедшие идеи. И он упаковал это под термином "объектная ориентация", что на самом деле не было так, но это было, знаете, это часть шарлатанства, так сказать. Я имею в виду, это немного жестоко называть это шарлатанством, потому что у него были и очень хорошие идеи. Но это как бы направило меня в этом направлении, и, конечно, со временем я узнал больше о том, что на самом деле означает объектная ориентация, и это привело к моей всей карьере. >> В следующие 10 или 15 лет. Как вы прокладывали свой путь и в конечном итоге оказались в ThoughtWorks, а также начали писать некоторые книги, начали публиковаться в стороне. Как вы прошли путь от новичка в индустрии, полного энтузиазма и просто впитывающего все, учащегося, до того, что вы начали медленно становиться тем, кто учит других? >> Ну, здесь снова куча случайностей, верно? Так, пока я работал в той консалтинговой компании, я встретил еще одного парня, которого они пригласили помочь им работать в этой области, американца, который стал самым большим наставником и влиянием на мою раннюю карьеру. Его зовут Джим Оделл, и он был ранним приверженцем информационного инжиниринга и работал в этой области, и он видел хорошие стороны этих идей, которые эти люди делали, и он был независимым консультантом и учителем, и поэтому он проводил много времени, занимаясь работой в этом направлении. Я ушел из Coopers & Lybrand примерно через пару лет, чтобы присоединиться к этой сумасшедшей компании под названием PEK. И я был там пару лет. Это была небольшая компания. В офисе в Великобритании было всего четыре человека, и это был самый большой офис в компании. >> Вау. [смех] >> Такое. И я увидел немного, знаете, увидев безумие большой компании, я затем увидел безумие маленькой компании. Сделал это пару лет, а затем оказался в положении, чтобы стать независимым, и я это сделал, во многом благодаря Джиму Оделлу, который, по сути, снабжал меня большим количеством работы, а также благодаря другой работе, которую я получил в Великобритании. Это было здорово. Я помню, как уходил из PEK и думал: вот и все, независимая жизнь для меня. Я никогда больше не буду работать на компанию. >> Знаменитые последние слова. >> Именно. И я продолжал. Я хорошо работал как независимый консультант на протяжении 90-х годов, и в это время я написал свои первые книги. Я переехал в Соединенные Штаты в 93 году, и мне было очень, очень хорошо, и, очевидно, с развитием интернета, много всего происходило в конце 90-х. Это было хорошее время, и я столкнулся с компанией под названием ThoughtWorks, и они были просто клиентом. Я просто ходил туда и помогал им. Да. История продолжается. Я встретил Кента Бека и работал с Кентом в Chrysler над знаменитым проектом C3, который является своего рода проектом рождения экстремального программирования. Так что я работал над этим, >> видел экстремальное программирование, видел Agile. Так что у меня были объектно-ориентированные вещи, у меня были Agile-вещи, а затем я пришел в ThoughtWorks, и они занимались большим проектом, большим проектом для них в то время. Все еще sizable, около 100 человек работали над проектом. Так что это sizable кусок работы, и он явно должен был рухнуть. Но я смог помочь им как увидеть, что происходит, так и избежать краха, и они выяснили, как как бы восстановиться от проблемы. Но затем они пригласили меня присоединиться, и я подумал: эй, знаете, присоединиться к компании снова, может быть, на пару лет. Они очень хорошие люди. Они мой любимый клиент. Знаете, я всегда думал об этом так: другие клиенты говорили: "Это очень хорошие идеи, но их очень трудно реализовать". А ThoughtWorks говорили: "Это очень хорошие идеи. Их очень трудно реализовать, но мы попробуем". И они обычно справлялись. И поэтому я подумал: "Эй, с таким клиентом, я мог бы присоединиться к ним ненадолго и посмотреть, что мы можем сделать". Это было 25 лет назад. >> Да. И теперь, переносясь в сегодняшний день, ваш титул уже более десяти лет, главный ученый. >> С тех пор, как я присоединился, это был мой титул при присоединении. >> С тех пор, как вы присоединились. Так что я должен спросить, что делает главный ученый в ThoughtWorks? >> Ну, важно помнить, что я главный никого, и я не занимаюсь никакой наукой. [смех] Титул был дан, потому что этот титул использовался довольно часто в то время для какого-то человека, занимающегося общественными идеями. Если я правильно помню, Грейди Буч был главным ученым в Rational в то время. >> На самом деле. Верно. >> И были и другие люди, которые имели этот титул. Так что это был очень претенциозный титул, но они чувствовали, что он необходим. Это было странно, потому что одна из вещей ThoughtWorks в то время заключалась в том, что вы могли выбрать свой собственный титул. Любой мог выбрать любой титул, который ему нравился. Но я не смог выбрать свой. Мне пришлось взять титул главного ученого. Им не нравились такие титулы, как "флагшток" или "баран", или [смех] или "громкоговоритель", который мне больше всего нравится. И одна вещь, которую ThoughtWorks делает каждые шесть месяцев, и последний вышел только что, это ThoughtWorks Radar. >> И этот последний радар, он вышел, я думаю, несколько дней назад. Это >> Сегодня он был запущен, я думаю. >> На самом деле, это было сегодня. Так что к тому времени, когда это будет в производстве, пройдет несколько недель, но >> на самом деле он очень, очень свежий. Так что я только что посмотрел на него и на вещи, которые он перечисляет. Но я просто перечислю несколько вещей, которые я там увидел, и "принимать", которые являются теми, которые они рекомендуют использовать: pre-commit hooks, ClickHouse для аналитики баз данных, VLM — это для обучения LLM в облаке или локально очень эффективным способом для пробного использования облачного кода, Fast MCP, который является фреймворком MC для MCB-серверов, и они также рекомендуют много различных вещей, связанных, например, с ИИ и LLM, для оценки. Можете ли вы немного рассказать о том, как ThoughtWorks создает этот технологический радар, каков процесс? И он очень, очень, как бы, на пульсе каждый раз, как будто он близок к пульсу индустрии, и опять же, я разговариваю со многими другими людьми. Как люди в ThoughtWorks остаются так близко к тому, что происходит в индустрии? >> Хорошо. Да. Ну, это будет немного история. Хорошо. Это началось чуть более 10 лет назад. Его происхождение было одним из тех, что мы действительно продвигали в ThoughtWorks: чтобы технические люди, практики действительно участвовали на различных уровнях управления бизнесом, и одним из лидеров этого была наша бывший технический директор Ребекка Парсонс. Так Ребекка стала техническим директором, и она сказала: "Я хочу консультативный совет, который будет держать меня на связи с тем, что происходит в проектах". Так она создала технологический консультативный совет, и в нем было несколько человек, чья работа заключалась в том, чтобы информировать ее о том, что происходит. Мы встречались, знаете, два-три раза в год. Она включила меня в консультативный совет не столько по этой причине, сколько потому, что я был очень публичным лицом компании. Она хотела, чтобы я присутствовал и участвовал в этом. И изначально это было просто нашим заданием. Мы просто собирались и обсуждали все это. А затем на одной из этих встреч Даррил Смит, который на самом деле был ее техническим ассистентом в то время, сказал: "У нас так много проектов, было бы хорошо получить представление о том, какие технологии мы используем и насколько они полезны, и чтобы лучше обмениваться идеями, потому что мы, как и многие компании, с трудом распространяем хорошие идеи достаточно широко. Я имею в виду, даже тогда, когда нас было всего несколько тысяч, это было сложно, а сейчас нас 10 000". Так что мы подумали: "Хорошо, это хорошая идея", и он придумал идею метафоры радара и колец радара, которые мы видим сегодня, и у нас была небольшая встреча, и мы создали радар. И это привычка: если мы делаем что-то для внутренних целей, мы стараемся сделать это публичным. >> И это всегда было сильной частью этики ThoughtWorks, это часть того, почему я там, конечно, знаете, мы просто, мы говорим обо всем, что мы делаем, и мы делимся всем, мы отдаем наш секретный соус все время. Так мы и сделали, и люди были очень заинтересованы, и поэтому мы продолжали это делать. Теперь процесс изменился, изменился немного со временем. На той первоначальной встрече многие из присутствовавших были непосредственно вовлечены в проекты, консультируя клиентов все время. Теперь, когда мы выросли на порядок, это гораздо труднее сделать. И мы также создали больше процессов, где люди могут отправлять "блипы", номинировать их. "Блип" — это точка на радаре, запись. >> И они идут к кому-то, кто связан географически или по линии бизнеса или по технологии, или по чему-то еще, и говорят: "Эй, мы думаем, что эта технология интересна". Они кратко расскажут нам о ней. А затем они кратко расскажут членам того, что теперь называется группой Doppler, потому что мы делаем радар. Да. Я имею в виду, мы можем быть немного свободны с нашими метафорами временами. И затем на встрече мы решим, какие из этих "блипов" включить в радар, а какие нет, и, очевидно, вы получаете некоторое перекрестное опыление, потому что кто-то скажет: "О, да, я тоже говорил с кем-то об этом", и это очень упражнение снизу вверх, и именно так оно создается сейчас. Так что у нас будут эти сессии сбора "блипов" примерно за месяц или два до встречи по радару, и мы постепенно их отсеиваем, а затем на самой встрече мы проходим их по одному, и для меня это немного странно, потому что я так далек от повседневной жизни в наши дни, что это просто этот ряд технологий, и я понятия не имею, что большинство из них такое, но интересно услышать, и иногда я цепляюсь за определенные темы или что-то в этом роде. И это была важная часть микросервисов около 10 лет назад, потому что это появилось через этот процесс радара, и мы собрались с Джеймсом Льюисом, и в итоге написали об этом гораздо больше. Но это действительно то, что происходит: мы проходим этот процесс выявления всего этого. >> Да. И аналогия с радаром, я знаю, что некоторые компании также принимают идею, которую, кстати, ThoughtWorks поощряет, говоря: "Создайте свой собственный радар, примите его в свою компанию". Вы можете, я думаю, у них даже есть инструменты для этого. Мне очень нравится, как ThoughtWorks никогда не говорили: "Это вещь для индустрии". Они сказали: "Это вещь для нас. Это то, что мы видим. Это то, что мы рекомендуем нашим командам, нашим членам команды или, возможно, нашим клиентам рассмотреть". Или есть также, мне нравится, что есть "удержание", может быть, просто будьте осторожны. Мы не видим больших результатов с этим, и вот причины. И да, я думаю, причина, по которой он кажется свежим, вероятно, в том, что большая часть работы, которую выполняет ThoughtWorks, кажется передовой, потому что все это, половина или треть этого, кажется, связано с самой горячей темой прямо сейчас: ИИ, LLM и все методы, которые люди пытаются использовать, чтобы увидеть, работают ли они, или это то, что мы видим, что действительно начинает работать. >> Да, я имею в виду, что для ThoughtWorks есть несколько тысяч технологов по всему миру, которые выполняют проекты различных видов для самых разных организаций, и радар — это механизм, который, как мы обнаружили, является способом извлечь некоторую информацию из их голов и распространить ее как внутри компании, так и в индустрии в целом. И вы правы, это рекомендуемая вещь для клиентов — пытаться делать свои собственные радары. Это немного отличается, когда это радар клиента, потому что иногда там может быть больше "вот что мы думаем, что вы должны делать" с немного большей настойчивостью, чем мы даем, и также они могут быть немного более избирательными в том смысле, что они могут сказать: "Да, мы просто не заинтересованы в использовании определенных технологий", в то время как для нас это случай, если наши клиенты это делают, то мы узнаем об этом, мы должны использовать это. >> Конечно, радар полон множества вещей, связанных с ИИ и LLM, потому что это огромное изменение в моей профессиональной карьере, это, безусловно, самое большое технологическое инновационное изменение, которое происходит. Оглядываясь на вашу карьеру, какие похожие изменения вы видели, которые можно в некоторой степени сравнить с ИИ в области технологий? >> Я думаю, это самое большое за мою карьеру. Я думаю, если бы мы оглянулись на историю разработки программного обеспечения в целом, сравнимым было бы смещение от языка ассемблера к самым первым языкам высокого уровня, что было до моего времени, когда впервые появились COBOL и Fortran и тому подобное. Я бы предположил, что это был бы аналогичный уровень сдвига. >> Так вы начали работать с Fortran, и вы, вероятно, знали людей, которые все еще занимались ассемблером, или, по крайней мере, знали некоторых людей из того поколения. >> Был немного ассемблера вокруг, когда я работал, из того, что вы подхватили в то время. >> Было ли это смещение с точки зрения мышления или, знаете ли, потому что это было большое изменение, вам действительно нужно было знать внутренности оборудования и инструкции и различные >> Я очень мало занимался ассемблером в университете, но это было очень полезно, потому что я никогда не хочу делать это снова [смех]. >> Очень мудро. Но что вы усвоили с точки зрения того, что нужно было изменить, и как это изменило индустрию, просто переход от в основном ассемблера к в основном языкам высокого уровня? >> Ну, для начала, как вы сказали, вещи были очень специфичны для отдельных чипов. Инструкции были разными на каждом чипе. Знаете, как и регистры, где вы получаете доступ к памяти. У вас были эти очень запутанные способы делать даже самые простые вещи, потому что ваша единственная инструкция была для чего-то вроде "переместить это значение из ячейки памяти в этот регистр". И вы всегда должны были думать на этих очень, очень низкоуровневых формах, и даже очень относительно слабый язык высокого уровня, такой как Fortran, по крайней мере, я могу писать такие вещи, как условные операторы и циклы, иначе это в моих условных операторах в Fortran 4, но я могу по крайней мере использовать "if" и я могу получить одну инструкцию, я не могу сделать блок инструкций, я должен использовать "go-to", но, знаете, это лучше, чем то, что вы можете сделать в ассемблере, верно? И поэтому есть явный сдвиг от аппаратного обеспечения к мышлению в терминах чего-то более абстрактного, и я думаю, что это очень, очень большой сдвиг. А затем, конечно, как только я использую Fortran, я могу быть в некоторой степени изолирован от аппаратного обеспечения, на котором я работаю. Я сейчас работаю на мейнфрейме? Я работаю на мини-компьютере? Я имею в виду, есть проблемы, потому что язык всегда немного отличался от места к месту, но у вас есть степень разделения там. Это было действительно довольно значительным, я думаю. Я имею в виду, я занимался этим только на небольших микропроцессорных устройствах, потому что опять же, это была часть электронной инженерии, так что мы были довольно близки к металлу для некоторой части этого, но вы определенно имели этот сдвиг в мышлении, и я думаю, что с LLM это аналогичная степень сдвига, хотя, как я уже писал об этом, интересная вещь заключается в том, что сдвиг — это не столько увеличение уровня абстракции, хотя есть немного этого, самая большая часть этого — это переход от детерминизма к недетерминизму, и внезапно вы работаете в среде, которая является недетерминированной, что полностью меняет ваше мышление. Мартин только что говорил о том, как ИИ — это самое разрушительное изменение с момента перехода от ассемблера к языкам высокого уровня. Этот переход был не просто изменением языка, который мы используем; он требовал совершенно новых цепочек инструментов. Аналогично, ускоренная разработка с помощью ИИ — это не просто более быстрая доставка; это измерение того, действительно ли то, что вы отправляете, приносит пользу. Именно здесь инфраструктура современного экспериментирования становится необходимой, и наш спонсор Statsig может помочь. С Statsig, вместо того чтобы сшивать разрозненные решения, вы получаете feature flags, аналитику и воспроизведение сеансов, используя одни и те же назначения пользователей и отслеживание событий. Например, вы выпускаете функцию для 10% пользователей. При этом остальные 90% автоматически становятся вашей контрольной группой с той же таксономией событий. Вы можете сразу увидеть различия в коэффициенте конверсии между группами, углубиться, чтобы увидеть, где пользователи, получающие лечение, выбывают из вашего воронки. Затем просмотрите записи сеансов конкретных пользователей, которые не конвертировались, чтобы понять, что пошло не так. Альтернатива — запуск заданий между различными службами для синхронизации сегментов пользователей между вашей службой feature flags и вашим хранилищем аналитики, а затем ручное связывание данных, которые могут иметь разную логику идентификации пользователей. Это большая работа, и она также может пойти не так. У Statsig есть щедрый бесплатный уровень для начала, а цены для команд начинаются от 150 долларов в месяц. Чтобы узнать больше и получить 30-дневную пробную версию для предприятий, перейдите на statsig.com/pragmatic. А теперь вернемся к сдвигу в абстракции с LLM. Можем ли мы поговорить об этом сдвиге в абстракции? Потому что один очень наивный или наивный взгляд на это — сказать: ну, у нас были три уровня, верно? У нас есть ассемблер, где у вас есть команды для оборудования. Вам нужно быть тесно связанным с оборудованием. У нас есть языки программирования высокого уровня, начиная с C, затем Java, затем JavaScript, и где вам не нужно быть осведомленным об оборудовании, вы осведомлены о логике, и что вы, возможно, скажете, ну, у нас есть новая абстракция — это английский язык, который будет генерировать этот код. Вы говорите, что это не скачок абстракции? Почему вы думаете, что это так? >> Я думаю, что это своего рода скачок абстракции. Я думаю, что разница в скачке абстракции меньше, чем скачок детерминизма-недетерминизма, и стоит помнить, что одна из ключевых вещей в языках высокого уровня, которую я не упомянул, когда говорил ранее, — это способность создавать свои собственные абстракции на этом языке. Это особенно важно, когда вы переходите к таким вещам, как объектно-ориентированное программирование, к более выразительным функциональным языкам, таким как Lisp, которых на самом деле не было так много. Я имею в виду, в Fortran и COBOL вы могли делать это в некоторой степени, потому что, по крайней мере, с Fortran вы можете создавать подпрограммы и строить абстракции из этого, но у вас гораздо больше инструментов для создания абстракций, когда у вас есть возможности более современных языков, и эта способность строить абстракции имеет решающее значение. >> Так вы можете создать строительный блок внутри языка, который устанавливает вас, и, конечно, здесь у нас есть, например, Domain-Driven Development, который позже позволяет это делать, и так далее. >> Именно. Я имею в виду, старая поговорка Lisp гласит: на самом деле вы хотите создать свой собственный язык в Lisp, а затем решить свою проблему, используя язык, который вы создали. И я думаю, что такой образ мышления — это хороший образ мышления в любом языке программирования. Вы одновременно решаете проблему и создаете язык для описания типов проблем, которые вы пытаетесь решить. И если вы сможете хорошо сбалансировать эти два аспекта, это приведет к очень поддерживаемому и гибкому коду. Так что создание абстракций — это, я думаю, для меня ключевой элемент языков высокого уровня, и ИИ немного помогает нам в этом, потому что мы можем создавать абстракции немного легче, немного более плавно, но у нас есть эта проблема, и теперь мы говорим о недетерминированных реализациях этих абстракций, что является проблемой, и нам придется научиться целому новому набору трюков балансировки, чтобы справиться с этим. Мой коллега Унмеш Джоши написал пару вещей, которые мне очень нравятся, о его мыслях о том, как, потому что он действительно продвигает это, используя LLM для совместного создания абстракции, а затем используя абстракцию для более эффективного общения с LLM, и я нахожу это очень, очень интересным способом мышления о том, как он работает с этим, потому что он действительно продвигает это направление. Я прочитал кое-что, и я не могу вспомнить книгу прямо сейчас, нам придется покопаться в ней позже, где говорилось, что, оказывается, если вы можете описать LLM целую кучу шахматных партий и описать это просто на обычном английском языке, то LLM не сможет по-настоящему понять, как играть в шахматы. Но если вы возьмете те же шахматные партии и опишете LLM эти шахматные партии в шахматной нотации, тогда он сможет. И я подумал, что это действительно интересно, что вы, очевидно, сокращаете размер токена, но вы также используете более строгую, гораздо более строгую нотацию для описания проблемы. Так что, возможно, это угол зрения, как мы используем LLM. Мы должны придумать строгий способ говорить, и мы можем получить большее влияние таким образом. И, конечно, это имеет большие параллели с идеями Domain-Driven Design в Ubiquitous Languages, а также с некоторыми вещами, над которыми я работал десятилетие или около того назад в области предметно-ориентированных языков и языковых сред. Так что есть некоторые захватывающие вещи вокруг этого, которые будет интересно посмотреть, как они развернутся. >> Да. Да. И я думаю, это первый раз, когда мы видим инструмент, который настолько широк в разработке программного обеспечения, что он недетерминирован, потому что у нас были нейронные сети, например, в прошлом, они не были, но их применение было гораздо более нишевым и не повсеместным. Теперь каждый разработчик, я имею в виду, если вы используете генерацию кода, вы используете недетерминированные вещи, конечно, мы интегрируем их повсюду, пробуя, где это работает. Справедливо ли сказать, что это, вероятно, первый раз, когда мы сталкиваемся с этой проблемой детерминированных компьютеров, которые мы очень хорошо знаем, мы знаем их пределы и все такое, и, конечно, есть некоторые гонки состояний и некоторые экзотические вещи, но теперь у нас есть >> именно проблема, которую нужно решить для >> это совершенно новый образ мышления. У него есть интересные параллели с другими формами инженерии. Другие формы инженерии вы мыслите в терминах допусков, и моя жена — инженер-строитель, она всегда мыслит в терминах допусков. Сколько дополнительного материала мне нужно добавить сверх того, что говорят мне математические расчеты, потому что мне это нужно для допусков, потому что, да, я имею в виду, я в основном знаю свойства дерева, бетона или стали, но мне нужно, знаете ли, идти на худший случай. Нам, вероятно, понадобится немного такого мышления. Каковы допуски недетерминизма, с которыми нам приходится иметь дело, и осознание того, что мы не можем подходить слишком близко к краю, иначе у нас будут обрушения мостов. Я подозреваю, что мы сделаем это, особенно в области безопасности. У нас будут заметные сбои. Я опасаюсь, потому что люди слишком близко подошли к краю в плане недетерминизма инструментов, которые они используют. >> О, безусловно. Но прежде чем мы перейдем к тому, где мы могли бы потерпеть неудачу, какие новые рабочие процессы или новые подходы к разработке программного обеспечения вы наблюдали или о которых знаете, которые кажутся захватывающими, которые мы теперь можем делать с LLM, или, по крайней мере, мы можем попытаться поставить им цель, которая была бы невозможна с нашим старым детерминированным инструментарием? >> Хорошо. Одна область, которая привлекла много внимания, — это возможность быстро создавать прототипы за считанные дни. Это намного больше, чем вы могли сделать раньше. Так что это "vibe coding". Но это больше, чем просто это, потому что это также возможность пробовать исследования. Люди могут сказать: "Эй, я не совсем уверен, что делать с этим, но я могу потратить пару дней на исследование идеи гораздо, гораздо быстрее, чем раньше". И поэтому для одноразовых исследований, для одноразовых небольших инструментов и тому подобного, и включая вещи, сделанные людьми, которые не считают себя разработчиками программного обеспечения. Я думаю, есть целая область, и, знаете, мы можем с полным основанием относиться с подозрением к тому, чтобы заходить слишком далеко, потому что там есть опасность. Но мы также понимаем, что до тех пор, пока вы относитесь к этому в пределах его правильных границ, это очень ценная область, и я думаю, что мы будем, это действительно хорошо. С совершенно противоположной стороны шкалы. Одна область, которая действительно интересна, — это помощь в понимании существующих унаследованных систем. Мои коллеги проделали большую работу в этом направлении год-два назад. И, по сути, идея заключается в том, что вы берете сам код, проводите семантический анализ на нем, заполняете графовую базу данных этой информацией, а затем используете эту графовую базу данных в стиле, похожем на RAG, и вы можете начать исследовать и говорить: "Ну, что происходит с этим фрагментом данных? Какие части кода касаются этих данных по мере их прохождения через программу?" Невероятно эффективно, и на самом деле, если я правильно помню, мы даже включили понимание унаследованных систем в "adopt ring", потому что мы сказали: "Да, если вы работаете с унаследованными системами, вы должны использовать LLM каким-либо образом, чтобы помочь вам понять". >> Так, так, в этом кольце, в радар-листе ThoughtWorks, меньше всего вещей в "adopt". "Adopt" означает, что мы настоятельно рекомендуем вам посмотреть на это, по крайней мере, знаете ли, сам ThoughtWorks смотрит на это. Там всего четыре пункта, и один из них — да, использовать GenAI для понимания унаследованного кода, что, по моему мнению, означает, что вы видели большой успех, что, кстати, освежает услышать. Я не слышал этого так много, и я думаю, это помогает в ThoughtWorks, я уверен, вам приходится работать с большим количеством >> Ну, я имею в виду, это произошло из-за того, что некоторые из людей, которые проделали действительно интересную работу над унаследованным кодом, случайно столкнулись с этим и посмотрели на это и сказали: "Эй, давайте попробуем". И они нашли это очень эффективным, и это также было постоянным интересом для многих из нас в ThoughtWorks, потому что нам приходится делать это все время. И как эффективно работать с модернизацией унаследованных систем, потому что каждая крупная компания, которую вы знаете, старше нескольких лет, имеет эту проблему. >> И у них ее в избытке. >> И особенно простые вещи, люди уходят, верно? Как бы просто. И имея GenAI, который может помочь вам добиться некоторого прогресса, это уже лучше, чем не добиваться никакого прогресса. >> Именно. Так что это две области, которые явно, я бы сказал, являются большими успехами в использовании LLM, а затем есть области, которые мы все еще выясняем. Я имею в виду, я, безусловно, вижу все больший интерес к более интересным вещам, поскольку люди пытаются выяснить, как работать с LLM один на один, чтобы создавать программное обеспечение приличного качества. Мы видим некоторые явные признаки того, как вы должны работать с очень тонкими, быстрыми срезами, небольшими срезами. Вы должны относиться к каждому срезу как к PR от довольно сомнительного сотрудника, который очень продуктивен в плане строк кода, но, знаете ли, вы не можете доверять ничему, что они делают. Так что вам нужно очень тщательно проверять все, когда вы играете с джинном таким образом. Джинн — это термин ДжиК Кента для этого. Или Дасти — антропоморфный осел, как Бита, мне нравится ее взгляд. >> Да. Но используя его хорошо, вы действительно можете ускорить свой процесс. Это не тот вид ускорения, о котором говорят сторонники, но он не тривиален. Определенно стоит научиться как-то использовать это, и это люди вроде Бургиты или Кента или Стива Джагга — это те люди, я думаю, которые продвигают это. Мы все еще, я думаю, учимся делать это. >> Все учатся. Абсолютно. >> И все еще остается вопрос, и большая часть опыта, который мы получаем, — это создание в совершенно новой среде. Так что это оставляет большие вопросы в отношении коричневой среды. Ну, мы знаем, что LLM могут помочь нам понять унаследованный код. Могут ли они помочь нам безопасно модифицировать унаследованный код? [крик] Это все еще вопрос. Я имею в виду, я только что разговаривал с Джеймсом Льюисом, потому что он тоже здесь сегодня утром, и он комментировал, что он играл с Cursor, и он строил что-то вроде этого, и он сказал: "О, я хотел изменить имя класса в не слишком большой программе, и он отправил его делать это". И возвращается через полтора часа, и использовал, знаете ли, 10% своего месячного лимита токенов, и все, что он делает, это меняет имя класса. >> И, и у нас на самом деле есть функциональность в IDE, которая, я до сих пор помню, была передовой, это было, вероятно, 20 лет назад, когда Visual Studio, это даже не была Visual Studio, это был JetBrains, который выпустил расширение под названием ReSharper, которое помогало рефакторить код, и люди платили серьезные деньги, это было около 200 долларов в год или что-то в этом роде, чтобы получить этот плагин, а теперь вы можете щелкнуть правой кнопкой мыши и сказать "переименовать класс", и он пошел и построил граф за кулисами каким-то образом, он пошел и изменил, вы могли переименовывать переменные, и снова это было огромное дело. На самом деле, в Xcode, ID Apple для разработчиков, какое-то время, когда вышел Swift, вы не могли делать эти рефакторинги, и люди были, так что интересно, как некоторые вещи легки, мы решили их, а LLM не очень эффективны в этом, не очень хороши в этом. >> Да. >> Да. И тогда, я имею в виду, он сделал это просто, чтобы посмотреть, как это будет. Потому что он знает, что вы можете просто, я имею в виду, у нас есть это уже давно, так что это как бы забавно. Я имею в виду, но это также доходит до того, что при работе с существующей системой и модификации существующей системы, это все еще действительно неясно. И тогда другая область, которая действительно неясна, как в новой, так и в старой среде, это то, что происходит, когда у вас есть команда людей, потому что большая часть программного обеспечения создается командами и будет продолжать создаваться командами, потому что даже если, и я не думаю, что это произойдет, ИИ делает нас на порядок более продуктивными, нам все равно нужна команда из 10 человек, чтобы построить то, что нужна была команда из 100 человек, и мы всегда будем хотеть этого. Нет признаков снижения спроса на программное обеспечение. Так что мы всегда будем хотеть команды, и тогда, конечно, возникает вопрос: как мы лучше всего работаем с ИИ в командной среде, и мы все еще пытаемся выяснить это. Так что есть много вопросов, у нас есть некоторые ответы, некоторые начала ответов, и это просто захватывающее время, чтобы наблюдать за всем этим. >> Вы упомянули "vibe coding". Каково ваше понимание и отношение к "vibe coding"? >> Ну, когда я использую термин "vibe coding", я пытаюсь вернуться к исходному термину, который, по сути, заключается в том, что вы вообще не смотрите на выходной код. Может быть, вы, знаете ли, мельком взглянете на него из любопытства, но вам действительно все равно, и, возможно, вы не знаете, что делаете, потому что у вас нет знаний программирования. Он просто выдает вам что-то. Так что это мое определение "vibe coding". И мое отношение к нему, как я уже указывал, я думаю, что это хорошо для исследований. Это хорошо для одноразовых, выбрасываемых вещей. Но вы не хотите использовать это для чего-либо, что будет иметь какую-либо долгосрочную функциональность, потому что это, я имею в виду, опять же, это глупый анекдот, но я работал, мой коллега Унмеш, он только что написал что-то, что мы опубликовали вчера. И в рамках этого мы создали небольшой псевдографик возможностей во времени, что является, знаете ли, одним из тех глупых маленьких псевдографиков, которые помогают проиллюстрировать точку. И он попросил LLM создать это. Он описал кривые, которые хотел, и получил результат и поместил его туда. И я посмотрел на него и подумал: да, это достаточно хороший график. Я хочу немного подправить его. Я хочу, знаете ли, метки находятся немного далеко от линий, которые они маркируют, поэтому я хотел бы приблизить их. Так что я открыл SVG того, что создал LLM, и, о, я имею в виду, это было поразительно, насколько сложным и запутанным это было для чего-то, что я сам написал раньше, и я знал, что это, знаете ли, дюжина строк SVG, а SVG — это не совсем компактный язык, верно, потому что это XML, но это было ошеломляюще странно. И я имею в виду, вот в чем дело: когда вы занимаетесь "vibe coding", это будет производить, черт знает что, и часто это действительно так, и вы не можете потом немного подправить это. >> Вам придется, по сути, выбросить это и надеяться, что вы сможете сгенерировать то, что вы пытаетесь подправить. И другая вещь, конечно, которая является разницей, и это сердце статьи, которую написал Унмеш, которую мы опубликовали вчера, заключается в том, что когда вы используете "vibe coding" таким образом, вы фактически удаляете очень важную часть чего-то, а именно цикл обучения. Если вы не смотрите на выходные данные, вы не учитесь. И дело в том, что так много из того, что мы делаем, это мы придумываем идеи, мы пробуем их на компьютере с постоянным взаимодействием между тем, что делает компьютер, и тем, что мы думаем. Мы постоянно проходим через этот цикл обучения, подход к программе, и точка Унмеша, которая, я думаю, абсолютно верна, заключается в том, что вы не можете обойти этот процесс. И то, что делают LLM, они просто как бы скользят по всему этому, и вы не учитесь. И когда вы не учитесь, это означает, что когда вы производите что-то, вы не знаете, как это подправить, изменить, развить и вырастить. Все, что вы можете сделать, это уничтожить это с орбиты и начать заново. Другое, что я иногда делал с "vibe coding", это, о, "vibe coding" как консалтинговая компания, столько проблем для решения, конечно. Но вы правы насчет обучения, насчет обучения как "vibe coding", так и ИИ. Одна вещь, которую я замечаю на себе, это то, как легко, знаете ли, дать запрос, получить кучу выходных данных, и вы знаете, что вы должны просматривать большую часть этого кода либо сами, либо в обзоре кода, но то, что я вижу на себе, это то, что в какой-то момент я начинаю уставать, и я просто позволяю этому пройти. И это также то, что я слышу, когда разговариваю с инженерами-программистами: те, кто работает в компаниях, которые внедряют эти инструменты, что практически каждая компания, это то, что гораздо больше кода выходит наружу, гораздо больше кода для обзора, и [кашляет] они спрашивают: "Как я могу быть тщательным в обзорах кода, когда их становится все больше и больше?" Вы видели подходы, которые помогают людям, как менее опытным, так и более опытным инженерам, продолжать учиться с этими инструментами? Просто подходы, которые кажутся многообещающими. >> Не очень много. Я очень внимательно слежу за тем, что делает Унмеш, потому что его подход очень сильно основан на идее: давайте попробуем создать язык для общения с LLM, работать с LLM, чтобы создать язык для более точного и тщательного общения с LLM, чего именно мы ищем. И я чувствую, что это многообещающий и гораздо более многообещающий подход. Убедитесь, что мы создаем свой собственный специализированный язык для работы с любой проблемой, над которой мы работаем, и я думаю, что это на самом деле приводит к другому, мы говорим о вещах, которые мы знаем, что LLM полезны для, еще одна вещь, и это снова то, что Унмеш подчеркнул, это понимание незнакомой среды. Опять же, я разговаривал с Джеймсом, он работал с, он работает на Mac с C, что не является языком, с которым он очень знаком, используя этот игровой движок под названием Godot. >> Godot. Да. >> Да. Го. >> И он ничего об этом не знает, верно? Но с LLM он может немного узнать об этом, потому что он может пробовать вещи. И если вы возьмете это с исследовательским смыслом, и я имею в виду, я имею в виду, я дошел до того, что ввожу в LLM. О, ну, как мне сделать то-то и то-то в R, что я делал 20 раз, но я все еще не помню, как это сделать. И вы, и исследования, и Унмеш снова делает замечание о настройке начальных сред. Знаете, дайте мне стартовый проект, скелетный проект, чтобы я мог просто начать двигаться. И поэтому такой исследовательский материал и помощь в незнакомой среде, и просто изучение незнакомого набора API и идей кодирования и тому подобного. Это может быть довольно удобно для. >> Я задаюсь вопросом, не является ли это все новым в том смысле, что я помню, знаете ли, один из последних крупных скачков производительности в индустрии около 10 или 15 лет назад был появление Stack Overflow. Так что до Stack Overflow, когда вы искали вопросы в Google, вы натыкались на сайт под названием Experts Exchange, и там был вопрос, и вам приходилось платить деньги, чтобы увидеть ответ, или вам приходилось платить деньги, чтобы получить ответ от эксперта, но обычно за этим ничего не было, даже если вы платили, и большинство из нас, я был студентом колледжа, просто не платили. >> Так что вы просто не могли найти ответ, и вы все были расстроены, но потом появился Stack Overflow, и внезапно у вас появились фрагменты кода, которые вы

мог скопировать, и, конечно, то, что делали многие молодые люди или менее опытные разработчики, даже такие, как я, это просто брали код, вставляли его туда и смотрели, работает ли он. По мере того, как вы становились более опытными инженерами или разработчиками, вы начинали говорить младшим инженерам, например: «Вам нужно понять это в первую очередь, например, или даже если это работает, вам нужно понять, почему это работает». Вам нужно, вы должны читать код. И я чувствую, что мы были, было несколько лет, когда мы переписывались туда и обратно, люди бездумно копировали и вставляли фрагменты. Были проблемы с, я думаю, был вопрос об проверке электронной почты, и самый популярный ответ был не совсем правильным. И оказывается, что хорошая часть программного обеспечения и разработчиков просто используют этот один. >> Я чувствую, что мы уже проходили через это. >> Да, это похожее, но >> возможно, в меньшем масштабе. >> Да. Но даже более усиленное и на стероидах, и с вопросом, знаете ли вы, как будут развиваться события в будущем, потому что кто еще будет писать ответы на Stack Overflow? >> Да. Итак, я я я задаюсь вопросом, не сводится ли все к тому, что вам нужно заботиться о ремесле. Вам нужно понять, что такое вывод LLM, и он там, чтобы помочь вам, и если вы этого не делаете, я имею в виду, вы должны, но если вы этого не делаете, вы в конечном итоге будете не лучше, чем кто-то, кто просто бездумно задает ему вопросы. >> Точно. Да. Я имею в виду, у меня нет проблем с тем, чтобы взять что-то из LLM и вставить его, чтобы посмотреть, работает ли оно, но затем, как только вы это сделали, поймите, почему оно работает, как вы говорите, а также посмотрите на это и скажите, действительно ли это структурировано так, как я хотел бы, не бойтесь рефакторить это, не бойтесь вставлять это, и, конечно же, комбинация тестирования всего, что вы вставляете, что работает, вам нужна проверка, и если вы постоянно делаете это туда и обратно с процессом тестирования, Мартин Фаулер только что говорил о важности тестирования при работе с LLM и в целом при создании качественного программного обеспечения. Говоря о качественном программном обеспечении, я должен упомянуть нашего спонсора сезона, Linear. Недавно я присутствовал на одном из внутренних еженедельных совещаний Linear под названием «Среды качества», и я был совершенно поражен. Это было 30-минутное совещание, которое проводится еженедельно. На этой сессии команда рассмотрела 17 различных улучшений качества за полчаса. 17. Это быстрое и суперэффективное совещание. Бум, бум, бум. Каждый разработчик демонстрирует улучшение качества или исправление производительности, которое он сделал на этой неделе. И это может быть что угодно: от огромных побед в производительности серверной части, которые экономят тысячи долларов, до мельчайших улучшений пользовательского интерфейса, которые большинство людей даже не заметят. Например, одно исправление заключалось в том, что высота окна композитора очень незначительно менялась при переходе на новую строку. Другое заключалось в исправлении этого однопиксельного смещения. Можете ли вы представить, что так сильно заботитесь о деталях? Проведя это каждую неделю в течение многих лет, вся их команда инженеров выработала этот невероятный глаз к качеству. Они ловят эти проблемы еще до того, как они будут выпущены. Теперь один из их инженеров сказал мне, что, поскольку они тренировали эту мышцу со временем, они начали замечать закономерности при создании вещей. Таким образом, в первую очередь выпускается меньше таких мелких проблем. Вот почему Linear ощущается так иначе, чем другие инструменты отслеживания проблем и управления проектами. Тысячи крошечных улучшений накапливаются, и вы чувствуете разницу. Когда вы используете Linear, вы испытываете результаты буквально сотен таких сессий «Среды качества». Томас, их технический директор, недавно написал статью об этом еженедельном ритуале, и я дам ссылку на нее внизу в примечаниях к выпуску. Если ваша команда заботится о мастерстве и создании продуктов, которыми люди действительно любят пользоваться, ознакомьтесь с Linear на linear.app/pragmatic. Потому что, честно говоря, увидев, как они работают вблизи, я понимаю, почему так много лучших инженерных команд переходят на них. А теперь вернемся к важности тестирования при работе с LLM. Я имею в виду, один из людей, на которых я особенно сосредоточен в этой области, — это Саймон Уиллис, и он постоянно подчеркивает важность тестов, но тестирование для него имеет огромное значение, и способность заставить эти вещи работать. И, конечно же, вы знаете, Би — из Fort Works. Мы очень привержены экстремальному программированию. Так что она тоже глубоко погружена в тестирование. Так что она скажет то же самое. Вам нужно действительно сосредоточиться на том, чтобы тесты работали вместе. И, конечно же, здесь LLM испытывают трудности, потому что вы говорите им делать тесты, и я слышу только проблемы [смех] или испытываю их сам, например, когда LLM говорит мне: «О, и я запустил все тесты. Все в порядке. У вас npm test пять сбоев». Да, я вижу некоторые улучшения там, кстати, с кодом, а также с другими агентами. Но да, это недетерминированный аспект. Иногда они могут лгать вам, что странно, верно? Я я все еще не >> Они лгут вам постоянно. На самом деле, если бы они были настоящими младшими разработчиками, как иногда любят говорить, их следует характеризовать, я бы поговорил с отделом кадров. >> Да. Например, на днях у меня был очень странный опыт, который является самой простой вещью. У меня есть конфигурационный файл, куда я добавляю новые элементы, новый JSON, знаете ли, блок, и я добавляю дату, когда я его добавил, просто в комментариях, говоря: «Добавлено», знаете ли, «2 октября», «Добавлено 1 ноября». Это всегда текущая дата. И я сказал LLM: «Не могли бы вы, пожалуйста, добавить эту конфигурацию и добавить текущую дату?» И он добавил ее, и он добавил ее, просто скопировав последнюю дату. И я сказал: «Это не сегодняшняя дата». Я сказал: «О, мне очень жаль. Позвольте мне исправить это для вас». И он поставил вчерашнюю дату. [смех] И и я чувствую, что вам нужно получить этот опыт, чтобы увидеть, что он может вас обмануть даже в такой простой вещи, как сегодняшняя дата, которую, знаете ли, вы можете вызвать функцию, но это зависит от того, какую модель я использовал, как работает эта модель, оптимизирует ли компания, создающая ее, использование токенов или нет, и так далее, и так далее, и так далее. Так что в конце концов, даже для самых простых вещей, вы, как профессионал, работающий над важными вещами, не должны доверять. Да, абсолютно. Никогда. Да, вы должны, вы должны не доверять, но проверять. >> Проверять. Да. Говоря с разработчиками в Thought Works и людьми, с которыми вы общаетесь, в каких областях они успешно используют LLM ежедневно, как мы упомянули прямо сейчас тестирование. Мы также упомянули такие вещи, как прототипирование, но видите ли вы какие-либо другие вещи, которые начинают становиться рутиной? Например, если я делаю эту вещь, позвольте мне обратиться к LLM. Это, вероятно, может мне помочь. >> Да, я имею в виду, я упомянул многое из этого, верно? Прототипирование, понимание устаревшего кода, о да, тот факт, что вы можете использовать его для исследования новых технологических областей, потенциально даже новых областей, если вы, знаете ли, доверяете ему значительно меньше, чем вы бы доверяли Википедии 10 лет назад, это то, что я слышу до сих пор. >> Да, одна интересная область, которую исследует Буржетта, — это разработка спецификаций. Есть идея, что, ну, знаете ли, LLM имеют свои ограничения, но что, если мы четко определим, что мы хотим, чтобы он делал, и дадим ему эту действительно хорошую спецификацию, и, знаете ли, он сможет с этим справиться, он сможет работать долго, у него были итерации и так далее. Каково ваше мнение по этому поводу, и у вас есть чувство дежавю, потому что мы слышали это раньше, верно? Ваша карьера началась примерно с этого, называемого каскадной разработкой. Так как вы видите это похоже, но также и отличается на этот раз? Ну, похоже на каскадную разработку, когда люди пытаются сказать: «Давайте создадим большой объем спецификаций и не будем уделять особого внимания коду». И здесь, я имею в виду, независимо от того, говорите ли вы снова, это то, что вы имеете в виду под спецификацией, это столько внимания уделяется этому, или это делается небольшими частями спецификации, делается плотный цикл, я имею в виду, для меня главное, что вы хотите, вы хотите избежать каскадной проблемы попытки построить всю спецификацию сначала. Это должно быть: сделайте наименьшее количество спецификаций, которое вы можете, вероятно, которое вы можете получить, чтобы добиться некоторого прогресса. Цикл с этим, постройте его, протестируйте его, если возможно, выведите его в продакшн, а затем цикл с этими тонкими срезами. Какую роль спецификация может играть в обоих случаях, можно утверждать, что это форма разработки, управляемой спецификациями. Но для меня важно, чтобы это были плотные циклы, тонкие срезы, такого рода вещи. >> И я знаю, что Биг определенно согласен с этим. Приходит, потому что она, и вы должны быть человеком в цикле, проверяющим каждый раз, что это явно важно, где спецификация и разработка затем снова становятся интересными. Это возвращается к этой идее построения доменных языков и предметно-ориентированных языков и подобных вещей. Можем ли мы создать своего рода более строгую спецификацию для обсуждения, и это, знаете ли, я упомянул, что делал Вуд Меш, используя его для создания абстракции, потому что, по сути, мы говорим, что он дает нам возможность создавать и выражать абстракции в несколько более гибкой форме, чем мы могли бы сделать, если бы мы строили их исключительно в самом коде. Но мы все равно не хотим, чтобы они слишком сильно отклонялись от кодовой базы, верно? Мы все еще хотим, чтобы понятие универсального языка означало, что это тот же язык в нашей голове, что и в коде, и мы видим одни и те же имена, и они делают одни и те же вещи. Структура явно параллельна, но, очевидно, то, как мы думаем, более гибко, чем то, как может быть код. а затем, знаете ли, можем ли мы немного размыть эту границу, используя LLM в качестве инструмента в этой области. Так что это область, которая, по моему мнению, интересна в этом направлении. >> Это интересно, потому что я чувствую, что мы никогда не могли использовать язык, настолько близкий к представлению кода, или бизнес-логику, и это очень ново. >> Да. Хотя опять же, люди, я имею в виду, есть много людей, которые переносят такое мышление DSL в свое программирование, и я бы тоже, я знаю людей, которые сказали бы: «Да, я бы дошел до того момента, когда я мог бы написать определенные части бизнес-логики на языке программирования, например, Ruby, и показать ее эксперту предметной области, и они могли бы ее понять». Они не чувствовали бы возможности написать ее сами, но они могли бы понять ее достаточно, чтобы указать, что было неправильно или что было правильно в ней. И это просто программный код, но это требует определенной степени того, как вы проецируете язык, чтобы получить такую ​​гибкость. И поэтому это, но такое мышление, как попытка сделать внутренний DSL языка программирования или, возможно, построить свой собственный внешний DSL, DSL означает предметно-ориентированный язык, например, если вы работаете с бухгалтерами, у вас будут термины, которые они используют, то, как они их используют, и так далее. >> Да. И то, что вы пытаетесь сделать, конечно, это создать этот коммуникационный маршрут, где не-программист может хотя бы прочитать, что происходит, и понять это достаточно, чтобы найти, что в этом неправильно, и предложить изменения, которые могут быть синтаксически некорректными, но вы можете легко их исправить, потому что вы, как программист, видите, как это сделать. И это цель, и некоторые люди достигли этой цели в некоторых местах. Так что интересно, позволят ли LLM нам добиться большего прогресса в этом направлении и увидеть, как это происходит более широко. >> И я полагаю, это должно быть, я просто предполагаю, поправьте меня, если я ошибаюсь, это должно быть особенно важно в предприятиях, этих очень крупных компаниях, где разработчики программного обеспечения не являются большинством людей, скажем, они составляют 10 или 20% персонала, и будут бухгалтерия, маркетинг, специальные бизнес-отделы, которые все хотят, чтобы для них писали программное обеспечение, и они знают, чего хотят, и исторически были слои людей, переводящих это, будь то менеджер проекта, технический специалист и т. д. Так вы говорите, что может быть довольно интересная возможность или просто эксперимент с LM, что, возможно, мы можем сделать это немного проще для обеих сторон. >> Это мир, который я знаю лучше всего, верно? Это мир. Я имею в виду, я имею в виду, мое ощущение, что вы очень хорошо знакомы с миром больших технологических компаний и стартапов, но этот корпоративный корпоративный мир, конечно, совсем другая история, потому что именно по той причине, которую вы назвали, разработчики программного обеспечения внезапно составляют небольшую часть картины, и происходят очень сложные бизнес-процессы, с которыми нам нужно как-то взаимодействовать, и, конечно же, обычно существует гораздо более серьезная проблема с устаревшими системами. И будет регулирование, будет история, будут исключения из-за всего знания. Я думаю, мы все можем просто подумать о банках, обо всем, потому что там идеальный шторм, верно? У них есть регулирование, которое постоянно меняется. У них есть инциденты, которых они хотят избежать в будущем. У них будут специальные VIP, я не знаю, счета или что-то еще, что они захотят сделать. И, конечно же, у них есть все эти бизнес-подразделения, которые знают свои собственные правила и фреймворки. И они существуют с дотехнологических времен. Некоторые банки существуют уже более 100 лет. >> Да. И помните, банки, как правило, более технологически продвинуты, чем большинство других корпораций в области программного обеспечения. [смех] >> Вы смотрите на хорошую сторону, когда говорите о банках. [смех] >> Вы работали и с некоторыми менее продвинутыми людьми. >> Я имею в виду, да, розничные торговцы, авиакомпании, государственные учреждения, такого рода вещи. Я имею в виду, это было интересно. Я разговаривал с некоторыми людьми, работающими в Федеральной резервной системе в Бостоне, и, знаете ли, они должны быть чрезвычайно осторожны. Им не разрешается прикасаться к LLM в данный момент, потому что, знаете ли, последствия ошибки при работе с крупной государственной банковской организацией довольно серьезны. Так что вам нужно быть очень, очень осторожным с такими вещами. И да, их ограничения очень разные, и это напомнило мне поговорку, что чтобы понять, как работает организация по разработке программного обеспечения, вы должны посмотреть на основной бизнес организации и увидеть, что они делают. Интересно. Я был на этой agile-конференции для Федеральной резервной системы в Бостоне, и они провели мне экскурсию по Федеральной резервной системе, где они обрабатывают деньги. И поэтому я видел места, где они приносят банкноты, которые были привезены из банков, и они их чистят, считают и делают все остальное, и снова отправляют. И вы смотрите на степень заботы и контроля, которые они проходят. Как вы можете себе представить. Я имею в виду, когда вы приносите огромные суммы наличных, и их нужно сортировать, считать и делать все остальное, контроль должен быть очень, очень строгим. И вы смотрите на это, и вы смотрите на заботу, с которой они делают все это, и говорите: «Да, я вижу, почему на стороне разработки программного обеспечения этот образ мышления проникает, потому что они привыкли к тому, что им действительно приходится быть осторожными в каждой мелочи здесь». Многие корпорации, конечно, имеют такое же понятие. Вы занимаетесь авиакомпанией, вы действительно обеспокоены безопасностью. Вы действительно обеспокоены тем, чтобы доставить людей к месту назначения, что влияет на весь ваш образ мышления или должно, и это так, и я полагаю, это причина, по которой мы явно видим, что мы всегда видим разрыв в использовании технологий, потому что у вас есть стартапы, которые являются группой людей, они только что привлекли финансирование или у них нет финансирования. Им нечего терять. У них ноль клиентов. Им нечего терять. Им нужно прыгнуть на последний поезд. Они хотят попробовать новейшие технологии. Часто строят на их основе или продают инструменты для использования новейших технологий, и они здесь, чтобы нарушать правила, и, знаете ли, в середине, когда у вас появляется несколько клиентов в бизнесе, вы начинаете быть немного более осторожными, и, конечно же, знаете ли, через 50 или 70 лет, когда основатели уйдут, и теперь это крупное предприятие, у вас просто будет разная толерантность к риску, верно? >> Точно. Да. >> Но что, что, что я нахожу увлекательным, говоря об этом, это то, что я не уверен, была ли какая-либо новая технология, которая была бы так быстро принята повсеместно. Вы упомянули, что, скажем, Федеральная резервная система или некоторые другие государственные организации могут сказать: «Давайте пока не будем этого касаться», но они также оценивают, похоже, что так. Так что, если они, знаете ли, они одни из самых, я думаю, отстающих в технологическом плане по очень веским причинам, они уже знают об этом или используют это, что, вероятно, означает, что это повсюду сейчас. О, это так. Я имею в виду, это так. Я имею в виду, мы видим это повсюду, но опять же, с большей осторожностью в корпоративном мире, где они говорят: «Да, мы тоже видим здесь опасности». >> И тогда вы видите, как более гибкие компании, с которыми вы работаете, и более ориентированные на предприятия. Что бы вы сказали, является самым большим различием между их отношениями к ИИ, их подходом? Это эта осторожность, или есть другие характеристики, которые большие, более традиционные, менее склонные к риску компании подходят к этому иначе? Важно помнить, что любая из этих крупных корпораций не является монолитной. Так что будут небольшие части этих компаний, которые могут быть очень предприимчивыми, а другие части могут быть очень не такими. И поэтому вы увидите небольшие, я имею в виду, как, знаете ли, когда я начинал в cheetah lightwe, и я был в этой маленькой части, которая очень, очень агрессивно делала действительно сумасшедшие вещи, верно? Я имею в виду, вы найдете это в любой большой организации, вы найдете некоторые небольшие части, делающие что-то. И поэтому вариация внутри предприятия часто больше, чем вариация между предприятиями. >> Хорошо, имейте это в виду. Итак, говоря о рефакторинге, LLM очень хороши в рефакторинге, и вы написали книгу в 1999 году под названием «Рефакторинг». Это второе издание, которое было обновлено через 20 лет. И это на самом деле очень подробная книга, охватывающая различные «запахи кода», которые могли бы показать, где находится код, методы его рефакторинга. На первой странице уже есть, мне очень нравится это. Есть список рефакторингов, я не знаю, как издатель это напечатал, потому что это так необычно, но это прямо здесь, в содержании. Почему вы решили написать эту книгу в 1999 году? Можете ли вы вернуть нас в ту среду и каково было влияние первого издания этой книги? Итак, я впервые столкнулся с рефакторингом в Chrysler. Да. Когда я работал с Кентом Беком, верно, в начале проекта. Я помню, в моей гостиничной комнате, во дворе или где-то еще в Детройте, он показывал мне, как он рефакторит код Smalltalk. И что я имею в виду, я всегда был тем, кто любил возвращаться к тому, что я уже написал, и делать это более понятным. Меня всегда очень заботило, чтобы что-то было понятным. Это верно в моем прозаическом письме и в моем программном письме. И поэтому я знал, но то, что он делал, это брал эти крошечные шаги, и я был просто поражен тем, насколько мал каждый шаг, но как, поскольку они были малы, они не шли не так, и они прекрасно сочетались, и вы могли сделать многое с этой последовательностью маленьких шагов. И это действительно взорвало мой разум. Я подумал: «Вау, это большое дело». Но Кент в то время был занят написанием первой книги по экстремальному программированию, «белой книги». У него не было сил писать книгу о рефакторинге. Так что я подумал: «Ну, тогда я сделаю это». [смех] И я начал, знаете ли, всякий раз, когда я рефакторил что-то, я делал тщательные заметки. И отчасти потому, что мне это было нужно для себя. Как мне извлечь метод, чтобы я не испортил его? И поэтому я делал тщательные заметки по каждому из них. А затем каждый из них превратился в механику в книге по рефакторингу, это был бы этот шаг. А затем я сделал бы пример для каждого из них. И это было первое издание в книге. И я сделал это на Java, а не на Smalltalk, потому что Smalltalk умирал, к сожалению. И Java был языком будущего, единственным языком программирования, который нам когда-либо понадобится в будущем в конце 90-х. И вот что привело к первой книге. И влияние, ну, я имею в виду, и также рефакторинг. Я также должен подчеркнуть, что это не было изобретено Кентом. Я имею в виду, это было очень разработано командой Ральфа Джонсона в Университете Иллинойса в Урбана-Шампейн. Они построили первый браузер рефакторинга в Smalltalk, который является первым инструментом, который делал автоматический рефакторинг. о котором мы говорим сейчас. Это был оригинальный браузер рефакторинга, построенный Джоном Брандтом и Доном Робертсом. >> Сделали это, и когда книга вышла, это вызвало больший интерес. Уже был некоторый интерес со стороны IBM Visual Age, потому что они вышли из Smalltalk. Первоначальные версии Visual Age были фактически построены на Smalltalk. И поэтому они уже в некоторой степени знали, что происходит, но именно люди из Jet Brains действительно захватили воображение, потому что они встроили это в ранние версии IntelliJ IDEA и действительно развили это. Затем вы столкнулись с этим с ReSharper, конечно. И они действительно сделали автоматический рефакторинг чем-то, на что люди могли полагаться, но все же хорошо знать, как делать это самостоятельно, потому что часто вы работаете на языке, где у вас нет такого рефакторинга. Так что приятно иметь возможность вытащить это, и некоторые из них явно отсутствуют, и да, так что влияние, которое он оказал, заключается в том, что рефакторинг стал словом, и, конечно же, как и все эти слова, его ужасно неправильно использовали, и люди используют рефакторинг для обозначения любого изменения программы, чего, конечно, не является, потому что рефакторинг — это очень строго эти очень маленькие семантически сохраняющие поведение изменения, которые вы делаете крошечными, крошечными шагами. Я всегда люблю говорить, что каждый шаг настолько мал, что его не стоит делать, но вы объединяете их, и вы можете сделать удивительные вещи. Я думаю, у нас у всех есть такая история. По крайней мере, у меня была история, когда один из моих коллег или, знаете ли, это мог быть я, но часто один из моих коллег говорил, например, «встаньте и скажите», например, «о, я просто собираюсь сделать рефакторинг», а затем на следующий день «о, я все еще делаю рефакторинг», на следующий день «о, я все еще делаю рефакторинг» и [смех] знаете, что упустили часть маленьких изменений, безусловно. Что заставило вас сделать второе издание книги через 20 лет в 2019 году, что было довольно недавно? Ну, это было ощущение желания обновить некоторые вещи, которые были в ней. Были новые вещи, которые у меня были. Я также беспокоился, что, я имею в виду, когда у вас есть книга, написанная на Java конца 90-х, она немного устарела. >> Да. [смех] >> И хотя основные идеи, как я чувствовал, были здравыми, и люди все еще могли использовать ее, я чувствовал, что вы, давая ей более современную среду. И тогда возник вопрос, останусь ли я с Java или перейду на другой язык, и в итоге я решил перейти на JavaScript. Я чувствовал, что это охватит более широкую аудиторию и позволит описывать вещи менее ориентированным на объектно-ориентированный подход. Так что вместо «извлечь метод» это «извлечь функцию», потому что, конечно, это тот же процесс для функций, а также некоторые вещи, которые вы не обязательно подумали бы сделать в объектно-ориентированном языке. Но в основном это было просто, чтобы получить это обновление, переделать примеры, чтобы действительно, надеюсь, дать ему еще 20 лет жизни, потому что это должно поддерживать меня, пока я не умру, знаете ли. [смех] >> Да. Итак, вы опубликовали эту книгу 25 лет назад или 26 лет назад в индустрии, основанной на ваших взаимодействиях с разработчиками. Как изменилось восприятие рефакторинга? потому что в книге вы специально написали, что вы видите рефакторинг как ключевой элемент в жизненном цикле разработки программного обеспечения, и вы также говорили о том, как при рефакторинге общая стоимость изменения кода со временем может быть намного ниже. Было ли время, когда это было более популярно, или все еще есть, или вы чувствуете, что это немного похоже на то, что рефакторинг вышел из моды, как некоторые из действительно инновационных инструментов того времени, такие как Jet Brains и другие. Они, возможно, не так, как бы, упомянуты, даже если они повсюду. >> Мне трудно сказать. Я имею в виду, опять же, большая часть моего взаимодействия — это с людьми из Thought Works. они, как правило, более осведомлены об этом, чем средний разработчик. Конечно, я читаю много вещей в Интернете, которые заставляют меня просто качать головой >> как описывается даже рефакторинг, не говоря уже об отсутствии его выполнения и, конечно же, в структурированном, контролируемом виде, как мне нравится это делать, потому что мне нравится делать это быстро и эффективно. И, знаете ли, это одна из тех вещей, где дисциплинированный подход на самом деле быстрее, даже если это может показаться странным описывать это так. Но я имею в виду, я должен, по крайней мере, это стало частью нашего языка, люди говорят о том, что делают это. Это есть в этих инструментах, и они делают это очень эффективно. Рефакторинги, которые они делают, я имею в виду, замечательно работать в среде, где вы можете фактически автоматически делать так много из этих вещей. И поэтому я чувствую, что мы определенно добились некоторого прогресса. Возможно, не так много, как я надеялся, но, знаете ли, так часто бывает с этими вещами. >> Заглядывая вперед с инструментами ИИ, они генерируют гораздо больше кода гораздо быстрее. Так что у нас будет гораздо больше кода. У нас уже гораздо больше кода. >> Как вы думаете, насколько ценным будет рефакторинг, думая о вашем предполагаемом значении этих небольших постоянных изменений? И вы уже видите, что что-то из этого важно? >> Я бы не сказал, что я уже вижу это. Но я, конечно, ожидаю, что это будет становиться все более важным. Потому что опять же, если вы собираетесь производить много кода сомнительного качества, но он работает, то рефакторинг — это способ привести его в лучшее состояние, сохраняя его работоспособность. Эти инструменты в данный момент определенно не могут рефакторить самостоятельно. Хотя мы объединились с другими вещами. Адам Торнхилл делает интересные вещи, объединяя LLM с другими инструментами, чтобы получить гораздо более эффективный маршрут, и я думаю, что такой подход к объединению может быть хорошим способом сделать это. Но определенно рефакторинговое мышление и размышление о том, как я делаю изменения, по сути, сводя их к действительно маленьким шагам, которые легко комбинируются. В этом вся хитрость. Маленькость и композируемость. Объедините эти два, и вы сможете добиться большого прогресса. >> Это интересно, потому что сейчас, если вы хотите рефакторить, вам нужно открыть IDE, конечно. И я имею в виду, быстрый способ — это просто использовать встроенные инструменты или перемещать вещи. Что я также обнаружил, это описание этого, когда у меня открыта командная строка с чем-то вроде cloth code или чем-то подобным. Это сложно, или я трачу больше времени на объяснение, чем на выполнение этого небольшого изменения. И я задаюсь вопросом, увидим ли мы больше интеграций в этом, а также, чтобы LLM могли фактически делать это, или некоторые из них могут делать это автоматически, потому что, как вы говорите, это не работает из коробки, но я думаю, что для любого качественного программного обеспечения, я имею в виду, мы все учимся на горьком опыте, что если вы просто оставите это там и не вернетесь и не измените это, когда ваши функции станут просто простыми вещами, когда ваша функция станет слишком длинной, когда ваш класс станет слишком длинным, вы разделите его, иначе вы не поймете его позже. Да, будет интересно также посмотреть, предоставит ли он способ контролировать инструмент. Я имею в виду, одна из вещей, которая меня интересует, это то, где люди используют LLM для описания запросов к реляционным базам данных, которые превращаются в SQL. Вы не знаете, как правильно написать SQL, но если вы введете это в LLM, он даст вам SQL, и вы сможете посмотреть на него и сказать: «О, это правильно или неправильно» и подправить его, и это даст вам начало, верно? И аналогично с рефакторингом, это может позволить вам начать и сказать: «О, вот какие изменения я рассматриваю, и я могу добиться некоторого прогресса». Я имею в виду, особенно когда вы говорите об этих автоматизированных изменениях в больших кодовых базах. Был пример этого, было ли это год назад или около того, когда одна из этих крупных компаний говорила об этом масштабном изменении, внесла изменения в API и очистила код, и они упомянули это как вещь LLM, но это не был LLM. Это был другой инструмент, и я совершенно забыл, как называются все эти вещи. О, у меня 60-летний мозг, и я ничего не могу вспомнить. Это придет мне в голову в какой-то момент. Но на самом деле, это было сочетание, знаете ли, может быть, 10% LLM и 90% этого другого инструмента. Но это опять же дало дополнительный рычаг, который позволил им добиться прогресса. Я думаю, что такие вещи довольно интересны, используя LLM в качестве отправной точки для управления детерминированным инструментом, а затем вы можете видеть, что делает детерминированный инструмент. Я думаю, что здесь есть интересное взаимодействие. Говоря о переходе от рефакторинга к архитектуре программного обеспечения, вы были очень заняты написанием книг в начале 2000-х. Вы написали книгу «Шаблоны корпоративных прикладных архитектур» в 2002 году, и это была коллекция из более чем 40 шаблонов, таких как «ленивая загрузка», «карта идентичности», «шаблон представления» и многих других. И я помню, примерно в это время была ваша книга о корпоративных архитектурных шаблонах, была также книга «Банда четырех», было много разговоров, когда я брал интервью примерно в это время, на собеседованиях меня спрашивали о том, как сделать шаблон фабрики и синглтон и все эти вещи. Архитектура программного обеспечения обсуждалась, мое ощущение было, что во многих местах или гораздо больше. Затем что-то случилось, что-то начиная с 2010-х годов, я больше не слышу, как большинство технологов говорят о шаблонах или архитектурных шаблонах. Как вы наблюдали этот период, когда книга вышла? какое было ее влияние, и почему было важно говорить об этом и внедрять это в индустрию, и как вы видели это изменение, когда мы перестали говорить больше о шаблонах, и почему, по вашему мнению, это произошло? >> Да, я всегда находил это, я имею в виду, что вы делаете с патентами, вы пытаетесь создать словарь, чтобы более эффективно говорить об этих видах ситуаций. Я имею в виду, это похоже на то, как в медицинской сфере они придумывают этот жаргон на греческом и латыни, чтобы более точно говорить о вещах, которые довольно сложны. Да. >> И с патентами мы пытаемся эволюционировать тот же вид языка, за исключением того, что мы делаем это не на греческом и латыни. Я определенно чувствую, что они помогают общению течь более эффективно. Знаете ли вы, когда люди знакомы с этой терминологией. Я имею в виду, вы не смотрите на них как на своего рода, знаете ли, сколько из них вы можете впихнуть в систему, которую вы строите. Это больше чувство того, как вы можете использовать его для описания своих альтернатив и вариантов, которые у вас есть, а также больше думать о том, когда применять вещи или не применять их. Я имею в виду, шаблоны полезны только в определенных контекстах. Так что вы очень хорошо понимаете контекст, когда их использовать. И да, это своего рода стыд, что часть ветра ушла из парусов, возможно, потому, что люди злоупотребляли ими, пытаясь использовать их как своего рода, как прикреплять медали на грудь. Но это все еще может быть очень, я имею в виду, я имею в виду, я работал очень недавно с Унмешем над его книгой по распределенным системам, и я чувствовал, что это был очень хороший способ снова создать язык для описания того, как мы думаем об основных элементах и ​​лучше понять, как работают распределенные системы, что является важным аспектом того, как справляться с жизнью в наши дни, потому что мы все строим такие распределенные системы. Так что я все еще чувствую, что они могут быть очень хорошим способом выразить это. Мне трудно понять, почему они стали менее модными. Может быть, они снова станут более модными. Кто знает? Но я всегда ищу способы распространить знания и сделать вещи более понятными. И я чувствую, что эта идея попытки определить эти существительные, которые мы можем использовать для более точного обсуждения вещей, является хорошим способом сделать это. Я задаюсь вопросом, потому что я видел, я работал в местах, где мы использовали эти вещи, а затем в местах, где мы просто выбрасывали их в окно, никто не использовал их. И разница была, честно говоря, просто в возрасте и отношении компании, потому что в какой-то момент возникло ощущение, что шаблоны предназначены для устаревших компаний. Так что стартапы просто начинали с чистого листа, знаете ли, с доски, знаете ли, UML был идеальным примером, где UML имел довольно строгие правила о том, как рисовать стрелки. И если вы сделаете это правильно, вы даже могли генерировать код и делать все эти вещи. А в стартапах архитектура программного обеспечения все еще существует, но вы просто рисовали ее на доске и рисовали квадрат или круг, и вас не волновали стрелки. И это было просто, я думаю, мы не будем запирать себя в существующих способах делать вещи. И это также своего рода образование, как вам нужно освоить эти вещи. Вам всем нужно иметь общее понимание, и, возможно, это просто сочетание этих двух вещей. И я полагаю, это также поколенческая вещь, знаете ли, каждые несколько лет выходит новое поколение, и так же, как в какой-то момент я был одним из первых в колледже, где было очень круто использовать Facebook, и это были только студенты колледжа, а затем, когда мои родители зашли туда, это было очень некруто использовать Facebook, или мои бабушка и дедушка зашли туда, как будто я перестал им пользоваться, когда они начали им пользоваться. Так что я задаюсь вопросом, есть ли такие волны, идущие туда и обратно, потому что внутри этих стартапов есть язык, как, знаете ли, жаргон, о том, как они говорят об архитектуре, и он начинает формироваться со временем. Вы начинаете видеть это, будь то люди с более длительным стажем, вы получаете все больше и больше жаргона, за исключением того, что он не в книге, которую кто-либо может прочитать, но вам нужно пойти туда или пойти в аналогичную компанию, где они берут жаргон с собой. >> Точно. И люди будут создавать эти жаргоны. И это неизбежная часть общения. Вам нужно, вам нужно не объяснять все с нуля, требуя пять абзацев каждый раз. Если вы постоянно используете этот термин, вы просто делаете из него слово. И тогда каждый создает свои собственные слова. И все, что вы делаете, когда придумываете книгу, такую ​​как «Шаблоны распределенных систем», это говорите: «Хорошо, вот набор слов с большим количеством определений и объяснений к ним. И давайте надеяться, что мы сможем как-то сойтись на этом, чтобы мы могли общаться немного шире». Но также вполне естественно для людей говорить, знаете ли, в нашей маленькой среде мы создаем свой собственный маленький жаргон. Так что мы не обращаем на это внимания, и тогда возникают несоответствия, которые вы замечаете только тогда, когда пересекаете эти разные среды. >> Грейди БХК, кстати, имел интересный взгляд на это. Так что я спросил его о том же, потому что он так много занимался программным обеспечением, он все еще занимается архитектурой программного обеспечения, и он продвинул эту область далеко вперед, и он сказал, что то, что, по его мнению, произошло, это то, что, начиная примерно с 2010-х годов, шаблоны умерли в основной индустрии, я скажу снова, они все еще существуют в некоторых нишах, но примерно в 2010-х годах произошло одна интересная вещь — облако. Облако начало расти, AWS, Google Cloud, и многие компании начали строить похожие вещи. Они начали строить сначала локальные серверные службы, где у вас была большая часть вашей бизнес-логики, затем она переместилась в облако, и Грейди сказал, что эти гиперскейлеры, облачные провайдеры, AWS, например, они построили все эти службы, которые действительно хорошо спроектированы, так что вы можете использовать одну за другой, и это хорошо сделано, вам не нужно слишком беспокоиться о хранении данных, вы просто используете, скажем, DynamoDB или управляемую службу PostgreSQL. Так что внезапно архитектура не так уж важна, потому что эти блоки заботятся о вас. У вас есть эти строительные блоки, и теперь вы говорите об использовании этой базы данных поверх этой системы. Его наблюдение было, возможно, архитектура была решена с помощью хорошо спроектированного строительного блока, который вы могли использовать, и вам не пришлось изобретать велосипед. >> Да. Или, но я подозреваю, что все еще есть шаблоны использования этих вещей, и это то, чем я не занимался, потому что у меня просто не было возможности >> сосредоточиться на этом или, точнее, у меня не было достаточно коллег, которые бы стучали мне в дверь с черновиками статей, чтобы их опубликовать. >> Ну, один шаблон, который я вижу, это то, что каждая компания, знаете ли, называет свою систему. Некоторые имеют причудливые названия, некоторые имеют логичные названия. Но когда вы говорите об архитектуре, вы обычно говорите, например, как, например, в Uber у нас был сервис с эмодзи банка, который назывался, который был перенесен в Gulfream, который, знаете ли, все это звучит не очень осмысленно, если вы снаружи. Иногда у них есть правильные названия, они пытаются с этим, сервис платежного профиля, но затем появляется новая версия, и теперь это платежный про, это PP PP2, в любом случае. Но внутри каждой компании, как вы будете говорить об этих конкретных именах, и вы будете говорить о том, как они работают, насколько они малы, насколько они велики, и это, я думаю, часто является жаргоном. >> Да, это так. Это снова становится частью жаргона крупных организаций, и опять же, вы берете компанию, которая существует гораздо дольше, чем Uber, и, конечно же, этот жаргон встроен в организацию. Вам может потребоваться несколько лет, чтобы просто понять, что, черт возьми, происходит, потому что вам просто нужно столько времени, чтобы изучить все эти системы и как они взаимосвязаны. >> Ну, один из самых увлекательных разговоров, который у меня был много лет назад, был с кем-то очень высокопоставленным в American Express, и мы говорили о том, как он отвечал за перепроектирование их системы для следующего поколения. И он просто получал идеи о том, как популяризировать идеи и донести их. И я спросил, как долго вы работаете над этим? Это было 3 года. И я такой: «Хорошо, так мы, как бы, где вы, вы как бы закончили?» Он говорит: «Нет, нет, это просто планирование, как [смех] мы близки к завершению планирования». И для меня это не укладывалось в голове, потому что за 3 года планирования. Но опять же, как только вы начали понимать масштаб бизнеса, сколько денег, сколько у них устаревших систем, половина того, что он делал, это общение с бизнес-стейкхолдерами, чтобы убедить их или получить их согласие. Я полагаю, это в конечном итоге происходит с большинством компаний, за исключением случаев, когда вы находитесь в более молодой компании или в цифровых или технологических компаниях, основанных в 2010 году или позже. Вы все еще этого не видите, но это может произойти через 10 лет. >> О да, это, конечно, произойдет. О, это интересно. Я помню, я разговаривал с кем-то, кто присоединился к банку, к устоявшемуся банку, и они присоединились из стартапа, и одной из их задач было модернизировать то, как работают банковские дела, и комментарий был: «Теперь мы здесь 3 года, теперь я думаю, что могу понять проблему, у меня есть некоторое представление о том, что можно сделать, что можно сделать, но это просто занимает столько времени, чтобы действительно понять землю, где вы находитесь в этом новом ландшафте, потому что он большой, и он существует давно, и он сложный, и он не логичен, потому что он построен людьми, а не компьютерами. И это не логичная система. И там есть всякая история, потому что всякие вещи происходят, потому что так и так встретились так и так, и имели стрелу с так и так. И все эти вещи как бы проникают со временем, и этот поставщик пришел сюда и был популярен здесь, а затем человек, которому нравился этот поставщик, перешел в другую часть организации. И пришел кто-то другой, кто хотел другого поставщика. И все это накапливается со временем в сложный беспорядок. И любая большая компания будет иметь такой сложный беспорядок, потому что очень трудно не попасть в такую ​​ситуацию. И да, я имею в виду, Uber повезло, что это относительно молодая компания, но она будет, знаете ли, если она выживет через 50 лет, она будет как American Express, верно? >> Да. Вы уже можете видеть изменения, слои процессов и так далее, которые как бы необходимы, как это необходимо, чтобы расти. Говоря об изменениях и итерациях, и agile, вы были частью 17 человек, которые создали Agile Manifesto, и я раньше спрашивал Кена Бека об этом, который был еще одним участником. Можете ли вы рассказать мне с вашей точки зрения, как это произошло, как вы все собрались, как этот довольно хаотичный, я думаю, день разыгрался, и каков был прием, насколько вы помните тогда? Это было в 2001 году, верно? Итак, я имею в виду, происхождение этого, я всегда чувствую, на самом деле было собрание, которое Кент провел примерно за год до того, как мы сделали Agile Manifesto, и это было собрание людей из Extreme Programming, которые работали с Extreme Programming, и мы провели его в этом месте недалеко от того места, где Кент жил в то время, посреди нигде в Орегоне, и он также пригласил некоторых людей, которые не были непосредственно частью группы Extreme Programming, таких как Джим Хаймит, и так далее. Часть обсуждения, которое у нас было, заключалась в том, следует ли Extreme Programming быть относительно узкой вещью, которую описывал Кент в «белой книге», или это должно быть что-то более широкое, что имело бы в виду многие подобные принципы, и Кент решил, что он хочет что-то более конкретное и узкое, а затем возник вопрос.

Ну, что мы делаем с этой более широкой вещью и как она пересекается с такими вещами, как то, что делали люди из Scrum, и всем таким прочим, что привело к идее собрать людей из этих разных групп, и у нас был спор о том, будем ли мы проводить его в Юте, потому что Алистер хотел его в Юте, а затем Дэйв Томас хотел провести его в Ангилье на Карибах, и по какой-то причине мы оказались в Юте, хм, и катание на лыжах, и поэтому мы собрали тех людей, которых собрали, и, конечно, это был случай, кто на самом деле пришел, и потому что, очевидно, было приглашено много людей, которые не пришли, хм, и я не был сильно вовлечен в это, хотя Боб Мартин настаивает, что я был вовлечен, он упомянул какой-то обед в Чикаго, что очень вероятно, потому что я все время ездил в Чикаго по работе в то время. Так что, вероятно, я это делал, но я не помню. Хм, и о самой встрече я на самом деле не очень много помню, что очень жаль. Я, я, я, знаете, проклинаю себя за то, что не вел подробный дневник этих нескольких дней. Хм, я хотел бы знать, знаете ли вы, как мы пришли к этой структуре ценностей, например, которая, я думаю, была действительно замечательной, но я понятия не имею, как это было собрано. Так что, к сожалению, я очень туманно представляю себе фактическое выполнение этого. Я помню, у меня есть довольно четкое воспоминание, хотя мы должны быть осторожны с этим. Я, возможно, вернусь к этому позже, о том, почему Боб Мартин был тем, кто действительно настаивал на том, что я хочу создать манифест, и я думал, о, ну да, мы можем это сделать, сам манифест будет совершенно бесполезным и, конечно, проигнорированным, но упражнение по его написанию будет интересным, >> хм, и это была моя реакция на это, и независимо от того, как я относился к манифесту, я чувствовал, что никто не обратит на это никакого внимания, о, вау >>, но, хм, эй, мы получаем удовольствие от его написания, и мы понимаем друг друга и так далее. И это будет ценность, верно? Мы будем лучше понимать друг друга. >> И тогда, конечно, тот факт, что это оказало некоторое влияние, был своего рода шоком. И тогда, конечно, он, он используется неправильно большую часть времени, потому что есть эта прекрасная цитата Алистера Коббина: ваша блестящая идея будет либо проигнорирована, либо неправильно истолкована, и вы не можете выбрать, что из двух. >> Ну, это также помогает, что манифест состоит из четырех разных строк, и поэтому люди просто выбирают, какую из них они хотят указать. >> 12 принципов. >> О, и 12 принципов, которые Да. и и тот факт, что в начале говорится, что мы раскрываем, хм, и что это непрерывный процесс, и что манифест — это просто то, что у нас есть, как мы дошли до этого, хм, так что это снимок момента времени, где мы были в 20201 году, да, всевозможные тонкости в манифесте, но, хм, я думаю, он оказал влияние в том смысле, что мои чувства были такими, что мы хотели писать программное обеспечение для Fort Works для наших клиентов в 2000 году, и это была настоящая борьба, потому что они не хотели работать так, как мы хотели. Мы сказали, что хотим приложить все усилия к написанию тестов, и мы хотим иметь автоматизированный процесс сборки, и мы хотим делать такие вещи. Мы хотим иметь возможность прогрессировать небольшими шагами. все эти вещи, которые были анафемой. Знаете, нет, у нас должен быть большой план на пять лет, и мы потратим два года на проектирование, и мы создадим дизайн, а затем он будет реализован в течение следующего года или около того, и затем мы начнем тестирование, верно? Я имею в виду, это был менталитет того, как все должно быть сделано. >> Да. Это была просто общепринятая мудрость, верно? >> Да. И наше представление о том, что нет, мы хотели бы выполнить весь этот процесс для подмножества требований за один месяц, пожалуйста. Всего один месяц. И, конечно, мы действительно хотели сделать это за неделю, но, знаете, маленькие шаги. И поэтому для меня великое в гибкости — это то, что мы можем фактически входить в организации и работать гораздо ближе к тому, как мы хотели бы работать. Наши клиенты позволят нам работать так, как мы хотим, в гораздо большей степени, чем мы могли бы делать это в 2000 году. И в этом успех. Я просто хотел, чтобы мир был безопасен для тех людей, которые хотели работать таким образом, чтобы они могли работать таким образом. Да. В результате всего этого произошло множество других плохих вещей. Но, в целом, я думаю, мы немного лучше. >> И вы видите, как вы смотрите, особенно когда вы смотрите на корпоративных клиентов, к которым у вас гораздо больше доступа, вы видите определенное изменение по сравнению с 25 годами назад, когда концепции гибкости гораздо более приняты, работа с клиентом, гораздо более инкрементальная доставка, забывая об этих очень длинных работах, как это просто повсеместно, верно? Можем ли мы так сказать или, по крайней мере, >> Я бы сказал, что мы добились значительного прогресса, но по сравнению с тем, как мы хотели бы, чтобы это было, и где находится наше видение, это все еще бледная тень того, чего мы хотим, чего мы хотели. Я имею в виду, и я подозреваю, что большинство из 17, которые все еще с нами, согласились бы с этим. Мы все еще чувствуем, что можем добиться гораздо большего, чем мы можем, чем мы были, но мы фактически добились материального прогресса. И дело в том, что мы всегда были в такой ситуации, когда, знаете, мы как бы продвигаемся вперед гораздо медленнее, чем нам хотелось бы. Да. Теперь, конечно, ИИ приходит, и он теперь везде, и он будет везде, и одна из вещей с ИИ, основная идея, лежащая в основе гибкости, заключалась в том, что вы вносите инкрементальные улучшения, и чем короче, тем лучше. Теперь с помощью ИИ, особенно с помощью ИИ, будет больше программного обеспечения везде. Оно уже есть. И есть ощущение, что клиенты не обязательно хотят ждать инкрементальных улучшений. Они хотят видеть качество заранее. Как вы думаете, будет ли гибкость работать так же хорошо с ИИ, с еще более короткими инкрементами, или вы думаете, что мы можем начать думать о каком-то другом способе работы с ИИ, ставя качество на первое место и возвращаясь немного к, знаете ли, разработке, основанной на спецификациях, получая версию программного обеспечения, которая просто отличная для начала. Я не знаю, как будет развиваться ситуация с ИИ, потому что мы все еще на ранних стадиях. Я все еще чувствую, что создание вещей в виде небольших фрагментов с человеческим, своего рода, человеческим обзором — это все еще способ делать ставки. Надеюсь, ИИ позволит нам делать эти фрагменты быстрее, >> и, возможно, делать немного больше в каждом фрагменте, но нам нужно, я бы предпочел получать более мелкие, более частые фрагменты, чем больше материала в каждом фрагменте. Улучшение частоты — это обычно то, что, я думаю, нам нужно сделать, и просто быстрее циклировать эти шаги. Именно здесь, я думаю, мы получили наши самые большие выгоды — это благодаря этому более быстрому циклу, а не попытке сделать больше в том же цикле, так сказать. И я все еще чувствую это, когда разговариваю с людьми, которые все еще говорят: знаете, посмотрите на все, что вы делаете в разработке программного обеспечения, и увеличьте частоту. Делайте вдвое меньше, но вдвое быстрее, и ускорьте этот цикл. Ищите способы ускорить это. И также, знаете ли, просто посмотрите на то, что вы делаете. Ищите сигналы в своем потоке и выясняйте, как сократить эти сигналы. Если бы вы могли получить некоторые идеи от идеи до рабочего кода за две недели, как вы сократите это до недели? Просто постоянно пытайтесь улучшить это время цикла. И я все еще чувствую, что это наша лучшая форма рычага в данный момент — улучшение времени цикла. >> Да. И я разговаривал с некоторыми ведущими лабораториями ИИ о том, как они его используют, потому что, конечно, они будут на переднем крае. Они будут использовать это. В их собственных интересах использовать свои собственные инструменты. В Entrophic, команда облачного кода, один из создателей облачного кода Борис поделился тем, как он создал 20 прототипов функции, как индикатор выполнения, когда вы выполняете задачу, как он перечисляет различные шаги и как он показывает, где он находится, и он создал 20 различных прототипов, которые он все попробовал и получил обратную связь, и решил, какой из них использовать за два дня, и он показал мне, на самом деле, у него были видео, он просто записывал их по мере того, как он шел, точный запрос, который он использовал, вывод, и это были интерактивные прототипы. Так что это были не просто, знаете ли, на бумаге, а они были внутри. >> И для меня это было как, вау. Как если бы вы сказали мне, что я создал 20 прототипов, и вы спросили меня, сколько времени это заняло, я бы сказал две недели, может быть, неделю, если бы они были маленькими, как бумажные прототипы. Но поскольку вы все еще можете ускорить это, и это все еще управляемо. Некоторые из них он выбросил. Некоторые из них он поделился с небольшой группой, большой группой. Так что я чувствую, что вы правы в том, как мы не достигли предела того, как быстро мы можем смотреть на вещи. >> Да, это возвращается к циклам обратной связи. Я имею в виду, большая часть этого — попытка, как мы вводим циклы обратной связи в процесс? Я имею в виду, как мы сужаем эти циклы обратной связи, чтобы мы получали обратную связь быстрее, чтобы мы могли учиться, потому что в конце концов, опять же, это сводится к тому, что мы должны учиться тому, что мы пытаемся сделать. Говоря об обучении и поддержании актуальности, как вы учитесь ИИ? Как вы остаетесь в курсе того, что происходит? Какие подходы работают для вас? И какие подходы вы видите, следуют ваши коллеги, которые также остаются в курсе того, что происходит? >> Ну, главный способ, которым я учусь в эти дни, — это работа с людьми, которые пишут статьи, которые попадают на мой сайт, потому что мои основные усилия в эти дни — это размещение хороших статей на моем сайте, и мое мнение заключается в том, что я не лучший человек, чтобы писать эти вещи, потому что я не занимаюсь повседневной производственной работой. Я давно этим не занимаюсь. Единственный производственный код, который я пишу, — это, по иронии судьбы, код, который управляет веб-сайтом. Я все еще пишу код. Я все еще генерирую трассировки стека, но это только в этой очень, очень эзотерической маленькой области. >> Поэтому, в результате, мне лучше работать с людьми, которые на самом деле занимаются такой работой, и помогать им доносить свои идеи и уроки и выражать их как можно большему количеству людей. Так что я учусь в процессе работы с людьми, чтобы они записывали свои идеи, что является очень интересным способом обучения, потому что, конечно, вы очень глубоко вовлечены в процесс редактирования большей части этого материала, и это была моя основная форма. Я провожу некоторые эксперименты, когда у меня есть возможность, не так много, как хотелось бы, но я считаю это вторым приоритетом по сравнению с работой с людьми. Так что, знаете ли, это необходимость только в свободное время, когда у меня есть возможность это делать. >> И, конечно, чтение из тех источников, которые я считаю лучшими. Я имею в виду, к счастью, один из этих лучших источников — это Бита, которая пишет со мной. Так что это хорошо. >> Саймон >> он превосходен. Да. >> Материалы Спитты превосходны. >> Саймон Уиллис, я постоянно слежу за тем, что он делает. >> Я хотел бы иметь его энергию и рабочую скорость для выпуска материалов. На самом деле, я хотел бы иметь вашу энергию, вы, человек, который так много выпускает в эти дни. И поэтому я ищу такие источники. Меня всегда интересует, чем занимаются такие люди, как Кент, потому что, давайте посмотрим правде в глаза, большая часть моей карьеры была основана на идеях Кента, и нет причин останавливаться, если это все еще работает, верно? >> И это те виды источников, я имею в виду, иногда выходят книги, которые проходят через меня, и я их прорабатываю. Так что большая часть этого в этом направлении. Я могу даже иногда смотреть видео, хотя я действительно ненавижу смотреть видео. Так что, да. >> Звучит так, как будто вы находите источники людей, которым вы доверяете, источники, которым вы доверяете. Опять же, ваш блог я очень рекомендую, потому что на нем пишут несколько человек. >> Так что у вас фактически довольно высокая частота глубоких статей об интересных, например, я редко вижу темы, которые обсуждаются в глубину, и поэтому я наслаждаюсь проверкой, потому что из-за этого. Я имею в виду, один из вопросов, над которым я размышлял, когда меня спрашивали, как вы определяете хороший источник информации, и это более общее, это связано с нашей профессией, но, конечно, и с миром в целом, поскольку мы, кажется, находимся в эпистемологическом кризисе, пытаясь понять, что происходит в мире, и в какой-то момент я сяду и запишу это, и я получу более связный ответ от этого, но часть того, что я всегда ищу, — это отсутствие определенности, я думаю, это хорошо, когда люди говорят мне, о, я знаю ответ на это, я обычно гораздо более подозрителен, и я гораздо более сознателен, когда люди говорят, вот что я понимаю в данный момент, но это довольно неясно, я помню одну из моих любимых ранних книг, когда я писал о архитектуре программного обеспечения, я отчаянно искал что-то в мире Microsoft, в отличие от чего-то в мире Java, было много написано в мире Java. Это было примерно в конце 90-х. Многое писалось в Java-мире, не так много в мире Microsoft. И когда я обнаружил этого шведского парня, Джимми Нильсона. И его книга была полна вещей, которые говорили: ну, вот как я чувствую по этому поводу, вот как подойти к этим вещам. Он был очень осторожен все время, очень ясно понимал, что это то, как он чувствовал в данный момент, но он понимал, что вещи могут измениться. С тех пор я очень хорошо узнал Джимми, и он фантастический парень. Но что так сильно меня впечатлило и так сильно повлияло на меня, это то, что я чувствовал в той степени, в которой, о, этому человеку можно доверять, потому что он не пытается дать мне это ложное чувство определенности и уверенности, и я думаю, что это важно, а также кто-то, кто стремится исследовать нюансы и говорить: ну, это работает в этих обстоятельствах, а не когда кто-то говорит мне: о, вы всегда должны использовать микросервисы, или кто-то говорит, вы никогда не должны использовать микросервисы, я имею в виду, оба эти аргумента могут быть полностью отвергнуты. Это когда вы говорите: ах, вот факторы, которые вы должны учитывать, хотите ли вы идти в этом или в том направлении. Когда кто-то отступает и говорит: ах, это компромисс. Есть разные вещи, которые нужно учитывать. Вот факторы, которые вы должны учитывать. И это не будет простой ответ. Вам придется углубиться в нюансы. Опять же, это повышает мою уверенность, потому что опять же, я чувствую, что это кто-то, кто обдумывает эти вещи, а не просто садится на своего рода простой рельс и едет по нему. И я думаю, что с этими источниками вы также можете доверять тому, что все, что мы делаем в разработке программного обеспечения, это будут компромиссы, верно? Самый распространенный ответ на вопрос, как долго это займет, — это зависит. Это зависит от того, делаем ли мы прототип, зависит от того, знаю ли я технологию, и так далее. Так что, если вы читаете источники или обращаетесь к источникам, где они говорят вам, хорошо, в моей ситуации, вы фактически узнаете об их ситуации, и вы можете выяснить, например, хорошо, в этом конкретном случае для них это сработало или не сработало, и позже вы, вероятно, сможете применить это немного лучше, потому что опять же, это очень отличается, если вы собираетесь работать в качестве инженера-программиста в строго регулируемом розничном магазине, которому 70 лет, по сравнению с тем, что вы только что основали совершенно новый стартап, где идите и делайте все, что хотите, ноль клиентов. Огромная разница. Да. И тогда это, я имею в виду, и опять же, вы видите это, я имею в виду, мы видим это с клиентами, многие клиенты говорят, дайте нам ответ, дайте нам поваренную книгу, простой ответ, который мне просто нужно применить. Да. Если вы ищете такой ответ из поваренной книги, вы попадете в беду, потому что любой, кто скажет вам, что есть ответ из поваренной книги, либо не понимает этого, либо намеренно скрывает это от вас, потому что всегда есть тонны нюансов. Мы, мы, мы возвращаемся к этому, как сейчас более чем 50-летнему искусству, нет серебряных пуль, верно? Один вопрос, который я получил онлайн, я спросил, что люди хотели бы спросить у вас, это какой бы вы дали сегодня совет младшим инженерам-программистам, которые начинают, все это происходит с ИИ, мы знаем, что с обучением, я думаю, вы также упомянули, или, возможно, это был Умеш, который упомянул, что с младшими инженерами это может быть немного рискованно, если вы слишком сильно полагаетесь на ИИ, не помешает ли это вашему обучению, потому что обучение важно. Если один из этих инженеров спросит вас: «Эй, я младший инженер. Я хотел бы в конечном итоге стать более опытным инженером, какие тактики вы бы мне посоветовали, особенно с инструментами ИИ? Должен ли я полагаться на них? Должен ли я не полагаться? Есть ли что-то, что может работать лучше, чем другие вещи? >> Ну, я имею в виду, конечно, мы должны использовать инструменты ИИ и исследовать их использование. Сложность для тех, кто более молод, заключается в том, что у вас нет этого ощущения, что, в какой степени выходные данные, которые я получаю, хороши, и во многих отношениях ответ таков, каким он всегда был: найдите хороших старших инженеров, которые будут вас наставлять, потому что это лучший способ научиться этому, и хороший опытный наставник стоит своего веса в золоте, и на самом деле во многих отношениях стоит отдавать этому приоритет над многими другими вещами, которые вы делаете, когда дело доходит до вашей карьеры, это получить это наставничество. Я имею в виду, опять же, то, что я нашел Джима Одела в начале своей карьеры, было невероятно ценным. Лучшее, что могло случиться со мной, была просто слепая удача. >> Но ищите кого-то вроде него, кто может быть вашим наставником. Я имею в виду, хотя мы в некотором смысле равны, я часто думаю о Кемпе Беке как о наставнике. >> Потому что, знаете ли, мы можем быть одного возраста или что-то в этом роде, но его мышление всегда движется вперед. И поэтому наблюдать за тем, что он делает, было очень ценно. Так что опять же, найдите кого-то вроде него. ИИ может быть полезен, но всегда помните, что он доверчив, и он, скорее всего, солжет вам. Так что будьте любопытны, спрашивая его. Хорошо, почему вы даете мне этот совет? Каковы ваши источники? Что заставляет вас говорить это? Я имею в виду, я помню, это вообще хорошая вещь, когда люди дают вам что-то, это сказать, что заставляет вас говорить это? Каков фон? Каков контекст, из которого вы исходите? Что приводит вас к этой точке зрения? И, исследуя это, вы можете лучше понять, откуда они исходят. И я думаю, что вы должны делать то же самое с ИИ, потому что в конце концов ИИ — это просто пересказ чего-то, что он видел в Интернете. Так что вопрос в том, видел ли он хорошие вещи в Интернете, или он видел большую часть дерьма, которое есть в Интернете, верно? Но если вы сможете найти хорошие вещи, то это может быть гораздо полезнее. >> И глядя на все эти изменения, которые происходят прямо сейчас с ИИ, LMS, как вы относитесь к технологической индустрии в целом? >> Я имею в виду, в широком смысле, я позитивен, потому что я все еще чувствую, что есть огромное количество огромных вещей, которые можно сделать с технологиями и программным обеспечением. >> И мы находимся, знаете ли, мы все еще находимся в ситуации, когда спрос намного превышает наши возможности. Но это долгосрочный взгляд. Я имею в виду, в данный момент мы находимся в этой очень, я бы сказал, очень странной фазе. Я имею в виду, жизнь всегда была странной фазой. Я имею в виду, странной по-разному. Текущая странность заключается в том, что мы, по сути, находимся в огромной, безусловно, в развитом мире, депрессии. Я имею в виду, мы видели огромное количество увольнений. Я имею в виду, я слышал цифры, от четверти миллиона до полумиллиона потерянных рабочих мест. Я имею в виду, это такой масштаб. Я имею в виду, мы видим это. Я имею в виду, в Fort Works мы раньше росли на 20% в год все время до примерно 2021 года. Я имею в виду, мы достигли стены, и мы видим, что наши клиенты просто не тратят деньги на это. >> Я имею в виду, ИИ делает свое отдельное дело, но это почти как отдельное дело, и это явно пузырь, но мы не знаем, насколько большим он будет расти. Мы не знаем, когда он лопнет. И мы не знаем, что будет после лопнувшего пузыря. Я имею в виду, все это непредсказуемо. Я думаю, что в ИИ есть ценность, в отличие от блокчейна и криптовалюты. В ИИ определенно есть что-то, но как именно это развернется, кто знает? И я имею в виду, я прошел через этот цикл с вещами в 90-х и 2000-х годах. Так что это повторение того же, только, вероятно, на порядок большего масштаба. >> Так что все это происходит, но на самом деле то, что происходит, самое важное, что нас затронуло, — это не ИИ. Это конец нулевых процентных ставок. Это большая вещь, которая действительно нас затронула. И именно поэтому начались увольнения до ИИ из-за этого. И мы не знаем, как это изменится, потому что это гораздо более макроэкономическая вещь. У нас есть Луни, который ведет автобус в Соединенных Штатах. У нас есть всевозможные другие давления, происходящие на международном уровне. Большая неопределенность в данный момент, и это влияет на нас, потому что это означает, что предприятия не инвестируют. И пока предприятия не инвестируют, трудно добиться большого прогресса в мире программного обеспечения. И поэтому у нас есть это странное сочетание практически полного отсутствия инвестиций, депрессии в индустрии программного обеспечения с пузырем ИИ. И оба происходят одновременно. >> И одно из массовых, с другой стороны, да, зависит от того, где вы находитесь. Например, я был в Кремниевой долине, и если вы ИИ-компания, все внутри выглядит отлично. Если вы снаружи, опять же, вы можете извлечь из этого выгоду, но это гораздо более осторожно. И если вы находитесь вне этого пузыря, скажем, вы в стартапе или в компании, которая не занимается ИИ, это просто тяжело. Так что у вас есть эти миры, происходящие. Я имею в виду, это все еще, я думаю, индустрия с большим потенциалом в будущем. Я думаю, что это хорошая индустрия, в которую стоит войти. Это не, знаете ли, время не так велико, как было бы, если бы вы вошли в эту индустрию, скажем, в 2005 году. >> Но, знаете ли, я все еще чувствую, что здесь есть хорошая профессия. Я не думаю, что ИИ уничтожит разработку программного обеспечения. >> Я думаю, что это изменит ее очень заметным образом, как изменились от ассемблера к языкам высокого уровня, но основные навыки все еще существуют, и основные навыки хорошего разработчика программного обеспечения, на мой взгляд, все еще не столько в написании кода. Это часть навыка. Большая часть навыка — это понимание того, что писать, что является общением, и особенно общением с пользователями программного обеспечения и преодолением этого разрыва, который всегда был самым критическим путем общения. >> И вы также упомянули, что эксперт-генералист становится намного важнее, что все это, когда я углубился в детали, мы дадим ссылку в примечаниях к шоу, статья, которую, я думаю, снова >> Умеш был на высоте, он на высоте, но все черты, кажется, не имеют ничего общего с ИИ. Это любопытство. Это погружение в глубину. >> Это расширение кругозора. >> Звучит так, как будто я слышу все больше и больше людей, которые думают о том, что значит быть выдающимся инженером-программистом. Основы, кажется, не меняются. >> Верно? Да. И я думаю, что это всегда было общение, и способность эффективно сотрудничать с людьми всегда была, на мой взгляд, выдающимся качеством того, что действительно делает лучших разработчиков. >> Проявляется, безусловно, в корпоративном коммерческом мире, который я знаю лучше всего, потому что все программное обеспечение, которое мы пишем, предназначено для людей, занимающихся чем-то совершенно отличным от нас. Я помню, когда я работал в службе здравоохранения, я всегда говорил, знаете ли, вот я занимаюсь концептуальным моделированием здравоохранения. Я понимаю огромное количество о процессе здравоохранения. Вы не захотите, чтобы я лечил ваши медицинские проблемы, потому что у меня никогда не будет этого навыка, потому что я не врач. Да. >> И поэтому врачи должны быть вовлечены в процесс. >> Итак, в заключение, я хотел бы задать несколько быстрых вопросов, где я буду стрелять, а вы будете отвечать, что приходит на ум. Какой ваш любимый язык программирования и почему? >> Хм, я бы сказал, что в данный момент мой любимый язык программирования — Ruby, потому что он стал, я так с ним знаком, я использую его так долго. Но тот, который является моей любовью, — это Smalltalk, без сомнения. Smalltalk. Не было ничего столь же веселого, как программирование на Smalltalk, когда я мог делать это в 90-х. Это была такая фантастическая среда. >> Вы и Кен Бек, и Кен Бек пишет свой сервер Smalltalk. Это его детище. Я думаю, он добивается прогресса. >> И я имею в виду, что там все еще что-то происходит. Есть проект Pharaoh в Smalltalk. И я все время думаю, знаете ли, если бы я мог взять несколько недель отпуска и прекратить все остальное, что я делаю, может быть, исследовать, посмотреть, что происходит в мире Smalltalk снова, потому что это было, я имею в виду, и все еще имеет столько силы в этом языке. >> Какие книги вы бы порекомендовали? И почему? >> Итак, книгу, которую я особенно люблю рекомендовать, — это «Думай быстро и медленно» Даниэля Канемана. Мне она нравится, потому что он действительно хорошо справляется с тем, чтобы дать вам интуицию о числах и заметить некоторые из многих ошибок и заблуждений, которые мы совершаем, когда думаем о вероятности и статистике. И это важно в разработке программного обеспечения, и потому что, я имею в виду, многое из того, что мы делаем, значительно улучшается благодаря тому, что мы можем понять статистические эффекты того, что мы видим, но также и в жизни в целом, потому что я думаю, что наш мир был бы намного лучше, если бы гораздо больше людей понимали немного больше о вероятности и статистике. >> Чем они делают. Я имею в виду, я, как и большинство детей, вероятно, когда они занимались математикой в школе, она была сильно основана на исчислении. Я действительно чувствую, что было бы намного лучше, если бы, знаете ли, она была гораздо более статистически основана, потому что знание того, как это использовать. Ну, я имею в виду, одна из вещей, которая помогла мне больше с вероятностью и вероятностным рассуждением, — это тот факт, что я очень увлекаюсь настольными играми, где вам приходится постоянно думать в терминах вероятности, и я просто честно чувствую, что знание этого важно, и эта книга, я думаю, отличный способ начать с этого, и поэтому это было одно из лучших чтений, которое у меня было за последние несколько лет. Другая книга, которую я хотел бы упомянуть, которая совершенно отдельная и бросает вызов совершенно по-другому, и которой я был полностью одержим, — это книга под названием «Власть брокера». >> Итак, это книга о парне по имени Роберт Мозес, о котором большинство людей никогда не слышали, но который был самым влиятельным чиновником в Нью-Йорке около 40 лет, примерно с 192 по 1960 год. Он никогда не избирался на какую-либо должность. Он контролировал больше денег, чем мэр или губернатор Нью-Йорка в то время. И эта книга о том, как он пришел к власти. >> Как власть работает в демократическом обществе, часто не на виду. >> И это увлекательная книга для этого. Это также увлекательная книга, потому что она так хорошо написана. Были моменты, когда я просто, знаете ли, я читал несколько страниц чего-то, и мне приходилось останавливаться, чтобы просто оценить, насколько блестящим было то, что я только что прочитал. И это ценно, потому что, чтобы быть лучшим писателем, и я думаю, мы все выигрываем от того, чтобы быть лучшим писателем, очень важно читать действительно хорошее письмо. И его письмо великолепно. Недостаток в том, что это 1200 страниц. Это действительно длинная книга, но мне так понравилось, что я не возражал. И тогда, когда вы переходите от этого, вы переходите к его второй биографии, потому что он написал только две биографии, и это его текущая пятитомная биография Линдона Бейнса Джонсона, LBJ, которая так же блестяща, и я читаю ее, но это гораздо больше, потому что это четыре тома до сих пор, и он еще не закончил пятый. Но опять же, есть моменты, когда я просто был поражен тем, насколько блестящим было письмо, и поражен тем, как власть работает в демократическом обществе, и я думаю, чтобы понять, как работает наш мир, такие книги очень, очень ценны. >> И наконец, можете ли вы дать рекомендацию по настольной игре? Вы очень увлечены настольными играми. На вашем веб-сайте есть список их. >> Да, это сложный вопрос, потому что это похоже на то, как если бы я сказал, что я очень заинтересован в просмотре фильмов. Какой фильм вы бы порекомендовали? >> Потому что я понимаю. Так много разных вкусов и вещей. Если я собираюсь выбрать что-то, что, я думаю, не слишком сложно для кого-то, чтобы начать, что, я думаю, все еще обладает довольно большим богатством в данный момент, я думаю, что игра, которую я бы выбрал, — это что-то под названием Concordia. >> Она довольно абстрактна по своей природе, но ее легко освоить, и в ней довольно много принятия решений в процессе. >> Ну, Мартин, спасибо большое. Было здорово, что мы смогли сделать это лично. >> Да, это сработало очень хорошо. Я просто оказался в Амстердаме по другому делу, и я знаю кого-то в Амстердаме, поэтому я подумал, что свяжусь, и мы наконец-то получили шанс встретиться лицом к лицу. >> Это было потрясающе. Спасибо. >> Спасибо. Большое спасибо Мартину за этот интересный разговор. Одна из вещей, которая действительно запомнилась мне, — это то, как самое большое изменение с ИИ заключается в том, как мы переходим от детерминированных систем к недетерминированным. Это означает, что наши существующие подходы к разработке программного обеспечения, которые основывались на предположении полностью детерминированной системы, такие как тестирование, рефакторинг и так далее, вероятно, не будут работать так хорошо, и нам могут понадобиться новые, если мы не сможем сделать элементы более детерминированными. Это также понравилось, как Мартин упомянул нам, что проблема с кодированием с помощью ИИ заключается в том, что когда вы перестаете обращать внимание на сгенерированный код, вы перестаете учиться, а затем перестаете понимать, и вы можете в конечном итоге получить программное обеспечение, которого вы не понимаете. Так что будьте внимательны в случаях, когда вы довольны этим компромиссом. Для дальнейшего чтения по лучшим практикам в области инженерии ИИ и обзора того, как изменилась область разработки программного обеспечения за последние 50 лет, ознакомьтесь с соответствующими подробными статьями в Pragmatic Engineer, которые приведены по ссылкам в описании ниже. Если вам понравился этот подкаст, пожалуйста, подпишитесь на вашу любимую платформу подкастов и на YouTube. Это поможет большему количеству людей открыть для себя подкаст, и особая благодарность, если вы также оставите оценку. Спасибо и до встречи в следующем выпуске.