The methodologies for developing large software systems have evolved to optimize for the unit economics of the moment. LLMs have changed the cost of creating a maximum virtual product for large software projects. As a result, we need to re-prioritize the prototyping phases of the software development lifecycle.

A maximum virtual product is “a hyperrealistic, exquisitely detailed model”¹ used during the planning and prototyping phase of a project. The term was introduced in How Big Things Get Done. Whereas a minimum viable product is a great fit for small-scale or easy-to-reverse projects, they are not well-suited for large, hard-to-undo projects. In these cases, a maximum virtual product enables extensive simulation and experimentation before executing a plan.

Software is thought of as an easy-to-reverse work product. Which is true, until it isn’t. A piece of software is less fungible as soon as people rely on it.

Software can be both a prototype and the final result. The difference depends on context. The relative expense of writing code influences whether it is likely to be used as a prototype². Up until recently, writing a high-fidelity software prototype was always an expensive endeavor. Back in the waterfall³ days, a program design was synonymous with a prototype. A program design, however, is a poor prototype because it fails to stress-test theory against practical realities. An interface mockup doesn’t address the ergonomics of how clients will use it. A program design doesn’t make the designer feel the pain of having to click 10 different places to perform an action.

The agile manifesto and related agile methodologies, such as extreme programming⁴ and scrum, de-emphasize the program design phase by slicing a project’s scope into small functional increments. The result is increased coding velocity at the cost of deferring system-wide design decisions. Smaller, earlier, narrow-in-scope, naive decisions then have time to calcify. Now the project is at a point where system-wide changes are expensive. Thus, the premature functional slicing of a large project increases its own development cost. Said another way: the project feels fast at the start, and devolves into a slog. Naturally, teams end up with a water-scrum-fall hybrid process. Adopting an iterative approach after the big design decisions are made.

And then the LLMs came. AI coding agents have made writing code way cheaper — code quality notwithstanding. The limiting factor of LLM-based code production is a sufficiently detailed prompt. This means that “hyperrealistic, exquisitely detailed model[s]” of software are within reach of most teams! It is easy to create an arbitrary number of high-fidelity software prototypes.

Now the program design phase can start with a maximum virtual product (many versions of it), followed by hands-on testing, then by requirement refinement. Repeat until satisfied! The load-bearing decisions of a project do not have to follow a philosophical and bureaucratic process. Instead, they follow high-quality feedback from the team’s hands-on testing.

footnotes

1. How Big Things Get Done, Dan Gardner and Oxford professor Bent Flyvbjerg (ch. 4, “Pixar Planning,” p. 78) ↩

2. Sixty Years of Software Development Life Cycle Models ↩

3. MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS ↩

4. http://www.extremeprogramming.org ↩

It’s time to ponder the cruel irony — for corporations, anyway — that the only computer we can build is Turing-complete. That makes walled gardens technically¹ impossible to enforce completely.

Every time some tech company erected a 10-foot enshittifying fence, someone would show up with an 11-foot disenshittifying ladder. Those 11-foot ladders represented the power of interoperability, the inescapable bounty of the Turing-complete, universal von Neumann machine, which, by definition, is capable of running every valid program.
—“Are the means of computation even seizable?”, Cory Doctorow

You may have missed that Chipotle was handing out free tokens to anyone who poked at its “Pepper” agent the right way.

After all, you or I might not have the knowledge and resources to uncover the keys’ hiding place, but someone does.
—“Are the means of computation even seizable?”, Cory Doctorow

Why must the most revolutionary technological innovation of the century be so unruly? Why must AI agents refuse to build neat little walled gardens?

Alas, we are left with no good, terrible tradeoffs. Give an agency to an agent and risk unexpected attack vectors. Clamp it down and diminish its usefulness. The screen is right there, Microsoft, click on it!

The aftermath of an overeager prompt can bring a business to its knees. The impending doom looms. “Duh! Agents shouldn’t be able to perform actions without human sign-off.” Do you want me chained to a keyboard, hitting accept edits like an automaton? That doesn’t feel like a 100x engineer to me. I tried telling it to make no mistakes. It didn’t take.

Bring your thinking hat. The work is not for the faint of heart. Get ready to…

footnotes

1. Although technically impossible to completely close off a consumer product, there are a lot of laws discouraging folks from doing so. ↩

