Автаматызацыя разработкі Laravel за дапомогай AI-агентаў: стварэнне, тэставанне, вылечэнне, паўтарэнне

Цыкл копіювання-вставкі

Пасьцёрцуйце, як часта ў звычны дзень з асістэнтам для кодавання на AI выглядае такая процедура: пішыце запіт, скопіюйце рэзультат у рэдагар, запускайце php artisan test, пабачыце адмову, скопіюйце тэкст памылкі, вставьце яго знова ў AI, сказайце «будзь ласка, выправіце гэта» і пачніце знова з кроку копіювання.

Дзеякі распрацоўшчыкі павтараюць гэты цыкл дзесяткі разоў на дзень. Гэта называецца розработкай пад адказом AI, пры тым самым найбольш занятым у гэтым цыкле не ёсць AI — гэта чалавек, які перадае сообшчы между модэлем і тэрміналам: вяршыць рашэнні, калі трэба запускаць тэсты, чытае памылкі, ацэнюе, чы не трэба ўжо адной выправкі, і вставляе все туды-сюды. AI застаёцца без дзеяння пакуль не прыйдзе наступныя інструкцыі.

Лепшая структура дозволяе усунуты людського кур’ера. Невеліка сістэма можа самостыйно віконуваты цыкл створэння, тэстування, віправлення і повторэння робіт до повного завершэння, а людына втручаецца лішэ під час остаточного перэгляду. Тут вікорыстовуюцца інструменты Laravel Boost і OpenCode CLI, які підходзяць для сучасноі екосістэмі Laravel. Пояснення наводзяцца повільно, шчоб той, хто ніколі ранішэ не працював з цымі інструментамі, міг іх зрозуміты.

Словнік

Дэякі тэрміні зустрычаюцца неодноразово:

• Agent: Штучній інтэлект, якому надано чытко візначэне задачы і певній набір інструментаў, подыбно до співробітніка з пісьмовімі обов’язкамі.
• MCP (Model Context Protocol): Коннектор, праз які ШЫ можа ставіты запітання непасрэдна до вашоі сістэмі, чы то база даных, чы журналі, шчоб унікнуты неправільніх прыпушчэнь на основі введэніх даных.

CLI (інтэрфейс командной лініі): програма-канал, якая працюе праз введэнне команд у прампт тэрміналу замест адкрыцья графічнага экрана.

Задання і абаранда: спосаб, якім Laravel адрабатвае заданні на фоне, паэтапна, так што жадны корыстнік не застанетсяць у стане чакання.

Оркестрайтар: кантролер, які задае прабег выконвання заданняў, сочыць за тым, чыя ўжо рэч, і ведае, дзе продаважыць праз працяванне пасля абэрэння.

Пытанне ўжо не пра тое, "чы можа ШЫ пісаць код"

Кожны, хто вжываў Claude Code, Cursor або падобныя інструменты з Laravel, ведае, што ШЫ можа ствараць міграцыі, модэлі, правілы і тэсты. Адныя заставаленые проблемы — гэта ручны рабочы працэс, які трэба выконваць праз гэта:

Developer → AI → Developer → Test → Developer → AI → Developer → Test → ...

Кожныя стрэлкі пазначаюць чалавека, які ручная працай пераводзіць кантэкст з аднаго крока на іншы, вырашаючы, што прыйшла час для тэставання або што памылка трэба перадаць назад AI.

Поручыце з автаматызаванай версіяй:

Developer → Orchestrator → Build → Test → (failed? → Fix → Test again) → Review → Done

Разлік можа здавацца незначным, але ён значнаўы. Цяпер існуе оркестрабілістар – слой, які ведае парадак выканання задач, калі трэба праказаць спробу занова і калі трэба зупыніцца, без неабходнасці сталага нагляду кожныя трыдзесят секундаў.

Laravel таксама рухаецца ў гэтым напрамку. Laravel Boost быў створаны так, каб агенты для кодавання на базе ШЫ отрымвалі рэальны кантэкст пра застосунак Laravel, а не толькі спадзяваліся на загальныя шаблоны.

Два главных інструмента

Laravel Boost: перакладчык межу ШЫ і застосункам

ШЫ можа быць сільным у Laravel загалом, але ў вашам конкрэтным праекце застаўця слепым. Ён не ведае, якую версію Laravel вы вікорыстоўваеце, як насправдэ працюе ваша база дадзеных, чы вы вікорыстоўваеце Livewire чы Inertia, або якія правілы называння прабачыла ваша команда.

