tech February 28, 2026 9 min read Erley Blanco Carvajal

From Assembly to English: Do We Code or Just Ask Now?

From bits to plain English: are we coding or just asking AI now?

01 — Article

From Assembly to English: Do We Code or Just Ask Now?

"Any sufficiently advanced technology is indistinguishable from magic."
— Arthur C. Clarke

I've been writing code for over a decade. I've wrestled with pointers in C, debugged segmentation faults at 2 AM, loved and hated JavaScript with equal passion. And today, as I type in plain English to an AI that builds entire systems for me, I can't help but ask: are we still programmers, or have we quietly become something else entirely?

This is the story of how we got here. And an honest look at where we might be going — whether we like it or not.

Level 0: Talking to the Machine in Its Own Language

Before there were programming languages, there was just the machine.

In the late 1940s and early 1950s, programmers didn't write code — they wrote instructions in binary, sequences of 0s and 1s that maps directly to electrical signals. Then came Assembly language (1947–1950s), and it felt like a miracle: instead of memorizing binary opcodes, you could write MOV AX, 1 and a program called an assembler would translate it for you.

MOV AX, 5
MOV BX, 3
ADD AX, BX   ; AX = 8

You were still thinking like the CPU. Every register, every memory address, every clock cycle was yours to manage. The machine spoke machine. You learned its dialect.

The cognitive gap between human intent and executable code was enormous. And programmers were, by necessity, more machine than human in their thinking.

Power level: Absolute. Abstraction: Zero. Human cost: Brutal.

Level 1: The Compiler Revolution — FORTRAN and COBOL (1957–1960)

Then John Backus at IBM did something radical. He asked: why can't we write code that looks more like math?

The answer was FORTRAN (1957) — the first high-level compiled language. Suddenly you could write:

Y = A * X**2 + B * X + C

And a program — the compiler — would turn it into the messy machine code for you. This was not just a technical leap. It was a philosophical one. You no longer needed to think like a machine. You could think like a mathematician.

COBOL followed in 1959, and it pushed even further: business logic written in something resembling plain English sentences.

ADD YEARS-OF-SERVICE TO BASE-SALARY GIVING TOTAL-COMPENSATION.

Managers could almost read it. Auditors could almost understand it. The programmer was starting to speak human.

"We wanted to make programs look more like the problems they solved." — Grace Hopper, co-creator of COBOL

Level 2: The Democratization — C, Pascal, and Structured Thinking (1970s)

Dennis Ritchie created C in 1972, and it changed everything. It was low enough to touch the hardware, high enough to be portable. Unix was written in it. Operating systems were written in it. The internet would eventually run on code written in it.

#include <stdio.h>
int main() {
    printf("Hello, World!\n");
    return 0;
}

Simple. Direct. Powerful. C didn't hide the machine — it framed it in a way humans could reason about.

Then Pascal taught us to think in structures. Modula-2 introduced modules. Slowly, programming was becoming less about talking to hardware and more about expressing ideas. The architecture of a program began to matter as much as its efficiency.

The programmer was no longer a machine whisperer. They were becoming a designer.

Level 3: Objects, Abstraction, and the Rise of the Architect (1980s–1990s)

Object-Oriented Programming was the great philosophical shift. Smalltalk pioneered it. C++ forced it into the mainstream. Java made it ubiquitous.

public class BankAccount {
    private double balance;

    public void deposit(double amount) {
        this.balance += amount;
    }

    public double getBalance() {
        return this.balance;
    }
}

Now you weren't just writing instructions — you were modeling reality. A BankAccount wasn't a bunch of memory addresses. It was a thing, with behaviors, with state, with relationships.

This era produced a new kind of programmer: the software architect. Someone who thought in patterns, in systems, in abstractions. Design Patterns (1994) by the Gang of Four became the bible. UML diagrams covered whiteboards.

The distance between human thought and code was shrinking fast. But the learning curve was still steep, and the priesthood of programmers remained small.

Level 4: Scripting, the Web, and the Explosion of Developers (1990s–2000s)

Perl, Python, PHP, Ruby, JavaScript. The web needed code, and code needed to be written by more than just computer science graduates.

Python, created by Guido van Rossum in 1991, was almost philosophical in its design: code should read like pseudocode. Indentation wasn't optional — it was enforced. Clarity wasn't a preference — it was a value.

def greet(name):
    return f"Hello, {name}!"

print(greet("World"))

JavaScript brought programming to every browser on the planet. Suddenly, millions of people who never took a CS course were writing code. The barrier to entry collapsed.

GitHub launched in 2008. Stack Overflow launched the year before. The collective knowledge of programmers became searchable, forkable, remixable. A teenager in Lagos could build the same things as a senior engineer at Google, if they were curious enough.

Programming stopped being a profession and started becoming a literacy.

Level 5: The Framework Era — Abstraction on Top of Abstraction (2010s)

React. Django. Rails. Spring. Laravel. Angular. Vue.

By the 2010s, most programmers weren't really writing code from scratch anymore — they were assembling and configuring frameworks. You didn't write an HTTP server. You chose Express. You didn't write authentication from scratch. You used Devise or Passport.

// You're not building React. You're speaking React.
function UserCard({ name, avatar, bio }) {
    return (
        <div className="card">
            <img src={avatar} alt={name} />
            <h2>{name}</h2>
            <p>{bio}</p>
        </div>
    );
}

The craft became curation. The skill was knowing which abstractions to trust, which libraries to choose, which patterns to apply. Senior engineers spent less time writing code and more time making decisions.

The machine was now three, four, five layers deep beneath you. You were starting to forget it was there.

Level 6: Natural Language — Claude Code, OpenCode, and the English Interface (2023–Now)

