The fear around AI and software jobs

The concern about artificial intelligence replacing software engineers is understandable. Generative AI can already generate code, explain existing code, write tests, produce documentation, debug certain problems, and build surprisingly polished user interfaces in a short amount of time. IBM's current overview of AI in software development describes AI as increasingly assisting with requirements, user stories, coding, testing, documentation, debugging, and other parts of the development lifecycle. [1]

Anthropic's analysis of more than 500,000 coding-related interactions reached an even more important conclusion: AI coding agents are increasingly being used for automation rather than only augmentation. In its 2025 analysis, 79% of Claude Code conversations were classified as automation, and Anthropic observed that web-development and user-interface tasks appeared among the most common uses. [2]

That means the threat should not be dismissed. Some software-development tasks are genuinely becoming easier to automate. Entry-level work centered around repetitive coding, simple interfaces, boilerplate generation, straightforward data transformations, and other highly structured tasks can reasonably face greater automation pressure. [2]

But a job is larger than the task it contains

The mistake is assuming that because AI can perform some software-development tasks, it therefore follows that the entire software-engineering profession can be replaced.

IBM describes the software lifecycle as increasingly involving AI across multiple stages, but also describes engineers as remaining responsible for overseeing AI-generated output, refining it against project goals, validating technical requirements, reviewing security, and maintaining human judgment. [1]

The 2026 Work Trend Index from Microsoft presents a similar direction. Its researchers report that as AI and agents take on more execution, people are increasingly shifting toward directing work, exercising judgment, controlling quality, and owning outcomes. [3]

That is a much more realistic way to think about the future of software engineering. The profession can change substantially even if the broader role remains necessary.

The real risk is task automation

Anthropic's research is useful because it does not merely say that AI is "helping developers." It shows that coding agents are already being used to automate meaningful portions of software work. [2]

At the same time, the results do not justify the claim that AI has already eliminated most software engineering work. Anthropic's analysis is a study of AI usage patterns, not proof of total job displacement. Automating a task is not the same thing as eliminating an entire profession.

The distinction matters because professional software engineering contains activities that are not reducible to typing source code: requirements interpretation, architecture, risk assessment, stakeholder negotiation, regulatory constraints, organizational politics, system ownership, incident response, quality responsibility, and business decision-making.

AI can generate code without owning the problem

A model can generate an implementation when it is given a sufficiently specified task. But professional engineering often begins before that task exists.

A customer may say: "We need a new customer portal."

The engineering questions are not limited to: "Which framework should we use?"

The real questions may be: What business problem is the portal solving? Which customers actually need it? What data can be exposed? What regulatory requirements apply? Who owns the business process? What does success look like? What happens if the system fails? What budget and timeline exist? Which existing systems must it integrate with?

AI can assist with many of those questions once information is provided. But the organization still has to decide what matters, what constraints are acceptable, and who is accountable for the result.

Context is one of the hardest problems

NIST's AI Risk Management Framework is particularly relevant here. NIST warns that many AI systems represent individual and social phenomena through mathematical quantities, but that this process can remove necessary context and make individual and societal impacts harder to understand. [4]

This is one of the most important limitations to understand about AI in professional environments. The problem is not simply whether a model can calculate something. The problem is whether the available representation captures the context required for the decision.

A technical system might measure customer complaints, employee productivity, fraud probability, or application performance. The measurement can be mathematically precise while the organizational interpretation remains uncertain.

Two organizations could receive the same metric and make different decisions because they have different risk tolerances, legal obligations, business strategies, cultures, and stakeholder interests.

The "temperature" problem

This is why I find the concept of temperature useful as an analogy.

A thermometer can tell me that a room is 32 degrees Celsius. That measurement is precise.

But the question: "Is 32 degrees hot?" depends on context.

Hot for whom? Compared with what? Under what humidity? During what activity? With what health considerations? Under what cultural or environmental expectations?

The numerical measurement has not changed. The interpretation has.

NIST's discussion of human-AI interaction makes a related point: mathematical representations of complex human and social phenomena can remove context that is important to understanding their real-world effects. [4]

Therefore, precision of calculation should not be confused with completeness of understanding.

Human judgment becomes more important, not less

Microsoft's 2026 Work Trend Index provides an interesting observation from its workplace research. Among the human skills respondents identified as becoming more important as AI takes on more work, the top answers were quality control of AI output and critical thinking. The report also says that many AI users treat AI output as a starting point rather than a final answer and remain responsible for evaluating and refining it. [3]

That creates a different engineering role: the engineer becomes increasingly responsible for judging what the machine produces.

If AI generates ten possible implementations, the valuable engineer is not necessarily the one who generated all ten. It may be the one who can determine which implementation is appropriate, which introduces unacceptable risk, which violates the organization's architecture, and which creates hidden operational costs.

AI can hallucinate and still look convincing

Another reason engineering judgment remains important is that AI systems can generate technically plausible but incorrect output.

IBM's current software-development guidance explicitly warns that AI-generated code can introduce security vulnerabilities and recommends human review, security audits, testing, and manual inspection of AI-generated output. [1]

This creates an important distinction: AI can produce an answer that looks professional without that answer being trustworthy enough to deploy.

