DEV Community: david duymelinck

https://a4al6a.substack.com/p/stop-using-pull-requests thought provoking

david duymelinck — Fri, 22 May 2026 08:02:53 +0000

Stop Using Pull Requests - by Andrea Laforgia

Your team’s code review process is probably an expensive illusion of quality. Here’s what the evidence says, and what to do instead.

a4al6a.substack.com

My thoughts on Spatie/Piper

david duymelinck — Fri, 22 May 2026 07:28:06 +0000

When I saw a library for the pipe operator I needed to check it out.

People that read my posts before know I'm a big fan of the pipe operator feature. The main benefit is that it is less likely that the functions have side effects, because they don't depend on a master object that comes with a builder pattern.

The good

I like that they moved the collecting function inside the functions.

function map(callable $callback): Closure
{
    return function (array $items) use ($callback): array {
        $result = [];

        foreach ($items as $key => $value) {
            $result[$key] = $callback($value, $key);
        }

        return $result;
    };
}

For people that are less aware how the pipe operator works in PHP 8.5 a short introduction.
The pipe operator passes a single variable on to whatever function is called next in the chain, [1, 2] |> array_sum(...). From the moment you want to use predefined arguments for a function, you need to wrap it in a function that collects that single variable, [1, 2] |> (fn($arr) => array_map(fn (int $i) => pow($i, 2), $arr)).
By moving the collecting function into the actual function they reduced the amount of code you need to write to [1, 2] |> map(fn (int $i) => pow($i, 2)).
In PHP 8.6 this verbosity problem will be solved, and then you can write [1, 2] |> array_map(fn (int $i) => pow($i, 2), ?).
But because the goal of the library is to mimic the Laravel builder pattern methods, I think it is a great choice.

I like that all the functions are in separate files. The functions.php file is there just to collect them all.

The misses

It is not to hard to see where the name comes from. The problem I have with it is that is too generic. Is it possible they are going to add other pipe operator categories?

That brings me to the following missed opportunity, why not split the library. There could be a collection-piper and string-piper library. This way the support functions and exceptions context will be clearer.
And you can choose which Laravel builder pattern you want replace, instead of adding functions you are never going to use.

Because functions are loaded upfront it might be a good idea to have a way to choose the ones the project is really going to use.
It is a problem that has not been addressed by PHP libraries and frameworks, including my own.
By having the functions in separate files this could be more easily achieved than having all the functions in a single file.

The negative consequence of having the collecting function in the functions, they can't be used for non pipe operator situations.

// plain use, pipe operator php 8.6 use
function map(array $items, callable $callback): array
{
    $result = [];

    foreach ($items as $key => $value) {
       $result[$key] = $callback($value, $key);
    }

    return $result;
}
// pipe operator PHP 8.5/8.6 use
function pMap(callable $callback): Closure
{
   return function(array $items) use ($callback) {
       return map($items, $callback);
   }
}

Conclusion

I am a bit of an anti-abstractionist. If you can achieve something with no abstraction, array_map(fn (int $i) => pow($i, 2), [1, 2]), do that. As you can see from the example even the pipe operator can be an abstraction.
And that is why Laravel collections and string builders were never my favourite additions to the framework. Even while they have functions that are genuinely helpful. I used map in the examples, but for me that is not one of the helpful functions.

By having more pipe operator libraries the use of the functions will be more versatile than with builder pattern methods. But we need to be aware of the limitations if they only target the pipe operator.

This is quite a short post but I had to get those thoughts out of my head.

PHP fun: Lean theorem in PHP

david duymelinck — Wed, 20 May 2026 16:40:47 +0000

In following post I saw

Shrijith Venkatramana

May 17

Designing Reliable Permission Models with Lean 4

#ai #webdev #productivity #programming

Comments

5 min read

def increment (x : Nat) : Nat :=
  x + 1

theorem increment_is_larger (x : Nat) :
  increment x > x := by
  exact Nat.lt_succ_self x

And I was wondering how close could I get in PHP.

Explain Lean like I'm an eighteen year old