And then, almost quietly, the final abstraction arrived.

Not a new syntax. Not a new framework. A new medium entirely.

You open Claude Code or OpenCode and you write:

Build me a REST API for a task management app. 
Users should be able to create projects, add tasks with due dates, 
and get notifications when deadlines approach. 
Use PostgreSQL and make it production-ready.

And it builds it. Not a scaffold. Not a template. A working, reasoned, structured system — with migrations, error handling, tests, and documentation.

The language is English. The compiler is a large language model. The output is production code.

References:
- Claude Code by Anthropic (2024): https://www.anthropic.com/claude-code
- OpenCode (2024): https://opencode.ai
- "The End of Programming" — Matt Welsh, Communications of the ACM (2023)
  https://cacm.acm.org/magazines/2023/1/267976-the-end-of-programming

For those of us who learned to program the hard way, this feels like a superpower. In a single afternoon, I built things that would have taken me two weeks before. The velocity is intoxicating.

I'm not going to pretend otherwise: this is extraordinary.

The Question Nobody Wants to Ask

But here's where I slow down. Here's where I stop celebrating for a moment.

Every level of abstraction we've described above gave us more power while keeping us in control. You wrote Python and you understood what Python compiled to. You used React and you understood the DOM beneath it. The abstraction was a convenience, not a dependency.

What happens when the abstraction is a mind?

When I ask Claude Code to build a system, I don't always understand every decision it makes. I trust it. I review it. But increasingly, I trust it faster than I review it carefully. The pace rewards trust. The deadline rewards shipping.

And here's the uncomfortable progression:

We built tools to write code faster.
Tools became so good we stopped understanding all the code.
We started reviewing AI output instead of writing from scratch.
We optimized for velocity over comprehension.
The AI learned from codebases we no longer fully understand.
We shipped systems neither we nor the AI can fully explain.

At what point does "the AI helps me code" become "the AI codes and I approve"? At what point does "I approve" become "I trust without fully checking"? At what point does the AI decide what gets built and why?

"The real danger is not that computers will begin to think like men,
but that men will begin to think like computers."
— Sydney J. Harris, journalist (1960s)

He wrote that before the internet existed. He had no idea how right he'd be.

The Optimistic Case — And Why I Still Believe It

I want to be honest with you: I'm not writing this from fear. I'm writing it from fascination.

Because the same evolution that worries me also thrills me. Every abstraction in history expanded who could create. Assembly was for specialists. C was for engineers. Python was for everyone with curiosity. English-as-code is for humanity.

A doctor in Nairobi can now build the patient management tool her clinic needs — without a developer budget. A teacher in Vietnam can create an interactive lesson platform — without knowing what a for-loop is. A small founder in Buenos Aires can ship an MVP in a weekend — without a technical co-founder.

The democratization is real. The leverage is real. The creativity unlocked is real.

The programmers who thrive in this era won't be the ones who type the fastest or memorize the most syntax. They'll be the ones who:

Think clearly about what needs to be built and why
Understand systems deeply enough to review AI output critically
Ask better questions — because better prompts produce better systems
Know when to trust the AI and when to push back

The craft doesn't disappear. It transforms.

What Comes After English?

If the pattern holds — and it has held for 70 years — the next level of abstraction is already forming.

Maybe it's intent-based programming: you describe outcomes, not implementations. "I want user retention to increase by 20%" — and the system designs, tests, and deploys the features to achieve it.

Maybe it's autonomous agents: AI systems that don't wait for prompts but continuously observe, decide, and act on your behalf.

Maybe it's something we genuinely cannot imagine yet — the way a FORTRAN programmer in 1957 couldn't have imagined React hooks.

But here's what I know: at some point in this trajectory, the question "are we programming the machine, or is the machine programming us?" stops being philosophical and starts being practical.

The tools we build shape the thoughts we think. The abstractions we rely on define the problems we can see. If we outsource enough of our reasoning to AI systems, we may find ourselves unable to reason without them.

That's not dystopia. That's just dependency. And dependency can be managed — but only if we see it coming.

The Programmer's New Responsibility

The job title will stay the same for a while. But the job is changing completely.

We used to be translators — converting human intent into machine language. Then we became architects — designing systems at scale. Now we are becoming curators and critics — directing intelligence we didn't build and can't fully audit.

That's an enormous amount of power. And an enormous amount of responsibility.

The best thing we can do is stay curious. Stay critical. Keep learning the layers beneath the abstraction, even when the abstraction is good enough. Because the day we stop understanding what's below us is the day we stop being able to steer what's above us.

We built all of this. We can shape where it goes.

But only if we're paying attention.

References

Backus, J. (1978). Can Programming Be Liberated from the von Neumann Style? ACM Turing Award Lecture. https://dl.acm.org/doi/10.1145/359576.359579
Ritchie, D.M. (1993). The Development of the C Language. https://www.bell-labs.com/usr/dmr/www/chist.html
Hopper, G. (1978). The Education of a Computer. Annals of the History of Computing.
Welsh, M. (2023). The End of Programming. Communications of the ACM. https://cacm.acm.org/magazines/2023/1/267976-the-end-of-programming
Anthropic. (2024). Claude Code. https://www.anthropic.com/claude-code
OpenCode. (2024). AI-Native Development Environment. https://opencode.ai
Gamma, E., Helm, R., Johnson, R., Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
Harris, S.J. (1964). Majority of One. Houghton Mifflin.
GitHub Octoverse Report. (2023). The State of Open Source Software. https://octoverse.github.com
Stack Overflow Developer Survey. (2024). AI Tools in Development. https://survey.stackoverflow.co/2024