DEV Community: Hayati

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

Hayati — Sun, 01 Nov 2026 06:33:40 +0000

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.

Make it work, make it right, make it fast

Hayati — Sun, 25 Oct 2026 07:08:54 +0000

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

This line has stuck in a corner of my mind for years. I used to read a lot of Medium posts and books like that, and I’ve shared this order with plenty of people since. When I asked myself where I’d picked it up and when it became a habit, I dug a little deeper and found it credited to Kent Beck. It’s actually older. Stephen Johnson and Brian Kernighan wrote it in Byte in 1983, about C: “the strategy is definitely: first make it work, then make it right, and, finally, make it fast.”

People quote it as three things to do. I read it as an order, where each step has its own definition of done and makes the next one safe.

Fig. 1 · Three gates, each with its own 'done'. Fast is a loop of measuring. The shortcut from working code straight to fast code is the one to avoid. (interactive version)

Make it work

Done means the tests for the behaviour you need are passing. It doesn’t have to be pretty, and it certainly doesn’t have to be fast. It has to be correct, and provably so, because the next step depends on those tests.

Make it right

Now you clean up, and the tests stay green while you do. That is refactoring in the strict sense from principle 01: new structure, same behaviour.

The C2 wiki has a long argument about what “right” means. Some say clean design, others say the edge cases handled properly. I think it’s both: the special cases covered, and code you’d be happy to change next month.

Make it fast

Two people who earned the right to say it have already warned us about this step.

Donald Knuth, in 1974: “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.” The second sentence usually gets left out. Knuth wasn’t against optimizing. He was against guessing where to optimize.

Rob Pike, in 1989: “You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is.” His next rule is a single word: “Measure.”

Try it yourself:

Fig. 2 · An illustrative profile, not a real measurement. The shape is the point: one part overwhelms the rest, and it's rarely the one people bet on. (interactive version)

Once you have a measurement, “fast” becomes a loop: change the hot part, measure again, stop when you hit the target. That last bit matters. Without a target, you never know when you’re done.

Why the order matters

Making something fast before it's right is often one of our most obvious mistakes. Clever tricks on top of messy code may not give you anything useful, and in the next change we end up wrestling with them. Trying to make something right before it works has its cost too: you're polishing something that can't do its job yet, which is about as pointless as polishing a torn shoe.

I went looking for who first said these three steps and ended up with two people writing about C in 1983. More than forty years on, the languages have changed and agents write a lot of the code, but the order hasn’t. When did you last make something fast, and had you measured first?

Stands on

C2 wiki: Make It Work Make It Right Make It Fast
Stephen C. Johnson and Brian W. Kernighan, The C Language and Models for Systems Programming (Byte, August 1983) (1983)
Donald E. Knuth, Structured Programming with go to Statements (ACM Computing Surveys 6(4)) (1974)
Rob Pike: Notes on Programming in C (1989)

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.

Shipping software with a pilot's checklist

Hayati — Sun, 18 Oct 2026 10:05:53 +0000

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

The Model 299, drawn loosely: engines running, gust lock still on. The red streamer is my addition, so you can find the lock. (interactive version)

I love watching Air Crash Investigation, and I’d rather hear it in the Turkish dub than in the original, because of the voice of the Turkish dubbing artist Fatih Özacun. I don’t know where my love of aviation comes from, but I’ve always loved flying, aircraft, air travel, and idly watching a plane heading off into the distance.

This story could have been one of those episodes. On 30 October 1935, at Wright Field in Ohio, Boeing flew the most advanced bomber anyone had built. The Model 299 climbed, stalled and fell. Two of the five people on board died, the pilot among them.

The pilot was Major Ployer Hill, the Army Air Corps’ chief of flight testing. Few pilots anywhere had more experience. He had forgotten one small thing: the gust lock[1] was still engaged. A newspaper called the 299 “too much airplane for one man to fly.”

More training was hard to justify; nobody was going to out-train the Army’s chief test pilot. So a group of test pilots wrote the steps for taxi, takeoff, flight and landing on a card. In Gawande’s account, the 299 then flew 1.8 million miles without an accident, and the Army ordered almost thirteen thousand of them. You know it as the B-17.

Two ways to forget

The 299 shows the first: too many steps for one head. A new system, or a migration on a table you’ve never touched. Nothing is routine yet, so everything has to be remembered at once.

The second is the opposite. The step you have done a thousand times is the one you skip, because skipping it has never hurt. You don’t test the rollback because it worked last time. You assume the flag is off because it usually is.

Both end with a step that only existed in someone’s head. Engineers need a better place to keep those steps than their own memory.

Two kinds of checklist

Daniel Boorman was designing flight-deck checklists at Boeing when Atul Gawande, a surgeon, went to see him while writing The Checklist Manifesto, a book about why checklists work in cockpits and how they could work in operating rooms. The first thing Boorman asks is which kind of checklist you need.

