Natural Language is the New Source Code, Engineered by Intent
When I was interested in starting my career in software 20 years ago, I would ask my mentors: "What language should I learn?"
Everyone had an answer. "Learn Java, big companies run on it." "Python, it's the future!" "PHP is everywhere, just learn PHP!" The assumption was always the same: pick the right language, master syntax, and you'll be valuable. Your career would be defined by the code you could write.
For two decades, that held true. A software company's value (it's IP!) lived in its codebase, millions of lines of logic, written by engineers, protected like crown jewels. The language you chose mattered because writing the code was the hard part.
We are approaching a transition.
When an AI agent can generate a thousand lines of working code in any language in seconds, the code itself becomes a commodity. Java, Python, PHP, it doesn't matter. The question my mentors never had to consider is now the only one that matters: it's not what language you write in, it's how you define what you want.
The new answer to "what should I learn?" isn't a language. It's Intent.
The companies that will dominate the next decade aren't the ones writing the most code. They're the ones who get frighteningly good at defining what the code should do, with enough precision that both humans and AI agents can execute against it without ambiguity.
This isn't a theory. It's already happening.
The Problem Nobody Talks About
(... Okay, we're starting to. I mean we're talking here about it. )
Here's what I'm seeing across engineering organizations right now: teams are adopting AI coding tools and getting a massive speed boost on day one. Then within weeks, they're drowning in AI generated code that mostly works but fails in weird, hard to trace ways.
Why? Because speed without specification is just faster chaos.
When you tell an AI "build me a rate limiter," it will. It'll generate something plausible. But plausible isn't production grade. The AI fills in every ambiguity with its best guess, and those guesses compound into systems that look right but behave wrong under pressure.
The fix isn't better AI. The fix is better input.
From Writing Code Based on Requirements to Architecting Requirements with intent
The most effective engineering teams I work with have flipped their workflow using two practices that have been around for decades but are now more relevant than ever: Behavior Driven Development (BDD) and Test Driven Development (TDD). (Shout out to Kent Beck who inspired me)
Recommended by LinkedIn
BDD is the "what." You define system behavior in plain language that any stakeholder can read and validate. TDD is the "how." You write the technical tests before writing any code, so you know exactly when you're done.
Together they form a translation pipeline. A human says: "Given a user has exceeded 100 requests per minute, when they make another request, then the system returns a 429 status and a retry header." That's not pseudo code. That's a real, executable BDD specification. It gets translated into automated tests (TDD), and only then does anyone, or any AI write the implementation.
The specification becomes the source of truth. Not the code underneath it.
When an AI agent works against that kind of contract, something happens: it can't hallucinate its way past a failing test. The BDD spec defines the expected behavior, the TDD tests enforce it, and the agent iterates until every condition passes. No hand waving. No "it looks right to me."
Microsoft Research validated this approach in 2024 and found roughly a 46% improvement in code generation accuracy when AI was given formalized test driven specifications versus open ended prompts. That's not a marginal gain. That's a different category of reliability.
Beyond Engineering: Where Your IP Actually Lives
This isn't just an engineering process improvement. It's a strategic shift in where your intellectual property lives.
When your specs are the source of truth, three things happen:
Your systems become portable. Need to move from one language to another? You don't rewrite the logic. You point the agent at the existing specs and generate a new implementation. The business rules survive any technology migration.
Your systems become auditable. When something breaks, you don't debug a black box of AI generated code. You look at the plain language spec and ask: did we define the behavior correctly, or did the implementation drift? That's a question any stakeholder can engage with, not just your most senior engineer.
Your systems become resilient to turnover. The specs are readable by anyone. New engineers, new AI tools, new vendors, they all inherit the same unambiguous contract. Your knowledge doesn't walk out the door when people do.
Quality Is a Part of Intent
The organizations that treat AI as a faster typist are going to get faster at building fragile systems. The organizations that treat AI as an executor of well defined intent are going to build something fundamentally more durable.
The skill that matters now isn't writing code. It's the ability to formalize what you actually want, precisely enough that any agent, human or artificial, can deliver it without guessing. The future belongs to the architects of intent.
If you aren't writing your tests first, you aren't leading the AI, you're just following it into a debugger.
It would seem that the mark of a developer is no longer in simply memorizing features, syntax, and traits of languages. But in having lived through using them.
AI is amazing when used with agents and tests. People have used them to do things like add passkey support to a small website, create dashboard websites, reverse engineer old NES and arcade games, and so on. However, based on my personal use, you really do have to double check the output. Sometimes the code looks reasonable but it hallucinates code that doesn't exist, and other issues. But it does speed up work.