Before writing my own, I used Wispr Flow and then the Willow Voice subscription service. Both work fine. I have nothing against either of them functionally. But the frequent updates kept making them more clever in ways I really did not want, and the feature set never quite met my needs. So I started writing my own.

I use VoiceToText for far more than I expected when I started. I compose messages and emails with it. I talk to coding agents with it. I dictate blog post drafts with it.

In fact, this very post started as a dictation. I spoke my raw thoughts into VoiceToText, read the transcript, and proofread it over and over. Then I asked Claude Code to clean it up, with strict instructions: make it idiomatic, give it structure, and do not generate anything I did not say. Which is pretty much the same way I drove it to write the code in the first place.

I think we have been abusing the word "vibe". It is short for vibration, from the Latin vibrare, to shake. Somewhere along the way it came to mean coding by feel: wave your hands at the model, accept whatever comes back, move on.

That is not what I did. This tool was spec'd and engineered, with me guiding every step of the way. I chose the features. I wrote the spec. I set the direction. I rejected code that did not fit the structure and the idiomatic style I wanted, and I drove the AI until it did. None of it was autopilot. I was intentional about the specs, disciplined about the structure, and disciplined about the tests.

What drives a process like that is not a vibe. It is fundamentals, solid understanding, and long years of experience. The engineer is the one driving: setting the direction and managing the entire process. Call it vibe engineering if you like. Whatever the word, the distinction that matters is who is driving.

So is it sloppy? Is it vibe coded? I do not know what those words mean anymore. What I know is that I used a coding agent to build a robust tool that meets my needs exactly, with just the features that I want and none of the distraction or cleverness that I did not ask for. That, to me, is intentional planning and engineering.

Along the way I also used OneLoop, the small coding agent I built myself². How I used it here is a separate post, and I will write about it at some point as a way of showing how I use coding agents in real work.

Short, opinionated, and right about most things. The core idea is Deep Modules: hide complexity behind simple interfaces. This is ETC from another angle. If your module has a complex surface, every consumer pays that tax forever. Make the surface small and the internals can evolve freely. I read it in a weekend. I have been thinking about it for years.

I already thought in systems before reading this. What Meadows gave me was the vocabulary. Stocks and flows. Feedback loops. Leverage points. The places to intervene in a system, ranked from least to most effective. When I write about NixOS or Emacs or OneLoop, I am reaching for these ideas even when I do not name them directly. Short and elegant.

Hamming spent decades at Bell Labs studying what separates great scientists from merely good ones. His central question: why do so few people make significant contributions while so many are forgotten? The answer is mostly about how you allocate your attention and whether you have the courage to work on important problems instead of safe ones. This maps directly to what I wrote about transmittable vs. untransmittable knowledge. Hamming is rigorous, contrarian, and deeply practical.

The best systems engineering book of the last decade. Kleppmann builds from simple primitives (logs, hashes, SSTables) all the way up to distributed systems, always grounding abstractions in the physical realities they paper over. Even if you never build a distributed database, the way Kleppmann thinks will change how you design any system. This book is first principles applied to data.

Interviews with 19 legendary programmers from the 1980s. Bill Gates, Andy Hertzfeld, Charles Simonyi, and others. What makes it timeless is the focus on how they think about problems, not what they built. You start to see patterns across how these minds approach complexity.

I live the Unix philosophy every day. Reading it from the source is different than absorbing it osmotically. Kernighan and Pike do not just describe the philosophy. They demonstrate it, building real tools from shell pipelines, showing how composability creates power that no monolith can match. Every time I write curl | jq or compose tools in Emacs, I am living this book. My OneLoop agent (read, write, edit, bash as four primitives) is an example of Unix way of doing things.

The spiritual ancestor of everything I love about Lisps. Homoiconicity. Functions as first-class citizens. Building abstractions upward from the smallest possible primitives. SICP teaches you to think about computation itself, not any particular language. If you are a Clojure programmer and you have not read it cover to cover, fix that.

Not a software book, and that is the point. Norman's central idea is that good design is invisible and bad design blames the user. This applies to everything from Makefile help targets to agent tool interfaces. Your self-documenting system? Your one obvious path? Your inspectability obsession? Norman gives you the design vocabulary to articulate why something feels wrong and how to fix it.

Weizenbaum wrote ELIZA in 1966, then spent the rest of his career warning about delegating human judgment to machines. He is not anti-computer. He is pro-human. He argues that some things should not be computed, not because they cannot be, but because doing so corrupts the thinking. Reading this in 2026, in the middle of the AI hype cycle, feels like finding a kindred spirit from fifty years ago. This is the philosophical depth behind "the agent is not the point."

