Make Your Prompts Dumber Transcript, AI Summary & Key Points

00:00 Remember all the hype around prompt engineering? This idea that we would have to get really, really specific with our prompts in order to set our agents up for success. It would become this whole new fancy field and thing we'd have to study and become good at. Yeah, that's all crap. I'm not going to pretend otherwise. I'm not trying to say with this video that engineers need to do more engineering with their prompts.

00:19 I'm actually here to say the opposite. I think that engineers suck at prompting, but I don't think it's because they're not engineering it enough. I think it's cuz they're overengineering it and they're not taking the opportunity that prompting offers us to take a step back and rethink how the computer can work for us. I'm thinking about a line between the two.

00:37 What is prompting? What is engineering? And when does it make sense to do either or? But the biggest key thing I really want to emphasize with this video is the idea that most of us just aren't prompting hard enough. I'm still in the early days of this myself and I've been helping a lot of the engineers in my personal life have this unlock by having like real conversations about what we're using AI for in our day-to-day and I have just been amazed at how many people have not had that like first brain unlock of like oh

01:09 the agent can do more. Just last week, I had almost this exact conversation with an engineer that just started a company and went through Y Combinator. And this convo changed how they think about their agents. And I'm realizing I need to take the time to try and explain this to all of you to get out of your engineering box long enough to really think about how agents can benefit you in your day-to-day work.

01:31 Whether this is with the things that you're building and coding or the ways you can use agents to help you in your day-to-day life and so much more. This is a guide on how to prompt better and to get out of your engineering box in your brain. Because I know engineers really tend to love some things that we talk about, like today's sponsor. I don't know if you all have noticed, but we've been shipping a lot lately.

01:50 Staying on top of all of it is nearly impossible, and people always ask, "How am I able to do it without losing track of what's going on?" I don't think I'd be able to without today's sponsor, Macroscope. Not only have these guys built my team's favorite code review tool, they've built a lot of other things that are useful for me as I run the team. You can see what I mean right when I log in.

02:06 This is the dashboard I land on when I go to macroscope and it shows me who's working on what and gives me a summary of all of the things that we have been shipping recently. It's so convenient to have a view like this if you're trying to keep up with what your team is working on. You can see all my crazy work with the TypeScript Rustport. You can see all of the overhauls we've been doing on the T3 code client experience, how we've changed the agent runtime and finally landed orchestrator v2, the tools I'm adding to

02:26 lake bed and the webmc layer and all the other stuff we're working on. I even get a per contributor breakdown of who's shipping what and how much of the work they're doing is actually getting merged. My numbers are a bit bloated here, especially when you consider this is all from October 2nd and I'm filming this on October 6th. But this is cuz I have the autonomous thread currently landing a bunch of things in the Rust rewrite.

02:45 I like these guys so much that I'm going to do a thing I haven't done in an ad for quite a while. We're going to actually look at some code in a real codebase. I'm doing this because with macroscop you can put the macroscope folder in your project and define custom run agents that will run on pull requests looking for specific things. We had a lot of problems with people making new components instead of using existing ones in T3 code.

03:04 So we spun up a UI consistency file. Okay, it is markdown. It's not real code. Sorry if you got baited. We define what it is, what model it uses, what tools it has, and what we want it to look for. And now we have this separate agent that will run in every PR that goes up as long as it's changing one of these files and it's excluding these ones as well because we don't want all of the TSX files to do this.

03:27 If a change is just touching tests, I don't want to have to recheck it. Macroscope has made our team ship better code and has made me a better boss. Figure out why at soy.link/microscope. Okay, the sponsor breaks over. It's time to get out of our engineering box for a bit. We need to live in a world where things like JavaScript and TypeScript don't exist, where we're not complaining about our apps using Electron and not using enough Rust and all those things.

03:49 We need to lock in for the normie experience for a minute. We're going to start with one of my favorite XKCDs. The normie asks the engineer, "When a user takes a photo, the app should check whether they're in a national park." To which the engineer says, "Sure, that's an easy global positioning system lookup. Give me a few hours." like, yeah, you could use that to figure out where the locations are.

04:09 Make bounding boxes for the national parks that you care about and then figure out if it's within that range. This is a type of lead code problem I've done enough times in my life. And then check whether the photos of a bird. I'll need a research team in 5 years. Of course, this is preI cuz obviously there's a lot of vision models that can do this type of thing trivially now, but at the time that required a shitload of research.

