Code Was Always Moving Toward English. It Just Got There.

Every senior dev I cross these days (10, 15 years of shops, migrations, stacks abandoned at the worst moment, people who survived the era where everything had to be microservices even for a CRUD app handling 12 users a day) carries the same thing. "I can't figure out if I should still learn to code or just get better at prompting." "I teach at the university, but should we still teach PHP to students who will graduate in 4 years..." "My job doesn't look like what it was 1 year ago, I don't know why."

Tokenmaxxer or pro vibe-coder. Which one?

What gets me every time is not the worry. It's the precision of the blur. These people debug race conditions in prod, they see hype cycles arriving from a distance. And yet: the same blank at the end of the sentence. I recognized that blank. We've been here before. Just not with LLMs.

Every Conversation. Same Silence.

The teaching angle keeps coming back across all these conversations, and it's the one that sticks with me most. "Do I still teach Python to students who will graduate in 4 years?" It has a hard deadline. The person asking has to make a curriculum decision by September. No room for "let's see how it evolves."

Across forums, Discord servers, Slack threads: someone building SaaS in Next.js, someone running a 3-person dev shop trying to decide whether to upskill on agents or go deeper on fundamentals, someone who ships integrations for a living and wonders if that job still exists in 18 months. Different countries, different stacks, different contexts.

Not "I don't understand what's happening." More like: "I can feel something is changing but I can't name it. And I've done enough transitions to know that matters."

That last part is the tell. Not knowing what's happening is uncomfortable. Not being able to name something you can clearly feel is a different kind of uncomfortable entirely. It usually means the vocabulary hasn't caught up yet.

I spent 40 minutes last Tuesday trying to name a folder. Not a repo. A folder. The naming problem in software is evergreen and LLMs don't make it better. They generate more plausible-sounding bad names, faster. That's all, carry on.

70 Years, One Direction

There is a thing nobody teaches in comp sci because it ruins the "languages are hard" mystique: since 1957, every single generation of programming languages moved in the same direction, toward English, without exception.

Machine code was binary. Assembly gave you mnemonics you could almost read if you squinted. Then FORTRAN and COBOL, in 1957 and 1959, arrived with something that had never existed before: a line of code you could read out loud without explanation. "MULTIPLY HOURS-WORKED BY HOURLY-RATE GIVING GROSS-PAY." That's COBOL. A business manager in 1960 could parse it cold, with zero programming background.

