The Myth of the 100x Developer

I have noticed that people who build software with AI like to talk in multipliers. They used to say it's made them 10x faster... but lately (whether due to impact inflation or just plain one-upmanship) the number has grown to 100x faster and appears to keep climbing. On the other hand, people who are skeptical of AI like to do the math on those claims and, rightfully so, watch them fall apart. The cleanest version of the 100x rebuttal goes like this: to be a 100x developer, you'd have to deliver an entire year's worth of work in under four days. Said out loud, it sounds absurd, because it is absurd. Nobody compresses a year into a long weekend.

I've been on both sides of this. I spent the first part of my career as a solo full-stack developer in the LAMP (Linux, Apache, MySQL, PHP) era where every single line of code was either hand written or painstakenly searched for and copy-pasted from other people's work examples... and I've spent the last year building with "AI" as a constant collaborator. As a result of this experience, I have come to believe that both the AI boosters and skeptics are measuring the wrong thing. The skeptics are right that "100x faster" is nonsense. The boosters are right that something enormous has changed. The disagreement exists because everyone is arguing about speed, but it turns out that speed was never the interesting variable.

Let me show you what I mean with my own numbers, because they're unusually clean (I do a LOT of documentation).

The Sixteen-year Version

In 2000 I got laid off from a digital agency and almost immediately fell into building a tool for a major SF Bay Area real estate brokerage that needed to stop producing marketing materials by hand. That tool became Inkswitch MarketSpace, a multi-tenant SaaS for real estate marketing that eventually served around thirty thousand agents across a dozen brokerages from Hawaii to Virginia. At its peak it warehoused over a million high-resolution property images, synchronized hundreds of thousands of listings against regional MLS feeds, and pushed millions of marketing emails a month. It integrated with payment processors, a domain registrar's reseller API, multiple email services, and a print vendor's raster image processor that turned a digital flyer into a physical piece in someone's mailbox. I wrote and ran all of it alone.

Here is the part that matters for this discussion: it took me six years to go from the first concept to something I could responsibly make public, and the full arc of building it ran closer to sixteen years before development wound down. Much of that time was spent doing hands-on coding, testing, and deployment. But a whole lot more of it was the slower work of discovering what the customer actually wanted, learning each integration partner's idiosyncratic protocol by hand in a pre-iPaaS era, and re-architecting as the product's center of gravity shifted... not to mention all the time spent searching for actually working samples of things that I could weave into my own work. The kinds of shortcuts coders relied upon even just a couple of years ago did not exist in that time... the basic frameworks a developer would casually reach for today were still five to fifteen years from being written. Like a one-man engineering crew carving a highway through the wilderness, I was literally building the road as I drove on it.

I'll also be honest about what that era's software looked like under the hood. The security posture was embarrassing... argually criminal by today's standards. There was no deployment pipeline, no code repository, no documentation, no test suite and no monitoring to speak of. Those weren't oversights, exactly. They were the cost of being one person with a finite number of hours... choosing which battles were affordable. Most weren't.

The Under-a-year Version

Now here is the last twelve months or so, from a standing start back into principal development.

Starting in July of 2025 I built Cuebe, a real-time theater production crew and cue sheet management system, as a deliberate crash course to find out whether any of my coding skills from the early 2000s were still relevant. And when I say "crash course" I want you to imagine the villain in the movie Time Bandits asking his henchman what "lasers" are. My awareness of modern coding tooling and processes was so limited that discovering what systems and processes I would need to learn how to use to pull this project together was like learning the names and relationships of 50 distant relatives the night before my own family reunion, with the same anxiety that somehow this was all information that I should already know like the back of my hand if I want to remain a member of the family. Starting from absolute zero, I was able to create a demo-ready app deployed to a publicly accessible server with role-based authentication and multi-user synchronized event timing in under five weeks.

Fast on the heels of Cuebe I delivered Route Companion, a multi-tenant logistics platform that bolts geographic route optimization onto the existing point-of-sale system of a high-end dry cleaners in an upscale coastal California community, in three and a half months as a paid client engagement. Following that effort, I built my own studio's website with a working retrieval-augmented chatbot in about one month of total effort. From that experience I extracted a modular component library, Blok, that now stands at forty-five published feature units. I'm partway through Heiress, an investor-funded, multi-tenant SaaS with real-time mobile to desktop photo capture and annotation and a cryptographic provenance ledger. And then I used my Blok system to built BigBoard, an internal observability dashboard that monitors my whole fleet of apps and all of their dependencies, with the working foundation standing up in four days and a local-LLM analysis layer added three days after that.

None of these projects are toys. They ship with real user authentication, role-based access control, modern password hashing, multi-factor auth, encrypted credentials, parameterized queries, multi-tenant data isolation, automated backups, uptime monitoring, redis-based rate limiting and real test coverage... from fifty-two percent on the backend of Route Companion with over ninety percent on critical paths to seventy-two percent on BigBoard. These are the exact things I skipped in 2005 because I couldn't afford them. Now they're the floor.

So: is this 100x? If you do the skeptic's arithmetic, the MarketSpace-to-portfolio comparison looks insane. Sixteen years of one product versus a year of six... with two more already in the pipeline. But that framing is a trap, and I want to walk into it on purpose before I explain why it's the wrong room to be standing in.

The Steelman

The skeptic's case deserves to be made well, so here it is at full strength.

