The "Negative split" software engineering effect

Most world records in distance running were set with a “negative split” - running the second half of the race faster than the first. You start disciplined, you save your energy, and you speed up when everyone else is slowing down.

On April 26th, for the first time ever, a human ran an official < 2-hour marathon. Everyone talks about his light shoes, but the interesting part is the crazy negative split he achieved.

With all the AI craze out there, 90% of companies are doing the exact opposite.

I learned this one the hard way, both with the team I started managing recently and in the marathon I finished at the end of February.

I've been training with a group for the last couple of years. There is one mantra our coach constantly pushed into our heads: run by heart rate, not by pace.

For most people, their legs and their hearts are not in sync. When you run too fast, your heart rate spikes, and your glycogen (the fuel your muscles run on) burns out way earlier than it should. Research shows that starting just 5-10% too fast can deplete your energy stores up to 30% earlier. That's why people hit the wall at kilometer 30 and can barely move.

The same thing will happen to many AI-crazy teams. A company's life is measured in years (say 7-10 years on average for a startup). The ones popping up everywhere are barely at 20% of the race. So you start super fast, and you continue to go fast, but you accumulate technical debt in your codebase and shortcuts in your architecture. You will slowly slowly start to “get tired”, and you'll finally hit that same wall.

The fix for runners sounds very simple: run slower, at the right heart rate, and you'll actually improve your pace faster. My coach was telling me this for months, but my answer was always the same: "I came here to train, to get my energy out, I can go faster." It took me a loooong time to actually stick with it. I always cheated a little, always ran faster than I was supposed to, because that's how my brain was wired for satisfaction. What's the point of running at 6:30 minutes per kilometer? It’s too boring.

But when I finally did listen, the results were amazing. I finished my first half-marathon at 5:40 per kilometer (~9 min/mile), faster than my best 10km run. I ran the last 3 kilometers at 5:00/km, as I had tons of energy left. And across 3 years of training, a triathlon, and a full marathon, I had zero injuries. Not one missed training session because of pain. Seriously, not a single one (injury = your people burning out or you have a production disaster, pick your favorite).

So there I was at the marathon, after a great half-marathon race, knowing all of this. I even wrote a whole newsletter article about intensity zones.

I initially planned for 6:00 m/km, but my 2nd son was born a month before the race, so my training was not ideal. The day before the race, I decided to go for 6:30 min/km, an easy pace.

Then the race started.

Sun on my face, 3,000 runners around me, kids cheering on the sides, people running with smiles everywhere (Sonnet 4.7 released, tons of AI tools, everyone says to have 10 agents running in parallel). I felt amazing.

I ran 6:10. Then some at 6:30. A couple at 6:20. First half average: 6:22. Just 8 seconds per kilometer faster than the plan. My heart rate spiked a bit, just a little over what I planned. But it was enough…

After kilometer 30, it became HARD. I slowed down considerably. Second half average: 6:42, for a total of 4:36 hours.

I am absolutely sure that if I had been more disciplined in the first half, I would have finished faster. It was just my own brain, telling me I can handle it.

A few weeks prior, I did the exact same thing to my team:

I wrote about it last week in detail - taking over an existing team in a new area, pushing scope to get early wins, until our most experienced engineer pulled me aside and told me to stop. What I want to add here is what he said in a longer conversation after that:

"It's very, very rare that I feel a change of cadence of work is justified. I give estimations, and I try to be as accurate as I can, but once truly asked, I'll give you an honest answer: it'll be done when it'll be done, take however long it'll take."

This is not a developer who works slowly. He did a massive refactor of our most critical system - initially estimated at 2 months for 2-3 people. He did it alone in 2 weeks, with zero production incidents.

He doesn't let external pressure change his pace. And when the complex, risky part comes, he has the energy and stability to handle it.

There's a quote from Peopleware I keep coming back to:

People want to finish. Time constraints have value, but not for making people work harder - they're just about using time as a forcing function to prioritize and cut scope.

In a recent all-hands, our CTO surprised everyone by saying he expects us to stop writing code manually entirely in a few months.

What made me take him seriously is that he mentioned the company is willing to go SLOWER in the short term to make this happen. The goal is to right high quality code, not to just rush blindly forward. It was not a "hype" sentence, telling us to go all in on LLMs.

He gave a concrete example: say you prompt an LLM to write a feature for you, and the result is bad. You try to adjust in a couple of prompts, but end up giving up and writing manually. He asked us not to do that, but to figure out what info could have helped the LLM to write better code.

The answer is almost always better context and guidelines, and those don't have to come from the end-user's prompt. They'll mostly come from a rich, company-specific, and constantly maintained layer. This is a difficult problem to solve, and most companies with strong engineering cultures are hard at work solving it for themselves.

It takes a lot of patience and cooperation by the majority of engineers, this is not something that can be built "in the basement" by hands-off architects.

When you decide instead to move fast with mediocre code (or to quickly type the right code yourself), you are running a positive split - you banked "progress" early, and you'll keep paying for it on every future prompt (which will either need to be adjusted manually, or shitty code will slip into production).

Not every run is a marathon. Sometimes you have 100m sprints, where you just need to go as fast as you can. When you test a concept, and you know this code will be thrown away, by all means, go turbo.

The challenge is that sometimes you don’t know when you start the run how long it’ll take.

My advice is not to go slower for the sake of it - it is to go slower so you’ll build a better foundation to move faster later. Slow down to speed up.

Giving this advice is so easy, but it is REALLY hard to follow, and I’m unfortunately creating ‘positive splits’ all the time. Still working to improve that :)