







One of my biggest weaknesses as a software engineer is procrastination when facing a new project. When the scope is unclear, I have a tendency to wait until I feel I’ve “felt out” the problem to start doing anything. I know I’ll feel better and work much faster when I get “stuck in” but I still struggle with that first step, overcoming the “activation energy” required to engage with the details. LLMs have been a game-changer for me in this respect: I can just throw a couple of sentences at them with the shape of the problem. This leads to one of two outcomes: The LLM comes up with a good solution, usually in a slightly different way than what I was thinking. I realize “oh wow the solution is much simpler than I thought”. Straight away I start thinking about the consequences of implementing and improving what the LLM suggested. The LLM comes up with a solution that I intuitively recognize as “wrong”. My immediate reaction is frustration (“How could it get it so wrong”) which leads me to go back and forth with the model, explaining to it why its solution could not possibly work. But in the process of arguing with the model, my brain is churning away and generating variations or different approaches that could work. After a while, even if the AI is still on the wrong track, the debate will trigger a moment of inspiration where suddenly the solution will come to me. I’ll excitedly start up a new conversation and start working through it with the model. The key is the emotional reaction I have immediately to the LLM’s response, either excitement or frustration. By harnessing this immediate feedback loop, I get my brain out of its passive, procrastination mode. It’s almost like a jolt: either I’m thrilled because it’s simpler than I thought, or I’m spurred to action by the urge to correct a perceived ‘wrong’ answer. This forces me to engage with the problem in a meaningful way.
Reducing the cognitive load of AI changes
When reviewing large amounts of AI-generated code, I often find that the LLM chooses terms for abstractions that do not always map to my own choices. For instance, what it may call a MutationIntent might personally be more natural to me as an EditRequest. Because the LLM's choice of words is not my ideal choice, I have to do a mental lookup of what it means every time I see it, which adds cognitive load.
Rotating the Space: On LLMs as a Medium for Thought
An essay on LLMs as a cognitive medium
LLM Neuroanatomy: How I Topped the LLM Leaderboard Without Changing a Single Weight
ML, Biotech, Hardware, and Coordination Problems. Sometimes I write about hard problems and how to solve them.
LLMs and performative productivity
It's worth asking whether LLMs are actually making us more productive at all—and if so, what we might be sacrificing in return.

The peril of laziness lost | The Observation Deck
In his classic Programming Perl — affectionately known to a generation of technologists as "the Camel Book" — Larry Wall famously wrote of the three virtues of a programmer as laziness, impatience, and hubris: If we’re going to talk about good software design, we have to talk about Laziness, Impatience, and Hubris, the basis of good software design. We’ve all fallen into the trap of using cut-and-paste when we should have defined a higher-level abstraction, if only just a loop or subroutine. To be sure, some folks have gone to the opposite extreme of defining ever-growing mounds of higher level abstractions when they should have used cut-and-paste. Generally, though, most of us need to think about using more abstraction rather than less.
Systems design 3: LLMs and the semantic revolution
Long ago in the 1990s when I was in high school, my chemistry+physics teacher pulled me aside. "Avery, you know how the Internet works, righ...
I work, I think? - Annotated
How AI may quietly dismantle the feedback loop that turns inexperienced people into competent ones, and why my work matters to me.
The Friction I Don't Want to Lose
I love learning. And while the friction of solving new problems is increasingly traded for speed, the experience gained by overcoming that friction is as important as ever.

AI fatigue is real and nobody talks about it | Siddhant Khare
You're using AI to be more productive. So why are you more exhausted than ever? The paradox every engineer needs to confront.
LLMs reward expertise
In the 2010s, if you had technical gaps (say, you couldn’t write CSS), you had to either rely on a skilled colleague or just hope that the answer to your exact problem was out there on the internet. Today, everyone can write sort-of-okay CSS by delegating the task to an LLM. LLMs make everybody into a generalist.

The Human-in-the-Loop is Tired
On reward functions, dopamine, and what it actually feels like when the code starts writing itself

Do not give up your brain
It's tempting to just let tools think for you, but you still need to be able to think for yourself and stay sharp.

You don't have to be smart if you can think clearly
When you’re on fire, problems are transparent: they’re solved simply by the act of looking at them. Even complicated layers of multiple problems can simply be glanced through like stacked panes of glass. But nobody can work that way all the time.

Artificial
An LLM is a computer program. We should talk about it like a computer program.

Don't Get Distracted
I’m going to tell you about how I took a job building software to kill people. But don’t get distracted by that; I didn’t know at the time.