04:27 The reason this would have taken 5 years is because it would have required inventing AI to do it. Now that we have it, it's easier. But at the time it would have taken 5 years of research to do it. Normal people are not good at understanding how complex technical things are. But now we're on the opposite end here. Now we are too used to this and we don't know what we can ask the agent for because we're always thinking in code.

04:54 I'm going to get super literal here with an exact example. This is the convo I had with my friend a few days ago. I want to talk about tool calls in T3 code. This is not a T3 Code plug at all. In fact, it's quite the opposite in a lot of ways. I've been spending a lot of time recently using T3 Code and other tools to audit all the things my agents have been doing on my machines.

05:18 I noticed a few particular fail cases. For example, when I was doing these audits in my history, I learned that most of the failures that Claude had in tool calls were because it was trying to call rip grep with a syntax and a new line format that worked in bash but not zshell, which meant that my zshell installs, which were most of my Linux boxes at all of my Macs, were seeing higher error rates with claude because the claude model was writing these bash commands in a way that wasn't compatible with zshell.

05:45 I wrote that with my friend who said something along the lines of, "Oh, that's super interesting. I've really actually wanted a feature for a while in T3 code where it will break down how long my tool calls take so I can figure out which tool calls are the slowest and the fastest, which commands are taking forever to run so I can optimize my environment more.

06:04 So something along these lines, if you're a T3 code user, the next statement I make will either not surprise you at all or surprise you a lot. My reply was, we already have this. Not only do we have it, we actually have it in the mobile app, too. To which he was very surprised. So, I had him open his phone and I went to the T3 Code app and I showed him where it was.

06:27 I'll show you here as well. I'm going to make a new thread without a project in order to show this to you. I'm filming so I want it to be fast. So, I'm going to switch over to GPT6 Astra on ultra fast so that this will go quicker. I can throw it on mediums. Doesn't matter that much. And I'm going to take what we said here, copy paste it. And now I'm asking it to break down all my tool calls so I can find which ones are slowest and optimize my environment.

06:50 I'll say in T3 code just to be clearer. I can even say on this machine if that's what I care about. I could tell it about the other machines too. And then I click send. And in approximately 3 minutes, hopefully less cuz I'm running this on ultraast. I'll now have a detailed breakdown of all of my tool calls and all of the things I've done with all of my agents on this machine.

07:12 The point I'm trying to make here is a lot of engineers are still thinking about these workflows as features that need to be built into their products. We are used to needing to have the feature in the tool to get the thing from the tool, but now we can just ask it and it's very different. I'm not saying that everyone should be adding their own features to T3 code, although I do really want to get extensions and like internal forking working.

07:38 I think that'll be really really cool. I'm talking about features that aren't actually features. They're information. And if you can get that information other ways, then it doesn't need to be a feature. It should just be exposed in the ways that you need to do these cool things. And now I'm going to give an example of one I did wrong. There's a feature I've been working on on and off for T3 Code that is effectively an alternative dashboard for all your running work that would have each task and what its current status

08:02 is and an agent that would go through all of them programmatically and tell you what its current status is and what it thinks you should do with it. It can rename threads. It can close threads. It can merge PRs and it will say here's the 40 threads you have. I think these eight should have the code merge and be closed. These 20 should be closed cuz they're useless now.

08:21 and then I'm going to rename and recategorize the rest and you should send these prompts to them. I thought I was really smart and clever for coming up with this idea for a feature, a dashboard where you can control all of your runs and see them more clearly in one place. And then I kept adding more and more things to it. I kept adding do buttons for different things you might want to do, a button that would auto regen all of the titles, stuff like that.

08:41 And I realized I could add all of these things for all the ways people want to use this or I could make this a chat instead. I could have a meta thread in T3 code that connects to all of your T3 code instances on all of your environments and lets you just ask for the thing you want. Want a nice dashboard? Tell it and it will make it. We now have the report.

09:01 I didn't even tell it to make it a page, but it did for me. So now I have a report of all of my tool calls and how long they have spent running on this machine. Apparently one home directory search lasted 41.7 minutes. Another lasted almost 10. search the repository or a known directory like this is useful info that I didn't have because I didn't ask this model in this way but see like how easily you can get useful info like this by just asking another one you'll ask a lot about is to break down how their context is

09:32 being used in T3 code so let's do that break down my current context window for this thread in T3 code make a nice visualizer for it and now I'm going to get a nice visual of how my context is currently being used. I know this example is going to work because I actually used it for a different video I was filming yesterday and that's how I learned due to the way my proxy is set up.

