Zaniar Shokati
← Back to writingSoftware Engineering

The Programming Language I Use Most Is Becoming English

Jul 28, 2026

I half-jokingly say that the programming language I use most is becoming English. That line is easy to misunderstand, so let me get the caveat out of the way first: English has not replaced Python, TypeScript, SQL, or any other language my software actually runs on. A prompt is not a deployable artifact, and a language model is not a compiler.

What changed is the interface between an idea and its first implementation. More of my work now starts as a conversation: describe the behavior, explain the constraints, challenge the proposed approach, generate a first pass, inspect what came back, and tighten the description. The code still matters. The amount of engineering that happens before I type the code has grown.

For most of my career, I introduced myself the way developers usually do: Python backend, React frontend, PostgreSQL, TypeScript. That was accurate, but incomplete. It described the tools I used, not the decisions I was responsible for.

AI-assisted development made that distinction much harder to ignore.

Syntax stopped taking most of the attention

When I started programming, a lot of my mental energy went into mechanics: the exact API signature, the right library, the framework convention I had forgotten, the syntax for a feature I did not use often. Those questions have not disappeared, but an assistant can now answer many of them quickly.

It can also generate boilerplate, draft tests, explain an unfamiliar module, or carry out a repetitive refactor. That is useful work. I use it every day.

But I used to describe this as "programming was never the bottleneck," and that was too broad. Implementation absolutely can be the bottleneck when a system has difficult performance constraints, a subtle concurrency model, messy legacy behavior, or a production failure nobody can reproduce. AI did not make those problems trivial.

What it has done, for me, is compress a large class of routine implementation work. The time I save there moves somewhere else: defining the behavior, finding the edge cases, choosing the trade-off, and checking whether the result is actually correct.

English became part of the development environment

Before code exists, there is usually a description of what the code should do. That description might be a ticket, a design document, a conversation with another engineer, or now, a prompt.

A vague description still produces vague software:

Add better feedback to the exam results.

There are dozens of plausible implementations hiding inside that sentence. Better for whom? Feedback on correctness, grammar, completeness, or learning strategy? Should it be generated synchronously? What evidence may the system use? What happens when the model is uncertain? How will I know the change is an improvement?

A useful engineering brief has to make those choices visible:

  • the user outcome, not just the requested UI change
  • the invariants the implementation must preserve
  • the inputs, outputs, and failure behavior
  • the constraints around latency, privacy, cost, and compatibility
  • the examples and tests that will count as evidence

That is why English feels more like part of my toolchain now. Not because natural language is magically precise, but because making it precise enough to guide implementation has become a larger part of the job.

Andrej Karpathy described a stronger version of this idea in his 2025 talk, "Software Is Changing (Again)". In his "Software 3.0" framing, large language models are a new kind of computer and natural language is how we program them.

I find that framing useful, but I would not take the compiler analogy too literally. A compiler rejects invalid syntax according to deterministic rules. A language model interprets an ambiguous request probabilistically and may return something convincing that is still wrong. The prompt matters now, but so do the tests, types, linters, reviews, observability, and domain knowledge around whatever it produces.

Conversation gets me to an implementation faster. It does not turn intention into correctness automatically.

The hard part is often deciding what should exist

When I work on DeutschGenie and Merulia, the questions that consume the most time rarely start with syntax.

They look more like this:

  • What is the user actually trying to accomplish?
  • Which part of the current workflow is genuinely frustrating?
  • What am I assuming without evidence?
  • How should the system behave when the answer is uncertain?
  • Which trade-off am I willing to accept?
  • What would prove that the change helped?

Those questions existed long before large language models. If anything, faster implementation makes them more important, because I can now commit to a weak answer much sooner.

DeutschGenie started from a problem I kept seeing in exam preparation: knowing that an answer was wrong was not enough. The useful question was why it was wrong and what the learner should do differently next time.

That sounds like a request for a better feedback screen. Sometimes it is. But it can also expose a deeper failure in the evaluation pipeline. If the system cannot distinguish an incomplete answer from a grammatically incorrect one, no amount of UI polish will make the feedback genuinely useful. The model can be accurate according to one metric and still be pedagogically unhelpful.

Merulia started from a similar observation. Vocabulary tools often present words as isolated translations, while useful language knowledge includes context, associations, register, and the situations in which a word actually appears.

In both products, the observation came before the stack. Python was not the starting point. React was not the starting point. The starting point was noticing something that felt broken, then trying to describe it precisely enough to build and test a better version.

Faster implementation also means faster wrong turns

There is an uncomfortable side to all of this: if an assistant lets me build a feature in an afternoon instead of a week, it also lets me build the wrong feature in an afternoon.

The cost of producing code went down. The cost of shipping the wrong behavior did not. A bad feature can still confuse users, corrupt data, create support work, or lock the system into an awkward model that takes months to unwind.

So I find myself asking "should this exist?" more often before asking "how quickly can I build it?" That is not anti-AI or anti-speed. It is what makes the speed useful.

The same applies at the code level. An assistant can propose an architecture, but it does not own the consequences of that architecture. It does not sit through the incident, explain the privacy failure, or maintain the abstraction after the original context has disappeared. I can delegate implementation work. I cannot delegate accountability.

That is the part of "AI does not replace engineering judgment" that matters to me. A model can absolutely help with judgment: it can surface alternatives, challenge an assumption, identify a missing edge case, or explain a trade-off I had not considered. Saying it cannot contribute would be obviously false.

But the engineer still has to decide which evidence to trust, which constraints are real, and whether the result is safe enough to ship.

Brooks's distinction still holds up, with one caveat

In "No Silver Bullet", Frederick Brooks distinguishes between essential difficulties—the complexity inherent in the software's conceptual structure—and accidental difficulties introduced by the tools and processes used to express it.

AI assistants are very good at reducing some accidental difficulty: syntax recall, boilerplate, documentation lookup, mechanical refactoring, and moving between representations. They can help with essential work too. I use them to explore requirements, compare designs, and find cases I missed.

What they do not do is make the essential complexity disappear. Someone still has to model the domain, reconcile conflicting requirements, decide what "correct" means, and verify the system against reality. In fact, Brooks wrote about automatic programming and expert systems in the original 1986 paper; the tools have changed dramatically, but the specification problem he pointed to is still recognizable.

I would not claim that every essential task must remain "entirely human." That is too neat, and current tools already make the boundary blurry. The more defensible claim is that higher-level tools move our attention upward. When implementation becomes cheaper, the quality of the specification, the model, and the verification becomes a larger share of what separates good software from plausible-looking software.

Where this leaves me

I still write Python. I still use React and PostgreSQL. I still need to understand the code well enough to debug it when the generated first pass fails in a way that looks impossible.

But more of my leverage now comes from being able to explain a problem precisely: what the system should do, what it must never do, what trade-offs are acceptable, and what evidence would change my mind.

That is why English feels like the programming language I use most. It is not the language the machine ultimately executes. It is increasingly the language in which I design the work, direct the tools, and expose gaps in my own thinking.

The code still matters. Understanding why it should exist—and being precise about what it must do—is becoming the harder half of the job.

Sources I leaned on