Posts

Nolan Lawson:

So how do we fight this horde of agents colonizing our brains? In short: stay human, friends. Resist the whispering earring. Be jealous of your time and attention, and try to find other sources of artistic sustenance than the chatbots. As doomed as it may feel, try to keep a part of yourself that is the tiny little village of Gauls holding off the Roman invaders. Whatever your inner sanctum is, protect it from AI infiltration.

Plus, I know that as soon as I ask the chatbot for help on even a single sentence (“can you help this land better?”), it’s all over for me. I’ve already given up on keeping my own voice in my code: I used to care a lot about variable names, function arrangement, which kinds of for-loops to use… and now I just accept Claude’s little stylistic quirks because they’re not worth fighting. If I let the same thing happen to my English writing, I’d feel like it had lost some indelible stamp of me-ness.

A lot has been written about AI writing. This is one of the best I’ve read, perhaps because it echoes a lot of my worries.

Zach Kehs:

Software is in the domain of the abstract. It is not like a building, or a bridge, that is in the physical realm where you can see and feel the nature of the thing. If you continue to add floors and rooms to a building forever, it will collapse. Software faces no such constraint. The code can always get worse. There can always be a new layer of indirection or a reduction in performance.

The pedants will rightfully point out that software can completely fail to function if it gets bad enough. In practice, such breaking changes are quickly reverted. The thousands of changes that came before to make the code worse are not. The software continues to 'work'. Other cases without a single breaking change to revert are where the ballooning costs of the bad software eclipse its benefit, or if development velocity approaches zero because nothing can be shipped without a breakage. In all of these cases, it is the business that dies long before the code hits any hypothetical floor (so don't act like there's a floor!).

Ignore the ostensibly main point about the use of language like “sinking ship”. The argument put forth for it is more interesting. Really good.

via Joy & Curiosity by Thorsten Ball

Philip Zeyliger:

We are all grappling with what it means to be an organization with agentic tools. We are seeing a Cambrian explosion of workflows in how to produce software. It is unwise, right now, to declare The Solution and enforce it. Developer Productivity teams that are pushing a workflow on their users are being counterproductive. Instead, the moment calls for experimentation and for giving people the agency to experiment, to learn, to iterate.

I agree. Boy, do I agree. My setup and workflow are constantly changing—maybe every month or so. But I see so many people stuck in a local minimum, just using Claude Code the way they were using it back in December last year.

I’m not saying everyone should be constantly tweaking setup/workflow; that’s definitely not for everyone. But not experimenting at all is perplexing to me.

Pieter Hintjens:

This article is an extract from Chapter 6 of the ZeroMQ book, on community building.

I’m not quoting from the actual parable so as not to spoil it. It’s short but profound.

So much good stuff in there. I’ll quote from across sections.

Florian Herrengt:

But then users start to report a weird bug. It's the 4th time your team has been trying to fix it. I mean... asking AI to fix it. Unfortunately, it seems like not even Fable can figure it out.

You go talk to the person who worked on this feature.

• "So where does the data come from?"
• "Hmm... actually I don't know. Let me ask Claude."

You sit next to each other watching an endless wall of text appear on the screen. Neither of you has any idea whether any of it is true but Claude seems very confident.

"Let's just turn on ultracode and ask it to double-check?"

This one will take a while. You start talking about the latest drama on X.

You finally get an answer back.

• "Does this make any sense to you?" * "I'm not sure."
• "Didn't you build this like... last week?"

Silence.

On not understanding large codebase:

Whenever I talk about this, someone eventually tells me that nobody ever fully understood large systems anyway. It's true.

You were never expected to understand every service and every database. But at least someone did and would explain it to you.

Now they ask an LLM because they don't actually know themselves.

Concluding:

Of course, bad engineers were always a liability.

It has been like this for decades, well before OpenAI or Anthropic existed. Bad decisions compounded, unnecessary complexity accumulated and teams ended up maintaining systems nobody really understood.

The difference is that there used to be a limit to how fast you could do it.

