As some of you know, I've been enthusiastically touting Claude Code, and coding agents in general in this space lately. I've been using Claude Code for over a month. I've submitted dozens of Pull Requests to our open source, version controlled database, Dolt.

Coding agents work. And they work mostly in the background, meaning the productivity gains in software development will be immense. What do coding agents mean for human software developers? Is this a dying job? How can a software engineer prepare for the agentic future? This article will discuss.

It's been a Good Run

I'm old enough to remember when software engineer, or programmer as we were called, was an average white collar job. You went to an office. You made an average office job wage. If you liked computers you went into the field. No guidance counselor recommended it. Programmer was a normal job for people who liked math, adjacent to an accountant.

It's only since the first internet boom in the late 90s, and especially post-Google, that software engineer has been considered a "great job". The initial internet boom created the precedent that software engineers received equity in their employer's company as part of their compensation, creating the possibility of life altering wealth. Then, Google created the free food, free haircuts, nap pod - software engineers rule the company culture that is common today. The rise of the internet and then smart phones created a 25 year boom where there was more software engineering to do than there were software engineers to do it. Companies fought for software engineers' services, resulting in ever-increasing compensation. These elements combined to make software engineer a great job, until now.

Something changed recently. Some of you may know we're in a software engineering recession and have been since the middle of 2023. The number of software engineer job openings has massively decreased from peak and flat-lined.

Fewer posted jobs combine with continuing layoffs at many companies.

It's especially brutal for new graduates.

When these unemployed software engineers started college, the internet shouted "Learn to Code!" at you if you complained about your lot in life. Now, Nutrition Science and Art History majors are snickering from the comfort of their cubicles. Are they shouting "Learn to Paint"?

It's becoming clear that software engineer currently is not as great a job as it used to be. It's still pretty great if you have a job but good luck finding another one if you lose it. For the first time in my career, I'm examining software engineering's future prospects.

What Happened?

Are recent advances in artificial intelligence (AI) affecting human software engineering jobs? Are coding agents displacing human software engineers? I don't think that is what happened. The timelines don't quite line up. Maybe it will happen but I don't interpret the above data that way.

I think what we're seeing is the end of the internet and mobile software booms. Almost everyone in the world has access to the internet on multiple devices. Almost everyone on Earth has a smart phone. Pre-AI, what tech vertical was growing fast in the past five years? Where was new software being built en masse? Everyone already searches the web using Google. Everyone already shops on Amazon. Everyone already has an iPhone. Everyone already wastes time on Facebook or Instagram or Netflix. You get the idea. Opportunities to build generational companies were getting fewer and farther between.

Since 2018 or so, tech has been looking for the next wave, so much so, many people decided prematurely that crypto and the somewhat related metaverse was it. Does anyone want to buy my Bored Ape? Maybe we can buy and sell stuff in the metaverse? In a retrospectively premature decision, Facebook even changed its name to Meta. We're still waiting for a massive use case in these spaces. Stable coins are cool but I'm not sure these areas were or are going to save software engineering.

Which brings me back to artificial intelligence. I think artificial intelligence will save software engineering, not kill it. I was skeptical AI was a going to be huge at first, mostly in the chat-based AI era. But now, agents are here. Agents can work autonomously for minutes at a time on complicated tasks. We haven't even mastered agents managing agents yet. Whole swathes of the economy are going to be automated.

Who is going to automate? Software engineers. Software engineers just aren't going to do the same things they used to do: mostly write code all day. AI is the next wave and software engineers are going to surf it like the internet and mobile waves before it.

Some software engineers are crashing out right now but just grab your board and paddle back out. A new set is coming.

The Agentic Software Engineer

What can you do to prepare for the coming AI wave? How can you become what I call an Agentic Software Engineer?

I'm not talking about becoming an AI researcher, like the ones rumored to be getting $100M pay packages from Facebook. That ship has probably sailed if you're already a trained software engineer. AI researcher is a sufficiently different job, involving a lot of algebra and AI specific knowledge, that you would likely have to retrain or take a really junior position to become one. If you're interested in it, I recommend watching this mini-GPT video by Andrej Karpathy so you can get sense for what's involved. It's about two years old now but it's the best summary of the type of work AI researchers do that I know of.

I am talking about what skills you can build in your day-to-day job that will help you be more productive with AI. How can you adapt your current skills to be better at taking advantage of AI tools? Engineers who build these skills will become indispensable in the new agentic world.

Use an Agent

It may seem obvious but the first thing to do is to try Claude Code, Gemini CLI, or Codex. These are the leading coding agents right now. All are free to start but do cost about $10/hour to use afterwards. These offer a command line experience that is much different than chat-based coding experiences you may have used in Cursor or Windsurf. These IDE-style interfaces have "agent mode" but it's harder to find and use, in my opinion. Having a terminal open and watching an agent work for 10 or 15 minutes really gives you an idea of what the future will look like. Multiple agents running on your computer doing work in parallel asking you for help when they need it.

If you're looking for something to do, just grab a bug from the Dolt issue queue. You may also need to clone go-mysql-server if you want to fix a SQL issue. Claude Code can handle working across the dependency as long as you start it in the parent directory of your dolt and go-mysql-server clones.

