Transcription
Привет, ребята, в этом видео я хочу обсудить разработку, управляемую спецификациями, специально для ИИ-ассистентов по кодированию и агентов, которые стали действительно популярными в последние месяцы с такими инструментами, как OpenSpec, которые вы видите на экране. Также есть Spec Kit, Agent OS, BMAD Method и несколько других. За последнюю неделю я посмотрел дюжину видео о них. Вы можете увидеть плейлист, также попробовал несколько, и я хочу поделиться своим мнением, особенно после нескольких вопросов от вас, ребята, в одном из предыдущих видео о режиме планирования в Cloud Code. Были комментарии вроде этого. Пожалуйста, сделайте больше видео об этом режиме, как BMAD Method. Также, пожалуйста, сделайте одно на эту тему. Также, пожалуйста, сделайте следующее видео, что вы предпочитаете, Specit или что-то еще, так что люди заинтересованы, и это видео попытается ответить на вопросы. Итак, сначала, какую проблему решают эти инструменты и методология в целом, разработка, управляемая спецификациями? Мы все, вероятно, согласимся, что режим планирования — это хорошо. Чем лучше мы планируем, тем лучше будут результаты работы ИИ-агента в большинстве случаев, а режим планирования в Cloud Code — хороший шаг в этом направлении. Но проблема с режимом планирования в том, что он предназначен для конкретного запроса, обычно для одной конкретной функции. А как насчет всего проекта? Если у нас есть какая-то спецификация от клиента или описание вакансии, как мы можем разделить это на этапы? Как мы поддерживаем исходную спецификацию в актуальном состоянии? Как мы переходим от задачи к задаче? Так что эти инструменты предлагают такую структуру, и я покажу вам пример OpenSpec в действии в качестве примера, потому что это самый простой из этих инструментов. Итак, давайте посмотрим, как это работает. Я попробую взять реальную работу с Upwork для старшего fullstack-разработчика по музыкальному проекту и попробую выполнить несколько шагов, первые шаги OpenSpec в действии. Итак, первое, что я делаю, это инициализирую OpenSpec внутри этого проекта. Я уже установил его как проект Laravel, потому что я обычно работаю с этим фреймворком. Так что у меня есть стандартная структура Laravel, а затем я открываю терминал и следую начальной документации OpenSpec. Я уже установил его глобально. Кстати, OpenSpec и большинство этих инструментов не зависят от ИИ-агентов. Они работают в Cloud Code, Cursor и других. Я просто поклонник Cloud Code в данный момент. Так что я буду использовать его. Итак, первый шаг инициализации OpenSpec в текущем проекте — это `openspec init`. Он просто создаст структуру OpenSpec внутри вашего проекта. Здесь нажмите Enter, чтобы продолжить. Мне нужно выбрать инструменты. Я выберу Cloud Code и продолжу. Итак, нам нужно взглянуть на `project.md`, сгенерированный OpenSpec, и это своего рода черновик того, что вам нужно предоставить в качестве контекста для всего проекта, и здесь в идеале вы должны ответить на эти вопросы вручную, и на самом деле официальная документация OpenSpec не предоставляет пример того, что делать с уже существующей спецификацией от клиента. Так что я импровизировал вот так. Я просто скопировал основное описание вакансии, исключая deliverables и how to apply, и вставил его сверху в этот `project.md`. Теперь нам нужно добавить техническую спецификацию. Итак, если мы снова откроем терминал, это рекомендации OpenSpec, и я скопирую и вставлю именно это в Cloud Code. Итак, я запускаю Cloud Code с опасным пропуском разрешений. У меня есть псевдоним для этого `ccc`, а затем я вставляю эту инструкцию и посмотрим, что получится. Кстати, я использую модель Opus 4.5, и это довольно важно. Чем лучше модель, тем лучше будет результат инструментов спецификации. Итак, говорится, что текущий `project.md` имеет хороший бизнес-контекст, но ему не хватает технических деталей, и именно это он пытается добавить. Итак, он смотрит на структуру проекта, видит, что это проект Laravel 12, и, вероятно, обновит структуру для него. Хорошо, он закончил работу, и давайте посмотрим на обновленный `project.md`, который теперь выглядит так. Он имеет структуру наших бэкенд и фронтенд технологий. Итак, у него есть тот же обзор проекта с заголовком, соглашениями по кодированию и тому подобным. А затем ваша следующая задача — фактически просмотреть это и, возможно, отредактировать то, чего вы не хотите, или, например, он предлагает ключевые отношения на уровне базы данных. Возможно, вы не согласны с SQLite и PostgreSQL. Возможно, вы предпочитаете MySQL и тому подобное. И затем, как только вы будете довольны этим `project.md`, вы можете начать запрашивать задачи по одной, спецификации для каждой из задач. В официальной документации OpenSpec цикл выглядит так. Для каждой задачи, которую вы хотите решить, у вас есть черновик предложения об изменениях. Каждая задача — это изменение. Так что для каждого изменения вам нужно сгенерировать предложение и просмотреть его, а затем реализовать задачи с помощью ИИ-агента, а затем архивировать, когда закончите, а затем перейти к следующей задаче, к следующему изменению. Итак, это список основных рабочих процессов, который, вероятно, является ближайшим к списку задач, и давайте попросим его поработать над этой первой задачей создания и редактирования гига, и это цикл изменений. Первый шаг — черновик предложения. Итак, есть `/command openspec proposal` или вы можете просто написать это вручную на человеческом языке, но я сделаю `/openspec proposal`, а затем вставлю описание этой конкретной задачи и посмотрим, что произойдет. И теперь он включает режим планирования Cloud Code с вопросами, на которые мне нужно ответить. Давайте просто выберем первый вариант во всех этих вопросах, потому что мне на самом деле неважно, как проект работает на данный момент. Я не клиент здесь. И теперь OpenSpec с Cloud Code сгенерирует несколько файлов, связанных с этой конкретной функцией. Хорошо, у нас есть результат, и это файлы. Итак, вы можете видеть изменения OpenSpec. У нас есть новое изменение под названием «добавить управление гигами», а затем для этого изменения у нас есть предложение и список задач. Итак, это список задач. Это то, чего я ждал для всего проекта, но OpenSpec работает более гранулярно, создавая список задач для каждого изменения спецификации. Итак, это список задач. Это предложение о всей функции, а затем `spec.md` содержит больше деталей о требованиях и о том, как эта функция должна работать. Итак, ваш следующий шаг — просмотреть все эти документы и предоставить любые отзывы, изменения, пока вы не будете готовы продолжить с Cloud Code, чтобы фактически реализовать этот список задач. Извините за дрожание голоса. Итак, вы можете редактировать эти файлы вручную, или вы также можете запрашивать Cloud Code. Итак, это официальная документация. Например, могу ли я добавить это или то? Есть несколько других команд терминала, таких как `openspec show` или `validate`, а затем вы просто реализуете изменение, и есть команда `/openspec apply` для этого конкретного имени изменения. Итак, у нас есть «добавить управление гигами». Итак, мы запрашиваем Cloud Code, или, по сути, Cloud Code уже предлагает это как следующий запрос, и мы можем просто нажать Enter в этом случае. Затем он автоматически запускает `openspec apply`. Так что это своего рода сотрудничество между OpenSpec и моделью Cloud Code OS в данном случае, которая в сотрудничестве вместе реализует это конкретное изменение для добавления управления гигами, и поскольку в этом списке довольно много задач, я ожидаю, что это займет около 10 минут. Итак, это список задач в Cloud Code, и я продолжу это видео после того, как оно закончится. И мы на финальной стадии, и это заняло примерно 9 минут. Итак, это сгенерированные файлы. Оглядываясь назад, вероятно, я бы взял задачу поменьше, чем эта, потому что теперь есть много чего для обзора, чего я не буду делать, потому что это не о коде Laravel или о чем-либо еще. Это о процессе. Так что представьте, что это сделано, и следующее — просмотреть код и запросить любые необходимые изменения. Но затем представьте, что вы довольны этой функцией, и как вы ее архивируете как выполненную и переходите к следующей функции. Для этого мы возвращаемся к документации, а затем следующий шаг — архивировать конкретную функцию. Итак, вот что мы запрашиваем `openspec archive add gig management` вот так, а затем посмотрите, что происходит в структуре папок. Итак, он фактически запускает команду `openspec archive`, которая перемещает это изменение в подпапку архива. Итак, теперь у нас есть `openspec changes archive` и папка `clear changes`. Итак, у нас нет новых изменений, и чтобы работать над следующей функцией, нам нужно вернуться к документации и снова завершить черновик предложения для следующей функции, и цикл продолжается. Конечно, если вы заметите, что что-то нужно изменить, то ваша новая функция, ваша новая спецификация, ваше новое предложение становится изменением предыдущей функции, и фактически даже Cloud Code предлагает следующую функцию «добавить управление списком музыкантов» дальше. Так что вы понимаете, как работает OpenSpec. Вы предоставляете исходное описание вакансии, а затем функция за функцией, спецификация за спецификацией, изменение за изменением, вы проходите проект. Итак, это, как я сказал, самая простая настройка для разработки, управляемой спецификациями, без усложнения. Другие инструменты, по моему опыту, из того, что я видел на YouTube и из моего внутреннего тестирования, более сложны и требуют больше работы заранее, чтобы перейти к фактической реализации задач. Давайте кратко рассмотрим эти другие инструменты и как они работают. Например, Agent OS тоже относительно прост. Вот документация. Рабочий процесс имеет несколько больше шагов. Итак, у вас есть план продукта с этими файлами для генерации, а затем цикл спецификации каждой задачи проходит через «shape spec» (формирование спецификации), затем «write spec» (написание спецификации), а затем у вас есть «create tasks» (создание задач) как отдельная команда с «create tasks», затем у вас есть «implement or orchestrate tasks» (реализация или оркестровка задач), что является двумя разными рабочими процессами. Итак, снова довольно много вещей, которые нужно изучить, чтобы иметь возможность использовать этот инструмент с его структурой. Следующий пример — Spec Kit, созданный GitHub, кстати, поддерживаемый довольно крупной компанией. После установки это рабочий процесс: «spec kit constitution» (конституция Spec Kit) для принципов проекта. Затем создайте спецификацию. Затем создайте план технической реализации. Разбейте на задачи и выполните реализацию, что выглядит похоже на Agent OS и OpenSpec на поверхности. Но если мы углубимся в документацию, там довольно много дополнительных терминов и структур, таких как создание ветки, автоматическое нумерование функций, такие термины, которые, по моему мнению, больше относятся к корпоративным средам и корпоративному языку. И, наконец, BMAD Method, который является самым большим из всех, потому что это не разработка, управляемая спецификациями. Это скорее гибкая разработка, управляемая ИИ. Так что более глобальные вещи с определенной структурой специализированных ИИ-агентов, 21 агент для разных целей одного и того же цикла. Итак, у вас есть 12 специализированных агентов, таких как разработчик, архитектор, аналитик, технический писатель и другие. И каждый агент будет выполнять часть спецификации. Итак, у вас есть 34 различных рабочих процесса в четырех фазах и много чего нужно изучить. Так что, чтобы сократить это видео, я даже не буду показывать это в действии. Что я покажу, я покажу несколько комментариев на YouTube от людей к видео об OpenSpec. Например, этот, хвалящий OpenSpec: «Мне не нужны 10 страниц BMAD спецификаций или несколько файлов Markdown». Еще одна вещь: создатель Spec Kit, очевидно, не очень хорошо разбирается в контекстном инжиниринге, так много лишнего. Другой человек говорит, что OpenSpec проще, чем GitHub Spec Kit, но это общая проблема со всеми этими методологиями, какую бы я ни показал, вам придется усердно работать, чтобы соответствовать их стандартам, вместо того, чтобы работать над своим проектом. И также по пути вы можете обнаружить, что этот инструмент на самом деле не подходит для вашего проекта или для вашего случая, потому что структура, например, слишком строгая, и вы даже не сможете следовать ей на 100%. Так что, по моему мнению, эти инструменты, особенно сложные, такие как BMAD и Specit, больше подходят для крупных компаний и крупных проектов, которым так или иначе нужна какая-то методология управления проектом. Так что это становится частью их процесса, вероятно, в направлении ИИ. Так что разработка, управляемая спецификациями, они делают что-то подобное в любом случае с точки зрения управления проектами. Так что этот инструмент может быть полезен. Также я заметил в этих видео на YouTube и в документации этих инструментов, что они обычно показывают своего рода идеальный сценарий, когда спецификация уже ясна заранее. Так что посмотрите здесь, например, «специфицировать систему чата в реальном времени с историей и присутствием пользователя». Обычно спецификация, описание вакансии, описание задачи от клиента гораздо сложнее, гораздо более нюансировано и, вероятно, с множеством неясных моментов заранее. Также довольно часто требования меняются почти в середине работы над задачей, вы что-то понимаете. Так что тогда это становится проблемой, вопросом, как обновлять спецификацию по ходу дела, чтобы ничего не сломать и тому подобное. Так что, по моему личному мнению, эти структуры любых инструментов, которые я вам показал, своего рода палка о двух концах, благословение и проклятие. Это зависит от того, с какими проектами вы работаете. Для простых проектов, для моих случаев использования, для демонстрационных проектов на YouTube или моего собственного сайта Laravel Daily.com или проектов, которые я просматриваю для моих клиентов Laravel Daily, это избыточно. Так что, если мы вернемся к исходной задаче Upwork, не было бы проще просто иметь запрос на разделение этой вещи на задачи? Иметь своего рода длинный файл со списком задач, а затем сказать ИИ-агенту Cloud Code или чему-либо еще, чтобы он просто работал задача за задачей, а затем обновлял этот файл, отмечая как сделано, как завершено и тому подобное. И тогда, если что-то изменится по ходу дела, сказать Cloud Code обновить исходный файл без какой-либо строгой структуры или специальных команд терминала. И люди на самом деле делают это. На самом деле, Тарик из Cloud Code делает именно это. У него есть запрос «прочитать спецификацию, опросить меня и обновить спецификацию», а затем потенциально составить список задач. И я снял видео об этом несколько дней назад. Если вы его не смотрели, я дам ссылку в описании ниже. Так что он не использует OpenSpec или что-либо еще, но все же называет этот процесс основанным на спецификациях, и я также покажу подход нашей команды без каких-либо внешних инструментов полгода назад мы начали работать над процессом, набором и последовательностью запросов, чтобы перейти от спецификации проекта к списку задач, а затем как работать с этими задачами. Итак, это типичный рабочий процесс для нашей команды для новых проектов в Laravel. Я даже не показывал его нигде. Так что это своего рода эксклюзив, потому что это своего рода беспорядочная вещь. Все находится в процессе, и я никогда не готовил это для публики. Но я просто кратко покажу вам своего рода альтернативу этим инструментам, управляемым спецификациями. Итак, есть восемь шагов для каждого нового проекта, и первые четыре шага технические, связанные с Laravel. Итак, вам нужно выбрать стартовый комплект. Вам нужно установить Laravel new и пакеты. Вам нужно добавить пользовательские рекомендации, которые я делаю для Laravel и Filament, если это необходимо, а также Context 7 — это дополнительный инструмент поверх Laravel Boost для дополнительной документации, и это номер пять, где мы переходим к своего рода разработке, управляемой спецификациями. Итак, исходное описание вакансии, где бы мы его ни взяли, например, с Upwork, попадает в этот файл. Итак, с тем же описанием вакансии с Upwork, с которым мы работали в этом видео, я помещаю его, я вставляю его в `project_description.md`. Затем здесь мне также нужно добавить технические детали, такие как стартовые комплекты и все, что я хочу с технической точки зрения. Так что, например, где-то здесь внутри я помещаю текстовый тег с другими инструментами, если это необходимо, а затем я прохожу три шага, чтобы преобразовать это описание в список задач. Итак, сначала, чтобы уточнить описание задачи, я прошу ИИ подготовить пользовательские истории, и из пользовательских историй гораздо проще разделить проект на истории, а затем просмотреть их и вносить изменения более гранулярно. Затем отдельно есть отдельный шаг, который другие инструменты на самом деле не подчеркивают, но я лично считаю его чрезвычайно важным. это структура базы данных, потому что структура базы данных, по моему опыту, влияет или навязывает множество других решений в дальнейшем. Так что, если структура базы данных не соответствует вашему видению проекта, ее гораздо сложнее рефакторить позже. Так что у меня есть отдельный шаг для этого, а затем из этих двух шагов я прошу ИИ подготовить фазы проекта. Итак, вот как это выглядит на практике. Итак, есть отдельный запрос для пользовательских историй, и вот он. Я на самом деле опубликую все эти запросы и все рабочие процессы для моих платных подписчиков Substack. Так что я поставлю ссылку где-нибудь ниже на статью, содержащую все эти запросы. В любом случае, это запрос, ссылающийся на документы и предоставляющий примеры того, что я имею в виду. Так что пример описания проекта, также с Upwork, и пример пользовательских историй из этого конкретного проекта. Так что это своего рода пример. Это общая вещь с ИИ. Чем больше вы показываете реальные примеры до и после того, что вам нужно и что вы имеете в виду, тем лучше он учится на примерах, чем на ваших запросах. Так что да, здесь я запускаю Cloud Code и вставляю этот большой запрос из 800 строк, потому что пример довольно подробный. И затем он задает мне вопросы, в данном случае 12 вопросов, на которые мне нужно ответить. Но, вероятно, я добавлю после этого видео, что он должен использовать инструмент «ask user question» (задать вопрос пользователю) из Cloud Code, чтобы автоматически включить этот диалоговый мастер вопросов, потому что сейчас мне нужно отвечать вручную, что я и сделаю прямо сейчас. Итак, сначала ответьте на это и так далее. Итак, да, это набор ответов, 12 быстрых ответов, которые Cloud Code с Opus определенно должен понять. Я на самом деле беспокоился, что отвечаю слишком коротко, но нет, по моему опыту, это на самом деле работает. Вы просто говорите «нет» или что-то еще. Упомяните одно слово из ответа, и этого обычно достаточно. Хорошо. И это занимает примерно 2 минуты. И теперь у нас есть пользовательские истории, 39 пользовательских историй. Итак, это новый файл Markdown в той же папке `docs`, который выглядит примерно так. Это своего рода список задач, но не совсем. Мы спорили внутри команды, следует ли разделять пользовательские истории и список задач. И, по сути, это для управления проектами и для клиентов, чтобы одобрить пользовательские истории без технических деталей и без плана того, как их реализовать. Это, по сути, кто что может сделать, а затем, конечно, следующий шаг — просмотреть, нужно ли все это и хорошо ли написано. Это своего рода огромный документ. Но опять же, чем больше вы планируете для ИИ-агента, чем больше деталей вы предоставляете, тем лучше результат. Так что это своего рода секрет, общеизвестный секрет для однократного запроса, потому что спецификация уже достаточно детализирована. И именно здесь я вижу будущее разработки в целом для кодеров. им нужно подняться на уровень выше в 2026 году и в будущем, и участвовать в управлении проектами, в спецификациях, в определении тестов, критериев приемки и тому подобного, а затем ИИ-агент будет реализовывать код, большую его часть, я думаю, это наше будущее, конечно, это будет не просто от нуля до единицы, это будет постепенно, но я думаю, нам нужно уделять гораздо больше внимания сейчас управлению проектами и спецификациям перед кодированием. Итак, пользовательские истории. Затем следующий запрос — структура базы данных на основе описания проекта и пользовательских историй, а также предоставление некоторых личных рекомендаций от нашей команды о том, что делать с проектом Laravel, в частности. Итак, в Cloud Code я могу очистить контекст, чтобы не загрязнять его еще больше, и предоставить этот следующий запрос для базы данных. Хорошо. И это занимает примерно 1 минуту, и у нас есть новый файл `database_schema.md`. Итак, это файл, и снова мы должны просмотреть его вручную. Итак, таблица пользователей, где находятся индексы, хотите ли вы использовать `varchar` здесь или `enum` для строк или отдельную таблицу. Так что таблицы поиска для инструментов, регионов и так далее, сводные таблицы с временными метками или без них, так что, например, я обычно не люблю `updated_at` для сводных таблиц в Laravel, потому что это редко используется ценно и так далее. Так что, по сути, вы просматриваете схему базы данных, но пока я оставлю ее как есть. И затем последняя фаза — это запрос из пользовательских историй, описания проекта и схемы базы данных, предоставьте список задач. И снова в конце каждого запроса мы пытаемся предоставить технические детали. Так что пока это только одна деталь, но мы думаем, что в будущем их будет больше. А также некоторые задачи могут быть уже выполнены, например, установка и настройка Laravel. Так что отдельная часть запроса, чтобы отметить их как выполненные. Итак, снова Cloud Code, очистить. Нам не нужен предварительный контекст, и я просто вставляю этот запрос. В данном случае он помещается на один экран, и он предоставит список задач, который затем мы запрашиваем у агента задача за задачей для реализации. Это немного отличается от оригинальной разработки, управляемой спецификациями, которая, по сути, создает спецификацию для каждой задачи и создает цикл для каждой задачи. В данном случае наша методология, которая на самом деле окупилась во многих проектах, заключается в наличии подробного списка задач, довольно большого количества запросов заранее, а затем вы увидите список задач, который пронумерован. Итак, у нас есть задача номер один, задача номер два и так далее. И тогда легче ссылаться на эти задачи. И затем, как только вы закончите задачу, вы обновляете или, по сути, просите агента обновить фазы проекта, номер задачи, чтобы она была выполнена или завершена, или что бы вы ни хотели, без перегрузки структурой конкретных команд терминала или команд с косой чертой или чего-либо еще. Вы, по сути, запрашиваете ИИ-агента в свободной форме, чтобы он специфицировал проект, а затем снова запрашиваете ИИ-агента, чтобы он прошел по задачам, и это занимает примерно 3 минуты, и у нас есть новый файл под названием `project_phases.md`. Вот как это выглядит с легендой: не начато, завершено или частично завершено. И у нас есть этот список задач. И затем, чтобы фактически начать реализацию, все, что я делаю, это снова в Cloud Code, очистить и посмотреть на `project_phases` и работать, например, над 1.1. Так что, по сути, запрашивая на человеческом языке, без слишком большой структуры, снова без излишеств и без перегрузки какой-либо системой. Это просто набор запросов, который также дает гибкость изменять запросы, когда мы хотим, добавлять что-то, удалять что-то, менять имена файлов этих описаний проектов, историй и тому подобного, и, возможно, экспериментировать в будущем с другой структурой. Вот почему мне нравится свобода над этими структурированными подходами, такими как Spec Kit, OpenSpec и другими. С другой стороны, это личное предпочтение. Может показаться, что мы изобретаем велосипед, так сказать. Если есть стандарты, почему бы нам не использовать OpenSpec или что-то еще? И для некоторых людей, для некоторых проектов, лучше использовать эти более структурированные инструменты. Для нас мы голосуем за свободу, так сказать. И вот здесь я возвращаюсь к оригинальному твиту Тарика из Cloud Code. Нет инструмента, кроме внутреннего инструмента «ask user question» Cloud Code, чтобы иметь этот мастер вопросов. Так что кажется, что создатели Cloud Code не используют никаких внешних инструментов спецификации. И кое-что еще более глубокое, что Тарик упомянул в ответе на другой твит, что возможности меняются с каждой моделью. Так что трудно иметь инструмент, который будет работать с моделью, потому что она постоянно меняется. И стратегия Cloud Code, по крайней мере, мы будем встраивать это больше в продукт. Так что я думаю, что произойдет в Cloud Code, но, возможно, в других с других сторон, нам больше не понадобятся специфические внешние инструменты, потому что многие внешние функции будут встроены в Cloud Code, в Cursor, во что бы то ни было ИИ-агент и IDE, которые вы используете. И вот еще один твит от Брайана Касла, создателя Agent OS, одного из инструментов, которые я показал ранее. Так что он ответил на мой твит, что я ставлю под сомнение инструменты разработки, управляемой спецификациями, и он согласен со мной, что большинство потребностей в этих инструментах отпало, поскольку модели и инструменты стали намного лучше. Особенно, я думаю, он имеет в виду Opus 4.5. Так что стратегия Брайана на будущее для Agent OS больше заключается в вычитании, чем в добавлении функций и структуры. Другими словами, все больше и больше людей полагаются на саму модель. Opus в данном случае и на инструмент, такой как Cloud Code, а затем мы полагаемся, по сути, на запросы, что, по сути, означает, что каждая команда и разработчик придумывают свой собственный набор запросов, своего рода изобретая велосипед, но, возможно, с другой стороны, так и должно быть. Это своего рода дикий запад ИИ, и никто на самом деле не знает, что они делают. Они проводят эксперименты. Это именно то, что я делаю на этом канале, и в целом много экспериментов, и я пробую вещи, и я выпускаю эти видео, и я думаю, что этот набор экспериментов и итераций продолжится. Модели будут становиться лучше, инструменты будут становиться лучше, появятся новые инструменты, затем новый набор методологий. Так что мой общий совет: делайте то, что работает для вас. Нет методологии, которая бы слепо подходила для каждого проекта, каждой команды, каждого случая использования. И вся идея разработки, управляемой спецификациями, — это очень хорошая идея в теории, что нам нужно структурировать спецификацию, что нам нужно работать над планированием, но инструменты не так важны, как раньше, даже 3-6 месяцев назад, по моему мнению. Опять же, мы можем обсудить, как обычно, в комментариях ниже. Так что да, это мои мысли и эксперименты по разработке, управляемой спецификациями, на данный момент, по состоянию на январь 2026 года. И снова, если вы хотите получить мои запросы и рабочий процесс, который я показал в последние 10 минут видео, после того, как это видео будет опубликовано, я размещу их как платную статью для платных подписчиков моего Substack. Каждую среду я отправляю бесплатные информационные бюллетени. Так что вы можете подписаться на это абсолютно бесплатно. Так что это последний выпуск с моими видео, а также новости от сообщества. Я увеличу это. Так что, если вы хотите получить эти ссылки с моими комментариями и другими вещами, вы можете подписаться бесплатно. Ссылка будет в описании ниже. Но если вы хотите получить дополнительный контент, который я думаю добавить каждую неделю, по крайней мере, один контент. Так что это на эту неделю, мои рекомендации для Laravel и PHP. И следующий контент будет рабочим процессом, который я показал в этом видео. Так что да, видео длиннее обычного, довольно много философии, так сказать. Что вы, ребята, думаете? Давайте обсудим все это в комментариях ниже. На этом все на этот раз, и увидимся в других.