Manuel Bärenz writes Haskell for a living and says the writing is the part he actually enjoys. He noticed that enjoyment starting to disappear under agent-assisted work, and wrote down the workflow he built to get it back. His answer is not abstinence — it is to let the agents do nearly everything except the coding.

He is honest about the payoff: “maybe twice as fast.” That is well below what the loudest vibe coders claim, and he is fine with it. His metaphor is a gardener using gentle organic fertiliser while the vibe coders drown their fields in industrial chemicals.

What the workflow actually says:

  • Keep writing code yourself. If everything is generated, the codebase becomes “an LLM wasteland that only your coding agents can thrive on.” Skills decay fast, because the threshold for handing work over is so low — a few weeks without coding is enough to notice.
  • Distrust generated code more than the marketing does. LLMs are “way worse at producing good, human-readable code than advertised.” They cope with code only they will maintain; they fail at code a human has to debug later, because the file reads as an alien landscape.
  • Delegate the boring parts, not the thinking. Planning is bookkeeping — turn conversations with domain experts into todos, have test results organised into a fix plan. Make the agent write its research down with links to the sources it used; when it later proposes something odd, ask which resource said so: “50% chance says it will discover its own mistake.”
  • Make it ask you. It should not make the crucial decisions. If it hands you a question you cannot act on, that is its failure to supply context, not yours.
  • Plan together, then you write the code. The line he calls the game changer: “The typical coding harnesses lure you into ‘plan first, then let the agent code’. Refuse.” The agent tells you the current todo, which files need touching, what the pitfalls are — and you type. His report: “I’m enjoying my work. Sometimes even more than before LLMs.”
  • Never read an LLM artefact without an automated review pass. Borrowed from the GAN trick of pitting a generator against a discriminator: work is only fit for human eyes once a reviewer agent runs out of findings. He points that at his own hand-written code too, and says it regularly catches a real bug.
  • Prefer smaller models. The fanciest ones burn the most tokens and may not survive the session, and a workflow that does not need frontier models can eventually run on open weights — “and not be dependent on technofeudal lords at all anymore.”
  • Treat a dead token budget as a service outage, not as “I bought too few.” The vendor sold you a promise and did not keep it, and the ceiling can move without notice. The practical response is the one you use on a plane: cache what you need in advance and always keep a planned backlog of todos you can work through offline.
  • Do not send fully generated PRs. Model prose is a tool output, not communication — append it in a collapsed block if at all. He says he did this once by accident and the other person was rightly fed up.
  • Watch your head. “Treat LLM gibberish as potentially harmful for your psychic health. Don’t consume to much of it.”

That is the whole point of the piece: not a productivity boast but a working arrangement for someone who wants to stay a programmer. His stated bar for being replaced is correspondingly high — models would have to be many times better than a human developer, use fewer resources, be more reliable in messy real-world situations, be at least as well aligned, and be accountable for what they produce.

The 214-comment thread on Hacker News argues with the premise from both directions, and supplies the detail the post leaves out: what actually goes wrong when you hand over the keyboard.

What the thread adds

  • matsmann — the inversion that explains how a personally satisfying workflow can still be professionally miserable: “What has made me enjoy it less, is having to deal with colleagues’ use of it. Sorry to say, but I don’t enjoy talking to meat proxies, or getting huge PRs that solve the wrong problem. It’s like half the people have turned off their brain. We produce faster, but we don’t produce the right stuff.”
  • beej71 — the skill-atrophy claim with a receipt attached: “…suddenly I had trouble planning out the architecture for a very small project… I thought maybe I would go to Claude and help get some ideas. But then I stopped myself… I got out a piece of paper and I scribbled ideas until the dam burst and suddenly the entire design was obvious… It took about 5 minutes. But those were an alarming 5 minutes. It was like I’d gone blind to the solution.”
  • cautiouscat and humlex — the same countermeasure, reached independently by two commenters: stay in the loop by using smaller and faster models instead of agent swarms. cautiouscat: “When I experimented with swarms it would spend an hour just having agents adversarially review to decide some pretty trivial details… I have way more connection to my work.” humlex uses a fast low-reasoning model for the same reason — “i can still have hands on the entire time and dont have to wait around for 20minutes for it to finish up and have made a bunch of decisions without me.”
  • superjose — the delegation that did work, and it is not coding: pointing an agent at a read-only production replica to check that the code matches real data shapes, where “it has caught a few misnomers”; using logs and commit history to debug low-impact production issues; generating tickets. For code itself: four weeks of scrutinizing every frontier-model decision and pushing back on many.
  • chicken-stew — skepticism aimed at the genre rather than the workflow: nothing but buggy or red-flagged generated code, and “I constantly read these amazing stories of people vibe-coding some firmware/driver that just works, and honestly I’m starting to question whether I’m reading the posts of some promotional bot.”
  • visarga — direct dissent on the post’s central premise: keeping your capability for hand coding “is not going to help as much as you imply. How many people know how to ride a horse today, or routinely multiply large numbers by hand.” The skill that matters instead: knowing the blind spots and failure modes of coding agents well enough to still get code you trust.

Where the workflow meets other people

The post’s advice assumes you own the repository and the review process; several commenters point out it does not survive contact with an organisation that does not. nlnn: “This is great for personal projects, but at work chances are someone will have completely rewritten/refactored/rearchitected everything I’d built up a good mental model of next time I blinked.” lolakutty describes the compounding version — commit a bad decision, work around it in the next PR, then work around the workaround, until “manually reviewing the changes becomes impossible because you have to reason about the changes keeping all the workarounds and special cases in your mind.” jemiluv8 adds the market version: the open-source bounties that funded his own early work (“roughly $300 per month… ranging from $50 to $350”) dried up once small tickets became one-shot prompts for frontier models.

Reading notes: HN handles are pseudonymous and the site publishes no per-comment scores, so the ordering here is HN’s own ranking, not a vote. This is a slice of the thread, and the disagreement about whether hand-coding skill is worth defending is quoted as a disagreement.