Automatyzacja rozwoju w Laravel za pomocą agentów AI: tworzenie, testowanie, naprawianie, powtarzanie

Biegacz z kopiowaniem i wklejaniem

Policz, jak często typowy dzień z asystentem do programowania opartym na AI wygląda w ten sposób: piszesz zapytanie, kopiujesz wynik do edytora, uruchamiasz php artisan test, widzisz błąd, kopiujesz tekst błędu, wklejasz go z powrotem do AI, prosisz „proszę to naprawić” i zaczynasz od nowa od kroku kopiowania.

Część programistów powtarza ten cykl kilkanaście razy dziennie. Nazywa się to rozwojem wspomaganym przez AI, ale najbardziej zajętą osobą w tym procesie nie jest AI – to osoba przekazująca wiadomości między modelem a terminalem: decydująca, kiedy należy uruchomić testy, czytająca błędy, oceniająca, czy potrzebna jest kolejna korekta, oraz wklejająca wszystko tam i z powrotem. AI pozostaje bezczynna aż do przybycia następnego polecenia.

Lepsze rozwiązanie eliminuje potrzebę ludzkiego kuriera. Mały system może samodzielnie przeprowadzać cykl tworzenia, testowania, korygowania i powtarzania, aż praca zostanie naprawdę ukończona, przy czym człowiek interweniuje tylko podczas ostatecznej weryfikacji. Narzędzia użyte tutaj to Laravel Boost oraz OpenCode CLI – dwa tooli pasujące do dzisiejszego ekosystemu Laravel. Wyjaśnienia są celowo powolne, aby osoba, która nigdy ich nie używała, mogła je zrozumieć.

Słownictwo

Kilka terminów pojawia się wielokrotnie:

• Agent: sztuczna inteligencja, której przydzielono określone zadanie oraz zestaw narzędzi, porównywalna z pracownikiem o określonej roli.
• MCP (Model Context Protocol): interfejs umożliwiający sztucznej inteligencji zadawanie pytań bezpośrednio do systemu, czy to bazy danych, czy logów, dzięki czemu przestaje zgadywać na podstawie tego, co przypadkowo wpisano.

CLI (interfejs linii poleceń): oprogramowanie operacyjne, w którym komendy wprowadza się w pole promptu terminala zamiast przeglądać interfejs graficzny.

Zadania i kolejka: sposób, w jaki Laravel obsługuje prace w tle, jedno zadanie po drugim, dzięki czemu żaden użytkownik nie musi czekać bezczynnie.

Orkiestrator: kontroler ruchu, który określa sekwencję wykonywania zadań, śledzi, kto ma teraz priorytet, oraz wie, gdzie kontynuować pracę po awarii.

Pytanie przesunęło się od „czy sztuczna inteligencja może pisać kod”

Każdy, kto korzystał z Claude Code, Cursor lub podobnego narzędzia do pracy z Laravel, wie już, że sztuczna inteligencja potrafi tworzyć migracje, modele, zasady bezpieczeństwa oraz testy. Pozostawionym problemem jest ręczny proces pracy z tymi elementami:

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

Każda strzałka oznacza osobę, która ręcznie przenosi kontekst z jednego kroku do następnego, decydując, że nadszedł czas na testowanie lub że błąd wymaga zwrotu do AI.

Porównaj z wersją zautomatyzowaną:

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

Różnica wydaje się niewielka, ale ma duży wpływ. Istnieje teraz koordynator, warstwa, która zna kolejność działań, kiedy próbować ponownie i kiedy przestać, bez konieczności ciągłego nadzoru co trzydzieści sekund.

Laravel również zmierza w tym kierunku. Laravel Boost został stworzony po to, aby agenci kodujące przy użyciu sztucznej inteligencji otrzymywały rzeczywisty kontekst dotyczący aplikacji Laravel zamiast zgadywać na podstawie ogólnych wzorców.

Dwie główne narzędzia

Laravel Boost: tłumacz między sztuczną inteligencją a aplikacją

Sztuczna inteligencja może być bardzo dobrze przygotowana do pracy z Laravel ogólnie, ale nadal mogła być praktycznie bezradna w twoim konkretnym projekcie. Nie wie ona, jaką wersję Laravel używasz, jak faktycznie zorganizowana jest twoja baza danych, czy używasz Livewire lub Inertia, ani jakie zasady nazewnictwa przyjęła twoja grupa.