The engineer therefore remains responsible for verification. Compilation is not proof that the system is secure. Passing a test suite is not proof that the business requirement is correct. A generated architecture diagram is not proof that the architecture is appropriate.

Software engineering becomes the verification layer

This is where rigorous software engineering becomes more valuable in an AI-assisted environment.

The engineer needs to establish: requirements, acceptance criteria, architecture constraints, tests, security controls, observability, documentation, review processes, and deployment safeguards.

AI can help produce artifacts for those activities, but the engineering process determines whether those artifacts can be trusted.

In this sense, software engineering becomes part of the control system around AI rather than something that AI simply eliminates.

The biggest leverage: move upward in abstraction

This is the career strategy I take from the current evidence.

I do not want to compete with AI purely on raw code-generation speed.

I want to remain technically strong while moving toward responsibilities that require understanding the problem, defining the solution, communicating with stakeholders, assessing risk, and owning the result.

This creates several layers:

Software engineering gives me the ability to build and evaluate systems.

Communication gives me the ability to explain those systems to different audiences.

IT consulting gives me the ability to diagnose organizational problems and propose solutions.

Business knowledge gives me the ability to understand why the organization needs the solution in the first place.

Governance and risk management give me the ability to understand what the organization can safely and legitimately do.

AI skills give me leverage to perform parts of all of this work faster.

The engineer as the human-AI supervisor

NIST's AI governance guidance is explicit that organizations should define and differentiate human roles and responsibilities for AI oversight and governance. It also recommends documenting human-AI responsibilities, risk information, transparency practices, and oversight procedures. [5]

That suggests an emerging category of engineering work that is easy to underestimate: supervising systems that themselves perform technical work.

The engineer may eventually spend less time manually writing every line of code and more time defining what the system should do, reviewing AI-generated implementations, creating evaluations, inspecting failures, managing risk, and maintaining accountability.

That is not the disappearance of engineering. It is a change in where the engineering responsibility sits.

The consultant becomes a translator

This is also where the IT consulting path becomes particularly attractive.

A client might say: "We want AI."

A weak consultant immediately starts discussing models.

A stronger engineer asks: "What business problem are you trying to solve, what process is currently failing, what data is available, what risks are acceptable, and how will we know the system actually improved the outcome?"

That is business analysis before implementation.

The consultant then has to explain the resulting architecture to engineers, the business case to management, the risks to security and compliance, and the practical impact to the people who will actually use the system.

The human becomes the translation layer between business intent, AI capability, software engineering, and organizational reality.

What skills become harder to commoditize?

I would not claim that any human skill is permanently immune from automation. That would be an impossible promise to make about a technology that continues to change.

A more defensible strategy is to deliberately strengthen skills that require context, accountability, human interaction, domain knowledge, and judgment.

For me, that includes:

business analysis, stakeholder management, technical communication, requirements engineering, consulting, negotiation, project planning, risk management, security governance, regulatory awareness, enterprise architecture, domain knowledge, and responsible AI oversight.

These skills do not replace technical engineering. They sit on top of it.

The strategy is not to fight AI

I do not think the smartest response to AI is to reject it.

IBM describes AI in software development as an increasingly important productivity and automation tool, while also recommending continued human expertise, review, testing, security controls, and oversight. [1]

Microsoft similarly describes a future in which people direct and supervise increasingly capable AI systems rather than simply performing every task manually. [3]

The better strategy is therefore: learn the technology deeply enough to understand it, use AI aggressively where it provides leverage, and develop the professional skills required to judge, direct, communicate, govern, and take responsibility for its output.

What I learned

The AI threat to IT/CS should be taken seriously, but it should also be framed accurately. AI can automate meaningful portions of software work, especially highly structured and repetitive tasks. That does not automatically mean the entire software-engineering profession disappears. [2] [1]

The more useful question is therefore not: "How do I prevent AI from replacing software engineers?"

It is: "What kind of engineer becomes more valuable when AI can perform more technical execution?"

My answer is an engineer who can still understand computers, code, architecture, databases, security, and systems at a deep technical level, but can also understand business problems, communicate with customers, manage requirements, evaluate risks, understand regulations and organizational constraints, supervise AI output, and take responsibility for the final result.

That is the direction I want to build: software engineering first, communication second, IT consulting and business context above it, with AI used as a force multiplier.

References

1. IBM. "AI in software development." Updated March 6, 2026.
   https://www.ibm.com/think/topics/ai-in-software-development
2. Anthropic. "Anthropic Economic Index: AI's impact on software development." April 28, 2025.
   https://www.anthropic.com/news/impact-software-development
3. Microsoft WorkLab. "2026 Work Trend Index: Agents, human agency, and the opportunity for every organization." May 5, 2026.
   https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization
4. National Institute of Standards and Technology (NIST). "AI Risk Management Framework: Appendix C - AI Risk Management and Human-AI Interaction."
   https://airc.nist.gov/airmf-resources/airmf/appendices/app-c-ai-risk-management-and-human-ai-interaction/
5. National Institute of Standards and Technology (NIST). "AI Risk Management Framework Playbook - Govern."
   https://airc.nist.gov/airmf-resources/playbook/govern/