How to Succeed as a Software Engineer in the AI Era
Somewhere in the past two years the economics of software development quietly flipped. Producing code became cheap. Verifying it did not.
That second sentence carries a lot, so let me spell it out. An engineer can now generate a plausible implementation of almost anything in minutes. Reviewing that implementation, deciding whether it is actually correct, and being willing to answer for it when it misbehaves in front of customers takes about as long as it did in 2020.
Nearly everything that has gained career value recently lives on the far side of that gap. It is also why so much advice about these tools rings hollow. They get treated as typing accelerators, and typing was never the expensive part.
A quick note on where this comes from. I have been writing software professionally for about 15 years. Today, I split my time between two vantage points on this shift.
I’m CTO of a sales automation platform in Brazil, where AI agents are not an assistant but the product. They run in production and talk to real customers over WhatsApp every day. I’m also a technical interviewer for Scalable Path. For the past six years, I have vetted candidates for placement with US clients. That is a good seat for noticing what the market has started rewarding and what it has quietly stopped paying for.
I am not going to argue about whether the tools are good, whether we are in a bubble, or which month the profession supposedly changed. What I can do is describe what the work now consists of and which skills repay attention, whether you are in your first year or your fifteenth.
One idea runs through all of it, and I will state it now so the rest has something to hang on: the check is the job. When you hand work off, to an agent or to anyone, the value of that handoff depends on how reliably you can catch the mistakes in what comes back. Delegation without a way to detect failure is not saved work. It is deferred work.
Table Of Contents
What Changed, and What Did Not
AI Coding assistance arrived in roughly four stages. First came autocomplete, then chat, then a single agent that could work through a task independently. Now, several agents can run in parallel or in the background while you do something else.
The first three mostly changed how quickly you could produce code. The fourth changed what a working day looks like.
Once an agent can take a described task and work at it unattended for 20 minutes, your hands stop being the constraint. Your attention becomes the constraint: what you specify, what you review, what you decide to accept.
My own days now contain far more spec writing and diff reading than they used to. They contain noticeably less of the thing I originally trained for, writing code.
What has not changed is that someone still has to be right. The code still runs in production. It still fails at inconvenient hours. The person who merged it still gets to explain what happened.
Delegation moves the work around. Responsibility stays exactly where it was.
That distinction matters because AI does not eliminate engineering work. It shifts more of that work from production toward direction, verification, and judgment.
Your Ceiling Is Set by the Tooling, Not the Model
Strip the marketing away and an agent is a model, a loop, and enough tokens to finish. The model proposes an action, something executes it, the result goes back into the context, repeat until done.
Thorsten Ball proved the point by building a working coding agent in a few hundred lines of code, much of it boilerplate.
Everything wrapped around that loop is called the harness, and it is ordinary code: which tools the model can reach, when the loop stops, what it may touch, what carries over between steps, how the work gets checked.
Those are design decisions. On any serious project, they are yours, not the model provider’s.
Why does this matter so much? Because a frontier model given a vague instruction and a loop still fails at production work. It tries to do too much at once and has no way of noticing it has drifted. Over the past year, teams that invested in the structure around the agent generally got more out of it than teams that sat waiting for the next model release. Your ceiling is set by something you control. That should be encouraging. It is also a to-do list.
The most useful rule I know here: a task without a check is just hope.
An agent that cannot tell whether it succeeded will tell you that it did, confidently and in detail. So the question is not just whether the model can do the work. You also need to know how either of you will find out whether the work is correct.
A check might be:
- A test suite
- A type checker
- A build that has to pass
- A benchmark that must not regress.
What makes these checks useful is that failure becomes visible without somebody watching every step.
The strength of your checks determines how much autonomy you can safely grant. When a task is covered by strong automatic checks, such as a reliable test suite running in CI, you can let an agent work through it with little supervision. When the checks are weak, you need to stay close: review more carefully and delegate smaller pieces at a time.
Most of the frustration I see with these tools comes down to granting more autonomy than the surrounding verification could support.
The Skills That Gained Value
I find it useful to sort these into two piles, because they behave differently.
The first pile is verification.
Reading code you did not write is now the limiting factor on how much you can ship. Yet relatively few engineers have practiced it deliberately. Historically, comprehension came partly as a side effect of having written the code yourself.
Tests belong in this category too, but their job description is changing. They were already a quality practice. With agents, they also become a control mechanism.
Tests let you constrain something that works faster than you do and cannot be held responsible for the result.
If you build products where the model is a component rather than a tool, the same logic produces evals, meaning assertions about model behaviour that run on every change. Right now that is the widest gap between demand and available skill I can see in this industry.
The second pile is selection. This is where sorting skills into technical and non-technical stops being helpful, because the items below sound like soft skills but function as engineering work.
Specification first
When execution is cheap, quality gets decided earlier, at the moment you say what you want.
“Add rate limiting to the API” produces something plausible and probably wrong.
A brief that states the scope, the limits, the behaviour that must not change, and how the result will be verified produces something you can actually check.
Writing has become load-bearing engineering work. It used to be the overhead around it.
The better you can translate an ambiguous request into constraints and acceptance criteria, the more useful an agent becomes. Specification quality increasingly determines implementation quality.
Business understanding
This is the least glamorous item on this list and possibly the most valuable.
The cost of building the wrong thing did not fall, and the wrong thing now arrives faster.
Why does this feature exist? Who is hurt when it breaks? What is the real constraint behind the request? What does the customer actually need?
An agent can know a great deal about software. It knows nothing about your customers unless you give it that context.
That makes business understanding more valuable, not less. Someone still needs to recognize when a technically correct implementation solves the wrong problem.
Communication
By communication, I mean three specific things rather than a personality trait.
- Writing that survives your absence.
- Review comments that transfer understanding instead of merely blocking a merge.
- Explaining a trade-off to someone who must make a decision without having your technical background.
As more implementation work gets delegated, these skills become part of the engineering system itself. They determine how accurately intent moves between people, agents, and teams.
Underneath both piles sits judgment, and this is the uncomfortable part.
Judgment gets built by doing the work, watching your decisions fail, and slowly developing a sense for why. The work being delegated is precisely the work that used to build some of that judgment.
I have no clean solution to offer.
The best advice I have is to do things the slow way on purpose sometimes. Build something without delegating the difficult part. Debug the strange failure yourself. Read the documentation instead of asking for the answer.
That is where the ability to evaluate the fast way comes from.
A Reality Check on AI Developer Productivity
Here are two things worth knowing before you measure yourself against what you read online.
First, the same tools produce opposite results on different teams.
The DORA research on this is consistent and a little deflating: AI amplifies whatever is already true about a team. Teams need strong technical practices, feedback loops, and organizational capabilities to turn adoption into meaningful results.
If the test suite is flaky, the agent cannot verify its own work and neither can you. If CI takes 40 minutes, the loop that makes any of this fast never closes.
Second, the honest numbers are lower than the marketing. Careful measurement tends to land nearer a thirty percent improvement than a multiple, concentrated in greenfield work and in small teams where the reviewer is the person who wrote the brief.
Your own impression of being faster is not evidence either, and the error runs in a predictable direction. Assistance removes friction you notice (the blank file, the unfamiliar API) and adds time in places you do not count, like the second read of a diff that turned out to be subtly wrong.
The work feels better whether or not the throughput improves. So if you are not seeing a tenfold gain, you are not doing it wrong. Nobody is getting that, but some people are reporting it.
There is a related question worth asking yourself now and then, because nobody else will: are you shipping more, or generating more? A lot of assisted output is volume that somebody will later have to read, understand and maintain. It looks like productivity on the way out and arrives as cost on the way in.
This is uncomfortable to examine, especially while the volume is being noticed and rewarded.
Where to Point Yourself
The tempting conclusion from all this is that depth stopped paying. By depth I mean real expertise in something specific: a language, a framework, a domain, or a layer of the stack. Knowledge deep enough that you can explain why a thing should be built one way and not another. Since an agent produces competent work in any language on demand, it is easy to assume that kind of expertise no longer matters. .
I think that gets it exactly backwards.
What changed is the shape of useful depth, not its value: broad enough to direct work across a stack you do not personally specialize in, deep enough somewhere that you can judge what comes back, argue with it, and be right.
The failure mode is being broad everywhere and accountable nowhere, which is a comfortable place to stand and a bad place to be when something breaks.
If you are early in your career, the market really is harder, and pretending otherwise helps nobody.
What has also changed is what counts as evidence.
Producing code no longer distinguishes anyone. Demonstrating judgment still does, and the skills that differentiate most right now, evals, test design, specification, do not require seniority to learn. Most of your future colleagues have not learned them either.
The Check Is the Job
The scarce resource moved, and it moved in a direction that is easy to miss while the tools are still impressive.
Generating an implementation is no longer the constrained step. Everything around it is: reading code you did not write, designing checks strong enough to delegate against, specifying work precisely enough that correctness can be judged rather than argued about, understanding the business well enough to notice a technically correct solution to a problem nobody has.
None of this is new. It was always the harder half of the job.
For a long time, much of it was hidden inside the act of writing. Judgment, comprehension, and verification were bundled into the hours spent producing something by hand, so it never had to be practiced on its own. Now it does.
The engineers who do well from here will not be the ones who produce the most code. That competition is over and nobody won it; the tools produce more than any of us, on demand, at falling cost.
What stays scarce is the ability to decide what should exist, state it precisely enough to be built, and know, with reasons, whether what came back is right.
The check is the job. It always was. For a long time, you could not see it. Now it stands on its own.