[INFOGRAPHIC: TITLE "70 Years Moving Toward English" + subtitle "one direction, no exceptions". Metaphor: a long horizontal road with 5 milestone road signs, left-to-right progression from binary to speech bubble. Style: Franco-Belgian ligne claire comic, thick black outlines, flat colors, clean horizon. Palette: cobalt blue #1A4FD8, signal red #E8291C, warm cream #FFF9F0, black #111111, light gray #DDDDDD. Content: 5 signs labeled MACHINE CODE (1950), ASSEMBLY (1952), COBOL/FORTRAN (1957-1959), PYTHON (1991), LLMs (2026). Each sign shows a small developer figure getting progressively more relaxed, last figure standing with mouth open and no keyboard visible. Highlight: LLMs sign in signal red with starburst, figure gesturing without keyboard. Footer: copyright rentierdigital.xyz. NOT flat corporate infographic, NOT minimalist tech aesthetic, NOT boring timeline with dots.]

Python, when it arrived in 1991, was designed explicitly to read like pseudocode. Readability wasn't an accident, it was a design goal, stated in the language's own documentation. And every transition had the same reaction from the generation being displaced. "Too much abstraction." "You lose control." "That's not real programming." FORTRAN was considered dangerously high-level in 1957. The people writing it were told compilers could never match hand-optimized assembly. Same reaction, different save file. They were wrong. The people who called Python too slow and not real code in 1991 were wrong too.

This is not a revolution. It is the continuation of a movement 70 years old.

The Question Is Already Obsolete

Everyone asks if they should still learn to code. The question is already obsolete. That sounds more dramatic than it is.

What happened with every previous abstraction layer: the layer below didn't disappear. Assembly still exists. COBOL still runs more banking transactions than any other language on earth (I think there are more COBOL lines in active production today than lines of Python, though nobody wants to say that in a conference talk). The question was never "does the old layer vanish?" It was always "what does the new layer change about when you reach for which tool?"

For the first time in the history of computing, the new abstraction layer is not a language slightly more readable than the previous one. It's a system that already understands human language and can execute it directly. The syntactic intermediary is, for the first time, optional. Not gone. Optional.

That changes what the real question is. The viral X post mocking "80% of code written by AI in 2025, then 100%, then 12%, then 300% of bugs in 2028" hit more than 1 million views because the framing is absurd and people recognized it immediately. It is not a percentage question. It is a layer question.

But there is a second question inside the layer question, and it's the uncomfortable one: what happens when your specifications become directly executable? When the spec is not a document you hand to a developer who writes code, but something the LLM runs directly, without intermediary, without translation? In an AI-first workflow today, there is still a human who reads the spec and writes code that translates intent into something executable. The LLM assists, accelerates, sometimes generates most of the code. But the translation step is still there. The question that makes people uncomfortable is not "does that step disappear?" It's "for which categories of problem does it disappear first, and how fast does that line move?" The 70-year movement just reached its logical destination for those categories. Not for all problems. Not even most, yet. But the direction hasn't changed in 7 decades.

Tokenmaxxing and Vibe Coding Are Symptoms, Not Strategies

Here is where I'm supposed to tell you one of these is right and the other is wrong. They're both symptoms of the same thing.

Tokenmaxxing is what you do when you believe more context always helps. Vibe coding is what you do when you believe the LLM handles everything if you stay out of the way. Neither is a strategy. Both are the behavior of someone who can feel the layer shift happening but hasn't developed the mental model for it yet.

A story making rounds in the community: a builder shipped 540k lines. Among them, 276k lines of tests. 33 cron jobs. The post-mortem was brutal. The tests were controlling an agent that didn't need controlling. The cron jobs were monitoring a system already managing itself. All that code was a cage. The instinct was right (control what matters), the model was wrong (code is still how you get control in the new paradigm). YOU DIED. Next time maybe build the jail after confirming the prisoner needs one.

Same impulse, opposite direction: someone builds 2 parallel pipelines for the same task. One is impressive, with feedback loops and cascading agents. The other is 4 files. They put both in front of an LLM and ask which to extend. Given a choice between architecturally impressive and something that just worked in 4 files, the model picked the 4-file version every time.

Both patterns are exactly what early COBOL programmers did when they got access to a high-level language: they structured their code like the assembly they knew before, because they had no new mental model yet. The old model applied to a new layer produces waste in either direction, whether that's 540k lines of cage-building or 1000x token burn on a task that needed 4 files.

The practical starting point for not falling into either trap is the Blueprint method in Vibe Coding, For Real, structured enough that you're not vibe-coding blindly, light enough that you're not building the cage. And at the infrastructure level, why CLIs beat MCP layers for AI agents applies the same lesson to tooling: less abstraction, more predictability.

3 Objections. 3 Historical Parallels.

The 3 serious objections to this layer shift deserve actual answers.

The cost. Agentic AI consumes up to 1000x more tokens than a standard LLM call. Microsoft, Meta, and Amazon all pulled back on internal tokenmaxxing this year. 1 infrastructure builder publicly cited $1.3M in tokens in a single month. That's real money. The parallel: early compiler runs were expensive. IBM charged by CPU cycle in 1957. The question was always whether the productivity gain justified the cost, and it did. Token costs are falling roughly 10x every 18 months. Mintlify cut token consumption 30x by serving Markdown to their agents instead of HTML. Cloudflare cut 80%. The cost objection is a tooling problem with solutions already in production.

The reliability. The ETH Zurich study (438 coding tasks, April 2026) found something counterintuitive: AGENTS.md files generated by LLMs reduced task success by 3% and increased cost by 20%. Human-written AGENTS.md: up 4% on success. The interpretation matters here: this is evidence that the practices for this layer are 2 years old, not 20, not that LLMs fundamentally can't be trusted. FORTRAN was unreliable in 1957. It took years of accumulated production failures before teams trusted it in critical paths. We are at the 1959 equivalent with agentic AI. The practices are forming now, exactly as they always have.

The security. Real, and not yet resolved. Buffer overflows were discovered in the 1970s and are still found in legacy code today. SQL injection was described formally in 1998 and remains in the OWASP top 10. Security problems introduced by new abstraction layers are engineering problems that get solved over time, with incidents along the way. The LLM layer has its own version already. That's not an argument against the layer.

What You're Actually Deciding

The 7 devs couldn't name their discomfort. Here is what it is: the perimeter of their job moved. The job didn't disappear. The perimeter moved.

Code is not going away. It is becoming the language of the deterministic layers, the parts where being wrong costs something real. A payment validation, a webhook routed to the right handler based on a fixed enum, an auth boundary, an operation that must succeed exactly once or not at all — those problems live in code because code is auditable, testable, deterministic. You don't tokenmax your way through a financial transaction.

Natural language takes the intentional layers: generating a product description from user input, deciding which content to surface for a user segment, drafting a response to a support ticket that landed in an edge case your spec didn't cover. Those problems live in prompts and specs because they're about expressed intent, where iteration on behavior matters more than exact execution. The spec becoming directly executable is the point there, not a risk.

The concrete question for a builder today isn't "do I still write code?" It's "where does this specific problem live?" Payment validation lives in code, and so does routing a webhook to a fixed enum or enforcing an auth boundary. Generating product descriptions from user input lives in a spec, and so does tuning an email subject line to a user's history. The line moves as LLMs get more reliable in deterministic contexts. But the mental model for drawing it is available right now.

The professor deciding his curriculum by September has a cleaner answer than he thinks. Teach why code exists at all. What a type is, what an exception is, what it means for an operation to be idempotent. Not PHP specifically, because specific languages matter less every year. Students who understand why determinism is valuable will know what to reach for and when, across whatever the stack looks like in 4 years.

How to stop gambling on prompts and start shipping is a practical framework if that's where you're stuck on the intentional side.

The blank at the end of the sentence those 7 devs couldn't fill wasn't ignorance. It was lucidity, arriving before the vocabulary did.

The shift already happened. Now the vocabulary needs to catch up.

Sources

• Tom's Hardware, "AI cost crisis hits tech giants as employee tokenmaxxing backfires" (May 23, 2026): https://www.tomshardware.com/tech-industry/artificial-intelligence/ai-cost-crisis-hits-tech-giants-as-employee-tokenmaxxing-backfires-agentic-ai-eats-up-to-1000x-more-tokens-than-standard-ai-sparks-corporate-pullback-at-microsoft-meta-and-amazon
• Kamil Banc, "Token maxing is what you do when you can't budget" (AI Adopters Club, May 12, 2026): https://aiadopters.club/p/token-maxing-is-what-you-do-when
• ETH Zurich SRI Lab, 438 coding tasks study (arxiv, April 2026): https://arxiv.org/abs/2503.13501

This post may contain affiliate links. If you click them, I might earn a small commission — costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure.

---

If you're feeling the shift but can't name it, that's the real signal. The welcome kit includes the Production CLAUDE.md template—built for devs navigating this exact transition—plus two other tools for shipping with AI instead of vibe-coding.

→ Get the welcome kit