Abstract
GenAI has changed the way we develop software. As of today, GenAI has helped us write code faster, assisted in managing requirements, and even supported us in making architectural decisions. However, despite its capabilities, we still apply AI within the established categories of software engineering: coding, requirements engineering, software architecture, etc.
But have you ever wondered what software engineering will look like once AI evolves and matures? This article aims to answer that question. It introduces a simple mental model that illustrates how all systems, including sociotechnical ones, are shaped by constraints.
The article further examines which human limitations hinder software engineering today and how AI could alleviate these constraints in the future. As a result, AI is likely to completely reshape the categories and paradigms of software engineering as we know them.
This article, splitted in three post parts, presents a projection of what this transformation might look like.
Part 1 introduces the key structural aspects of today’s software engineering and the role of AI within these structures.
Part 2 explores how human limitations led to the emergence of these structures and which innovations are linked to these constraints.
Part 3 presents a projection of how software engineering might be transformed, both socially and technically, once AI partially or completely alleviates human constraints.
Part 1: AI in the Realm of Human-Dominated Software Engineering
When confronted with new technology, we tend to interpret it through existing categories. Initially, a smartphone was seen as merely a smarter phone. However, over the following decades, it ultimately evolved into a pocket computer. If we were to encounter such a device for the first time today, we would likely call it a “pockputer” rather than a smartphone. Smartphones (or pockputers) have drastically reshaped how we communicate with each other and consume information.
As Marshall McLuhan put it, innovations are not additive—Europe after the invention of the printing press didn’t become just “Europe plus printing press,” but rather an entirely new Europe.
The same is likely to happen with AI and software engineering. It will not simply be “software engineering plus AI,” but an entirely new form of software engineering. To understand what will happen in the future, we must first examine the forces that shape software engineering today and how AI is set to transform them.
AI Within Existing Categories
Let's start by examining the common sociotechnical architectures of our organizations. See the picture below.
To keep these artifacts congruent and coherent—or, simply put, aligned—people must align themselves with each other. For example, during backlog refinement, teams discuss work packages together to ensure alignment between requirements and code.
As we began integrating GenAI into software engineering, we did so within existing categories, as illustrated in the picture below.
A common pattern in software development is that people in different roles and functions work on their respective artifacts. Programmers write code, UI designers create UI designs, Product Owners draft User Stories, Testers develop Test Cases, Business Analysts define Requirements, and so on.
To keep these artifacts congruent and coherent—or, simply put, aligned—people must align themselves with each other. For example, during backlog refinement, teams discuss work packages together to ensure alignment between requirements and code.
As we began integrating GenAI into software engineering, we did so within existing categories, as illustrated in the picture below.
We enhanced our tools with various copilots that help automate mundane tasks, validate our outputs, and assist in brainstorming ideas. However, our AI tools have remained confined to existing categories, such as GitHub Copilot for code or Atlassian Intelligence for user stories in Jira.
Although numerous tools can generate one artifact from another—such as converting UML diagrams into code—ultimate alignment between artifacts is still achieved through human-driven coordination, such as meetings, chats, etc.
Why does software engineering today rely on all these categories and human-driven methods of alignment? The answer lies in the natural constraints of human cognition.
Systems and Constraints
All systems are shaped by constraints. The structure of a snowflake is determined by constraints of humidity and temperature; the structure of a city is shaped by constraints of space and infrastructure capacity; the structure of a solar system is governed by the constraints of gravity and centrifugal forces.
Accordingly, when constraints change, so does the structure of the systems. We call this process transformation.
Here’s an example:
A few hundred years ago, the structure of our societies was profoundly influenced by a single major constraint—the short shelf life of food.
As a result, people had to live close to farms, and farming was widespread, decentralized, and consisted of relatively small ventures. Food was bought almost daily from small local stores, where customers often interacted directly with farmers. Meals were prepared shortly after purchase and consumed immediately, typically shared with family members.
The invention of the refrigerator was more than just a fancy home appliance—it relaxed a fundamental constraint that had shaped our way of life. With refrigeration, food no longer had to be cooked and eaten immediately or consumed synchronously with family members. Grocery shopping no longer had to be a daily task—we could now buy supplies for an entire week.
As a result, large faceless supermarkets, offering everything in one place, replaced small specialized stores. Large-scale, distant farming enterprises displaced local farmers. The entire architecture of food production, distribution, storage, and consumption was transformed because a once-rigid constraint was relaxed.
One could even interpret the refrigerator as a transfer function—it ensured we remained well-fed, but perhaps, also, more isolated.
The question is: which constraints shape software engineering, and what transformation is likely to occur once AI relaxes these constraints?
Part 2 of this series will introduce two shaping constraints and explain the history of innovations in software engineering as a continuous attempt to cope with these constraints Stay tuned…
Comments