Boost to pakiet Composer, który pozwala sztucznej inteligencji zobaczyć rzeczywisty stan projektu. Działa poprzez MCP, dzięki czemu sztuczna inteligencja może bezpośrednio pytać aplikację: sprawdzać schemat bazy danych, oglądać istniejące trasy, widzieć najnowszy błąd, wykonywać polecenia Artisan oraz szukać informacji w dokumentacji Laravel odpowiadających aktualnie zainstalowanym wersjom pakietu.

Instalacja wymaga dwóch poleceń:

composer require laravel/boost --dev

php artisan boost:install

Drugi z nich jest interaktywny. Pyta, jakiego IDE lub narzędzia AI używasz, i instaluje odpowiednie zasoby.

Warto jasno zaznaczyć, że Boost tłumaczy kontekst, ale nie podejmuje decyzji. Nie powie „wykonaj testy teraz” ani „uruchom agent naprawczy w przypadku błędu”. Jego jedynym zadaniem jest zapobieganie temu, by agenci byli ślepi na rzeczywisty stan aplikacji.

OpenCode: miejsce, gdzie agent wykonywa pracę

Jeśli Boost tłumaczy kontekst, to OpenCode to warsztat – interfejs wiersza poleceń stworzony specjalnie do programowania przy użyciu AI. W odróżnieniu od zwykłego chatbota umożliwia definiowanie kilku agentów o różnych obowiązkach, na przykład takiego, który pisze kod, oraz innego, który analizuje wyniki testów; każdy z nich ma własne instrukcje i ograniczenia.

OpenCode może również łączyć się z serwerami MCP, w tym z Boost. Po połączeniu wszystko, co oferuje Boost, staje się dostępne dla danego agenta działającego wewnątrz OpenCode.

Praktyka: łączenie Boost z OpenCode

Najpierw spróbuj ręcznie wykonać różne czynności w terminalu, zanim cokolwiek zautomatyzujesz.

1. Wskazanie OpenCode na Boost

Gdy Boost jest zainstalowany, OpenCode musi dowiedzieć się, gdzie znajduje się jego serwer MCP. Te informacje trafiają do pliku opencode.json w korzeniu projektu:

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

Dokładna komenda może się różnić w zależności od wersji Boost, więc należy postępować zgodnie z tym, co generuje php artisan boost:install, zamiast kopiować to ślepo. To jeden z elementów, które najczęściej ulegają zmianom pomiędzy wersjami.

Należy potwierdzić, że OpenCode może widzieć serwer:

opencode mcp list

Jeśli laravel-boost jest wymieniony jako połączony, agenci mają dostęp do wszystkiego, co udostępnia Boost.

2. Stworzenie agentów o różnych obowiązkach

Zamiast jednego agenta do wszystkich zadań, podziel obowiązki. Stwórz plik .opencode/agent/builder.md w projekcie:

---
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": "..."}

Linię tools.write: true umożliwia temu agentowi modyfikację plików. Późniejszy agent otrzyma write: false, co sprawi, że będzie tylko do odczytu i nie będzie mógł nic zmienić, a powód tego wkrótce zostanie wyjaśniony.

Wylistuj zarejestrowane agenty:

opencode agent list

3. Najpierw uruchom to ręcznie

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

Kilka uwag na temat tego polecenia:

• --agent określa, który agent ma zostać uruchomiony – czy to budowniczy, tester, czy jakiś inny zdefiniowany agent.
• Dodanie --format json sprawia, że wynik to surowe dane zamiast formatu przeznaczonego do wyświetlania dla ludzi. To właśnie zostanie później użyte w wywołaniu PHP.
• --session i --continue pozwalają agentowi pamiętać wcześniejszą rozmowę zamiast zaczynać od nowa za każdym razem.

Wykonaj je ręcznie kilka razy, aby lepiej się z nimi zapoznać przed automatyzacją.

Konkretny przypadek: przydzielanie zadań w TaskFlow