Lean is a language that is a language where tests are a part of the code that gets compiled as you can see in the example.

With the usual programming languages there is the code, and separate from it there is the mental model that is part in the tests and part in the documentation.
One of the biggest reasons for bugs is that the tests didn't check all options of the mental model, or that the documentation has diverged from the code.

This has become a bigger problem with the use of AI because of the mountain of code, tests and documentation it can generate.

This is were Lean tries to bundle the code and the mental model together, which makes it easier for humans and AI to spot errors.

Building a similar concept in PHP

Compiling ahead of time is not going to happen in PHP. The closest that it can get is describing the theorem close to the function or method.
This is a job for an attribute.
In Lean all argument values and outputs will be checked at runtime. But in PHP the attribute will be used by a runner.

#[Attribute(Attribute::TARGET_FUNCTION | Attribute::TARGET_METHOD | Attribute::IS_REPEATABLE)]
class Theorem
{}

#[Theorem]
function increment(int $int) : int
{
   return $i + 1;
}

The Theorem attribute without arguments could be used to run a randomised argument type and/or output type test.

Nat in Lean is a natural or positive integer. In PHP I'm going to create an Input interface with a value method. The Theorem attribute is going to have an $inputs argument which uses the interface.

For the proof check the PHP 8.5 feature Closures and First-Class Callables in Constant Expressions comes in handy.

Every proof needs a description to distinguish the theorems.

#[Attribute(Attribute::TARGET_FUNCTION | Attribute::TARGET_METHOD | Attribute::IS_REPEATABLE)]
class Theorem
{
    private $inputs = [];

    public function __construct(
        public string $description,
        public Closure $proof,
        Input ...$inputs,
    )
    {
        $this->inputs = $inputs;
    }

    /**
     * @return Input[]
     */
    public function getInputs(): array
    {
        return $this->inputs;
    }
}

interface Input
{
    public function value();
}

class NaturalNumber implements Input
{

    public function value(): int
    {
        return rand();
    }
}

#[Theorem(
    'is higher',
    static function(Input $input, mixed $output) : bool { return true; },
    new NaturalNumber(),
)]
function increment(int $int) : int
{
   return $i + 1;
}

I decided for the NaturalNumber to use a random number. The benefit is that the input mutates, which could surface bugs that where not in frame when adding the theorem. The consequence is that the input needs to be shown to create a repeatable theorem.

Now for the runner. Because it is a POC I'm going to create a runFunctionTheorems function that accepts a function as a string.
And it is going to return the function and theorem description as the key and the theorem proof as the value of an array.

function runFunctionTheorems(string $function)
{
    if(!is_callable($function)) {
        throw new InvalidArgumentException("$function is not a function");
    }

    $functionReflection = new ReflectionFunction($function);
    $theoremReflections = $functionReflection->getAttributes(Theorem::class);

    if(count($theoremReflections) ==  0) {
        throw new InvalidArgumentException("$function has no Theorem attributes");
    }

    $results = [];

    foreach($theoremReflections as $theoremReflection) {
        $theorem = $theoremReflection->newInstance();
        $inputs = array_map(fn($i) => $i->value(), $test->getInputs());
        $actual = $functionReflection->invoke(...$inputs);

        $results["$functionReflection->name $test->description"] = ($test->proof)(count($inputs) == 1 ? $inputs[0] : $inputs, $actual);
    }

    return $results;
}

$result = runFunctionTheorems('increment');
var_export($result);

// result
array (
  'increment is higher' => true,
)

The next iteration will probably be a DTO that changes the runner function output into an array with that type of DTO's. This makes it possible to add the inputs and show the values when the proof has failed.

Conclusion

I have written big test suites and I'm wondering if is going to be feasible to add every possible type of test to the code.

Having the tests in the code makes it harder to overlook them. My usual workflow is to open the test file and have the code file in a split-screen.
I think having them in one file is a focus improvement.

