2026-09 - W1

It takes 5 cloud services to hear my doorbell · Bit Nebula

Something went really wrong along the way if you have to take 5 cloud services just for a doorbell…

One flake to rule them all | Farid Zakaria’s Blog

Interesting way of tackling those multiple flake inputs. Although, I’m not quite sure about this, as that that means adding omniflake delegates the pinning of every indexed flake to this omniflake repository. I don’t know. In term of usability, it might clearly be a good thing, but won’t that also be a SPOF?

A bicycle for the mind

Related to “There’s no such thing as Just a Tool | deadSimpleTech”. Quite interesting analogy with car:

The example is an human that is using a car. The car is just a tool. It doesn’t change you. You can disembark from the car and be just a human anytime you want. Yet, owning and being able to operate a car changes how you interact with the world around you. Moving around by a dozen or a few hundred kilometers is easy. So, taking a job at the other end of the city is a reasonable choice. You can have friends that live further away and still get to see each other. You can go for vacations at some distant beach or mountain or natural park, reach remote places, and carry a lot of things with you.

However, some of us have become dependant on cars. This can happen for a variety of reasons. Obviosuly, the choices you made (such as living far away from your workplace). But also, a large part of our infrastructure is designed for people with cars. This is less extreme in some countries than others, but, to some extent, pretty much anywhere you go, you will find out that there’s a road so car can get around, and people are relying on it because it’s convenient, or cheaper, or there’s no other way to do it. … Just like bike and cars, computers are tools, too. They also change how we perceive and interact with the world. … So, how do LLMs and their use in Linux and Debian fit into this? Well, I think LLMs are like cars for a bicycle rider like me. They are faster. They are not safer, but generally you can ride one and you’ll be OK. But, more importantly, they change how people view the world, and through that, they change what people decide to do with the world.

Maybe We Shouldn’t Be Reviewing All This Code

Or, perhaps the problem isn’t that AI has broken code review, maybe it’s that we’ve been using code review to solve the wrong problems

If we want to explore alternative solutions, I’d rather do that before implementing one of them.

If we want knowledge transfer, pair. Sitting next to someone, physically or virtually, while they reason through a problem teaches you far more than reading their completed solution afterwards.

If we want junior engineers to learn how experienced engineers think, let them work with experienced engineers while they’re thinking. Pairing comes to mind again here, but teams could also do design sessions collectively with a whiteboard before they write (or instruct the agent to write) anything.

If we want collective ownership, organise teams so people actually build and operate software collectively rather than relying on a pull request to tell everyone what somebody else has already built. For this again use pairing, mob programming, or team design sessions around whiteboard.

If we want architectural alignment, design together (I won’t repeat myself about pairing and team design sessions, oh wait…) and then encode the important constraints as fitness functions.

State of Postgres | Datadog

The Harness Playbook — Stencil

Interesting perspective from the author of oh-my-pi.

Grep beats LSP? Why coding agents ignore your fancier tools — AgentConnect Blog

It seems, grep is still king. Although, the conclusion is more nuanced.

Protecting Engineers’ Skills in the AI Era - IEEE Spectrum

Duh.

AI Agents Push Humans Out of the Loop

The Harness, the Horse, or the Hay - by Brett Queener

Interesting analogy.

There’s No Limit to How Bad Code Can Get

TL;DR: Metaphors like “a sinking ship” are often used to describe codebases, but are misleading. A business will sink long before code quality reaches a hypothetical floor. Technical debt has no bankruptcy, no clean reset, so metaphors that imply an end provide a false sense of security.

One CEO in eight got what AI was sold as, survey - Coté

The End of Code Review? Or an Opportunity to Rethink it?

I think the bigger question is about all the other benefits we got from code review that were not about code quality, like coordination and mentoring. I think the better question to ask is how much those are still needed and how we can get them in forms that are not code review. For example, would better standup meetings or AI summaries of changes be able to replace the awareness benefits of code review? Would deliberate feedback and mentoring mechanisms better support the junior to senior software engineering pipeline than code review? I think stepping back and rethinking a world without code review is a more useful exercise than tweaking existing code review practices.