Normware: The Decline of Software Engineering
There’s a common refrain that “AI won’t replace software engineers”, often with the resolution, “you’ll be replaced by software engineers that use AI”, implying that AI will be used to make software engineers more productive and efficient. I argue that software engineers will be replaced by normies, non-engineers (accountants, lawyers, etc.) that are empowered to create their own software to solve their own problems.
I don’t think that we’re close to automating software engineering. But what if we simply didn’t need software engineers?
I envision a world where AI tools & no code tools enable normies to create, normware, software created by anyone to solve their own problems. To some extent, it’s been happening for decades. But now it’s possible to easily make good normware.
First, let’s start at the beginning.
Are You Valuable If You Don’t Write Code?
There are a lot of job disciplines that write code but aren’t software engineers. The first non-engineer coder I worked with was a computational linguist. He was a linguist, definitely not a software engineer, but he did write a lot of Python. I also worked with a game artist, who was clearly an artist, but whose medium was code (and visual design). I’ve since worked with dozens of professions that are comfortable writing code but aren’t software engineers.
At Amazon, I was introduced to the idea that principal software engineers don’t write any code. Principal engineers would publically lament that they write so little code that they likely aren’t even capable of writing production code.
That made me think a lot. I had always defined myself by my ability to write code. But I was a senior software engineer, and it appeared that all paths upward involved not writing code. It shook me.
Today, I’m seeing a similar phenomenon with AI coding. Software engineers of all levels are wrestling with what their value is. If it’s not writing code, what do we do?
Why Hire A Software Engineer?
Without talking directly about all the things a software engineer does, why are we hired in the first place?
- Big Projects — I’ve seen business folk prototype a solution, but eventually get to the point where further development is too difficult to do themselves. Sofware engineers bring in things like design patterns and unit tests that allow projects to grow even larger.
- Distribution — Similarly, after prototyping a solution, how can people use it? e.g. web app, Excel spreadsheet on a SharePoint server, mobile app.
- Scale — How many users? Any top level internet site, like Google or Facebook, has gotten huge and it’s very complicated to operate at this scale. They hire legions of software engineers and publically declare that their success hinges on the quality of engineers they hire.
- Maintenance — Software engineers have lore about how software is alive. An untouched application will eventually inexplicably break. In fact, some engineers will brag that a piece of software they wrote has run untouched in production for 20 years. That brag only carries weight because it’s unusual, most software inexplicably breaks without maintenance.
- Safety — In some cases, often real-time embedded devices, human health & safety is at risk and software engineers are hired to take responsibility for the quality and integrity.
None of those things are inherently about writing code. So why do I think software engineering is disappearing?
An Experiment: Storymode
Over the holidays I hacked together a web app that I dubbed storymode. I wanted Claude to write stories & convert them into audiobooks to occupy my kids for multiple 10 hour road trips.
The catch: I didn’t write it. I made a rule for myself, I used Cursor’s Composer with the new Agent Mode. Not only did I not write code, I didn’t even read it. I blindly accepted every change without review.
And it worked! With only a couple exceptions, I was able to write an entire web app that solved my problem, and did so soley in English prose. A couple of times I ran into doom loops and had to manually intervene. But that’s happening less and less as models & dev tools get smarter.
Normware: Solve Your Own Problem
We’re clearly at a juncture with software and software engineering. The debate is where we’re going. It’s hard to imagine that software will remain unchanged in five years. I think the production of software will move toward it’s users.
Why? Simple economics.
I call this normware, the software that normies write to solve their own problems. Think about how good dev tools are in relation to, say, the software used submit expense reports. Dev tools are good because they’re made by the same people who experience the problem. On the other extreme, in enterprise software the buyers & users are different people; it’s notorious for being difficult to use.
Minimize the distance between developer & user. The bigger the distance, the harder it will be to get right.
Normware is that, but taken to the limit. It’s the minimum possible distance between developer and user. For everything.
Hybrid Roles Reduce Communication Overhead
If you’ve watched software engineering develop over the decades, you’ll notice that this pattern has already been playing out on repeat. Group A and group b have diverging skill sets and a lot of time & energy is wasted by having them miscommunicate, so instead we’ll create group AB that has both skill sets.
Reducing distance increases effectiveness:
- Dev Ops = development + operations
- Full stack = frontend + backend dev
- ML engineers = data scientist + engineer
- DataOps = data engineer + operations
- DevSecOps = development + security + operations
- Tech evangelist = developer + marketer
- Legal technologist = lawyer + software developer
- Game artist = game developer + artist
- Computational linguist = linguist + developer
- Bioinformatics engineer = biologist + data scientist
The list gets longer as the years go by, because it is desireable to reduce communication overhead. Yes, communication is good, but even better is not needing to communicate. And someone who can think clearly in two domains is infinitely more useful than two people that can’t communicate.
The obvious downside is that these hybrid roles tend to be not quite as proficient at either of the pre-combined roles, but the business prefers them anyway because they deliver the right thing at a much higher rate.
The Curse of Scale (The Problem Solved By Normware)
My hottest take of all is that product managers are neither group A nor group B. Maybe they started as a software engineer, but when they become a PM they’re disallowed from writing software. Or maybe they were a subject matter expert, but when they become a PM, they’re disallowed from continuing to practice their expertise, so skill atrophies.
Worst of all, product managers are pushed by upper management to make big ideas that push the product into the market leader position. But in pursuit of big ideas, they lose touch with the original mission.
This is an artifact of scale.
When software becomes a product, it needs users. Prior to being a product, it simply had users. As it continues to live as a product, it needs growth in users. To achieve growth, it needs to cater to new groups of users, and in the process it caters fewer of the original users, because it’s difficult to serve a diverse user base.
Cory Doctorow’s enshittification is a special case of this effect that addresses what happens to a two-sided marketplace as it scales.
Scale always creates problems. In distributed systems, cellular architecture was created to artificially reduce the scale of traffic. Engineers at AWS created the architecture after realizing that new problems always continue to emerge as scale increases.
Similar to cellular architecture, normware constrains scale, which makes it fundamentally simpler for new solutions to emerge and thrive.
Normware Doesn’t Need Software Engineers
Normware is inherently a lot smaller and simpler, and thus can largely avoid the overhead caused by scale.
- Small Projects — They solve only one problem at a time, and rewrite when it gets complex.
- Distribution — Little to no distribution infrastructure, e.g. maybe they run a webapp on their laptop or use a no-code platform.
- Small scale — They make it for their friends or immediate team.
- Maintenance — Still needs to be maintained, but it’s small so AI tooling is a viable option.
Normware doesn’t need software engineers. AI dev tools may be good enough for normies to solve their own problems and maintain their own solutions. After storymode, I’m convinced of this.
Normware Dev Tooling
What kinds of software do normies use to create normware?
- MS Excel — The classic normware. Accountants and business people have created spreadsheets to solve their own problems for years. The UI isn’t great, so I think this will steadily be replaced by other options
- Cursor & Windsurf — Code editors with heavy AI enablement. It’s more formidable to get started, but there’s virtually no upper bound to what you can make.
- UIPath & RPA software — These tools let you directly automate a mouse-driven point-and-click workflow on your computer. From what I hear, UIPath is investing heavily in AI & computer vision. Claude’s computer use tools will give UIPath stiff competition, and lots of other options will soon emerge.
- Custom GPTs & MS Copilot — A great way to integrate data sources into your workflow. These are essential no-code AI tools for making your data very useful to others.
It’s not necessarily about replicating what software engineers do, it’s just about solving your own problems.
Normware Will Become Dominant
My hot take here is NOT that businesses want their reserachers, accountants, lawyers, etc. solving their own problems. Businesses always have wanted that. I can name more than 5 teams I’ve worked on that were started by a prototype made by a normie & a spreadsheet. Thus far normware only rationalized the need for increased software engineering investment.
The hot take is that normware can be developed & maintained by normies.
While working on storymode it struck me that anyone can do this. The main reason why they don’t, is because they don’t know they can. It’s just an education problem.
Software Engineers Will Still Have Jobs
I do think software engineers will be able to weather this fine.
- Societal change is slow, you have years to redefine yourself
- Normware isn’t always appropriate, e.g. when health & safety is at risk
- Existing software will always need to be maintained (e.g. there’s still 800B lines of COBOL in use today).
- Normware depends on non-normware software platforms like Cursor or MS Excel
But regardless, you need to expand yourself.
Traditionally, software engineers formed a tight knit pod and isolated from the rest of the business. We had enough jargon and inside jokes that we could sustain our own parallel culture. That’s unlikely to continue.
Make friends with the sales guys and generally branch out.