How I Use Laravel and AI

At Laravel Serbia Meetup #8 in Novi Sad, I spoke about how I use Laravel and AI in my everyday work, and why I ended up building my own system for coordinating AI agents.

I did not build that system because I wanted more agents on the screen. I built it because using AI without structure quickly becomes chaos. An agent can produce code, but a finished response is not the same as finished software. Someone still has to decide what should happen, what must not change, and what evidence would prove that the result works.

What is development today?

Development is the art of turning intent into verified behavior.

AI can generate an implementation. I still own the intent, the boundaries, and the decision to accept the result.

Take the small feature from my meetup demo: add a Most voted badge to the leading proposal. The intent is the useful outcome for the user: make the leading proposal easy to recognize. The boundaries say what must remain true: show no badge when every proposal has zero votes, show it on every tied positive leader, preserve the existing ranking and design, and introduce no migrations or new dependencies. The decision to accept the result comes only after tests, browser evidence, independent review, and an audit prove those conditions. “The agent finished” is not acceptance.

What orchestration means

In AI development, orchestration means turning one goal into a controlled sequence of work. A task is divided into clear responsibilities. Each specialist receives a bounded assignment, the access required for that assignment, and a definition of what counts as done. Independent work can happen in parallel, while dependent work waits for its prerequisites.

I call my system Orkestar (“orchestra” in Serbian), and Lenka (the name I gave my AI assistant) is its conductor.

The orchestra metaphor is useful. The agents are the musicians. The task contract is the score. Lenka does not play every instrument; she decides which specialists are needed, when they should enter, what they are allowed to do, and which evidence they must bring back. I remain responsible for choosing the piece and deciding whether the performance is good enough.

Solo is one concert hall: a visual workspace where I can see the conductor, workers, tasks, and progress. But the hall is separate from the orchestra. Orkestar can run in any terminal. I often use Herdr, and I can also work directly in a regular terminal or through another supported AI client. The model and subscription are separate choices too. Orkestar is the workflow around the tools I already use.

From a spoken idea to the orchestra

I often begin with Voiceavel rather than a keyboard. I dictate an idea to ChatGPT in my natural words. ChatGPT then turns that raw idea into a clear assignment in my tone, with the outcome, boundaries, and acceptance criteria made explicit.

I review that assignment before it enters the workflow. Once I approve it, ChatGPT can send it to Orkestar, or I can copy and paste it into Orkestar myself. Voice makes the first step faster; the approval step keeps the intent mine.

The rules my agents must follow

The rules matter more to me than the number of agents.

Every task starts with an explicit outcome and acceptance criteria. The contract says what the feature must do, what it must preserve, and what is outside scope. If an agent discovers an unrelated problem, it reports it instead of quietly expanding the task.

Before Lenka creates an agent, she must decide five things:

Responsibility: What exact outcome does this agent own?
Scope: Which files or part of the system may it work on?
Permissions: What does it need to read, change, or run?
Model: What is the least expensive model that is capable, available, and authenticated for this job?
Proof: What must the agent return so another agent can verify the work?

Permissions come before model choice. A reviewer does not need permission to edit production code. An orchestrator may need project context and run records, but it does not need to make the implementation itself. A builder can change its assigned files, but it cannot approve its own work.

Cost also belongs in the design. I do not use the strongest and most expensive model for every step. Ordinary coordination, implementation, and testing can use capable lower-cost models with medium reasoning. I reserve higher reasoning for difficult judgment and the final audit. A powerful model still needs a bounded task.

Proof is part of delivery

My preferred flow for a small change is deliberately simple: one builder implements it. Focused testing and an independent security and performance review then inspect the same revision. Finally, an auditor compares the evidence with the original acceptance criteria.

If a repair changes the code, the affected checks run again. If a required check is blocked or missing, the result remains partial. A green command helps, but it does not prove the real user journey. For a visible feature, I also want browser evidence on the relevant screen sizes, with console and network problems checked where they matter.

This is one of the biggest changes AI has made to my work. I spend less attention on typing every line and more on judgment: defining behavior, identifying boundaries, designing control, and deciding what evidence I will trust.

Why Laravel fits this approach

Laravel gives this workflow a strong foundation because its conventions and application context can be made explicit. Laravel Boost helps an agent inspect the actual application and search documentation that matches the installed packages. Laravel MCP lets a Laravel application expose controlled tools and resources to AI clients while its authorization and business rules remain part of the application.

That matters because I do not want an agent guessing how the project works. I want it reading the current project rules, inspecting the real application, and using the right documentation before it changes anything.

What the meetup taught me

The live demonstration at the meetup did not finish successfully. It ran for around half an hour, and too much raw tool traffic made the work difficult to follow. That was useful evidence too.

It showed me that orchestration must be proportional to the problem. A small feature should not require an hour of ceremony. Progress must be understandable to the person supervising it, and a workflow should never hide an unfinished result behind a confident final message.

After the meetup, I shared the whole Orkestar repository on GitHub as open source. Anyone can use it, read the role and permission definitions, fork it, and adapt the workflow to their own tools. It is a skeleton to build on, not a promise of hands-off software delivery.

For me, AI development today means I can delegate more implementation while remaining responsible for what we build and what we accept. The human role does not disappear. It moves closer to intent, boundaries, and proof.

Control is designed, not bought. And the goal remains the same: turn intent into verified behavior.