What AI Will Not Replace in Software Engineering: An Honest Assessment

TL;DR — AI will replace a lot of software engineering work, but not all of it — and the honest line is more useful than either "AI kills programmers" or "AI is just autocomplete." The parts that survive are the ones that require real context, taste, ownership, and judgment about what to build and why.

In May 2024, I asked Claude to refactor a core module of my product. It was a 350-line TypeScript module handling subscription event processing. I had been putting off this refactor for three months because it was tedious — the code worked but was ugly, and fixing it properly required understanding all the interactions between the module and the rest of the system.

Claude took 40 seconds.

Those 40 seconds triggered a very real emotion in me: first surprise, then excitement, then a vague sense of fear. Not fear of being replaced exactly, but fear of what it meant about the future of the work I do.

Three days later, I reached a conclusion: AI will replace some programmers, but not all of them. And the part that will not be replaced has less to do with whether you can write code and more to do with what you actually do all day.

First, What Will Be Replaced

Let me be direct about this, because avoiding the question does not help anyone.

AI already does these things well:

• Generate standard CRUD code from specifications
• Write test cases based on code or specifications
• Explain what code does
• Debug common errors from error messages and stack traces
• Implement clear technical specifications
• Generate database migration scripts
• Write first-draft documentation
• Refactor code to new patterns

The programmers most at risk are those doing what I call standardized development — writing code to established patterns, implementing features to given specifications, without needing much business judgment. If your daily work looks like: receive this ticket, implement this feature in the way the ticket describes, submit a pull request — AI is getting good at that. Not perfect, but good enough to be concerning.

What Will NOT Be Replaced

1. Judgment

Question: Should this code use Redis or Memcached?

AI can give you 10 answers, each with merit. Some answers will reference benchmarks. Some will cite community consensus. Some will suggest trying both.

But the final decision requires judgment — your judgment, informed by knowledge of your specific context: your users, your scale, your team capacity, your operational maturity, your existing infrastructure.

Judgment comes from experience. From knowing what has worked and what has failed. From understanding not just the technical trade-off but the human trade-offs involved — who will maintain this, who will debug it at 2 AM, what happens when it breaks.

AI does not have judgment. AI has patterns. It knows what most developers do in most situations. That is not the same as knowing what you should do in your specific situation.

2. Product Sense

Question: Is this feature we are building actually what users need?

Code written perfectly for the wrong feature is worthless. Not worthless in a philosophical sense — worthless in a commercial sense. You shipped the wrong thing, your users are not happier, your product is not better.

Product sense — the ability to understand what users actually need versus what they say they need, the ability to prioritize ruthlessly among competing demands, the ability to say no to requests that are technically interesting but strategically wrong — this is not a technical skill. It is a human skill.

I have seen brilliant engineers ship features that nobody used because they solved a problem that did not exist. I have also seen mediocre engineers ship features that transformed the product because they understood the users deeply.

AI cannot give you that understanding. AI can analyze user feedback at scale. It cannot replace the qualitative judgment of what matters.

3. Breaking Down Complex Problems

Question: How do we approach building this system from scratch?

Taking a vague, complex problem — "we need to handle payments" — and breaking it into sub-problems that can be solved with code — "authentication flow, payment gateway integration, webhook handling, subscription management, invoice generation, refund processing" — this ability comes from experience.

It comes from having seen enough systems fail. From having debugged enough production issues. From knowing what questions to ask before building rather than discovering the gaps after.

AI struggles here. AI is excellent when the problem is well-defined and you know what you want. AI falls apart when the problem is ambiguous and you are not sure where to start.

4. Navigating Ambiguity

Question: This requirement is unclear. The product manager is not sure what they want. The stakeholder keeps changing their mind. What should we do?

AI performs superhumanly on well-defined tasks. AI fails completely on poorly-defined tasks.

Software engineering in practice is mostly poorly-defined tasks. Requirements are vague. Stakeholders are not sure what they want. Edge cases emerge that were not anticipated. The right answer depends on factors that are not written down anywhere.

Navigating ambiguity is a human skill. It requires understanding politics, relationships, trade-offs, and the organizational context. It requires knowing when to push back and when to compromise. AI has none of this.

5. Stakeholder Communication

Question: How do I explain to the product manager why this will take three weeks instead of two days?

Writing code is 30% of software engineering. The other 70% is communication: explaining technical constraints, managing expectations, translating between technical and non-technical languages, building trust, negotiating priorities, handling conflict.

AI cannot do this. AI cannot have a relationship with a product manager. AI cannot read the room in a meeting. AI cannot negotiate a deadline with empathy while protecting technical quality.

My Honest Assessment of My Own Situation

AI tools currently help me with:

• Generating test cases for features I build (saves approximately 2 hours per feature)
• Writing scripts for small automation tasks
• Explaining error logs quickly
• Drafting documentation for new API endpoints
• Generating suggestions during code review

These tasks save me approximately 20–30% of my time.