09:55 Railway was dumping 70,000 tokens of context into every single request I made. We do have a button that shows your context usage that is hidden behind a legacy feature because we shouldn't have to think about these things. And I think the fact that I had a 70k token context thing at the front of all my prompts for the last two months and didn't even notice shows how little managing your context yourself matters at this point.

10:17 Obviously using Opus 5.5 on extra high is not going to get you the data or the feature you want immediately. But once you get in this mindset of like run the thing in the background and then let it pop up when it's ready, you realize that it doesn't matter that much how long things take as long as you don't expect it or need it immediately. But the main thing I want to encourage here is thinking about the things you want and figuring out how you can get them without building them.

10:44 Instead, asking for them. And I'm not just saying this because I want us to be lazy and use a bunch of tokens instead of being more efficient with code. It's actually quite the opposite. Once you realize there are things that would never have been worth building that do have some unique value to you right now, you suddenly start doing a lot more of them.

11:04 Like I've created deep complex visualizers to help me think through one bug I was trying to solve. I built my own platform for managing my music listening history because I wanted it to be easier to combine my title data dump with my old last FM scrabbling data. These are all features that could be built into other products or products that I could build for myself, but I've learned to just treat them as prompts.

11:28 And you'll be amazed how many useful things you can find and do if you start asking for them instead. If you channel, and flashbang warning, the noob on the left here, and they're innocent ask for if something's a photo of a bird. Instead of asking me to build a feature in T3 code, try asking for the outcome you want from your agent. And this applies best for the complaints people have about their agents.

11:52 For example, somebody asked earlier for us to add a feature in the new T3 code orchestration layer to pick what sub aent your models will use. And it sounds like a great idea until you remember the model is what's choosing what sub aent to use. And you can just tell it not to just glaze T3 code here. But if I switch over to, I don't know, 61 soul on medium fast, I can ask it spin up two opus 5.5 delegates to explore performance wins in T3 code, summarize their thoughts, and then start a new thread using Grock 4.7 to

12:32 implement your findings. And I can choose what computer to run on. I'll throw it on this laptop so we can actually see and so that Grock will work. And now my codeex sub is going to be used to start this work. And it is going to call two instances of cloud code that will be contained within this thread. And then once it's done, it's going to make a new thread with the results.

12:53 I could make a little additional drop down or even expand this one to have a different section. It's like what sub aent should be used. But you can also just prompt it. Now we have these two delegates running. And you can see here the Opus 5.5 server and client explorations are going because I told it to use those. I didn't select the sub agent model.

13:11 I just said what I wanted. And if you find yourself saying the same thing over and over again, that's when you start adjusting your skills and your agent to cloudmomd files. Oh, look. The context window breakdown is done. So here we are. Instead of having to build a context window visualization feature into T3 code, I just asked and now I have the visualization.

13:29 If there's things I want to change or questions I want to ask about or things I want to do from here, I can ask and have those changes made. And if it's useful enough, I can turn this into a skill that I can use again in the future. But that's all fine and dandy. I think I have mostly exhausted the first part of what I want to say here, which is about the prompting side and leaving the engineering box.

13:49 But now I want to get into the real meat, which is what happens when we go back into the engineering box with this way of thinking. I have found that when I took this mindset back to my engineering work and my product building and making things in T3 code especially, it's fundamentally changed how I think about what we add and how we add it. I'm going to show an example that I built because somebody was having some pretty severe issues specifically with T3 code on Windows where it was crashing a bunch and I was

14:20 effectively writing prompts for them to use in cloud code on their machine to debug it. This inspired me enough to make a feature. I think one of the coolest things we have in T3 code is not actually in T3 code. It's in the T3 CLI. NPXT3 triage. This is a builtin triager that can be used to debug issues that you are having on your machine. And I put it in the terminal because I want it to work even if the desktop app is failing to open.

14:47 So, you probably have a lot of ideas for what this is. I probably slopped up this crazy complex feature that connects to all the different edges of T3 code to figure out what's going on where like a doctor that pulls in all this data and makes best guesses on where the errors are. That's not what I did. Ready to see what it does? I'll press enter. I'll press yes because I haven't installed the latest stable build here.

15:09 It asks if I want to use cloud code or codeex. I will say cloud code. And then it pipes the prompt in to quad code directly and sends that prompt using your harness of choice. And then that prompt has very specific instructions in it. I can even show you guys those. A T3 code user is having a problem with their install and started this session with T3 triage machine facts.

