About a year and a half ago I wrote a post about vibe coding where I compared AI to a nail gun. Handy for the boring parts, but you still had to be the carpenter. The carpenter part still holds up. The nail gun comparison doesn't, because the nail gun now builds the whole shed if you tell it what kind of shed you want.
Writing the code is the easy part now
An agent can take a task, write the code, write the tests, run them, read the failures and fix its own mistakes while I'm making coffee. A year ago that sounded like a conference demo. Now it's a normal Tuesday for a lot of us.
Give it a vague prompt like "build me a notification system", though, and you'll get something that compiles, has tests, and is wrong in ways you'll only notice three months later. It picks a database because it's popular, writes its own retry logic, and wires the services together however it guessed made sense. The code is fine. The decisions behind it are the problem.
What the agent needs from you is the stuff that was always the actual engineering:
- what the architecture should look like
- how the services talk to each other, and who owns which data
- which technologies to use, and why those
- what to watch out for, like rate limits, retries, or that one legacy service nobody wants to touch
- what "done" means, in acceptance criteria it can check
- what it must not do: don't touch the auth module, don't add a dependency for something we already have, and don't "fix" failing tests by deleting them
If you can explain all of that clearly, the agent does great work. If you can't, it'll build the wrong thing very fast and very confidently.
Brooks called this in 1986
Fred Brooks wrote an essay called No Silver Bullet where he split the difficulty of building software into two kinds. Accidental complexity comes from the tools, like syntax, boilerplate and fighting your build setup. Essential complexity comes from the problem itself: what the system has to do and how its parts fit together. His argument was that no single tool would make us ten times more productive within a decade, because tools can only remove the accidental part.
AI agents go after the accidental part harder than any tool before them. The essential part is still there, and it's pretty much the list above. Brooks summed it up better than I can: "The hardest single part of building a software system is deciding precisely what to build." Forty years later, that's still the part someone has to get paid for.
Coders and engineers
It helps me to split our job into two roles that used to be the same person. A coder turns a clear spec into working code. An engineer figures out what the spec should be in the first place.
The coder part is what AI took over. And a lot of junior roles were basically coder roles: someone more senior writes the ticket, you implement it, repeat. For years the advice to everyone was "learn to code", a lot of people did, and the junior market got oversaturated with people who could turn tickets into code.
I think that market is coming to an end. The work those roles were built around is exactly the work agents are best at, and an agent doesn't need months of onboarding. People who only want to be coders will have to move into something else. That's not a fun thing to write, but I'd rather say it than pretend the job is safe.
Engineers are in a much better spot. The coding got abstracted away, so what's left is the part that was always hard: understanding the problem well enough to know what will break before it breaks. The really good engineers get even more out of this, because one person who can describe a system well can now get through work that used to need a small team.
In an earlier post I wrote that explaining your work is the other half of the job. It turns out that's also the half AI can't do for you. Writing a good brief for an agent is the same skill as explaining to Janez from product why his "quick feature" touches three services. The agent just complains less.
If you're starting out, that's what I'd practice. Build things end to end, read the code the agent writes instead of just accepting it, and get comfortable explaining why a system should be shaped a certain way.
Keeping up is a job of its own
The other thing nobody warns you about is how fast all of this moves. Every few weeks there's a new agent, a new model, or a new way to extend the one you already use with plugins, skills, MCP servers, subagents and hooks. By the time you've settled into a workflow, someone has posted a better one.
It's easy to spend an evening configuring your agent instead of building the thing you wanted to build. I don't think you need to chase every release. Pick one tool, learn it properly, and switch when something is clearly better for the work you actually do. The tools change every month, but describing a system well is the same skill it was before any of this.
So where does that leave us
I don't think software engineering is going away. Writing code by hand mostly might. The job was always deciding what to build and making sure it holds up, and that still needs a person who understands the system and how it fails. The agents are getting better at everything else.
Now if you'll excuse me, I have to go read the Claude Code changelog. There were three new releases while I was writing this.