The value is in the difficulty - Annotations
We’ve seen this arc before, and music is the richest analogy.
Like Bruce Sterling always says:
Whatever happens to musicians happens to everybody.
We’ve seen this arc before, and music is the richest analogy.
Like Bruce Sterling always says:
Whatever happens to musicians happens to everybody.
Not sure I buy the argument here, though I do very much look forward to local language models getting better so we can ditch the predatory peddlars of today’s slop. But this trip down memory lane to the early web of the 1990s could’ve been describing my own experience:
But the thing I do remember was the first time I came across Derek Powazek’s Fray online magazine. It was the first time I had seen a website look beautiful. This was without CSS and without Javascript. I still remember quite clearly an “issue” of Fray that used frames to create some kind of “doors” you could slide open to reveal an article inside.
Fray was what made me want to make websites:
I distinctly remember sites like prehensile tales, 0sil8 and the inimitable Fray triggering something in my brain that made me realise what it was I wanted to do with my life.
You can’t write a compelling narrative about the thing you didn’t build. Nobody gets promoted for the complexity they avoided.
Complexity looks smart. Not because it is, but because our systems are set up to reward it.
Anyone can add complexity. It takes experience and confidence to leave it out.
You know my thoughts on generative tools based on large language models, but this example of personal empowerment is undeniably liberating.
We value learning. We value the merits of language design, type systems, software maintenance, levels of abstraction, and yeah, if I’m honest, minute syntactical differences, the color of the bike shed, and the best way to get that perfectly smooth shave on a yak. I’m not sure what we’re called now, “heirloom programmers”?
Do I sound like a machine code programmer in the 1950s refusing to learn structured programming and compiled languages? I reject that comparison. I love a beautiful abstraction just as much as I love a good low-level trick.
If the problem is that we’ve painted our development environments into a corner that requires tons of boilerplate, then that is the problem. We should have been chopping the cruft away and replacing it with deterministic abstractions like we’ve always done. That’s what that Larry Wall quote about good programmers being lazy was about. It did not mean that we would be okay with pulling a damn slot machine lever a couple times to generate the boilerplate.
My social networks are currently awash with Deep Blue:
…the sense of psychological ennui leading into existential dread that many software developers are feeling thanks to the encroachment of generative AI into their field of work.
Marcin’s history of “molly guards” in hardware and software:
Old-school computing has a term “molly guard”: it’s the little plastic safety cover you have to move out of the way before you press some button of significance.
There are two wolves inside you…
My Builder side won’t let me just sit and think about unsolved problems, and my Thinker side is starving while I vibe-code. I am not sure if there will ever be a time again when both needs can be met at once.
In an age of abundance, restraint becomes the only scarce thing left, which means saying “no” is more valuable than ever.
I’m as proud of the things I haven’t generated as the things I have.
Generated code is rather a lot like fast fashion: it looks all right at first glance but it doesn’t hold up over time, and when you look closer it’s full of holes. Just like fast fashion, it’s often ripped off other people’s designs. And it’s a scourge on the environment.
I’ve seen so many times how 10 lines of code can end up being worth £millions, and 10,000 ends up being worthless.
People use “enshittification” to describe platform decay. What I’m describing here is one of the mechanisms that makes that decay feel personal. It’s the constant conversion of your attention into a KPI.
The hard part of computer programming isn’t expressing what we want the machine to do in code. The hard part is turning human thinking – with all its wooliness and ambiguity and contradictions – into computational thinking that is logically precise and unambiguous, and that can then be expressed formally in the syntax of a programming language.
That was the hard part when programmers were punching holes in cards. It was the hard part when they were typing COBOL code. It was the hard part when they were bringing Visual Basic GUIs to life (presumably to track the killer’s IP address). And it’s the hard part when they’re prompting language models to predict plausible-looking Python.
The hard part has always been – and likely will continue to be for many years to come – knowing exactly what to ask for.
Can you ship AI-generated code without creating a maintenance nightmare six months from now? Can you debug it when it breaks? Can you modify it when requirements change? Can you onboard new engineers to a codebase they didn’t write and the AI barely explained?
Most teams haven’t realized this shift yet. They’re optimizing for code generation speed while comprehension debt silently accumulates in their repos.
One team I talked to spent 3 days fixing what should have been a 2-hour problem. They had “saved” time by having AI generate the initial implementation. But when it broke, they lost 70 hours trying to understand code they had never built themselves.
That’s comprehension debt compounding. The time you save upfront gets charged back with interest later.
Every engineer eventually overbuilds something. You think you’re being smart. You’re thinking ahead, building for growth and before you know it, you’ve created a system ten times heavier than your actual problem. That’s the trap. We keep designing for imaginary futures for scale that may never come and call it engineering. But it’s not engineering. It’s over-engineering.
The industry rewards it too. Nobody gets promoted for keeping things small and sane. You get promoted for complexity.
There’s quite a crossover between resilience and longevity:
- Understand the requirements
- Keep scope small and fixed
- Reduce dependencies
- Produce static output
- Increase Quality Assurance
I’ve worked in the tech industry for close to two decades at this point. I’ve seen how difficult it is to build quality products, but I’ve also seen that it can be done. It just feels like no one gives a shit anymore, beyond a handful of independent devs and small shops. It’s wild.
Hannah runs through the details of making a grid-aware website:
The design adjusts between “low”, “moderate”, and “high” based on the quantity of fossil fuels on your local energy grid.
I like this idea, but I really think it needs to be on by default, rather than being opt-in.
And I’m really intrigued by the idea of a grid-aware browser!
Instead of that deep immersion where I’d craft each function, I’m now more like a curator? I describe what I want, evaluate what the AI gives me, tweak the prompts, and iterate. It’s efficient, yes. Revolutionary, even. But something essential feels missing — that state of flow where time vanishes and you’re completely absorbed in creation. If this becomes the dominant workflow across teams, do we risk an industry full of highly productive yet strangely detached developers?
Here’s the main problem I’ve found with generative AI, and with “vibe coding” in general: it completely sucks out the joy of software development for me.
I hate the way they’ve taken over the software industry, I hate how they make me feel while I’m using them, and I hate the human-intelligence-insulting postulation that a glorified Excel spreadsheet can do what I can but better.