More Work for Father
The tools got faster again. Why is there still so much work?
On 18 September I opened the cloud console of cairn, the knowledge store I built for my agents and me to write into. Two collections. Not three.
The whole Home Assistant and homelab collection was gone. Thirteen pages. No alert. A line in a startup log nobody reads. The system looked healthy, in his own opinion.
I found it because I was testing the thing.
TLDR: That’s the article.
The joke, before it gets old
In 1983 a historian called Ruth Schwartz Cowan wrote a book called More Work for Mother [1]. Washing machines and vacuum cleaners were sold as time saved. Housework hours did not drop. The machines replaced the work of servants and kids and husbands. Then the standard of clean went up to fill the space.
Swap the mother for a guy with too many repos.
In the last few weeks my agents and I made 602 commits across three projects. “Edgar”, the small agent engine I build to learn, went from version 1 to version 4 in a little more than a week.
I have never had this much built for me. I have five projects running in parallel and a list of more. I can’t stop.
Classic me.
An idea I keep having
Humans make tools. That’s the oldest thing we do.
Tools and knowledge grow exponentially. We don’t. We are linear beings running on a brain that was finished a long time ago. So it feels like everything changes and nothing really does. Our ambitions grow as fast as the tools. Our intelligence doesn’t.
In 1925 a biologist called Alfred Lotka had a name for this: exosomatic evolution [2]. Endosomatic tools come with the body. Legs, claws. Exosomatic tools you make. They are not part of you. Animals adapt the slow way, by selection over generations. We adapt by building.
The body did not stop, to be fair. Cooking probably reshaped our guts. Dairy farming changed who can digest milk as an adult. Both layers still run. But the fast one is the tools. It’s the one we steer.
(a thought for later: is AI reshaping us?)
The last time we stopped reading the output
In 1952 Grace Hopper had a working compiler (a program that turns human-readable code into machine instructions). Years later she said: “Nobody believed that. I had a running compiler and nobody would touch it. They told me computers could only do arithmetic.” [3]
In 1957 John Backus shipped FORTRAN. Programmers back then hand-tuned machine code and did not trust a program to write it for them. Backus wrote that they were convinced efficient programming “could not be automated” [4]. His team spent most of its effort on the optimizer, the part that made compiled code almost as fast as hand-written code. That’s how the trust was earned.
Today nobody reads the machine code their compiler spits out. Nobody calls that lazy.
We just moved up one step again. From coding to directing and reviewing.
A tool that made monsters
In 1959 COBOL was designed to read like English, so managers could write their own programs [5]. No more waiting on specialized programmers.
It didn’t go that way. COBOL ran banks and governments for sixty years. Today it’s a language nobody wants to work in. The fantasy of removing technical skill made monsters.
So is AI the next COBOL? Maybe. I don’t know. We will soon see, I guess.
The difference I can see is small and it matters. This time the tool can help fix what it made. As long as the complexity is managed.
What I actually read (it’s not the code)
I read almost none of the code. With exceptions.
Edgar I had to read, because I built it to learn and made it readable on purpose, it was the entire point. The other repos, i guess maybe 5%.
What I do read is everything around the code. Every question the agents ask me. Every task review and sprint review. Every postmortem. Every thread on a feature or a bug. Edgar alone has 68 ADRs (architecture decision records, one short file per design decision, with the why in it).
That’s where I use my judgement.
Software development is complexity management.
The Logistics of Ideas
Dijkstra said it in 1970: “The art of programming is the art of organizing complexity” [6]. Fred Brooks split the work in two in 1986 [7]. The essential part is deciding what to build. The accidental part is the labour of building it.
I agree with every line.
(another thought: AI is picking up the accidental part.)
If complexity is managed correctly it doesn’t really matter how the code got written. It can be fixed.
If you know it’s broken.
Job number two is tester
Back to the missing pages.
cairn keeps its data safe by streaming a copy to cloud storage through a tool called Litestream. On 15 September that stream stopped moving. A stall throws no error. For about 59 and a half hours the copy sat still while the app kept serving from its own disk. Every restart after that rolled back to the stale copy without a word. It turned out to be a known open bug in Litestream, issue #1515 [8].
The agents traced it, wrote it down and recovered the data. Then a fix built from an unmerged upstream branch went in. Its first restore wrote a corrupt snapshot. The safety check did its job and stepped back to an older clean point. Thirteen pages gone. Not the first loss that week. That’s the day I counted two collections instead of three.
A fix that lost data. Reverted the same day. Everything recovered from the copy on my laptop. Three ADRs.
No check caught it. I did, because I was working with the data.
Kernighan and Plauger wrote a statement i love in 1978: “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?” [9]
Now point that at a model. If it writes at the limit of what it can do, the same model is not capable enough to debug it. Somebody has to notice.
So the human in the loop matters more now. Not less.
Job one is directing and reviewing. Job two is tester.
A compiler earned trust by being predictable and checkable. A model is neither, not yet. That’s why I read the postmortems, track decisions, annotate roadmaps.
The operator sets the sign
The last article ended with a promise. Here it is.
These tools multiply. A multiplier does nothing to a small number. And it has a sign.
Engage with it. Read the decisions, use it. It multiplies you.
Offload to it. Hand over the thinking, stop looking. It divides you.
Same tool. Opposite results.
The research on automation says the same. Complacency hits experts too. Practice alone does not fix it [13].
It’s an old worry. Plato has a king warn that writing will give people “the appearance of wisdom” and not the real thing [12]. He was half right. Writing made us smarter as a species and let a lot of people look smart without being it.
Think of an architect with a crew that builds anything, fast. A good drawing gets built early. A bad drawing also gets built early. The crew never tells you the drawing is wrong.
The pitch says these tools close the gap between the expert and the beginner. I see the opposite. I think the gap is getting wider. Faster than ever.
What I am probably getting wrong
A lot. As usual. But this is how I learn.
The measurements are a mess. METR ran the best known trial in 2025 and found experienced developers 19% slower with AI while they believed they were faster [10]. Sixteen developers, early 2025 models. In 2026 they tried again and the study broke. Developers in the research refused to work without AI. Between 30 and 50% avoided submitting tasks they expected AI to handle well [11]. (And beware the research is also quite unscientific in itself, the numbers are unreliable in both directions).
Mine too. More than 1,400 commits in a month, across all my repos, is output. Value is another question. One guy is not a sample. N of 1 is not real research.
And “you can always fix it” is exactly what a monster says right before it eats you. It held this time because I happened to look.
Where I would start
- Make the agents write every decision down. One short file each, with the why. Read those, not the diff.
- Ask for a postmortem on every bug. Even the small ones. Especially the small ones.
- Use what you build. Daily. You are the sensor nobody wrote.
- Keep one copy that doesn’t go through the clever path. Mine was sitting on my laptop and it saved me more than once.
The tools got faster.
The work got bigger.
Somebody still has to look.
TL;DR New tools raise the ambition faster than they cut the work. We evolve through what we build. Lotka called it exosomatic evolution. The tools now grow much faster than we do. The job moved up a step, from coding to directing and reviewing, the same move compilers forced in the fifties. Software is complexity management. The code can always be fixed, if somebody notices it’s broken. So job number two is tester. My agents lost thirteen pages of my data. No check caught it. I did, because I was using it. The tool multiplies whoever engages and divides whoever offloads.
And if you have the time read the books I linked, great stuff written by the giants on whose shoulders we stand.
Try it. Paste this into whatever agent you build with:
From now on, for every change you make:
1. Write a short decision record: what you decided, the options you rejected, why.
2. After every bug, write a postmortem: what broke, how it was found, what stops it next time.
3. End every session with a review: what changed, what is untested, what I should try by hand.
4. Tell me the one thing I should use today to check it still works.
I will read these instead of your code. Write them for a person, not for a compiler. Be concise, write like I am 12.Most of the work is already done. You just have to read it. And then use the thing.
References
[1] Ruth Schwartz Cowan, More Work for Mother: The Ironies of Household Technology from the Open Hearth to the Microwave, 1983. https://hss.sas.upenn.edu/content/more-work-mother-ironies-household-technology-open-hearth-microwave
[2] Alfred J. Lotka, Elements of Physical Biology, 1925, on exosomatic instruments. Discussed in: https://www.sciencedirect.com/science/article/abs/pii/S0921800915004243
[3] Grace Hopper, quoted in the OCLC Newsletter, March/April 1987. https://cs.yale.edu/homes/tap/Files/hopper-wit.html
[4] John Backus, “The History of FORTRAN I, II, and III”, 1978. https://softwarepreservation.computerhistory.org/FORTRAN/paper/p25-backus.pdf
[5] “It’s COBOL all the way down”, Increment. https://increment.com/programming-languages/cobol-all-the-way-down/
[6] Edsger W. Dijkstra, Notes on Structured Programming, EWD249, 1970. https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD249/EWD249.html
[7] Frederick P. Brooks, “No Silver Bullet: Essence and Accident in Software Engineering”, 1986. https://www.cs.unc.edu/techreports/86-020.pdf
[8] Litestream issue #1515. https://github.com/benbjohnson/litestream/issues/1515
[9] Brian Kernighan and P. J. Plauger, The Elements of Programming Style, 2nd ed., 1978, chapter 2.
[10] METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, July 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
[11] METR, “We are Changing our Developer Productivity Experiment Design”, February 2026. https://metr.org/blog/2026-02-24-uplift-update/
[12] Plato, Phaedrus, 274b to 277a. https://newlearningonline.com/literacies/chapter-1/socrates-on-the-forgetfulness-that-comes-with-writing
[13] Raja Parasuraman and Dietrich H. Manzey, “Complacency and Bias in Human Use of Automation: An Attentional Integration”, Human Factors 52(3), 2010. https://doi.org/10.1177/0018720810376055