It is now possible to write 500 lines of TypeScript by writing 50 lines of English. The English is the code. The TypeScript is just the compilation output.
This isn’t a metaphor. English has become the highest-level programming language available to software engineers in 2025. Not because English itself changed, but because the tooling around it finally caught up. AI agents can now reliably translate English descriptions into working code across most common programming tasks.
The implications are profound: we’re no longer constrained by the syntax and ceremony of traditional programming languages for expressing what we want to build. English is now the most efficient interface for communicating programmer intent.
A new generation of AI agent coding tools has emerged in the last six months:
These tools represent a fundamental shift. Previously, AI coding assistance was limited to autocomplete suggestions and code snippets. Now, these CLI agents can understand complex requirements expressed in English, maintain context across entire codebases, run tests, fix bugs, refactor code, and implement complete features from natural language descriptions.
What changed is reliability. The translation from English to code became accurate enough that it’s now faster to express intent in English and review the generated code than to write it character-by-character yourself. This is what I described in English is a High Level Programming Language Now—we’ve reached a new level of abstraction.
This shift also transforms our role as engineers. As I explored in We Are All Software Architects Now, we’re moving from code implementation to system design, using English as our primary interface for specifying technical architecture.
The history of programming is a history of rising abstraction levels. Assembly language abstracted machine code. C abstracted assembly. Python and JavaScript abstracted C. Each level traded some control for massive gains in expressiveness and productivity.
English represents the next level up.
Consider this comparison:
// TypeScript (lower-level implementation)
interface User {
id: string;
email: string;
passwordHash: string;
createdAt: Date;
}
async function createUser(data: CreateUserDTO): Promise<User> {
// Validate email format
if (!isValidEmail(data.email)) {
throw new ValidationError('Invalid email');
}
// Check if user exists
const existing = await db.user.findUnique({
where: { email: data.email }
});
if (existing) {
throw new ConflictError('User already exists');
}
// Hash password
const passwordHash = await bcrypt.hash(data.password, 10);
// Create user with transaction
return await db.user.create({
data: {
email: data.email,
passwordHash,
createdAt: new Date()
}
});
}
// ... plus validation functions, error types, database schema, tests, etc.
versus:
// English (higher-level requirements)
"Create a user management system with email/password authentication.
Include proper validation for email format, check for duplicate accounts,
hash passwords with bcrypt, use database transactions for data integrity,
and add comprehensive error handling. Follow our existing patterns for
validation and error responses."
The AI agent can write all the TypeScript code, following the project’s existing patterns and conventions. You review the output to ensure correctness. The English becomes the actual programming—the TypeScript is just the compiled result.
Traditional programming languages are implementation languages, not requirements languages. They force you to think at the wrong level of abstraction for most tasks.
When you need to add user authentication to your app, you don’t start by thinking about function signatures and type definitions. You think: “I need users to log in securely with email and password.” That’s an English sentence. Then you translate it into TypeScript or Python or Rust.
That translation step is now unnecessary for conventional code. The AI can handle it. You can stay at the requirements level—the level where you’re actually making decisions about what the system should do.
As I noted in AI is My IDE Now, this shift means the AI agent becomes the primary interface, not the editor. You express what you want in English, the AI implements it in whatever lower-level language your project uses, and you review the result.
Requirements come from humans. Product managers, designers, clients, users—they all speak English, not TypeScript. Every software project starts with English descriptions of what needs to be built.
Previously, you had to mentally translate those requirements into code. That translation introduced bugs, misunderstandings, and complexity. The distance between “what the client asked for” and “what the code does” was a primary source of software defects.
With English as a programming language, you can stay closer to the original requirements. “Add a dark mode toggle to the settings page” can go almost directly into the codebase. The translation to React components, state management, CSS, and styling happens automatically. The gap between requirements and implementation shrinks dramatically.
This doesn’t eliminate the need for technical thinking. You still need to understand the system architecture, make trade-offs, and review the generated code carefully. But the tedious work of translating English intent into programming language syntax is increasingly automated.
English has the richest technical and scientific vocabulary of any language. This isn’t cultural bias—it’s a historical fact. Most modern computing concepts were developed in English-speaking contexts, and the terminology spread globally in English.
Try expressing “implement OAuth2 authorization code flow with PKCE extension” in Spanish: “Implementar flujo de código de autorización OAuth2 con extensión PKCE.” The technical terms are borrowed directly from English because Spanish doesn’t have native equivalents that the technical community actually uses.
The same pattern appears across languages:
This creates a practical problem for non-English speakers using AI coding tools. The tools work best with English prompts because the underlying technical concepts are expressed most precisely in English.
AI models were trained predominantly on English technical content. Stack Overflow, GitHub, programming documentation, technical blogs—the vast majority of programming knowledge on the internet is in English.
This creates a feedback loop: English prompts work better → developers use English → more English content gets created → AI models trained on that content work even better with English.
A Spanish speaker prompting an AI agent with “crear un sistema de autenticación” will likely get less reliable results than an English speaker writing “create an authentication system.” Not because the AI is biased, but because it has seen far more examples of authentication systems described and implemented in English.
This is unfortunate for non-English speakers, but it’s the reality of where AI coding tools are in 2025. English is the de facto interface language for programming with AI, just as it’s the de facto language for international scientific collaboration.
Consider expressing these technical concepts across languages:
| Concept | English | Spanish | Observation |
|---|---|---|---|
| ”Implement OAuth2 flow with PKCE” | Direct, precise | ”Implementar flujo OAuth2 con PKCE” | Borrows English terms |
| ”Add dependency injection” | Clear term of art | ”Agregar inyección de dependencias” | Literal translation, less precise |
| ”Refactor to use async/await” | Standard terminology | ”Refactorizar para usar async/await” | Borrows English async/await |
| ”Deploy with blue-green strategy” | Industry standard | ”Desplegar con estrategia azul-verde” | Color terms translated, concept borrowed |
Technical English isn’t just English—it’s a specialized dialect that evolved specifically for expressing programming concepts. Other languages can translate it, but they’re always translating from this English-based technical vocabulary.
This gives English speakers a genuine advantage when programming with AI. The prompts can be more precise, the AI responses more reliable, because both human and AI are working in the native language of computing.
English as a programming language excels at conventional code patterns—the kind of code that follows established practices and appears frequently in training data.
User authentication? There are millions of examples. The AI knows how to implement it securely. CRUD operations for a database? Standard pattern. React components? Seen countless times. REST API endpoints? Well-established conventions.
For these tasks, English is genuinely the best programming language. You can describe what you want more clearly in English than you could implement it in TypeScript, and the AI-generated code will likely be correct on the first try or require only minor corrections.
The productivity gains are substantial. As discussed in Cleaning Up AI Slop With AI, these same tools can analyze and refactor existing code when given proper English instructions. The language works for both creation and maintenance.
English breaks down for novel work. If you’re implementing a new algorithm that hasn’t appeared in training data, or optimizing performance-critical code that requires understanding of specific hardware characteristics, or building core cryptographic implementations where correctness is paramount, you’ll still need to work in traditional programming languages.
The AI doesn’t have a mental model of your unique system. It has statistical patterns from millions of codebases. When your code diverges significantly from those patterns, the English → Code translation becomes unreliable.
For novel core systems, you’ll likely write detailed English specifications that are essentially pseudocode, then carefully review every line of generated code. Or you’ll write the code by hand. English still helps—it’s useful for documentation and explaining intent—but it’s not the primary programming language for truly innovative work.
This needs emphasis: using English as a programming language only works when you review the output carefully.
As I explained in AI is Like Steroids, AI amplifies your capabilities but doesn’t replace your judgment. The tools are powerful but not infallible. They generate code fast but don’t guarantee correctness.
The discipline required is significant. You must understand the system architecture. You must review generated code line by line for anything touching authentication, payments, or core business logic. You must run tests, check for edge cases, and verify that the implementation actually matches your English specification.
This is covered thoroughly in Responsible Use of AI for Senior Software Engineers. The core principle: the human makes all high-level decisions and reviews all output. AI is a force multiplier, not a replacement for thinking.
What happens without this discipline? You get what I described in Building a Technical Debt Factory with AI Agents—a mountain of unreviewed code that technically works but is unmaintainable, insecure, and likely to fail under scale.
English is the best programming language in 2025, but only when wielded by someone who knows what they’re doing.
Let’s acknowledge the obvious objections.
“English is ambiguous.” True. “Add a user dashboard” could mean many things. But so could a vague function signature in TypeScript. The solution in both cases is the same: be more specific. “Add a user dashboard showing post count, follower count, and recent activity, following our existing dashboard pattern in the admin section.”
Precision in English is a learned skill, just like precision in TypeScript. And English has an advantage: when you’re unclear, it’s immediately obvious to other humans reading your description. Vague code can compile and run while still being wrong.
“You need domain knowledge.” Absolutely. You can’t program effectively in English without understanding software architecture, security, scalability, and your specific domain. But that was always true. Knowing TypeScript syntax never made you a good programmer—understanding systems did.
English just raises the level of abstraction. You still need all the same knowledge. You’re just expressing it at a higher level.
“This only works in 2025 because of specific AI capabilities.” Yes. That’s exactly the point. The tooling evolved to make English reliable as a programming interface. Five years ago, this blog post would have been science fiction. Five years from now, it will be obvious.
The trade-off favors English now for most development work. That’s new. That’s why English is the best programming language in 2025 specifically—not in 2020, maybe not in 2030 if something even higher-level emerges, but right now.
English is now the best programming language for expressing programmer intent. Not for all code, not in all situations, but for the majority of software development work in 2025.
The abstraction hierarchy is clear: English sits above TypeScript, Python, and Rust, which sit above assembly, which sits above machine code. Each level is appropriate for different tasks. But for most tasks—implementing features, refactoring code, building conventional systems—English is the most efficient interface.
If you’re still programming primarily by typing TypeScript or Python character-by-character, you’re working at the wrong level of abstraction. You’re writing assembly when a higher-level language is available.
The shift I described in We Are All Software Architects Now is accelerating. Our job is becoming less about code implementation and more about system design. English is the language of that design.
Use it. Review carefully what it generates. Maintain your technical understanding. But recognize that the programming language of 2025 isn’t TypeScript or Python or Rust.
It’s English.