What Elite Sport Taught Me About Building AI Systems

There is a genre of essay where a former athlete explains that sport taught them discipline, resilience and the value of hard work, and that these qualities also apply to business. I have read a lot of them. They are all the same essay, and none of them contain anything you could act on.

This is not that. I spent my childhood and teens in the Egyptian squash system, reached the top 9 in the world junior rankings, won a World Junior Team Championship with Egypt, played collegiate squash at Trinity College, and competed professionally. Then I became an engineer. Some specific things transferred. Some specific things did not, and a couple of them cost me time before I noticed.

What transferred

Fast, honest feedback loops

A squash rally gives you an answer in about four seconds, and it does not care how good your reasoning was. You believed the drop was on. It was not. The information arrives immediately, publicly, and without any regard for your investment in the idea.

You cannot spend a decade inside that loop without developing a low tolerance for unfalsifiable claims. When someone tells me a system is working, my instinct is to ask what result would look different if it were not — and that instinct came from sport, not from research.

Concretely, it is why I build evaluation before I build capability. Not out of discipline. Out of discomfort with the alternative: working for weeks inside a loop with no scoreline, where the only feedback is whether the output feels better. That is the engineering equivalent of practising alone and assuming you are improving.

Thinking in patterns rather than events

The transition every developing player makes is from watching shots to watching patterns. Early on you see a sequence of individual events — she hit a drop, I hit a boast, she hit a drive. Later you stop seeing events and start seeing structure: she goes short every time I go crosscourt from deep, and it has happened five times.

That shift is not a squash skill. It is the same instinct that makes someone useful looking at data — the willingness to treat a single observation as noise and to wait for the thing that recurs. It transferred directly, and it is most of why the questions I ask about a system tend to be about distributions rather than incidents.

Marginal gains, and tolerating work that does not feel significant

No individual training block feels like it matters. You do the session, you feel roughly the same, and the improvement is invisible on any timescale you can perceive. Over a season it is enormous.

Engineering has long stretches with the same shape. Improving retrieval quality, tightening an evaluation suite, fixing the calibration layer under a vision pipeline — none of it produces a visible moment. Sport made me comfortable with work that only pays cumulatively, which turns out to be most of the work that matters in production systems.

Deciding under incomplete information

At 9–9 you have to choose, and you will not have enough information, and waiting is also a choice with a worse expected outcome. You learn to make the call with what you have and to accept that a well-reasoned decision can lose.

I use that constantly. Shipping decisions are almost never made with sufficient information, and teams that wait for certainty pay for the delay in ways that are harder to see than the cost of being wrong. Sport also teaches the second half of this, which is more important: you evaluate the decision on the process, not the outcome. A good decision that lost is still a good decision. A bad one that won is still bad, and repeating it will cost you.

Preparation as the actual edge

Matches are largely decided before they start — by the training, and by knowing what you are walking into. As a junior, the difference between playing an opponent I had scouted and one I knew nothing about was often the difference in the result, and the work happened days earlier.

The same is true of production systems. The evaluation suite you built beforehand is what saves you at 2am. The monitoring you set up before launch is what tells you what broke. Almost everything that feels like competence in a crisis is preparation that happened when nothing was wrong.

This is also, fairly directly, the reason Core Sports AI exists. The preparation advantage I had access to as a player was limited by how much footage a person could physically watch.

What did not transfer — and what actively hurt

This is the part the genre leaves out.

Individual performance culture. Squash is an individual sport. On court, everything is yours: the preparation, the decisions, the result, the blame. That is a coherent model for a sport and an incoherent one for building software, where the output is a system produced by a team and the failure modes are mostly organisational. I had to unlearn the reflex to absorb problems personally rather than route them, and it took longer than I would like.

Tolerance for pain as a proxy for progress. Endurance is genuinely trainable and genuinely useful in sport. In engineering, the ability to keep working through difficulty is a trap, because difficulty in engineering is usually information. A problem that will not yield to sustained effort is often a sign the approach is wrong. Sport trains you to push. Engineering frequently requires you to stop and reconsider, and my instinct was the opposite for years.

The assumption that effort is legible. In sport, the work shows. Fitness is visible, results are public, and nobody has to be told who is training. Engineering is not like that at all — the most valuable work is often the least visible, and expecting it to be self-evident is a good way to be quietly wrong about how a team is functioning.

The thing I most underrated

That the domain knowledge itself would be the asset.

I assumed for a long time that the squash career and the engineering career were separate — an interesting biographical fact and an unrelated profession. What I have found building sports AI is that knowing what a pattern means on a court determines what is worth measuring, which determines what gets built. The engineering is table stakes. Knowing which of ten thousand detectable patterns a player would actually change their game for is the part that cannot be hired in.

The two halves were never separate. It just took me a while to see the connection.