The consequence of having the tests in the code is that the runners should not be active in production. And that also means there are attributes that are going to be compiled without any benefit.
There could be a build step that removes the attributes, but then the line numbers don't match with the development code. A solution for that problem is a sourceMap file.
So having the tests separate from the code gives the best cross environment debugging experience.

Even this simple function test runner has shown me how much work it is to create a test library. And we should thank the people who took that job upon their shoulders every day.

https://en.liujiacai.net/2026/05/16/bun-rust-port/ great read

david duymelinck — Sat, 16 May 2026 10:50:27 +0000

My Thoughts on Bun's Rust Rewrite | Jiacai Liu's personal website

Before we discuss Rewrite Bun in Rust, there's something that needs to be said, because no one is saying it. Bun stands where it does today because of Zig. Jarred chose Zig back then not because it was "cool," but because Zig enabled a small team to rapidly prototype a high-performance JS runtime without a GC, without a heavy runtime. Zig's low friction, direct memory manipulation, and straightforward C interop were the core reasons Bun could punch above its weight on performance with an extremely small team in its early days. The architecture, data structures, and low-level design of Bun that you see today – that was shaped by Zig.

en.liujiacai.net

Composer is just a console application

david duymelinck — Sat, 16 May 2026 10:04:45 +0000

I want to preface the post with two remarks.

Yes adding just to the title is clickbait. It is like saying Symfony's bin/console and Laravel's artisan are just console applications.

I'm embarrassed I never took the time to understand Composer until now. I have been preaching for a long time to start each PHP project with Composer, even when the project is not going end up on Packagist.

How did I get here

I recently did an exploration of Yii3. And in the configuration file I saw something that caught my eye.

// NOTE: After making changes in this file, run `composer yii-config-rebuild` to update the merge plan.

So I dug deeper and found out the command is part of the Yii3 config component. I will explain later how they did it, but if you are curious try to find out for yourself. This post will still be here when you get back.

The second trigger were @suckup_de itp-context library's cli commands.
Having to use vendor/bin/itp-context-summarize and vendor/bin/itp-context-validate triggered my developer laziness. At first my thoughts went to creating a console application like console/bin. But then you still need it to put it in the vendor bin and the command would be vendor/bin/itp-context summarize. This only helps with the discoverability of the commands not with typing less.

The Composer plugin way

Composer allows you to add commands using plugins.

I'm going to show how it is done using the vendor/bin/itp-context-summarize command.

The first step might be a hurdle for some people but the commands should be a project on their own. The main reason is that for a composer plugin to work the type in composer.json has to be composer-plugin.

{
    "name": "voku/itp-context-commands",
    "type": "composer-plugin",
    "require": {
        "composer-plugin-api": "^2.0"
    },
    "require-dev": {
        "composer/composer": "^2.0"
    },
    "autoload": {
       "psr-4": {
         "ItpContextCommands\\": "src/"
       }
    },
    "extra": {
        "class": "ItpContextCommands\\Plugin"
    }
}

The plugin code is very simple.

class Plugin implements PluginInterface, Capable
{
    public function activate(Composer $composer, IOInterface $io)
    {
        // void
    }
    public function getCapabilities(): array
    {
        return [CommandProvider::class => ItpContextCommandProvider::class];
    }

    /**
     * @inheritDoc
     */
    public function deactivate(Composer $composer, IOInterface $io)
    {
        // void
    }

    /**
     * @inheritDoc
     */
    public function uninstall(Composer $composer, IOInterface $io)
    {
        // void
    }
}

The ItpContextCommandProvider is even more simple.

class ItpContextCommandProvider implements CommandProvider
{

    /**
     * @inheritDoc
     */
    public function getCommands()
    {
        return [
            new SummarizeCommand(),
        ];
    }
}

Now that the bootstrapping is done, the work on the actual commands can begin.

use Composer\Command\BaseCommand;

#[AsCommand('itp-context:summarize')]
class SummarizeCommand extends BaseCommand
{
    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        // the real code
        return Command::SUCCESS;
    }
}

You might have noticed the BaseCommand as parent instead of Command or no parent at all. This is a Composer restriction.