Boost — гэта пакет Composer, які розкрывае для AI абсалютны стан праекту. Ён працюе праз MCP, таму AI можа безпасэрвна запытваць прыкладненне: адзірнуцца на схему базы дадзеных, паглядзець на існуючыя маршруты, паблікаваць найнэўжоўшыя памылкі, выкананыць каманды Artisan і шукаць інфармацыю ў дакументах Laravel, якія адпаведаюць версіям пакетаў, якія фактычна ўстановлены.

Для установкі трэба две каманды:

composer require laravel/boost --dev

php artisan boost:install

Другій варыянт ўзаемадзейны. Ён запытае, які IDE чыра AI-інструмент вы вжываеце, і запускае адпаведныя рэсурсы.

Варта чыста сказаць, што Boost тлумачыць кантэкст і не прыме якіх-лібо рашэнняў. Ён не скажае "заўядзейце тэсты зараз" чыра "запускайце агента для выправлення пасля абыякавасці". Яго ўжоўнае завадзе — не дазволіць агентам не бачыць рэальнаг стану прыкладнення.

OpenCode: дзе агент выканае работу

Калі Boost тлумачыць кантэкст, то OpenCode — гэта рабочая атмосфера: CLI, створаны спецыяльна для кодавання з адной помочы AI. На адзінцу з звычайных чат-ботаў, ён дазволяе вам задаць калькі агентоў з разнымі абавязкамі, напрыклад, аднаго, які піша код, і другога, які чытае рэзультаты тэстаў; кожны з іх мае свае інструкцыі і межы.

OpenCode таксама можа быць падключаны да сервераў MCP, у тым чыра Boost. Пасля падключэння ўсе, што прысутнае у Boost, становіцца доступным для таго агента, які працуе ўнутры OpenCode.

Практычныя практыкі: запоўненне Boost у OpenCode

Спачатку спробуйце робіць усё вручную ў тэрмінале, перш чым автоматызаваць які-небудзь працэс.

1. Наведачы OpenCode на Boost

Калі Boost ўстановлена, OpenCode павінна дазнацца, дзе знаходзіцца ўсё ў яе сервера MCP. Гэтая інфармацыя зберагліваецца у файле opencode.json у корні праекта:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "laravel-boost": {
      "type": "local",
      "command": ["php", "artisan", "boost:mcp"],
      "enabled": true
    }
  }
}

Точныя каманды можа разлічвацца залежна ад версіі Boost, таму трэба следаваць тым, што генеруе php artisan boost:install, а не копіюваць яго слепа. Гэта адна з тых частак, якія найчырэйша можу зменіцца между выданнямі.

Паказваце, чы рэштар OpenCode можа бачыць сервер:

opencode mcp list

Калі laravel-boost паказваецца як з’яўлены, агенты маюць доступ да всьго, што надае Boost.

2. Стварыце агентаў з разнымі абавязкамі

Замест аднаго агента для всіх задач, раздзеліце абавязкі. Стварыце файл .opencode/agent/builder.md у праекце:

---
description: Build Agent for new features
mode: primary
tools:
  write: true
  edit: true
---
You are the Build Agent.
Use Laravel Boost tools to understand the application structure
before writing any code. Never assume the database structure -
always check the schema first. Write tests for every new behavior.
At the end of your work, return ONLY JSON in this format:
{"status": "success", "files_changed": [...], "summary": "..."}

Лінія tools.write: true дазваляе гэтам агенту мяніць файлы. Наступны агент будзе мець write: false, што робіць яго толькі для чытання і не дазваляе яму чаго-небудзь змяніць, а прычына, якая мае значэнне, будзе паказана за час.

Спісавайце зарэгістраваныя агенты:

opencode agent list

3. Спачатку запускайце яго ручная

opencode run --agent builder "Add a task assignment feature to TaskFlow according to the requirements in TASK.md"

Калькі лекцыі пра гэтыя каманды:

• --agent выбірае, які агент будзе работаць – будувальнік, тэставальнік чы ўсё іншае, заданае раней.
• Дадзенне --format json прыводзіць да таго, што выходны дадзеныя будуць у сыром фармаце, а не у фармаце, падходзячым для людзей. Самэ гэта будзе вікорыстоўвацца пазней у вызовах PHP.
• --session і --continue дазволяюць агенту памятаць пакананыя пераговоры, замест таго каб ён пачынаў з нуля ў кожны раз.

