The essay's core move is a role reversal: instead of the now-standard workflow where the human writes a spec and the agent codes, the author insists the human codes and the agent does everything else — planning, research, bookkeeping, cleanup. It's a simple inversion, but it cuts against the entire thrust of how AI coding tools are being marketed and adopted. The argument is that if you hand over the actual writing of code, you lose three things simultaneously: the pleasure of the craft, your understanding of the codebase, and your skill over time. The author, a self-identified Haskell programmer, is honest about where this perspective comes from. If you enjoy the act of writing code — the expression of thought in a language you've chosen — then delegating that act to a machine is giving away the best part of the job and keeping the worst. This is not a universal truth; it's a taste-dependent claim, and the essay owns that. The observation that enthusiasts of different languages have different LLM opinions is one of the sharpest asides here. The practical workflow is laid out with real specificity. Use LLMs for converting conversations into todos, organizing test results into fix plans, and researching your codebase to surface edit points. But when it's time to write, you write. The agent becomes a well-briefed junior colleague who prepares your desk, not one who sits in your chair. The essay explicitly warns against the trap of watching agents work — make coffee instead, or better, do your own parallel research so you're never dependent on the agent's version of reality. There's a GAN analogy buried in the review-cycle section that deserves more development than it gets. The idea of treating the human as discriminator and the LLM as generator is structurally sound, but the essay cuts off before fully working through the implications. The section on when agents are useful for coding — FIXMEs, boring adaptations, library swaps — is practical and honest, and includes a genuinely useful caveat: if you're asking an agent to write seven variations of the same case, you should probably be abstracting instead. The weaknesses are scope and evidence. This is one programmer's workflow, presented as advice, with no data on whether the productivity claims hold up. The Haskell-specificity is both the essay's charm and its limitation — the argument that writing code is enjoyable assumes you're working in a language where that's true, which the author acknowledges but doesn't resolve. The essay also doesn't engage with the counterargument that for many developers, the boring parts ARE the code, and the interesting parts are the architecture and product decisions. What lands is the emotional honesty. The opening paragraph names the actual anxieties — burnout, job loss, code quality degradation, loss of ownership — and the essay addresses them without either dismissing them or catastrophizing. The advice to make agents group around your way of working, rather than reshaping yourself around the agent's preferred workflow, is the kind of sentence that sticks.