Once you've used an agent to write code and fall in love like I did, try to find tasks in your normal development flow that you can offload to the agent. This should be additive stuff like "improve the tests for this recent change I made" or "find and unskip a test in the test suite". The idea here is to augment your current work, not replace it.

After the initial granting permissions phase which requires a bunch more babysitting, let the agent work for 10 or 15 minutes and then check on it, kind of like you would email or Slack/Discord. If the agent needs attention, give it some and go back to your normal task. Once you do that for a while, you'll start to get a sense for the types of tasks agents are good at and you can start integrating them into your normal flow to get more done on your main work stream. Some people get so inspired they start to run more than one agent in the background but that's a bit too much context switching for me. Find the right balance for you.

That said, I think you'll start to notice some of your skills as a software engineer are about to become much more important and some of your skills as a software engineer are about to become much less important. Some skills will be similarly valued. I've compiled a list below and I think most software engineers will agree with this assessment after using agents for a month or so. The idea here is to spend time getting better at the skills that are becoming more important and less time on the skills that are becoming less important.

Skills++

These are the software engineering skills I think will be more valuable in the agentic AI era.

Version Control

I made the case in another article that version control is a critical piece of agentic workflows. Version control is the coordinating mechanism between you and your agents. Git is the most scalable version control model and we're about to have 1,000s of more code writers. You need to know Git-style version control.

It will become pretty clear when you want to set up an agent to run in parallel to your normal work stream that that agent needs its own clone. You don't want you and your agent stomping on each other's work. Your agent will probably need multiple branches for in flight projects. You will want to review the diff your agent made. Your agent will make mistakes that need to be reset or reverted. Version control is the key to coordinating with your agent.

If up until now you've just been typing Git commands, not understanding what they are doing, now is the time to learn the Git model. Git is going to be the collaboration backbone for humans and agents. Become a Git specialist.

"Product"

There is a nebulous set of skills that I will refer to as "product". These are things like creative problem solving, requirements gathering, interface design, and task management. Some companies even have a specialized role for people with these skills called product manager, hence my name for the category of skills. Most software engineers have varying levels of "product" skills and software engineers who are very good at product often become product managers.

Product skills are about to become much more important. Managing one or many agents exercises many of the same skills product managers use to manage one or many software engineers, just at a much more micro scale. Skills like breaking tasks up into manageable pieces and defining exactly how a feature should work become more important in a world where agents write most of the code.

Task management is extremely useful because currently agents can only handle tasks of a certain size before becoming extremely inefficient. Breaking problems down into small enough chunks that agents can handle each task is very important in the agentic world.

My best advice for getting better at product is to use the thing you are building as if you were a customer. Be opinionated on how the thing you are building should work. Build to your own specifications, not to specifications handed to you by others, even if you are doing it as a side task. Have other people you trust tell you whether what you built is cool. If it's not, what happened? Why were you wrong? Repeat this a few times and you'll get better.

Code Review

Agents are going to write code, not humans. An agent can crank out 500 lines of complex, working code in less than 10 minutes. It may be ugly. It may be buggy. But it will exist and it will compile. No human software developer can even type that fast.

Humans are going to review code written by agents. In fact, code review is likely to be the most time consuming task in your day as an agentic software engineer. Accept it. You're now a code editor, not a code writer.

How do you get better at code review? This is an interesting question. I think the best way to become good at code review is to write a lot of code yourself. Writing is the best way to really embrace best practices, notice common mistakes, and identify edge cases. If agents are writing the code, how are humans born into the agentic world going become good code reviewers? Do we all need side projects to sharpen our code review skills? That seems inefficient. I don't have any good answers but I'm open to suggestions here.

Testing

Is the agentic era going to trigger the revenge of the software engineer in test, the much-maligned SDET? Some companies have a specific role for a software engineer that specializes in test. These are usually junior or less paying roles than traditional software engineers. Coding with agents massively increases the value of tests. We're all SDETs now.

Coding agents know that code needs to compile and tests need to pass. So, a good workflow is to have the agent write the tests first, review them to make sure they are correct, and then be very wary of changes to the tests in the future. Agents will change the tests to match buggy behavior and assert that's how it should work in the first place. The more specific your tests, the better the agent will do writing your code first try. The engineers best at building tests are going to be invaluable managing agents.

I find the engineers who are best at writing tests take pleasure in finding a failing test case. They are driven to break the code. Can you muster the requisite paranoia and patience to cover as many test cases as possible? You are ready for the agentic software engineering future.

System Design

Related to testing, you need to design your code and application such that it can be tested. You need to have separation of responsibilities between libraries. You need hardened interfaces. Deployed code must work the same as tested code. Building a testable system requires skills of senior engineers. I group all these skills into what I call "System Design" but you can also call it "Architecture".

Senior engineers become senior by building larger and larger systems. You need to be able to do that too. If you're not building new systems, pay attention to how systems work. Figure out places that fail often and ask yourself why. Are they hard to test? How could you change the system such that they were easier to test?

Operations