The original essay on why adding people to a late project makes it later. But it is really about something deeper: the irreducible complexity of communication and the necessity of conceptual integrity in software. Brooks' concept of conceptual integrity (a system should reflect one set of design ideas, not a committee's compromises) is my oneness principle by another name. The anniversary edition includes "No Silver Bullet," which is even more relevant in the age of "AI will solve everything."

—

These are not the only books I have read. They are the ones I keep coming back to. The ones where I will catch myself mid-conversation reaching for an idea and realizing it came from one of these pages. If you have read them, you know what I mean. If you have not, start with 1, 2, and 9.

I see two extreme positions dominating the current AI conversation, and I think both are mostly emotional reactions to something that deserves clearer thinking.

The first camp says that coding agents will do everything. No more coders. No more software engineers. Massive layoffs are coming. Big names in the industry are declaring the end of programming as we know it. Within this camp, there is a further impulse: stop reading code, just let the agent do it. Accept the output. Move on. Everyone is suddenly talking about "agentic this" and "agentic that" without, in many cases, actually understanding what an agent is or how it works under the hood. The word has become a branding exercise more than a technical description.

The second camp says that AI is fundamentally bad. It steals work. It produces garbage. It makes people dumb. It offloads thinking. It is a threat to the profession and to the craft of engineering. This camp includes engineers I have learned a great deal from over the years, people whose judgment I ordinarily trust. The animosity is real and honest, but I think the conclusion is wrong.

Both camps are having an emotional reaction to a genuine change in the landscape. I understand why. The change is real and the pace is fast. But the framing on both sides is shortsighted. The question was never whether AI will replace you or whether AI makes people stupid. That is the wrong question. It was always the wrong question. The question is: what is this thing actually good for, what does it need to be useful, and how do we harness it in a way that produces verifiable, reproducible, deterministic outcomes?

I did not set out to build a coding agent to prove a point. I built one because I wanted to understand what was actually happening when I used one. I had been using Pi² and Claude Code in my daily work, and I was impressed but also unsatisfied with how much of the process stayed opaque. So I built OneLoop¹.

Here is what OneLoop does: it reads files, it writes files, it edits files, and it runs shell commands. There is an agent loop that assembles a prompt with the conversation history, sends it to the LLM, parses the response, and executes whatever tool the model asks for. The session is a JSONL file that grows linearly. That is the whole thing.

What surprised me was not how complex the agent needed to be. It was how capable the LLM is with just those few primitives. Given the ability to read files and run commands, the model does genuine detective work. It gathers evidence. It recognizes patterns across a codebase. It follows leads from one file to another, from one log line to a stack trace to a root cause. It can narrow a bug from a vague symptom to a specific line of code by systematically reading, searching, and cross-referencing.

That is not magic. It is a small number of durable primitives plus a very powerful pattern recognition engine. But seeing it up close, from the inside, made something click for me. The value is not in the agent as a thing. The value is in what those primitives enable the LLM to do gather evidence so the human can see more clearly.

The LLM is good at pattern recognition across large surfaces. It is good at gathering and synthesizing information. It is good at following a trail of evidence when you give it the tools to look around. It is good at generating plausible code, yes, but that is almost a side effect of a deeper capability: it is good at helping the human gain clarity on the problem.

That is what I keep coming back to. The real value of an LLM in a coding workflow is not that it writes code for you. It is that it helps you see the problem more clearly. It gathers context you might not have the patience to gather. It spots patterns you might miss because you are too close. It follows leads you might not have thought to chase. The code generation is real and useful, but it flows from the clarity, not the other way around.

This is also why the "just let the agent do everything" camp is wrong. If you accept the output without inspecting it, without understanding what happened, without building your own mental model of the problem, you have gained nothing durable. You have a patch that works right now and no understanding of why. That is not engineering. An LLM will happily write and rewrite code to fix one thing while breaking another, over and over, and you should not just accept that cycle without rigor. If you do, there is a term for it: faith-based engineering.

And it is why the "AI is fundamentally bad" camp is wrong too. The pattern recognition is real. The evidence gathering is real. The clarity it can produce is real. Throwing that away because the current implementations are imperfect, or because some of the surrounding hype is ridiculous, is like refusing to use a compiler because you once saw it generate a wrong optimization. The tool does not have to be perfect to be genuinely useful.

I do not want this to read as a cautious "be careful with AI" post. I am genuinely excited about what this enables.

There is so much accumulated waste in our industry. Clunky systems that evolved through years of locally reasonable decisions into globally unreasonable messes. Wrong abstractions that nobody has time to fix. Half-baked integrations, scattered validation logic, unclear ownership, duplicated effort. We all know these systems. We have all worked in them. The problem was never that we lacked the intelligence to fix them. The problem was that we lacked the time and the patience to gather the evidence needed to see clearly what was actually wrong.

