September 7, 2026

There usually isn't a correct answer

Writing software with AI is a really different experience than writing it by hand. Before coding agents, software was expensive to produce, in the sense that it required a lot of time from a lot of highly skilled and highly compensated people. Now, generating code is very cheap comparatively speaking, and the expensive part is deploying, operating, and maintaining it. People say AI can do this too but my experience in the industry is that it can’t, which I think is mostly why software engineers still have jobs and are actually more in demand than ever. This only makes it more important to choose wisely what software is worth producing in the first place. […3 min read]

post#agent-driven-development#ai#ai-agents#complexity#productivity#quality#software-development#software-engineering

August 13, 2026

AI is removing the middle class of software engineering (via)

This was a pretty scathing indictment of the tech industry but I think on point. It says a lot of things that you’re not supposed to say out loud right now but that everyone is thinking. Like:

AI makes projects with weak engineering culture fail much faster.

and

In every team, there are competent people who make the project possible. There are also people who essentially make it harder for everyone else.

I don’t actually think anyone benefits from being mean about it, but this is generally true in my experience. Not just in software but in life generally, sadly.

There used to be a time when people sat down and talked about how they'd do something. Now they can just prompt an agent for a few hours and open a PR.

The most tragic aspect of this way of working is that, to the untrained eye, it works.

It does appear to work and I think this is the most dangerous part. Something I really struggle with lately is finding the right balance between excitement and gatekeeping. On one hand it’s really cool to see more people with different ways of seeing things coming up with software solutions to their problems. On the other hand I die a little inside every time I see what’s under the hood, especially when I’m asked why it doesn’t quite work.

This project has become so convoluted, with so many layers and services, that no one on your team could possibly start to understand what's going on.

So, what do you do?

Fixing it would require such a colossal amount of work that it would be impossible to even start justifying it to anyone in management.

It’s always been frustrating to me that “management” (in my experience it's more often product teams than management who control engineering time, but same concept) don't understand the importance of untangling these kinds of architectural messes. "Tech debt" work often gets prioritized alongside regular product development and engineers are constantly forced to justify its "business value", but this makes absolutely no sense and fundamentally misunderstands the cost and consequences of carrying technical debt.

More often than not there is no direct value (in the business sense) in paying down tech debt, but it's a non-negotiable prerequisite for getting literally anything else done. Like real debt, you don't get anything new when you pay it off -- you already consumed the value when you took on the debt. But until you do pay it off you can't buy anything else.

At some point, someone still has to know what is going on. And that's the most valuable person on the team.

It has become very annoying to be this person. I used to just go in and fix things and make software work. Now I have to stage an intervention first.

link#ai#careers#complexity#quality#reflections#software-engineering#tech-industry

February 10, 2021

January 30, 2021

How state makes software complex

What makes large codebases so hard to reason about, and so hard to extend? I really want to find out because I'm tired of losing my mind working on them. One paper I love called "Out of the Tar Pit", by Ben Moseley and Peter Marks, argues that state is the main source of complexity in large software systems. This article is an overview of a couple of the ideas from that paper, along with some discussion about how we might conceptually think about necessary state in software in order to improve its overall quality. […6 min read]

post#complexity#papers#software-engineering