What Should Software Engineers Do in the Age of Agents

Background

AI agents are changing the shape of software development.

For a long time, building software required a person to learn programming languages, frameworks, databases, deployment, debugging, and many other details before they could turn an idea into something usable. That path still exists, but it is no longer the only path.

In the agent era, a person can describe what they want through text or voice, ask an agent to build it, review the result, give feedback, and repeat the process. They do not need to fully understand React, database schema design, API routing, or deployment pipelines before seeing a working version of their idea.

The adoption is already obvious. Stack Overflow’s 2025 Developer Survey reports that 84% of respondents are using or planning to use AI tools in their development process, and about half of professional developers use AI tools daily. A study on GitHub Copilot also found that developers completed a JavaScript HTTP server task 55.8% faster when using Copilot.

So the question is no longer whether AI will become part of software engineering. It already has.

The more appropriate question is: when the first version of software becomes much easier to create, what is left for software engineers?

The First Version Is Becoming Cheaper

Many vibe coding projects today are UI-heavy: web apps, mobile app prototypes, dashboards, landing pages, small tools, and personal products. This makes sense because UI gives immediate visual feedback.

A person does not need to understand software architecture to know whether a page looks close to what they imagined. They can see the layout, the colors, the buttons, the spacing, and the interaction flow. Even if they cannot read the code, they can still say: this looks wrong, move this higher, make this more minimal, add a card here, change the button behavior.

That feedback loop is powerful.

For small projects, this means the barrier has dropped dramatically. A non-engineer with a clear idea and decent taste can now push an agent toward something that looks usable. Modern cloud platforms also make build and deployment easier than before. With enough patience, a person can spend a few days exploring, asking AI to explain errors, and eventually get a project online.

This does not mean software development has become easy. It means the first visible version has become cheaper.

Taste Is Not an Engineering Advantage

One uncomfortable point for software engineers is that taste and creativity are not exclusive to engineers.

A person with no programming background can still have good product instincts. They can understand a user problem. They can recognize a pleasant interface. They can have a sharp sense of what feels useful, beautiful, or emotionally engaging.

In the past, they still needed engineers to turn that taste into software. Now, for simple products, agents can close part of that gap.

This means “I can build the UI” is becoming a weaker advantage by itself. If the product is mostly visual, mostly standard CRUD, mostly a wrapper around existing APIs, or mostly a simple workflow, then the gap between a professional engineer and a motivated non-engineer becomes smaller than before.

That is not because engineering no longer matters, it is because some parts of engineering are becoming more automated.

The value moves elsewhere.

Complexity Is Still the Wall

The real wall appears when a prototype needs to become a system.

A beginner can use AI to build an MVP or a working demo. But once the product involves complex workflows, multiple user roles, client-server boundaries, background jobs, data consistency, permissions, observability, performance, testing, and long-term maintainability, pure vibe coding starts to shake.

The agent may fix one issue and break another. It may rewrite code without understanding previous decisions. It may introduce duplicated logic, hidden coupling, inconsistent state, or fragile abstractions. The project may still run, but it becomes harder to reason about.

This is where non-engineers are at a disadvantage. If they cannot read and evaluate the code themselves, they can only keep asking the AI to repair the system. The quality of the final product depends almost entirely on the AI’s current capability, not on the builder’s own technical judgment.

The data also suggests this limitation. In Stack Overflow’s 2025 AI survey, only 3.9% of professional developers said AI tools handle complex tasks “very well.” Stack Overflow also discussed a broader AI trust gap: more developers actively distrust AI accuracy than trust it, and only a small fraction report a high level of trust in AI-generated output.

DORA’s 2025 report gives a similar warning from a system perspective. It argues that AI does not fix a team by itself; it amplifies the system that already exists. In Google Cloud’s summary of the report, AI adoption is associated with higher throughput and product performance, but the report also continues to emphasize the tension between AI adoption and software delivery stability.

This is where software engineering still matters.

Not because engineers can type code faster than AI, but because engineers can understand systems.

From Writing Code to Shaping Systems

The role of a software engineer should move from “the person who writes code” to “the person who shapes systems.”

That includes code, but it is bigger than code.

A good engineer needs to know how to define boundaries, reduce coupling, design workflows, review generated code, choose trade-offs, and keep the product maintainable after the first demo works. They need to understand when to move fast and when to slow down. They need to know when an abstraction is useful and when it is premature. They need to see the difference between a feature that works once and a system that can survive change.

This is also why system thinking and product thinking become more important.

System thinking helps engineers understand how different parts of the product interact: UI, state, backend, database, deployment, monitoring, and user behavior. Product thinking helps engineers understand whether the thing being built is worth building at all.

AI can generate a lot of code, but it does not automatically know the right product direction. It does not understand the market by itself. It does not feel user frustration. It does not decide which problem is worth solving.

Humans still drive the intention.

The Competition Is Not Human vs AI

I do not think the future is simply a competition between humans and AI.

AI is passive. It is a tool. It responds to human intention, human prompts, human feedback, and human demand. The more important competition is between people who can use AI to express clear product judgment and people who only use AI to produce more code.

In that world, finding real needs becomes more valuable. Understanding users becomes more valuable. Knowing the market becomes more valuable. Being able to turn a rough idea into a stable, useful, and maintainable product becomes more valuable.

AI also raises the expectation for software engineers. If AI can handle more basic implementation work, engineers are expected to do the parts AI cannot reliably do yet: understand context, make judgment calls, design systems, evaluate trade-offs, and take responsibility for quality.

To stay competitive, engineers need to embrace AI, not reject it.

But embracing AI does not mean blindly trusting it. It means learning how to use it as leverage while still keeping human judgment at the center.

Final Thoughts

If the thing I am building can also be built by a beginner using an agent and a few days of vibe coding, I should probably be careful.

That does not mean the work has no value. But it does mean the difference is getting thinner.

In the agent era, software engineers need to move upward. The value is less about manually producing every line of code and more about deciding what should exist, how it should work, and how it can survive beyond the first demo.

Maybe one day humans will no longer need to manually develop software. Before that happens, the best thing software engineers can do is make sure their work is not just repeatable implementation.

It should contain judgment, system understanding and product insight.

It should contain something that cannot be replaced by simply asking an agent to generate more code.