The Rise and Fall of the Kings
In the beginning, we were webmasters. One role to rule them all. We'd manage a MySQL database in the morning, use blank.png spacer images to pixel-perfect a layout by afternoon, and deploy by dropping changed files over FTP before dinner. There was no scalability because there was no scale. Mobile was a decade away. SVN was version control. And deployment was, well, shameful by modern standards.
The web back then was a promise yet to be fulfilled. Amazon and Google were in their infancy. The internet wasn't colonized by business moguls and monopolists yet. It wasn't a good business. It was an anarchy of the nerds.
That era lasted too little, if you ask me.
As the web became the mightiest distribution channel in human history, everything changed. Scale drove technical complexity. Business drove organizational complexity. The nerds lost the reins to the suits, and a Cambrian explosion of roles followed: SREs, UX designers, mobile engineers, data scientists, ML engineers, platform engineers — each with their own lingo, their own career ladders, their own conferences.
The infamous Spotify org model video circa 2012 shaped a generation of tech organizations. Squads, chapters, tribes, guilds. And with them came the philosophies to make all these people work together without stepping on each other: DevOps, microservices, Team Topologies. A golden rule emerged: keep the cognitive load of a team limited to what its members can hold in their heads.
This is how we arrived at the modern software organization. Managers, principals, product managers, designers, multidisciplinary teams — and an exhausting, never-ending fight against human nature to keep everyone accountable and connected to business results. We've been living in the age of the reorg, because nobody seems to have cracked how to make all this machinery actually work.
The hyper-specialization created a tsunami of demand for specialized workforce. The peak, for me, was around 2018, when a colleague — a born salesperson who couldn't have cared less about computers — came to ask me for advice on becoming a programmer. The salaries had gotten that good.
From reorg to reorg, trend to trend, this was how we lived for the last decade. Things were great if you were a software engineer pulling $500K+.
The king grew comfortable. Then AI came. And now the king is naked.
The Rotten Pillars
Here's the thing most people in the industry haven't fully internalized yet: the entire way we build software — the org charts, the processes, the role definitions, the team structures — all of it was built on a set of assumptions that AI is systematically dismantling.
Start with the business pillars. Building tech products was expensive. It was time-consuming. It required super-specialized experts who spoke a language nobody else understood. It was risky — how many software projects never saw the light of day? How many failed spectacularly, from Pets.com onward? Every feature was a bet with a huge opportunity cost. You couldn't build ten versions and test which one worked, because building even one version took months and cost hundreds of thousands of dollars.
When the cost of building drops by an order of magnitude, every assumption downstream shifts.
AI is making software dramatically cheaper to produce, faster to iterate on, and less dependent on rare specialists. The elaborate processes we built to de-risk expensive development? They become overhead. The specialized roles we created to handle complexity? They become bottlenecks. The organizational structures we designed to coordinate dozens of specialists? They become bureaucracy.
The engineering pillars were equally fragile. Team Topologies taught us that the fundamental unit of software delivery is a team, and the fundamental constraint is cognitive load. You kept teams small — five to nine people — gave them clear boundaries, and structured your architecture to match. You needed stream-aligned teams, platform teams, enabling teams, complicated-subsystem teams. All because human brains can only hold so much context at once.
But AI doesn't have that constraint. Not in the same way. An AI agent can hold the full context of a codebase, understand the infrastructure, parse the business requirements, and generate code across multiple languages and platforms — simultaneously. The cognitive-load argument, the foundational argument for how we organize engineering teams, is dissolving.
A few weeks ago, I built twelve pieces of software in six weeks of evenings and weekends. Not prototypes. Not toy projects. A native macOS app with webcam-based hydration tracking. A system that reverse-engineered a proprietary camera protocol to monitor a construction site. A sales training simulator with sub-300ms voice latency and AI personas that score your performance against a rubric. A Vue.js-to-Next.js migration of a production control plane that an external vendor had quoted at six months and a million reais — finished on a Friday evening between 5pm and 7pm.
But the point isn't the projects. The point is what their existence does to every role in the modern SDLC.
Take that sales training platform. The idea had been sitting on a whiteboard for months. In the old world, it would have gone through product discovery, design sprints, engineering estimation, backlog prioritization. Multiple specialists across weeks or months. I built it from ideation to working product — voice mode included, scoring rubric and all — in under twenty-four hours. Take the control plane migration. Three years on the roadmap. Constantly deprioritized. An external vendor quoted six months and R$1 million. My colleague and I sat down with Claude Code on a Friday at 5pm. By 7pm it was done. The team couldn't believe it on Monday morning.
When one person can do this, the entire machinery we built to coordinate dozens of specialists starts to look unnecessary.
Product managers existed to de-risk what gets built, because building the wrong thing was catastrophically expensive. When you can put a working prototype in front of real users in hours, you don't need six weeks of discovery to justify a bet. You just build it and see. The best product thinkers will thrive — the ones who truly understand the customer, who carry genuine domain insight. The ones who were mostly shuffling Jira tickets and running ceremonies are in trouble.
Designers spent weeks crafting experiences. AI can now one-shot decent UI and generate ten variants for testing. Connected to behavioral feedback, it iterates faster than any human team. The designers who operate at the strategic level — understanding psychology, brand, emotion — are irreplaceable. The ones producing wireframes and component specs are watching their craft dissolve.
I'd never written a line of Swift before this year. I shipped two native macOS apps with custom UI, menu bar integration, and webcam detection in a couple of weekends. The language barrier — the thing that justified frontend specialists, iOS developers, Android developers, each with years of platform-specific expertise — is gone.
Data pipelines, dashboards, infrastructure runbooks — same story. AI generates ETL pipelines from descriptions, queries data conversationally, monitors systems and diagnoses incidents before humans even notice. The months-long dashboard project becomes a conversation. The 3am pager alert gets handled by an agent that also writes the post-mortem.
I had a conversation recently with an engineering manager on my team who argued that at least the edges of the cycle would remain human: deciding what to build at the beginning, and operating resilient systems at the end. That same week, I saw Claude Code generate a PRD ten times better than the best one I'd ever seen in my career, given access to a repository and company documents. I also watched an agent connected to Datadog, AWS, and GitHub detect a major database issue before it became a crisis — and produce the most thorough incident report I've ever read, complete with a pull request performing the required migrations to prevent disaster.
Every role in the SDLC was justified by the same underlying reality: software was hard, expensive, and required rare expertise. That reality is fading. The roles don't disappear overnight. But they compress. Dramatically.
The Future of Technology Organizations
The fundamentals of human nature haven't changed. We still need humans in charge, making decisions, being accountable for outcomes. But the shape of technology organizations will be radically different.
I'm testing this right now. At Stone, I've thrown two entirely new projects at a team of five that already handles all of our digital sales — hundreds of thousands of transactions a month. I'm spinning up a new team to tackle one of our hardest problems with three people: one PM, two software engineers. A year ago, either of these would have required dedicated squads of eight or more.
Teams shrink to their essence. Instead of a squad of eight to ten — a product manager, a designer, five engineers, an SRE — you're looking at something like one product/business person and two engineers. Maybe fewer.
Engineers become managers of agents. The job isn't writing code anymore. It's directing, reviewing, and orchestrating AI agents that write code. The craft shifts from production to curation, from typing to thinking.
The agents themselves become specialized — not by language or platform, but by role (SWE, SRE, security expert), by domain (payments, authentication, governance), and by project. They work together in loops, building software within the existing infrastructure of the organization. Think of it less like a team of humans and more like a fleet of capabilities you compose and direct.
Engineering managers who "only manage people" become a thing of the past. When your team is two humans and a fleet of agents, the distinction between technical leadership and people management collapses. Everyone is technical. Everyone manages — agents, if not people.
Specialized roles fade. Generalists win. When AI handles the deep specialist work, the human advantage shifts to breadth: understanding the business, the customer, the system as a whole. The T-shaped engineer becomes the only shape that matters, with AI providing infinite depth on demand.
And here's the most consequential shift: managers become accountable for real business outcomes, not engineering outputs. There's no more hiding behind "we need to refactor" or "we're paying down tech debt." The machine does that in the background. What's left is the only question that ever mattered: are we building the right thing?
What Needs to Evolve
I should be honest about where AI falls short today. Not the hand-wavy "it hallucinates" caveat. The specific ways it fails that reveal what's genuinely hard.
When I was reverse-engineering a proprietary camera protocol for my construction site monitor, Claude spent roughly thirty hours trying and failing. It would commit to an approach, hit a wall, and instead of reconsidering its fundamental assumptions, keep hammering the same angle with minor variations. I had to intervene three times to steer it toward a different path entirely. That pattern — resilient wrongness, insisting on an approach because it can't see its own blind spots — is a real limitation. It's not a hallucination problem. It's a judgment problem.
I've seen it design interfaces with toolbars stacked on toolbars, every page looking like it was built by a different person, missing the basic cohesion that any junior designer would catch on instinct. I've seen it produce reports so verbose and generic they read like they were written by a committee of no one — technically correct, emotionally disconnected, useless for a human audience.
And then there are the failures that reveal something deeper. My Livelo loyalty program notifier needed to understand that the rarity of a promotion isn't just about how often it appears — it's about how large the multiplier is. A 2x promotion every week isn't rare. A 10x promotion once a year is. AI couldn't make that distinction. It took a human who had been checking Livelo compulsively for years to know what "rare" actually meant. That's not a bug that gets fixed with a better model. That's domain intuition — the kind of knowledge you earn by living inside a problem.
Then there's the coordination problem — the one that Team Topologies and org design tried to solve. Does AI make it go away? No. But here's the nuance: when you have dramatically fewer people in an organization, coordination becomes manageable in a way it never was with teams of hundreds. You can hire the best. You can optimize for cooperative skills. You can spend real time building trust and alignment — because the AI is handling the production work. The coordination problem doesn't vanish. It just stops being the dominant constraint.
These aren't speed bumps to wave away. They're the contours of a new division of labor. Humans provide judgment, taste, domain intuition, and the ability to know what they don't know. AI provides speed, breadth, and tireless execution. The boundary between those two will keep shifting. But it exists, and pretending otherwise is as naive as denying the transformation altogether.
The New Bottleneck
Here's what I keep coming back to. Building those twelve projects in six weeks was the easy part.
Getting anyone to care — that's the hard part. And it's going to get harder.
A few years from now, the internet will be bloated with software. Everyone with an itch and an AI subscription will be able to scratch it with a working product by the weekend. The supply of software will explode. The supply of human attention won't.
It goes further than that. AI doesn't just make building cheap — it makes marketing automated, sales automated, support automated. The obvious playbooks get commoditized right alongside the code. So where can you have an angle?
I genuinely believe the answer lives in the real world. In the things that can't be generated: real relationships with real customers. A brand that people trust because a human being stood behind it. Distribution channels built on reputation, not algorithms. The companies that win won't just build differently — they'll sell differently, support differently, show up differently. In person. In ways that matter.
The bottleneck moves from production to distribution. From engineering to everything else.
But here's why this story isn't a tragedy for the people who build things. For the nerds who actually love making stuff — who got into this because they were curious, not because the salaries were good — this is the best news possible. The tools are finally worthy of the ambition. You can build what you've always wanted to build. The barrier isn't skill or time anymore. It's taste, judgment, and the willingness to do the hard part: getting what you built into the hands of people who need it.
The king is dead. The era of comfortable hyper-specialization, of $500K salaries for working in a narrow lane, is ending. I'm betting on what comes next — reorganizing my teams, learning new tools every week, shipping things I never would have attempted a year ago. Not because I'm certain about every prediction in this essay. I'm not. But the only losing move is standing still.
We started this story with webmasters — generalists who did everything, driven by curiosity more than career ambition. We're heading back toward the same place, thirty years later. The tools are incomparably more powerful. The scale is incomparably larger. But the fundamental shape of the work — one person, many capabilities, endless curiosity — feels strangely familiar.
Nothing will be the same. And somehow, everything will be what it always was.