Fig. 1 · Read-do walks the list one line at a time. Do-confirm works from memory, stops at the pause point, then checks. (interactive version)

Read-do: read the line, then do it. This is for things you do rarely and under stress: the incident runbook, the database restore. You are not expected to remember; you are expected to follow.

Do-confirm: do the work from memory, then stop and check it against the list. This is the pull request template and the release check. It trusts your skill and catches the slip.

Software checklists often fail by being the wrong kind. A pull request template written as twelve numbered steps is a read-do list in a do-confirm moment: nobody opens a PR and follows a template line by line, so people tick the whole thing at the end without reading it. A restore runbook that says “verify the backups are healthy” is a do-confirm list in a read-do moment. At three in the morning you need the exact command, and the runbook only reminds you that one exists.

Fig. 2 · Pick the kind for each moment. (interactive version)

What makes one work

Boorman’s rules, as Gawande reports them:

A pause point. A checklist belongs to a moment, like before merge or right after a deploy. Not “whenever”.
Killer items. His term for the steps that hurt when skipped and get skipped anyway. Everything else goes somewhere else.
Short. His rule of thumb is five to nine items. Spend much more than a minute at a pause point and people start shortcutting.
Tested. Try it in a rehearsal, then revise it when real use exposes a gap.

“Short” sounds like it rules out a fifty-step database restore. It doesn’t. The checklist only has to be short enough to use at its pause point; the detailed steps live in the procedure it points to.

Asaf Degani and Earl Wiener, two human-factors researchers, studied airline checklists for NASA and added a rule about the answers: a response should give the item’s actual state or value, not the fact that you looked at it. They quote a pilot who answered “checked and set” during taxi and found out on the takeoff roll that the speed bugs were still on the approach setting. His verdict: “‘checked’ and ‘set’ can be said too easily without any sound verification.”

Fig. 3 · Speeds made up for the toy. The story is the one Degani and Wiener quote. (interactive version)

Software needs one more rule on top of theirs: every item needs a clear condition for done. “Dashboards: watched” means nothing unless someone knows what to watch, for how long, and when to stop the rollout.

Here is a deploy card written with all of that in mind. The grey lines are checked by the pipeline; they stay on the card so the crew knows they exist. The rest belongs to a person. Tap a line to call it out.

Fig. 4 · A deploy card. Grey lines belong to the pipeline, every other line has an owner. The baseline and the thirty minutes are examples: pick your own, and write them down. (interactive version)

Each response is a state someone can check. “Rollback-safe” means the previous release still runs against the new schema; if it doesn’t, the rollback line below it is a lie. “Last release” names the version you would go back to.

When the checklist becomes code

In software, some checklist items can become enforced checks in the delivery pipeline. Aviation does a version of this too. On the Boeing 777-9, the electronic checklist reads some items from the aircraft itself: if the folding wingtips aren’t extended, it marks the Before Takeoff checklist incomplete and raises a caution.

The clearest case I know is a gateway setup I built at work, which KrakenD later wrote up as a case study. Each backend team owns the files for its own routes, and those files compile, together with shared templates, into one configuration of more than 500 routes. Checking that the whole thing still builds after a one-line change is exactly the kind of step people skip. So on every pull request a pre-check builds the full configuration, and only a pull request that builds goes on to review.

Fig. 5 · A pull request that doesn't build goes back to its author. One that builds still waits for a person from the owning team. (interactive version)

What the pre-check can’t decide stays with a person: a code owner from the owning team has to approve before anything merges. The pipeline only checks the conditions someone wrote down. Whether the change is a good idea is still a human call, and that is where the attention should go.

A checklist needs an owner, like any other code. After an incident or a rehearsal, fix the lines that were unclear, and grey out the ones the pipeline now enforces so nobody checks them twice. The lines that need someone’s judgment stay, even when a script could tick them.

Gawande names the resistance plainly: using a checklist “feels beneath us,” an embarrassment for people who are supposed to be good.

So go back to that morning at Wright Field. In the cockpit sits the Army’s most experienced test pilot; nobody knows flying better. What brings the airplane down is a small lock left on the tail. The pilots who came after him weren’t more talented. They had a card, that’s all. With it, the same design flew 1.8 million miles without an accident and became the B-17.

Before you press deploy next time, ask yourself one thing: what’s my gust lock?

Stands on

Notes

A gust lock pins the control surfaces so wind can’t slam them around while the aircraft is parked. Essential on the ramp, fatal on the runway.

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.

A refactor without tests is a rewrite

Hayati — Sun, 11 Oct 2026 11:48:40 +0000

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

“I’m refactoring it” is one of the most stretched sentences in software. It gets used for renaming a variable, and for a service that is down for a week while someone cleans it up.

