A Year of Mornings

On AI Coding and Its Discontents - Cal Newport

“Writing your own code, slowly but surely, and using LLMs for narrow or particularly annoying tasks (say like writing tests or throw-away scripts), is the best way to produce the highest quality code, since it’s the only way to properly understand it.” […]

This last year has been exhausting. The PR departments of the frontier labs have done an excellent job convincing us that AI developments are occurring at an astounding, world-changing rate. But if you zoom out, it becomes clear that almost every “breakthrough” since last summer has concerned the narrow domains of computer code and math, which are defined by highly structured languages and come accompanied by massive amounts of specialized training data.

And yet, even in this best-case-scenario setting for AI, we’re still struggling to figure out how to actually use these tools in a way that makes sense in the long run.

Writing production code is tricky in that it can not fail. In this engineer’s case it broke production twice.

The thesis of this article is that it’s ok to use AI to write code, which if it breaks does not cause to too much of an issue. Which has been my experience too. I have primarily used Claude to build personal tools, and my website and some scripts and what nots at work. Also, how much of code out in the world is truly code that can not break?

But I know of people who are talking to their agents and having it build things.

The one thing I agree with is - that we are all trying to figure out the steady state of using AI in development work.

Give me one reason by Seth Godin

The honest rejections would say something like, “my boss didn’t like you,” or “I was in a bad mood,” or “we realized that our spec wasn’t very clear and the person we liked didn’t fit it either,” or “we wanted someone who looked more like us,” or “your competence made us nervous,” or…

Take what they wrote and replace it with “no.”

It’s a short read. And I just wanted to share it.

How I use LLMs to learn complex topics · Laurentiu Raducu by Laurentiu Raducu

While I was analyzing new AI bottlenecks that might slow down data center buildup, I realized there are many aspects of chip production that I do not know. Surfing the web, I asked myself what if there would be a game to get you through the process of building a chip at a fab? For sure learning this way will stick, since you can map concepts with objects within the game.

I have my own systems built by Claude to learn and now remember stuff. This was interesting as well.

Defending my own brain against enshittification

His days are punctuated by cups of coffee and tea at strict intervals, cigarettes, ironed sweater vests, empty time for deep thinking, placing a bench outside his office for passersby each day, and most notably, when he arrives at his office at 10 am alone, he opens all the windows in the building and says good morning to the ghosts who live there.

Lovely story.

Oooohhh Summer, How Much Risk Is a Useful Amount of Risk? by Craig Mod

The world doesn’t need a park that bans rollerblading. It needs one that bans smartphones.

Oh yes it does.

The other takeaway from Matthew’s talk was people tend to “report” stories rather than tell them. So they report what happened and what was said, but they leave out what they a) thought, and b) felt. Add those two in and you’re doing better than most.

I’m trying to do the second part more in my nordletters.

On building scalable control planes by Dr Werner Vogels

One thing the team talked about constantly, almost to the point where it became a mantra, was that no matter what happens to the control plane, VMs that are already running need to keep working. We call this static stability, and it sounds obvious because of course running VMs should keep running. But at scale, obvious things are the hardest to protect, because every new feature, every change, every dependency is a chance to accidentally violate that guarantee. Maintaining it is the difference between an outage where customers can’t launch new resources and an outage where everything stops. Both are bad, but the second is catastrophically worse. The fact that EC2 was statically stable gave me some comfort in my early days.

Such an insightful post. I come from the context of servers having memorable names, sure a large infrastructure (4000+ servers) but still a context where you ssh to servers and fix them if they go down.

How I write by Murat

Since writing is also a tool, the advice on honing your tools also applies to writing. The best way to get better at writing is by writing a lot. Write daily. By writing a lot of bad prose, you will eventually learn how to write better and get more comfortable with writing. Take every opportunity to write. Maintain a blog. Read a lot. All the while, be mindful of your writing. Always consider how you can improve it further.

I feel like I’m at a place with my writing where I know how I write. But still I find these sorts of posts interesting, where people talk about the craft of writing, the tools they use and so on.

I want to be a better writer after all.

Murat is someone I was not following before. I came to know about them through this write that blog series, which I came to know after Simon Willison linked to his interview with Write that Blog.

I have several unlinked notes on writing, maybe this is a signal for me to create a common note.