Software Engineering Is Not Ending. It Is Growing Up

Another week, another headline saying software engineering is over. If you run a business, that noise is unhelpful. What I see on real builds is less dramatic and more useful: the work still needs specs, tests, and follow through. The win is not a pile of bots. It is work that finishes dependably.

Founders send me these headlines and ask a plain question: should I still pay for engineering if AI writes the code now? Short answer: yes, but what you are paying for has changed. You are not buying lines of code. Code got cheap. You are buying completion you can trust, on work that matters, without babysitting the machine.

I build agent systems most days. The current setup that actually ships is a hybrid: agentic loops and graphs for the doing, plus spec driven planning and test driven checks for the proving. That combo is the whole ballgame right now. Drop either side and you get demos that impress and systems that fall over.

The headline is wrong but the shift underneath is real

Something did change. For fifty years the job was mostly this: a person breaks a problem down, writes the decision logic into code, then patches that code as the business changes. Code held the logic. Code was the asset.

With agents, that flips for a lot of routine work. The model reasons through the task and writes throwaway code as a tool to get there: a quick script to pull data, a check against an API, a file transform it runs once and drops. The durable part is no longer the script. It is the loop that plans, acts, checks, and corrects. I wrote about that move from single prompts to loops in From Prompting to Loop Engineering, and the next step from simple loops to graphs in From Loop Engineering to Graph Engineering.

So the headline writers see disposable code and declare engineering dead. They miss where the engineering went. It moved up a layer, into designing the loop, the graph of steps, the checks at each edge, and the rules for when a human steps in. That design work is engineering, just with different materials.

If you sell software by the seat or by the line of code, this feels like an ending. If you buy outcomes, it is good news, because routine build cost keeps dropping while the premium moves to reliability.

What agentic work looks like on a real job

Forget the stock photo of a robot team. Here is the shape I use when it has to work more than once:

A harness sits around everything. It holds credentials, budgets, timeouts, logs, and permissions. Nothing runs loose. Inside the harness runs a loop: look at the task, pick a tool, run it, read the result, decide the next step. For simple jobs that loop is enough. For jobs with branches, approvals, or parallel paths, that loop becomes a graph: defined nodes, defined edges, clear handoffs, places where the run can pause and wait.

I laid out those three layers in Harness, Loop, Graph: The Three Layers Behind Reliable AI Agents. The layer people skip is the harness, and that is where production systems live or die. Anyone can demo a loop. Fewer can show you logs, cost per run, retry behavior, and what happens when a tool returns garbage.

The agents themselves stay small and short lived in my shop. One task, one clear input, one checkable output, then it goes away. I stopped keeping a cast of named personalities around because they collect stale context and odd habits. Small scoped runs are easier to test and cheaper to rerun. I wrote up why in Scoped Agents Beat One Big Agent.

That is the doing side. Alone, it is not enough.

Spec driven plus test driven is the part you cannot skip

Models are fluent and confident, which is exactly why you pin them down before they run. I start every serious build with a short spec a person can read in five minutes: what done means, what is out of scope, which systems it may touch, what it must never do, and how we will check the result. If done cannot be stated plainly, the agent will invent its own definition and you will find out in production.

From that spec I pull acceptance checks that a machine can run. Not vibes. Checks. Does the invoice match the order? Did the file land where it should? Did the API return the shape we agreed? Some checks are plain code assertions. Some are a second model grading against a rubric. Either way, the run is not finished when the first draft appears. It is finished when the checks pass.

The habit comes straight from test driven development, just widened. Write the expectation first, then let the agent work toward it, then keep the tests so the next change has something to argue against. On code tasks this means real tests in the repo. On operations tasks this means the same idea: expected inputs, expected outputs, recorded evidence. The teams that treat agents like junior builders with a strict reviewer ship faster than teams that treat them like magic.

This hybrid is unglamorous and it works. Spec keeps the agent pointed at the right job. Tests catch the fluent wrong answer. Loops and graphs give it room to recover without starting over. Take away the spec and tests and you get fast output nobody trusts. Take away the loop and graph and you get a careful plan nobody executes.

Bots are cheap. Dependable completion is the product

Here is the line I keep repeating to buyers: do not pay for bots, and do not pay for code volume. Pay for completion you can count on.