Jedyny praktyczny przykład pomaga utrzymać rzeczy w realiach. Wyobraźmy sobie prostą aplikację do zarządzania zadaniami o nazwie TaskFlow, która potrzebuje następującej funkcjonalności: użytkownicy mogą przekazać zadanie innemu użytkownikowi, ale wyłącznie w ramach projektu, do którego obaj mają dostęp. Rozbicie na wymagania:

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.

To powszechny wymóg, który sprawia, że jest to dobry przykład. W takich przypadkach często potrzeba dwóch lub trzech prób, zanim kwestia tego, kto może uzyskać dostęp do czego, technicznie nazywana autoryzacją, stanie się doskonale rozwiązana. Właśnie wtedy automatyczny cykl sprawdzeń odgrywa kluczową rolę.

Dlaczego proces wymaga dziennika zdarzeń

Gdy praca jest wykonywana w tle, nikt nie może polegać na pamięci, by przypomnieć sobie „jak brzmiał ten błąd?”. Wszystko musi być zapisywane, a w tym przypadku oznacza to tabelę bazy danych pełniącą funkcję dziennika postępów:

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();
});

Model:

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

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

Kolumna status ma kluczowe znaczenie. Przechodzi przez następujące etapy:

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

Dlaczego nie użyć zwykłej flagi done? Ponieważ orkiestrator musi wiedzieć, na jakim etapie znajduje się praca, a nie tylko to, czy została zakończona. Śledzenie etapów pozwala również na wznowienie działania po awarii procesora w trakcie wykonywania zadań oraz na widoczność aktualnego postępu w konkretnym miejscu.

Łączenie OpenCode z PHP

Ludzie często pomijają ten krok: nie rozrzucajcie poleceń OpenCode po wielu plikach. Jeśli narzędzie zostanie później zamienione, nie powinno być konieczne edytowanie dziesiątek miejsc. Stwórzcie jeden punkt wejścia, interfejs:

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

Następnie rzeczywista implementacja, która wywołuje OpenCode z 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',
        ];
    }
}

Zwiąż to z dostawcą usług:

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

Dzięki temu wzorcowi każda zadań komunikuje się wyłącznie z AgentRunner i nie obchodzi jej, czy za nią stoi OpenCode, czy coś innego.

Jedno zadanie na etap

Dla tych, którzy dopiero poznają Laravel Jobs: zadanie to operacja wykonywana w tle za pomocą kolejki, więc nikt nie musi czekać, aż się zakończy.

Zadanie budowania

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);
    }
}

Tutaj uruchamia się agent budowania, jego wynik jest zapisywany, a proces przechodzi bezpośrednio do następnego zadania (RunTests) bez konieczności ręcznego klikania.

Zadanie testowe

To zadanie jest celowo uproszczone – nie wymaga zrozumienia kodu. Uruchamia zestaw testów i odczytuje jego wynik.

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());
    }
}

Procedura jest prosta:

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

Nie przekazuj agentowi surowych błędów

To najłatwiejsza do pominięcia lekcja, a jednocześnie ma największy wpływ na jakość. Powiedzenie agentowi tylko, że test się nie udał, i poproszenie o naprawę to zbyt mało. Agent musi zaczynać od zera, ponownie czytając każdy plik i próbując zgadnąć, co poszło nie tak.

Najpierw strukturyzuj informacje o błędzie:

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

Następnie przekaż to agentowi, którego jedynym zadaniem jest diagnoza – nazwijmy go Debug Agent – wraz z instrukcjami ściśle ograniczającymi to, co może robić:

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

Dlaczego oddzielać diagnozę od naprawy? Aby stworzyć lukę pomiędzy zrozumieniem problemu a wykonaniem naprawy. Jeśli agentowi po prostu każe się naprawić rzeczy, ślad wskazujący, dlaczego dany plik uległ zmianie, znika, a ostateczna weryfikacja staje się znacznie trudniejsza.

Dla TaskFlow wynik działania Debug Agenta prawdopodobnie będzie wyglądał tak:

{
  "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"
}

To byłoby wiarygodne odkrycie, ponieważ jest to jeden z najczęstszych błędów autoryzacji: zasada, która sprawdza jedynie to, czy użytkownik jest zalogowany, a nie to, czy rzeczywiście należy do projektu.

