The End of Building From Scratch: Software in the Agent-Native Era

I think we are reaching the end of a certain kind of software company.

Not the end of software. Not the end of engineering. Definitely not the end of taste, architecture, or hard technical work.

I mean the end of the default belief that the highest-leverage thing you can do is build another standalone app from scratch.

I was wrong about the unit of leverage.

It's not just that AI lets us build more apps but that the ladder moved again.

And this always happens.

Machine code became assembly. Assembly became C. C became Python and JavaScript. Every time, the lower layer stayed real, but the obsession moved upward. The people who won were not always the people doing the old thing faster. They were the people building the new surface everyone else could stand on.

That is the loop.

And now the loop is turning again.

For years, the indie-builder instinct was simple: find a problem, build an app, launch it, iterate, turn it into a SaaS if God is kind.

That made sense when the first working version was scarce. If you could turn an idea into software, you had leverage most people did not.

But AI changed the first implementation from a proof of capability into proof that you had an afternoon.

Not "AI writes code now." Everyone knows that. The real point is this:

When code becomes easy, the moat moves from execution speed to placement.

Where should this thing live?

That question is becoming more important than "can I build it?"

The app is becoming the wrong unit of thought

Most new software does not fail because the builder is stupid.

It fails because it is an island.

Another login. Another dashboard. Another settings page. Another private database shape. Another integration layer that every future tool has to learn separately. Another place a human has to remember to go.

This was annoying when humans were the only operators.

But the next operator is often an agent.

And an agent does not care that your dashboard looks clean. It wants context it can read, tools it can call, permissions it can respect, memory it can update, tests it can run, logs it can inspect, and a workflow it can hand off without losing the plot.

That is what I mean by agent-native.

Agent-native software is not "AI inside the product."

Most of that is just the old product wearing an AI jacket.

Agent-native software is built so agents can understand it, operate it, compose it, and improve it. It treats agents as workers in the system, not as a chatbot bolted onto the side.

You can already see the shape if you stop looking for one killer app and start looking under the apps.

Start with CLI tools, honestly. They are already agent-native in the most boring, practical way: Claude Code, Codex, and other coding agents can read files, call commands, run tests, inspect logs, and hand the work back through the terminal. Then MCP exists because every model-to-tool integration cannot be a custom one-off forever. A2A exists because agents coordinating across vendors cannot be a pile of hacks. Paperclip treats agent work like company work: goals, agents, budgets, blockers, approvals. Multica turns coding agents into assignable teammates. Hermes Agent points at persistent memory and learned skills. HyperFrames makes video creation something an agent can author through HTML, CSS, and JavaScript.

These are not just products.

They are places where work can compound.

If I build a closed one-off app, I get one artifact. Maybe it works. Maybe people clap on launch day. Maybe I get a demo that feels powerful for forty minutes.

But if I improve an agent-native layer, every future agent that can read that layer gets a little more capable.

That is a different kind of leverage.

And, once you see it, normal app-building starts to feel slightly strange.

Why n8n still sits in my head

I need to say this carefully because most people talk about n8n like it is just another automation tool.

That is not why it mattered to me.

I was building complex enterprise automation in n8n. Real multi-agent AI systems. Not 10-node toy flows.

Not "when a form is filled, send a Telegram message."

One of the real flows — a multi-agent SEO system, not a toy example.

The same system, deeper in — branches, state, retries.

Messy work. Flows with enough branches and state and retries that if you kept all of it at the code level, you eventually stopped building the thing and started babysitting plumbing. At some point I remember looking at those flows and feeling this weird irritation.

Because I could do it in code.

That was not the issue.

The issue was that I could feel myself working at the wrong abstraction.

Agent plumbing. Observability. Retry logic. Tool calls. Context moving from one place to another. Memory getting written, then read, then accidentally trusted too much. All of this stitched inside code where only the developer can see the real graph. And my brain kept saying: why are we hiding the work?

That was the n8n moment for me.

n8n should have been the layer after high-level languages.

Not "a better Zapier." Not "no-code for technical people." The layer after Python and JavaScript.

Because once code got easier, the obvious missing rung was not more code. It was a visual workflow layer that humans could see, agents could execute, teams could self-host, systems could integrate with, and builders could reuse as protocol. Visual building is not beginner mode.