Today, implementation is cheap. You are paid to make good decisions. To build software that will scale while managing complexity.

A lot of good decisions have to be made to keep a large/complex codebase healthy. Bad decisions compound. Fast.

Bad engineers make bad decisions, and AI allows encourages them to do it at a speed that wasn’t hitherto possible. Worse, thanks to the deluge of changes that AI enables, it makes it difficult for the good engineers to review & curtail the bad decisions.

The conclusion is obvious: we can’t afford to have bad engineers.

Sean Goedecke:

The key idea here is that the best way to be sycophantic to smart people is to disagree with them without making them feel stupid. Ideally you’ll come up with a counter-argument that works against what they’ve said but is straightforward for them to knock down by clarifying their idea. If you do it right, you’ll validate their self-image as a smart person who appreciates rigorous critique. But if you actually come up with a devastatingly rigorous critique, they won’t enjoy it at all. At best, they’ll resentfully agree with you. At worst, they’ll double down on being right and convince themselves you’re a rude idiot.

Oh damn! This seems so obvious once it’s pointed out that I feel stupid for not having realised it.

FWIW, I think Claude models do this far more covertly than the GPT models. This might be one reason why I dislike working with Claude in general.

Marcin Wichary:

On her blog, Lea Verou makes a case that each user-facing website dark-mode toggle should only ever show two options, but in a smart way.

The challenge is that any dark mode toggle needs to actually accommodate three options: dark, light, and the default “whatever the system says” (which can be always dark, always light, or change with the time of day). Many toggles simply pass that complexity onto the user:

I have been enjoying the Unsung blog by Marcin Wichary a lot. This post exemplifies why. He takes the smallest ideas in design and UX and dives deep into them.

I have already changed my website’s dark/light mode toggle to work this way! (I never had the tri-state toggle, but any change in preference was only for the current browser tab, it wasn’t getting persisted.)

Timber Stinson-Schroff:

If I have a regret, or a cautionary tale, it might be reading Thinking In Systems: A Primer by Donella Meadows. Meadows was apparently a wonderful woman, and she wrote a solid book. But if you’re a twenty-one year old desk jockey, like I was, systems thinking is basically a hard drug. Books like Meadows’, or The Fifth Discipline by Peter Senge, to name another example, will juice you up with a dangerous amount of hubris and delusion about your agency. Why? Well, it’s one thing to know where to look for leverage points in a system (places where you can make a lot of change without a lot of effort, basically). But there are some complicating factors…

This is an interesting take — that Systems Thinking is not good for young analysts, not because the ideas are wrong, but because it makes the said analysts misjudge their abilities and influence. I haven’t seen much commentary that doesn’t deride an idea but warns a certain group of people of its dangers.

Sean Goedecke:

My guess is that people who work on small codebases with low-turnover teams (say, Redis or games like The Witness) would say “obviously you have to understand it completely, otherwise you can’t do good work”. I’d also guess that people who work on large codebases with high-turnover teams (say, the Google web search backend or GitHub) would say “obviously you can’t understand it completely, you just have to do the best you can in your local area”.

These are two largely different ways of programming with different methods, practices and cultures. However, the first group is over-represented in online discussion about software engineering. I want to defend the second group against the first. In many software engineering environments, there’s nothing wrong with being in a state of partial understanding. In fact, in large systems a partial understanding is the best you can do.

I'm becoming a fan of this Sean Goedecke. Such good writing. No fluff at all. Read the entire post—it's well argued.

Luke Kuzmish:

I don’t know if people were always saying “it’s not X, it’s Y,” but I’m hyper-aware of it. When I see it, I assume it was written by AI. I am starting to look for the fingerprints of LLM generated text everywhere. It’s exhausting to be suspicious all the time.

Whether I write the code myself or an agent does, having two separate models review the code has been a win, hands down. Remember, both AI and humans are sometimes bad at code. Multi-model code reviews add more Swiss cheese to the process.

Many such truisms in this post. I agree with a lot—but not all—of them.