Now the library can add voku/itp-context-commands to the composer require section. And when the library is installed Composer will ask the question that the plugin may be used. When you allowed it, you can use composer itp-context:summarize or composer itp:summarize. And that makes my developer lazy part happy.

Thinking bigger

Most PHP solutions have a console application, bin/console and artisan are the most known. Yii has yii. Statamic has please next to artisan.
And that got me thinking, what if you could merge those applications with composer to have a single point of entry for all commands.

For this to work the Composer plugin API could extend the CommandProvider interface with a getApplication method.

For Symfony the CommandProvider child could be something like.

use App\Kernel;
use Symfony\Bundle\FrameworkBundle\Console\Application as SymfonyApplication;
use Symfony\Component\Console\Application;

class SymfonyCommandProvider implements CommandProvider
{

    public function getCommands(): array
    {
        return [];
    }

    public function getApplication(): Application|null
    {
       $kernel = new Kernel(getenv('APP_ENV'), (bool) getenv('APP_DEBUG'));

       return new SymfonyApplication($kernel);
    }
}

The Composer Application could then have a getPluginApplicationCommands method. A naive implementation could be.

public function getPluginApplicationCommands(): array
{
   $commands = [];

   $composer = $this->getComposer(false, false);
     if (null === $composer) {
        $composer = Factory::createGlobal($this->io, $this->disablePluginsByDefault, $this->disableScriptsByDefault);
     }

     if (null !== $composer) {
        $pm = $composer->getPluginManager();
        foreach ($pm->getPluginCapabilities('Composer\Plugin\Capability\CommandProvider', ['composer' => $composer, 'io' => $this->io]) as $capability) {
           $application = $capability->getApplication();
           // ConsoleApplication is alias of Symfony\Component\Console\Application
           if($application instanceof ConsoleApplication) {
              $commands = $application->all();
           }
        }
    }

    return $commands;          
}

And that method can then be used to add the commands.

The biggest problem with the change at this moment is that the commands from other applications can overwrite the Composer commands.
To prevent this the CommandProvider interface could be extended with the getApplicationNamespace method.
This requires the following changes.

use App\Kernel;
use Symfony\Bundle\FrameworkBundle\Console\Application as SymfonyApplication;
use Symfony\Component\Console\Application;

class SymfonyCommandProvider implements CommandProvider
{

    public function getCommands(): array
    {
        return [];
    }

    public function getApplication(): Application|null
    {
       $kernel = new Kernel(getenv('APP_ENV'), (bool) getenv('APP_DEBUG'));

       return new SymfonyApplication($kernel);
    }

    public function getApplicationNamespace(): string
    {
       return 'symfony';
    }
}

public function getPluginApplicationCommands(): array
{
   $commands = [];

   $composer = $this->getComposer(false, false);
     if (null === $composer) {
        $composer = Factory::createGlobal($this->io, $this->disablePluginsByDefault, $this->disableScriptsByDefault);
     }

     if (null !== $composer) {
        $pm = $composer->getPluginManager();
        foreach ($pm->getPluginCapabilities('Composer\Plugin\Capability\CommandProvider', ['composer' => $composer, 'io' => $this->io]) as $capability) {
           $application = $capability->getApplication();
           // ConsoleApplication is alias of Symfony\Component\Console\Application
           if($application instanceof ConsoleApplication) {
              $commands = $application->all();
           }

           $namespace = $capability->getApplicationNamespace();

           if( '' != $namespace) {
              foreach($commands as &$command) {
                 $command->setName($namespace . ':' . $command->getName());
              }
           }
        }
    }

    return $commands;          
}

Conclusion

I'm wondering if there is consequence that stops us from using Composer as a centralised command entry point?
Did Symfony set the example by using a separate file for the application, and did the rest follow the example?
Why did Symfony choose to add the bin directory to the root directory of the project instead of using the bin key in composer.json?

I got a lot more questions than answers after this Composer plugin deep dive.
The good thing is that I discovered more options with a solution I use daily.

My 2 cents on Yii3

david duymelinck — Thu, 14 May 2026 09:49:25 +0000