Done properly, it is the only paradigm where a human and an agent can stand over the same canvas and point at the same flow.

That matters more than people think. Most AI systems become spaghetti because the human cannot see the work graph. The model does something. A tool fires. Memory updates. A retry happens. Some exception gets swallowed. Then suddenly nobody knows what the system believes anymore.

With a real visual workflow layer, the human gets the overview effect without the rocket.

You see the work. You see the branches. You see the handoffs. You see where context enters and where it mutates. You can steer the same structure the agent is using.

That should have been the agent era's control surface. I still think n8n was positioned to own it. The reason it did not fully own it, in my view, is that it stayed too much like a workflow tool and did not go agent-native first.

Imagine if the core abstraction had been context, memory, and agent from the beginning. CMA baked in. Imagine agent-native skills as reusable workflow primitives. A marketplace and agent harness, closer to what Paperclip points toward, where agents could discover, install, and run trusted workflows instead of every builder hand-rolling the same glue. And this is why I still do not dismiss n8n. The thing it revealed is bigger than the product:

The future is not random AI spaghetti.

The future is a visible work graph that agents can run and humans can understand.

The old flex became cheap

A lot of people building software now are not traditional software developers. They are founders, marketers, operators, designers, analysts, creators, domain experts.

They know the problem.

AI gives them execution.

Some developers hear that and treat it like decline, like the craft itself is getting disrespected.

I do not think that is the right read.

The deeper pressure is not on developers as people.

It is on companies that confused software output with software advantage.

AI labs pointed intelligence at coding first because code is a lever.

If a system can write code, inspect code, test code, repair code, and eventually improve the tools around code, you are not just automating developers. You are aiming at the machinery that improves the machinery.

The machinery improving the machinery.

That is why the Fable 5 / Mythos 5 / Gpt 5.4 moment feels strange to me.

I am not going to turn an unsourced lab-rumor into a headline. But the direction is obvious: labs are already thinking about how much of AI training, eval work, tool building, and research plumbing can be automated by AI itself.

That is the recursive loop.

At some point the scary part is not "AI can write the function."

The scary part is that we may not fully understand the system of agents improving the system of agents.

That is where Goodhart's law walks in quietly and ruins the room.

When a measure becomes the target, it ceases to be a good measure. So companies measured velocity, tickets, story points, PRs, shipped features, lines changed, dashboards launched, apps delivered. Then the org slowly optimized for those shapes.

And for a while, that looked like competence.

Now AI can produce those shapes brutally fast.

Because code was measurable.

That is the part I keep coming back to.

Code was never the whole skill. It was the easiest part of the skill to benchmark, reward, fine-tune, and scale.

The main thing was always system thinking: what should exist, where should it live, what should it connect to, what should it refuse to do, and what feedback should change it tomorrow.

I will not be naive and say AI cannot system-think.

It can. It will get better at it.

But humans who have actually built systems still have an edge in judgment. Not because they type better, but because they have scars from watching the wrong thing work perfectly.

That is why the old flex became cheap.

Not engineering.

The flex.

"We can build a dashboard."

"We can launch an app."

"We can ship a prototype in a week."

Okay. So can everyone else with a half-decent agent stack and enough taste to reject the bad output.

The company-level question changes.

What do you know that others do not?

What feedback loop do you own?

What workflow do you understand from the inside?

Which domain expert can you study deeply enough to replicate their process without flattening the thing that makes them good?

What experiment can you run faster because your system is already instrumented?

What layer are you improving so the next hundred runs get better?

That is literally how I think about automation.

I was never really building from scratch.

I was watching how a domain expert thinks, where they look, what angle they choose, what they ignore, what they double-check, and then trying to turn that thinking process into a system.

Coding was just the first domain where this worked at global scale.

It will not stay the only one.

That is the science angle people miss.

Real science was never "write more papers." It was hypothesis, experiment, observation, falsification, repeat. The paper was just the artifact at the end.

Real software is becoming the same thing.

The app is the paper.

The system that asks better questions, runs tighter experiments, measures without lying to itself, and compounds what it learns, that is the lab.

Most companies are still celebrating the paper.

Agents make papers cheap.

Labs are still hard.

And you can already see this outside software.

AlphaFold-class systems made protein structure and molecular interaction prediction feel like a new kind of interface to biology. Oncology is seeing specific, narrow advances in targeted drugs, immunotherapy combinations, genomic testing, and AI-assisted treatment matching.

