Кирилл Русаков
Разработка

Laravel, Copilot и Spec-Driven Development: собираем пайплайн

Laravel, Copilot и Spec-Driven Development: собираем пайплайн

Привет, коллеги!

Мы все уже наигрались с ChatGPT и Copilot. Пофиксить баг, написать метод, сгенерировать тест — это стало рутиной. Но что дальше? Очевидно, что следующий шаг — не просто точечные запросы, а интеграция ИИ в сам процесс разработки.

Сегодня разберу два интересных подхода, которые сигнализируют о новом тренде: структурированной, почти инженерной работе с ИИ-ассистентами. Один — "народный кейс" от разработчика, другой — research-проект от самого GitHub.

1. Laravel Copilot Workspace: Конвейер специализированных агентов

Недавно я наткнулся на статью, где автор построил вокруг кастомных агентов GitHub Copilot (тех, что описываются в .agent.md файлах) целый рабочий конвейер для Laravel-проекта.

Суть подхода:

  • Специализация: Вместо одного "умного Copilot" создается целая команда узких специалистов: 10-requirements-create (аналитик), 20-architecture-plan (архитектор), 30-code-build (кодер), 40-tests-run (тестировщик), 50-docs-update (техписатель).
  • Общий контекст: Вся информация о проекте лежит в строго структурированных папках: inputs/ (ТЗ, домен), rules/ (стандарты команды), docs/ (документация). Каждый агент знает, откуда читать и куда писать.
  • Процесс как код: Работа разбивается на "батчи" (пачки задач), и агенты последовательно ведут проект по этапам, от идеи до релиз-пакета.

Это прагматичное решение проблемы контекста. Больше не нужно каждый раз объяснять ИИ "а вот у нас DDD, а вот тут такие-то правила". Контекст живёт в файлах, а агенты — это просто "исполнители" с разными ролями. Идеально ложится на Laravel с его четкой структурой.

2. Spec Kit от GitHub: Разработка через исполняемые спецификации (Spec-Driven Development)

Почти одновременно с этим GitHub анонсировал свой исследовательский проект Spec Kit. Идея идет еще дальше.

Суть подхода — SDD (Spec-Driven Development): Главный артефакт разработки — это спецификация (spec) на естественном языке. Не код, не ТЗ в Jira, а именно spec. Далее, специальный CLI-инструмент specify помогает:

  • Создать "конституцию" проекта (/speckit.constitution) — принципы и ограничения.
  • Написать spec (/speckit.specify) — что и зачем мы строим.
  • Создать технический план (/speckit.plan) — как и на чём.
  • Разбить на задачи (/speckit.tasks).
  • Исполнить (/speckit.implement) — и вот здесь ИИ на основе spec, constitution и plan генерирует код.

Фокус смещается с написания кода на проектирование и формализацию intent (намерения). Код становится производным, почти "скомпилированным" из спецификации.

Что общего и в чем разница?

Общее — это тренд:

  • Оба подхода борются с "vibe coding" — когда каждый запрос ИИ начинается с чистого листа.
  • И ИИ, и разработчик должны иметь единый источник правды о проекте.
  • Акцент на последовательности шагов, где результат одного этапа — основа для следующего.

Разница:

  • Laravel Workspace — это тактическое решение "снизу" для уже сложившегося процесса (Laravel + GitHub Copilot). Оно про автоматизацию и порядок.
  • Spec Kit — это стратегическая гипотеза "сверху" о новом виде разработки (SDD). Оно про смену парадигмы.

Зачем это PHP-разработчику сейчас?

  1. Создать папку project_context/ с README о домене и правилах, написать пару кастомных .agent.md файлов для типовых задач (например, "Создать Eloquent-модель с Observer и тестами") — это даст сиюминутный прирост в качестве и скорости.
  2. Даже если не использовать CLI, сама идея "сначала детальная spec, потом код" — это мощный mental-сдвиг. Попробуйте перед тем как писать фичу, не набрасывать код, а подробно описать её в Markdown-файле так, как если бы это было ТЗ для ИИ-коллеги. Вы удивитесь, сколько проблем отсеется на этапе проектирования.

ИИ становится частью CI/CD

Эти проекты показывают, что сообщество перестает воспринимать ИИ как магический чёрный ящик, начинают интегрировать в инженерные практики, строить вокруг него процессы, требовать воспроизводимости и структуры.

Для нас, backend-разработчиков, это значит, что скоро (а где-то уже сейчас) ценным навыком станет не только умение "договориться с Copilot", но и способность проектировать и описывать системы так, чтобы их понял не только коллега, но и AI-агент.

Что думаете, коллеги? Видите ли вы место подобным структурированным подходам в своих проектах или считаете, что это избыточная сложность?

11