The end of YC
When engineers lose their edge.
Like everyone else, I don’t like any of today’s note-taking apps. Like everyone else, I’ve tried dozens of them—Apple Notes, Google Keep™, Evernote, Notion, Obsidian, Roam, Bear, rogue .txt files files, Moleskin, 3M, MS Paint—and have never found one that’s not missing some critical feature or doesn’t have some fatal design flaw. And so, like everyone else, I have an idea for how to make a note-taking app that’s actually right, and finally fixes this problem for good.
Alas. Because, and I cannot stress this enough, I am not an engineer. I cannot build real products. Sure, I can write scripts: Crude functions of nested if statements and hardcoded loops that I manually run from a terminal or in a loose Python notebook somewhere. But I cannot do the work that makes an engineer an Engineer. I do not understand classes or methods or callbacks. I have no idea what __init__ does. It took me many hours to get ten lines of raw HTML on the internet. Though I hear they are important, I have never written a “test.” In the back of a closet, there is an old laptop of mine, bricked and thrown away because it is still stuck in VIM.
And so, my idea has stayed in my head, existing only between me and the occasional Arby’s. My notes remain disorganized. My wireframes, unbuilt; my million dollar idea, unrealized. My hero, unmet.
Until last week, when I found myself at Arby’s again:
“Speaking of buses, there’s a fundamental problem with how people conceptualize notes, and obviously, the correct note-taking app would –”
“Build it.”
“Yeah, I thought about that, but, start another company? The consumer market is too fragmented and enterprise productivity tools –”
“No, stop, just build it. Sign up for one of those AI developer tools and build it. Don’t explain this to me; explain it to them.”1
Fine, I thought. I’ll see what the hype is about. I typed up a rough description of what I wanted—a PRD, in the flimsiest of senses—and dumped it into a couple VS Code extensions and a few chatbots on .dev websites. If nothing else, I figured, this will make for good content about how these fads are shoddy slop factories that are destined to fail. The working title was already written: Turn down the music and get off my lawn. Bah humbug.
That is not what happened.
Within a few minutes of installing Cursor and setting up a handful of developmental studs, I had built a working prototype. Within 24 hours, I not only had a polished app; I was already at the limit of my initial idea, no longer just manufacturing what had been in my head, but trying to come up with new things to manifest. And within 48 hours, I was ruined. The comfortable physics that I thought governed Silicon Valley—that stuff takes time to build; that products need to be designed before they can be created; that computers cannot assume intent or interpolate their way through incomplete ideas—broke, utterly. It all worked too well, too fast.2 I was staggered, drunk on the Kool-Aid and high on the pills, unwell and off-brand. I knew that anyone can now build vibe-coded toys; I did not know that people with a basic familiarity with code could go much, much further.
Though it’s hard to benchmark how far I got in two days, this is my best guess: The app is roughly equivalent to what a designer and a couple professional engineers could build in a month or two. Granted, I didn’t build any of the scaffolding that a real company would—proper signup pages, hardened security policies, administrative features, “tests”—but the product expresses its core functionality as completely as any prototype that we showed Mode’s early investors and first customers. In 2013, it took us eight people, nine months, and hundreds of thousands of dollars to build something we could sell, and that was seen as reasonably efficient. Today, that feels possible to do with one person in two days.
Well, with one more caveat. Because I learned a second thing at the end of my two days of vertigo: That my idea was terrible.
The entire conceit didn’t work. My long-loved thesis, when rendered on a screen, was catastrophically bad.3 I did not want to start a business around my app. I did not want to take notes in my app. I did not want to use my app. I wanted to start over.4 Great chefs can come from anywhere, but not everyone can be a great chef.
To stylize this whole story, this is what it use to take to test out an idea:
You ponder the idea. You talk to people about it, at work and in coffee shops and at an Arby’s. You research the market, poke at potential competitors, and explore the space.
You decide the idea might work. You hire a lawyer, file some paperwork, set up a bank account and an email address, and start a company.
You make rough wireframes. You make decks for venture capitalists. You talk about the TAM, and growth dynamics, and distribution channels. You develop a “narrative.”
You hire a team; you sell the team on the idea; you tell them that you’re building a rocket ship.
You build a crude prototype. If it doesn’t work, you blame the problems on the product’s incompleteness. You keep going. You forge ahead. You rise and grind.5
You slowly marry yourself more tightly to your idea. You cross a financial Rubicon—there are now investors and a cap table and expected returns. You cross a reputational Rubicon—your friends6 know what you’re building, and your identity attaches itself to its success. You cross a multiplicative Rubicon—employees pledge their lives, fortunes, and sacred honor to the same cause.
And then, at some point, many months in, you find out: Was the idea good? And if you find out it’s not, you might plow ahead anyway, because that’s the only direction left to go.
And now, it’s this:
Lob a couple hundred words at Cursor and play with what it makes.
There are two ways to interpret all of this. The first is that it’s great for Silicon Valley, and for startups. They can test quicker, build cheaper, and disrupt better. They can accelerate, and replace the classic “triple, triple, double, double, double” climb to $100 million with a “100x, all at once” wormhole. They can conquer more, faster. As Silicon Valley’s Book of Proverbs says, “AI won’t replace programmers, but rather make it easier for programmers to replace everyone else.”
Undoubtedly, parts of that are true. Speed is already most startups’ biggest advantage; all of this makes that more acute. There will be companies that build with AI and companies that don’t, and those that don’t are dead.
But I’m not sure that’s good for programmers or Silicon Valley. Today, all of those prerequisites for building a product and testing an idea—founding a company, fundraising, hiring, and so on—are annoying speed bumps for engineers and other industry actors. But if you look like a good technologist, the machinery of Silicon Valley—from venture capitalists to incubators to Stripe Atlas, which promises to help people start a company in a few clicks—will power you through each one. For a Stanford computer science grad, Sand Hill Road is a red carpet and offices full of eager sherpas. For a restaurateur from Chicago, it is red tape and dismissive gatekeepers. For the former group, their ideas become products. For the latter, they become what ifs and could’ve beens.
In other words, a lot of today’s technology is the levered ideas of technologists. It is a book store, run by an engineer from a hedge fund; it is computerized cash registers, from a social media founder and Oracle employees; it is fitness classes, built by a Bain consultant and an MIT grad; it is a note-taking app, built by someone who knows enough Typescript to build a note-taking app. But if these products succeed, it’s often more because of the technology than the idea of the technologist. It’s not that the idea was bad; it’s that the idea was not the transformational advantage. A fine CAD program beats a drafting table. A fine banking app beats driving to a branch. Even my app beats hand-written note cards. And because people who are technologists first, and architects or bankers or writers second, are the only people who can lever their ideas with technology, their ideas win.
Moreover, this isn’t just some accidental selection bias; this is the whole point of Silicon Valley. Flagship incubators like Y Combinator are built on the thesis that a smart kid with a computer and summer internship at Goldman Sachs can outwit all of American Express. That’s not because the kid understands the needs of payment processors better than people at American Express, or has better ideas than they do; it’s because the kid can build their idea.
But what if anyone can? What if lots of people at American Express can build stuff? What if someone who’s been an architect for twenty years can make the design software they’ve always wanted? What if a veteran investment banker can write a program that automatically generates pitch books? What if a real writer makes a note-taking app? What if software is the levered ideas of experts?
Sure, the experts’ ideas might not always be better than ours. Sometimes they might get it wrong, and sometimes the Stanford kid will get it right. But if we begin comparing our ideas to theirs, and pitting the solutions designed by drive-by engineers against those built by a problem’s permanent residents, I suspect that we’ll realize that our ideas are awfully mediocre. We merely adopted the dark; other people were born in it.
Of course, technology has been “democratizing” other industries like this for years. In a world in which making movies is hard and expensive, Hollywood producers look like brilliant artists. In a world in which TikTok makes it possible for anyone to make a movie, the old guard is suddenly naked and exposed. Now, we’re doing the same thing to ourselves.7
Well, no, that is all a little bit too extreme. Bolt and v0 aren’t that good, and you can’t vibe-code your way to a new payment processor; Cursor is not that accessible, and every barista can’t build a new point-of-sale system for their coffee shop. There are gradients to all of this.
But engineering execution is no longer as important as it once was. When wireframes build themselves, there is a lot less differentiation in better manufacturing. There is only the idea. There is only taste.
David Perell—the “writing” guy—recently said it’s increasingly harder to out-write an LLM. They write as well as most of us do, and are just as clever. The authors who make it, he argued, will be those whose writing comes from personal experience. When the world is full of big-brained robots built on public data, “proprietary data”—personal experience, domain expertise, what we know rather than what we can do—is our only edge.
A lot of software today is built on relatively little proprietary knowledge and personal experience. It is built by people with passing exposures to the problems they’re solving.8 It is built by founders who arrive at their ideas via an incubator and a pivot. It is built by Geoff.
That used to be ok, because our unique talent for technology more than made up for our naiveté elsewhere. Founders could build huge businesses by plowing technology into analog problems, and investors like YC could build huge funds by selecting for whiz kids over world-weary experts. And they could both succeed because technical leverage mattered more than domain-specific taste.
But I’m not sure that will work for much longer. Just as it’s becoming harder to out-write an LLM, it’s becoming harder to out-develop one too. And if experts can prompt their way to a product just as easily as those of us in Silicon Valley can, what winning talent are we left with?
The White Lotus Power Rankings
After the first episode (the one that aired 12 days ago), a dominating performance by Saxon:
Plus, the men like Rick. The women hate him, and are real suspicious of Piper:
Cast your vote for episode two (the one that aired this past Sunday)!
Some people pay for chatbots to do the emotional labor that their partner won’t do. People in Silicon Valley pay for chatbots to do the emotional labor of humoring them about their dumb startup ideas.
Ok, not entirely. A lot of them were actually pretty clunky. Products like v0 and Replit tried to do too much, and the hosted app that they were building was constantly breaking and hard to debug. Cursor was much better, mostly because it just wrote code in a local environment. That made development loops much faster and far more tactile.
Never meet your heroes, they say.
So I did, and the new version…kinda works? It’s become more of a composition assistant than just a note repository, and it was somewhat instrumental in writing this post?
You post about it on LinkedIn.
And more importantly, your enemies.
That’s the danger of democratizing technology, I suppose. If you build it, you can’t be sure that you’re the one who’s going to get elected.
Obviously, this isn’t true of products built for Silicon Valley’s own problems.
The last 10% takes 90% of the work, and the last 1% takes 99% of the work and time. So sure you can get 80% of the way there, but that’s not the majority of the work. And you’re overestimating agency, we have had the internet for a long time, many choose to consume and a select few choose to produce and publish software and writing. There will always be a filter, the tools help but most people do not persist the roadblocks that come up.
As always Ben, spot on!