Not "cancer is cured."

That sentence is lazy and misleading.

But a few specific cancer workflows are moving faster because biology is becoming more computable.

That is the bigger version of "AI makes code faster."

AI makes any encoded process faster.

Code was just the cleanest mirror.

I think it is just the recursion doing what recursion always does.

When the abstraction layer rises, the old scarce skill becomes a building block. Assembly did not disappear because C existed. C did not disappear because Python existed. But the center of gravity moved.

Same thing is happening to writing application code from scratch.

If your identity is "I type code," the ground is moving under you.

If your identity is "I turn ambiguous goals into reliable systems," you are more valuable than ever.

That is the agentic developer.

Not a prompt writer. Not a vibe-coder with confidence. A person who can decide where the work should live, choose the right existing layer, write the right spec, constrain the agent, review the output, catch the lie, design the eval, and turn repeated work into infrastructure.

The agentic developer still knows when to build the app.

But more importantly, they know when the app is the wrong shape.

Maybe the idea should start as a CLI tool. Maybe it should be a plugin. Maybe it should be an MCP server. Maybe it should be a Paperclip company. Maybe it should be an n8n workflow. Maybe it should be a contribution to an open-source repo that future agents already know how to navigate.

This is why I keep coming back to CLI.

Not because every workflow should live in the terminal forever.

Because CLI is already good enough for agents to touch real work.

Files. Commands. Tests. Logs. Diffs. Exit codes.

The boring surface is the point.

Claude Code and Codex do not need a perfect new world to become useful.

They need a path to inspect the work, change the work, prove the work, and hand it back.

Good enough is underrated when it compounds.

That is the shift from information to insight.

Information: AI makes code faster.

Nugget: faster code makes output-shaped software less defensible, especially for companies that mistook output for progress.

Insight: stop asking "what app should I build?" and start asking "what system should learn from this work?"

When building from scratch is still right

This is not an anti-engineering argument.

It is actually the opposite.

Building from scratch is still right when you are inventing a primitive. When performance, latency, safety, security, or compliance makes the existing layer unacceptable. When the abstraction hides the exact domain logic that creates your advantage. When the product is the system itself.

Do not outsource your moat because "agents can code."

That is lazy.

But also do not rebuild commodity foundations because building feels like progress.

That is vanity wearing a hoodie.

The discipline now is knowing the difference.

Most software ideas do not need a new island. They need to live inside the continent agents are already learning to navigate.

And that is why "building from scratch" is ending as a default posture.

Not because nobody should ever build deeply again.

Because deep building is moving upstream.

The raw part

The old builder loop is emotionally addictive.

You get an idea. You open the editor. The agent starts generating. The app appears. For a few minutes it feels like you bent reality with your bare voice commands.

For a few minutes it feels like you bent reality.

And I get it.

I have felt that hit.

The same way, at 3 AM, you can be staring at a black screen between compiler runs and suddenly see your own reflection in it. And for one second you realize the recursive loop you are debugging in code is also happening in your head.

You are a pattern, recognizing a pattern, inside a bigger pattern.

A pattern, recognizing a pattern, inside a bigger pattern.

Then the terminal prints something stupid and you are back.

But that flash is real.

Something big is happening.

The dangerous part is that the feeling can lie.

A product-shaped object is not leverage. A demo is not a system. A codebase is not a moat. A dashboard nobody else can operate is not infrastructure.

The scarce part used to be code.

Now the scarce part is judgment.

Judgment is knowing what not to build. Judgment is knowing when to contribute to a shared layer instead of creating a private one. Judgment is knowing when a workflow should be visible because the human still needs to steer it. Judgment is knowing when an agent should act, when it should ask, and when it should stop.

That is why I am less interested in building another standalone app from scratch and more interested in agent-native surfaces that compound: skills, protocols, memory, orchestration, evals, permissions, workflows, templates, and review loops.

The pattern is recursive.

We built tools to manipulate machine code. Then languages to manipulate tools. Then frameworks to manipulate languages. Then agents to manipulate frameworks.

Now we need systems that let agents manipulate the systems while humans can still see the shape.

That is the loop recognizing itself.

The best builders will not be the ones who ship the most isolated apps.

They will be the ones who build the pattern that can edit its own pattern.