GitHub is down again? Oh boy, it has a scalability issue, you might say. I say your coding agent may be to blame, and thus may be you should take responsibility? The platform is buckling under a weight it wasn't designed to carry. We've seen downtime, API timeouts, and "maintenance mode" messages since its inception, but we have not seen them as frequently as we have since November 2025. (Does this month ring a bell? It is when Anthropic released Claude Opus 4.5, which wowed all of us with its complex code generation capabilities.)

The mainstream narrative blames "infrastructure scaling" or "unexpected coding party traffic spikes." But the real culprit is staring us in the face: the explosion of agentic AI.

We are no longer just seeing human-paced code commits. We are seeing AI agents generating thousands of API calls per second—opening PRs, commenting on issues, and pushing commits at machine speed. GitHub, the world's primary collaboration tool, is being swamped by a flood of low-value, automated noise.

Before we talk about engineering, we need to talk about quality. "AI slop" isn't just a buzzword; it's a systemic degradation of our codebases and our learning processes.

Agentic AI makes it too easy to generate working demos. It's incredibly easy to spin up a project that looks impressive in a 30-second TikTok video. But when that project hits a real codebase, it becomes unmaintainable vaporware.

The internet is clogging up with boilerplate PRs, automated dependency updates, and "AI-written" refactorings that no human actually reviewed. We are seeing a shift from writing software to reviewing AI output, and the latter is a fundamentally passive, low-value activity.

So, how do we fix GitHub's backend crisis?

A naive solution is simple rate limiting: "You can only make 100 calls per hour." But smart AI agents will just hit that limit faster or spin up more parallel threads to compensate. Throttling a dumb agent just creates a "thundering herd" effect.

The real solution is organization-level flow control via hard queueing.

GitHub needs to implement an intelligent queue system per organization. Every API call (PR creation, issue comment, commit push) should go into a queue that enforces a thinking delay.

• Burst Limits: "Your team just pushed 50 commits. The next 50 must wait 10 seconds."
• Exponential Backoff: "You've generated 5 PRs in a minute. The next one must wait 10 minutes."

This isn't just about server load; it's about forcing a pause.

When an AI agent tries to "slop" a project, the queue forces it to sit on its hands. It breaks the agentic loop. It turns a 2-second generation cycle into an overnight batch process. It forces developers to check the logs, read the diffs, and actually collaborate before the next burst of commits is allowed through.

Here is the counterintuitive truth: We need GitHub to be slower.

When you write code manually, you understand the architecture. You feel the pain points. You learn the library. When AI writes it for you, you just review it. Reviewing is passive; writing is active.

By enforcing hard queues and flow control, GitHub can become the "Great Filter." It can force a friction point between generating code and shipping code.

• Real Software vs. Demos: Vaporware thrives on speed. Real, maintainable software thrives on deliberate thought. Slowing down the API forces the agent (and its human overseer) to think before they commit.
• Learning vs. Generating: If the platform forces you to wait 10 minutes between bursts, you might as well use that time to read the documentation. You might as well write the next function yourself to see where the AI got stuck.

Let us face it. GitHub is the world's source control. It is the Library of Alexandria for the software age. It is supposed to be the place where the best ideas in code are preserved, reviewed, and improved.

When AI floods the platform with generative noise, we aren't just filling servers; we are diluting the signal. We are turning a library of human knowledge into a warehouse of automated spam.

We need GitHub to be the library guard. The one who looks at the flood of AI-generated PRs and says:

"Slow down. Read this first. Understand what you're doing. And for the love of code, don't push until you've actually thought about it."

By forcing a slowdown, GitHub doesn't just save its infrastructure. It saves the soul of software development. It forces us to stop slopping and start building maintainable, working software. May be GitHub will not do that but someone should then I will migrate.

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.