Спробаваце яго рукою колькі разоў, каб адчуць яго працэю, перш чым автоматызаваць.

Конкрэтны прыклад: прадзеленне заданняў у TaskFlow

Одны працоўны прыклад дапамагае застацца на практычным роўні. Уявіце просты прыстаў для керавання заданнямі пад назвай TaskFlow, якому трэбае такая можлівасць: корыстувачы могу перадаць заданне іншаму корыстувачу, але толькі внутрь праекта, да якога ўжо і той, і іншы маюць доступ. Разбіўка на трэбаванні:

1. A task has an assignee column (belongs to a User).
2. A user can only assign tasks within a project they're a member of.
3. A user must not assign or access tasks from other projects.
4. All of the above must be covered by automated tests.

Гэта распашчынае выкліканне, якое і робіць гэта прыкладам добрым. Такія справы часта патрабуюць двух-трох спроб, прычыму пытанне пра тое, хто можа адрыхнуцца да чаго, тэхнічна называема автарызацыяю, стане абсалютна ясная. Самэй тут і з’яўляецца патрэба ў автаматызаванай цікле.

Чаму працэс патрабуе журналу

Калі работа выканана на фоне, ніхто не можа паспакоўвацца на памяць пра тое, „какі ж то быў бяг?“. Усё павінна быць зафіксаванае, а тут гэта значыць табліца базы дадзеных, якая выступае як журнал прыбылі:

Schema::create('ai_tasks', function (Blueprint $table) {
    $table->id();
    $table->string('type');
    $table->string('status')->default('pending');
    $table->text('prompt');
    $table->json('result')->nullable();
    $table->unsignedTinyInteger('iteration')->default(0);
    $table->timestamps();
});

Модэль:

class AiTask extends Model
{
    protected $fillable = [
        'type', 'status', 'prompt', 'result', 'iteration',
    ];

    protected function casts(): array
    {
        return ['result' => 'array'];
    }
}

Колонка status несе важнае значэнне. Яна праходзіць праз гэтыя стадыі:

pending → building → testing → (fixing → testing)* → reviewing → completed / failed

Чаму не простая пазнака done? Таму што оркестрайтар павінен ведаць, на якій стадзіі знаходзіцца праца, а не проста ўжо завершылася яна чы не. Адстэйк стадзій таксама дазволяе пракрыты рэжым пасля таго, як працоўнік зламаеся пад час выканання, і робіць можлівым бачыць актуальны прагрэс у якомусь месца.

Споўненне прыемнасі OpenCode для PHP

Людзі часта прыхоўваюць гэты крок: не распрысквайце команды OpenCode па многіх файлах. Калі пазней змяніцца інструмент, не трэба будзе рэдагаваць дзесяткі месцаў. Створыце адну точку входу, інтэрфейс:

interface AgentRunner
{
    public function run(string $agent, string $prompt): array;
}

Потым справжняе адаптаванне, якое вызывае OpenCode з PHP:

class OpenCodeAgentRunner implements AgentRunner
{
    public function run(string $agent, string $prompt): array
    {
        $result = Process::timeout(600)->run([
            'opencode', 'run',
            '--agent', $agent,
            '--format', 'json',
            $prompt,
        ]);

        if (! $result->successful()) {
            return [
                'status' => 'error',
                'error' => $result->errorOutput(),
            ];
        }

        return json_decode($result->output(), true) ?? [
            'status' => 'error',
            'error' => 'Agent output was not valid JSON',
        ];
    }
}

З’ўяжыце яго ў паслужальніку:

$this->app->bind(AgentRunner::class, OpenCodeAgentRunner::class);

За дапамою гэтага шаблона кожны Job супрацоўвае толькі з AgentRunner і не пакушаецца дазнаць, чыі ён элемент — OpenCode чы інша прыстановка.

Одны Job на стадыю

Для тых, хто новы ў Laravel Jobs: Job — гэта задача, якая выконваецца на фоне праз канэ, таму ніхто не мусі чакаць, пакуль яна завершыцца.

Задача будовы

class BuildFeature implements ShouldQueue
{
    public function __construct(protected AiTask $task) {}

    public function handle(AgentRunner $agent): void
    {
        $result = $agent->run(
            agent: 'builder',
            prompt: $this->task->prompt,
        );

        $this->task->update([
            'status' => 'testing',
            'result' => $result,
        ]);

        RunTests::dispatch($this->task);
    }
}

