The World Once Everything is Automated Away

A pessimistic view of the future of software engineering and the world in general, when you have nothing left to do.

In 2026, journalism is a dying art. Copywriting doesn’t need to be done by humans anymore.

Illustrations? Fully generated. Audio? Music? Video? Nothing survives the revolution.

Even interior design, product design, and architecture are being automated. Decision-making is now trivial.

The world is being run by complex algorithms that pattern-match and optimize every aspect of our lives.

So you say, “Because software developers made it, they must be the only ones whose jobs are safe?”

Nope. You can one-shot a state-of-the-art full-stack application that maintains, deploys, and plans its own features. It can even write its own documentation.

Testing? QA? Code reviews? All handled by the software itself.

Oh, are you arguing that these produce tasteless, low-quality, and unmaintainable software?

Sure. But are you saying you can produce a more tasteful, high-quality, and maintainable software?

Software in the past had more slop and was buggy than it does now. Just because it is made by AI, now you can blame shift and say, “well that’s why I don’t trust AI to write software”?

Go ahead and hand-craft your own software, but the world is moving on without you.

Making money isn’t about craftsmanship anymore. It’s about speed, efficiency, and optimization.

Remember, Fruit Love Island amassed 300M views. The world is now run by algorithms that optimize for virality, not quality.

There is nothing left to do.

…is what I would say if I were CLUELESS about how the world works.

Did I fool you? Aww, who doesn’t love rage-baiting for engagement?

Rest assured. Your job is (probably) safe. 🤷‍♂️

Benchmaxxing, agent skills, self-improving loops, harness engineering—every time I see the news, I can’t help but feel these are just superficial overhypes of the same old thing.

Recently, Claude announced a new model called Mythos, claiming it was a zero-day security threat that couldn’t be released.

Not long after, it was here anyway.

People were astounded by the sheer capabilities of the model and how it was going to save their lives.

Then, right on cue, the government locked it down overnight.

? What?? Why are you guys unhappy about it? Didn’t you say it was deemed too dangerous for release? I’m just doing my job.

And over the next few days, we welcomed it back with open arms.

Don’t you see how ridiculous this is?

This is the exact same playbook used for ChatGPT and every other model. The hype cycle never changes.

GPT-2 was “too dangerous for release.” A mere 1.5-billion parameters, and it was going to destroy the world. Now, we run 1.5B models locally on our phones, and it’s not even a big deal.

And do you know how much these giant models cost to run? You can drop a few sentences into Claude Code and burn through $10 in five minutes.

Sorry, but I come from the era where you could top up $10 of OpenAI credit and run GPT-3.5-Turbo for a whole month. This is utterly absurd.

Isn’t it obvious that you just pay more to get more? More parameters, more tokens, more agents—and more diminishing returns.

Now your vibe-coded, sloppy app is going to sit there, unmaintainable, because you don’t actually understand what the agent wrote.

Fix it, no mistakes.

Say that to a real junior software engineer, and you might get escorted to HR. But now, you can say it to an agent, and it will happily fix your bugs while introducing two more.

This entire paradigm is completely overhyped. There is nothing new here.

…is also what I would say if I were a software engineer destined to be replaced in the next five years, not by a higher intelligence, but by the ignorance I use to gatekeep myself from the truth.

When I purposely spread misinformation on the internet

Which one did you fall for? Aww, how cute… 😘

Alright, no more bait-and-switch. I just wanted to show you how both arguments make total sense on the surface.

Unless you look at the other side, each perspective feels completely irrational and uninformed.

We will parse the truth of the matter, piece by piece. But first, let’s address the elephant in the room.

Is software engineering solved?

Short answer: No. And I’m not saying this to claim software engineering is some superior field. I could say the same thing about any industry.

Roomba never solved cleaning. Trains never solved transportation. LLMs never solved journalism.

But why? We can always build a smarter Roomba, a faster train, and a more capable LLM.

