Everyone Is a Builder Now
The deluge of shadow IT
Last year (!) Brian Armstrong told the world that ~40% of daily code at Coinbase is AI-generated — and that he wanted it past 50%. I bet many people read it as a layoff memo with a future tense. Truth be told, the story seemed to write itself: AI gets good at code, engineers get cheap, then optional, then gone.
And you wouldn’t be wrong — the layoffs happened, just a few months later.
There’s another angle to it. Look at what Armstrong actually does on weekends. He builds little web apps. By his own account, “it’s not really coding — I just observe, communicate, execute, and copy-paste, and it usually works.”
It’s interesting because he is by no means alone. Garry Tan runs Y Combinator and still ships ten to twenty thousand lines of code a day on the side — cheered by some as proof of what’s possible, dismissed by others as throwaway slop. At least it’s entertaining.
I have personally had many conversations mirroring this sentiment.
The point is — people further from the codebase keep climbing back into it. Not to replace the engineers, but rather because — among other things — it turned out to be fun. Hell, it is!
That’s the part where I start to question the ongoing replace-or-augment debate.
Essentially, we were sold two futures. In one, AI makes engineers faster (which it does), and demand for them explodes. In the other, it makes them unnecessary. In other words, one assumes that the demand will expand (due to cost going down) and the other assumes that it is fixed (or at least growing way slower than supply).
What if the pile was bottomless, though? Or what if it’s at least way deeper than we think? So deep in fact, that due to the entry barrier falling through the floor, the cohort of engineers, even if it grows, will be dwarfed by an even larger cohort of non-engineers building software?
Brian Armstrong even said as much in his layoff Twitter/X post:
“Second, AI is changing how we work. Over the past year, I’ve watched engineers use AI to ship in days what used to take a team weeks. Non-technical teams are now shipping production code and many of our workflows are being automated. The pace of what’s possible with a small, focused team has changed dramatically, and it’s accelerating every day.”
I just happen to work with an institutional investment office — analysts and portfolio people. Most not being software engineers by training. In the old days they were supposed to be the consumers of software the tech team builds for them.
Instead they became the catalyst. They build their own workbenches now. They manipulate data, stand up small applications that crunch a dataset and render a dashboard, ship things that are genuinely useful. People who hadn’t written a line in fifteen years, or ever, are suddenly in the code. And you can see it on their faces — they are enjoying it!
If you think about that, we’ve run this experiment before, every time the entry barriers to programming dropped. Assembly to Fortran and C let scientists write their own simulations instead of begging the systems team (not mentioning what the introduction of Python did!).
The spreadsheet turned millions of accountants and analysts into programmers who would never accept the title.
No-code/low-code did it again (albeit never at the scale we were promised).
Each wave, the prediction was the same — this abstraction will reduce the need for programmers — and each time the population of people who build software went up, not down, because the barrier to entry fell and a new cohort walked in.
LLMs are just the steepest drop yet. The barrier used to be syntax, setup, and the years it takes to stop being dangerous. The barrier is now a clearly stated intent. So of course the CEO is back. So is the analyst, the PM, the designer, the ops lead who spent a decade routing around IT with increasingly cursed spreadsheets.
Yeah, yeah, yeah. Jevons Paradox. We heard it before.
But hear me out: the cheaper code gets, the more of it the organization wants, and the more of your non-engineers quietly become part-time builders.
That’s not a threat to your engineering function! It’s a vastly larger surface area of software, created by people who don’t report to it, don’t follow its conventions, and don’t know what they don’t know. Give it a second thought, because this has significant implications for tech organizations (or rather — any kind of organization).
Which is exactly what happened the last time. The spreadsheet didn’t just make accountants into programmers — it made them into programmers nobody supervised, and the unsupervised work turned out to run real things. A copy-paste slip in a risk spreadsheet helped JPMorgan misjudge the exposure behind a multi-billion-dollar loss. An Excel error in a single Reinhart-Rogoff paper propped up austerity policy across actual governments. Audits have long found that the overwhelming majority of consequential spreadsheets contain errors. So within a decade an entire industry existed to govern the result: version it, audit it, lock down what data it could touch, and stop a fat-fingered cell from quietly restating earnings.
And a vibe-coded app is the spreadsheet’s far more dangerous descendant. A spreadsheet sits in a file; an app reaches into the production database, calls live APIs, moves money, holds the PII. And yes, I have seen the blasphemous contraptions people already build in Excel. Still, a spreadsheet error pretty much stays in its cells; an app error is a breach, a leak, or a 3 a.m. page.
In essence though — the builders came first. The rails came after — retroactively — because the rails turned out to be where the real problem, and the real market, lived.
So here’s the thought.
Everyone is busy building the tools that help amateurs produce the first working version. Others are building AI SDLC pipelines for engineers.
Almost no one is building the part that makes the thousandth version last — the pipelines, the guardrails, the paved road that lets a portfolio analyst’s Saturday app run on Monday without an engineer babysitting it.
And any technology leader with visibility into budgeting knows — the majority of costs of software development are spent on maintenance.
The market for helping non-engineers build things (not prototypes!) that last is under-explored. The on-ramp is crowded (prototype). The highway is crowded (SDLC pipelines). Nobody is paving the regular road.
If the prototype is now free, the durable thing around it is the scarce one. That’s not the small market. It might even be the bigger one, as more and more people become builders.
We’ll see what happens. One thing is certain — the bugs caused by incorrectly filled Excel spreadsheets will be overshadowed by the problems that will come from the new wave of apps being built.
Fasten your seatbelts, because it’s going to be a hell of a ride.