Good that that debate has been put to rest, if there ever really was one. LLMs are here to stay, and I don’t know anyone who’s tried them who doesn’t use them for something — which means they think they can get a speedup on that particular something, whatever else they say about LLMs being stupid or “not real AGI” or “Schießmichtot ” (shoot-me-dead, a German expression meaning basically whatever).

What I find striking, though, is how different the two experiences of vibecoding vs. “coding at work” are. I’m under the impression that I get a significant boost at work as well, but it’s more about rapid initial exploration of workable solutions than pumping out code really fast. Now, the experience from vibecoding surely carries over into how effectively you can wield your tool of choice at work, but I had this thought today about how so many things have shifted slightly. For example, I’ve found it more useful to maintain a simple complaints sheet with one-liners of what doesn’t work than to describe bugs properly. In the evening hours, I can feed those, ever so slightly rephrased, to my LLM and let it do its job while I watch a video, and get my improved app for the next day.

Now, one observation here for me is that fixing minor imperfections is often so fast that it becomes almost tolerable when fixing one thing breaks another.

This is exactly the sort of thing you want to prevent “at all costs” normally, which you do by a) ensuring modules are shared and b) testing.

As exciting as it was at the beginning to listen to Yegge, I thought it outright crazy to lean into “letting go” that hard. But the longer I do this, the more I have to concede certain things. For example, that even duplication isn’t always totally bad. I mean, I even heard Donald Knuth make that case before LLMs became big — that literally “forcing” DRY comes at the cost of readability and makes code harder to understand and maintain. We should remember, it’s always tradeoffs — always. DRY is no exception. And DRY is at this moment still a notorious weakness of LLMs, which you can either put a lot of effort into counteracting, or accept to a certain degree.

Now — bear with me on this one — there’s this school of thought, which I believe comes from the microservices world, where testing certain things is basically impossible, so you shift focus to observability and resilience. You accept failure and make sure you can recover quickly and that you’re on top of what’s going on. People have already suggested doing away with PRs since they’ve become a new bottleneck (can’t find where I read that, but on the topic of PRs, I found this interesting), so isn’t there a case to be made for treating at least certain classes of errors as acceptable? It depends on the cost of things going wrong, obviously. But the point is, it might be easier - and ultimately less expensive - to fix some problems as they’re discovered, even if they break again later, than to test for them at great expense or to prevent errors “at all costs” by developing them to a high standard — which boils down to making sure they “share the same component ”.