The Difference Between Today's Task and Accretive Work in the Age of AI

There's a 'joke' that goes around occasionally that has some truth to it: "Excel is the world's most popular programming language." Occasionally it's 'Excel macros' or 'VBA' instead of just Excel.[1]

The core truth of it is that a massive amount, possibly most, of the world's software is not a carefully hand-crafted application in that lives in Github written by expert software developers. It's a heap of Excel functions in an XSLX file, with no tests, no source control, no PRs, and no real planning behind it. And it works for that one specific task that the person who built it needed at the time.

AI vibe-coding is probably filling in the middle-ground between that stuff and 'real' code - it does more than just building somehting to complete today's task, and it is accretive in the sense that someone can build on top of it, but it doesn't really look that way to someone used to working on 'proper' software.

[1] Further reading if you're interested - https://news.ycombinator.com/item?id=27048672

Isn’t this a question of how much the “terrorised survivors” spend on tokens to make the output “canonised”?

I think the main argument that the billions spent are not going to be recouped is accurate, but I strongly suspect the cost of producing high quality code will remain the same -just being produced faster (speed, cost, quality - you still only get to pick two)

If one Steve Yegge can burn tokens in “Gas Town” that cost as much as me and ten others then you have saved my salary but spent it on Steve’s token use for roughly the same code quality as me steve and ten others would have produced in three months - just it took steve three days

Same price, faster delivery. Is that a win ? I suspect that facebooks recent announcement (“we cannot think of enough things to do with software so who wants our GPUs?” Might suggest that it’s a business model problem more than a software probkem

Realistically speaking, most programs, no, 90% of them are terrible. Including mine. I write terrible code too, so I'm in no position to judge.

The programs I've taken apart and looked at, even ones running in real industrial settings and large corporate factories, 90% of them are terrible.

Most code is just 'Today's Task.' The people who deny this are probably those working at IT service companies, because they build around maintainability and scalability.

But as you go down into hardware, there's an additional pressure: 'We don't know when this hardware will reach end-of-life.' The centaur metaphor is a simplified dichotomy. 'Centaur is good, reverse-centaur is bad.' But in reality, the vast majority of programs end up as disposable one-off code.

These days, AI related articles just seem to amplify whatever values people want to believe, turning into tribal warfare posts. Realistically speaking, you can write maintainable code with AI too. In fact, the 'Canonization' mentioned in this post is essentially pattern-templating, which AI does better.

The fundamental problem with AI code is that as the input prompt gets deeper, it introduces enterprise level complexity rather than the depth the program actually needs. I don't think that's the core issue here.

The advantage of human written code is that it can be complex when it needs to be and simple when it doesn't, but AI code tries to apply the same level of complexity everywhere. Honestly, the most widely used things in the w […]

AI makes it cheaper to create working fragments. It does not automatically make those fragments part of a maintainable system. In practice it may make the canonization step more important not less