Хутчэй тут запускаецца агент Build, яго рынак зберагаецца, і працэс пераходзіць безпосерэдна да наступнай задачы (RunTests) без неабяжных клікаў.

Задача тэставання

Гэтая задача спецыяльна простая. Яй не патрэбна разумеўка коду. Яна запускае набор тэстаў і чытае яго рынак.

class RunTests implements ShouldQueue
{
    public function __construct(protected AiTask $task) {}

    public function handle(): void
    {
        $result = Process::timeout(300)->run('php artisan test --compact');

        if ($result->successful()) {
            $this->task->update(['status' => 'reviewing']);
            ReviewFeature::dispatch($this->task);
            return;
        }

        $this->task->update(['status' => 'failed']);
        AnalyzeFailure::dispatch($this->task, $result->output());
    }
}

Прыцэпленне простае:

Test
 ├── passed → move to Review
 └── failed → move to Analyze

Не перадавайце неапдэтаваныя паказанні праблем агенту

Гэты урок — найлёгшы для прахадзення, ал яго вплыв на якасць ўельмі вялік. Калі проста сказаць агенту, што тэст не выйшоў, і папросіць яго выправіць гэта, гэтага будзе занадто мало. Агент пачынае все з нуля, перачытае кожны файл і намагаецца з’ясавіць, што пайшло не так.

Спачатку структуруйце інформацыю пра неудачу:

{
  "status": "failed",
  "failed_tests": [
    {
      "name": "user_cannot_assign_task_from_other_project",
      "error": "Expected response status code [403] but received 200."
    }
  ]
}

Tады які агент вялікія дзеўы, чыльныя толькі для даглыбокага аналізу, з інструкціямі, якія строго обягваюць тое, што вялікія дзеўы можа робіць:

You are the Debug Agent.

Analyze the failed tests below. DO NOT modify any files.
Inspect: relevant models, policies, migrations, and tests.
Return JSON with:
- root_cause
- affected_files
- recommended_fix
- risk_of_regression

Чаму раздзеляць дыягназы і рэшэнне? Ёсць мета стварыць прасоц между разуменням проблэмы і выкананнем рэмонту. Калі агенту проста сказаць вылечыць проблемы, следы, якія паказваюць, чаму конкрэтны файл змяніўся, знікаюць, і падзеічна перагледка стае набагато сложнейшай для парабярання.

Для TaskFlow выход Дэбаг-агента мог бы выглядаць так:

{
  "status": "analyzed",
  "root_cause": "TaskPolicy does not verify project membership before allowing assignment",
  "affected_files": ["app/Policies/TaskPolicy.php"],
  "recommended_fix": "Add a project membership check inside the assign() method",
  "next_action": "fix"
}

Гэта была бы правдападобная нарадка, адколь гэта адна з найболей распашчытых памылак узначэння прав: правіла, якія пераглядаюць толькі тое, чы ў карыстальніка ёсць прыўязка, а не тое, чы ён насправдзе належыць да праекту.

Выправіце, а потым зноў працаваце; ніколі не выправілі — і готова.

class FixFeature implements ShouldQueue
{
    public function __construct(protected AiTask $task, protected array $analysis) {}

    public function handle(AgentRunner $agent): void
    {
        $result = $agent->run(
            agent: 'fixer',
            prompt: json_encode($this->analysis),
        );

        $this->task->increment('iteration');
        $this->task->update([
            'status' => 'testing',
            'result' => $result,
        ]);

        RunTests::dispatch($this->task);
    }
}

Заўважыце, што пасля вылікавання статус вяртаецца да testing, а не пераходзіць у completed. Прынцып чыстае: агент не мае права прызнаваць ся завершаным толькі таму, што файл зменіўся. Яедыным правамерным доказам правільнасці ёсць набор тэстаў, які дзеясно быў запусцаны знову, а не сабстрактныя тверджэння самога агента.

Оркестрайтар як кантролер трафіку

Спачатку можа здавацца прыемным выстаўляць заданнія ў лінейную ланцюговую структуру:

Bus::chain([
    new BuildFeature($task),
    new RunTests($task),
    new ReviewFeature($task),
])->dispatch();

