What Principles Might Change In AI-assisted Software Development?
Some firmly held notions in software development may break as the automation promises of AI take hold. Let's explore some of these and take some educated guesses as to how these might change.
Hi everyone,
Thank you for reading Great CTOs Focus on Outcomes. I publish weekly and have an archive of over 150 posts, each packed with valuable insights on various topics relevant to CTOs and the issues they face, distilled from my career experience.
I strive to make each post a helpful resource on the topic it focuses on so that when a CTO has a need, they can reference an atomic nugget of insight. To this end, I regularly revisit and refine my posts, ensuring you always receive the best and most up-to-date information with maximum clarity.
If you’d like to support the growth of this resource, consider upgrading to a paid plan and take advantage of the additional ways I can help you.Recently, CEOs and CTOs have asked me what assumptions might change with the advent of AI-assisted software development. Some companies are pausing hiring and increasing their experimentation with AI-assisted coding to see if they can be more productive with fewer people but more AI.
As I explored in my recent post, leaders are looking for improved efficiency and effectiveness from AI - some are naively looking to vibe-code their way to the bank, and others are being more deliberate about their approach :
Putting those with poor and misguided intentions aside, I believe this is still a legitimate question: whether it was inspired by hype and unrealistic expectations, leaders should be considering what changes as AI takes hold.
I am observing people using AI for significant productivity gains. Whether those gains are 30% or 100x gains, as some claim, remains to be seen. From what I have observed, the gains are more than the average technologist may realise and in ways many won’t anticipate. If that’s the case, what might change with rapid productivity gains?
Don’t get me wrong, the limitations of AI that many are highlighting, such as hallucinations and limits of reasoning and creativity, are real, but what is underreported is the effectiveness of what people do to overcome those limitations. I will look to cover more examples in future posts. In the meantime, let’s gaze into the near future and consider:
“What software development principles are subject to change in the AI-assisted software development era?”
This thought exercise challenges our assumptions. Things that may have become pillars of our belief system may crumble when there is a significant change, such as the change that AI-assisted software development represents.
The Principles Likely to Change With AI-assisted Software Development
I empathise with people who feel it is hard to know what impact AI will have on software development. Indeed, I have no idea where it will end up. Still, from my unique vantage point, I have seen enough to be confident that there’s enough progress and momentum that many of the principles and touchstones associated with software development may be subject to change.
Recently, with the express goal of identifying which principles may be in question as AI-assisted coding evolves, I’ve spoken with colleagues, friends, CTOs I consult with or coach, software engineers and a range of other people with different perspectives that, along with my experimentation, and here is my list of which are likely and why :
The size of teams
“2-pizza teams”
Overall size of a software development organisation
The relative importance of maintainability and code readability
Don’t Repeat Yourself (DRY)
Literate/readable/clean code
Specialisation vs Generalisation
The split of responsibilities between roles
The rise of new roles
stable teams vs dynamic teams
Conclusion
Why these principles may break down in an AI-assisted environment
The size of teams
The size of teams may be disrupted by changes in the productivity around a range of tasks. Whether it’s the increased effectiveness of an individual or, depending on what you believe is possible with AI, with developers managing teams of synthetic developers, what may need to be invested to achieve specific outcomes will change. Of course, that will change the market, and it’s hard to judge what the effects of that will be.
“2-pizza teams”
The 2-pizza team was an extension of a rule attributed to Jeff Bezos for effective meetings (seen as a counteraction to the Ringelmann Effect ), and it has been cited informally as a guideline for software teams ever since. Whether intentional or not, many team structures over the past couple of decades, whether feature teams, tiger teams, stream teams, or other configurations, have all approximated this size of 5-8 people (and no greater than 15).
AI tools assist in all aspects of the software development lifecycle. Thus, they promise to shift back towards more generalisation and away from specialisation due to the potential for most topics. AI can either help the developer learn enough to undertake the task themselves or do it with AI assistance.
It may be more effective for much smaller teams of 2-3 engineers to collaborate with the support of code-assist tools, agents, synthetic co-workers, or other AI-assist methods.
Overall size of a software development organisation
A prevailing question I have been getting recently is whether overall software development organisations can be smaller regarding headcount. I believe that in most cases, the answer is yes, even without the progression of AI, as too often leaders add roles as a default response to problems and because they are poor at managing other factors such as delivery, change management or quality. With the progression of AI, even more will be possible, but whether it’s the traditional organisations or AI-native organisations that prove this remains to be seen.
Factors include the increased costs of AI tooling, possible increased productivity, and the generalisation of present-day roles. I cover this in more detail in a separate post, which will be published soon.
The relative importance of maintainability and code readability
Don’t Repeat Yourself (DRY)
Principles such as "Don’t Repeat Yourself" exist to help with code literacy and maintainability. Suppose we can change code more swiftly and spend less time reading lines of code because other indicators might become more valuable representations of the state and capabilities of code. In that case, we may put less stock in such principles.
Literate, readable and clean code
Over time, code representations may become more critical for machines than humans. As this shifts, practices concerned with human code readability may be superseded by machine reading efficiency and literacy.
Specialisation vs Generalisation
There is always an oscillation between specialisation and generalisation as software and software practices evolve. Specialisation of roles occurs as the depth of what can be known and must be known to be effective in an area grows. It can spring back as tools and practices evolve, allowing some complexity to be managed more easily. AI is already demonstrating an ability to facilitate this shift in ways it can support rapid learning of technical concepts and take some of the toil away from developers. In effect, it can also lower the barrier to participation in development.
The split of responsibilities between roles
Our definition of the expectations for each of the typical roles in a software development team is likely to change. Existing trends of shifting left may be accelerated and devolved such that any team member may do them.
The rise of new roles
Conversely, other types of specialisation may form, such as a range of AI-specific competencies, including specialists in prompt engineering, monitoring for model drift, AI ethics, and other concerns that start to require dedicated expertise and management. These changes are driven by need and demand and may not all come at once; hence, the oscillation effect between specialisation and generalisation continues.
Like stars, these changes will appear like oscillations when viewed from a certain angle. Still, should we map out the components and their evolution using a tool such as a Wardley map, we are likely to see more sophisticated movement as the relative effects different components have on each other play out.
stable teams vs dynamic teams
The acknowledgement that much of the world’s software must be actively supported to achieve the quality of experience most expect from modern software has led to a slow shift towards stable teams organised around a service or discrete value that the organisation has committed to providing.
The advent of AI-assisted software development may challenge our assumptions around this, as developers can re-establish the context of working on a service and may be better able to move between services and value pools to make improvements.
The issues associated with teams that form around transient needs may be lessened due to improved observability and ability to view the architecture through various lenses AI tools may afford us, whilst advantages such as flexibility and responsiveness are retained.
Conclusion
Some of us have used some or all of these principles to inform our approach to software development over the past few decades. However, as the world changes, we may hold on to these assumptions too tightly.
It helps to identify these and examine what was true that led to that principle's usefulness and what might need to shift to render it less valid. This can help us continue to have strong opinions, loosely held, knowing that as things change, we remain adaptable.
What principles may not hold as AI-assisted development rises in popularity? Share what you think and shifts you have already noticed in the comments.
If you enjoyed this publication, please help others find us and benefit from the insights.