Defensibility After Vibe Coding: How YC Founders Build Moats in the AI Era

Once that became clear, the next pattern in the interviews was pretty obvious: the best founders are getting much closer to the customer than a generic AI product can. They’re not trying to win by being broadly useful. They’re trying to become deeply embedded somewhere specific.

A lot of the strongest companies in this set are making a very deliberate tradeoff: narrower market, deeper context. Caleb from Lance frames it cleanly: you can either get very good at selling self-serve agents, or get very good at a vertical. His team chose the latter. That choice matters because vertical depth gives you access to things a horizontal tool usually never earns — the workflow, the weird exceptions, the compliance constraints, the language customers use, the data exhaust from doing the job every day. Cathleen at Opalite Health makes this point especially well. A medical interpreter is not just a model with better prompts. It has to live inside clinical workflows, fit around HIPAA constraints, and remove friction for providers already operating in a high-stakes environment. That is not a thin wrapper problem. What also stood out to me is that these founders are often willing to do the unscalable part on purpose. Mathias from Balance talks about handholding customers closely, then automating what the team learns from that process. Akash at Chasi is even more direct: they go to the customer, sit with them, implement, and earn trust the slow way. In software, that kind of service can look unsophisticated from the outside. In practice, it’s often exactly how the moat gets built. So if section one is about code becoming cheaper, this is the natural response: get so close to the workflow that replacing you means rebuilding not just software, but accumulated context, trust, and operational know-how. That is a much taller order.

Another pattern I didn’t expect to be this strong: some founders are reacting to the “everything is easy to build” moment by choosing problems that are very obviously not easy. They’re leaning into regulated environments, ugly implementation constraints, and technically painful markets where speed alone does not get you very far.

This is the opposite of the usual startup advice to pick the path of least resistance. A number of founders I spoke to are effectively saying: if software is getting commoditized, then I want to operate where commoditization hits a wall. That wall can take different forms. Sometimes it’s regulation. Sometimes it’s safety. Sometimes it’s the reality of physics, logistics, or mission-critical reliability. Skyler at GRU Space talks about going where complexity and economic gravity protect the company from easy replication. Jayram at Byteport has a similar instinct from the infrastructure side: if you are building something truly critical, customers are not eager to trust the vibe-coded version. I also liked the way Leo from DAIVIN framed their strategy. Diving is the hardest environment for what they’re building, which means success there becomes more than validation. It becomes reputational proof. If it works underwater, people reasonably assume it can work somewhere easier too. That’s a powerful kind of defensibility because credibility earned in the hardest setting tends to travel. Kamran at Constellation Space pushes that logic even further into architecture. If intelligence moves on-board, into the satellite layer itself, then the moat stops looking like an app and starts looking like a system. That distinction matters. A lot of AI-era products are easy to copy at the interface layer. It’s much harder to copy the company that chose a domain where the real work sits underneath the interface, inside constraints most competitors won’t want to touch.

The last bucket of defensibility here is the one I think will matter more and more over time: not just what your team builds, but the internal systems it builds for itself. Once everyone has access to similar frontier models, a lot of advantage shifts into the private machinery around them.

Several founders described moats that do not show up cleanly in a demo. They live in internal loops: the data a company accumulates from serving a niche workflow, the agents it builds to compress research or operations, the bespoke tooling that quietly makes a team much faster than it looks from the outside. Amit from Ishiki Labs is a good example of the data version of this. Their product generates in-house scenarios and interactions that can be used to train a more socially aware layer for turn-taking AI. That’s interesting not because “data moat” is a new phrase, but because the data is being created through a very specific product surface and then folded back into capability. The internal-agent version is just as compelling. Atharva at AxionOrbital built an AI co-scientist that can move from hypothesis to papers, methods, code, benchmarks, and results. Christian at Orthogonal has an internal flywheel where support requests and recurring implementation work feed agents that can increasingly handle more of that workload. In both cases, the company is building machines that help build the company. Vincent from Panta makes the workflow angle clear too: sometimes the moat is simply that the internal tool is so tightly coupled to how your team actually operates that nothing off the shelf comes close. That feels increasingly important to me. When features are easier to copy, the more durable edge may be the private operating system behind them — the systems that help you learn faster, ship faster, and absorb customer complexity faster than the next team.