Martin Fowler, who wrote the book on it, puts it more precisely. A refactoring is “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.”

The interesting part is the end of that sentence: without changing its observable behavior. It raises a question people tend to skip: how do you know?

How do you know nothing changed?

You can read the diff, or try a few things in the app (these days we often don’t even read PR diffs: an AI agent writes the code, and another one reviews it :) Neither holds up once the change is bigger than a few lines.

Tests are the simple answer. They pin down what the code does today, and they tell you within seconds when a step moves it. Without them, “the behaviour didn’t change” is a wish rather than a fact. A change you can only hope is safe carries the risk of a rewrite, whatever the ticket calls it.

Fowler has a one-line test for this: “If somebody talks about a system being broken for a couple of days while they are refactoring, you can be pretty sure they are not refactoring.”

Fowler would call the untested kind restructuring rather than a rewrite. My rule is stricter: if I can’t show the behaviour stayed put, I plan the change with the care I’d give a rewrite.

Small steps, each one checked

Refactoring, done his way, is a chain of small moves with names: Rename Variable, Extract Function, Move Function. After each one you run the tests.

These are the moves we worked hard to get used to, and racked our brains over, back before AI. Now, building with Claude and Codex, we sometimes have to steer the agents down the same road. The most capable models already know all of this, and the way they are trained, to keep running the code and fixing it until the tests pass,[1] lets them do it in the natural flow of work. Still, we need to take care to hand them our own way of working.

Flip the switch below and watch the same five steps with and without tests.

Fig. 1 · Five small steps. With tests, the step that changes behaviour fails at once and gets undone. Without them, the bug shows up weeks later and nobody knows which step it came from. (interactive version)

With tests, a broken step is always the last step, so you know exactly what to undo. Without them, all five ship together. When the bug arrives, the question is no longer “what did I just do?” but “what did we do in October?”

The legacy code trap

Michael Feathers put it bluntly in Working Effectively with Legacy Code: legacy code is simply code without tests. Age has nothing to do with it. Last week’s code without tests is legacy code.

And it comes with a trap. To change the code safely you need tests. To get tests around it you often have to change the code first: a constructor that opens a database connection, or a function that reads the clock. Feathers’ way out is a loop where the change you actually came for is the last step.

Fig. 2 · Feathers' legacy code change algorithm. The first edits only make the code testable; the change you came for comes last. (interactive version)

Step 3 is where the careful, tiny edits go: pass the clock in as a parameter, pull the database behind an interface. Feathers calls the places where you can swap behaviour without editing the code there seams.

Step 4 has a trick I like. You don’t write tests for what the code should do; you write characterization tests for what it does. Write an assertion you know is wrong, run it, and let the failure tell you the real answer. Then put the real answer in the test.

// A characterization test: it records what Price does today, not what it should do.
// If today's answer looks wrong, pin it anyway and fix it in a separate change.
func TestPrice_CurrentBehaviour(t *testing.T) {
    for cents, want := range map[int]string{
        0:      "0.00",
        199:    "1.99",
        -5:     "-0.05",
        100000: "1,000.00",
    } {
        if got := Price(cents); got != want {
            t.Errorf("Price(%d) = %q, want %q", cents, got, want)
        }
    }
}

Now the refactor has a net under it.

Refactor or rewrite?

Fig. 3 · Three changes. By my rule, which one is a refactor? (interactive version)

When it really is a rewrite

Rewrites aren’t a sin. Sometimes the old code has to go. They just need a different plan, and the first step of that plan is to define the rewrite in a much clearer frame and say its name louder.

A rewrite you’ve named can be planned like one: run the old and new code side by side and compare what they return, move traffic behind a flag, keep the way back open. Fowler’s strangler fig is the patient version of this: grow the new code around the old, a piece at a time, until the old part can be switched off.

Next time someone says “I’m refactoring it”, ask the question this whole essay hangs on: how will you know nothing changed? If the answer is a test suite, let them refactor as much as they like, in small steps. If the answer is “I’ll click around”, it’s a rewrite with a nicer name, and it deserves a rewrite’s plan.

Stands on

Martin Fowler: Definition of Refactoring (2004)
Martin Fowler: Refactoring Malapropism (2004)
Martin Fowler, Refactoring: Improving the Design of Existing Code (2nd ed.) (2018)
Michael Feathers, Working Effectively with Legacy Code (2004)
Martin Fowler: Strangler Fig (2024)
OpenAI: Addendum to o3 and o4-mini system card: Codex (2025)
Anthropic: Best practices for Claude Code

Notes

OpenAI says codex-1, the model behind Codex, was trained with reinforcement learning on real-world coding tasks and “iteratively runs tests until passing results are achieved.” Anthropic’s Claude Code guide describes the same loop: Claude “does the work, runs the check, reads the result, and iterates until the check passes.”

If you'd like more of these, you can support the writing on Patreon.