Але гэта толькі лінія. Як толькі з’являецца якась гілка, напрыклад, паверненне для выправлення пасля невыпання тэсту, лінейны ланцуг стае недастатковым. Тут патрэбны ўместы некія «контролеры руху», якія ў кожны раз, калі іх запрашваюць, пераканальваюць тэкушчы статус і выбіраюць наступны крок:

class AgentOrchestrator
{
    public function next(AiTask $task): void
    {
        match ($task->status) {
            'pending'   => BuildFeature::dispatch($task),
            'testing'   => RunTests::dispatch($task),
            'failed'    => AnalyzeFailure::dispatch($task),
            'fixing'    => RunTests::dispatch($task),
            'reviewing' => ReviewFeature::dispatch($task),
            'completed', 'stopped' => null,
            default => throw new LogicException("Unknown status: {$task->status}"),
        };
    }
}

Змена падходу ў значныя. Оркестратор больш не запытаецца, калькі ўжо заведама задача. Ён запытаецца, якая пераходна процедура ёсць дапустыма за ныякім статусам. Так лёгчэ зарабляць належныя паследкі, а новы этап, такі як перагляд безпекі, можа быць дадзены без наражання на спяшанне весьго працэсу.

Абмежыце колькасць пракатоў

Без ліміту можа развівацца такі сцэнарый:

Fix → Test fails → Fix → Test fails → Fix → Test fails → ...

Гэта трывае час, а кожны вызов Шуму таксаванся. Рашэнь — цяплы ліміт:

class RunTests implements ShouldQueue
{
    protected const MAX_ITERATIONS = 5;

    public function handle(): void
    {
        if ($this->task->iteration >= self::MAX_ITERATIONS) {
            $this->task->update(['status' => 'needs_human_review']);
            return;
        }
        // ... run tests as usual
    }
}

Калі пяць спроб выправлення недасцца, сістэма зупіняецца і пазначае задачы для люсты, замест таго каб працаваць без канца. Гэта не павінна обовязкова значыць, што ШЫ паслаба ў сваій працы. Інодзе ваказанні ёсць неяснымі, або для прыняцтва рашэння даскледзецца людзіні.

Тэсты з статусам «зелены» не означаюць, што функцыя завершана

Лёгка забыць пра гэта, калі сістэма, якая працуе сама, здаецца захоплёнай. Падазроўваю, што агент запішае ўдзейсненне на кшталт:

public function assign(User $user, Task $task): bool
{
    return $user->isAdmin();
}

Все тэсты можаць прыйсці як пасуючыя, таму што ў iх абдзерваюцься толькі сцэнарыя, якія хтось выдумаў у тым часе. У рэальных трэбаваннях было напісана, што корыстнік павінен быць членам праекту, а не што ён павінен быць адміністратаром. Логіка некорэктная, хоць усе тэсты залішаюцца пасуючымі.

Самэльга гэтыя працэсы ўразлівы:

Build → Tests pass → Deploy immediately

Бялейшы варыянт выглядае так:

Build → Test → (if failed: Debug → Fix → Test again) → Human review → Deploy

Этап адміністрацыі все ж такі мусіць включаць чалавека, прынеймна для всіх падзеяў, якія стосуюцца таго, хто можа даўацы доступ да чаго. Для змян, чутлівых да безпекі, такіх як гэта, разумна ўмова ад чалавечай пераглядкі пры з’еднанні, незалежна ад таго, насколькі чыста выглядае автаматызаваная процедура.

Паралельныя агенты і канфлікты файлаў

Ідэя адрабаткі Security Agent і Research Agent адночасна несе ў сабе пахідню. Калі два агенты можуць запісваць той самы файл праўдачы, выступае сітуацыя канкурэнціі, што значыць, два працэсы перазапішуць працу адна другой.

Agent A → writes Task.php
Agent B → reads Task.php (nearly at the same time)
Agent A → writes Task.php again

Канонічная правіла — гэта разпад адміністрацыйных обавяннасцей на тые, якія могу пісаць, і тые, якія можу толькі чытаць:

Research Agent   → read-only
Review Agent     → read-only
Security Agent   → read-only
Build Agent      → write access
Fix Agent        → write access

Гэта таксама пояснюе рэччу з лінійкай tools.write: true у пакульшым файле builder.md. Яна кантролюе, якіе агенты можаць змяніць файлы, а якія толькі можаць іх пераглядаць.

Супрацавайце з супер-агентам

