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, где у меня есть информационный бюллетень, который вы можете проверить. Большое спасибо. Я надеюсь, что это придаст вам уверенности в эту новую эпоху ИИ, что вы действительно можете оказать хорошее влияние. Спасибо.