Writing Code More Slowly with AI as a Part-Time Go OSS Maintainer

This morning's research log surfaced nolanlawson's "Using AI to write better code more slowly." AI coding is almost always framed as a tool for going faster. This post flips that premise and argues for deliberately using AI slowly, to raise the quality of the code instead. Reading it, I felt this lands hardest on the part-time indie developer — the one with the least time to spare — because the pull toward speed is stronger there than anywhere else.

The "speed tool" framing is where it gets dangerous

The core of the article is the claim that the bottleneck in good software isn't typing speed but the speed of understanding. When you have AI generate code and accept it as-is, you do get faster — but that speed is, flipped around, the speed at which code you don't understand piles up. The author's proposal is to use AI as a reviewer and an explainer rather than a generator, tilting it toward reinforcing your own understanding. The idea is to invest AI not in the time spent writing code, but in the time spent understanding it. In practice that means the win shows up not in the diff you ship today, but in how fast you can move through the same module a month from now, when the context you skipped past has long since evaporated.

What stings for me is that the pull toward speed is structural. On weekdays I have a day job doing contract development, and the time I can give to OSS is the limited stretch of nights and weekends. Under that constraint, "let AI write it, and if it runs, move on" looks like the shortest path. But with an OSS library like gpdf that other people import and depend on, the gap between code that appears to work and code that is actually correct comes straight back to me as an issue.

When you ship OSS part-time, the quality debt always comes due later

gpdf is a Pure Go, zero-dependency PDF library; I shipped v1.0.0 in March 2026. If I let AI write something like CJK font subsetting in one pass and call it done because the tests pass, I will almost certainly hit a wall later. Font specs are a pile of exceptions, and it is not unusual for the tests that pass to cover only a sliver of the spec. Use AI purely for speed here, and code that runs without being understood accumulates — until, six months on, I can no longer read my own code. The asymmetry matters: writing it fast is a one-time saving, but reading it back is a cost I pay every time the issue tracker lights up.

So lately, before I ask for an implementation, I ask the AI first: why does this code work the way it does, and which parts of the spec does this implementation not touch? Explanation before generation — that is the order. What the article calls "using it slowly" landed, in my context, as exactly this swap in ordering. The typing itself does not get faster, but the speed of understanding, the part that pays off later, does — or so it feels.

If you don't make "slow" a rule, speed wins anyway

Trying to use AI slowly through willpower alone fails the moment time runs short; you drift back to the fast path. So I have chosen to bake the way I use AI into the process itself. Concretely, the rule is that pre-release validation never gets to lean on an AI review alone. After I have had the AI explain things once, I run the benchmarks and the edge cases by my own hand. This two-stage setup is contiguous with the process I wrote about earlier in my pre-release validation strategy; adding AI did not change the skeleton.

Put the other way: if you add AI without changing your time design, the time you free up gets absorbed straight into "ship even faster." Where you put the hours AI frees up is exactly the question I raised in the daily time design of a day-job OSS builder. Whether you can route your new writing speed back into understanding is decided not by the tool's performance, but by where you place the time.

Common questions

For a part-time dev, isn't faster just the right answer?

For day-job code with deadlines, there are plenty of situations where speed is the right answer. But the OSS I maintain alone is a different case, because the one paying the maintenance cost of fast, opaque code is also just me. On a team, someone else can shoulder the understanding; alone, the understanding debt all comes back to me. So for OSS specifically, I think using AI slowly and leaving understanding behind is, over the long run, the faster path. The math only inverts when nobody but you will ever have to open the file again — and for a library other people import, that day never comes.

Other notable reads today

• Language Models Need Sleep (arXiv / Hacker News) A paper proposing a sleep-like consolidation phase that converts an LLM's short-term context into persistent weights. The framing of AI memory management as "consolidation" is a genuinely interesting angle.
• Does anybody actually like React? (Hacker News) A longtime React developer argues there are many reasons not to use it and no reason to, dissecting how network effects distort tech selection. Having built nadai.dev on Vue, this wasn't someone else's problem to me.
• The User Is Visibly Frustrated (Hacker News) Argues the paradox that AI agents "acting human" actually breeds frustration, and proposes leaning deliberately into a robotic UI instead.
• Ferrari Luce (Hacker News) Ferrari's first EV, designed by Jony Ive and Marc Newson, drew attention for an interior that drops touch-maximalism and returns to physical controls. Reads as a case for re-examining the value of physical UI.
• Uber COO says AI spending is getting 'harder to justify' (Fortune / Hacker News) Uber's COO says the annual AI budget ran dry in April with no visible causal link to more useful consumer features, casting doubt on AI's cost-effectiveness. Contiguous with this morning's main topic.
• Netherlands blocks US takeover of vital digital supplier (Politico EU / Hacker News) The Dutch government blocked, for the first time, a US acquisition of Solvinity, the cloud behind DigiD. Data-request risk under the CLOUD Act is becoming a wall for public-infrastructure M&A.

Next time I touch gpdf's font code, I plan to start by having the AI explain the spec before I let it write anything. I'll leave the speed to the day job, and keep the understanding in the OSS.