I got to exploring Yii3 via Craft CMS. Craft is moving to Laravel with their sixth version. When I saw the announcement I was thinking Yii was having problems because Yii3 was stuck for a long time on 80 precent, if I can remember that right.
But now I have seen Yii3 I think the decision is more because they needed change their guts anyway when they update to Yii3.

Major changes

Yii2 is, like most other frameworks, one pre-configured bundle. With Yii3 all components are separate and the glue that binds them together are the templates; web, api, console. The workhorse of the templates is the configuration.

This loose structure allows the framework to use different setups depending on the need of the application.
There are multiple runners to pick your flavour of PHP runtime.
You can use the database package you prefer.

The use of Yii::$app-> is discouraged.

Routes can now be any callable you want, which brings Yii3 to the same level as the other frameworks.

No frontend related packages as Composer dependencies. This was the biggest problem for me to use the previous version. A backend framework should be frontend agnostic.

Where they can improve

The configuration is very confusing at first sight.
The main configuration file has variables in it as strings.
The dependency injection configuration looks more like a Wordpress configuration than a modern framework configuration.
While I get it that using arrays is the most versatile way to allow all the configuration options, most frameworks have started to use attributes for a better developer experience.

It is still using nikic/FastRoute. While it was a good router library, others implemented the same technique and got faster after further development.

Conclusion

I do think with Yii3 they moved the framework in the right direction. The closest framework in spirit to Yii3 that comes to mind is Laminas.

The question is will it be enough to survive when the most known solution build on it is moving away?
The numbers on their website are mainly from the use of the previous versions of the framework. A big change will always scare people away.

Symfony 8.1, the big CLI update

david duymelinck — Fri, 08 May 2026 16:08:29 +0000

When I saw the change list in the Symfony 8.1 beta 1 announcement The first thing that I noticed is that there are a lot of Console and CLI related changes.
The first few "New in Symfony 8.1" posts confirm this.

Added the TUI component

I have written about the TUI component but now it is a part of the framework.

The quick explanation for the people who are unaware of the component.
Think Claude code/OpenCode, Midnight commander/Yazi, basically everything in Awesome TUI's you can now make in PHP.

HTTP-less application

While this change goes further than only Console, it streamlines creating commands with multiple dependencies or config values.

Up till now when you didn't want the HTTP functionality of the Kernel, you needed to inject the services explicitly or create your own container.
While they are still options, adding a HTTP-less Kernel causes less friction because of the familiarity with the web kernel.

Input improvements

Argument resolvers in Console is a big one.
This brings command arguments on the same level as the Controller arguments.
Method based commands makes it possible to group commands like you would with a Controller. While it gives you more options the argument resolvers addition allows to inject services as an method argument so there is less need to use constructor dependency injection.

I'm sure a future article in the new series will be the image support for QuestionHelper and #Ask.
This will only work on terminals that support image rendering. But having the distinction between images and other files gives you more options.

It will be possible to add validation constraints to QuestionHelper and #Ask and #MapInput.
It is already possible to add a Validator, but the using the constraints makes the argument a lot cleaner.

Adding any type as a default for an argument is going bring more type safety to command arguments. The current restriction felt arbitrary.

Exposing the raw input values is great when the command exposes another command you want to limit.

Preventing incompatible mode flags might be a less important change after this list, but I think it is an important one.

Miscellaneous

Added OSC progress state. You probably seen the progressbar on top of the page when you are reading an article on a website. This is also possible in the terminal. I didn't know that, but it is nice when you scrolled up in the terminal.

The partial command name list is now alphabetical. Having order is always better than chaos.

Conclusion

Of course the release contains other features, like DeepCloner, but the main focus seems to be on CLI features.

And with the HTTP-less application the framework is moving from a web focused framework to a general use framework. Where the TUI component showed PHP CLI code isn't only for basic commands, Symfony 8.1 shows it can do more than only websites. It was already possible when you brought your own tools, but now you can do it using Symfony conventions.

This is going to be a great release!

Where to store slugs

