The robots are replacing the packages
Installing a Laravel package takes thirty seconds. Writing a solid implementation takes time. But with AI-assisted development, time isn't as much of a factor because the writing happens in the background.
We ask the agent to build a file uploader. In the past, that request would have triggered a reflex: how am I going to build this? Browsing through Laravel packages, Spatie's media library package looks like a popular and safe choice. I'll install it, configure it, and get going with my day. Agents don't have that reflex. They just build.
Not every problem or package is equal. How do we make the decision between relying on an external library versus making the robots dance to build us exactly what we need?
Category 1: The shared problem
Many problems are common and have already been solved.
You want to define your site's menu structure to render it as a main menu, a footer menu, and generate breadcrumbs from it. It's a problem that exists in a lot of applications. We built spatie/laravel-navigation for that.
Site navigation is a self-contained and stable problem. Once your menu is built, it's built. While a package might have a nice API or solve some edge cases for you, none of these are hard problems. Let the robots build exactly what you need.
Category 2: The hard problem
Some problems look simple from the outside and reveal their true complexity once you're inside them.
You want to add business hours to a website. On the surface: Monday through Friday, nine to five, done. Then you need to add exceptions for holidays. Then you need to add exceptions for vacations and special closing days. Then you need to add exceptions for Sunday openings. You need a model that expresses "these recurring hours, except when they're not." Then Google needs to parse it so you need to serialize everything in JSON-LD. Then you realize people are viewing business hours from different time zones, which makes the whole thing significantly more complicated.
An agent is capable of working through this, but you need to describe the complexity you want solved ahead of time, or reactively as you’re working through it. It's not going to anticipate common problems for you. A well-curated package will. Our opening hours package encodes edge cases that took years of real-world usage to surface. You get all of that without having to think of it.
Reach for packages when dealing with hard problems you don’t want ownership over. Let the robots work on your core business instead.
Category 3: The external problem
Some problems are tied to something outside your control, like an API you're integrating against. Third party services and protocols evolve over time, and your code needs to keep up.
You want to add a Linear integration to your app. An agent can write you a client that works today, but when Linear updates their API, it's your responsibility to notice, investigate, and update your code. A well-maintained package absorbs that change for you. All you need to do is composer update.
The same is true for packages built around driver patterns. You could be using Pusher for real-time data today, but you might want to switch to Laravel Reverb in the future. A package with driver support reduces that refactor to a config change. If your agent built a Pusher integration, it might need to rebuild it as a Reverb integration later.
For external problems, the maintenance burden is ongoing. A package reduces the amount of code you need to update over time. The robots can spend their tokens elsewhere.
Category 4: The tasteful solution
Not every package decision is a technical one. Sometimes you want a package because it's opinionated.
Inertia nudges you and your agent towards a specific pattern. Even though you might be able to wire up a DIY version of Inertia with exactly what you need, you choose Inertia because you believe in the direction of the framework.
Similarly, we're not just using Livewire for its technical benefits. We're using it because Caleb Porzio has excellent taste in API design. Major library updates often include new affordances and primitives. These are distilled from patterns and limitations the author & package users have used or reached.
For code at the center of your architecture that affects how you're building apps, reach for an author you trust. Robots don't have taste yet.
Where this leaves packages
As serial package builders, we have a stake in this. But the reason we build packages is to fill gaps that need filling. If agents step in to fill the shared problem gap, we'll happily sunset those packages and aim our sights at more interesting problems.
The question before every composer require is no longer "is there a package for this?" Almost certainly there is. The new question is: "do I want to own this problem?"