If 100x means what it literally says... the same unit of work, produced one hundred times faster... then it is fantasy. A year of professional software work is roughly two thousand hours. One hundred times faster would compress that into about twenty hours, less than three working days. No one is doing that, and anyone who claims to is either redefining "work" mid-sentence or selling something.

The hard truth that most people don't talk about is this... most of what makes a software project take a year was never about how fast you can deliver lines of working code in the first place. It was figuring out what to build, talking to the people who'd use it, hitting dead ends, waiting on your own slow accumulation of competence in an unfamiliar domain, and discovering the requirement you misunderstood three months ago. An AI that produces working code faster doesn't obviously touch most of that. The coding itself, the part that looks like it's being accelerated, was often the smallest slice of the clock.

The skeptics are also right that a great deal of "10x / 100x" talk is marketing dressed as testimony, that AI-generated code can be confidently wrong, and that an enthusiastic beginner shipping fast is often shipping a liability. If you measure keystrokes-to-output on a fixed, well-understood task, the honest multiplier is real but modest... and nowhere near a hundred. And, as we've seen in many cases, that multiplier may even be negative.

I agree with all of that. And it still completely misses what happened to me.

The Wrong Axis

The steelman assumes the deliverable is fixed and only speed varies. It measures the same work, faster. But that's not my experience at all. I'm not delivering the same work a hundred times faster. I'm delivering different work... deeper, broader, and of a quality I simply could not reach before, regardless of how much time you'd have given me.

Think about that security list again. In the MarketSpace era, proper auth, MFA, encrypted secrets, and a real test suite weren't things I did slowly. They were things I didn't do at all, because each one carried a fixed cost in competence and hours that wasn't worth paying for a solo product fighting to stay alive. The relevant change isn't that those tasks got faster. It's that their cost fell below the threshold where I bother. Work that was previously uneconomical became routine. That's not a point on the speed axis. It's a different axis entirely.

This is why the car metaphor everyone reaches for is incomplete. The skeptic pictures the same car going from one mile an hour to a hundred, and rightly says that's not what's happening. But the real change was never the car's top speed. It's that I no longer have to stop and build the road as I go. The reason MarketSpace took six years to reach daylight wasn't that I delivered working code slowly. It's that every few miles I had to get out and lay pavement... acquire a skill before I could use it, learn a new integration protocol from poorly written docs, or hand-roll infrastructure that didn't exist yet. The AI doesn't make my car faster. It paves the road ahead of me so the distance from "I have an idea of where I want to go" to "I'm driving there at speed" has collapsed to nearly zero.

The Part That Compounds

If it stopped there, it would be impressive but linear. The reason it doesn't feel linear... the reason "100x" gestures at something true even though the number is wrong... is that the gains compound.

When I built this site's custom authentication system, I didn't just ship it and move on. The pattern got extracted into my Blok repository as a reusable unit. My next project consumed it, and so will the next five projects I build. One piece of hard work, done once, now arrives very nearly pre-built in every project that follows. When BigBoard needed every monitored app to expose a connectivity endpoint, adding that capability across three separate production apps was a single day's cross-portfolio work, because they all sit on the same shared core. Each new project doesn't start at zero. It starts further down a road I've already paved, and every project I finish lengthens the road for the next one.

That's the actual shape of the delta. Lower the cost of doing things right, and you do more of them. Do more of them on shared infrastructure, and each one makes the next cheaper. The inputs are linear... my hours haven't multiplied... but the outputs aren't. Cheaper rigor makes refactoring safe; safe refactoring makes good architecture affordable; good architecture makes the next feature cheaper still. The multiplier people are grasping at isn't speed. It's compounding.

A Capability That Didn't Exist

There's one more dimension the speed framing can't see at all, because it isn't about how I build... it's about what the software itself can now do.

When I built my studio site, I gave it a chatbot named Mason that answers visitor questions using retrieval-augmented generation, grounded in my own documents, with citations that point to the exact character range in the source. I had never built anything like it. I first encountered RAG on a Friday and had a working version integrated by the next afternoon. BigBoard runs a local language model on a small Linux box in my office... no cloud, no per-call cost... that writes a nightly health analysis and sends me a weekly wrap-up email of my whole portfolio... and supports semantic search across months of signal history. Today I'm exploring agentic tool selection, letting user-selected LLM models with "bring your own key" support decide which capability to invoke for a given task to support understanding and adoption of the even more complex tools I'm using those same models to build.

None of these were on the menu in 2005. They didn't exist as options at any speed. So when someone insists the only thing AI changed is how fast you can deliver lines of working code, they're not just understating the productivity shift. They're missing that an entire category of product capability... language understanding, retrieval, reasoning over a corpus, run-time tool selection and integration... is now something a solo builder can put inside the thing they ship. The tool that accelerates the building becomes an ingredient in the work that gets built.

How I'd Actually Talk About It

So when people ask whether AI made me a 100x developer, here's my honest answer: no, and the question is aimed at the wrong target. I don't produce the same work a hundred times faster. The change is a change in kind, not degree. The cost of doing things well collapsed, so work that used to be out of reach became routine; that work compounds across projects because it lives on shared infrastructure; and the AI itself became a capability I can build into the product, not just a faster way to deliver the lines of code the product is made of.

If you want the metaphor in full: AI doesn't make your car a hundred times faster. It means you don't have to build the road as you go. And once you've spent a year laying down a network of roads... your patterns, your libraries, your reusable infrastructure... the question stops being how fast can I drive and becomes how many places can I now reach. That's the part the multiplier was always failing to name. It was never about velocity. It was about expanding the map.