15:37 I say where the context is that I dumped when you ran the command, which is just like basic data about T3 code on the machine. And then I tell the model to follow the playbook below. I tell it you're a support engineer working with us effectively working inside of a coding agent session to help debug things, unblock the user, and turn it into a well-written GitHub issue if one is warranted.

15:58 Triage context file exists with all of these things. Here is what the agent has to do. I could have built a complex flow that inserts question one, then you answer, and then some hook comes in to ask the next thing or put it in the next stage. I was building all that. I found myself making a very elaborate T3 triage feature when I first started working on this.

16:20 And then I realized the models are smart. They can do this, too. And instead, I put the whole flow that I want the user to go through in as a single giant prompt. First, it should ask what went wrong. The first message to the user should ask them to describe what went wrong in their own words. Ask them to paste screenshots directly if they have any.

16:38 Ask follow-out questions when their descriptions are vague. Good repro steps are the most valuable thing you can extract from the convo. Then read the machine facts. Check for a newer playbook. I actually have a publicly because it's open source anyways. I have the playbook linked in case it updates so that it gets new info if you're on nightly or whatever.

16:53 Get the source because again we're open source. So it can clone the source to see if it can find the bug in the source code itself. Then it should investigate, check upstream to see if the bug is fixed, and then offer outcomes to help the user. File the issue if there is an issue to file, if it's not just a config issue on their machine, make sure you clean up all secrets or other data before you file issues with data.

17:14 And then prefer duplicates over new issues. So go to an existing issue and comment there instead. This is all you need for a user to debug their problems. They run that one command, it throws them in cloud code or C codeex and now they can fix their issue. This feature when I first started working on it was going to be thousands of lines of complex code and then I realized it could be five lines of code and then 30 lines of markdown.

17:41 And now it works way better. I can't tell you how much effort I was putting in trying to make pasting an image into T3 Triage work so I could then route it properly before I realized like, oh, I can just have Claude or Codex ask you to paste the image instead. It's easier that way. Just run the command and then explain your problem to your agent. This is one of the two things I really wanted to push so you guys think this way because there's a lot of flows that are too dynamic, have too many branches, too many weird

18:08 holes that a user can fall into to make a complex feature that supports everything they might need. If I knew all the ways T3 code could fail, then I wouldn't need this feature at all cuz I would have just fixed it all. The reality is I don't. T3 code can and will have errors that prevent users from opening it, that prevent users from getting it working how they want.

18:27 And having that just go through cloud code or codeex instead makes it way more likely that when they hit those edges that they can be resolved without T3 code having the right feature to figure that out for them. So if half the stuff we should be building should actually just be a markdown file instead, what's left to build? I don't know. Let's ask.

18:47 I'll give an example of what I mean here. in this exact T3 triage window. I was having problems with a recent build flickering when I made new threads. I'm pretty sure it got resolved recently, but it was a lot of work because I don't think we log enough data around how the app itself is rendering. If I was to ask you to debug issues with rendering in T3 code right now, is the data available to you to see what happened in the past?

19:14 If not, how would you recommend we introduce that data so that you'll have more access to more useful info in the future? And I I do not get how people live in their terminals. I just voice a texted a paragraph and I can't read it. Get out of your [ __ ] terminals, guys. Get over yourselves. You're just wrong. It like I I was such a big terminal person.

19:36 I can't do it anymore. I actually cannot do it anymore. Obviously, this is going to do a lot of additional steps because this is the whole triage flow, but eventually it's going to tell me what it does and doesn't have access to and recommend things that I could expose. And I am regularly amazed at how few engineers realize they can do this. Here's another real example I did somewhat recently.

19:54 I was trying to figure out what it would take to add more valuable computer use stuff to T3 code. And I know the computer use in the chatgbtcodex desktop app is great. So, I decided to just ask to describe in detail the computer use capabilities that you have access to. All of this info is in its context window. It's there and now I'm asking it to give me the data and tell me what it is.

20:19 And then I can use this info to go build it myself. And I was able to copy and paste its description of all the things it can do into Opus in T3 code and say clone as much of this as you can and did. Still in a PR. We have some other fun plans, but like do you know how cool it is that you can just ask it what it has access to? And if you notice it has less access than it does in a different tool, ask it to summarize the difference.

20:45 Here's all of the capabilities it has. It can discover apps. It can open apps. It can read interfaces. It can see the interface to capture a screenshot instead of just getting the structured text data. It can use the mouse with click, double click, rightclick, drag, and scroll. It can use the keyboard, can edit fields. It can use browser tabs, handle files, and even verify its results.