That is where the LLM changes the economics. It can gather that evidence. It can read every file, run every test, trace every dependency, and lay it out in front of you. Not so you can blindly accept its conclusions, but so you can think more clearly about what to do. The human judgment is still the scarce resource. The LLM just makes that judgment cheaper to exercise well.

I see a tremendous opportunity to disrupt waste that has been sitting around for years, not because we did not know it was there, but because the cost of understanding it was too high relative to everything else on the backlog. That cost is dropping fast. The question is whether we use that drop to generate more noise or to finally clean things up.

A concrete example. You inherit a codebase and you know there is cruft. It is hazy though. You cannot quite see where the patterns of waste begin and end. There is duplicated logic scattered across handlers, half of it slightly different from the other half, and you are not sure which version is the source of truth. It would take you a full day just to trace all the variations, map the dependencies, and build a mental model of what the code is actually doing versus what the domain needs.

Instead, you ask the agent to read through the relevant files and identify the pattern. It does. It lays out every variation side by side, shows you where they diverge, and highlights which ones match the domain intent and which ones are just drift. Now you can see it. What was hazy is concrete. You did not outsource the thinking — you outsourced the gathering. The judgment about what to keep, what to collapse, and how to restructure is still yours. But the cost of getting to that judgment just dropped from a day to ten minutes.

That is the economics I am talking about. You still have to think. You still have to decide. But you get to do it from a position of clarity instead of a position of exhaustion. And once you can see the pattern clearly, you can guide the agent to clean it up in a way that stays close to the domain — with tests to verify, diffs to inspect, and a clear before and after.

The same applies to building new things. If you can describe what you want with enough clarity — invariants, contracts, tests, acceptance criteria — the LLM can help you get there faster. Not by replacing your thinking, but by amplifying it. The hard part was never the typing. The hard part was always the thinking. Nothing about that has changed.

I think the future of coding agents — and agents in general — looks less like a product and more like a library. Small composable building blocks. APIs, maybe even ABIs³, that expose just enough surface for people to build on top of. Every major platform will roll out their own agent APIs. The winners will be the ones that treat the agent as something you compose and extend, not something you adopt wholesale.

That is the spirit behind OneLoop. It meets my needs because it is tailored to the way I work — my tools, my environment, my workflow. It is not designed for everybody, and I am not pretending it is. When I believe I have hardened the core pieces enough, with clean interfaces so that someone else can pick, choose, and compose their own workflow on top of it, I will open source it. Until then, I might just release it as-is — warts and all — so people can take inspiration, steal what is useful, and build something that fits their own brain.

Because that, I think, is the right shape for an agent. Not a monolithic product that tells you how to work. A small set of composable primitives that you shape around how you already think.

I keep coming back to the same realization. The agent is not the point. It never was.

The point is people thinking more clearly about the problems they are trying to solve. The point is engineering rigor producing verifiable, reproducible outcomes. The point is being able to gain clarity on the actual problem, make sound judgments, and create real value. The point is disrupting the waste and the clunk that has built up over years of shortcutting.

The coding agent is a tool that, built on a handful of small primitives and harnessed with discipline, can help with all of that. But it is still just a tool. It is a very powerful one, and I am excited about what it makes possible, but it is not the thing that matters. What matters is what the human does with the clarity the tool helps produce.

The question was never whether AI will replace you or whether AI will make you dumb. The question is: will you use this tool to think more clearly, build more intentionally, and create more value? That question has always been the right one. The tool just changed.

A coding agent with four primitives is not a limitation in the way it first appears. Most of what a coding agent actually needs to do boils down to reading a file, writing a file, changing part of a file, or running a command. If you can see each of those happen, you can reason about what the agent is doing. If you can script around them, you can make the agent behave the way your project already behaves.

This matters to me because I spend a lot of my time with agents trying to get clarity - building a clearer mental model of a problem before I commit to a direction. That work depends on visibility. What did the agent change? What did it run? What did it see? An agent whose behavior reduces to a handful of visible primitives is much easier to think alongside than one that hides its moves behind a thicker abstraction.

I do not think this is a new insight. Unix made the same bet a long time ago. So did Emacs, in its own way, with text, buffers, processes, and commands. The bet is that a small number of durable primitives plus a programmable substrate will outlast whatever feature-of-the-month the industry is currently excited about. Pi feels like that bet applied to coding agents.

I did not come to Pi looking for a new philosophy. I came to it because it fits two things I already depend on.

The first is Nix. I have written before about why I lean on it heavily⁴. In short, I do not want coding agents mutating my machine. I want them to declare what they need, pull it into an isolated shell, use it, and leave no residue. Pi cooperates with this model very naturally. Because its only way to reach the outside world is the shell primitive, I can point it at nix shell or nix develop and it will happily do real work inside a clean environment. A Rust toolchain, a specific Python, an odd CLI tool for one task - none of it has to touch my base system. When I am done, nothing is left behind except, if I want, a flake.nix that captures what actually worked.