Finally, we have operations. How is code deployed? How is it monitored? What happens when it breaks? How quickly can you unbreak it when it does? At some companies, there is a different role for the software engineers who are good at this called a Site Reliability Engineer or DevOps specialist.

We're all going to become Agent Reliability Engineers. The software engineers that can run the most agents in parallel are going to produce the most code. Agents are going to manage teams of agents. You are going to be looking at dashboards and getting alerts when something on your team of agents goes wrong. This won't be much different than monitoring a website or service and getting engaged when something goes wrong. You're going to be designing and debugging agent deployments that shift the behavior of an entire complex network of agents. Learn how to run large scale systems.

If you hand off operations to another team now, consider bringing that function in house. Or, at least make friends with your Site Reliability Engineer ot DevOps specialist. Understand their perspective. You'll need to learn it soon anyway.

Skills--

These are the software engineering skills I think will be less valuable in the agentic AI era. This may seem like a short list but these skills used to be table stakes, you just had to have them, for a software engineer. Soon, I'm not so sure they will even be required.

Leet Code

Solving difficult algorithmic problems, which I call Leet Code after the popular website, were long the hallmark of a great software engineer. In fact, the standard software engineer interview was a series of Leet Code-style problems. The agentic software engineering era will replace the Leet Code era. These AIs are trained on Leet Code problems and can solve them instantly. In fact, coding agent performance is measured in many benchmarks by performance on Leet code style problems. You get what you measure. I think humans won't be finding cycles in a directed graph using breadth first search much longer.

I think Leet Code may live on in interviews because I've long thought Leet Code was less about testing coding skill and more about testing for a specific type of intelligence. The type of intelligence that makes you good at Leet Code, generally makes you good at writing all types of code. This type of intelligence is still valuable in the agentic software engineering era, as it is an easily testable signal of related types of intelligence. Leet Code style problems are also easy to ask for the interviewer, generally requiring few lines of code to accomplish something complicated. Leet Code interviews are here to stay.

Syntax

How do you dereference a pointer in C? How do you create a map in Java? How do you reverse an array in Python? The agent knows so you don't have to. Language syntax mastery is not going to be as useful as it was when recalling syntax from memory helped you write code faster. You'll need to know enough syntax to be able to read code that is known to compile. In fact, I don't know Golang and I've been very productive on our Golang project.

Typing

This is one I'm glad to see since I've been a two, max four, fingered typist my entire career. You aren't going to be typing much. The agent can think and type faster than you ever will be able to. Some people even use voice to text for prompts because the bandwidth is higher.

In fact, if you find yourself typing too much, it's a signal you haven't decomposed the problem you are trying to solve into a manageable enough piece for the agent to handle. If you're arguing too much with your agent, decompose the task.

Skills += 0

These are the software engineering skills I think will be similarly valuable in the agentic AI era.

Debugging

Agents are pretty good at debugging once the problem is identified and specified. Agents are not good at ambiguous bugs. I think software engineers will spend less time in the debugger pinpointing specific bugs and more time in the debugger trying to understand how to decompose a failure mode into something an agent can fix. Software engineers will still have to master their debugger, just not for smaller, reproducible, testable bugs. Software engineers will use their debuggers to understand how the code agents wrote works and why it's failing.

Documentation

High level documentation will still be human written. This type of documentation still requires some type of imagination an agent doesn't yet possess. Rote function or API-style documentation, however, is easy for AI to generate. This will be a win for software engineers because rote documentation was a chore to write.

But...it's Boring

This brings me to my final point. I think being an Agentic Software Engineer is going to be a more boring job than being a traditional Software Engineer. You worked in the Ford machine shop custom building cars, solving novel challenges every day. Now, you're screwing in the same bolt every day for the rest of your life. The world has more cars but you are materially worse off.

Most engineers live for the flow state where it's just you are your editor, all other distractions melt away. You are solving a hard problem, writing and editing code. You look up when the code actually works and two hours have passed. This is mastery. That's not going to happen very often, if at all, for an Agentic Software Engineer.

We already see this push back as major companies move software engineering to be more agentic. Here's a popular thread with a few open source DotNet PRs written by AI where human Microsoft Engineers are getting frustrated. Reviewing bad agent code, being lost how to correct it, and being forbidden from writing it yourself sounds terrible. The transition from today to the agentic world is going to be rocky for software engineers.

If you're looking at the list of skills in the Skills++ section and don't want to get better at some or all of them, I'm not sure what to tell you. If you're a Leet Code wizard and that's why you are a software engineer, I'm worried for you. The job of a software engineer is changing and maybe for the worse, at least for some.

Unfortunately, agentic software engineering is inevitable. Today, agents paired with human engineers are vastly more productive on average than human engineers alone, all for an additional $10/hour. Companies that embrace agents are going to out ship companies that don't. Software engineers that embrace agents are going to run those companies. Become good at working with agents. Become an Agentic Software Engineer.

Conclusion

I think we're all going to become Agentic Software Engineers. The skills needed are slightly different than the skills you need today to be a software engineer. The software engineers that embrace these new skills will run the software engineering companies of the future. Agree or Disagree? Come by our Discord and let's discuss.