Highlights of the Week
Hackernews Thread
And he said something then that I will never forget and which absolutely blew my mind because no one had ever said anything like it to me before: “I don’t think being good at things is the point of doing them. I think you’ve got all these wonderful experiences with different skills, and that all teaches you things and makes you an interesting person, no matter how well you do them.”
I came across this thread the other day about hobbies and while a lot of the ones in it have no interest to me, this quote really did strike me. It is more about the journey rather than the destination. The whole point of a hobby or doing most things is to do the thing and get the experience. It is not about ticking off a box, or trying to get to be the best of the best in the world or doing something nobody else has ever done. More it is about collecting these experiences and skills to mould yourself to be a different kind of person. The one you want to be and it all adds up to make you an interesting person. So just explore the world, in time or space or knowledge.
Nobody Is Coming to Save Your Career
Growth didn’t happen until I deliberately stepped out of the comfortable work and took on something that was bigger than my capabilities. That only happened after I rocked the boat a bit. That’s when the trajectory changed. Disturbing a comfortable situation is one of the hardest things to do at work because everyone around you, including your manager, is benefiting from the status quo. When you say, “I want to take on something bigger,” you’re introducing risk into a system that was running smoothly. Your manager now has to figure out who covers your current work. They have to trust you with something you haven’t proven you can do yet. They might even have to go to bat for you with their own boss to get you that opportunity.
This was a good wake up post for me. Often we get comfortable where we are and need to make a change to shake things up and get to the next part of life. Growing comes with changing, and stepping out of your comfort zone. So work towards it and try make that change.
Thoughts on Slowing the Fuck Down
https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/
The problem with agents is that they make errors. Which is fine, humans also make errors. Maybe they are just correctness errors. Easy to identify and fix. Add a regression test on top for bonus points. Or maybe it’s a code smell your linter doesn’t catch. A useless method here, a type that doesn’t make sense, duplicated code over there. On their own, these are harmless. A human will also do such booboos. But clankers aren’t humans. A human makes the same error a few times. Eventually they learn not to make it again. Either because someone starts screaming at them or because they’re on a genuine learning path. An agent has no such learning ability. At least not out of the box. It will continue making the same errors over and over again. Depending on the training data it might also come up with glorious new interpolations of different errors.
The presented fixes for this in the piece is to slow down which I’m not sure exactly makes sense but the problem is definitely real. Producing more code means more errors means more problems everywhere. Humans make the same ones but the sheer speed causes them to occur at a much greater rate. Slowing down just because feels wrong though. Maybe there’s a better way of structuring things around it all.
Compound Engineering: Make Every Unit of Work Compound Into the Next
https://every.to/guides/compound-engineering
Previously, I suggested an 80/20 rule for building features: 80 percent of time planning and review, 20 percent on working and compounding. When you look at your broader responsibilities as a developer, you should allocate 50 percent of engineering time to building features, and 50 percent to improving the system—in other words, any work that helps build institutional knowledge rather than shipping something specific.
I like the code review skill of the compound engineering plugin so I said I’d read the docs a bit more fully. This bit stuck out. Spend more time thinking about the direction and plan of attack, rather than of doing the actual change. That means you can hopefully review the change better and have a better idea of where things are going. Directionally true I feel.
I Saw Something New in San Francisco
https://nytimes.com/2026/03/29/opinion/ai-claude-chatgpt-gemini-mcluhan.html
Researchers have drawn a distinction between “cognitive offloading” and “cognitive surrender.” Cognitive offloading comes when you shift a discrete task over to a tool like a calculator; cognitive surrender comes when, as Steven Shaw and Gideon Mave of the University of Pennsylvania put it, “the user relinquishes cognitive control and adopts the A.I.’s judgment as their own.” In practice, I wonder whether this distinction is so clean: My use of calculators has surely atrophied my math skills, as my use of mapping services has allowed my (already poor) sense of direction to diminish further.
It is all a balance. Letting agents do things means we’re not doing them means we’re not going to be as good at them. Makes sense for some things but not for others. We need to make that decision though of what we want to retain the skills for
See also the gym vs job concept in https://danielmiessler.com/blog/keep-the-robots-out-of-the-gym
Eight Years of Wanting, Three Months of Building With AI
https://lalitm.com/post/building-syntaqlite-ai/
AI turned out to be better than me at the act of writing code itself, assuming that code is obvious. If I can break a problem down to “write a function with this behaviour and parameters” or “write a class matching this interface,” AI will build it faster than I would and, crucially, in a style that might well be more intuitive to a future reader. It documents things I’d skip, lays out code consistently with the rest of the project, and sticks to what you might call the “standard dialect” of whatever language you’re working in19.
But here’s the flip side: the same speed that makes AI great at obvious code also makes it great at refactoring. If you’re using AI to generate code at industrial scale, you have to refactor constantly and continuously20. If you don’t, things immediately get out of hand. This was the central lesson of the vibe-coding month: I didn’t refactor enough, the codebase became something I couldn’t reason about, and I had to throw it all away. In the rewrite, refactoring became the core of my workflow. After every large batch of generated code, I’d step back and ask “is this ugly?” Sometimes AI could clean it up. Other times there was a large-scale abstraction that AI couldn’t see but I could; I’d give it the direction and let it execute21. If you have taste, the cost of a wrong approach drops dramatically because you can restructure quickly22.
I found that AI made me procrastinate on key design decisions34. Because refactoring was cheap, I could always say “I’ll deal with this later.” And because AI could refactor at the same industrial scale it generated code, the cost of deferring felt low. But it wasn’t: deferring decisions corroded my ability to think clearly because the codebase stayed confusing in the meantime. The vibe-coding month was the most extreme version of this. Yes, I understood the problem, but if I had been more disciplined about making hard design calls earlier, I could have converged on the right architecture much faster.
Tests created a similar false comfort35. Having 500+ tests felt reassuring, and AI made it easy to generate more. But neither humans nor AI are creative enough to foresee every edge case you’ll hit in the future; there are several times in the vibe-coding phase where I’d come up with a test case and realise the design of some component was completely wrong and needed to be totally reworked. This was a significant contributor to my lack of trust and the decision to scrap everything and start from scratch.
Basically, I learned that the “normal rules” of software still apply in the AI age: if you don’t have a fundamental foundation (clear architecture, well-defined boundaries) you’ll be left eternally chasing bugs as they appear.
The takeaway for me is simple: AI is an incredible force multiplier for implementation, but it’s a dangerous substitute for design. It’s brilliant at giving you the right answer to a specific technical question, but it has no sense of history, taste, or how a human will actually feel using your API. If you rely on it for the “soul” of your software, you’ll just end up hitting a wall faster than you ever have before.
This type of post is one I’d like to see more of, that of describing how people are using AI to build real systems. I’ve no background or experience in a lot of what was mentioned but this is a very good piece. There’s certainly pitfalls of AI and learning how to use it all properly is a skill in of itself. Relying on it too much for things it is good at can lead back to poor consequences in the first place. For example the fact it is good at refactoring can mean we defer lots of decisions to a later date with the expectation that we can easily change it. But those little things all add up to a much bigger issue that we get overall stuck on in other and new ways.
And 100% the insight that normal rules of software still apply. I’m finding this is more and more true as I read and write more.