The Developer Is Not Dead. The Developer Is Evolving.

A postgraduate perspective on AI, open-source tools, and what it means to build software in 2026

By Himavisi Ekanayake | Business Information Systems | March 2026

There is a conversation taking place right now across every engineering floor, every university lab, and every LinkedIn feed worth following. It goes something like this: artificial intelligence can now write code. Does that mean we are no longer needed?

As a postgraduate student straddling both Software Engineering and Business Information Systems, I sit at an unusual intersection of this debate. I am technically trained enough to understand what these tools do, and business-minded enough to ask what they mean for organisations, careers, and the profession at large. This article is my honest attempt to answer that question.

Part I: What Is Actually Happening Right Now

Let us be precise about the current moment, because precision matters more than panic.

Earlier this year, Anthropic released an updated version of Claude Code, its autonomous coding tool. Developers across the industry described the leap as more significant than the arrival of ChatGPT in 2022. The tool can now build features, run tests, fix bugs, and review its own output with minimal human instruction. One engineer described writing hundreds of thousands of lines of code across six projects in two weeks, having read almost none of it himself.

"The cost of software production is trending towards zero." — Malte Ubl, independent software engineer and former Google engineer, reflecting on the post-Opus era

This is not marketing. It is a genuine inflection point. And yet, the reaction that serves no one is fear. The reaction that serves everyone is understanding.

Part II: The Open-Source Dimension

Running parallel to the rise of proprietary AI coding assistants is a quieter but equally significant shift: the maturation of open-source AI infrastructure.

In 2026, developers no longer need enterprise licences or cloud budgets to access capable AI models. Tools that were previously accessible only to well-funded teams are now available to independent engineers, university researchers, and startups operating on minimal runway. This is not a minor convenience. It is a structural change in who gets to build, and what they can build with.

For a BIS student, this matters because it reshapes competitive dynamics in industries that depend on software. For an SE student, it means the barrier between an idea and a working prototype has collapsed. The question is no longer whether you have access to the tools. It is whether you know how to direct them.

Open protocols such as Anthropic's Model Context Protocol (MCP) are also beginning to standardise how AI tools communicate with external systems. Rather than every developer building bespoke integrations, a shared protocol allows AI assistants to interact with databases, APIs, and enterprise software in a consistent, auditable way. This is precisely the kind of infrastructure that transforms experimental technology into dependable business capability.

Part III: The Skills That Actually Matter Now

Here is what the data tells us, stripped of both the hype and the dismissal.

According to the 2025 Stack Overflow Developer Survey, 84% of developers now use AI tools regularly. Yet the software engineering job market is still projected to grow by 17% through 2033, adding approximately 327,900 new roles globally. These two facts are not in contradiction. They reflect what always happens when a productivity tool reshapes an industry.

The roles that are shrinking are the ones centred on output volume: writing boilerplate, scaffolding APIs, generating test coverage for well-defined requirements. The roles that are expanding are the ones centred on judgment: system architecture, security governance, cross-functional problem framing, and the ability to understand when an AI-generated solution is technically correct but strategically wrong.

Writing code is to software engineering what laying bricks is to architecture. The bricks can be automated. The architecture cannot.

For those of us completing postgraduate programmes right now, this is clarifying rather than threatening. It means the skills we are developing, understanding systems holistically, communicating across technical and non-technical stakeholders, evaluating trade-offs under uncertainty, are not being commoditised. They are becoming the baseline expectation.

What This Means for SE Postgraduates

The engineers who will define this decade are not the fastest typists or the most prolific committers. They are the ones who can articulate what needs to be built, evaluate what gets returned, and take responsibility for what ships. Claude Code's creator stated in early 2026 that the title of software engineer may eventually evolve toward something closer to builder or product engineer. Whether or not the title changes, the underlying truth is sound: the most valuable thing a software engineer offers is not syntax. It is judgment.

What This Means for BIS Postgraduates

Business Information Systems has always existed at the junction of technology and organisational strategy. That positioning is now more valuable than ever. The organisations struggling with AI adoption are not struggling because the models are insufficient. They are struggling because up to 90% of their enterprise data remains locked in unstructured silos, because governance frameworks have not kept pace with capability, and because the people who understand both the business problem and the technical landscape are in short supply. That is the gap a well-trained BIS professional is built to close.

Part IV: A Closing Thought

Every generation of engineers has faced a version of this question. COBOL was supposed to let business managers write their own programs. No-code platforms were supposed to eliminate the need for developers. Each time, the demand for software grew faster than the automation of software creation. There is a principle in systems theory called Jevons paradox: making a resource more efficient tends to increase its total consumption, not reduce it. Software has followed this pattern without exception.

The developers and analysts who will thrive in this environment are not those who resist AI tools, nor those who defer entirely to them. They are the ones who learn to direct them, critique them, and build things with them that would have been impossible to build alone.

That is the work ahead. And from where I stand, it is genuinely exciting.

What is your experience with AI tools as a student or early-career professional? I would be glad to hear how others are navigating this shift.

#SoftwareEngineering #BusinessInformationSystems  #AITools  #OpenSourceAI  #PostgraduateLife  #FutureOfWork  #TechCareers  #Artificial