Thoughts
AI and the silver bullet: what is still missing?
Developing software is difficult. We may have the best developers in the world, the best development processes, the best coding tools, rigorous quality assurance, and sophisticated CI/CD pipelines—and it will still be difficult.
This is so because of software’s nature, its essence. We need to understand what the software should do, how its many parts should work together with the business processes, and how it will fit into the world and culture around it. We also need to determine how it will be deployed, adopted, and used to produce the intended results.
AI is making parts of this work remarkably easier. After building applications with it myself, I find the possibilities exciting. Yet the experience keeps bringing me back to a question I explored in 2011: have we finally found software development’s silver bullet?
We have been removing obstacles for a long time
Fred Brooks examined this question in “No Silver Bullet—Essence and Accidents of Software Engineering,” published in Computer in 1987 after its initial appearance in 1986.¹ The metaphor was memorable: a seemingly straightforward software project could turn into a werewolf of missed schedules, mounting costs, and disappointing results. The industry kept searching for a silver bullet—a breakthrough capable of producing extraordinary improvements in productivity, reliability, and simplicity.
Brooks distinguished between accidental difficulties, associated with how we produce software, and essential difficulties, inherent in what we are trying to build. Better tools could remove considerable accidental work without eliminating the complexity of the underlying essential problem.¹
In my 2011 article, I considered whether Platform as a Service—PaaS—might be that breakthrough. PaaS and other cloud platforms simplified infrastructure management and deployment. Visual development tools offered another promising possibility: bringing the person who understood the business need closer to building the application. These advances removed important obstacles. Yet, they also left us with fundamental questions about what the application should accomplish and how it should work.
Today, AI has made that connection between understanding a need and building a solution much more tangible for me, and much more critical to solve for!
What happens to essential complexity?
Brooks identified four characteristics behind software’s essential difficulties: complexity, conformity, changeability, and invisibility. They offer a useful way to examine what AI helps us address—and what remains.
Complexity comes from a system’s many interacting parts and possible behaviors. In my recent work, AI has helped me navigate code I could not have written as fast on my own, examine dependencies, and reason through architecture. That assistance makes complex systems more approachable. Their interactions still require careful design and verification, but models are getting much better at connecting all the dots.
Conformity concerns the need to fit a world outside the application: other systems, business rules, organizational practices, and constraints. AI can help implement an interface. Understanding what that interface must mean to the business requires context that a technical description alone may not capture. There is only so much we understand about other systems and processes that we can give as input to our model.
Changeability reflects how software must evolve as needs and circumstances change. Faster implementation helps us respond. We still need to understand which changes matter, what they affect, and whether they improve the outcome.
Invisibility concerns the difficulty of seeing software’s full structure. Explanations, diagrams, and prototypes help us examine it, but no single view captures everything. AI gives us additional ways to explore a system while leaving us responsible for questioning and validating those representations.
These difficulties overlap. Understanding requirements, for example, involves both how the application fits its environment and how that environment changes.
My experience suggests that AI gives us powerful new ways to work through these challenges. It does not make them disappear.
The application was easier than the questions around it
I have recently built applications ranging from small learning experiences for my son to a system for my father’s consultancy in culture and organizational change.
The latter collects feedback from executives belonging to the same management team. It includes multiple users, databases, and deployment on AWS. The speed at which I could build and connect these components was remarkable. My father could not believe how fast I built it, nor could I!
Yet the most demanding conversations concerned how the application would be used in practice.
When would my father introduce it during a consulting engagement? How would participants understand the exercise? When would responses be collected? How would results be shared with the people receiving feedback? What conversation should follow?
Each answer shapes the software.
A working mechanism for collecting responses is useful only if it supports the consulting process. Understanding that process determines what information is needed, how the experience should unfold, and what the results should enable. All this is the essential complexity.
Even so, AI helped me ease the burden. I was able to build an early version, get feedback, iterate, test more alternatives, validate… so even though I could not replace my father’s knowledge of his work, I was able to bring his input to the software being built very effectively.
Knowing what to build is harder than building
I recently had an insightful conversation with a former CTO whom I greatly admire. He gave me a keen perspective on the discussions about AI taking over developers’ jobs that stayed with me: a developer knowing how to prompt an AI tool would not be enough. He would instead prompt AI himself and hire the people who deeply understood the business problem that needed solving. That’s the critical element that will set a new solution apart from the rest.
I concur tremendously.
Which pain point deserves attention? What should the business process accomplish? What would a better outcome look like? How will we know whether the application helps?
The ability to turn those answers into software is becoming more accessible. The ability to uncover, question, and refine those answers remains enormously valuable.
Technical judgment is still essential. Faster development increases the opportunity for people who can combine that judgment with business understanding—and work effectively with the people who know the process firsthand.
Furthermore, building is just the start
There is another layer to the challenge: once deployed, a tool still requires being adopted and used in order to drive value. Technical deployment merely makes the application available. Organizational adoption is what changes business processes, molds culture, and yields benefits.
People need to understand the new tool’s purpose, trust the experience, and incorporate it into their responsibilities. For my father’s application, collecting feedback is one step. Him using that feedback to support productive conversations and meaningful change is the larger objective.
Anyone who has led a business transformation will recognize this distinction. Delivering the tool creates an opportunity. Realizing its value takes further work.
Are we closer to the silver bullet?
Building with AI has made me more enthusiastic about what we can accomplish. Ideas that once required substantially more effort or help are now within reach, and we can test them much sooner. It has also reinforced something I have encountered throughout my career: understanding the business problem and guiding the organizational change are central to making technology useful.
Perhaps we are getting closer to the silver bullet. But the essential questions remain: what should we build, how should it work, and what must change for it to make a difference? I will continue searching for it.
References
- ¹ Brooks, F. P., Jr. (1987). “No Silver Bullet—Essence and Accidents of Software Engineering.” Computer, April 1987. Read the essay.