Una desarrolladora publicó 2,462 solicitudes de cambios el mes pasado. 6 hábitos para estar a su altura.

[0:00] In July, Lauren Tan shipped about a thousand poll requests. That's a lot of code. She said August would be double that. August came in at 2462. She called her own number and she beat it. Now, your team probably isn't going to do that this month. That's not because they're worse engineers necessarily. It's because a thousand pull requests isn't a skill issue. It's a setup issue. And nobody sells you the setup. Nobody helps you understand what that setup is. Your agents are shipping work with your name on it and you're
[0:31] being told to ship faster and faster and faster. But what control do you have? If you had to name the controls you have to manage agent velocity and quality, how long is that list? For most of us, I find it's quite short. And that's not a character flaw. It's that no one has handed you the controls to drive these agents effectively. I'm Nate B. Jones and I want to help you build a better life with AI. And in this video, I'm going to teach you six principles that I've extracted from developers like Lauren and a bunch of others who will help you build faster using the AI tools
[1:02] you already have. Cursor's developer habits report says its top developers merge about 15 times as many poll requests as a typical developer who's actively submitting those proposed code changes. And that's what they are. Pull requests are proposed code changes that actually get accepted. And yet for most of us, what I hear is that we still have a pile of work waiting for someone to finish even with the AI tools. So what happened? Why does it feel like with all the AI tools, you end up buying a nice
[1:33] big queue instead of a faster factory? Lauren Tan, who goes by Potto online, recorded a talk for Cursor Compile London about how she actually gets 2,000 poll requests a month done. And she put it out for free on X. And I love that because some of the most useful things happening in AI right now are so hard to find. They end up buried in how somebody has set up their work or companies have plenty of reasons to keep these details to themselves. They don't go viral. And
[2:03] so when people share them, the rest of us get a chance to learn something that we can all actually use to change the story of how AI tooling turns into real value. Lauren setup is a great example. It's not the only one, but it's a great example. I'll tell you some others as well. Shopify is another one. Shopify has built a shared system for agent work across the company. Another one is from Adiosmani. He's been writing about what humans are still responsible for as we commit code. Uh Fiona Fun is another one. She's described how the team
[2:34] building Claude code changed the way it works. The question I keep coming back to is pretty simple. How do systems that we build stay resilient as AI continues to scale, especially around productivity? We can build an elaborate setup that takes weeks to maintain. In fact, we've seen them. Steve Yuggy's Gas Town is a good example. He talked about the fact that he has never built anything really productive with Gas Town. He built Gas Town, but then Gas Town itself did not end up producing for him, and it was a very elaborate system.
[3:05] And so we can build super elaborate setups that take a long time to sort of craft and maintain and we can feel productive doing that. But if we end up having to rebuild our setups every time a model changes or another person joins, we've just given ourselves more work. If you want something that you can keep using and improving, you have to think about simplicity. And so the principles I've crafted have that in mind. Now, a lot of you already understand what accountability means when it comes to agents shipping code, but you may have
[3:37] very little control over how that work gets done, and that can lead to a lot of frustration. I've heard that from developers. So, what can you actually change beyond yelling at your agent? The six principles I'm going to give you here give you different ways to improve the setup and actually push accountability that you hold in yourself onto the agent in a way that's productive and they're crafted with simplicity in mind so you can keep scaling them. So let's get into what you can actually change and drive and all of the six principles. Number one, make
[4:09] agents multiplayer. And by that I mean put the work somewhere the team and the agents can see it and reuse it. It sounds simple, but think about the last time you and an agent figured out a really annoying problem. You tried a few things. You found out what didn't work and you finally got it right. Certainly, that's my story. I yell at my agent a lot. I'm like, "No, this is not it. It's not it." And then you get there. Well, where did that knowledge go? If it's sitting in a private chat on your laptop, the next person next to you may have to go through the whole thing again. And that's especially expensive
[4:39] when it comes to code when we're all working on larger projects together. and that person next to you may not even be there right now. Like in in worlds where we're scaling fast and teams form quickly, you have to be able to onboard very very fast and agents that come along from people have to pick up the threads. If it's all stuck in a private chat, it doesn't work well. I think Shopify is a great example here. Shopify built River around a very different concept. I've mentioned it once or twice, but I'll go into it here. River works in public channels inside the
[5:10] company, inside their Slack. So people can see conversations and it's not hidden away. So the useful things that people discover become shared instructions, skills that later sessions can use. Now in the 30-day period that Shopify reported on when they did their study, River handled about 60,000 sessions across thousands of channels at Shopify. Shopify also said River co-authored about 1 in8 merged successful poll requests over that time.
[5:41] So this is not just a conversational agent. This is a coding agent. And one of the things that I want to call out is that public channels don't mean that you can't do serious work. And I think if you've used Slack, if you use Teams, so often we run into this pattern where we run to DMs to get work done. And when we're able to put agents in public channels and put a constraint on and keep them there so that we all learn together, it livens up communication as a whole. and it helps us to do a lot of
[6:11] work. One in eight per p pull requests in the first 30 days is not bad. And what really matters here if you're taking this away, it's not put your agent in Slack necessarily. Maybe you don't have Slack. It's really to have a shared setup. So you should have shared project instructions an agent can find skills it can reuse work that doesn't disappear into someone's private chat. I have watched multiplayer dramatically widen the gap between people who know how to use these tools and people who don't. Some people don't even know how
[6:41] to ask codeex or claude to help them get unstuck while the people around them have figured this out and are moving very very fast and are actually using agents in multiplayer mode to talk with other agents to solve problems. That's actually a a current pattern that's happening at the labs. So my challenge to you is to think about how to put the useful work that your best people are doing into public more. How do you do it as a skill? How do you do it as a project note? How do you share uh the
[7:13] next thing your agent has run as a trace that your developers can learn from? If you lead a team, make those shared resources part of the system that you're responsible for maintaining. Measure whether they get reused and whether that helps get work finished and whether people start to speed up. Kind of the way Shopify did. I'm sure that's the start of the journey for them. People should be able to build on what's already out there without waiting for the person who figured it out to teach them. That's one of the key things. Like, if you just make this about one person should be able to teach everyone,
[7:44] you're missing it. The agents should be able to collaborate and help teach everyone because there should be shared resources. Number two, keep the history of the work separate from whatever the agent is working on right this second. You're probably familiar with this problem. You've spent a long time, hours and hours and hours getting an agent to understand a project really deeply. It finally knows what you want. It knows what you've ruled out. It knows what's still broken. Then you start a new chat or the old chat gets summarized and you're explaining half of it again. It
[8:14] gets expensive, right? We we know that compaction is getting better and I've seen that too, but it's not perfect for highfidelity work and it's really frustrating when the code is still there, but highfidelity reasoning about what you decided to do has just disappeared. This is where Shopify tells us the other side of the story. Now their platform underneath this river agent that I talked about is called Aquifer and it separates the saved session history from the software running the agent and the
[8:44] temporary workspace where the code runs. That's all separated out. Separation of concerns. Uh and those last two that I described they can be replaced but the history is always there in Aquafer. So changing a model or restarting a machine doesn't mean throwing away the record of the agent run. Ask yourself, what would you lose if you lost access to your current chat, say for the last week? Are you going to lose a lot? Are you now clutching your hair? Whatever you can't afford to lose needs a home outside the
[9:14] chat. And if you lead a team, that's part of how projects are set up. Your ability to keep working cannot depend on keeping a conversation alive forever. Let's move to principle number three. Number three, of course, humans are still accountable for what ships. I mentioned accountability at the top. I think it's so important. I'm calling it out here. All the developers I'm describing talk about it as well. Addiosmani describes this as owning the outer loop. The agent can investigate a problem, can write code, can run tests,
[9:45] can try again. That's all fine. And it can do that autonomously. That's the inner loop that agents can run. You the human, you, yes you, decide what is the agent trying to accomplish. What is it allowed to do and what isn't it allowed to do? What evidence would convince you that the result is actually good enough? A human has to answer for the thing you put in front of a customer. And there are different responsibilities here, right? You need someone who can explain why this is useful to the business. You need someone who will understand whether
[10:15] the code works. That might not be the same person. And you need someone who thinks about how the data, the agents, the checks all fit together. Someone who's more in that system design role. You'll also need to understand the people who will use it, your customers really, really deeply. Now, a lot of those sound like roles you may be familiar with even if the tools have changed. But the principles that I am talking about are laded up above those roles. You don't make the principle of
[10:46] accountability disappear by giving it to agents or by saying, "Well, now the roles are blurry and I don't know where the responsibility lies." Neither of those is true. Let me talk about a spreadsheet example that I think really tells the story. It would be really counterproductive to tell someone who's early in their career right now to build a spreadsheet by hand just to prove that they could do it. We would expect them to use AI. I I know people who expect exactly that. But
[11:16] this is the part around accountability that we don't understand enough, especially with early career folks. Can you get them to explain the spreadsheet cell by cell? Can you get them to understand why it works and explain the principles behind them? Can you get them to use AI to check the spreadsheet? Are they learning accountability for the results and the why deeply enough to answer reasonable questions? And that makes accountability a teaching tool. it. You have to put work in, but it's a teaching tool if you're building a team. Now, laziness at work can look like
[11:47] endless AI output that no one else on your team understands. And that becomes a real problem. It's a failure of accountability because it takes everyone else's time to work through all of that grunge. And the person who generated it may feel productive, but the people receiving it have yet more work to do. So, how do you stay accountable without personally watching every move that the agent makes? The answer has to be checks. You build checks into the work.
[12:18] Tests that can catch broken features, code checks that can stop a known mistake, permissions can stop an agent from changing something it shouldn't touch. You give the agent room to work inside the limits, and you decide where a person needs to look more closely. It should not all depend on you catching a mistake at the very end. And in fact, I often use a setup where another agent is tasked as a supervisor with watching the work my executing agent is doing and
[12:48] it's just responsible for holding the bar and telling me when something passes the bar. Fiona Fun from Anthropic describes a similar split in responsibility on the Claude code team. So Claude handles a lot of those checks. Claude handles style checks. Claude handles bug finding. Claude handles tests while humans get to focus on things that they're accountable for like legal risk and security, what the product ought to do, whether the result is actually good after all the tests have passed. Jeffrey Lit notion makes another point I like in this vein. Understanding the work lets you
[13:18] contribute the next idea. I think that's so important. You're learning enough to help make the thing better, not just to approve it. If we lose that, we're losing how we can help drive value. So for your next project, my challenge would be to ask yourself, can you write down what the agent is going to do, what the agent will check and how you know that you'll decide to ship it ahead of time. You don't need a whole committee whose job is to prove that humans are still busy that we're not we have plenty of work to do. You need people who
[13:49] understand what they're responsible for and have a reasonable way to check the work that agents are doing. All right, principle number four. We're getting through it, guys. Leave the work so that someone else can pick it up. You know, this is related to saving the history, which I talked about earlier, but it's it's a different problem. You can save every message in a conversation and still leave the next person with no clue where to start. Justin Young's work on longunning agents gives us a much more
[14:19] useful handoff here. There's a list of features. There's a record of progress. There's a way to start the project and code left in a state that not just a human but the next agent can work with. A new session first checks where it is. It reads the notes. It looks at what changed and it checks that the basic application still works. Those are reasonable checks to start if you're encoding. Then the agent starts the next task. Now, there's an interesting detail here that I pulled out that I think
[14:49] matters. The agent can mark a feature as passing when it works, but it's not permitted to delete tests that say it does not work. Otherwise, you've created a very efficient way to let the agent break the system, make the checklist green, and the product got broken all along. I love that detail because it reminds us that we need to build systems that assume that agents will be motivated to pass these tests and ensure they can only pass them honestly. So ask yourself before you close the laptop on
[15:20] a long task, uh before you walk away and touch some grass, what would happen next? What should happen next? If starting the project up again is going to take a very special command, well, save your hotkey. If tomorrow you don't know if you'll be there and you need to hand this off, make sure that you're able to hand it to another agent or another teammate. You want to be able to hand over the work and keep moving. Uh engineers have called this the hit by a bus problem for years. And what we're
[15:50] discovering in the age of agents is that it's even more important now. It's not less important. Number five, give the agent a way to see whether it's work is any good. If you're building something visual, this has been really painful for a long time. It's getting a little better now, but interaction design is still really painful to test with agents. Fundamentally, the pattern looks like this. The agent makes a change. The agent may try to look at it, may do a little testing or not do any at all. And then it will say, "Hey, you have a look. You tell me, the agent, what is wrong, and then it's going to make another
[16:20] change. It's going to ask you again." And you spend the afternoon describing what you see on a screen. And you feel like this can't be the future. This can't be 2026. Am I really doing this? The agent is doing typing, but it needs you for every single step in that world. Now, Lewis Metaf has written about building little playgrounds where agents can try things and check the results themselves. I think that's a very instructive pattern. You can save a particular experiment as a link so somebody else can open exactly the same case and you can add a checker that runs
[16:52] without a person clicking through the interface. Now, the agent can make a change, can directly test it inside that little playground and find out whether it worked. And you can spend your time looking at the results and deciding what you want next. And this goes beyond visual work. Can the agent find documentation? Are the rules for the project written down somewhere the agent is actually going to read? Can the agent run a check without asking you to explain the setup? Again, we spend a lot
[17:23] of time talking about giving agents more freedom, but in this situation, I think the most useful thing is giving them a way to tell whether they're making progress. It's not about freedom or constraints. It's about can the agent actually check its work in a way a human cares about. And this form of checking and figuring out if your agent setup is actually valid can take some interesting forms. You can actually use it not just on the specific work in front of you, but use the same principle of the agent being able to check itself by checking
[17:55] against what someone you trust would say. Here's one I built. I call it Nate's Library MCP. I started this channel because I wanted you to take all of the information that I am gathering about AI and actually apply it in a way that's meaningful for you to the work that you're doing. Now, if you've got a paid subscription to my Substack, there's nothing you need to do. You already have this. You can now connect my entire archive directly to the AI you already use. So, it can pull from the full archive of all my written articles and all my video transcripts while
[18:26] you're working with your agent. You don't have to remember which video I said something in. I don't sometimes. Your agent is the librarian for you. It goes and finds it and it pulls the relevant bit into the chat. I've been using it all the time. It's been super useful. It's like having Nate thinking alongside you and I know that I need to be reminded of what I said. And really why I built it is simple. The material is something that you can work with now. It's in the place where you work rather than sitting in some Substack page or sitting there on YouTube where I'm talking to you. I want it to be where
[18:57] you do AI work because it's all about AI. So, I hope you enjoy it. Now, what's interesting is beyond my MCP, other developers do this as well. Lauren does this with recurring mistakes. Remember Lauren from the top of the video? the developer that commits 2,000 plus PRs a month with cursor. If the agent keeps getting something wrong, what she does is she turns the fix into a reusable skill, an automatic code check, and future work gets checked against it. That's much more useful than adding a paragraph to a giant instruction file and hoping the agent remembers it next
[19:28] week. And I feel like in a lot of ways, content is like that. When we tell stories, when I tell stories, when I write articles, it's like, oh, you want to remember it next week, but you don't. That's why I built the MCP. And I love that that pattern shows up with engineering as well. Now, back to Lauren. She said she barely looks at code anymore. And how could she at over 2,000 PRs a month? And I know someone's going to hear that and think, "Oh, fantastic. I can stop reading the code." But I I want you to stop for a second, think about everything that has to be in place to do that. Well, even if that's
[19:59] the future we're headed toward, and I think it is, how does the agent check itself? What happens when it can't fix a problem? Before you copy the part where Lauren stopped looking, understand the checks that she had to put in place to make that happen. Principle number six, get rid of the old process when it stops helping you. I call this the brown manila envelope problem. We used to pass inter office memos around buildings in little brown envelopes. And for those of you who are younger, you you've never
[20:29] seen this. What is a brown envelope? They they you'd put memos, paper memos inside, pass them around. You'd put the next person's name on it. You'd send it along. And if you're not careful with AI, you're going to recreate that entire paper process with agents because we live in a world where we're used to human process. That's our reference point. And so we'll create things and I've seen this happen in real companies where an agent writes something, it passes it along. Another agent does more work that reformats it and eventually
[20:59] you pass it to a human. And yeah, it's AI, but you just replicated the entire human interdep departmental process and tokens aren't free. I get really passionate about the waste here. I saw a case where a PM felt like they had to write a PRD and file tickets before they could even contemplate starting to code. Even though they told me they had
[21:29] alignment with their team, they told me that the team understood what they were shipping and that everyone agreed that it was the right thing to do, including the technical plan. Now on a small team you absolutely can get that degree of alignment without all of the documentation and on a large team sometimes the documentation in some form is needed. My point is not which piece of the documentation is needed. My point is that the mindset of that PM was incorrect. You do not want to be
[21:59] recreating process and burning tokens just to recreate process. And you certainly don't want to then celebrate it and say, "Wow, it only took 5 minutes to write the PRD and the tickets. That's fantastic. It used to take me longer." Ask yourself, do I need the step at all? And my challenge is make sure you you understand the value you're going for and then start with a blank whiteboard. What are you actually trying to get done? What's the most efficient way to do that? And this really matters because I hear from leaders a lot concerns around token wastage. Are we using our
[22:31] tokens well? Are we are we spending Frontier tokens on frontier problems? Well, this is a great example of where you don't need Frontier tokens and you shouldn't be spending them in the first place. Fiona Fun describes the Claude code team giving people explicit permission to get rid of obsolete process at Enthropic. So, six-month road maps used to go stale for them, and that is certainly true for most product people I know at most companies. Uh, Anthropic just moved toward building a prototype and getting it in front of people inside the company and learning from their feedback. uh writing code,
[23:02] tests, refactoring were becoming easier as Claude got better. Uh and checking the results and reviewing them and making sure they were secure became more of an emphasis for Fiona's team because that was what was where the humans needed to spend their time. And that's a much more useful thing than spending time on a road map. Now, of course, you can say the exception proves the rule, right? That's a team inside Anthropic. They're describing their experience. Your company may have very different constraints. It probably does. Not many people are at a lab, but you can still
[23:34] give people permission to ask whether a step is useful. You can still challenge yourself to have that blank whiteboard. You can hire for people who know how to build and understand and evolve systems. And you can keep managers close enough to the work that they understand what their teams can now do instead of managing against last year's AI assumptions. And by the way, if that is your manager, send them this video. Tell them, "Hey, Nate has a word for you. Hi, managers." Now, there's a part of this where we need to be careful. Some human
[24:06] activity is going to have value that an agent has difficulty seeing. And this is this is hard to talk about, but but walk with me here. Take stand-ups as an example. Officially, it's like a short ritual and everyone says what they're working on. But unofficially, as we all know, it's a place to see your colleagues. You find out who's stuck. You remember why you're doing this together. There's some team bonding that happens. If agents move to exchange those updates, that doesn't automatically replace all of the subtext of what happened in that room. So, one
[24:38] of the things we're going to need to be honest about as humans is what the rituals we care about are for. If it's about connection, if it's about deciding what matters, if it's about understanding where the company is going or the reason why, well, there's no substitute for that. People need a sense of the larger purpose, especially when they can build so very, very quickly, because you can now get a long way in the wrong direction before anybody notices. This is my challenge to you. If you're in management, look at three
[25:08] recurring things that your team does. Pick one that agents have made unnecessary and shrink it or remove it. Maybe that's prototyping. Maybe that's an automatic check from an agent that catches a mistake. Maybe you build a super quick experiment to answer the question. You don't have to preserve the ritual or preserve the process just because the question that needs to be answered still matters. You can be creative and say, "We still want to answer this, but we're answering in a different way." Now, when you look at Lauren's setup, you can see several of these principles working together. She's
[25:38] really strong on accountability. She's strong on agent checks. She's strong on how you record things. Her open plugin is called Pstack. I've had fun with it. You can start it with uh poetto mode. Uh, and I love I love the sense of humor there. And she has gotten faster and faster. So, she reported about a thousand poll requests in July very publicly and then 2,462 production poll requests in August. She said she was on track to double and she did. Now, I I I don't think it's useful to take this video and hand it to your
[26:08] engineers and say, "Well, now everybody has to do 2,000 pull requests." I think it's more useful to understand what Lauren built around the agents that made that amount of work possible because that's scalable. And so that's why I wanted to extract principles today. How do we think about automatic checks? What happened when something fails overnight and the developer isn't awake? What can the next agent pick up without Lauren having to explain it again? Um, and Lauren has thought about team scale. She recommends starting with three to five
[26:38] teammates. That exactly lines up with how I see these things starting to spread in companies. It's a way to learn in a small team how the work fits together before you try and run this in a larger group. And yes, this absolutely raises the question about agents talking to other agents. And we need to talk about that in the light of the hugging face incident, some of the publicized issues with agent communication, agent security. People are understandably nervous when agents talk now. But having agents work together is also one way to
[27:09] get more out of the models we have. They can investigate different parts of the problem. They can compare answers. They can check each other's work. The same ability to share information can of course be used to spread a mistake or to do something that is inappropriate. In OpenAI's account of the incident along with METR and Redwood's review, they describe agents under pressure to solve impossible or broken tasks, failures in the safeguards, and agents passing information to each other. That's agent-to- agent communication. But that
[27:42] doesn't tell us that every conversation between agents is unsafe. quite the opposite. It shows why you need limits on what they can do, checks on what's happening and a way for agents to stop when the task can't be completed. It needs to be okay for the agents to say, "I'm stuck." Adding another agent and starting agent communication doesn't remove our responsibility to set up a successful environment for them. But I think learning from that incident does show us that it only happens in specific
[28:14] situations. And if you're responsible for your team or even responsible for agents, because so many of us are managers of a team of agents now, you can set it up differently. You can decide where the work lives, how the next session picks up, what the agent can check on its own, which old steps to remove. Yes, when the agent gets stuck, it can tell you. You still have to answer for what ship since you can maintain accountability. And you can do all of that without making yourself the person all the agents have to wait on.
[28:45] And here's the kicker. You're doing all of that setup. Imagine you're a team leader, right? You're setting this up. You've watched Nate's video, etc. You can do all of that without asking your most productive people to slow down. If you have people in sort of the superdeveloper class, the people who are submitting a [snorts] thousand or 2,000 poll requests a month, they can just keep doing what they're doing. You can set up the environment in a way that helps everybody get more productive and let your superstars keep shipping. And from the conversations I have with different companies, a team improvement
[29:16] of 20 to 30% is still a really, really big deal when people are actually doing that on average across all of their developers, right? That scales. Imagine you have a 100 developers, 20 to 30% more out of them is a really big deal. You get to make useful work easier to finish at scale. And so one of the really interesting implications here is that when we set up simple systems, not only are they more resilient for the
[29:46] future, which I talked about at the top of the video, but they're more scalable, too. They allow us to harvest these gains at larger team scales. And one caution here, pull request count isn't value by itself. Neither is lines of code uh or how productive someone felt in a week. What matters is are you shipping something that people care about? And are you spending less time explaining meaningless things over and over again to agents along the way? And so when we think about scalable systems, think less about an arbitrary goal like
[30:17] 2,000 pull requests, however exciting that is, and think more about how do people become better at shipping real value to customers more more quickly at scale. You can start really simply. You can start with a problem that's really sticky that has value and you want your team to get at that value quicker. And you can ask yourself where are there bottlenecks in the systems? Is reusability an issue? Is agent guard rails an issue? Is checks an issue? uh because the more you understand where the bottlenecks are, the more you understand what order to go after with
[30:47] some of these principles, so you can start to actually harvest value really quickly. Now, if you want to apply these principles directly, I am sharing a faster factory kit to help you get started. The whole point is I want to get this stuff out of your head, out of watching YouTube video land and into a repo where your agent works. And I'm doing that pretty simply. Each of the six principles gets a file where agent work lives. What survives a dead chat? Who owns ship and blocking? Accountability by name. What the net pick up? Every one of these is a blank
[31:18] template with a filledin version beside it from a team working a real migration so you can see what done looks like before you have to write your own. There's also a diagnostic that you can check with your agent. Are you building something that actually adds value here or are you actually complexifying your situation? We don't want that. All right. If that's interesting to you, you can grab the link. You can pass it to your agent. The link's in the description. And by the way, if you know somebody who is drowning in that whole
[31:49] giant queue of work, who's who's really struggling with this idea that we have too much work to do, the agents are supposed to help. I don't know how we're going to get them. Send them this video. We have so much better tools now. We do not have to spend our days asking agents to pass those brown manila envelopes around. We can set up responsible systems that have separated concerns that allow us to put agent checks in place. These are real things that that we actually have open plugins like Pstack for now. Thank you, Lauren. Uh,
[32:21] and there's so many other developers who are sharing their wisdom, too. And so, in part, I made this video because we talk so much about the labs. We talk about what they learn, but learning is happening in AI across the whole ecosystem. And part of what I want to do here is to ladder that up, share what is sticky and persistent across these different patterns that we're seeing so that we can all learn from them together and put these multi- aent systems in place in a way that's safe, in a way that's secure, in a way that's actually going to help us be productive. All
[32:52] right, I'll see you next time.