Software engineering in the age of AI: run the mile you're in

I have a confession to make: I am not a runner.
If you check the internal Slack channels at TrueLayer, you’d think half the engineering team is currently training for a 5k or a marathon. While I admire the discipline, I usually prefer my cardio to be a bit more... metaphorical.
However, the analogy holds up. Building a scalable, global payment network is not a sprint; it is an endurance sport. It requires pacing, resilience, and a strategy that looks beyond the next 100 meters. That is why, despite my lack of mileage, I’ve found myself looking to the philosophy of American distance running legend Ryan Hall.
Hall for many years held the US record for the half marathon (59:43) and was the first American to run a sub 2:05 marathon. But his legacy isn’t just about the times on the clock; it’s about his mindset.
Hall famously argued that an athlete must focus on the process — training, effort, and attitude — rather than the outcome. He viewed performance not as the primary goal to be chased, but as a natural byproduct of living in alignment with deeper commitments. He often spoke of the need to "run the mile you're in," resisting the urge to panic about the distance remaining or dwell on the miles already behind.
In the current era of Generative AI, software engineering feels like a race where the finish line keeps moving. The pace of change is intense, the hype is deafening, and the anxiety about "outcomes" (Will AI replace us?) is at an all-time high.
I believe that looking at this through Ryan Hall’s lens can offer a grounding path forward. By shifting our focus from the frantic pursuit of outcomes, to the simple daily discipline of present effort and thoughtful processes, we can build better software and healthier teams.
Here are the principles that guide our engineering culture in this new era.
1. Run the mile you're in
The pace of AI development is overwhelming. It is easy to get paralysed by the "miles down the road".
Focus entirely on the current step. In engineering terms, this means solving the user problem directly in front of you with the best tools available today.
2. Performance is a byproduct of alignment
In racing, if you obsess over the split time, you tense up and lose form. The time is just a result of your training mechanics.
In software, true velocity isn't about typing speed; it's about direction. AI tools can help us write code faster, but they cannot tell us what to build. If a team lacks clarity of vision, AI merely allows us to build the wrong thing faster than ever before.
Alignment first. Speed later: Before we engage the AI copilots, we must engage with each other. We prioritise clear roadmap, ADRs, shared architectural vision, and unambiguous requirements.
Clarity is the constraint: Our performance is now defined by how well we align as a team on the problem statement.
3. Rest takes confidence
Hall also said, "Anyone can train like a madman, but to embrace rest takes confidence."
AI models don't sleep, but engineers must. The temptation in the AI age is to match the machine's velocity, churning out code faster because we have copilots.
We use AI to buy ourselves time to think, not just time to type. We have to resist the temptation to use the efficiency gains from AI not to squeeze in more features, but instead to create space for deep work, and the rest required to maintain creative cognitive function.
4. Pain is a powerful teacher
My runner colleagues have taught me a lot about the "bonk" (hitting the wall during a run due to inadequate prep). In engineering, our "bonk" comes in the form of production incidents or missed deadlines. It is tempting to gloss over these moments or look for quick fixes, but we need to dig into the pain to learn the lesson
Incidents are data: A production outage is not just a failure; it is a high-fidelity signal about the fragility of our system. What can this pain teach us about our observability and resiliency?
Deadlines are mirrors: If we miss a deadline, it reflects a gap in our estimation or scope management. We don't view this as a defeat, but as necessary feedback to refine our process for the next sprint.
5. Belief drives the body
"The body will always follow where the mind leads."
We view AI not as a replacement, but as a power tool. A power drill does not make the carpenter obsolete; it allows them to build a house in half the time, provided they have the skill to handle the tool safely.
The operator mindset: If we believe we are simply "coders," AI threatens our identity. If we believe we are "problem solvers," AI amplifies our ability.
Command the tool: An exoskeleton only works if the human inside moves with intention. We must cultivate the belief that human judgment, empathy, and architectural intuition are the drivers. AI provides the torque; we provide the direction.
6. If it's not fun, it's not worth doing
In reading more about Ryan Hall for this blog post, I came across the fact that his father told him, "If it's not fun, it's not worth doing." This simple advice carried him to two Olympic Games.
AI should return the "fun" to engineering. Let the models handle the repetitive stuff — the boilerplate, the regex parsing, the unit test scaffolding, the migration scripts. That leaves you with the fun stuff: the complex distributed systems problems, the intuitive product design, and the creative solutions that actually require human ingenuity, and probably why you became an engineer in the first place.
Hall never just ran to beat the clock; he ran to find out what he was capable of. We approach AI with the same curiosity. It is not here to finish the race for us, but to help us run it better, faster, and with more joy than before.
So take a deep breath, trust your training, and keep your eyes on the road immediately ahead. The finish line will take care of itself.

eBay partners with TrueLayer to offer Pay by Bank at checkout
Everything you wanted to know Signup+, explained in two minutes

)

)
)
)