david duymelinck — Thu, 30 Apr 2026 18:38:14 +0000

A few days ago I saw a post about a slug library. And they used specific ORM models, post and author, to store the slugs.
A slug is a part of the routing. And while they can be stored in a database, the best location is not as a field of a content table.

The basics

As I mentioned a slug is a part of the routing. In the case of a post that can be where-to-store-slugs. This can be the full path, /where-to-store-slugs, but it also can be a part of the path, /posts/where-to-store-slugs.
When your website is multilingual there can be aliases for the slug.
For the people that go old school it can a part of the query string, ?title=where-to-store-slugs.

On a mostly static website you can get away with putting the slugs in the routing configuration.
When the urls are more dynamic, I'm thinking about user created pages, the routing configuration can still be an option when you include an environment specific configuration. The problem there is that the routing configuration is cached most of the time to make the routing as fast as possible. So every slug change could create a refresh cache event.

The second fastest thing of your website is the database. So that is why the library, and others like it, use that as the storage solution.

What is wrong with storing slugs as a part of an ORM model?

Because a slug can be the full path, most libraries have an option to check the uniqueness of slug. You don't want duplicate urls.
The problem is that most libraries only check the uniqueness for the specific model, not for every model that has slugs.
For example an author can have the slug mike and a post can have a slug mike, because the post title is an acronym. Most libraries lower case the slugs they generate.

Having the slug as a part of the path is a fix, so now you have post/mike and author/mike. Now they are unique in their respective path, but you needed to change the routing to fix a uniqueness problem in the database. This is too tight of a coupling to not cause problems in the future.

A more extreme example is /mike/mike. It could be the authors page as the parent to give context to the post. But it could also be the post that is the parent to give context to the author.
I have seen editors have all sorts of weird rules to make urls unique, but there were always occasions where they managed to create duplicate urls.

What is the better solution?

As I mentioned before an environment specific configuration for dynamic urls is an option.

When you want to store the slugs in the database use a separate table. That table contains the urls with the slugs, their matching controllers and extra metadata if needed.
Another solution is to create an url tree, this is a good solution when you expect many urls with multiple levels.

The first two solutions make it easier to check the uniqueness because they centralise the slugs.
The url tree is like the prefix example, it only needs to check the uniqueness in a specific branch.

Conclusion

While a library that adds a slug to an ORM model might seem like a quick solution. I think most of the times they are a solution with a short lifespan.

The best way of thinking about slugs is to see where they fit in the website routing strategy.
When slugs are always a part of paths with prefixes or suffixes, the library could be the solution the website needs.

To be clear this is not a rant against one library in particular, I seen multiple libraries in different languages that have the same pattern.
My message for the library builders is to move the storage to the edge of the library, don't make it the main feature.

Using a slug might seems an insignificant detail, but there is always more than meets the eye.

Fixing the array functions for the pipe operator

david duymelinck — Tue, 28 Apr 2026 21:57:34 +0000

Update: I released it as a package. When you try it give some feedback.

I had a good conversation with @delacry over the library that was introduced .

And what struck me the most was the last example.

$topAdmins = $users
    |> array_filter(?, fn(User $u) => $u->isActive())
    |> array_map(fn(User $u) => $u->refresh(), ?)
    |> array_filter(?, fn(User $u) => $u->isAdmin())
    |> (fn($us) => (usort($us, fn(User $a, User $b) => $a->name <=> $b->name) ? $us : $us))
    |> array_slice(?, 0, 10);

It is an example with the upcoming partial function application change (PHP 8.6).
I do agree, while it looks miles better than it is in PHP 8.5, it still is not that straight forward as the solutions with the builder pattern.

So I took a bit of time off from my dates project to come up with PAF. POAF looked weird to me, and PAF reminded me of a thing we said in Dutch when I was young, pief poef paf. So that is the whole story behind the name.

The example with the library looks like this.

