Taylor Otwell's AI workflow: own the architecture, delegate the typing

Taylor Otwell's AI workflow: own the architecture, delegate the typing

Taylor Otwell skips plan mode half the time, uses GitHub Desktop purely for diffs, and still hand-writes every core API interface himself. Here's exactly where he draws the line between AI work and human judgment.
nunomaduro
28.5K Subscribers
7 min read

Key Findings

  • Own the API design, let AI write the implementation. That's where architectural judgment lives, and it's where bugs actually matter — keep that part human.
  • A dedicated diff review step isn't optional hygiene. It's the quality control layer that stops AI-generated code from quietly breaking things.
  • Sub-agents are a context management tool, not a power move. Use them to keep your main context clean — not because they sound impressive.
  • Skip the abstraction pattern when there's no real reuse or complexity to justify it. Ceremony dressed up as best practice just slows you down.
  • Your AI outputs generic code by default. Steering it toward your stack's idioms with a best practices guide is the difference between correct code and well-crafted code.

Sublime Text, Open Code, Ghostty Terminal. That's the full stack Taylor Otwell uses to build Laravel, Laravel Cloud, and everything in between. No elaborate IDE plugin chain. The simplicity is deliberate: in an AI-assisted workflow, the editor serves one primary function — reviewing what the model produced, fast.

The interview, recorded at a Laravel event in Japan, is one of the more candid accounts of how a senior open-source maintainer has actually wired AI into daily work. The picture isn't AI maximalism. It's something sharper and 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 is clear: the threshold for skipping straight to build keeps dropping as the models improve and his own calibration sharpens.

For model selection, his approach is deliberately simple. Kimi 2.6 handles fast, low-stakes tasks. GPT-5.5 handles anything with real complexity. The mental model: if the task is "rename these files," speed wins; if it touches architectural decisions or complicated logic, reach for the stronger model.

GitHub Desktop as the most underrated diff tool

After generation, Otwell reads quick output in Sublime Text — but for actual diffs, he uses GitHub Desktop.

"It's so good. Such an underrated tool."

The host, Nuno Maduro, agreed immediately. GitHub Desktop wears the "Git GUI" label, which causes most developers to overlook it. For reviewing AI-generated changes before committing, though, 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 sounds. One of the real risks in an AI-assisted workflow is committing generated code without a clean review pass. A dedicated, visually clear diff tool as a non-negotiable step in the process is quality control infrastructure, and treating it as optional is where things quietly break.

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 shifted things considerably, and most of the SDK's foundational code was already written. When asked what he'd do differently now, he gave 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. 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. AI doesn't do the creative work here — it handles the low-judgment, high-volume work so that human attention concentrates where it actually counts.

Sub-agents: context management, not a power move

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 all 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 carries a large tool registry. Loading all those tool definitions into context on every turn is expensive. Segmenting tools across sub-agents reduces that bloat. Otwell noted that 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 worth reaching for just because it sounds impressive.

How the best practices guides steer LLMs toward real Laravel

The best practices guides shipped with Laravel Boost do something specific: they steer LLMs toward idiomatic Laravel patterns rather than the generic PHP patterns the models default to.

Otwell's example is concrete. 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.

"Correct code" and "well-crafted Laravel code" aren't the same thing. Models trained on the broad PHP corpus produce valid output that misses years of community convention. The best practices guides are a steering mechanism for taste.

Pushpak led the initial development; Otwell reviewed and refined. He treats it as a living document, because Laravel conventions themselves evolve. What looked like a best practice four years ago — before action classes became common — looks dated now.

On actions and form requests: pragmatism over ceremony

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 with real pre-flight logic — the kind you'd find in a product like Laravel Cloud — form requests earn their weight.

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 announcements came out of the conversation.

Managed queues had landed around the time of recording — an autoscaling queue system that scales to zero, with built-in graphs. Otwell described it as 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 scale-to-zero infrastructure that 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 without a committed ship date. Otwell acknowledged the team has already experimented with the idea.

Maintaining open source when AI floods the PR queue

One friction point came up: AI-generated spam pull requests. The pattern Otwell described is specific — someone creates an issue, an automated system watches that issue, and within a short window 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 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 — and it's consistent with everything else in his workflow. 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.

Create articles like this

Start Free →
Mr. Article

Share Article

Share this article with anyone. No login required to view.

Share via
or copy link directly
https://mrarticle.blog/shared/vidBeQxpQs2xdwf0dnctOT72BFOQnxYI

Anyone with this link can view a read-only version of this article.

Link copied to clipboard!