The second is Emacs. I have also written about treating Emacs as a programmable workbench⁵. A coding agent that respects shell and files, and does not insist on its own fancy UI, drops into that workbench without friction. Pi runs in a buffer. As a simple example, I can make it interact with Emacs buffers to persist the commands it ran, so I can come back to them later if I need to.

Those two fits are not accidents of Pi's implementation. They fall out of the decision to keep the primitives small and the surface inspectable. An agent that tried to be a full IDE would not compose with Nix or Emacs this cleanly, because it would be busy being its own environment.

The other thing I like about Pi is that its extension points are honest. When I want the agent to behave differently on a particular project, I do not have to reverse-engineer a hidden system prompt or wait for a vendor to ship a feature. I can add an extension, adjust a skill, or wire in a custom tool, and the change is visible in the same place the rest of the behavior lives.

Here is a concrete example. I wanted a small workflow for myself: whenever I ask one model to brainstorm an idea with me, a second comparable model should immediately review the response and list pros and cons, and optionally a third arbitrator model should weigh in when the two disagree. Useful pattern, but not something any agent I know ships out of the box. I asked Pi to build it for me as a peer-review extension. It did. Now, my brainstorming sessions work exactly as I wanted.

What made that work was not that Pi is clever. It was that Pi ships with documentation and code examples for its own extension points, and those examples are legible enough that the agent could read them and write a correct extension on the first try. I did not reverse-engineer anything. I did not hunt down a third-party tutorial. I just asked Pi to make the extension and it built the thing.

That is the part I keep thinking about. Pi is self-documenting in the same sense that Emacs is self-documenting⁶ - the system knows how to explain itself, to me and to any agent I put in front of it. That property sounds almost unremarkable until you notice how rare it is in modern tooling, and how much friction its absence quietly adds to every customization you try to make.

Pi is not the right answer for everyone, and I do not want to oversell it.

Out of the box, it is minimal. If you want an agent that arrives pre-wired with a dozen integrations and a confident opinion about how your project should be structured, Pi will feel underdressed. You are expected to bring the way you think, work, and taste yourself. That takes some getting used to. It is the same kind of work Nix and Emacs ask for, and it pays back in the same way.

It is also a young project. Rough edges exist. Pi is not the only agent in this minimalist neighborhood either - Aider and OpenCode share a lot of the same instincts, and I think that is healthy. The argument I am making is not that Pi has won. It is that the design pressure behind Pi is the one I want more agents to feel.

At some point I realized I had been talking about Pi's design philosophy enough that I should probably just internalize it the hard way: by building something that takes the same bet from scratch. So I did. I wrote a small coding agent in Rust called OneLoop⁷. Its core is exactly what this post has been describing: four tools (read, write, edit, bash), one agent loop, and a session model that appends linearly to a JSONL file. Nothing else.

I am not bringing this up to announce a project. I am bringing it up because it proved something to me. OneLoop is rough, young, and does almost nothing compared to any "serious" coding agent on the market. And yet I am using it right now - in fact, the flake.nix in the OneLoop repo itself was written by OneLoop. The agent is building its own infrastructure. It works for real work because the model does the heavy lifting, and the agent's only job is to stay out of the way: hand it files, hand it a bash shell, and let it run. When your agent is just primitives and a loop, you do not need much more than that to be productive.

Building it also taught me something I did not fully appreciate from just using Pi. The hard part of a minimalist coding agent is not the agent loop - that is genuinely small. The hard part is everything around it: truncation heuristics so the model context does not explode, sensible output formatting so you can see what happened, session persistence so you can pick up where you left off. Those are real engineering problems. But they are infrastructure problems, not agent design problems, and it is useful to know the difference. Pi absorbs those infrastructure decisions so you do not have to think about them. OneLoop forced me to confront them directly. Both experiences are valuable.

The reason I wanted to write this down is not really about one tool. It is about a pattern I keep noticing in the parts of my setup that have aged well.

The systems I still rely on after many years tend to share a shape. A small number of durable primitives. A programmable substrate. Honest extension points. A willingness to be boring where boring is the right answer. NixOS has that shape at the system level. Emacs has it at the workbench level. Pi showed it to me at the agent level. OneLoop is my way of making sure I actually understand it.

I do not know which specific tools I will be using in five years. I do know that the ones that survive, for me, will look more like this and less like the feature-heavy alternatives that dominate the current moment. That is the real reason I love Pi. Not because it is the final answer, but because it is built in a shape that can keep being useful while the rest of the landscape keeps adding bloated features until it works for everyone - maybe not for you or me.