Over the past 1.5 years, I’ve had many conversations with friends where they express fear about AI coming for our software engineering jobs. I’ve gotten a little tired of explaining my opinion: we will be just fine.

After using Claude Opus 4.5, this opinion is even stronger. Opus 4.5 is really good at coding. You might think that this is counter to my opinion, but what I expect to happen is a shift in the distribution of skilled software engineers (see image above).

A disclaimer: all of this is just my opinion! Don’t make any Polymarket bets based on this blog post and get mad at me if I’m wrong.¹

Big tech layoffs are happening left and right, but that isn’t due to job elimination via AI. There is probably no such thing as “normal” economic times, but a president shooting the economy in the foot with nonsensical trade policy definitely counts as weird.

At the same time, there is a tremendous boom of funding going towards AI startups. Inevitably, many of those laid off will shift towards working at promising startups. Five years ago, I had never heard of OpenAI or Anthropic and now they are the most sought after companies to join.

The same pattern of bust followed by boom happened in 2008 and 2020. I suspect my own layoff in early 2025 was partly due to economic conditions. And similarly, I have decided on the entrepreneurial route. My timing could not be better.

The pace of innovation has accelerated at an astonishing rate in recent human history. The internet only became commonplace 30 years ago; today we’ve invented robots that can think nearly as dynamically as we do².

The world is still somewhat slow to adapt in spite of this. There are still many institutions that operate by sending and receiving faxes. The entire world isn’t going to change overnight, despite what your LinkedIn or Twitter feed is telling you.

The number of software engineering jobs have grown exponentially in the last 50 years. I expect that as software engineers become more productive with AI, the demand for bespoke software will increase because it will be cheaper to produce.

Even before LLMs took over, low-code automation tools like Zapier and Airtable were on the rise. The world was already demanding the ability to automate tedious tasks without needing the expensive time of an engineer.

The original computers were people. Their job was to manually do math and compute. Planet Money did a great episode on the invention of the digital spreadsheet and how that impacted jobs:

This has been the general pattern of automation throughout human history. As technology continues to develop, fewer humans are needed to do a given task. The task doers have deeper knowledge and skills compared to their predecessors.

My last name means blanket weaver. If I had inherited this career, I assume I would know how to repair mechanical looms, international distribution, the science behind different fabric materials, and learn many other specialized skills that were unknown several hundred years ago.

I see LLM coding tools as the mechanical looms of software engineering. It’s still important to have a knowledgeable person do the work; it’s just that the work looks different. No longer do I have to manually write API endpoints or simple button components by hand. But it remains critical that I understand how to do that work correctly and to fix the mistakes of AI if needed.

I’ll repeat: Opus 4.5 is really good at coding. A year ago, LLM coding tools were quite powerful, but you couldn’t trust them to do anything too complex without guidance. Opus 4.5 has changed that; it’s a tremendous leap forward from the previous tremendous leap forward. And yet, I don’t think they’ll ever be able to write software without human guidance.

For an LLM to be an effective assistant, it needs to follow instructions. As a result, it will do a lot of things that are bad ideas.

I was the first engineer on the Marketing Technology team at Square and was often pulled in to assess feasibility of requests or to scope projects. Many times, I said no. The ask was sometimes nonsensical. Or there would be odd dealbreakers from other teams. In some projects, the request would come from someone who had incorrect assumptions about how our systems work.

It was my job to understand these requests, synthesize requirements, and research potential solutions. Perhaps an LLM can do that too, but it’s default to action often gets it into trouble. Blindly trusting an LLM can cause a lot of problems. Every week I seem to read post about an agentic workflow that dropped the production database.

When I switched to product engineering. A lot of my time was spent arguing with other engineers across the company. We would disagree on how APIs should be designed, how much info we should display in a certain UIs, what were the limits of the data we could fetch, and really hating the way certain central APIs were structured and making the case we should go to war with that team.³

If Claude wants to take that part of my job, be my guest. But I don’t think he’ll be very good at it.

There is a sad sentiment held by many engineers about their skills becoming irrelevant. But this is certainly not the first time. How did assembly programmers feel when higher level languages abstracted away memory allocation? How did punch card programmers feel once code was no longer punched in paper? I got so good at sharpening my hole-puncher and memorizing the encoding patterns! I can’t believe these skills are now going to waste!

We are simply at the next evolution of programming. Who knew that the highest level programming language was actually English?

I share in this sadness but I am much more enamored by the possibilities of this era. I built an app for my new talent agency and hiring platform in 10 days. Before these tools, it would have taken me at least a month to write.

This has always been my impression of LLM coding tools since their inception. Initially, Claude Code had me fooled. I was convinced he was all genius. I trusted him blindly. I didn’t inspect the code changes too closely. When developing my hiring platform, I eventually noticed certain API calls were leaking restricted data:

“Claude, why did you include the entire candidate record in the GET interview response?”

Oh, we have to query this record from the database for some logic in the API route, so I figured I should just include the whole record in the response since I already had it.

“That data isn’t needed in this route. And don’t you remember when I had you create API access controls to carefully restrict what fields were accessible by different user types?”

Oh yeah. Whoops 🤷

The bad decisions would often compound. Claude never thought to make React component files small and modular. It rarely considered reusing code or downloading existing packages. There were excess tables in the schema and API routes that were never utilized. I eventually found two separate PDF generation functions that were nearly identical!

The productivity gains from Claude were worth it as I was building my MVP. But I have incurred tech debt that will come due.⁴ To use LLMs effectively, you still must be a good engineer that makes good coding decisions.

The measurement is: how effective of a software engineer are you relative to others?

This image is my prediction. We can assume that a pre LLM coding tool world had a normal distribution.

With the power of AI, the worst engineers become more productive. The quality of the code they are writing is probably equally bad, but they will be able to produce much more output. That will move them up the chart.

Similarly, decent and good engineers become much more productive. They know how to make all the right decisions and steer the AI accordingly. They will generally move up as well.

But many engineers will move down. AI tools will make them lazier. Certain skills and best practices will atrophy. Their volume of output may improve, but the quality will worsen.

Thus, the shift to a bimodal distribution.

I am already seeing the effects of promptosis⁵ on engineers I interview. Candidates are writing messy code and don’t clean it up. They are making incredibly odd choices because they don’t know how to code in different contexts. For a few people, it’s as if they’ve completely forgotten how to think.

It’s disheartening but I think this new disease is exacerbating the symptoms that lazy engineers already have, not causing them.

As the self proclaimed authority on engineering evaluation, I think live coding interviews are more important than ever. As long as your questions evaluate for real world skills, it’s even more important to use these to determine if your candidates can think for themselves.

AI assisted interviews are becoming popular; I’m writing a few such questions myself. Being able to effectively guide the AI is now a critical skill in the engineer’s toolbox.

It’s still early, but I believe an effective interview process should ask both types of questions.

tl;dr - the work is changing but the job stays the same. I believe that the gains in productivity for software engineers will allow for more companies to build more software. This is a good thing! There is so much more software that could be written to solve problems⁶ that are currently restricted based on cost.

I predict that the demand for software engineers will grow. Even more software jobs will be created. The best engineers will have even greater outcomes.

But the question for us as software engineers: as you start adopting these tools, where are you going to fall on that chart?