21:01 is able to read in two different ways through the accessibility tree as well as through screenshots. And now I have all this info about what it is able to do. And I got it from asking. And if you notice the model can't or doesn't do a thing you want, you can ask about that, too. Why didn't you add a screenshot to this PR? What tool would be helpful so you can add screenshots to future PRs?

21:21 Why couldn't you figure out this bug? Why is this issue still happening? Can you run it yourself and figure out why this happened? Can you read through the transcript from this other thread and figure out what went wrong? You can prompt about your prompts. You can prompt about your programs. You can prompt about your systems. You can prompt about your questions.

21:39 You can prompt about a whole lot of things that aren't engineering. I was prompting trying to collect all my MRI files for my doctor's websites. I could have built a program that would go through all the portals for all my doctors and collect and organize all the PDFs. Or I could ask an agent to go do it. Apparently, this way of thinking is now brain rot.

21:56 I would argue you'd say the same thing about email when it first happened. Like, why would you go to the doctors or send a letter? You can just email them. Well, that's silly. You're not going to get real advice from that. Well, yeah, there's a lot of things where it's a lot easier to send the goddamn email. And it's not that like I'm going to send the email and never see people again.

22:16 It's I'm going to send the email for things that I wouldn't have went to go see. Do I spend less time hanging out with my friends in person than I did when the internet wasn't around when I was five? Some amount? Yeah, but I'm talking to 10 times more people and most of those people are ones I never would have talked to cuz they weren't around before the internet and I had no way to reach to them.

22:37 Similar with this. It's not that I am choosing to prompt instead of building. It's that I'm choosing to prompt the things I never would have bothered building. And then when I realize how powerful that is, I go a step further where I focus my building on creating the primitives and creating the workflows, the tooling, the pipelines, and the data pipes and access that my agents need so that my prompts can do more.

23:00 And here is where we get to the silliest example by far that I I really think all of us need to do, and I know a lot of us haven't yet. Y'all need to add your goddamn email to chat GPT. I know this sounds insane. I put this off so long and I know it sounds even more insane that it changed my life how much it did, but it did. I have five inboxes, four of which I have to monitor actively.

23:22 And I have spent so much time harassing the team at Superhum to make it work the way it should. Superhum was the best email client and it just just slowly rotted and the Gmail website is garbage. Every other email app is even more garbage. I have been so close to making my own email app for like four years. I got close again recently. And when I hurt my hand and couldn't go through my email as easily, I begrudgingly tried the feature where you could link your emails, multiple of them at a time, by the way, to my CHBT

23:55 account. I went from checking my inbox 10 times a day to like once a day. And now I just ask my agents instead. It's so much better. And now with tools like dot, I can tell it to watch out for a certain type of email. Like I could say, "Look out for emails from Amazon. I know that we're about to get a huge AWS bill." Or I can go even crazier. I can see the AWS bill email and ask my dot, "Hey, this seems really big.

24:20 Can you go through my AWS dashboard and figure out why our costs are so high and help me reduce it?" And then have it spin up a bunch of other agents and other things, usually in my case, T3 Code. Now that I've connected the T3 code MCP to my codeex, I can have codecs and dots spin up cloud threads in T3 code. I've created the pipes to allow these things to connect and connected the data that my agents need to operate.

24:44 And now I can go from it tracing an email for me to shipping real changes with other agents and other programs across my systems. And here is the craziest thing about all of this. Never felt more like an engineer. There were dips where this stopped. I've even been called out for some of these dips here and there. When you start to like glaze over the code and accept that the language being used or the frameworks being pulled in doesn't matter as much as it used to, you start to feel less like an engineer.

25:14 These things you spent all of this time and all of your life caring so much about don't matter the way they used to. And it sucks. But that's just the trough of despair because once you come out of that and you realize that for these agents to do the things we want them to, they need better systems to operate within, you realize that the clever [ __ ] that made me love engineering has never been more valuable.

25:36 Silly things like realizing that question or that feature could just be a prompt. Things like the clever solution of adding a debug flow that just pipes you over to cloud code or codeex. things like exposing your application's interface over MCP so other agents can access it and control it or adding web MCP to a dashboard you just built so that you can do more with it and access it in other ways.

26:01 Engineering is so goddamn fun right now. I built like five Rust apps this year and have a way deeper understanding of modern memory management because I want to build for a future where our agents are running on compute that's effectively free because we can run it in isolates and I have all of these crazy like out there engineering ideas that weren't possible because we didn't have the manpower to build them and they weren't particularly useful because there weren't enough engineers writing code for these new