I am not directly replaceable by AI for reasons that have nothing to do with my coding ability:

1. I have eight years at my current company. I know a lot of context that is not written down anywhere — why certain architectural decisions were made, who to talk to when something breaks, what the historical constraints were, which stakeholders are reliable and which are not.

2. I have built trust with my team over years. That trust means people take my technical recommendations seriously and act on them.

3. I have product sense. I understand our users reasonably well. I can prioritize effectively.

4. I know how to navigate ambiguity. I know when to push back and when to compromise.

The Programming Jobs That Will Survive

Based on my assessment of the current state and trajectory of AI capabilities:

The programming jobs most likely to survive AI disruption are those where:

• The problems are ambiguous, not well-defined
• Stakeholder communication is high
• Deep domain knowledge matters
• Trust and relationships are built over years
• The output is not code itself but outcomes that require code plus judgment

The programming jobs most at risk are those where:

• Problems are well-defined and standardized
• Communication requirements are low
• Domain knowledge is easy to acquire quickly
• Trust is not a prerequisite
• The output is primarily code

Specific Advice

If you are early in your career: Learn to code well enough that you understand what AI is generating. Do not rely on AI to write code you could not write yourself. The moment you cannot evaluate AI output, you become dependent on it. Dependency is a bad position to be in when the tool changes.

If you are mid-career: Invest heavily in judgment, product sense, and communication. These compound over time in ways that AI cannot replicate. The programmers who will thrive are the ones who use AI to amplify their judgment, not replace it.

If you manage programmers: Do not measure output by lines of code or tickets closed. Measure outcomes. Measure quality of judgment. Measure stakeholder satisfaction. The programmers who thrive will be the ones who use AI to amplify their judgment, not replace it.

What My Colleagues Think

I have talked to about 20 colleagues about AI and programming at various points over the past two years. Their views cluster into three groups:

Group 1 (about 30%): AI is going to replace us. We need to get out now.

Group 2 (about 40%): AI is a useful tool but will not replace real engineers.

Group 3 (about 30%): I have not thought much about it.

Group 1 is more anxious than the evidence warrants. Group 3 is less prepared than they should be. Group 2 is closest to correct but often underestimates the rate of change.

The honest answer is that nobody knows. The people most confident about what AI will do to programming jobs are the most likely to be wrong, in both directions.

My approach: act as if the future will be challenging but manageable. Build skills that are robust to AI disruption. Invest in judgment, relationships, and communication. Do not panic and do not ignore.

The Skills That Matter More, Not Less

Here are the skills I have deliberately invested in since AI started getting good at coding:

Systems thinking: Understanding how complex systems interact — how a change in one part of a system affects other parts. AI struggles with this.

Communication: Explaining technical concepts to non-technical people, writing clear documentation, giving effective presentations. AI struggles with this.

User research: Talking to users, understanding what they actually need versus what they say they need, synthesizing qualitative insights. AI cannot do this.

Business judgment: Understanding how technical decisions affect business outcomes, prioritizing work that matters, saying no to work that does not. AI cannot do this.

Learning how to learn: The skill of learning new things quickly and effectively. This matters more, not less, when AI changes the landscape.

Why I Am Optimistic

Despite the uncertainty, I am genuinely optimistic about the future of software engineering as a career.

Here is why:

Software solves real problems. People need software to manage their finances, communicate with each other, run their businesses, and access information. This need is not going away.

The need for judgment will grow. As AI handles more execution, the judgment to know what to build and why will become more valuable, not less.

The problem space is expanding. AI makes it cheaper to build software. Cheaper software means more software gets built. More software means more demand for people who can build it well.

The new jobs do not look like the old jobs. They involve more judgment, more creativity, more human connection. These are the jobs humans are best suited for.

Why I Am Cautious

I am also cautious. Here is why:

The rate of change is fast. AI capabilities are improving faster than most people expect.

The transition will be significant. Some jobs will be eliminated faster than new jobs are created. The people most disrupted may not be the people who adapt fastest.

The distribution of gains is uneven. The companies building AI will capture most of the economic value. The workers using AI will capture some of it. The workers replaced by AI will capture none of it.

My caution leads me to: build skills that are robust to disruption, maintain financial flexibility, keep the day job while building optionality.

The Specific Actions I Am Taking

1. Learning to work with AI, not against it. I use AI tools every day. I am getting good at knowing when AI is helpful and when it is not.

2. Investing in judgment skills. I practice making decisions, reviewing outcomes, and learning from mistakes. Judgment is a skill that improves with practice.

3. Building financial flexibility. I keep my expenses low. I maintain a runway. I do not overextend financially.

4. Building optionality. The product I am building is optionality. If one path closes, I have others.

5. Staying curious. The people who thrive in changing environments are the ones who stay curious about what is coming next.

Did this article help you? If you're working through career direction, or want to use AI to work smarter, let's talk — I'm happy to help you think it through.