The motherfuckingwebsite series¹ ironically turned into an example of why web development is hard. There is always one more layer of complexity to add — responsiveness, load performance, accessibility, security, and juggling 100 npm packages. But, it’s a funny, ironic website series!

I made² the agenticmotherfucking.website to savor the schadenfreude of the complete re-evaluation of the human value-add proposition in the software-writing process. It’s fitting that I, a mediocre-at-best web developer, was able to one-shot a motherfucking website between washing dishes and taking out the trash.

The creator of thebestmotherfucking.website commented on the Hacker News post!

And folks took the initiative to email me:

---

footnotes

1. All the pages of the series that I’m aware of: mf website, better mfw, even better mfw, best mfw, perfect mfw, secure mfw. ↩

2. Here is the prompt I used:

   Make me a static html website that is a sequel to the https://motherfuckingwebsite.com/ and its sequels: http://bettermotherfuckingwebsite.com/ https://thebestmotherfucking.website/ https://perfectmotherfuckingwebsite.com/ https://securemotherfuckingwebsite.com/ https://evenbettermotherfucking.website/ https://bestmotherfucking.website/

   This new sequel to the MFW series is the “vibe coded” version. It should include all the lessons and best practices mentioned in the previous versions of the series. However the tone of the story should focus on the fact that creating a website with clean code doesn’t matter anymore. Everyone is vibe coding now, no one cares about maintainability or keeping complexity low. Static website don’t even matter anymore because everyone is too busy doomscrolling through videos of Reddit stories with a subway surfer asmr video in the background (in fact, add a subway surfer video loop the scrolls with you as a commentary on short attention spans). In the time it takes to hand-code a motherfucking website I can spawn a swarm of ai agents that can make an entire slopfest ecosystem that can burn through a million dollars worth of tokens every hour just I can get hired for a stupid high paycheck or take vc money with my AI native token burning machine. Come up with more ironic twists of how old principles don’t matter in our current world of ai because they don’t prioritize the things that carry attention span.

   The subway surfer inspired video loop was later removed because it bloated the CSS and defeated part of the simple-ness that MFW aspire to have. ↩

I did not think I was going to get old… how wrong I was! Years ago, I watched Neil deGrasse Tyson explain how deceptively long one billion seconds is. One billion seconds is a good way of splitting a hypothetical 90-year life into three parts. Having recently passed my first one-billion-second milestone, I felt the need to make something to commemorate the moment. As a nerd with little creativity, I decided to make a one-billion-second calculator website: onebillionseconds.io

To prove how uncreative I am, here is a list of other folks who made the same thing before me: meandeviation.com, zertrin.org, brainbashers.com, brownspaceman.com, billionbirthday.com, freecalculator.io, tigre-bleu.net, Wait But Why, bryanbraun.com, weeksoflife.com, lifecalendar.io, and Robert Waldinger.

Over the years, I’ve made several attempts at a personal blog. First, when I learned the basics of HTML and JavaScript back in high school — I abandoned that blog because I spent 80% of my time trying (and failing) to make the page look “cool”. Silly me, couldn’t I see that fancy CSS is just fluff? It would be years before I ran into the motherfucking website series (better, even better, best, perfect, secure) — ironically, the MFW series demonstrates how web dev gets out of hand with endless layers of complexity. I tried again in college, when I thought my schoolwork on threads and concurrency controls was outstanding and the world had to know about it. And now I give it a third try — this time as a seasoned software engineer with shockingly little front-end experience, but with the knowledge that fancy styling is nothing but fluff¹.

Creating a blog wasn’t the original goal. The goal was to create a calculator site to tell a story about the unintuitive nature of large numbers. But as I struggled with the mess that is modern web development, I decided to keep a journal of my progress, which eventually became this blog. The “oneb” name was initially inspired by getting lazy writing onebillionseconds over and over again. The name grew on me and took on a meaning of its own: one blog, one bit/byte, or a play on words of an ordered list that doesn’t discriminate (“one, b, III”). I’m curious to see where this blog iteration goes and how long it sticks around. Thanks for reading!

---

footnotes

1. Me from the future! LLMs are a thing. They will make a pretty-looking website for me, while I remain blissfully unaware of how to write CSS. ↩