# 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.[^1]

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](https://thezvi.substack.com/p/ai-135-openai-shows-us-the-money), “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.

[^1]:
    I suppose this allowed me to become more confident with pencil-and-paper
    programming, a skill which was useful for precisely one advanced placement
    exam, and nothing since.