Сярод найбольшых спакус калі гэта запрацоўвае — гэта адзін агент, які плануе, стварае, тэстуе, дыбагуе, вылечвае, пераглядае і развяртае. Гэта часта прыносіць наэфектныя наследкі. Чым большая адпаведальнасць лежыць на адзінам агенце, чым большых дазведамоцяў яму трэба обрабоўваць, чым большых інструментаў у яго ёсць, тым больша верагатыба, што ён зрабіць неправы выбар. Лепшая распадзіць агентаў па адпаведальнасцях:

Planner   → designs the approach
Builder   → writes the new feature's code
Tester    → runs the test suite
Debugger  → diagnoses failures (read-only)
Fixer     → executes the fix
Reviewer  → final quality check (read-only)

Гэта тая ж самая прынцыпа, як і адказ утрыманню адной вялікай класы, якая караце заўсёды ўсякія задачы ў працоўніку. Таксама не трэба ствараць аднаго агента, які робіць усё.

Мінімальны спіс пераканаў пры рэальным выкарыстоўванні

Для эксперыментаў у рэальным праекце гэтыя пункты трэба включыць з самага пачатку, а не дадаць пазней:

• жорсткі ліміт па перапрыбутках, каб цыкл выправлення не могаў работаць без канца
• ліміт часу для кожнага запыту, які выкананы агентам
• ліміты доступу да файлаў, якія паслядуюць ролі агента — толькі чытанне або запіс
• тэсты, якія ўжо існуюць і праходзяць, перш чым статус можа быць пераказаны на перагляд
• пярэчненне чалавека перш чым ўсё прайдзе у працоўны рэжым
• логаванне кожнай рашэння, якое прымівае агент, а не толькі канечнага рэзультата
• захаванне секрэтных файлоў, такіх як .env, каб агент ніколі не прачытаў іх па адной чыстай спадчынне

Пашчык — останній елемент частацяка недооценяўся. Колы агент можа выпавляваць команды на сістэме праз Process::run(), ён фактычна можа ефектывно віконаваць майжэ будзь-які команды на тому серверэ. Обмежэнія доступу — гэта не варыкант, а обовязковая умэка з першага дня.

Фактычная роль Boost

Ось повная картынка:

Developer (us)
    │
    ▼
Orchestrator (traffic controller, running on Laravel Queue)
    │
    ├── Build Agent
    ├── Test Agent
    ├── Debug Agent
    └── Fix Agent
          │
          ▼
      OpenCode (where the agent does its work)
          │
          ▼
    Laravel Boost (context translator, via MCP)
          │
          ▼
    Our Laravel application

Boost ніколі не вырашае сам адзначыць запуск тэстоў чы выкананне агента з парадкамі пасля неудачы. Ён выкаанае аднае, важліваяе заведаменне: прымешчаецца, каб кожны агент у праекце розумеў рэальны стан прыкладнення і не спадзяваўся на загальныя шаблоны. Пытанні пра тое, хто дзеяе, у які момент і калі все зупініцца, застаюцца за аранжыроўчыкам, створаным на базе Laravel Queue.

Пытанне, якое трэба задаць зараз

Кілька гадоў тыму цікавым пытаннем было, чы можа ШЫ напісаць правільны код на Laravel. Ён явна можа і продовжвае прагрэсаваць. Болей актуальным пытаннем сёння ёсць тое, чы можа ШЫ выканаць свой сабеўласны цыкл з будавання, тэставання, неудачы, разумення прычыны, парадку і знову тэставання, пакуль ён справа не будзе завершаны, без людзі як ручнага кур’ера на кожным кроцы.

Сцэнарый TaskFlow парадызначае, што адказ — так, за ўмовы, калі не забудзецца троха пунктав. Неабходна чыстая фіксацыя прагрэсу, трэба встановіць часткавы ліміт на практыку перапрыбуткаў, а тэсты з рэзультатам «зелёны» павінны лячыцца як адны сігнал, а не канец парадку.

Boost дапамагае агентам разумець кантэкст прыемлівання. OpenCode дае ім месца для працы. Laravel Queue стае канструкцыяй, якая аранжуе усё па парадку. А распрацоўшчыкі можаць падняцца на вышэйшы ранг — з мануальных аператараў на кожным кроцы да пераглядачаў фінальных рэзультатаў.

Vibe coding прышвартоўвае працэс напісання коду. Такая оркестрацыя дазволяе працэсу кодавання працаваць самам, і самэ гэта робіць експерыменты з AI-кодаваннем цікавымі.