AGI, Jobs, and What Happens Next?

AGI vs ASI: They Are Not the Same Thing

Before talking about jobs, we need to understand what we actually mean by AGI and ASI.

For simplicity, I think of AGI as something like a human with extremely high intelligence.

Imagine having a brilliant mathematician, scientist, engineer, programmer, researcher and analyst sitting next to you. You can ask them incredibly difficult questions and they can solve problems that would take ordinary humans a very long time.

But you still need to define the problem.

You need to tell it what you want, what constraints exist, what resources are available, what is acceptable and what the desired outcome looks like.

AGI could be like having a genius working with you. ASI could be something fundamentally different.

ASI — Artificial Superintelligence — is where things become much harder to reason about.

Instead of having one genius mathematician, another genius scientist and another genius engineer, imagine having all of those capabilities combined into one intelligence.

You give it an end result, and it figures out how to get there.

At that point, predicting the effect on jobs becomes extremely difficult.

So throughout this article, I want to focus mainly on the AGI world. When talking about ASI, I will be much more careful because, honestly, no one knows.

How Will AGI Affect Jobs?

Let's start with software engineering because it gives us a good example of how technological progress has historically changed human work.

But before we jump into today's software engineer, let's go back.

50 Years Ago: Building the Foundations

Around fifty years ago, software engineers were solving problems that sound almost fundamental from today's perspective.

Things like:

• How do we make computers process information?
• How do we make computers understand instructions?
• How do we build compilers?
• How do we make programming languages more practical?
• How do we store and retrieve information efficiently?
• How do we communicate between computers?

Languages like C made programming much more practical than directly working with machine instructions.

Databases introduced ways of storing and manipulating huge amounts of structured information.

SQL allowed developers to work with data using a much more human-friendly way of expressing operations.

Networking technologies such as TCP/IP created the foundations for computers to communicate with one another.

At the time, these were incredibly difficult problems.

Today, many of these things are abstractions that developers simply use.

And that tells us something important.

25 Years Ago: The Internet Changes the Problems

Fast forward roughly twenty-five years.

The World Wide Web had already changed the world. JavaScript had become an important part of web development. Databases were solving newer and larger problems.

The web also created completely new challenges.

Suddenly, websites needed to support users from different countries and languages. Text encoding became a serious problem, helping drive the widespread adoption of standards such as Unicode.

Internet applications had to deal with slow connections, scaling, distributed systems, security and reliability.

Engineers were solving problems at two broad levels.

On the customer side: How do we make the experience smooth?

On the engineering side: How do we make this system faster, cheaper, more reliable and capable of serving millions of people?

Again, the problems changed because technology had already solved many of the previous problems.

The Software Engineer Today

Now let's assume something important:

AGI already exists.

Don't think of it as something arriving ten or twenty years from now. Imagine that tomorrow you wake up and AGI is available to you.

What happens to the software engineer?

The job changes.

A modern software engineer may spend much more time understanding the business problem, defining requirements, setting constraints, designing architecture and coordinating intelligent agents.

Think of AGI as a genius software engineer.

You can give one agent one problem. Another agent gets another problem. Another agent works on testing. Another investigates a technical question. Another explores an architectural approach.

The human engineer then becomes the person who:

• understands the actual business requirement,
• breaks the problem into solvable pieces,
• directs the agents,
• reviews their output,
• resolves conflicts between solutions,
• makes architectural decisions,
• and ensures the final system actually solves the problem.

The human doesn't necessarily stop engineering. The human starts directing intelligence.

Initially, this may not mean that software engineers disappear.

It may simply mean that one software engineer can accomplish dramatically more.

What Does an SDE Actually Do in the Next X Years?

The exact timeline is impossible to know, so think of this less as a prediction and more as a direction of travel.

In the near term, software engineers probably still write code — but increasingly with agents beside them. More first drafts, tests, documentation, migrations, debugging attempts and implementation work can be delegated.

As those systems become more capable, the engineer spends more time deciding what should be built, how the problem should be framed, what constraints matter, which trade-offs are acceptable and whether the result is actually correct.

One engineer may coordinate several agents at once: one implementing, one testing, one researching, one reviewing security and another exploring a different architecture.

The job can move from producing every line of code to producing correct technological outcomes.

That does not make engineering trivial. In some ways it raises the bar. If implementation becomes cheap, bad judgment can simply produce bad systems much faster.

So what becomes your USP?

If everyone has access to powerful intelligence, access to intelligence itself cannot be the differentiator.

