Why Every AI Team Needs Pirates and Architects
It’s 2026 and you can vibe code anything now. But just because you can vibe code it doesn’t mean you can vibe fix it, or at least vibe fix it quickly. This is a firsthand account from the co-founder and CEO of Every (a 25-person company) of building an app called Proof entirely through Codex, never looking at a single line of code, launching it to a huge response, and then living through the production meltdown that followed.
The core lesson is that software engineering in 2026 reorganizes around two roles: the pirate, who vibe codes as fast as possible to find something valuable, and the architect, who turns that valuable mess into a machine that actually works. The two are mutually dependent. Pirates keep architects supplied with market-tested raw material; architects keep pirates from shipping things that fall apart in production.
Beyond the team structure, the talk delivers concrete field rules for both roles: how pirates should think about simplicity, throwing out prototypes, and the addictive “slot machine” trap of one-more-prompt; and why senior engineers, far from being replaced, become more valuable when paired with AI because models still lack the conceptual clarity to make a system hang together at the macro level.
Vibe Coding Proof in 10 Days
In my spare time over the last couple of weeks I made an app called Proof. I did it entirely in Codex. I never looked at a single line of code, and I went from a basic idea to a finished app in about 10 days.
Proof is an agent-native document editor. You can think about it as Google Docs if Google Docs was made for agents to use. I made it for myself, to solve my own problem collaborating on markdown docs with my agent. I got a really basic MVP going, and then we launched it.
Launch Day and the Meltdown
Launch day was wild:
- Tweet engagement: ~1,500 likes and 500,000 views on the launch tweet alone
- Documents created: ~4,000 new Proof documents in the first 24 to 48 hours
When I looked at it the morning after launch and saw the stats, I was like, we’re going to the moon. Of course, I’m doing this video, so we did not go to the moon. But I did learn a lot about the future of coding with agents.
For the couple of weeks after launch, everything was melting down. I was staying up till 4:00 a.m. every night trying to get this hot piece of flaming garbage to work. I was literally sleeping with my laptop open next to me so that my agents could run, then checking it every three or four hours like I was some settler on the prairie tending my fire overnight so it wouldn’t go out.
And now it just works. I don’t have to spend much time making sure it’s up. I can just build new features. It still has some messy things, but it actually works, I use it every day, everyone on the team uses it, and it’s starting to grow as a real production app. Taking it from a vibe-coded sloppy mess to that point taught me a lot. Those lessons apply whether you’re vibe coding an app and wondering what happens when it hits production, you’re a startup CEO trying to figure out how engineering works in this new world, or you’re a software engineer wondering whether your skills are even valuable anymore.
The New Structure of Engineering Teams
The big takeaway is that there’s a new structure for software engineering in 2026. Engineering teams should be structured around two people: a pirate and an architect.
The Pirate
The pirate’s job is to figure out the product. It’s to move as fast as possible, explore the territory, and make something that people really need. The pirate is vibe coding. They’re not thinking about architecture. They’re not thinking about making a well-oiled machine, because what they want to do is find something valuable as quickly as they can. They own the vision for the product.
The Architect
The architect’s job is to keep that process on rails. As the pirate gets closer to something valuable, the architect helps turn it into a machine that is understandable, extensible, and maintainable, one that won’t just go down randomly for no reason that no one can figure out.
These roles are mutually dependent. Pirates need architects to keep them from making something that just falls apart. And architects need pirates to give them the raw material to work with, to make a system that’s actually worth making.
Lessons for Pirates
I definitely think of myself as a pirate. A few things I’ve learned about getting better at it.
1. Make a Simple Thing That Works Really Well
Because you can vibe code anything, the best thing you can make is a simple thing that works really well. The temptation with vibe coding is to keep adding one feature after another after another and never actually make anything of value. You’re going to be far better at building things people want if you zero in on what’s actually important about your product.
2. Once Something Works, Throw Out What You Have
Once you hit on something that works, you should just throw out what you already have. One of my favorite writers, Annie Dillard, calls this “covering your tracks.” In writing, you never want people to see how you got to the idea you have. You just want to give them the idea. The same is true in building products.
If you’re vibe coding a product and iterating on it constantly, your codebase is going to be a mess of tracks: different places you tried to go, different features you tried to build, different conceptualizations of the product. That’s all fine. But once you hit the thing you actually want to do, start it over. Code is cheap to write, so it’s actually very cheap to throw out.
The temptation will be to say, I don’t have to start over, I’ll just get my agent to refactor the codebase. That’s definitely not going to work. One of the interesting things about coding agents is they get really distracted by what’s already there. If you give them a vibe-coded mess, it’s actually going to be really hard to get them to rewrite it from scratch while they’re looking at the vibe-coded mess. What you really should do is just start a new codebase. A good sign that it’s time to do this: you have something that’s clearly valuable, and you have lots of bugs piling up that you can’t figure out how to fix no matter what you do.
3. Don’t Treat the Agent Like a Slot Machine
As I was doing this, Codex felt like a slot machine where each prompt I was like, this is going to be the one that works. My team was looking at me like, dude, you’ve been saying this for four days, what are you doing? And I just kept doing it. It’s really addicting to watch these agents work. It’s always easier to believe this one’s going to be the next one that solves all my problems than to actually go in and understand what’s going on.
It’s really important to think about your relationship to a coding agent and get the right relationship to it, so that you’re actually using it to build interesting things and not just wasting your time building garbage.
4. Remake Every Productivity App for Agents
There’s such a big opportunity to remake every productivity app for agents. Proof is sort of like Google Docs or Microsoft Word if it was primarily supposed to be used by an agent rather than a human. Every app for work, whether it’s Google Sheets or PowerPoint or anything like that, the primary users of the next generation of that software are going to be agents. If you start with an agent as your user, the kind of software you build is going to be totally different and really valuable.
Lessons for Architects
Let’s say you’re a much better version of me. You’re smarter, more careful, probably better looking, and you’re an architect, not a pirate. What can you take away from this?
If you’re an architect, you’ve probably been thinking: is software engineering going away as a profession? Do I have any value anymore? My experience says no. I actually fixed a lot of the issues with Proof by pulling in an architect to help me rewrite a few sections of the app from the ground up over the course of a week or so. That’s what really fixed the problems. It’s very clear to me after that experience that an architect using an AI is incredibly powerful and incredibly important, and isn’t just going to be replaced by a model in the near future.
That’s not to say coding models aren’t powerful or aren’t totally changing everything. They absolutely are. But coding models still lack some of the conceptual clarity that a really senior engineer can bring to a project. What you find with a coding model is they make lots of local changes that all make sense in isolation, but if you zoom out and look at the deep picture, the whole thing doesn’t hang together. Real engineers are very good at doing that. That won’t necessarily always be true of coding models, but for now, especially if you’re a senior engineer using these to extend your powers, you’re just making new expertise that the models don’t have.
Summary
Software engineering is changing. The way teams are structured, what you can build, and how you can build it is changing dramatically. And all you really need are two roles: a pirate, someone moving as fast as possible to figure out what’s valuable, and an architect, someone helping turn the valuable yet disorganized things the pirate has discovered into a well-structured, well-organized machine.
As for me, I’m definitely going to be using an architect next time I launch my vibe-coded side project, because my entire team will mutiny if I don’t. And honestly, it’s better to do things together. You don’t have to do everything yourself. If you watch this and get inspired, fire up Codex or Claude Code or your favorite coding model and join me on the moon.
Meta
Added: 2026-05-13