Four years ago, some people started posting on Twitter about this cool new tool. It could create simple HTML with a button. Position it, change the color, and change the text—all that from a simple, human-readable description.
The internet went wild! This was the most advanced thing ever; we’d never seen anything like it.
“Now add another button next to it. Make it bigger and red, with the label `Cancel.`”
And it did.
For most of us, it truly felt like magic (to be honest, it still does for me; like, how does it know?! I added it to my mental list of human-created wonders, like how heavy metal planes fly, or cruise ships don’t sink).
But the hype never faded. It evolved.
I remember how excited I was when I got early access to GitHub Copilot.
“Look, it knows what I want to do. It even uses the correct variable names that I used in this other file! You just need to press Tab, and it fills it out for you! No, it’s really smart!”
Like a child getting a new toy.
Then, we started chatting to our code. We started calling it an agent.
Sure, it made mistakes, but it helped us so much with our work. I haven’t had to remember the parameter order of the substring() method or how to do array chaining. I’d never have to open Stack Overflow again! And it could even fix my TypeScript linting errors!
And it kept getting better. New models and new tools kept showing up like crazy.
And the AI chat, which started as a sidebar, took over the main interface of code editors. Because why would we have the code view as the default when we spend most of the time talking to the agent and prompting??
Because we were prompting more than manually writing code. First, only the more curious people. Companies were reluctant for a short while to give access to these new tools to work on their codebases.
But the speed of adoption was unseen in human history.
No one wanted to be left behind, and the frontier models offered 10x speed with 10x less human effort.
We saw headlines about AI taking millions of jobs with self-driving trucks or automation in assembly lines. But as overconfident software engineers, with our comfortable, high-paying jobs and perks no other industry provides, we thought this wouldn’t affect us—for a time.
Until it did.
The general mood started shifting.
If AI can do so much more with so little human input, why would companies need to pay for us? Companies thought the same: a wave of massive layoffs swept across tech in the name of AI efficiency.
Suddenly, a generic sense of existential crisis reached all software engineers. I had several conversations with folks about how they feel about their job security and what their “Plan B” is if AI takes their job (surprisingly, many answered with growing vegetables on a farm; I guess that’s the furthest from computers).
Lately, I’m not hearing many of these concerns. We collectively agreed that AI - for now - won’t take all our jobs. Sure, it’ll make it damn hard for new engineers to enter the job market, because AI can easily do all the tasks juniors did, but that’s not “our” problem (I’m being super sarcastic here).
Then, on September 23rd, David Heinemeier Hansson walked on stage at Rails World.
The creator of Ruby on Rails, who used to be one of the loudest defenders of writing code by hand (with his famously strong opinions), opened the conference with: “It’s pencils down, people.”
His company, 37signals, stopped writing code by hand. He says he hasn’t written a line himself since around March.
If I look at my work, I haven’t either.
Our jobs have changed, forever.
We’re not spending our time on cracking some interesting coding challenge by looking at our code.
We’re writing instructions for our agents (usually multiple at a time, because who has time to wait for Claude or Cursor to finish one task? That’d be so inefficient!).
We’re writing skills so they automatically do the work we used to do.
We let our agents review code that others’ agents wrote.
No wonder social media is full of memes about how we interact with AI (often self-reflecting, mocking our new behaviors).
So in this new reality, when we don’t have to remember algorithms or how to write unit tests, and we can forget about the manual steps of git rebase, what is left to do?
What is expected from software engineers?
And how can we still be good software engineers when our whole job description has changed in just four years?
Who Is A Software Engineer?
It used to be easy to answer this question: a programmer, developer, someone who writes code that makes the computers do their thing.
Of course, that was never the real answer; coding was only one step in the process.
According to trustworthy sources (Wikipedia):
A software engineer is a technology professional who applies engineering principles and programming expertise to design, develop, test, and maintain software systems and applications.
Cambridge Dictionary summarizes it even more tightly:
Someone whose job is to create computer programs.
Neither definition mentions coding.
That’s already reassuring, because coding is what AI solves out of the box.
This isn’t a new idea.
Already back in 1985, Peter Naur wrote that programming is really about building a theory: a mental model of how the program solves a real problem. The code is just a byproduct.
While there can’t be one universal way to describe software engineers, we can use these previous definitions to see that neither mentions code written or algorithms, and both focus on the output, the result: creating software.
In fact, years before AI, this trend was already common: we weren’t required to remember everything by heart; Stack Overflow articles helped with our issues, UX libraries helped us make prettier software, and smart linting rules reminded us of missing semicolons.
We aimed to make code simpler to write, more robust, and safer. We built out-of-the-box frameworks and ready-made open-source packages we could reuse in our projects. Our job was to piece these puzzle pieces together in a way that makes sense for a computer and build a functioning program that (hopefully) addresses a business need.
In 1986, Fred Brooks (IBM, author of The Mythical Man-Month) split software difficulty into two types: accidental, which comes from our tools and syntax, and essential, which comes from the problem itself.
And since computers exist, we’ve been tirelessly working to remove the first.
But you can’t take away the essential part. It’s the work of figuring out what the software should actually do: the rules, the edge cases, and thinking ahead to what’s coming later.
There are many anecdotes about lazy programmers who automated half their work, and I think it is true in general: we, software engineers, have always wanted to simplify coding, write less, and lean on existing artifacts.
What Makes a Good Software Engineer
Let’s go back to first principles.
If software engineers are expected to create (and maintain) computer programs, then a good software engineer delivers them.
They are expected to make sure that what they build works as designed.
Or we can go even one step further: really good software engineers are expected to build things that solve actual problems, and those products work as designed.
When AI writes all the code, what is the human Moat? That machines can’t do.
Taking full responsibility for the product.
I really like this idea, as it circles back to my blog’s name: high agency dev.
It means that, as a software engineer, you can be outstanding if, instead of just executing the tasks that are listed in your Linear, you take initiative at all steps and own your work:
You contribute to conversations about what to build (push back if needed, since you represent the technical side).
You deliver to the highest standards, making sure your work doesn’t degrade others’ work.
You proactively unblock your work; don’t wait for others.
You take full ownership, responsibility, and accountability for the code and configurations you do, even if it’s written by your agents.
You make sure, with the utmost care, that releasing your work to production goes smoothly, without breaking anything (and you do it confidently).
You help follow through on the impact of your work.
And you make sure everyone on your team is well informed and always up to date.
You don’t wait for others to tell you what to do. You take initiative: you notice things only you can spot early on; you find the right people to make decisions; you bring technical expertise to the table; and you make sure what’s promised gets done.
No matter who (or what) writes the code, someone has to answer for it.
IBM figured this out back in 1979. A slide from an internal training said: “A computer can never be held accountable. (…)”
Karpathy said the same at Sequoia in April 2026: you are still responsible for your software, just as before.
Antisocial Reality
It might be harsh, especially if you’re the kind of person who used to love coding, being in the zone. Sorry, but this is the new reality.
DHH loved it too. In 2025, he said that if he stopped writing code himself, he would turn into “a project manager of a murder of AI crows.”
A year later, he’s the one saying pencils down.
You might hope that some part of the job will stay technical: writing code and not talking to people. Designing architectures, configuring servers, tweaking databases.
And while you should know about these things, the truth is: agents can already do them too. Your understanding is more important than your skills to manually go and implement them.
There are flame wars in the tech scene about how AI can and will do all your work. You don’t have to agree with either side, but if you pay close attention to the direction and speed, I think you can see where things are going.
Even if there are current limitations, it’s only a matter of time before newer, better models solve them too.
So your new work becomes figuring out what to deliver, working with the team, and directing your agents to implement it correctly.
Building Is Easy
If the agent writes the code, what is hard now?
Knowing what to build.
Historically, as a software engineer, you had little impact on which features got prioritized.
But a feature nobody needs is still a feature nobody needs. You just ship it faster.
So speed stopped being your advantage.
Your technical expertise is still needed elsewhere: managing complexity (don’t let AI go rogue; you still want to understand it well and hold the steering wheel), thinking ahead for the future (so the current solution doesn’t introduce changes that’d make future work more difficult), considering alternative, more optimal solutions, and keeping the overall context end-to-end in your head.
And what’s left is deciding (or helping decide) which problem is worth solving. And for that, you need a business hat on top of your engineering one.
Think Like a Product Engineer
This idea isn’t new, but AI has popularized it in recent years.
In 2019, Gergely Orosz wrote about the product-minded software engineer. He described engineers who care about the users and the business, not just the ticket. They ask why a feature exists. They suggest cheaper ways to test an idea, and they follow the results after it ships to see whether it helped.
Back then, it was like going the extra mile. Those engineers often became team leads. Proactive, communicating directly with business stakeholders.
But now it’s the job.
When an agent can write the code, solving tickets won’t put you ahead.
You can stand out by doing everything around them.
Who asked for this? What problem does it solve? How will we know it worked? What happens if we don’t build it at all? What can go wrong? Who should I involve?
Product decisions might seem to be made above your level. But questioning these things can bring you more visibility in the team and new angles that only you could see. And if you’re working in a healthy environment, these questions and pushbacks are embraced, as everyone’s trying to make the product better.
This is where high agency comes back in:
A product engineer doesn’t wait for a perfect spec to land in Linear. They go and find out what the spec should say.
But enough of the philosophizing. What does it look like in practice?
A Day In The Life of a Good Software Engineer
Grow your own context
We like to keep AI context small to perform better.
But you’re a human, not a company, and your advantage is you can have a much broader overview than AI does. You don’t have to know all the details; that’d be overkill.
But go and talk to a lot of people:
The PM, the designer, QA, fellow engineers, the on-call person.
Each of them knows something about the ongoing projects that aren’t in the tickets, and they might give insights about future directions and upcoming initiatives that can expand your context.
Keep everyone updated
With agents, work moves fast. Often way too fast for the people around you to follow.
Keep everyone up to date.
A three-line update every day beats a perfect report every two weeks.
I learned throughout my career that even if you’re breaking bad news early on (e.g., delays or blockers you weren’t aware of before), the team can handle it. It’s much better than trying to figure it out quietly on your own, behind the scenes.
Remember: you are the one who has access to the code and who knows about the progress. Other stakeholders have to take your word for what’s going on. Don’t keep them in the dark.
Give frequent updates to build trust and also to increase your visibility.
Write instructions like they’re the product
Because they are now.
Not gonna lie, I’m also not a fan of writing tech specs and PRDs, and I just want to jump into coding.
But your job is now to translate between the business and computers. Take the requirements and phrase them in a way your agent can understand.
Your deeper knowledge of the overall context is extremely useful here: you can think of unwanted side effects and long-term expectations.
Hold the theory
I’ve found that agents try to solve the problem in the most efficient, simplest way. But that often doesn’t consider other requirements and limitations that you, as a well-informed engineer, would automatically incorporate into your solutions.
For example, if you’re implementing a new feature while another team is removing legacy code, you shouldn’t use it in your solution. AI might jump at it and use it, since it’s how it’s been used elsewhere. But you should know better.
Your agent doesn’t have this overall context of how things are going in your company. But you do (or you should have).
Writing those documents is how you add the extra information: the business rules, the states, the edge cases, the trade-offs, and instruct your agents to do things the right way.
Your 90% and your 10%
In April 2023, Kent Beck (the creator of TDD and Extreme Programming) tried ChatGPT for the first time.
His verdict: the value of 90% of his skills just dropped to $0. The other 10% got 1000x more leverage. “I need to recalibrate.”
But he couldn’t answer the questions: which skills were which.
It took him two years to name the 10%: having a vision, cutting the path into milestones, and keeping the design under control so complexity doesn’t explode.
Once again, none of it is typing.
Coding Was Never the Job
Can you think about the best engineer you have ever worked with?
Do you remember how fast they typed? Or do you remember the question they asked in planning that saved the team a month of work?
That’s the job. It always was.
And we just couldn’t see it, because the code was in the way. It took most of our time. It was the loud, visible part. The part with green checkmarks and merged PRs.
Now that AI took that loud part, what’s left is the part that could make you stand out in the first place.
Honestly, I think this is good news. 😁
An orchestra conductor doesn’t play a single note during the concert. But nobody asks if they’re doing any work. They know the whole piece. They keep everyone in time, and they hear the wrong note before the audience does.
You have your own orchestra now.
Your agents play, your team listens, and you conduct.