English Is Now My Primary Programming Language

Last year I started tracking where my development time actually goes. The answer was uncomfortable: I write more English than code. Not documentation — specifications, acceptance criteria, context frames for AI models, verification prompts, iteration notes. The ratio runs roughly 80/20 in favor of prose.

This shift didn’t happen overnight, and it’s not unique to me. Andrej Karpathy named it in 2023. Jensen Huang repeated a version of it at every major keynote since. Simon Willison has been documenting it in real workflows for two years. But in early 2026, with Claude Code, Cursor, Aider, and Kiro running in production pipelines across thousands of teams, this is no longer a provocative forecast — it’s an observable fact for anyone paying attention.

Here’s what the transition actually looked like. I started with what the community calls vibe coding — a generous description for “tell the model what you want and see what comes out.” It worked well enough for prototypes. It fell apart the moment I needed maintainability. Regressions appeared in places I hadn’t touched. Context drift turned a clean codebase into a patchwork. The model wasn’t failing; I was. I was giving it ambiguous input and expecting precise output.

The fix was a methodology shift, not a model upgrade. Spec-Driven Development means writing a structured specification before any code gets generated. Concrete requirements. Edge cases named explicitly. Acceptance criteria that double as test prompts. When I tightened the English, the code quality jumped. Token consumption dropped because the model stopped hallucinating intent. The specification became the source of truth, and I became its author.

English didn’t replace Python or TypeScript. It became the interface to them. The mental model that works: you’re writing compiler input — except the compiler is a large language model, and its error messages come back as hallucinated functions and drifting scope. Precision in the spec reduces the noise downstream. This is not a metaphor. It’s a production workflow.

The uncomfortable implication is geographic and linguistic. Native English speakers — and more specifically, people who write with structural clarity in English — hold a measurable edge. Not because the models are biased, but because ambiguity in the input produces ambiguity in the output. A developer writing specifications in their third language, fighting for precision word by word, spends more iterations on the same task. The tooling democratizes access to software creation; the language requirement quietly re-creates a different barrier.

There’s a second tension worth naming. The skills that made someone a strong developer in 2019 — syntax fluency, API memorization, low-level debugging — are not the skills that make someone effective in this model. The new profile looks more like a technical writer crossed with a systems architect: someone who can decompose a problem, specify its constraints, and verify the output critically. Most hiring processes aren’t testing for that yet.

My read: the engineers who thrive in the next five years won’t be the ones who code fastest. They’ll be the ones who specify most clearly. The ability to write a rigorous, unambiguous description of a system — its inputs, outputs, failure modes, and constraints — is now a core technical competency. Treating it as a soft skill is how teams end up with AI-generated code that nobody fully understands and nobody wants to maintain.

What percentage of your working day is English now?