Technical Escape Velocity

1.

When I was learning to program, I remember a specific phase transition in that process of skill acquisition – a distinct “before” and “after”, similar to how when learning to read there’s the “before” of ignorance, the “after” of effortlessly reading, and surprisingly little memory of the intermediate struggle of learning.

For programming, this phase transition was the point where I felt confident that I could, in principle and given enough time, program anything that could be programmed.

I learned to code, initially, through a mixture of Java Minecraft plugins, Objective-C OSX and iOS games, and physical programming books, which I’d studiously read in my middle school’s designated reading time, trying to absorb operating systems programming while… staring at a book without access to a computer.¹

This time spent grasping at concepts that I didn’t have a good handle on was legitimately useful, but frustrating. I recall feeling the unwieldy uncertainty of the unknown with how to take a simple idea I had (“program a ‘simon says’ game!”) and then turn that into a reality (arrays, display elements, event loops). The number of unknown unknowns was too high to have a chance at finding what I needed on StackOverflow.

Then, there was some critical point where my mindset shifted. I’d built up enough of a mental model of the key concepts behind “how to program a computer” – control flow, filesystem operations, network requests, parsing/serialization, calling REST APIs, etc. – that it felt like I could figure anything out given sufficient time. I think there’s two components to this mindset shift: (1) having enough of the common patterns in your repertoire to make the “easy things easy”, and (2) developing the meta skill of knowledge acquisition (i.e. knowing what search terms to use, having a reasonable grasp on enough of the CS/systems theory to search for what you need) to make the “hard things possible”.

2.

As a handle for this mindset shift, I’ll call this “Technical Escape Velocity”. As in, you build up enough technical knowledge to bootstrap yourself to escape the “gravity well” of ignorance.

In orbital mechanics, escape velocity is the minimum speed needed to break away from a celestial body’s gravity well without further propulsion. Technical Escape Velocity (TEV) is admittedly a stretched metaphor, but I like it for the following reason: when you reach escape velocity, you don’t immediately leave the gravity well, you just have sufficient conditions for eventually exiting the gravity well.

Different problem domains have different gravity wells. A small webapp has a smaller gravity well than a sprawling full-stack SaaS app, which in turn has a smaller gravity well than “leading a 20 person engineering team through a complex, layered distributed system migration”.

For a given problem domain, you can eventually become proficient enough to solve all the solvable problems within that domain. If you’re lucky, some of this knowledge will even transfer between domains. Critically, you still only know you’ve solved the problem once you have evidence of it actually being solved. Just because you think or feel like you have TEV, doesn’t mean you actually do. Trickier problems with larger gravity wells require you to wait longer to know if you’ve actually left orbit – or if you’ll ultimately crash back to the surface in failure.

3.

Fast forward to 2025, AI tooling has dramatically changed how this learning process can work today. As Zvi Mowshowitz often says, “AI is the best tool ever made for learning, and also the best tool for not learning.” Tools like Claude Code or Codex make the TEV for simple tasks effectively zero – “write a simon says game for me” is something that any frontier AI model should be able to do, essentially zero-shot. But it also enables you to use that as a crutch: if you stay comfortably in the zero-TEV problem domains, then when you hit a wicked problem, you will not have built up enough tacit knowledge and experience to make the jump.

In 2025, a coding agent can do a lot of your “tedious homework” as a developer. It can also give you a pretty reasonable head-start on design and architecture questions. This makes the TEV for low- to medium-difficulty tasks dramatically lower than it had been 5 years ago.

The class of problems with nontrivial TEV has contracted, to where now only the most difficult, wicked problems have a high TEV. I’m not sure AI has dramatically lowered the TEV of those problems. Large architectural decisions that will impact the work of dozens of engineers and take years to fully realize? Still hard. Still requires a lot of tacit knowledge, experience, intuition, and long-horizon planning. AI can help, but discerning slop from reasonable strategy still requires a very high TEV. To be clear, I’d rather have Claude Opus 4.5 on-hand to bang out prototypes and rubber-duck ideas with, but I don’t think its long-horizon judgement is there yet.

The highest-of-high TEV problems are the ones where you have a very weak, delayed feedback signal. Projects where you have to wait months to see whether structural bets you made paid off or not. Projects where you need to course-correct midway through because of unforeseen circumstances. Strategic actions taking realpolitik into account. These problems are high TEV because they aren’t purely technical – they’re still systemic and involve a lot of technical decision-making, but they also are deeply intertwined with organizational, business, and market forces. It’s notoriously difficult to even tell if humans are skilled in domains such as these, because teasing out luck versus skill becomes nontrivial.

Will AI be there in 3-5 years? My intuition is “no, unless we have another architectural advance in long-term planning”. And yet, I’ve been quite surprised over the past year at how quickly coding agents have been climbing the TEV curve. It’s hard not to hedge in either direction on this; there is significant uncertainty.