Introduction
AI can now write significant amounts of software code, including increasingly large and complex systems. This is rapidly changing the way software is developed and has already affected the careers of many in the industry. It has also raised questions about how reliably AI can code complex systems, how its risks can be managed, and the extent of job disruption. Most importantly, it raises a fundamental question: does the ability of AI to write software make software engineering less important?
The answer lies in distinguishing coding from software engineering. Software development involves much more than writing code. At the very least, it involves five activities: understanding requirements, design, coding, verification, and support. The quality of each activity affects the ones that come next. Coding is only one part of this larger engineering process.
This article focuses on software design and, in particular, on how the use of AI coding tools is changing its role and importance. Software design is one of the key activities in the software life cycle. Assuming that user requirements have been gathered correctly, design becomes a key factor in the success of the system. AI makes code generation easier, but this makes software design more important, not less. For large software systems, the effectiveness of AI in coding and support will depend significantly on the quality of the design. As teams depend more and more on AI coding tools, they will have to pay greater attention to how their software is designed.
To understand why this is happening, we will briefly discuss the fundamentals of both software and design. We will use a stakeholder-centric approach and see how AI itself can become a stakeholder in software design. Through these discussions, we will see that the fundamental goals of software design remain the same, but their importance increases as AI takes on a larger role in software development.
What is software
We often think of software as a kind of machine. Like all machines, it takes certain inputs and provides outputs.
But software is a special type of machine. The inputs and outputs of software can change frequently. More importantly, software itself is continuously modified while it remains in operation. Over a period of time, a software system can undergo so many modifications that it may bear little resemblance to its initial state.
Any complex system can be thought of in terms of a simple formula:
where x is the set of all inputs, y is the set of all outputs, and A contains all the processing that is done to convert x to y.
Take the example of an airplane. It takes many inputs from its sensors and through its controls. But these are not the only inputs. Environmental factors such as wind and pressure, altitude, gravity, and even the weight and movement of the passengers are all inputs to the plane. The outputs are the changes it makes to the engine parameters and, ultimately, changes in speed, angle and so on. We can imagine that both x and y are large sets, and A is made up of thousands of parts interacting with each other.
Our brain, with 80 billion neurons and nearly infinite numbers of inputs and outputs, is also a good example of a complex system.
Software is one of the most complex systems created by humans. The number of inputs and outputs of a system such as an ERP can be mind-boggling. But the real challenge of a software system lies not only in its complexity, but in its elastic nature: it undergoes frequent modification throughout its life, often while continuing to serve its users.
The brain is a good example of a complex system that changes over time. New connections between neurons, and changes in the strength of existing connections, allow the brain to learn new things. Learning can mean incorporating new inputs, new outputs, or new relationships between them.
But the brain is a unique system. There are hardly any other examples of natural or man-made systems that undergo such frequent modifications to accommodate changes in their inputs and outputs while continuing to operate. This puts software in an esoteric club: complex systems that are continuously modified during their lifetime.
This characteristic has an important implication for software design. A designer is not only designing the system that exists today; the designer is also designing how that system can be understood, modified and extended tomorrow. The design therefore has to account not only for the current requirements of the system, but also for the changes that the system is likely to undergo throughout its life.
What is software design
Design is a kind of planning. More precisely, design is a plan for achieving the goals of a system. Imagine you are planning for a trip. The plan will include the destination, travel, stay, places to see, day-wise itinerary, documents required and many other things. Taken together, this plan can be called a design. Some parts of the plan will be more concrete than others. For example, tickets and accommodation may be booked firmly in advance, while the plan for a particular day may be decided only vaguely.
When you actually start the trip, the design turns into execution. Some parts will go as planned, while others will have to be adjusted to accommodate real-time situations. Software design follows a similar pattern. Being virtual in nature, it can be described in much greater detail than a holiday trip, but it is still a plan that guides execution.
A closer analogy for software design is furnishing a house. If we want a comfortable and functional home, we have to plan the furnishing in advance. We first identify the civil work, electrical wiring, plumbing and furniture that will be needed. Some components can be specially made, while others can be bought from the market. We then have to ensure that all these components fit together and work as a whole. A washing machine, for example, will need water, drainage and electricity connections, and the design has to ensure that these are available at the right location. The design can also be progressively refined. Once we decide that a wall-mounted folding bed will go in the second bedroom, we can drill down into the design of the bed itself.
Software design has much in common with this process. The first job of the designer is to break down the system into progressively smaller components until each component is simple enough to understand and build. The interconnections between these components are worked out, and the technology for each part is decided. Some components may be built specifically for the system, while others may be ready-made and directly reused.
Software design also includes other aspects of planning. It lays down guidelines for coding that the future builders of the system should follow. It specifies how different components should interact and how the system should be tested. These guidelines help ensure that individual pieces of code remain consistent with the overall design.
An important point to keep in mind is that software design is not a one-time activity. While the bulk of the design is done in the pre-coding phase, design also happens during coding (peri-coding) and during support (post-coding). Just as some aspects of a trip are decided during execution, some design decisions are made while the software is being built or modified. The fact that these decisions are made during coding does not make them part of coding; they are still part of the design activity. For example, developers may decide the names of database tables, functions and variables during coding, based on design guidelines. Such decisions are part of design activity, delegated to the coding phase for convenience. Similarly, design continues to evolve during the support phase as new user requirements emerge.
Thus, software design is not simply a blueprint created before coding begins. It is an evolving plan for achieving the goals of a complex system, together with the decisions and intent that guide how the system is built, understood and changed over its lifetime.
Why is software design needed?
We have discussed examples of design in holiday trips and interior decoration. When you go on a tour, you plan carefully so that you can enjoy the trip without unnecessary hiccups. Similarly, you design the furnishings of your home so that it provides the desired ambience, comfort and utility to you and your guests.
Any design is ultimately tied to the objectives of its stakeholders. In a tour, the touring members are the stakeholders, and the plan is designed to help them achieve their objectives. In home decoration, your family and guests are the stakeholders, and the design is meant to provide them with the desired comfort, utility and experience.
Software design follows the same principle. A software system has multiple stakeholders, each with different objectives, and a good design must help each important stakeholder achieve those objectives. The stakeholder’s objective determines what the software needs to provide, and that in turn determines the design requirements.
Listing the stakeholders of a software system will help us understand these objectives. The stakeholders that immediately come to mind are:
-
Users of the system
-
Administrators of the system
-
Owners of the code
-
Clients of the code
These are the more obvious stakeholders of software. But there are two others that are less obvious:
-
Code consumers
-
Future developers
The modular nature of software creates the need for code consumers. The code you write is often used by other developers to build ‘their’ part of the software. This is like a wall-mounted bed made by a carpentry shop and used by another carpenter furnishing your home. Code consumers can be members of your own team or members of other teams in your company. They can also be clients if your business involves creating software libraries.
The objective of a code consumer is to use the code easily and reliably. This objective translates into several design requirements. The software designer has to ensure that:
-
The code gives the right amount of control. The consumer should have appropriate control over the behaviour of the code, mainly through the parameters and options provided by its interfaces.
-
The code is robust. Code consumers might pass values that are not strictly correct. A well-designed code unit should handle such situations gracefully rather than simply breaking down.
-
The code is responsive and informative. When the code does not work as expected, it should provide useful information through error codes, relevant values, warnings and other feedback.
-
The code is well documented. For example, if you are designing an API, its purpose, working, inputs, outputs and possible errors should be documented clearly enough for the consumer to use it without unnecessary struggle.
The future developers are another large and important category of stakeholders. They will maintain, modify and support the software system throughout its lifetime. A significant part of a software system’s life is spent in maintenance and support, making future developers important stakeholders of the original design.
When future developers work on the software, they will modify it. A modification typically goes through the following stages:
-
Understanding the changes in requirements
-
Identifying the impact on the code
-
Updating the design and test cases
-
Making the changes
-
Testing the updated software
These activities give us a good idea about the qualities that software should possess to serve future developers well. They can be summarized as ‘friendliness’ attributes. Some of them are described below:
Navigation-friendly: It should be possible to trace the connections from user requirements to the smallest code components. For example, if there is a requirement for Single Sign-On (SSO), the future developer should be able to trace this requirement to the database tables and modules that implement the feature. This makes it easier to understand the system and identify the impact of changes in requirements.
Modification-friendly: There are many design principles that fall into this category. If the software has well-designed modules with simple interfaces, designing and executing changes becomes easier. If commonly used routines, such as database operations, are grouped into separate, easily callable units, changes are easier to implement and manage.
Containment-friendly: The effect of a change should be limited to the smallest possible part of the system. A fundamental change, such as a change in a database table, can otherwise ripple throughout the system. Good design establishes boundaries between components so that such effects are contained.
Thus, the relationship between stakeholders, their objectives, and design requirements provides a useful way to understand the purpose of software design. The aim of this article is not to list all possible stakeholder objectives or design principles, but to provide enough examples to demonstrate how design serves the different stakeholders of a software system. This perspective will also help us understand why AI, when it becomes a consumer and modifier of software, needs to be considered as a stakeholder in software design.
Software design and AI-SDE
The proliferation of AI in coding is changing the nature of the stakeholders we need to consider in software design. Both code consumers and future developers can now be AI coding tools rather than human developers. We can call these tools AI Software Development Engineers, or AI-SDE, to mirror the popular SDE designation of human developers.
AI-SDE as a code consumer
As a code consumer, an AI-SDE may have to choose between using an existing module and writing a new one. Consider a simple example. Suppose it has to store some values in a database. It can easily generate the code to do this, but the software design may specify a library that handles all database operations. The AI-SDE has to discover this library, select the right class and method, understand the interface, pass the parameters correctly and handle the return values.
The design objectives of control, information and documentation now become particularly important. Human developers can often work with incomplete documentation because they can rely on experience, conversations with other developers and tribal knowledge of the system. An AI-SDE has to rely much more heavily on the information that is explicitly available to it. The architecture, design guidelines, interfaces and specifications of the database library therefore need to be clear and up to date.
If this information is missing or incorrect, the AI-SDE may regenerate code for database operations rather than use the existing library. If the documentation or interface specifications are wrong, it may generate code that is also wrong, requiring intervention from a human SDE. Thus, a good design helps the AI code consumer to determine what code should not be written because the required capability already exists.
AI-SDE as a future developer
The designer has to pay even more attention to the AI-SDE as a future developer or modifier of the system. Generating a new function is relatively easy because the AI can work from a defined requirement and produce an implementation. Modifying an existing mature system is fundamentally different. Before making a change, the AI-SDE has to understand the existing system, assess the impact of the change, identify the components involved, update the design and test cases, make the changes and finally verify that the system continues to work correctly.
This is where the navigation, modification and containment-friendly characteristics discussed earlier become important. The AI-SDE must be able to navigate from requirements to the relevant parts of the system, understand the relationships between those parts and determine how far a change might propagate. A well-designed system makes this process easier by making its architecture, dependencies and boundaries explicit.
This also means that design cannot remain a document created once at the beginning of the project. As the software evolves, the design must evolve with it. When an AI-SDE proposes a significant change, the corresponding design should be updated so that it continues to represent the system accurately. Human SDEs may review and approve these changes, particularly where the impact is significant. Test plans should also be updated so that the effects of the change can be assessed.
Why AI makes design more important
As we have seen, developers — both human and AI — who work as code consumers and future developers need a significant amount of design support. They are much more effective when the code adheres to clear design principles. For example, a future developer trying to assess the impact of a change will benefit greatly from a codebase that is navigation-friendly.
But what happens when the design of a system is inadequate? A human SDE can still work effectively, although it may take more time and effort. They can talk to other team members, consult documentation, or draw upon their own experience. It is not uncommon for SDEs to call former team members who have since left the organisation to ask questions about a codebase. Human SDEs can also draw upon their knowledge of the organisation’s practices to fill in missing pieces.
The AI-SDE is different. It is much less effective when the design does not adequately support its task. More importantly, its ability to compensate for missing information is limited. An AI-SDE may attempt to complete the task even when it does not fully understand the system or the intent behind the existing design. In the absence of a strong design, it can therefore generate inaccurate, inefficient or inconsistent code.
This can create a circular effect. If an AI-SDE introduces poorly understood or poorly designed code, the next AI-SDE working on the codebase will have an even harder time understanding it. Each modification can add further complexity, making the system progressively more difficult to navigate and modify. The problem can compound over time.
For this reason, a sound foundation of software design becomes even more important when AI is involved in development. Good design does not merely help an AI write better code; it helps ensure that every subsequent AI-generated change makes the software easier, rather than harder, to understand and evolve.
Designing for AI-SDE
While the fundamental principles of software design do not change drastically when the developer is an AI, there are important differences in how the design should be expressed and maintained. A design that works well for human developers may not provide the same level of support to an AI-SDE.
Make the design explicit and keep it updated
An AI-SDE can benefit from design only when the design is explicitly available to it. Tacit guidelines that everyone in a team knows are of little use to AI. For example, a team may know that a particular library should always be used for database access, or that a particular component should never be modified directly. If these rules exist only as shared knowledge among team members, an AI-SDE may not know about them.
Making the design explicit is relatively easy during the pre-coding phase, when architecture, components, interfaces and guidelines are being documented. It becomes harder during coding and post-coding support, when design decisions are frequently made incrementally. This makes it particularly important to keep the design updated as the software evolves.
Take help from AI in creating and updating the design
The same AI that creates and modifies code can also help create and maintain the design. AI can convert recorded discussions, handwritten notes and rough writing into structured design documents. It can analyse existing code and identify design patterns, conventions and guidelines that may not have been explicitly documented.
This creates an opportunity to make design maintenance much less burdensome. Instead of expecting developers to document every design decision manually, teams can use AI to continuously extract and update the design from discussions, code and other development artifacts. The objective should be to ensure that the documented design remains a useful and current representation of the actual system.
Design can now carry instructions for the AI-SDE
Think of the AI-SDE as a layer above the compiler. Just as code contains instructions for the compiler, the design can contain instructions for the AI-SDE. This changes the economics of some traditional design decisions.
Many software design techniques were developed partly to reduce the amount of code that developers had to write or maintain. With AI, the cost of generating code can be very low. This means that some techniques whose primary purpose was to save developer effort may become less valuable.
Consider object-oriented programming and class hierarchies. A developer may create a class hierarchy partly to avoid repeatedly writing similar code. With an AI-SDE, it may sometimes be simpler to describe the required behaviour and have the AI generate the implementation, even if that results in some duplication. For example, rather than designing a complex hierarchy to maximise code reuse, the design could instruct the AI to generate a specialised class based on the required behaviour.
The important question for the designer therefore changes from “How can I minimise the amount of code that has to be written?” to “What design will produce the best software when an AI can generate the implementation?”.
Do you have an AI-Ready design?
If you are responsible for the quality of your codebase, the efficiency of software delivery, or more generally for serving the stakeholders of a software system, it is time to take a fresh look at your design. As AI-SDEs become part of software development, it is worth asking a simple question: Is your software design AI-ready?
A good place to start is to check whether the design exists, is up to date and is complete enough to guide development. Can an AI-SDE discover the architecture, understand the interfaces and dependencies, identify the constraints and conventions, and trace requirements to the code and tests? If important design decisions exist only as tacit knowledge within the team, the software is not yet AI-ready.
If your engineering team is using AI-SDEs to generate or modify code without an approved and current design, it may be time to step in and establish one. Design should not become a bottleneck for AI-assisted development; the use of AI for creating, documenting and updating the design itself can make this process much more manageable.
For technology leaders, an AI-readiness assessment of the software design can therefore be a useful starting point for adopting AI coding at scale.
Summary
As the use of AI coding tools grows, AI-SDEs will increasingly become both consumers and modifiers of software. This changes the demands placed on software design. The design must be explicit, current and sufficiently detailed for an AI-SDE to understand the architecture, discover and reuse existing components, make changes safely, and verify their impact.
The fundamental principles of software design have not disappeared in the age of AI. But when code can be generated cheaply and rapidly, good design becomes even more important. It provides the structure, intent and constraints that prevent the increased speed of coding from turning into increased complexity.
For an AI-enabled software team, the quality of software design will increasingly determine how effectively AI can contribute to coding. For technology leaders, building this design foundation should therefore be a key priority as AI becomes an integral part of software development.