Torras.ai

For most of the history of software engineering, progress has followed a clear pattern: abstraction replaces mechanics.

We began by programming machines in the most literal way possible. Early developers wrote machine instructions directly, manipulating registers and memory addresses. It was powerful, but cognitively expensive. Every detail had to be managed manually.

Assembly language abstracted raw binary into symbolic instructions. It did not remove complexity, but it made it manageable.

 mov eax, [price]
 sub eax, [tax]
 mov [net_amount], eax

Then came higher-level languages. Among the earliest were Fortran and COBOL, each representing a significant conceptual leap. Fortran allowed engineers to express mathematical formulas in a way that was closer to how they already reasoned about them. COBOL attempted something even more ambitious: it sought to bring programming closer to the language of business.

A typical COBOL instruction might read:

SUBTRACT TAX FROM PRICE GIVING NET-AMOUNT

Rather than the more compact expression you would see in many later languages:

net_amount = price - tax;

The creators of COBOL believed that if programs resembled English, business users could more easily read and perhaps even write them. It was an early attempt to narrow the gap between human intention and machine execution.

Yet COBOL was not English. It was a formal language designed to look like English. It remained rigid, deterministic, and syntax-bound. Humans still had to adapt to the machine’s structure. The abstraction reduced the cognitive burden of low-level programming, but it did not eliminate the translation layer between intent and implementation.

That translation layer has defined the profession of software engineering for decades.

Declarative Intent: The Case of SQL

There was another important moment in this evolution that is often overlooked: the arrival of SQL.

Structured Query Language (SQL) was different from most programming languages that preceded it. It was declarative. Instead of telling the system how to retrieve data — which indexes to traverse, which loops to execute, which joins to compute first — the developer simply described what data was needed.

 SELECT name, balance 
 FROM accounts 
 WHERE balance > 1000;

This was a profound abstraction shift. The engineer expressed intent. The database engine decided the execution plan.

In that sense, SQL was closer to natural language than most procedural languages. It read almost like English. It focused on describing the desired outcome rather than prescribing the sequence of operations required to achieve it.

And yet, despite its accessibility, SQL never truly became a language for business users. It remained technical. Writing correct queries required understanding schemas, relationships, performance implications, normalization, indexing, and transactional behavior. The abstraction simplified execution, but it did not eliminate the need for expertise.

SQL was an early demonstration that describing what instead of how is powerful. But the translation layer still existed. Humans still had to think in structured, formal syntax. The system optimized execution, but it did not interpret ambiguous intent.

The Translation Layer

Traditionally, building software has required a conversion process:

1. A business problem is expressed in natural language.
2. A developer translates that description into structured requirements.
3. Those requirements are translated into code.
4. The machine executes that code.

The core value of the developer has long resided in this translation ability. Syntax knowledge, familiarity with frameworks, and recall of library functions were all part of making that translation efficient and accurate.

However, the arrival of large language models has begun to alter this dynamic in a fundamental way.

Today, it is possible to write something like:

 Design a modular payment processing system with idempotent operations, 
 audit logging, retry logic with exponential backoff, 
 and integration tests simulating network failures. 
 It must follow the existing application’s architecture and conventions, 
 including the same coding style, framework choices, database patterns
 (ORM, migrations, transactions),logging/observability stack, 
 configuration approach, and deployment practices. Reuse existing 
 libraries and utilities wherever possible, and avoid introducing new 
 dependencies unless strictly necessary. 

This is not code. It is structured intent.

And yet, a capable AI system can transform that intent into scaffolding, test cases, and even architectural patterns within seconds.

This is not simply automation of boilerplate. It is automation of translation.

The Shift in Scarcity

Every abstraction layer changes what is scarce.

When compilers became reliable, memorizing assembly instructions stopped being valuable. When frameworks matured, hand-writing infrastructure code stopped being a differentiator.

Now, as AI systems generate syntactically correct and often structurally sound code, the scarcity is moving again.

The valuable skills increasingly include:

• Precise articulation of requirements
• Decomposition of complex systems into manageable components
• Explicit definition of constraints and edge cases
• Architectural reasoning
• Critical evaluation of generated output
• Testing and validation discipline

Memorizing syntax or recalling obscure API details becomes less central, because those tasks are increasingly automated.

This does not eliminate the need for deep technical knowledge. On the contrary, it amplifies the importance of judgment. Engineers must still understand performance implications, security trade-offs, concurrency risks, and system boundaries. But the mechanical act of writing code is no longer the sole bottleneck.

Intent becomes the durable asset.

English as a Programming Layer

To say that English is becoming a programming layer is not to suggest that formal languages disappear. Compilers, runtimes, and execution environments still operate on structured code.

Rather, English — or more precisely, structured natural language — is becoming the highest abstraction layer above traditional programming languages.

The flow increasingly looks like this:

 Intent (natural language)
 → Structured generation (AI)
 → Formal code
 → Machine execution

In this model, code becomes an intermediate artifact. It can be regenerated, refactored, and optimized automatically. What remains stable is the problem definition and the clarity of constraints.

The quality of the final system depends less on the developer’s ability to recall syntax and more on their ability to describe what the system must do, under what conditions, with what guarantees, and against which failure modes.

Natural language becomes executable not because it is inherently precise, but because AI systems have become capable interpreters.

Who will build Software Now?

This shift raises a deeper question than how engineers should be trained. It raises the question of who will program.

If AI systems can translate structured intent into executable software, will business users finally be able to build what they need directly? Will natural language become sufficiently precise that domain experts can describe systems without intermediaries?

History suggests caution. COBOL tried to bring programming closer to business language. SQL allowed users to describe what data they wanted instead of how to retrieve it. Both were meaningful abstraction shifts, and yet both remained technical tools. The translation layer did not disappear; it simply moved.

Perhaps this time is different. Perhaps AI systems will absorb enough complexity to allow non-technical users to operate safely at a higher level of abstraction.

Or perhaps technical professionals will remain essential — not as typists of syntax, but as designers of constraints, architects of systems, and guardians of correctness.

Even if English — or any other natural language, for that matter — becomes the highest abstraction layer, somewhere underneath, COBOL will continue processing transactions, compilers will continue optimizing instructions, and formal code will still execute deterministically.

Abstractions evolve. Infrastructure persists. Value moves upward.

Whether AI democratizes programming completely or simply elevates the role of engineers to a higher layer, only time will tell.