Writing

From Code to Intent: The Future of Software Development

Every era of software moved developers one layer further from the machine. AI is the next move: from writing code to stating what it must do, and proving that it does.

Harish DarkoJuly 6, 2026revised November 7, 20266 min read

An earlier version first appeared on LinkedIn on July 6, 2026. I rewrote it here to tighten the argument, and added two diagrams and an example from my own work. Read the original and comment there ↗

We already trust layers we never read

Few developers ever read the machine code their software runs on. We trust the compiler, the runtime, the framework, the cloud platform, the pipeline and the managed database. That trust took decades to build, one layer at a time.

Each layer took detail off our hands. Assembly gave names to machine instructions. C, Java and Python let us think in logic instead of registers. Frameworks went one level higher: a Spring Boot developer does not write an HTTP server, a React developer does not update the page by hand, and a Terraform user does not click through a cloud console.

The question keeps changing

First the question was “How do I make the machine do this?” Then it was “How do I build this application?” Then “How do I deploy and run this system?” Each one lasted long enough for whole careers to be built on answering it.

AI changes the question again: what outcome do I want, and how do I prove the system delivers it?

This one is harder to accept than the others. For a long time, code was the center of what it meant to be a developer. Languages, syntax and frameworks were the job. They still matter, but I do not think they stay the deepest source of value for much longer.

AI coding tools already show why. Describe what you want and a draft appears. Ask for tests, a refactor, a Terraform module or a debugging idea, and something usable shows up in seconds. But fast isn’t the same as correct, and that gap is where the developer’s job moves.

Intent plus verification

If AI writes the code, someone still has to know what the code must do, where it can fail, who it affects, whether it is secure, whether it holds up under load, and how to prove all of that. The job does not disappear. It moves from typing every line to shaping the system and proving how it behaves.

The real shift is intent plus verification.

Verification matters more, not less, once AI writes code faster than anyone can read it. We already live with a version of this. Almost nobody reads what the compiler produces, and we are fine with that because of everything around it: language rules, tests and years of it working. Generated code is heading the same way. We will not read every AI-written change as closely as we read hand-written code today, but we will need to know exactly where to look:

• Does this API reject bad input?
• Does this database change quietly break existing data?
• Did this generated Terraform make something public by accident?
• Does this AI-written test only cover the happy path?
• Does any of it still meet the business requirement?

What it looks like in practice

That is the loop on a small scale. The intent was plain: one station’s data must never overwrite another’s. AI helped write the code fast. The verification is what lets me stand behind it. I keep a log of catches like this on my How I work page.

Who answers for it

None of this means the fundamentals disappear. People still learn C, and people still learn SQL even though tools write most of it for them. The lower layers matter the moment something breaks. But the daily center of gravity moves, and one question moves with it: who is accountable when the software is wrong?

If a payment system charges the wrong amount, nobody cares whether a person or a model wrote the line. If a healthcare system sends the wrong alert, the harm is the same either way. If a deployment exposes private data, “the AI wrote it” satisfies nobody. Software still needs a person who owns the outcome, and better tools do not automate that away. That raises the stakes for developers. It does not lower them.

The shape of the team

I picture the next few years as a main AI agent coordinating smaller ones. One checks requirements. One writes backend code. One writes tests. One looks for security issues. One prepares the deployment. One summarizes what happened in production after the release.

The engineer sets the target, checks the output, resolves the ambiguity that nobody could automate, and owns what ships. So the strongest engineers will look a little different. Technical depth still matters, and so does product sense: knowing how customers use the product, explaining a decision clearly, and designing systems that can be watched, corrected and improved instead of shipped once and forgotten.

This pulls software closer to the business, not further from it. Take a support ticket classifier. It should not just tag a ticket “Billing” or “High priority” and stop. It should show why, point to the words that led to the call, flag a risk to the response deadline, let a person override it, and track whether it keeps making the same mistake. That is what accountable software looks like when AI does the first draft.

The center keeps moving

The history of this profession is the center of gravity moving: from machine instructions to languages, to frameworks, to cloud platforms, to automated delivery, and now to intent, with AI doing the drafting.

Each move felt like a loss of control at the time. It was not. It changed what control meant. I think this move is the same kind of change: a different job, not a smaller one.

The developers who grow with it will keep learning technical skills, just different ones: how systems behave, how users think, how a business defines value, and how to prove that software does what it was built to do. That was always the work underneath the syntax. Less memorizing, more understanding. It might be the most human part of the whole thing.