Sublime Text, Open Code, Ghostty Terminal. That's the entire stack Taylor Otwell uses to build Laravel, Laravel Cloud, and everything in between. No elaborate IDE plugin chain, no custom tooling. The simplicity is deliberate — in an AI-assisted workflow, the editor mainly serves one purpose: reviewing what the model produced, fast.
The interview, recorded at a Laravel event in Japan, is one of the more candid looks at how a senior open-source maintainer has actually integrated AI into daily work. The picture that emerges isn't AI maximalism. It's something more measured.
Skipping plan mode more than you'd expect
When asked about his process for building a feature in Claude, Otwell's answer cuts against the "always plan first" conventional wisdom.
"I used to use plan mode all the time, but now more and more I'm skipping straight to build sometimes, especially for pretty straightforward features."
He still uses plan mode roughly half the time — for complicated work, he'll send a couple of planning messages and then cut the model loose. But the direction of travel is clear: the threshold for skipping straight to build keeps lowering as both the models and his own calibration improve.
For model selection, he keeps it simple. Kimi 2.6 for fast, low-stakes tasks. GPT-5.5 for anything with real complexity. The mental model is roughly: if the task is "rename these files," speed wins; if it involves architectural decisions or complicated logic, go with the stronger model.
GitHub Desktop as the most underrated diff tool
After generation, Otwell reviews output in Sublime Text for quick reads — but for actual diffs, he uses GitHub Desktop.
"It's so good. Such an underrated tool."
The host, Nuno Maduro, immediately agreed. It's one of those tools that the broader developer community tends to overlook because it wears the label of a "Git GUI," but for reviewing AI-generated changes before committing, its diff view is genuinely excellent. Otwell doesn't use it for branching workflows or anything elaborate. Just diffs.
This detail matters more than it might seem. One of the real risks in an AI-assisted workflow is committing generated code without a clean review pass. Having a dedicated, visually clear diff tool as a non-negotiable step in the process is a form of quality control infrastructure.
What he'd do differently building the AI SDK today
Otwell started work on the Laravel AI SDK in September 2025. By December, the agentic development wave had changed the landscape considerably — and most of the SDK's foundational code was already written. The question of what he'd do differently now produced one of the more precise answers in the interview.
He'd still plan the core API and interfaces himself, by hand.
The AI would write the implementation. He'd review that output, move methods around, adjust things — but the initial shape of the public API would remain his own work. His reasoning: the interfaces are where architectural judgment lives. The "boring code" that fills in those interfaces is where AI saves the most time without introducing meaningful risk.
"It just saves a lot of typing."
That framing is worth sitting with. Not "AI does the creative work" — rather, AI handles the low-judgment, high-volume work so that human attention concentrates where it actually matters.
Sub-agents: context management, not magic
Otwell gave a concrete example for when sub-agents earn their place. Say a main agent needs to verify whether a specific tweet was already published. To do that, it has to hit the internet, pull back raw HTML, and filter through it. Doing that inside the main agent's context pollutes the window with irrelevant data.
A sub-agent handles the lookup, returns just the answer, and the main context stays clean.
Sub-agents also help when an agent has a large tool registry — loading all those tool definitions into context on every turn is expensive. Segmenting tools across sub-agents reduces that bloat. As Otwell noted, sub-agents were a community contribution, merged a few weeks before the interview, with Pushpak leading day-to-day SDK development.
The principle generalizes: sub-agents are an architectural choice about context hygiene, not a power feature for its own sake.
Laravel best practices guides and how LLMs write "good" Laravel
The best practices guides shipped with Laravel Boost do something specific: they steer LLMs toward the idiomatic Laravel patterns that have evolved over time, rather than the generic PHP patterns the models default to.
Otwell's example: if a model sees a collection and needs to call a method on each item, without the best practices guide it might reach for a loop. With it, the model uses higher-order collection methods — $collection->each->someMethod() — the way a senior Laravel developer actually would.
This matters because "correct code" and "well-crafted Laravel code" aren't the same thing. Models trained on the broad PHP corpus will produce valid output that misses years of community convention. The best practices guides are essentially a steering mechanism for taste.
Pushpak led the initial development; Otwell reviewed and refined. He views it as a living document — Laravel conventions themselves evolve, and what looked like a best practice four years ago (before action classes became common) looks dated now.
On actions and form requests: pragmatism over dogma
Otwell's take on the actions pattern is worth noting for anyone who's heard it framed as a universal rule.
He uses actions when he needs to reuse logic across an API endpoint and a controller, or when the operation is genuinely complex. For a simple controller method that won't be called from anywhere else, he doesn't bother creating an action class.
Same logic applies to form requests. For simple validation, $request->validate() inline in the controller is fine. For complex validation — the kind where there's real pre-flight logic, like in a product such as Laravel Cloud — form requests earn their weight.
The pattern is consistent: add abstraction when it reduces real complexity or enables real reuse. Skip it when it's ceremony.
Laravel Cloud's incoming changes: $5 plans, spend caps, managed queues
Three concrete shipping announcements came up in the conversation.
Managed queues landed around the time of recording — an autoscaling queue system that scales to zero, with built-in graphs. Otwell described it as building the queue system he'd always wanted: something that could beat Horizon for teams running on Cloud.
New pricing brings a $5/month tier. Combined with the scale-to-zero infrastructure (which wakes in milliseconds), the intent is to make Cloud viable for side projects without a runway of idle costs.
Spend caps address what Otwell called the biggest piece of feedback from Cloud users: fear of an unexpectedly large bill. Users can set a hard cap, choose whether to shut everything down when it's hit or just receive notifications, and configure alerts at 50%, 80%, and 90% thresholds. For production workloads, the notification-only path makes sense; for a side project, shutting down at the cap is a reasonable default.
Agent sandboxes — isolated environments for running untrusted or agent-generated code — are on the roadmap but without a committed ship date. Otwell acknowledged the team has already experimented with it.
Maintaining open source when AI floods the PR queue
One friction point that came up: AI-generated spam pull requests. The pattern Otwell described is specific — someone creates an issue, and within a short window, an automated system watches that issue and fires off a PR. He closes the spam PR; another user opens essentially the same one. The volume has increased.
What he pushed back on, though, is the assumption that AI-origin PRs are automatically invalid.
"Sometimes they do get merged because they're correct — even though they came from AI."
The signal he cares about isn't how the code was written. It's whether the code is right. That's a sensible place to draw the line.
The broader picture from the conversation is someone who's integrated AI into daily work without handing over the parts that require judgment. Core API design stays handcrafted. Review stays human. The model writes the implementation, handles the fast simple tasks, and saves typing.
What changes at Laracon US in Boston — across Cloud, Forge, open source, and the already-confirmed Pest 5 — is a separate question. Otwell's standard formula: a mix of things people missed over the last few months, and things nobody has seen yet.