$topadmins = $users
  |> filterValues(?, fn(User $u) => $u->isActive())
  |> mapSingle(?, fn(User $u) => $u->refresh())
  |> filterValues(?, fn(User $u) => $u->isAdmin(), true)
  |> sortValuesCustom(?, fn(User $a, User $b) => $a->name <=> $b->name)
  |> array_slice(?, 0, 10);

Of course I'm biased, but I don't think anyone is going to say it looks worse.
Functions where the array is the first argument and return an array, like array_slice, don't need to be wrapped.

It is a bit more than a dumb wrapper for the array functions.
Another good point from the conversation was that array_filter leaves gaps in the keys. You could use array_values, but that only solves the problem for the integer keys. For string keys the solution is more complicated.

So I created a reIndex function that takes care of three cases:

integers
strings
custom logic.

In the example you see that is triggered by adding true to the second use of the filterValues function in the chain.
I know using a boolean is controversial, but with named arguments you can do reIndex: true. I'm using them more and more, because they are code as documentation.

I went a bit overboard and I added the function to the map functions. The only use case I can think of at the moment, is using the custom logic to manipulate the keys before going to the next function in the chain.

It is still early days, and I already have a few other directions I want to take for the library. For example the sortValues and sortValuesCustom functions could be one.

It is a small library but I think it has enough value to make it a package. But it has a few more iterations to go before it is ready to be released.

AI agent attention shattering

david duymelinck — Sun, 26 Apr 2026 05:44:39 +0000

For the library I'm working on I finally getting the power of running multiple agents in parallel. The problem I discovered is that the ping that the agent sends when the job is done is affecting my attention span, like chat app or email pings.

A while ago Boris Cherny, who created Claude Code, mentioned on X that he had 8 tabs with agents open.
The question I have is how many of those tabs are forgotten for days or even longer?
I found out 4 agents running in parallel is my maximum, while maintaining a workflow that is not doing work between job-done-pings.
More than 4 agents gave me more pressure to check when they are done. Maybe over time I will develop a higher tolerance, but for now that is my tipping point.

I can understand that people that are more into AI will start longer running tasks. But I'm running short tasks, because those get the best results.

Before AI came onto the scene, many developers had the idea two monitors were better than one. But after a while a lot discovered the bigger screen size is just a way to add more distractions.
Two screens are good when text needs to be instantly checked against a visual representation. But for most developers that instant checking ability is not needed. We have tests that do the checking for us.

When we were forced to stay at home. One of the positive conclusions was that for mentally intensive work we needed a time were nothing distracted us. And now people at the office also set blocks of do-not-disturb-time in their calendar when they need that distraction free time.

And here we are introducing a new attention seeker with multiple AI agents.
While running AI agents in parallel will make you more productive. This also can make you lose oversight when you don't control the workflow.

How do you handle multiple agents at once in your workflow?
Do you feel like a person that can multitask? Should we multitask?

My 2 cents on the Spatie guidelines agent skills

david duymelinck — Sat, 18 Apr 2026 06:41:37 +0000

I saw on Laravel-news a post about Spatie guidelines. Because other peoples guidelines are always a chance to learn something new, I thought it would be fun to read through them and provide comments.
I'm going to focus on the PHP/Laravel guidelines.

The PHP agent skill is split up in two files where most of the information in SKILL.md is repeated in spatie-laravel-php-guidelines.md. This seems a waste of tokens.

Use camelCase for non-public-facing strings

I assume the model(s) don't always follow that rule of PSR-12. It is not explicitly mentioned, so it can only be inferred by reading the examples.

Use short nullable notation: ?string not string|null

This is explicitly mentioned in PSR-12.

I understand the reasoning behind the rule because of the other PHP functionality using the question mark to signal null like $client?->address and $client ?? new Client().

My own take is to use the long notation to be consistent with the cases where null is a part of three or more options, string|int|null. It is one less place where your mind needs to make the switch that a question mark means null.

Use typed properties, not docblocks

I'm all for documenting using code. It is one of the reasons I'm against using array shapes in docblocks. When the shape is that important use a type.

Use constructor property promotion when all properties can be promoted

