Over the past few years, we have been so focused on worrying about the future of our own profession that most of us have failed to notice the most important thing that’s about to happen:
Everybody will be able to write software.
This isn’t a theoretical idea. There are already people in HR, Finance, and Sales at companies across the world using AI assistants to write complete computer programs. This isn’t entirely new—everybody is familiar with “that giant spreadsheet that somebody in Finance wrote for their own use.” The difference is that AI assistants unlock the full power of computer programming for everybody. However, they also unlock the full dangers and consequences of computer programming—a series of lessons that we as a profession have learned the hard way over a period of 60+ years.
We can worry about this, complain about it, try to ignore it, etc. But what we really should ask ourselves is: what are we going to do about it?
Well, there are a series of things that we need to do, but today I’m going to focus on just one:
We need to help the new builders.
Helping Others Understand
Too often, we have been dismissive of people with less technical background who seek to build software. We tell them it’s too hard to understand why we do what we do. We tell them they could never understand and they just have to trust us.
We do this in part out of arrogance (we really do have a craft that we have spent years learning, practicing, and polishing) but also because it’s actually really hard to explain to people all the lessons of software engineering without making them actually do it for years.
All of this needs to change in this new world. People with all sorts of backgrounds, technical or not, are going to be writing real software programs. We need to make it our mission to help them, not to tell them they’re “holding it wrong.”
We need to get good not just at building software, but at explaining to others why software is built in a certain way. Otherwise, millions of people are going to be building things that will come back to bite them in ways they can’t imagine or predict currently. And the greatest problem is: the consequences of bad decisions in software don’t show up for months or years, sometimes. So they will not just learn these lessons on their own. By the time they learn them, it will be too late. It will have caused so many problems that it will become your problem anyway: you will have to deal with security issues, massive infrastructure costs, unmaintainable systems, and numerous other consequences that are now causing serious issues for your business.
The solution is not to forbid people from using these tools. The tools give them too much power, too much convenience, and too much legitimate value. They will find some way to use them, or revolt against your restrictions until you give up. We have to lean into how we will help them, how we will teach them.
The very minimum bar is that we have to help them understand when they need to reach out to an engineer. How far should they go without help (which could be pretty far)? At what point do they need professional assistance, advice, or a little bit of education?
Won’t The Agents Just Do It?
I’m sure that some people will argue that this isn’t necessary, that the AI agents will handle the whole process, and so forth. Or that the agents will get so good at writing code that they will avoid all the consequences, and so everybody can write software of any level of complexity perfectly safely.
I’m almost entirely confident that won’t happen, because there are some problems that are only solved by understanding they exist and having the intention to solve or prevent them. Even if the agent wrote perfect code that did exactly what you said to do, you’d have to know to tell it to do certain things.
Just as an example, recently I talked to a non-technical person who had been building software using a modern AI agent. This person had no background in software engineering at all. They described how they had “discovered” that they got better results if they experimented with multiple solutions before choosing one. I’m sure at some point they will also “discover” that they get better results if they define a set of requirements, if they research more up front, if they write out clearer specifications, if they make more incremental changes to the system, if they release more frequently, and so on and so on. While agents will get better at doing some of this on their own, there will always be some areas where the agent simply can’t execute an intention you didn’t express, or where you even told it explicitly to do the wrong thing.
The problem with software development is that it can go wrong in an infinite number of ways. Recently I heard a story of a team that racked up a huge infrastructure bill in a single month, caused by bugs in software that had been written by non-developers. Sure, you could design a system to prevent that specific failure mode, but there are infinite more failure modes hiding in the bushes, just waiting to jump out and attack unsuspecting citizen developers.
There are solutions to a lot of this. There’s infrastructure you could build to make it much safer for such “citizen developers” to write software. But not everybody will have that infrastructure, and even when they do, it will never cover every possible edge case. Plus, some people will intentionally or unintentionally “work around” the infrastructure to do the wrong things anyway.
I could provide all the healthy food in the world to people, make it easily accessible, and some people would still eat terribly, because they don’t understand nutrition. This isn’t a technical problem, and so it doesn’t have a technical solution.
This is a Repeating Pattern
In the history of software engineering, every ten years somebody comes along and invents some new paradigm of development and re-discovers all the lessons we have learned about software development over the last many decades.
Once upon a time we had structured programming (blocks and loops). Then we developed object-oriented programming, and everybody re-learned all the lessons we already learned from structured programming. We were putting software on mainframes, and then we were shipping boxed software personal computers and had to re-learn all the lessons about development processes that had already been learned in the mainframe era. When web development started to rise in the world, the whole world of web development rediscovered all the tools, structures, and processes of software development that software engineers had already known for decades.
This pattern has repeated over and over. When mobile development rose, it went through the same cycle. Machine learning engineers went through it and are still going through it.
This pattern repeats because there are aspects of building software systems that are inherent in solving the problem, no matter what shape the problem takes. It’s also worth understanding that this pattern isn’t new, and that every time it’s happened, we have been dismissive of the new developers much to their detriment and ours.
This time, though, it’s not just a small group discovering a new paradigm of software development. Potentially, it’s everybody in the world discovering software development itself.
So here is my plea to you. When you find somebody using an AI agent to build software with no understanding of it, don’t dismiss them. Don’t throw your hands up and walk away. Don’t lecture them about how they are doing everything wrong and how they have to work and study for years to do it the right way. Listen to their troubles, gently give them specific suggestions to help with their immediate situation, give them a “tip” or two that will help them do better in the future, and let them know you’re there when they have more questions.
Over time, I suspect that this will actually become more and more of our role as software developers—not just to build things, but to help mentor and guide a world that is newly coming to discover both the joys and the pains of building real programs.
-Max