What is the value of a software engineer anymore?
Many new grads and juniors ask me how my work has changed as an engineer.
What is the difference between what I did in 2021 and what I do today?
Here is what changed.
Assume all the planning is done and I know exactly what I need to build.
In 2021
60% of my work was spent coding.
Pressing one letter at a time on the keyboard with my little fingers, one after another, for hours straight.
Like a caveman.
20% was spent researching.
Googling things about the language, framework, patterns, and protocols, and reading other parts of the codebase to understand how things worked.
20% was spent testing and reviewing.
This was easier because I typed every letter by hand, so I already knew almost everything that had changed.
In 2026
5% planning the overall design and structure before agents start writing.
40% reviewing agents’ code and comparing it against the design.
5% requesting design and code changes from the agents.
40% understanding and validating the implementation, making sure the code actually does what I think it does.
5% talking to other people about related changes.
5% testing and doing final reviews.
Conclusion
I’m no longer a coder or programmer.
I’m more of a code reviewer and designer.
The value I brought to the table in 2021 was the code.
I was one of the few people who could write it.
If you brought a random stranger in off the street, gave them the requirements, and asked them to build what you wanted, they couldn’t do it.
In 2026, I’m no longer doing coding.
If you bring a random stranger in off the street, give them the requirements and Codex, they can produce “working” code.
So what is my value?
Why would you pay me thousands of dollars?
I have been asking myself that question a lot recently.
And here it is.
Think about a company that pays for a piece of software.
They pay because that software does something valuable for their business.
In some ways, their business depends on it. And that dependence rests on two claims:
1: Behavior: What the software claims to do and actually does.
2: Potential: What it will continue to be able to do in the future through upgrades, vulnerability fixes, new features, and changes.
If that software doesn’t do what it claims, you can’t depend on it.
You need guarantees. You need a solid foundation you can trust and build your business on.
On the other side, if you sell software, you need those same two things from your engineers.
1: Behavior: You need them to guarantee, as far as reasonably possible, that the software behaves the way it is supposed to.
2: Potential: You need them to ensure that the software remains flexible enough to improve, change, stay maintainable, and stay secure.
This is where I come in as an engineer.
That stranger off the street who can “build” using Codex isn’t capable of guaranteeing what they built.
I can.
No guarantee is 100%, but we want to get as close as reasonably possible.
Engineering is the process of increasing that confidence. Good engineers can guarantee more.
The reason I spend most of my time reviewing agents’ code and design is to understand what the system actually does and change it when it does something wrong.
Because I understand it, I know what can happen, what will not happen, and what may happen. I can communicate that, and you can depend on what I tell you.
Hence, my value is that I can take responsibility for what I build.
I can tell you what it will do, what it can do, and stand behind those claims.
And you can go ahead and tell your customers what our product can do.