← AI News & Strategy Daily with Nate B. Jones
AI News & Strategy Daily with Nate B. Jones
AI-Native Companies Run on Code: 15 Rules for Operators
00:17:52
The operators keeping up with AI move repeatable work into code and keep judgment human. 15 rules for what should become a system, and what shouldn't.
Loading summary
Transcript1 lines
- [00:00]
A
I couldn't not make this video. We have so much pain in front of us when we're trying to adjust to AI. I get so many questions about Nate. Why is my business moving slow and Anthropic is able to release like every week? I'll tell you the answer is relatively simple. I made this video to tell you why companies like Anthropic and OpenAI and small startups in the Valley are able to ship so, so fast. And why almost everybody else isn't able to use AI that way. What is their secret sauce? What is thing that they have? Hint. It's not AI. So in this video you are going to learn the 15 rules of the road that I use to help teams move toward that kind of fast shipping cadence. I think operators have a new job in the AI era. Move more of the company's repeatable human interactions toward code. They are changing where the company lives. They do it in different ways. Decisions that used to vanish inside meetings, for example, they become decision documents that people can refer to, but really that agents can act on. And that's a hint. Product managers who used to direct engineers through ticketing work now put things in the terminal and work with engineers directly there. Reviews, they become evals, repeated reminders. They become systems that agents can act on and build and improve on over time. Design gets into code, gets into the SDK in ways that it never did in the 2010s. Look, I'm not saying every human interaction moves into software. Trust stays human. Taste stays human. But a lot of the repeatable parts of coordination that we use to run our businesses can be moved toward code so we can speed up execution with agents. If every decision has to be re explained by a person, the humans become the rate limit on the business. And that is the distinguishing factor between companies like Anthropic and OpenAI that are shipping quick and companies everywhere else that are not shipping as fast. And that is why I've written 15 commandments to guide organizational change toward this kind of AI future. And I'm sharing them with you here today. They are actual commandments. I did have fun with this. I wrote thou shalt not language, et cetera. And I want to share them and discuss them because I want us to understand how together they form a system that we can use to move our organization toward a faster shipping cadence, toward a world where we all are able to move as quickly as these AI tools allow. Now, each of these 15 commandments exists because AI has changed the work underneath it. Some move coordination out of meetings and into durable systems. Some move product judgment closer to actually building. Protect the time now made more valuable by quick execution because the value of our time has shifted. And the rest protect human relationships that let a company operate at that speed with high trust. Together, we've got one intention. Find the point of greatest leverage for the business and for the humans involved in the business, and then move scarce human judgment to that point. The easiest analogy here is digital photography. Back when film cost money, and I remember those days, a family might take 24 pictures on a vacation or 48 pictures on a vacation. Somebody chose the shot, somebody waited for everyone to look at the camera. I remember that the price of film and the complexity of processing that film supplied a kind of discipline in how many images were produced. Digital photography completely removed that price barrier. And now you can have 40,000 pictures and six versions of the exact same sunset, and no idea where your kid's birthday went in that pile of 40,000 pictures. This is what AI has done to all of work. The cost of another draft, another prototype, another analysis, another piece of code is collapsing to zero. The old scarcity used to force choices, and a lot of our organizations are designed to force those choices. But when it disappeared, the choices did not become less important. They actually just became easier to avoid. Void. So an AI heavy company needs to answer two questions to successfully process this Volume one. What can we make now? What are we unwilling to spend time on, even if it's nearly free? Getting to these 15 commandments helps you answer those questions. Let's start with Commandment 1. Thou shalt not slow down engineering. Thou shalt go fast. I get that that sounds like what every Silicon Valley startup says. So let me be specific about what I mean. Speed is not asking people to work more with AI just for the sake of working with AI. Speed is really about accelerating learning loops. And learning loops are driven by what we can put in front of customers, which is driven by the code we can put together. The old process stretched the distance between these bets because every change consumed scarce engineering capacity. And the original question might have moved by then. I have been the product manager that launched something and the original question had changed, right? A lot of us have. AI has removed so much of the cost of the queue that the queue itself isn't really worth relevant anymore. And then we don't have issues with the queue and we can actually focus our time on saying, given this enormous engineering velocity that we're protecting, how do we build ambitiously to deliver extraordinary value to customers? So Commandment one puts Every other rule on trial. Does this meeting shorten the path from evidence to a better product? Does it shorten our learning loop if it doesn't get rid of it, does this document carry a decision if it doesn't get rid of it, does this approval actually catch a risk or is it just paperwork? Does this handoff improve the customer experience? Or is it not really working worth doing? If we cannot name the job that we're doing with the process around engineering and how it's actually delivering value in this world with an agentified development pipeline, then we're probably slowing down the process. The other scarce thing is distribution. Building something that nobody sees is still worth $0, just as it was 10 years ago. Cheap execution raises the premium on deciding what deserves to exist and getting the useful thing in front of the right person. To make it simple, I'm going to put these in clusters and I'm going to show you the rule. Clusters, the command clusters. Right? That matter the most. Why each one exists because of AI and why none of them is safe to copy alone. You need to go through all 15 because they are a system that works together. Let's take the most provocative cluster first. Commandment 3 product does not make roadmaps. Commandment 5 product does not control or direct engineering time. If I just stop there, I would not have a radical new operating system for building companies. I would just have a good way to produce confusion, right? But now we live in a different world. AI has driven the cost of building to zero. So what does that mean for us? In Roadmap world, a team can now put a working version in front of a customer before the old roadmap meeting would have found a free hour on everyone's calendar. And I'm not kidding. With tools like 5.6 Ultra. With tools like Fable 5, with a multi agent system like Ringer, which I talked about this week, you can get an entire product out there before two days from now when you have the meeting. But that doesn't remove the need for product judgment. Instead, it removes the need for product to stay out of the code. So Commandment four goes with Commandment. Commandments three and five. It says products shall be in the terminal daily. You will get into the code one way or another. Commandment 6 is in the same cluster. It says products shall sit with engineering and jam daily. But you take on the obligation as a PM to sit in the work, touch the material, bring the customer and make decisions while the thing is becoming real. Remember, I started by saying you don't slow down Engineering getting PM into the code, getting product to jam with engineering on the code so that we are focused on the artifact that's being produced for the customer. That is what enables us to do good product thinking without slowing down the whole train. And I want to make something clear. The core questions these job competencies need to answer aren't changing. Engineering still has to answer, does this code work and will it keep working? And that is a high bar. And a lot of teams are using AI to slip by on that product. Still has to answer, should this exist and does anybody care enough to use it? Same terminal. Maybe you're in the code base together, different questions. And that's why Commandment 13 matters. Act like all that matters is one profoundly helpful and delightful customer experience. You are doing the coordination work that all of the roadmap process used to do. Commandment 12 gets at this. It broadens out the product surface for design. Design is in the code, right? The terminal is a design space. The SDK is a design space. So is the UI when a payment fails and the error tells the customer exactly what to do next. Somebody designed fallback experience when an agent reaches a permission boundary. Yes, we're designing for agents now and explains what it needs to do instead of failing silently. Someone designed that agentic experience. A designer who only designs screens is now designing the lobby while the rest of the building gets built without them. We don't want to be in that position because we need the questions design asks all the way through our technical systems. I don't see a world where we aren't using design. I see a world where design is overemployed because there's so many more surfaces that need good design input. So these different commandments I mentioned, these rules of the road, they form one system. If you remove roadmaps, you have to have a system for replacing distant coordination with daily contact, clear accountability and a customer experience that's concrete enough that you can judge. And you need to be able to do all of that in real time. That's what that whole cluster of commandments is all about. So here's our writing system. Commandment 2 says no meetings longer than an hour. If that forces documentation, that is the point you want want to be prioritizing documentation because increasingly we have agents that need to have feedback on the things we discuss in meetings. Writing is a forcing function for agents. And this gets to Commandment 11, which talks about documentation as code. I mean that more literally than I would have meant it even a year or so ago. Agents read documents and they use them to decide what to do. A document can supply the standard, the source hierarchy, the permissions, the escalation path, the definition of done. If you have ambiguous documents, you are just spreading chaos through that system. You need to obsess over your documents so that they are clear. Otherwise you're just pushing that chaos downstream. And that's actually the risk of AI slob. I don't care if you say you're absolutely right in a document. I do care if you know what's in it. I care if you understand what you're trying to accomplish with that document. And so often when people sit down to write, they don't have that clarity. And what comes through is AI slot because the human clarity isn't there. There's no substitute for that. I want to be really clear about that. There's no substitute for that. I learned the discipline behind writing at Amazon long before the current agent wave. We had to type everything by hand like troglodytes. I once got to 57 drafts of a six page narrative in product. We had a culture of learning to write from one another. We would take lunches and sit down and review docs together because that helped us make our own docs better and it helped us to critique others, it helped us to ask questions better. It led to a stronger document culture that should not die. We don't all need to adopt the exact same document standards as Amazon, but we all need to care about our writing that much. In the age of agents, we need to treat the clarity of intent we communicate through writing with that degree of rigor. And this is where we get to Commandment 7. So Commandment 7 talks about killing monthly meetings. We want to be in a place where we are auditing our regular time commitments and we are allocating more time to building because as I discussed earlier in this video, it's an incredible time to build. We have so much leverage in building if we have ambition, if we have alignment. And if you're wondering, I did actually build a tool for this. I built a tool to help you audit your meetings. Because this is something that is personal to me. I want to make sure we use our time well. If we're going to have meetings, I want them to be effective. So. So if that's you, if you want to use your time better, I've got a tool for you. There's a link below. We can get into it. So that's the writing cluster. We talk about the quality at which we need to write, we talk about our Time commitment. We talk about how we spend time in meetings, we talk about where we go with writing so we can save time in meetings. And you can see how this all adds up to thinking about intent. Are we communicating intent clearly in meetings? Are we communicating intent clearly in writing? The third cluster is a behavioral cluster. It's for us humans. It's about making the speed of AI survivable for human cultures and teams because it is a big change. So Commandment 8 talks about staying flexible to deliver value like water over stone. They're able to adapt. I think that's especially important. I know you've seen that in business books. But the reason that matters in the age of AI is because we are communicating and writing more. We're used to talking face to face. We now have more value on those face to face meetings. And it's really important that the writing level up and that we assume best intent. There's no reason, no matter what your level is, to moan or complain. And the reason why is that we all have access to an incredible amount of intelligence and tooling to build solutions. We should be in a position, regardless of our level in the business where we can either directly fix the problem we're worried about or propose a fix and propose a complete fix. And that gets a Commandment 14, which talks about building with a team. You do not build alone. And this is somewhat controversial. I know that there are entire startups out there that are all about the one person, billion dollar company. I believe enduring businesses are built with teams. They may not be as large as they were in the past because we can do so much with a small team that's well coordinated, but great. Small teams build incredible things. And they're building together because building together enables us to catch each other's mistakes, to clarify intent for AI and ultimately to build more effectively for customers. Find a community. Doesn't have to be mine. Find somebody else's community, that's great, but find a community. Teamwork matters because cheap individual output is not the same as making something that people want. One person and one agent can produce an enormous amount of material, but they still need all of us working together to get to taste and domain knowledge and customer connection and brand and willingness to say that this doesn't work and have some courage to actually confront that. And there's one more commandment I want to bring up here that's in this cluster of adjusting to our world of AI. I call it the teaching commandment. It's about helping folks along who are not going as fast and learning from folks who are going faster. That is how we all get faster together. It's true in organizations. If you don't have an organization or if you want to learn from others, it's true outside in Internet communities as well. Now, before we close, there are two common ways to ruin this whole concept. And the first is partial adoption. If you only take the no roadmap rule, for example, but you don't get your PMs into the code, all you're doing is producing chaos. And one of the things I see in the journey of adoption for a lot of firms outside the Valley is that they don't realize that they have to actually do this process all at once or it's going to fail and it's going to be painful. But it's easier to adjust to it if you set out the entire expectation set. Why am I talking about all these at once? It can be overwhelming to get 15 of these rules and be like, oh my gosh, it's too much. But I want to let you know that I'm sharing them all at once because the teams that I see that are successfully accelerating cadences aren't biting this off piece by piece. They are actually looking at this as an interconnected systems where humans need to change, clarity of intent needs to change around writing, and getting into the code needs to change. The way you get into the code needs to change. And so there is no substitution. And that's why I want to call out two failure modes that I see. One of them, as I'm kind of hinting, is just taking a part of this. Oh, you know what, Nate, you're right. We should get better at no meetings. That's not going to get you where you are to go. You actually have to look at the whole system as a way of building human infrastructure to accelerate moving the company toward a code focused, agent focused reality. You are moving more of the company into code so that agents can operate against it, so you can get higher quality, faster results. That's really what this is all about. And so a lot of the root of why OpenAI and Anthropic are shipping faster is because they have had this culture, they are are teaching this culture, they are inculcating this culture and they are hiring for this culture. And so they're reinforcing it as they go and it's speeding up. It's like everyone they hire at Anthropic is expecting this kind of speed now. And that makes it so much easier than coming into a company where everyone expected quarterly releases and trying to get them to speed up. There is a massive culture change, and that is part of what is going on. And that is why I keep saying, you gotta have this whole conversation and be willing to move. Move the whole business forward. Okay. If you want to dive into this much more deeply, I have a whole substack article on this that you can dig into. There's obviously the calendar tool that I built for this, and I have, of course, a companion guide that you can run through, feed to your agent, and actually build a complete change management process for you, for your company, for your team, whatever scale you're at. Because I want to make this easy. I want you to be able to apply this in a way that's useful for you. You. This video is a starting point. This video should get you thinking about what it really takes to transform in the age of AI. I hope it does. I hope you had fun. I hope you're excited for it. There's a whole discussion on that coming on Monday.