The advantage moves toward things such as judgment, taste, problem selection, systems thinking, domain knowledge, verification, communication, ownership and the ability to learn quickly.

A model may generate ten plausible solutions. Someone still has to know which one fits the business, which assumption is wrong, what can break in production, what users actually need and whether the problem was worth solving in the first place.

When intelligence is abundant, your edge is what you notice, what you choose, what you can judge, and what you can make real.

There is an old idea that the map is not the territory. A specification, a model output and a beautiful demo are still not the messy real world. Engineers who understand that gap remain useful.

But Here Is Something Interesting

Suppose a really good software engineer working with AGI can now accomplish the work that previously required three average software engineers.

What happens?

The obvious answer is:

"The company only needs one person now. The other two lose their jobs."

But is that necessarily what happens?

The optimistic possibility

Let's imagine something more optimistic.

What if those three software engineers all start using AGI as a genius one-to-one tutor?

They learn faster. They understand systems better. They improve their engineering skills. They become significantly more capable.

Maybe all three eventually become excellent engineers.

This is the optimistic case, and it should not be treated as a guarantee. But it is worth following the logic.

Suppose before AGI, a company could afford to solve ten problems for the cost of solving one problem today.

If solving problems suddenly becomes dramatically cheaper, wouldn't the company want to solve more problems?

Maybe it builds more products. Maybe it experiments with ideas it previously couldn't afford. Maybe it enters new markets. Maybe ten startups become possible where previously only one could exist.

This is one possible way productivity increases can expand demand.

The Limits of the Optimistic Scenario

But there is an important problem with this argument.

Productivity does not automatically create demand.

Just because software becomes cheaper doesn't mean customers suddenly want ten times more software.

There are other bottlenecks.

• How much capital is available?
• How many customers exist?
• How much physical infrastructure exists?
• What regulations apply?
• How quickly can companies manufacture things?
• How much management capacity exists?
• Does society actually want the products being created?

So the optimistic scenario is possible. But it isn't guaranteed.

And that's where things get interesting.

Three Possible Futures After AGI

I don't think there is one obvious future. I think there are at least three broad possibilities.

What Should We Do?

If this transition is coming, I don't think the right response is to stop learning software engineering. The better response is to learn the parts that let you understand and direct increasingly powerful tools.

Learn programming deeply enough to understand systems and verify what the machine gives you. But also learn architecture, product thinking, communication, business, security, debugging and how to turn vague requirements into precise specifications.

Most importantly, use the tools. If a person with AI can do substantially more than a person without it, refusing the leverage does not protect the old job.

Fortune favors the prepared. We cannot choose exactly how fast the technology moves, but we can choose whether we are learning to work with it before the shift becomes unavoidable.

The Salesperson Example

This is not only about software engineers.

Imagine a salesperson with an intelligent system that researches every customer, summarizes every previous interaction, prepares a personalized pitch, drafts follow-ups and identifies which leads deserve attention.

The salesperson still needs to understand people, build trust, negotiate and recognize what the customer actually cares about. But the amount of preparation one person can do changes dramatically.

The same pattern can appear in research, law, design, education, operations and many other knowledge jobs: intelligence becomes leverage, while the human role moves toward context, judgment and responsibility.

You Have a Genius Too

There is another reason I am not purely pessimistic.

The same intelligence that threatens to automate part of your work can also teach you.

You can ask questions without embarrassment. You can ask for another explanation, a counterexample, a simulation, a practice problem or a critique of your reasoning. You can explore subjects that previously required finding the right teacher, book or expert.

That does not automatically make everyone exceptional. Access to a gym does not make everyone strong. But the ceiling on how quickly a motivated person can learn may rise enormously.

Why Five Years Matters

Five years is a long time in technology and a short time in a career.

The tools available five years from now may look very different from the tools available today. That makes predicting a particular framework or job title less useful than building capabilities that survive tool changes.

Learn how computers work. Learn how businesses work. Learn how to reason about trade-offs. Learn how to communicate. Learn how to use new tools quickly. And keep building things that touch reality.

New Industries We Cannot See Yet

People in an earlier computing era could understand faster computers without necessarily predicting social networks, app stores, cloud computing, creator economies or millions of software businesses built on top of the internet.

AGI-level systems may create the same problem for our imagination. We naturally picture today's companies doing today's work with fewer employees because today's world is what we can see.

But lower costs can also make previously absurd ideas practical. Tiny teams may attempt scientific, educational, creative or technical projects that once required organizations.

We should not assume those new industries will absorb every displaced worker. We should simply leave room for the fact that the future can create categories we do not yet have names for.