26:28 primitives to be valuable to them. I'm solving these problems that didn't matter enough before and took too much effort to solve because suddenly the problem matters more and the solutions more accessible. And all of this comes back to the idea of throwing away the way we did engineering for many years in order to make better things with prompts if I'm being real.

26:48 And I cannot tell you how often I'm scrolling through the feature requests for T3 code or the issues we have on the repo or seeing the things people DM me that they're requesting. at least half of it is stuff that they could prompt for themselves, not to extend T3 code, but just to use it. And this idea that a feature could just be the product itself and like the number of features that exist in T3 code because you can just ask your agent for it is crazy.

27:14 But we have to build more primitives to expose those. For example, right now when I ask for a visualizer, it will give me an HTML page that I can open and go to, which is super cool and all, but I shouldn't have to leave T3 code to see it. I could open it in the inapp browser, which I actually have disabled for various silly reasons. Oh, there we go.

27:34 Open integrated browser. Like, I can do that here, but wouldn't it be nice if my agent could make its own visualizer in line? They have that in codeex. We don't have it in C3 code yet, but these additional primitives aren't new features in the sense it's not a new button the user clicks to do something. The point of this new tool would be to allow users to effectively build their own dynamic features.

27:54 And that's a thing that I'm really excited about. The last thing I want to say is to the people who don't feel this right now, who do still feel like they're losing the thing they love and that engineering is getting less fun every day. I really do get it. Especially now that I've talked to more people who are in that boat. I legitimately think most of you are near the end of that piece though.

28:17 Like if we did the curve of like how much do we feel like an engineer over time? When you first start, you probably don't feel very good. Then you start feeling pretty good about it. You realize you're actually kind of dumb and then you slowly get better and better at it. Most of us have been through this already as engineers some amount, but now it's getting more screwed up because we kept getting better and better engineering and then all of a sudden we felt this with AI.

28:42 It's like the things I'm doing aren't solving complex systems or debugging code. Now I'm just sending prompts. But what you will realize over time is that the things that are worth building are much deeper and more complex. Now I'm a product engineer. I build products that people pay money for with subscriptions and like make money through ad revenue.

29:05 Hi y'all watching on YouTube. The problems that were worth me solving before were around how I would assemble pieces and how I would make userfacing solutions. Now I'm building my own operating system and my own compilers. Not because I never wanted to before and suddenly do. I'm doing it now because it makes more sense to the problems that I could solve these ways matter more now and these solutions are more viable to build now.

29:32 So the incentive to build it's gone up and the complexity of what you can build alone has gone up. The amount of engineering I do on a given day is way way higher and the complexity of the problems I spend my time thinking about is way higher as well. Am I thinking about the details of every SQL query in my codebase anymore? No, absolutely not. But am I thinking about how the connection method between the SQL database and the server layer works?

29:57 And if there are further ways I can optimize that and build my own connection layer to keep it warm without increasing my cost a bunch. Yeah, absolutely. Am I building my own text stacks that you can run with npx create t3 app right now? No. I'm building my own JavaScript runtime for my own cloud. I'm engineering harder than I've ever engineered and my brain is working harder than it's ever worked.

30:18 If you see me scrolling past some cloud slop in a project that everything functions well in that's super well tested and think that I'm doing that because my brain rotted, you fundamentally don't understand how much more engineering work we can be doing. And I think a lot of the people critiquing AI developers for brain rot are doing so because they're here right now and they feel awful because they had to spend their whole career getting to this high point that they were at before.

30:46 They spent so much time getting themselves up to the point here and then AI made it all feel worthless and useless and dumb. But once you get through that trough, once the valley of despair makes its way to the end, all of a sudden your brain's going to be working harder than ever. And I hope you'll take the opportunity to rethink things and to live in this trough a bit.

31:10 Spend some time down here. It sucks. It feels bad. It feels like everything you've done forever was worthless because the features you want to add are just prompts. They're not features. But once you hit the edge of that, when you see what the AI can't do, you realize that there's so much more to build to get the most out of it. And that's how I want you all to think going forward because this was the unlock that got me so excited.

31:29 Or you can go back to saying, "I'm paid off by OpenAI. That's the only reason I think this way." Sure, that's a lot easier for y'all, and I can't wait for you to be unemployed if you keep thinking that way. But for everybody else that genuinely loves building, there has never been more to build and there's never been more reason to build it. Hopefully this inspires you all.