With the existence of a variable arguments list this is a bit of a tricky guideline.
A variable arguments list is a more solid way to pass input than an array.
So when a model follows that rule, all none variable properties aren't going to get promoted?

Document iterables with generics:
/** @return Collection<int, User> */

A better way would be to create a specific collection type for the Eloquent model output. It used to be more (too much?) effort but with code generation it is not going to matter.

Always import classnames in docblocks; never use fully qualified names:

This is good advice!

Happy path last: handle error conditions first, success case last

While it is a good rule, it is not always possible.

if (! $user) {
    return null;
}

if (! $user->isActive()) {
    return null;
}

In the same code block with ternary examples this looks very drawn out.

if($user?->isActive() === null) {
  return null;
}

I understand it is an example of multiple if's over multiple branches. But reducing the if's in a function is also a good goal.

// Ternary instead of else
$condition
    ? $this->doSomething()
    : $this->doSomethingElse();

For me this looks like using match when it is better to use switch.
While the ternary operator is not explicitly bound to a return. The PHP documentation suggests that is the most likely use case.
Else isn't that bad that it needs to be avoided by any means.

Use tuple notation: [Controller::class, 'method']

This assumes the controller is very likely to have constructor dependency injection, while it is better to use method dependency injection.
The method dependency injection makes it also possible to use new Controller()->method(...) which is more robust than the method as a string.
In the few cases constructor dependency injection is the best solution, the tuple notation can be used.

Stick to CRUD methods (index, create, store, show, edit, update, destroy)

I understand the rule from a consistency perspective. On the other hand it is very restrictive.
When the controllers are only CRUD vessels, is Laravel the right solution?

Use config() helper, avoid env() outside config files

Solid rule!

Put output before processing an item (easier debugging):

$items->each(function (Item $item) {
    $this->info("Processing item id `{$item->id}`...");
    $this->processItem($item);
});

$this->comment("Processed {$items->count()} items.");

It assumes there is a build-in way to add debug information. As far as I know that is not default.

Class constants also use PascalCase:

This is not compatible with PSR-2.

Conclusion

An agent skill is hard to get right because different models can interpret information in another way.
The skills will work with the model(s) Spatie is using, and that is why some of the guidelines may look a bit out of place.

Like with any other guidelines, they are opinionated. And because we all have our own opinions there are parts where we don't agree.
But the nice thing about agent skills is that they are easy to change to your own liking.

Are routing files a thing of the past in PHP?

david duymelinck — Fri, 17 Apr 2026 03:42:09 +0000

The one link that got my attention in this weeks The Weekly Drop was PHP Attributes Can Be Used for Route Definition and Discovery

As a long time user of Symfony this feels like Drupal is catching up, and I'm all for it. The Drupal developers are really embracing attributes. The first time I noticed it is when they started using it for hooks.

Next to the Route attribute the change also allows the use of invokable controllers. From the Drupal article:

namespace Drupal\router_test\Controller;

use Drupal\Core\Controller\ControllerBase;
use Symfony\Component\Routing\Annotation\Route;

/**
 * Test controller.
 */
#[Route(
  '/test_class_attribute',
  'test_class_attribute',
  requirements: ['_access' => 'TRUE']
)]
class TestClassAttribute extends ControllerBase {

  /**
   * Provides test content.
   */
  public function __invoke() {
    return ['#markup' => 'Testing __invoke() with a Route attribute on the class'];
  }

}

I see quite a few people using single route controllers. And to me it doesn't make sense having to name a method when PHP provides a way to invoke a class with a single public method.

With Symfony, Tempest and now Drupal offering attribute based routing, it looks like Laravel is the biggest framework that doesn't uses attributes for routing.
Laravel already has middleware attributes. This is one of the parts of the routing that is heavily used.

There is a third party package that makes it possible to use attributes for routing.
And you can use it with the Laravel middleware attributes.
This shows it could be a core feature.

It would be amazing when the frameworks could create a standard for the routing attributes. This would make it possible to use controllers in multiple PHP solutions with a few changes or a framework discovery feature.

What is your route attribute use? When you use a router config file, what is stopping you from using attributes?