Web development is fun again

Yes, I recon coding is dead.

No, that doesn't mean there's nothing to learn.

People like to make comparisons to calculators rendering mental arithmetic obsolete, so here's an anecdote: First year of university, I went to a local store and picked up three items each costing less than £1, the cashier rang up a total of more than £3 (I'd calculated the exact total and pre-prepared the change before reaching the head of the queue, but the exact price of 3 items isn't important enough to remember 20+ years later). The till itself was undoubtedly perfectly executing whatever maths it had been given, I assume the cashier mistyped or double-scanned. As I said, I had the exact total, the fact that I had to explain "three items costing less than £1 each cannot add up to more than £3" to the cashier shows that even this trivial level of mental arithmetic is not universal.

I now code with LLMs. They are so much faster than doing it by hand. But if I didn't already have experience of code review, I'd be limited to vibe-coding (by the original definition, not even checking). I've experimented with that to see what the result is, and the result is technical debt building up. I know what to do about that because of my experience with it in the past, and I can guide the LLM through that process, but if I didn't have that experience, the LLM would pile up more and more technical debt and grind the metaphorical motorbike's metaphorical wheels into the metaphorical mud.

You can vibe code, i.e. no code review, but this builds up technical debt. Think of it as a junior who is doing one sprint's worth of work every 24 hours of wall-clock time when considering how much debt and how fast it will build up.

I have less confidence after a session, now I second guess everything and it slows me down because I know the foot-gun is in there somewhere.

For example, yesterday Gemini started added garbage Unicode and then diagnosed file corruption which it failed to fix.

And before you reply, yes it's my fault for not adding "URGENT CRITICAL REQUIREMENT: don't add rubbish Unicode" to my GEMINI.md.

I basically don’t outsource stuff to an LLM unless I know roughly what to expect the LLM output to look like and I’m just saving myself a bunch of typing.

“Could you make me a Go module with an API similar to archive/tar.Writer that produces a CPIO archive in the newcx format?” was an example from this project.

I think the classic division of problems being solved might, for most people, solve this seeming contradiction.

For every problem, X% is solving the necessary complexity of the problem. Taming the original problem, in relation to what computers are capable of doing. With the potential of some relevant well implemented libraries or API’s helping to close that gap.

Work in that scenario rarely feels like wasted time.

But in reality, there is almost always another problem we have to solve, the Y%=(1-X) of the work required for an actual solution that involves wrangling with mismatches in available tools from the problem being solved.

This can be relatively benign, just introducing some extra cute little puzzles, that make our brains feel smart as we successfully win wack-a-mole. A side game that can even be refreshing.

Or, the stack of tools, and their quirks, that we need to use can be an unbounded (even compounding) generative system of pervasive mismatches and pernicious non-obvious, not immediately recognizable, trenches we must a 1000 little bridges, and maybe a few historic bridges, just to create a path back to the original problem. And it is often evident that all this work is an artifact of 1000 less than perfect choices by others. (No judgement, just a fact of tool creation having its own difficulties.)

That stuff can become energy draining to say the list.

I think high X problems are fun to solve. Most of our work goes into solving the original problem. Even finding out it was more complex than we thought feels like meaningful drama and increase the joy of resolving.

High Y problems involve vast amounts of glue code, library wrappers with exception handling, the list in any code base can be significant. Even overwhelm the actual problem solving code. And all those mismatches often hold us back, to where our final solution inevitable has problems in situations we hope never happen, until we can come back for round N+1, for unbounded N.

Any help from AI for the latter is a huge win. Those are not “real” problems. As tool stack change, nobody will port Y-type solutions forward. (I tell myself so I can sleep at night).

So that’s it. We are all different. But what type of acceleration AI gives us on type-Y problems is most likely to feel great. Enabling. Letting us harder on things that are more important and lasting. And where AI is less of a boost, but still a potentially welcome one, as an assistant.