Napraw, a następnie przetestuj ponownie – nigdy nie poprzestawaj tylko na naprawie

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);
    }
}

Zauważ, że po naprawie stan powraca do testing, zamiast przechodzić na completed. Zasada jest jednoznaczna: agent nie ma prawa deklarować ukończenia pracy tylko dlatego, że plik się zmienił. Jedynym ważnym dowodem poprawności jest zestaw testów, który rzeczywiście został ponownie uruchomiony, a nie samo twierdzenie agenta.

Orkiestrator jako kontroler ruchu

Początkowo łączenie zadań w linii prostej wydaje się kuszące:

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

Ale to jest tylko jedna linia. Gdy tylko pojawia się gałąź, na przykład powrót w celu naprawy po nieudanej próbie, liniowa łańcuchowa struktura okazuje się niewystarczająca. Potrzebny jest coś na kształt kontrolera ruchu, który za każdym razem, gdy jest wywoływany, sprawdza aktualny stan i wybiera dalszy krok:

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}"),
        };
    }
}

Zmiana sposobu myślenia jest znacząca. Orkiestrator nie pyta już, jaki jest następny zadań. Pyta, która transycja jest dopuszczalna biorąc pod uwagę obecną sytuację. To ułatwia debugowanie, a nowy etap, takie jak przegląd bezpieczeństwa, może zostać dodany bez zakłócania całego procesu.

Ograniczenie prób ponownych

Bez ograniczeń może rozwinąć się taki scenariusz:

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

To marnuje czas, a każde wezwanie do sztucznej inteligencji również wiąże się z kosztem. Rozwiązaniem jest ustalenie górnej granicy:

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
    }
}

Jeśli pięć prób naprawy nie wystarczy, system się zatrzymuje i oznacza zadanie do obsługi przez człowieka, zamiast próbować w nieskończoność. To niekoniecznie oznacza, że sztuczna inteligencja słabo radzi sobie z tym zadaniem. Czasami wymagania są niejednoznaczne lub decyzja rzeczywiście wymaga interwencji człowieka.

Testy z wynikiem „zielonym” nie oznaczają ukończonej funkcji

Latwo o zapomnienie o tym, gdy system działający samodzielnie wydaje się ekscytujący. Załóżmy, że agent napisał coś w stylu:

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

Wszystkie testy mogą przejść pomyślnie, ponieważ obejmują jedynie scenariusze wyobrażone w danym momencie. W rzeczywistych wymaganiach stwierdzono, że użytkownik musi być członkiem projektu, a nie koniecznie administratorem. Logika jest błędna, mimo że wszystkie testy wciąż pokazują wynik pozytywny.

Dlatego ten proces jest niebezpieczny:

Build → Tests pass → Deploy immediately

Ta bezpieczniejsza wygląda tak:

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

Etap przeglądu powinien nadal obejmować udział osoby, przynajmniej w przypadku wszystkiego, co dotyczy uprawnień dostępu. W przypadku zmian wrażliwych pod względem bezpieczeństwa, takich jak ta, wymaganie ludzkiego przeglądu przed połączeniem jest rozsądne, bez względu na to, jak sprawnie wygląda automatyczny proces.

Agenci równoległe i konflikty plików

Pomysł uruchamiania jednocześnie Agenta Bezpieczeństwa i Agenta Badawczego niesie ze sobą pułapkę. Jeśli dwa agenci mogą edytować ten sam plik mniej więcej w tym samym czasie, pojawia się sytuacja wyścigu, co oznacza, że dwa procesy nadpisują się nawzajem swoimi zmianami.

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

Zasada rządząca polega na podziale obowiązków między tymi, którzy mogą pisać, a tymi, którzy mogą tylko czytać:

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

To również tłumaczy linię tools.write: true w wcześniejszym pliku builder.md. Określa ona, które agenty mogą edytować pliki, a które mogą je jedynie przeglądać.

Opieraj się super-agentowi

Największą pokusą, gdy to zadziała, jest pojedynczy agent, który planuje, buduje, testuje, debuguje, naprawia błędy, przegląda wyniki i wdraża zmiany. Zazwyczaj przynosi to negatywne skutki. Im większą odpowiedzialność ponosi jeden agent, im więcej informacji musi przetwarzać, im więcej narzędzi posiada, tym większe jest ryzyko podjęcia błędnej decyzji. Lepiej jest dzielić zadania według odpowiedzialności:

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)