In fact, we are doing that right now. So why do these problems persist?

Because it is a categorical mistake to think that these problems are solvable,

or more accurately, that they are discrete problems at all.

A class of problems is an abstract category. Each unique instance introduces different states and entirely different processes.

Transportation’s problems include traffic congestion, accidents, environmental impact, and, of course, speed and efficiency.

And within speed and efficiency, there are endless metrics and parameters to optimize, many of which carry hard physical constraints.

For instance, a train cannot exceed the speed of light.

A train cannot accelerate or stop instantaneously because human passengers need to get on and off intact.

And a train certainly can’t plow through an occupied house.

Therefore, saying software engineering is “solved” is a categorical mistake. The word software engineering itself carries no constraints.

It’s like when you can’t find a closed form to some indefinite integrals. The problem class is unbounded.

So what’s solved?

The core of problem-solving is comprised of three components.

Now with Neural Networks, we simply map the problem space onto a giant approximation function that attempts to solve the problem in a good-enough way.

This shortens the execution process, but it doesn’t eliminate the problem.

Yet again, the same argument that I like to make: it’s a categorical fallacy.

Decision has nothing to do with feeling or consciousness,

or even quality, intelligence, or trust.

You have always been able to delegate decision-making to another real, living human being. You can hire a manager, a consultant, or a coach to make decisions for you.

These people are smart, trustworthy, and capable. They make mistakes sometimes, but it doesn’t really matter.

The sole reason is simply that the decision has always been yours to begin with.

Decision is the act of choosing between options. You can’t delegate the entire act of decision-making, simply because delegation is a decision in itself.

Even if you hire a manager to delegate to their subordinates, you still had to hire the manager.

Therefore, this has nothing to do with ability, but rather with ownership.

You can’t draw a line between two points without drawing out from the first point. The delegation has to start somewhere, and that somewhere is always you.

But as always, this is an ontological error.

Really? Why?

If you already automated the execution, you can just ask the agent to plan out evaluation criteria and metrics for you.

You can always hire a critic or a QA engineer, to test the solution.

Ah, you want ‘Delivery’?

Okay, I can also request that they send this report directly to the customer, and if the customer is unhappy, they can escalate it back to the team without going through me.

So why not? Why can’t you delegate it away?

The thing is, only you have a say in whether the solution is acceptable or not to you.

You can always delegate the evaluation process and the measurement criteria, but you can’t delegate the ownership of the evaluation: whether that criteria is acceptable.

Just like the infinite delegation loop in decision-making, the act of delegating to a delivery agent is a delivery in itself.

When you say “I sent a package,” you don’t mean you walked there and handed it to them. You delegated the execution to a courier.

But if that package contains something illegal, the courier doesn’t go to jail. You do.

You can outsource the labor, but you cannot contract away the liability.

The line has to connect back to the origin, and the origin is always you.

So what’s solved?

Nothing has really been solved.

The solution search algorithm has been shortened, made more efficient, and perhaps requires a sacrifice in sovereignty—but the problem is yours to identify, and the solution is yours to own.

But that doesn’t make you any more important

You can deny the use of generative art however you want, but it’s going to find its way into appropriate places.

You can be an agentic maximalist, solve 100 problems with 1000 subagents running in parallel, and ship products without any human intervention, but you still own the consequences of your actions.

You can believe software engineering is solved and go work on hardware, physics, chemistry, medicine, data, marketing, or any other field, but nothing has infinite benefits with zero trade-offs.

You can also believe that software engineering is largely unsolved and go work on the next big thing, but the perspective from another field is no different than you looking at them.

I can switch software engineering with energy or law or art and I now sound like a Socrates of 2026.

At the end of the day, it’s a trivial observation.

Judgement has always been yours, and it always will be.

Okay, I get it. Now I decide to delegate the decision-making to you. What now?

And no, don’t cop out by saying ‘you are the only one who can make that decision’ or ‘well, I wish I knew it too.’ I’ve heard that too many times already.

