Transcription
Всем привет. Конференция проходит хорошо? >> У вас хорошая конференция на данный момент? >> Хорошо. Замечательно. У меня есть для вас сообщение, которое, я надеюсь, будет, э-э, утешительным сообщением для тех, кто считает, что, э-э, их набор навыков больше ничего не стоит в эту новую эпоху, а именно: я считаю, что основы программирования сейчас важны как никогда. И я учитель, и недавно я преподавал курс под названием "Claude Code для настоящих инженеров". Приятно и провокационно. И в процессе работы над этим курсом мне пришлось разработать учебную программу по программированию с использованием ИИ, что является своего рода кошмаром, потому что все постоянно меняется, верно? ИИ — это совершенно новая парадигма. Нам наверняка придется отказаться от всех старых правил, чтобы внедрить новое. И вокруг этого возникло своего рода движение, которое называется движением "спецификации в код". И движение "спецификации в код" гласит, что вы можете написать спецификацию о том, как должно работать приложение, а затем использовать ИИ, чтобы превратить ее в код. Если в приложении есть проблема, вы возвращаетесь к спецификации. Вы не смотрите на код. Вы просто меняете спецификацию. Вы снова запускаете компилятор, и получаете больше кода. Поднимите руку, кто слышал об этом. Держите руку поднятой, если вы пробовали. Хорошо. Я тоже пробовал. Можете опустить руки. И что я заметил, так это то, что я запускал его и старался не смотреть на код, но я смотрел на код и понял, что сначала я получал код, а затем я запускал его, получал худший код, а затем я сделал это снова, получил еще худший код, и я сделал это снова, я продолжал запускать компилятор, продолжал запускать компилятор, и я просто получал мусор. Знаете, поднимите руку, если такое случалось с вами. Да. Я не думаю, что это работает. Идея о том, что мы можем просто игнорировать код и просто иметь код, пусть он сам себя управляет, — это просто своего рода кодирование под другим названием, и я не верил в это тогда, я думал: "Хорошо, как мне исправить компилятор, как мне сделать так, чтобы он не производил плохой код каждый раз или худший код?" И поэтому я подумал: "Хорошо, мне нужно объяснить LLM на английском языке, как выглядит хороший кодовый базис". Позвольте мне достать одну из моих старых любимых книг, которая называется "Философия проектирования программного обеспечения" Джона Остергоуда. Зайдите на Amazon, купите ее. У него есть определение того, как выглядит плохой код. Он называет это сложным кодом. Сложность — это все, что связано со структурой программной системы, что затрудняет понимание и изменение системы. Верно? Итак, плохой кодовый базис — это кодовый базис, который трудно изменить. Если вы не можете изменить кодовый базис, не вызывая ошибок, значит, это плохой кодовый базис. Хорошие кодовые базисы легко изменить. Итак, я подумал: "О, это было хорошо. Давайте попробуем другую книгу. Давайте попробуем "Прагматичного программиста". Зайдите на Amazon, купите ее. У них есть целая глава о чем-то, что называется "энтропия программного обеспечения". И это именно то, что я видел. Энтропия — это идея о том, что вещи стремятся к, э-э, катастрофе и, э-э, разлетаются друг от друга и коллапсируют. И именно так ведут себя большинство программных систем: каждый раз, когда вы вносите изменение в кодовый базис, если вы думаете только об этом изменении, не думая о дизайне всей системы, ваш кодовый базис будет становиться все хуже и хуже. И это именно то, что я видел. Все в идее "спецификации в код", что вы просто снова и снова запускаете компилятор, приводило к ухудшению кода. Теперь есть идея, которая движет движением "спецификации в код", а именно то, что код дешев. Поднимите руку, кто слышал эту фразу раньше, что код дешев. Да. Ну, я не думаю, что это правильно. Я думаю, что код не дешев. На самом деле, плохой код самый дорогой, чем когда-либо. Потому что, если у вас есть кодовый базис, который трудно изменить, вы не можете получить всю выгоду, которую может предложить ИИ, потому что ИИ в хорошем кодовом базисе на самом деле работает очень, очень хорошо. И это означает, что хорошие кодовые базисы важны как никогда, а это означает, что основы программирования важны как никогда. Это тезис этого доклада. Итак, давайте перейдем к практическим вещам. Я расскажу о различных режимах сбоев, с которыми вы могли столкнуться или еще не столкнулись с ИИ, и о том, как их избежать, просто вернувшись к старым книгам и изучив хорошие практики программирования. Звучит хорошо? Итак, первое: ИИ не сделал того, что я хотел. Знаете, у меня была хорошая идея в голове, а ИИ сделал что-то совершенно другое, или он сделал какие-то, э-э, вроде спецификаций, которые, я знаю, он просто сделал что-то, чего я не хотел. Поднимите руку, кто сталкивался с этим режимом. Круто. Хорошо. Ну, вот что говорят в "Прагматичном программисте": никто точно не знает, чего хочет. Это вы и ИИ, между вами есть коммуникационный барьер, верно? И поэтому, когда вы разговариваете с ИИ, это своего рода сбор требований ИИ. Он, по сути, выясняет у вас, что вам нужно. И я понял, что есть еще одна книга, Фредерик Брукс, "Дизайн дизайна", и в ней говорится об этой идее, называемой концепцией дизайна. заключается в том, что когда более одного человека вместе проектируют что-то, у вас есть эта идея, которая как бы витает между вами, эта эфемерная идея того, что вы строите. И то, что вы строите, или идея этого, называется концепцией дизайна. Это не актив. Это не то, что вы можете поместить в файл markdown. Это невидимая теория того, что вы строите. И поэтому я подумал: "Хорошо, вот что происходит. У меня и ИИ нет общей концепции дизайна". Поэтому я придумал навык. Навык очень, очень простой. Он называется "гриль меня" и выглядит так: "Допрашивай меня безжалостно по каждому аспекту этого плана, пока мы не достигнем общего понимания". Пройди по каждой ветви дерева дизайна, что является еще одной вещью из Фредерика Брукса, разрешая зависимости между решениями одно за другим. Этот навык, как, э-э, репозиторий, содержащий этот навык, имеет около 13 000 звезд или что-то в этом роде, он просто взорвался. Стал вирусным. Людям нравится эта вещь. Эти пара строк означает, что ИИ задает вам около 40 вопросов, 60 вопросов. Я видел, как он задавал людям сто вопросов, прежде чем он был удовлетворен тем, что они достигли общего понимания. И это означает, что ИИ превращается в своего рода противника, который постоянно подбрасывает вам идеи и пытается достичь общего понимания. И это означает, что разговор, который вы затем генерируете, вы можете взять и превратить его в документ с требованиями к продукту или что-то в этом роде. Или, если это небольшое изменение, вы можете просто превратить его непосредственно в задачи, а затем ваш AFK-агент подхватит его. И не пишите мне об этом, но я лично считаю, что это лучше, чем режим планирования по умолчанию в инструменте, который я использую, а именно Claude Code. Режим планирования чрезвычайно стремится создать актив. Он действительно хочет, э-э, просто создать план и начать работать. В то время как я думаю, что гораздо приятнее сначала достичь общего концепции дизайна. Так что это первый совет. Теперь режим сбоя номер два: ИИ просто слишком многословен. Это как будто вы говорите с ИИ вразнобой. Поднимите руку, если вы, э-э, чувствуете это. Если вы когда-либо сталкивались с этим режимом сбоя. Да. Это как будто ИИ говорит, используя слишком много слов, чтобы попытаться передать то, что он делает. Это не похоже на то, что вы говорите, используя один и тот же язык. И это мне показалось очень, очень знакомым. Верно? Если вы долгое время были разработчиком и работали, скажем, с экспертами в предметной области, кто-то строит приложение, скажем, эксперт в предметной области хочет, чтобы вы построили что-то на, я не знаю, микрочипах. Вы понятия не имеете, что такое микрочипы. Вам нужно установить какой-то общий язык, верно? Потому что иначе они будут использовать термины, которые вы не понимаете. Вы будете переводить это в код, который, возможно, вы даже не понимаете, и, конечно, эксперт в предметной области не поймет. И поэтому существует этот своего рода языковой разрыв между вами и экспертом в предметной области. И поэтому я вернулся к объектно-ориентированному дизайну. DDD, это то, что я все еще исследую на грани, но все, что я читаю о DDD, просто музыка для моих ушей. Я чертовски люблю это. И DDD имеет концепцию универсального языка. С универсальным языком разговоры между разработчиками и выражения кода, и разговоры с экспертами в предметной области — все они выводятся из одной и той же модели предметной области. По сути, это файл markdown, полный списка терминов, которые вы и ИИ имеете в общем. И вы действительно фокусируетесь на этих терминах, и вы действительно убеждаетесь, что они соответствуют тому, что они на самом деле означают, и вы используете их все время в коде, когда вы говорите о коде, когда вы говорите с экспертами в предметной области, или в нашем случае, когда вы говорите с ИИ. Поэтому я создал навык. Этот навык — навык универсального языка. Он просто сканирует ваш кодовый базис, ищет терминологию, а затем, э-э, создает файл markdown. Создает файл markdown универсального языка. Куча таблиц markdown со всей терминологией. И это я передаю ИИ, и я могу его прочитать, и я действительно держу его открытым все время, когда я провожу гриль с ИИ и планирую и тому подобное. И что я заметил, читая следы мышления ИИ, это не только улучшает планирование, но и позволяет ИИ думать менее многословно и фактически означает, что реализация более соответствует тому, что вы на самом деле планировали. Так что это абсолютно было мощным инструментом. Это было невероятно хорошо. Так что это второй совет. Создайте общий язык с ИИ. Итак, давайте представим, что вы согласовали с ИИ. Вы знаете, что вы должны строить. ИИ построил правильную вещь, но она не работает. Поднимите руки, если такое случалось с вами. Да, просто не работает. Ну, есть очевидная вещь, которую мы можем сделать, чтобы улучшить это, а именно: мы можем использовать циклы обратной связи. Мы можем использовать, э-э, статические типы. Знаете, если вы не используете TypeScript, у, это безумие. Э-э, если вы не используете, э-э, если вы строите фронтенд-приложение и не даете ему, LLM, доступ к браузеру, чтобы он мог осмотреться, ему это абсолютно необходимо. И, очевидно, вам также нужны автоматизированные тесты. И одна вещь, которую я здесь замечаю, заключается в том, что даже с этими циклами обратной связи LLM не использует их очень хорошо. Он не извлекает максимум из своих циклов обратной связи так, как это сделал бы опытный разработчик. И поэтому он делает то, что он обычно делает, это делает слишком много за один раз. он произведет, скажем, огромное количество кода, а затем подумает: "О, я, наверное, должен проверить тип этого на самом деле, или я должен, э-э, да, может быть, проверить тест на этом, или может быть, сделать что-то вроде этого". И это в "Прагматичном программисте" описывается как "бежать быстрее фар", что, по сути, означает ехать слишком быстро, потому что скорость обратной связи — это ваш скоростной лимит. Скорость обратной связи — это ваш скоростной лимит, что означает, что вы должны тестировать по ходу дела, делая маленькие, намеренные шаги. И ИИ по умолчанию действительно не очень хорош в этом. И поэтому навык номер три — это TDD. Вы должны использовать разработку, управляемую тестами, потому что TDD заставляет LLM делать маленькие шаги. Вы сначала создаете тест. Вы делаете так, чтобы этот тест проходил, а затем вы рефакторите код, чтобы сделать его лучше и рассмотреть дизайн. Проблема здесь в том, что тестирование действительно сложно. Тестирование всегда было сложным. И причина этого в том, что существует множество различных решений, которые вам нужно принять при написании теста. Вам нужно выяснить, насколько большой единицей вы хотите протестировать. Вам нужно выяснить, что мокать. Вам нужно выяснить, какие поведения вы вообще хотите протестировать. И все эти решения зависят друг от друга. Так что, если вы тестируете действительно большую единицу, такую как целое огромное приложение, то оно может быть довольно нестабильным. Вы, возможно, не захотите тестировать так много поведений. Знаете, если вы тестируете только эту единицу, вам нужно мокать эту единицу. Знаете, все это взаимосвязано. И я думаю об этом годами, на протяжении всей моей карьеры разработчика. И что мы замечаем, так это то, что хорошие кодовые базисы — это кодовые базисы, которые легко тестировать, верно? Итак, здесь мы возвращаемся к идее о важности кода: чем лучше ваш кодовый базис, тем лучше ваши циклы обратной связи. Потому что вы можете, э-э, дать лучший отзыв LLM, он производит лучший код. И поэтому я подумал, как выглядит хороший кодовый базис, как выглядит тестируемый кодовый базис? Снова обратимся к Джону Эрхауту. Он говорит о наличии глубоких модулей в вашем кодовом базисе. Не мелких модулей, не множества модулей, которые раскрывают вроде бы, э-э, множество функций. Это должны быть относительно немногие большие, глубокие модули с простыми интерфейсами. Давайте быстро сравним их. Глубокие модули, много функциональности скрыто за простым интерфейсом, скрывающим сложность. Вы можете заглянуть внутрь глубокого модуля, если хотите, но вам не нужно. Вы можете просто использовать интерфейс. Мелкие модули, не так много функциональности, сложный интерфейс. И я просто подожду, пока вы сделаете фотографии. Мелкие модули в кодовом базисе выглядят примерно так, где у вас есть куча разных крошечных пузырьков, через которые ИИ должен пройти и ориентироваться. И это действительно сложно для ИИ исследовать. И поэтому часто вы увидите, что если у вас есть кодовый базис, подобный этому, который ИИ действительно хорошо создает, то у вас будет ситуация, когда ИИ не понимает, что делает ваш код. Он попытается исследовать код, но поскольку он плохо организован, заполнен мелкими модулями, он, возможно, не доберется до нужного модуля вовремя или не поймет все зависимости, все это. Он не понимает ваш код. И как выглядит кодовый базис, полный глубоких модулей? Ну, он выглядит так, где это тот же код, но он просто структурирован внутри границ, где у вас есть эти интерфейсы наверху. И эти интерфейсы, вы, вероятно, должны иметь над ними большой контроль и хорошо их проектировать. В противном случае, знаете ли, ИИ может испортить дизайн. Но реализацию, вы можете оставить это ИИ. Итак, как превратить кодовый базис, который выглядит так, в кодовый базис, который выглядит так? Ну, у меня есть навык для этого. Улучшение архитектуры кодового базиса. Оказывается, это не совсем просто, но это набор шагов, которые вы можете многократно повторять. Вы просто исследуете кодовый базис, ищете возможности, где есть код, который вроде бы, э-э, связан, и заключаете все это в глубокий модуль. И это тестируемый кодовый базис, потому что границы вокруг этого кода очень, очень просты. Вы тестируете на интерфейсе, вы проверяете, используя этот интерфейс, и вы готовы к работе. И поэтому это кодовый базис, который вознаграждает TDD. Но как насчет режима сбоя номер шесть, который заключается в том, что ваш, хорошо, скажем так, ваши циклы обратной связи работают. Скажем так, дела идут своим чередом. Вы можете выпускать больше кода, чем когда-либо прежде, но ваш мозг не успевает, верно? Э-э, поднимите руку, если вы чувствовали себя более уставшим, чем когда-либо прежде в своей карьере разработчика. Да, я тоже. Это изматывает. И я думаю, что это кодовый базис, который на самом деле затрудняет работу вашего мозга, потому что вы, так же как и ИИ, должны держать всю эту информацию в голове. В то время как это, не только проще для вас читать и понимать, но это также означает, что вы можете относиться к этим модулям или этим глубоким модулям как к серым ящикам. вы можете сказать: "Хорошо, я просто спроектирую интерфейс, но я не буду слишком беспокоиться или слишком сильно проверять реализацию". Вы можете сделать это, очевидно, с, э-э, вещами, которые менее критичны в вашем приложении, не можете сделать это с, э-э, знаете ли, различными вещами, такими как финансы или что-то в этом роде, но во многих, многих модулях вашего приложения вам не нужно слишком много думать о реализации, если у вас есть тестируемая граница за пределами модуля, и если вы понимаете его назначение и можете спроектировать его снаружи. Я обнаружил, что это действительно спасло мой мозг, потому что я могу просто сказать: "Хорошо, ИИ, я позволю тебе позаботиться о том, что находится внутри большого блока, я просто буду тестировать снаружи и проверять это". Так что это пятый совет: спроектируйте интерфейс, делегируйте реализацию. Но это означает, что всякий раз, когда мы касаемся кода, всякий раз, когда мы планируем что-то, нам нужно думать о модулях в нашем приложении и быть осведомленными о них. Нам нужно хорошо знать эту карту. Это должно быть частью нашего универсального языка. Нам нужно встроить это в наши навыки планирования. Так что мой писатель PRD внутри PRD я конкретен об изменениях модулей и интерфейсах внутри этих модулей, как они изменяются. Я постоянно думаю о них. И это исходит от Кента Бека. Инвестируйте в дизайн системы каждый день. И это суть, верно? Потому что "спецификации в код" мы не инвестируем в дизайн системы, мы от нее отказываемся. Мы избавляемся от этого. В то время как я думаю, что это абсолютно ключевое. И поэтому код не дешев. Это сообщение, которое я хочу, чтобы вы унесли с собой. Код важен. И если мы думаем об ИИ как о действительно отличном программисте на местах, своего рода тактическом программисте, сержанте на местах, вносящем изменения в код, вам нужен кто-то выше этого. Вам нужен кто-то, кто думает на стратегическом уровне, и это вы. И это требует фундаментальных навыков программирования, которые мы использовали в течение 20 лет, дольше. Теперь, если вы заинтересованы в любых навыках, которые я здесь представил, это в репозитории GitHub, Mac PCO skills. И если вы заинтересованы в обучении, которое я провожу, или в любом бесплатном контенте, я есть на YouTube, я есть в Twitter, но я также на aihero.dev, где у меня есть информационный бюллетень, который вы можете проверить. Большое спасибо. Я надеюсь, что это придаст вам уверенности в эту новую эпоху ИИ, что вы действительно можете оказать хорошее влияние. Спасибо.