Hayati

Posted on Nov 1 Originally published at hayatibis.dev

It's not a sprint, it's a marathon

#softwareengineering #ai

Originally published on hayatibis.dev, where the figures move and the toys are interactive.

Years ago I had English practice sessions with a British friend, Andrew. After the second one I told him I didn’t think I’d reached the level I wanted. He said: “It’s not a sprint, it’s a marathon.”

It stuck with me, because it’s true for most things in life. Learning a language, sport, a career. It’s also true for software, which is funny, because software named its steady unit of work after the dash.

The irony in the word “sprint”

The Scrum Guide, the short official definition of Scrum by its two creators, says: “Sprints are the heartbeat of Scrum, where ideas are turned into value.” They are “fixed length events of one month or less to create consistency.”

A heartbeat is the opposite of a sprint. It’s the pace you keep for your whole life. The name is a sprint, but the definition really describes a rhythm.

The Agile Manifesto had already said it plainly in 2001: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

These days we’ve left Scrum and the agile ceremonies behind and work from a kanban to-do board. The name on the board changes nothing, though. We can’t work day and night under any method. What I want is systems that protect the balance between work and life, and that can also protect themselves without someone standing over them.

What a marathon pace looks like

The example I can show is this site. One essay a week, Sunday morning, not five in a burst. The Sunday run starts at 09:07 on its own, rebuilds the site and sends the copies out. If a draft still has a gap in it, the production build refuses to ship it. Nobody has to be awake for that.

That’s what I mean by a system that protects itself. It isn’t my willpower that keeps the pace, really; it’s the parts of the system.

Illustrative numbers. A small mill engine with a Watt flyball governor. Turn up the steam, the way agents push harder, and with the governor on the balls swing out, lift the sleeve, and the bell crank and the long drag link close the throttle: the flywheel only goes from 60 to 71 or 74 rpm. Take the governor off and the same push runs it up to 300 rpm; at 1,200 the flywheel and the arms can’t hold, and the engine flies apart. Nobody stands at the valve; the parts keep the pace. The drawing turns at half speed, and past a point it can’t show how fast. (interactive version)

Agents never get tired

Andrej Karpathy wrote a long set of notes in January after weeks of coding with Claude. One part is about tenacity: “They never get tired, they never get demoralized, they just keep going and trying things where a person would have given up long ago to fight another day.” And then: “You realize that stamina is a core bottleneck to work and that with LLMs in hand it has been dramatically increased.”

So the agent can sprint all day. We can’t, and the work we keep is exactly the part that needs a rested head: reading, reviewing, deciding, owning the thing next year.

We have to move at the speed agents produce, but at a speed we can accept, and without breaking the systems they touch. That means stopping the agent’s mistakes before they reach anything, instead of catching them by hand at midnight.

Karpathy names those mistakes too. “The most common category is that the models make wrong assumptions on your behalf and just run along with them without checking.” They overcomplicate, bloat abstractions and don’t clean up dead code. Forrest Chang turned these notes into a single CLAUDE.md that you can install as a Claude skill[1]. It’s a small file, and it does the standing-over for you.

But the point isn’t only the code. A healthy setup is an orchestration: instructions the agent reads, tests that pin behaviour, a gate before production, a schedule, and a person who reviews at a pace they can keep. Each part is healthy on its own and they work together. Take one out and the others have to sprint to cover it.

The work didn’t shrink

Since agents came into our lives, our workload has gone up enormously. We still have to stay regulated and keep to a sustainable level. I’m not the only one who sees it.

Aruna Ranganathan and Xingqi Maggie Ye studied 200 employees at a US technology company from April to December 2025 and wrote it up in Harvard Business Review as “AI Doesn’t Reduce Work—It Intensifies It”. They saw people “manually writing code while AI generated an alternative version, running multiple agents in parallel”. The result was “a continual switching of attention, frequent checking of AI outputs, and a growing number of open tasks.”

Karpathy says the same about himself: “the main effect is that I do a lot more than I was going to do”. Simon Willison, a survey of 442 developers and Google’s DORA report land in the same place: the output goes up, so does the load, and AI amplifies the strengths and weaknesses a team already has. A team that already sprints will sprint harder.

Every developer is a condom now

In July a joke went around X. Ariel Kwiat wrote:

𝕏Ariel @ArielKwiat (interactive version)

Within a day other engineers were saying it about their own agents.

It’s funny because it’s half true. We are the thin layer between what the agent writes and production. But a condom you have to put on by hand, tired, at one in the morning, is not a great protection plan :) I’d rather put that layer in the system: the skill file, the tests, the gate. Then the human can review on Monday morning, rested. And with workflow engineering, a world is coming where we aren’t the reviewer at every stage. By then the protection has to be in the system already.

A paper is going around X these days as the death certificate of programming. Its first title really was “The End of Software Engineering”. Six days later its author, Zhenfeng Cao, renamed it “Agentic Software”, and the conclusion now says: “The old software engineering is not ending; it is growing into something larger.” The core idea is still close to mine, though: human capacity for complexity is “essentially constant”, code becomes “a transient artifact”, and people become “intent architects, agent coordinators, and outcome auditors”. Writing code has stopped being human work; what’s left is intent, and running a system that stays healthy. The EvoClaw result the paper cites backs that up: agents’ scores drop “from >80% on isolated tasks to at most 38% in continuous settings”.

AI really has changed our work, and there’s no point pretending it hasn’t. Building and running that system will be the job of the professionals in that field, until AI takes this work over too.

Back to the second lesson

Andrew was right after the second lesson, and he’d be right after the second week with a new agent too. What pace could you keep for a year, and which part of your system keeps it when you’re not looking?

Stands on

Notes

It has four rules: think before coding, simplicity first, surgical changes, and goal-driven execution (“Define success criteria. Loop until verified.”).

A new essay every Sunday: get it by email. If you'd like more of these, you can support the writing on Patreon, or buy me a coffee once.

DEV Community