The prompt that changed my perspective
I recently used Perplexity Computer to link my investment accounts together and build a portfolio tracker. Not a landing page. Not a toy. An actual working application that authenticated into multiple brokerages, pulled live holdings, and displayed it in a clean interface. I wrote a prompt, walked away, and came back 10 minutes later to something that worked.
What hit me wasn’t that the application existed. It was that I didn’t write a single line of code. The gap between “I wish this existed” and “this exists” collapsed into an afternoon. I’ve been in software long enough to know what it takes to build a tool like that, and watching it materialize from a prompt was the first time the pace of change stopped feeling theoretical and started feeling immediate. This piece is what I’ve been thinking about since.
Code without a tether is a commodity
The clearest way to think about which software survives the AI wave is to ask what the software is actually selling. If the answer is “the code itself,” it’s in trouble. If the answer is “the network, the data, or the physical operation the code sits on top of,” it’s most likely safe.
Jira and Figma are pure software. There’s nothing inside them a sufficiently capable model can’t reproduce on request, and nothing stopping an enterprising user from typing “build me Jira, but less annoying.” Their moats are switching costs and habit, not anything intrinsic to the product. The code is just the part everyone sees.
X (Twitter) is the opposite. You can clone the UI in a weekend and it’s worthless, because the product was never the interface, it was the hundreds of millions of people already posting there and the real-time conversation that only exists because everyone agreed this is where it happens. That doesn’t come out of a prompt. MrBeast is not going to migrate to your clone no matter how cleanly you rebuilt the timeline. The same pattern holds wherever the software is a delivery mechanism for something real:
- Uber: drivers, riders, and regulatory relationships in every city
- Bloomberg: proprietary data feeds and decades of terminal lock-in
- Plaid: bank integrations nobody, and I mean nobody, wants to redo
Anything with a two-sided market, a proprietary dataset, a hardware component, or a messy real-world integration layer has a real moat. Anything that’s just code pretending to have one does not. The software industry is about to get re-sorted along that line, and a lot of companies that currently look like category leaders are going to discover their moats don’t work when bridges are free.
I’ve been thinking about how this test applies to the two products I manage. Savvy Trader is a platform where investors share and subscribe to investment portfolios. Its moat is the creators themselves: people with verified track records who’ve been publishing trades against live market data, providing unique and thoughtful commentary alongside every move they make. “Recreate Savvy Trader” gets you the UI, it doesn’t get you the people. Earnings Hub is a tool that tracks earnings estimates, EPS and revenue data, and corporate guidance. It’s the best earnings calendar on the market and it’s not particularly close. But at the end of the day, it’s a clean and intuitive interface on top of public earnings data. Majority of the underlying information isn’t proprietary. If I’m being honest with myself about my own thesis, Savvy Trader is on the right side of this line and Earnings Hub is offsides. Being the best doesn’t make you safe when someone can prompt a good-enough version into existence. That’s useful clarity to have, even when the answer isn’t the one I’d prefer.
Capability doesn’t mean everyone builds their own
If anyone can prompt their way to a Jira clone, won’t everyone just do that, and doesn’t that kill the industry? Probably not. Everyone can cook dinner at home and restaurants still exist, because convenience, expertise, consistency, and the experience are worth paying for even when the alternative is available. Nobody’s shutting down the Olive Garden because you own a pan.
The fact that a small business could prompt its own CRM into existence doesn’t mean it will. Most people and most organizations still want something pre-built, supported, and warrantied by someone whose job it is to keep it running at 2am. What collapses isn’t the existence of software companies, it’s the pricing power of generic software. The “$40 per seat per month for reasonable tooling” business has the floor drop out from under it. Companies that survive offer something beyond the code: support, integrations, trust, brand, or the peace of mind of knowing someone else is on the hook when things break.
B2B takes the bigger hit than B2C
The replacement pressure is heavier on the B2B side, and the reason is purely about incentives.
A company evaluating build-versus-buy has a real financial motive to build. Every SaaS subscription is a recurring cost, a vendor relationship, a security review, and a dependency. If the cost of building a functional internal version drops from “impossible without a team and a year” to “one builder and a weekend,” the math flips for a huge percentage of B2B purchases.
An average consumer has almost none of that motivation. A big chunk of consumer software is ad-supported and free at the point of use, which means building your own version doesn’t save money, it actively costs more. You’d be paying in time and hosting fees, plus an AI subscription to build the thing in the first place, for something you currently get for free. That’s a rough pitch. Even for the paid stuff, the effort usually exceeds the ten dollars a month you’d save. Most consumers won’t bother building their own, but some will absolutely prompt a replacement to save a few bucks.
The overall pattern looks like this: the more a product’s value comes from the code itself, the more exposed it is. The more it comes from data, network, physical operations, or sheer user base, the safer it is. B2B tooling for known workflows is the most exposed because the buyer is economically motivated and increasingly technically capable. Large consumer platforms with real moats are safe. Where any given product falls on that spectrum depends on one question: if someone prompted a working clone into existence tomorrow, would anyone switch? If the answer is yes, the moat was never the code. The code was just the part that used to be hard.
The current state is the image-generation moment
There’s a useful parallel to AI image generation, after all a picture is worth 1,000 words. The first time you saw a model produce a photorealistic image, it felt like magic. Then you looked closer and noticed the hands had six fingers, the text was gibberish, and the eyes were subtly crossed. The “this changes everything” reaction was right about the trajectory and wrong about the immediate reality.
Software generation is at exactly that stage, which means there’s no reason to panic just yet. You can prompt a full application into existence and the first impression is stunning. Then you use it for two minutes and the cracks show up. State management is subtly broken, edge cases aren’t handled, integrations are fragile, and there’s always one button that does nothing. It’s the six-finger problem in software form.
The other thing the image-generation analogy gets right is that it happened unevenly. Image generation didn’t come for every visual market at once. It hit stock photography first, then logo design and spec illustration work, then certain kinds of concept art, and still hasn’t fully hit high-end commercial illustration or fine art, though I’d be lying if I said there aren’t a few AI-generated pieces my wife made hanging in our house right now.
The economic consequences don’t hit on the day AI can almost build software. They hit on the day AI can build software that holds up under real use, and that day is later than the demos suggest but sooner than the skeptics think. Image generation took a few years to go from “amazing but cursed” to “good enough that entire industries reorganized around it.” Software is harder because the failure modes are functional rather than visual, which means there’s further to go and the cliff is higher when you fall off it.
Three structural shifts for software creators
By software creators I mean everyone whose job is to make software happen: developers, product managers, designers, and anyone else in that loop. The employment picture for all of them changes in three ways at once. The first is obvious. The other two are less so, and they’re the ones worth paying attention to.
Shift 1: Software companies need fewer creators. If one person with good AI tools can do what five used to do, headcount at pure software companies comes down. The people who remain will operate at a higher level of abstraction, closer to architecture and decision-making than implementation. This isn’t hypothetical. Atlassian cut 10% of its workforce, with its CEO citing changes needed for the “AI era.” Block cut nearly half its workforce, with Jack Dorsey explicitly pointing to AI. Whether every one of these cuts is genuinely AI-driven or partly cover for restructuring that would have happened anyway, the direction is clear, and the trend is moving faster than most of the industry expected.
Shift 2: Non-software companies start hiring software creators they never had before. Every company subscribing to a stack of SaaS tools is a potential builder of its own internal software, but building and maintaining it still requires somebody who knows what they’re doing. Mid-sized businesses paying six or seven figures a year across dozens of tools will hire their first in-house builder to replace those subscriptions with owned software. This isn’t happening at scale yet, because the current state is still the image-generation moment. Most companies would get burned trying to replace their stack today. The smart ones are keeping a close eye on tools like Perplexity and Claude so they know when those products are truly ready for primetime.
Shift 3: A lot of creators won’t have employers at all. This is the quiet version of the story and probably the most important. The historical reason software creators worked at companies was that building anything serious required a team, infrastructure, capital, and distribution an individual couldn’t assemble alone. All of those barriers are dropping at once.
Why give your company the profit from work you could do, own, and monetize yourself? It’s a question that’s going to get asked a lot more often over the next few years, and the people asking it will usually be the ones worth keeping.
Think of all three shifts together as a Thanos-style rebalancing of the industry. Jobs at pure software companies get destroyed. Jobs at every other kind of company get created. Solo creators build entire applications that used to require teams. The snap isn’t clean and a lot of people land awkwardly in the middle of it, but the universe finds a way to stay roughly in balance.
The cosmic irony of remote work
Speaking of balance, there’s a strange symmetry to all of this that I can’t stop thinking about. The software industry spent 2020 and 2021 achieving what many considered to be the dream: widespread remote work. Get paid six figures, live wherever you want, work in your sweats, never commute again. Too good to be true, and maybe it was. And let’s be honest, a lot of people took advantage. The same flexibility that let great engineers do their best work from a cabin in Colorado also let a lot of people collect a paycheck while doing the bare minimum from their couch, and everyone in the industry knows it even if nobody wants to say it out loud. It’s almost like the universe looked at an entire class of workers who’d managed to decouple their income from showing up anywhere, decided the pendulum had swung too far, and found the most ironic possible way to reset it. Not by dragging people back to the office, but by making the work itself something that doesn’t require a person at all.
The part that matters to me
There is still a lot of work to be done before AI starts truly replacing software jobs at scale. Even Perplexity Computer, the tool that kicked off this whole train of thought, has plenty of kinks. But it was the first time I used something and felt like the future is a bit closer than I maybe realized. Not here yet. But close enough that pretending otherwise feels irresponsible.
Savvy Trader is on the right side of the line I’ve been drawing, and my job there is to deepen the moat: more creators, better product features, tighter relationships with the people whose real performance is the actual product. Earnings Hub is on the wrong side, and my job there is harder. Figure out what I can build on top of the public data that isn’t just code, or accept that growth will slow down as consumers start building similar products in-house, literally from their house, at their kitchen table, in their pajamas. Sitting with that discomfort is better than pretending the wave isn’t coming when I can already see the water rising.
The people who navigate this well aren’t going to be the ones who guessed the future right. They’re going to be the ones who were honest with themselves about where they stood, so they don’t find themselves offsides.