I want to hear your opinion on this matter.

A million-dollar question, isn’t it?

The answer is never going to be “coding is solved; go study something more foundational like physics,” “nope the basics are solved; applied fields like robotics are the future,” “escape the hatch; build a quant trading empire,” or “disappear into academia; for the love of the game.”

To be respectful, those aren’t wrong action items inherently, but they just aren’t the answer to the question.

Because it’s not about the playing field; it’s how you maneuver the ball.

What’s a problem worth solving?

What’s a problem worth solving?

No, I’m not asking a rhetorical question.

That. Exactly. Is the problem worth solving.

The ability to identify a problem is far more valuable than executing it.

Being able to decide your constraints, your ground rules, and your target is what’s left.

Whenever you hear a requirement or a specification, second-guess it. You should always ask, “Is this the right problem to solve?”

Do push back. Do question the requirements. Do challenge the assumptions.

Though, if at the end of the day, you have no problem worth solving, then you probably have overdone it.

Be a bit more lenient. A good judgement isn’t always a strict judgement.

Does this achieve my goal?

Try asking ChatGPT:

I got a 75 in a math test!!! What do you think?

You will get a generic response like, “That’s great! Keep up the good work!”

It’s designed to be sycophantic, not to challenge your assumptions.

Asking for a critique is a great way to get a dead-center, bell-curve response.

Highly-represented code found on GitHub isn’t necessarily the best code; it is just the most statistically prevalent.

Therefore, the ability to judge the quality of a solution is indispensable.

Breakthrough systems are built by deliberately working against immediate usefulness and violating expectations.

So, don’t always trust the most popular solution, especially not from an LLM.

But who am I to judge?

The irony of you being the best judge is that you’re also the worst judge.

It’s paradoxical, but the higher the stakes you have in a decision, the more biased your judgement becomes.

Because as the execution is abstracted, your field of vision also narrows.

Ever asked an LLM, “Why does this code not work?” It will adversarially invent a bug in your code, even if the code is perfectly fine.

Because, statistically, your prompt implies a bug exists.

Incremental improvement is also one of the huge limitations of LLMs. They are designed to treat your prompt and the current state as absolute constraints.

Claude will do whatever you ask, which makes it an elaborate monkey’s paw underneath an approximation algorithm that strives for the next local optimum.

Of course, that doesn’t mean you can’t leverage LLMs for decision-making.

Setting up a rigorous grill-me agentic loop is a great way to tackle the blind spots in your worldview.

However, you are going to stack the root cause of the problem on itself; you are still the one who has the final say.

It’s always a good idea to get a second opinion from someone who actually holds a stake in the outcome.

Opinions are cheap, so take them from someone who IS willing to put their credibility and accountability on the line.

A good rule of thumb is, quoting from an author Neil Gaiman,

Remember: When people tell you something’s wrong or doesn’t work for them, they are almost always right. When they tell you exactly what they think is wrong and how to fix it, they are almost always wrong.

A bit of a tangent rant:

As someone from an Asian household with a strong Chinese bloodline, I can tell you that getting unsolicited opinions from relatives is a surefire way to get a biased, unaccountable perspective.

Here is a response you can use to shut them down:

I appreciate your opinion, and it has been weighed into the decision-making process. Ultimately, I am the one who has to live with the consequences of this decision.

I hope that being directly responsible for the outcome puts me in an advantageous position by default, in case you are worried about my uninformed judgement.

Unless you also want to take a percentage of accountability for it, which is a decision in itself that will have to recursively go through the same process. So, let’s not make things more complicated than they need to be.

Because you read my article, now you know the infinite delegation rule and ontological ownership of delivery. You can use it to your advantage! 🤷‍♂️

That concludes why there are more things to do, when there are seemingly fewer things to do.

The more execution is abstracted, the more important judgement becomes, and consequently the less you can trust your own judgement.

I guess that’s it?