A collection of bots is easy to demo. Ten agents with names, a dashboard, a chat box. It feels like a workforce. Then you run it on Tuesday data instead of demo data and three steps fail quietly, one step bills the wrong customer, and nobody can tell you which run did what. The code exists. The work did not complete.

Dependable completion looks boring by comparison. Same task, hundred runs, known pass rate. When it fails, it fails loud and stops. Every run leaves a trail: what it tried, what the tools returned, what it checked, where a person approved. Reruns cost pennies and behave the same. That is the product, whether the buyer ever sees the word agent or not.

How I test tool calls before anything ships is a decent window into this. I check selection (right tool?), arguments (right shape?), and sequence (right order?), with deterministic checks where possible and a judge model where judgment is needed. Full routine is in How I Test Tool Calling Before an Agent Touches Production. It reads like plumbing because it is plumbing. Plumbing is what keeps the house dry.

This is also why prompt skill alone stopped being the differentiator. A clever prompt helps one step. A sound harness with specs and tests helps every run after it. Founders sometimes ask for the prompts, as if that file is the asset. The asset is the system that finishes the job when the prompt meets messy reality.

What I actually run on client builds

Plain version, no mystique. For a typical operations or build task:

First, a one page spec with done criteria. The client signs off in words, not nods. Second, a small graph with named steps and owners: machine steps, check steps, and the one or two places a person must approve. Third, checks wired to each step that matter: schema validation, totals that reconcile, files that exist where claimed, links that resolve. Fourth, a harness with a budget per run, a time limit, and full logs. Fifth, a trial batch on real data, usually fifty to a hundred runs, where we measure pass rate and fix the top two failure modes before calling it live.

That trial batch surprises people. The first pass rate is rarely pretty. Forty or sixty percent on messy inputs is normal. The work is in the next two weeks: tighten the spec where the agent guessed, add a check where it drifted, split one fat step into two thin ones, add a human approval where the cost of error is high. Pass rate climbs into the nineties. That climb is the engineering. Nobody applauds it and everybody depends on it.

I keep the pieces small on purpose. A focused step with a clear contract beats a grand agent that does everything and explains nothing. Small steps are testable, replaceable, and cheap to rerun when a provider changes a model or an API shifts under you.

What this means if you are buying software work

If a vendor pitches you a fleet of agents, ask what happens on run number two hundred. Ask for the pass rate on your data, not demo data. Ask what a failure looks like and who gets woken up. Ask to see a log from a failed run and the check that caught it. Ask what one run costs and how long it takes. If those answers are vague, you are being sold bots, not completion.

If a builder tells you engineering is dead and all you need is prompts, get a second opinion. Prompts are the easy tenth. Specs, graphs, tests, harnesses, evals, and someone willing to sit through the ugly first batch: that is the other nine tenths. It still takes judgment, and it still takes someone who has watched systems fail in ways the demo never shows.

None of this argues for big process or slow process. The spec I described fits on one page. The test suite starts with five checks. The graph starts with four boxes. Small and strict beats large and loose. Start narrow, prove completion, then widen the job the system is allowed to touch.

Frequently asked questions

Is software engineering really ending? No. The routine of hand writing every line is shrinking, but designing specs, loops, graphs, checks, and safe failure behavior is growing. The title sells the scare. The work moved up a layer toward reliability and completion.

What is agentic engineering in plain terms? It is building systems where a model plans and acts through tools inside a loop or graph, with a harness for safety and tests for proof. You define done up front, check each step, and keep logs so failures teach instead of repeat.

Why combine spec driven and test driven methods with agents? Specs stop the agent from solving the wrong job. Tests catch fluent wrong answers before they reach customers. Loops and graphs give the agent room to retry sensibly. Each piece covers a weakness in the others.

What should I pay for: agents or outcomes? Outcomes. Count finished jobs that passed checks, on real data, at a known cost per run. A pile of bots with no pass rate is a demo. A narrow system that completes dependably is an asset you can build on.

If your team is staring at an agent demo that works on stage and wobbles at work, book a call and I will tell you plainly whether you need a tighter spec, better checks, or a smaller first job, because that diagnosis decides everything after it.

About the Author

I'm Brian Marvin, an AI-native Fractional CTO with 30 years in technical leadership. At empowered.guru, I help startups turn agent demos into systems that finish work dependably, without burning down what already runs.