I had never really thought too much about WIP limits before reading this. I assumed they existed to encourage team members to help unblock each other, instead of picking up another ticket. However there is a cognitive reason, which is all the more pertinent with agentic coding.

We looked at the agents and thought: these things are cheap, they run in parallel, there’s no reason to limit how many I spin up. And that’s true — for the agents. The constraint was never the agents. The constraint is the single human in the middle whose job is to actually understand what came back.

This is old, old wisdom and we keep re-learning it. Jerry Weinberg, in Quality Software Management back in 1992, put a number on context switching: split your attention across two projects and you lose roughly 20% of your time to the switching itself. Add a third and you’re bleeding something like 40%. The lines on that chart are brutal, and — this is the important bit — they don’t care that your workers are robots. The switching tax is levied on you, the one doing the switching. Eight agents means you are basically not paying attention to any of them.

Kanban people have been shouting about WIP limits for twenty years for exactly this reason. Limiting work-in-progress isn’t about the capacity of the workers. It’s about the capacity of the system to finish things well. And a pile of half-attended-to agent output isn’t finished. It’s inventory. Expensive, unread, possibly-wrong inventory.

Most of the variance in developer output, even with AI augmentation, is not about the developer, it’s about friction. It’s about how many times a day someone gets interrupted, how long the builds or tests take, how quickly a review is turned around, how confident they feel deploying on a Friday afternoon, whether the test suite is trustworthy, and whether they spend their week on work they consider meaningful.

100% this! If you want to improve developer output, then protect them from unnecessary meetings and distractions.

The big shift with agents is that it’s now technically feasible — and consequently tempting — to launch multiple workstreams. In fact, the entire agentic workflow actively encourages it. I mean, when launching an agentic task, I never know what the wait time will be. Are we talking 30 seconds, or do I have to watch the internal LLM ramblings for 25 minutes? That wait time is like an open invitation for self-interruptions, which are the most damaging types of context switches. AI coding just gives us so many passive pause points: waiting, reviewing, correcting, waiting again, ad infinitum.

To avoid getting bored, it’s tempting to embark on a second and third task in parallel just to stay busy. This is often a mistake: agents scale; human attention doesn’t.

I can very much relate to this, particularly with my neurodiverse brain that wants to remain stimulated. I've fallen into the trap of launching multiple agents, all working on different projects, and it never works out well as my attention gets fragmented, and I become overwhelmed.

I've been thinking about this, and I do think it's a great form of degradation. I would love to see more sites that are statically rendered, but under load dynamic features are removed.

Giving clear instructions about what to do and what not to do, and ensuring those instructions are consistent and not noisy, will forever be a challenge with AI, no matter how good it gets.

We have coworkers, partners, and other people we know and interact with who are sentient. They pass the Turing test, they are “AGI,” and yet: we still have a hard time conveying instructions, ideas, and concepts among each other.

I've been thinking about this lately, and I can very much relate to this statement. Regardless of whether you're working with an agent or a living and breathing colleague, if you don't give them clear requirements and historical context, there is a very good chance they will go off-piste.

If you’re using quotes around your own terms and preemptively closing any discussion about it, then you’ve already lost.

This is exactly what the article is trying to argue, in the authors own words, he wants a "meaningful conversation". As for the quotes, it's challenging the claim that "coding is largely solved", as made by Boris Cherny at Anthropic, by dissecting what is meant by both "coding" and "solved".

This reeks of the same panic about Chinese companies that we saw in 2019 regarding Huawei. Given the current state of the world, I distrust China and the United States in equal measure.

Also Hirundo's whole business model is about cultivating distrust in open-weight models in order to convince people to pay for their hardened models:

Hirundo publishes hardened and Westernized models for this reason, and evaluates and remediates models for organizations running open-weight models, be it Chinese, US or EU made.

There is a CSS media feature for that prefers-reduced-motion.

Judging by this quote, the only thing dying is quality:

Since the beginning of the year, the quality of software has been degrading pretty much everywhere, much of it caused by over-reliance on AI, or perhaps more accurately, the outsourcing of thinking and decision making to AI. In July, I moved my video podcast off of Spotify after a series of unexplainable outages, and Spotify’s engineering team seemed to take no real pride or accountability in fixing the root causes of the issue.

Only this week, Uber shipped a new feature to production in the Uber Eats app – a new way to select extras with your food order – with seemingly no QA testing:

That's exactly my issue with people saying something is "AI slop", it's a lazy way to shutdown conversation on something you disagree with.

Can you prove it's AI slop? The author has previously posted that they don't allow AI-generated content on their blog.

Could you give an example of what makes this an AI article? If you're referring to the image, that is credited to the Illustrator Jeffrey Phillips.

As for airline backend infrastructure, I remember attending a great talk from Skyscanner, explaining how airlines were ahead of the curve getting computers but the problem is they haven't kept them modern. That however, is not an excuse for poor front-end performance that the article discusses.