To ten sam zasada co unikanie jednej ogromnej klasy, która zajmuje się wszystkim w aplikacji. Nie twórz też jednego agenta, który robi wszystko.

Minimalna lista kontrolna przed faktycznym użyciem

Dla eksperymentów w rzeczywistym projekcie powinny one być obecne od pierwszego dnia, a nie dodawane później:

• ograniczenie liczby prób ponownych, aby pętla naprawcza nie mogła działać w nieskończoność
• limit czasu dla każdego polecenia wykonywanego przez agenta
• ograniczenia dostępu do plików dostosowane do roli agenta – tylko odczyt lub zapis
• testy, które muszą istnieć i przejść z powodzeniem, zanim status może przejść do etapu weryfikacji
• zatwierdzenie przez człowieka przed wdrożeniem czegokolwiek do produkcji
• rejestracja każdej decyzji podejmowanej przez agenta, a nie tylko ostatecznego wyniku
• Ochrona plików poufnych, takich jak .env, aby agent nigdy przypadkowo ich nie odczytał

Ostatni element jest często niedoceniany. Gdy agent może wykonywać polecenia w systemie za pomocą wcześniej opisanych wywołań Process::run(), może w praktyce uruchomić niemal wszystko na tym serwerze. Ograniczenia dostępu są wymogiem od samego początku, a nie opcją.

Rzeczywista rola Boost

Oto pełny obraz sytuacji:

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 nigdy nie decyduje się na uruchomienie testów ani na aktywację agenta naprawczego w przypadku błędu. Robi jedną rzecz, bardzo ważną: upewnia się, że każdy agent w projekcie rozumie rzeczywisty stan aplikacji i nie domyśla się na podstawie ogólnych wzorców. Kwestie tego, kto działa, w którym momencie i kiedy wszystko się zatrzymuje, pozostają w gestii orkiestratora zbudowanego na Laravel Queue.

Pytanie, które należy teraz zadać

Kilka lat temu istotnym pytaniem było to, czy sztuczna inteligencja może pisać poprawny kod w Laravel. Oczywiście potrafi to robić i stale się doskonali. Bardziej aktualne pytanie brzmi: czy sztuczna inteligencja może uruchamiać swój własny cykl sprzężenia zwrotnego – budowanie, testowanie, wystąpienie błędu, zrozumienie przyczyny, naprawa i ponowne testowanie – aż rzeczywiście wszystko zostanie załatwione, bez udziału człowieka pełniącego rolę ręcznego pośrednika na każdym kroku.

Scenariusz TaskFlow wskazuje, że odpowiedź brzmi „tak”, pod warunkiem, że nie zapomni się o trzech rzeczach. Postępy muszą być dokładnie rejestrowane, próby ponowne powinny mieć określony limit, a testy pozytywne należy traktować jako jeden sygnał, a nie jako oznakę zakończenia.

Boost pomaga agentom zrozumieć kontekst aplikacji. OpenCode dostarcza im miejsce do pracy. Laravel Queue stanowi filar, który uporządkowuje wszystko. A programiści mogą awansować na wyższy poziom – od ręcznego operatora na każdym kroku do osoby sprawdzającej ostateczny wynik.

Vibe przyspiesza proces pisania kodu. Taka orkiestracja pozwala procesowi programowania działać samodzielnie, i właśnie w tym miejscu eksperymenty z kodowaniem przy użyciu AI stają się interesujące.

Literatura pokrewna

• Mapowanie ekosystemu AI w Laravel: Prism, LarAgent, Neuron AI i Boost — Od zwykłych wezwań do LLM po pełne agenty w Laravel: co robią Prism, LarAgent, Neuron AI, SDK AI oraz Boost, wraz z przykładem RAG do pytań dotyczących polityki HR.
• Rozwój oparty na specyfikacjach z użyciem agentów kodujących AI: praktyczny przewodnik — Jak utrzymać agenty kodujące AI zgodne ze specyfikacjami: czterofazowy proces pracy, pliki AGENTS.md i SPEC.md, role różnych agentów, poziomy dojrzałości oraz odchylenia intencji.