YT YouTube2Text

YouTube2Text → Transcripts → Your prompts kinda suck

Your prompts kinda suck — Transcript

by Theo - t3․gg · 6,814 words · 934 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Remember all the hype around prompt
0:01engineering, this idea that we would
0:03have to get really, really specific with
0:05our prompts in order to set our agents
0:06up for success? It would become this
0:08whole new fancy field and thing we'd
0:10have to study and become good at. Yeah,
0:12that's all crap. I'm not going to
0:13pretend otherwise. I'm not trying to say
0:15with this video that engineers need to
0:17do more engineering with their prompts.
0:19I'm actually here to say the opposite. I
0:21think that engineers suck at prompting,
0:24but I don't think it's cuz they're not
0:25engineering it enough. I think it's cuz
0:26they're over-engineering it, and they're
0:28not taking the opportunity that
0:30prompting offers us to take a step back
0:32and rethink how the computer can work
0:35for us. I'm thinking about a line
0:37between the two. What is prompting? What
0:39is engineering? And when does it make
0:42sense to do either or? But the biggest
0:45key thing I really want to emphasize
0:46with this video is the idea that most of
0:49us just aren't prompting hard enough.
0:51I'm still in the early days of this
0:53myself, and I've been helping a lot of
0:55the engineers in my personal life have
0:57this unlock by having like real
0:59conversations about what we're using AI
1:01for in our day-to-day, and I have just
1:03been amazed at how many people have not
1:05had that like first brain unlock of
1:08like, "Oh, the agent can do more." Just
1:11last week, I had almost this exact
1:13conversation with an engineer that just
1:15started a company and went through Y
1:16Combinator, and this convo changed how
1:19they think about their agents. And I'm
1:21realizing I need to take the time to try
1:23and explain this to all of you. To get
1:25out of your engineering box long enough
1:27to really think about how agents can
1:29benefit you in your day-to-day work.
1:31Whether this is with the things that
1:32you're building and coding or the ways
1:34you can use agents to help you in your
1:35day-to-day life, and so much more.
1:38This is a guide on how to prompt better
1:40and to get out of your engineering box
1:42in your brain. Because I know engineers
1:43really tend to love some things that we
1:45talk about, like today's sponsor. I
1:47don't know if you have noticed, but
1:48we've been shipping a lot lately.
1:49Staying on top of all of it is nearly
1:51impossible, and people always ask, "How
1:53am I able to do it without losing track
1:55of what's going on?" I don't think I'd
1:56be able to without today's sponsor,
1:58Macroscope. Not only have these guys
1:59built my team's favorite code review
2:01tool, they've built a lot of other
2:02things that are useful for me as I run
2:04the team. You can see what I mean right
2:06when I log in. This is the dashboard I
2:07land on when I go to Macroscope and it
2:09shows me who's working on what and gives
2:11me a summary of all of the things that
2:13we have been shipping recently. It's so
2:14convenient to have a view like this if
2:16you're trying to keep up with what your
2:17team is working on. You can see all my
2:19crazy work with the TypeScript Rust
2:20port. You can see all of the overhauls
2:21we've been doing on the T3 code client
2:23experience, how we changed the agent
2:24runtime, and finally landed Orchestrator
2:26V2. The tools I'm adding to Lakebed and
2:28the Web MCP layer, and all the other
2:30stuff we're working on. I even get a per
2:32contributor breakdown of who's shipping
2:34what and how much of the work they're
2:35doing is actually getting merged. My
2:37numbers are a bit bloated here,
2:38especially when you consider this is all
2:39from October 2nd and I'm filming this on
2:41October 6th, but this is cuz I have the
2:43autonomous thread currently landing a
2:45bunch of things in the Rust rewrite. I
2:47like these guys so much that I'm going
2:48to do a thing I haven't done in an ad
2:49for quite a while. We're going to
2:50actually look at some code in a real
2:52codebase. I'm doing this cuz with
2:54Macroscope, you can put the .macroscope
2:56folder in your project and find custom
2:58run agents that will run on pull
2:59requests looking for specific things. We
3:02had a lot of problems with people making
3:03new components instead of using existing
3:04ones in T3 code, so we spun up a UI
3:06consistency file. Okay, it is markdown,
3:09it's not real code. Sorry if you got
3:10baited.
3:11We define what it is, what model it
3:13uses, what tools it has, and what we
3:15want it to look for. And now we have
3:17this separate agent that will run in
3:19every PR that goes up as long as it's
3:21changing one of these files and it's
3:23excluding these ones as well cuz we
3:25don't want all of the TSX files to do
3:27this. If a change is just touching
3:29tests, I don't want to have to recheck
3:31it. Macroscope has made our team ship
3:32better code and has made me a better
3:33boss. Figure out why at
3:35swyx.io/macroscope.
3:37Okay, the sponsor break's over. It's
3:38time to get out of our engineering box
3:39for a bit. We need to live in a world
3:41where things like JavaScript and
3:43TypeScript don't exist, where we're not
3:45complaining about our apps using
3:46Electron and not using enough Rust and
3:48all those things. We need to lock in
3:51for the normie experience for a minute.
3:52We're going to start with one of my
3:54favorite XKCDs. The normie asks the
3:56engineer, "When a user takes a photo,
3:58the app should check whether they're in
4:00a national park." To which the engineer
4:03says, "Sure, that's an easy global
4:04positioning system look up. Give me a
4:06few hours." Like, yeah, you could use
4:08that to figure out where the locations
4:09are, make bounding boxes for the
4:12national parks that you care about, and
4:13then figure out if it's within that
4:15range. This is a type of LeetCode
4:16problem I've done enough times in my
4:17life. And then check whether the photo's
4:19of a bird. I'll need a research team in
4:215 years. Of course, this is pre-AI, cuz
4:23obviously there's a lot of vision models
4:24that can do this type of thing trivially
4:25now, but at the time that required a
4:28shitload of research. The reason this
4:30would have taken 5 years is cuz it would
4:32have required inventing AI to do it.
4:35Now that we have it, it's easier, but at
4:36the time it would have taken 5 years of
4:38research to do it. Normal people are not
4:41good at understanding how complex
4:44technical things are. But now we're on
4:46the opposite end here. Now we are too
4:49used to this, and we don't know what we
4:52can ask the agent for because we're
4:54always thinking in code. I'm going to
4:56get super literal here with an exact
4:59example. This is the convo I had with my
5:01friend a few days ago.
5:02Want to talk about tool calls in T3
5:05code.
5:06This is not a T3 code plug at all. In
5:07fact, it's quite the opposite in a lot
5:09of ways.
5:10I've been spending a lot of time
5:12recently using T3 code and other tools
5:15to audit all the things my agents have
5:17been doing on my machines. I noticed a
5:19few particular fail cases. For example,
5:22when I was doing these audits in my
5:23history, I learned that most of the
5:25failures that Claude had in tool calls
5:27were cuz it was trying to call Ripgrep
5:29with a syntax and a new line format that
5:31worked in Bash, but not Zsh, which meant
5:34that my Zsh installs, which were most of
5:37my Linux boxes and all of my Macs, were
5:39seeing higher error rates with Claude
5:41because the Claude model was writing
5:43these Bash commands in a way that wasn't
5:45compatible with Zsh. I brought this up
5:47with my friend who said something along
5:48the lines of, "Oh, that's super
5:49interesting. I've really actually wanted
5:51a feature for a while in T3 code where
5:54it will break down how long my tool
5:56calls take so I can figure out which
5:58tool calls are the slowest and the
6:00fastest, which commands are taking
6:01forever to run, so I can optimize my
6:04environment more.
6:05So, something along these lines. If
6:07you're a T3 Code user, the next
6:09statement I make will either not
6:11surprise you at all or surprise you a
6:13lot. My reply was,
6:15"We already have this."
6:17Not only do we have it, we actually have
6:19it in the mobile app, too. To which he
6:21was very surprised.
6:23So, I had him open his phone, and I went
6:24to the T3 Code app, and I showed him
6:26where it was.
6:28I'll show you here as well. I'm going to
6:29make a new thread without a project in
6:31order to show this to you.
6:32I'm filming, so I want it to be fast.
6:34So, I'm going to switch over to GPT-6
6:37Astra on ultrafast, so that this will go
6:39quicker. I think they're on a medium, so
6:41it doesn't matter that much.
6:42And I'm going to take what we said here,
6:44copy paste it, and now I'm asking it to
6:46break down all my tool calls, so I can
6:48find which ones are slowest and optimize
6:50my environment. I'll say in T3 Code,
6:53just to be clearer. I can even say on
6:55this machine, if that's what I care
6:56about. I could tell it about the other
6:57machines, too.
6:59And then I click send. And in
7:00approximately 3 minutes, hopefully less,
7:03cuz I'm running this on ultrafast, I'll
7:05now have a detailed breakdown of all of
7:08my tool calls and all of the things I've
7:10done with all of my agents on this
7:12machine. The point I'm trying to make
7:13here is a lot of engineers are still
7:16thinking about these workflows as
7:19features that need to be built into
7:21their products. We are used to needing
7:23to have the feature in the tool to get
7:26the thing from the tool. But now we can
7:28just ask it, and it's very different.
7:31I'm not saying that everyone should be
7:33adding their own features to T3 Code,
7:35although I do really want to get
7:36extensions and like internal forking
7:37working. I think that'll be really,
7:39really cool. I'm talking about features
7:41that aren't actually features. They're
7:43information. And if you can get that
7:44information other ways, then it doesn't
7:47need to be a feature. It should just be
7:49exposed in the ways that you need to do
7:51these cool things. And now I'm going to
7:53give an example of one I did wrong.
7:56There's a feature I've been working on
7:57on and off for T3 Code that is
7:59effectively an alternative dashboard for
8:00all your running work. That would have
8:02each task and what its current status
8:04is, and then agent that would go through
8:06all of them programmatically and tell
8:09you what its current status is and what
8:10it thinks you should do with it. It can
8:12rename threads, it can close threads, it
8:14can merge PRs, and it will say, "Here's
8:16the 40 threads you have. I think these
8:18eight should have the code merged and be
8:19closed. These 20 should be closed cuz
8:21they're useless now. And then I'm going
8:22to rename and recategorize the rest and
8:24you should send these prompts to them."
8:25I thought I was really smart and clever
8:27for coming up with this idea for a
8:28feature, a dashboard where you can
8:30control all of your runs and see them
8:32more clearly in one place. And then I
8:34kept adding more and more things to it.
8:36I kept adding new buttons for different
8:38things you might want to do, a button
8:39that would auto regen all of the titles,
8:41stuff like that. And I realized I could
8:43add all of these things for all the ways
8:45you would want to use this, or I could
8:47make this a chat instead. I could have a
8:50meta thread in T3 code that connects to
8:53all of your T3 code instances on all of
8:55your environments and let's you just ask
8:57for the thing you want. Want a nice
8:59dashboard? Tell it and it will make it.
9:01We now have the report. I didn't even
9:03tell it to make it a page, but it did
9:04for me. So now I have a report of all of
9:07my tool calls and how long they have
9:10spent running on this machine.
9:12Apparently, one home directory search
9:13lasted 41.7 minutes. Another lasted
9:17almost 10. Search the repository or
9:19known directory. Like this is useful
9:20info that I didn't have cuz I didn't ask
9:22this model in this way. But see it like
9:25how easily you can get useful info like
9:27this by just asking. Another one you'll
9:29ask a lot about is to break down how
9:31their context is being used in T3 code.
9:34So let's do that. Break down my current
9:36context window for this thread in T3
9:40code. Make a nice visual-
9:44lizer for it. And now I'm going to get a
9:46nice visual of how my context is
9:48currently being used. I know this
9:49example is going to work because I
9:51actually used it for a different video I
9:52was filming yesterday and that's how I
9:54learned due to the way my proxy is set
9:55up, Railway was dumping 70,000 tokens of
9:58context into every single request I
10:00made. We do have a button that shows
10:03your context usage that is hidden behind
10:05a legacy feature cuz we shouldn't have
10:06to think about these things. And I think
10:07the fact that I had a 70k token context
10:10thing at the front of all my prompts for
10:12the last 2 months and didn't even notice
10:15shows how little managing your context
10:17yourself matters at this point.
10:19Obviously, using Opus 5.5 on extra high
10:21is not going to get you the data or the
10:22feature you want immediately, but once
10:24you get in this mindset of like run the
10:25thing in the background and then let it
10:27pop up when it's ready, you realize that
10:30it doesn't matter that much how long
10:32things take as long as you don't expect
10:34it or need it immediately. But, the main
10:36thing I want to encourage here is
10:38thinking about the things you want and
10:40figuring out how you can get them
10:42without building them. Instead, asking
10:44for them. And I'm not just saying this
10:46because I want us to be lazy and use a
10:49bunch of tokens instead of being more
10:50efficient with code. It's actually quite
10:52the opposite. Once you realize there are
10:55things that would never have been worth
10:57building that do have some unique value
11:00to you right now, you suddenly start
11:02doing a lot more of them. Like I've
11:05created deep complex visualizers to help
11:08me think through one bug I was trying to
11:10solve. I built my own platform for
11:13managing my music listening history
11:15because I wanted it to be easier to
11:16combine my title data dump with my old
11:18Last.fm scrobbling data. These are all
11:21features that could be built into other
11:22products or products that I could build
11:24for myself, but I've learned to just
11:26treat them as prompts. And you'll be
11:29amazed how many useful things you can
11:31find and do if you start asking for them
11:33instead. If you channel and flash bang
11:36warning, the new one on the left here
11:39and their innocent ask for if
11:41something's a photo of a bird. Instead
11:42of asking me to build a feature in T3
11:45code, try asking for the outcome you
11:47want from your agent. And this applies
11:50best for the complaints people have
11:52about their agents. For example,
11:54somebody asked earlier for us to add a
11:56feature in the new T3 code orchestration
11:58layer to pick what sub agent your models
12:00will use. And it sounds like a great
12:02idea until you remember the model is
12:05what's choosing what sub agent to use.
12:07And you can just tell it not to just
12:09glaze T3 code here, but if I switch over
12:11to I don't know 61 Soul on medium fast,
12:15I can ask it spin up two Opus 5.5
12:20delegates to explore performance wins in
12:24T3 code, summarize their thoughts, and
12:28then start a new thread using Grok 4.7
12:32to implement your findings. And I can
12:35choose what computer to run on. I'll
12:36throw it on this laptop so we can
12:38actually see in so that Grok will work.
12:40And now my Codex sub is going to be used
12:43to start this work and it is going to
12:46call two instances of Claude code that
12:48will be contained within this thread.
12:50And then once it's done, it's going to
12:51make a new thread with the results. I
12:53could make a little additional drop down
12:55or even expand this one to have a
12:57different section that's like what sub
12:59agent should be used. But you can also
13:01just prompt it. Now we have these two
13:03delegates running and you can see here
13:04the Opus 5.5 server and client
13:06explorations are going because I told it
13:09to use those. I didn't select the sub
13:11agent model. I just said what I wanted.
13:13And if you find yourself saying the same
13:14thing over and over again, that's when
13:16you start adjusting your skills and your
13:17agent and Claude MD files. Oh look, the
13:19context window breakdown is done.
13:21So here we are. Instead of having to
13:23build a context window visualization
13:25feature into T3 code, I just asked and
13:28now I have the visualization. If there's
13:30things I want to change or questions I
13:31want to ask about or things I want to do
13:33from here, I can ask and have those
13:35changes made. And if it's useful enough,
13:38I can turn this into a skill that I can
13:40use again in the future. But that's all
13:42fine and dandy. I think I have mostly
13:44exhausted the first part of what I want
13:46to say here, which is about the
13:47prompting side and leaving the
13:49engineering box. But now I want to get
13:52into the real meat, which is what
13:53happens when we go back into the
13:55engineering box with this way of
13:57thinking. I have found that when I took
13:59this mindset back to my engineering work
14:02and my product building and making
14:04things in T3 code especially, it
14:06fundamentally changed how I think about
14:08what we add and how we add it. I'm going
14:11to show an example that I built because
14:13somebody was having some pretty severe
14:15issues specifically with T3 code on
14:17Windows where it was crashing a bunch
14:20and I was effectively writing prompts
14:21for them to use in Claude code on their
14:23machine to debug it. This inspired me
14:25enough to make a feature. I think one of
14:27the coolest things we have in T3 code is
14:29not actually in T3 code, it's in the T3
14:32CLI NPX T3 triage. This is a built-in
14:37triager that can be used to debug issues
14:40that you are having on your machine. And
14:43I put it in the terminal because I want
14:44it to work even if the desktop app is
14:47failing to open. So, you probably have a
14:48lot of ideas for what this is. I
14:50probably slopped up this crazy complex
14:52feature that connects to all the
14:54different edges of T3 code to figure out
14:56what's going on where like a doctor that
14:59pulls in all this data and makes best
15:01guesses on where the errors are.
15:03That's not what I did. Ready to see what
15:05it does? I'll press enter. I'll press
15:07yes cuz I haven't installed the latest
15:09stable build here.
15:10It asks if I want to use Claude code or
15:12code X. I will say Claude code.
15:15And then it pipes the prompt in to
15:19Claude code directly.
15:21And sends that prompt using your harness
15:24of choice. And then that prompt has very
15:27specific instructions in it. I can even
15:29show you guys those.
15:31A T3 code user is having a problem with
15:33their install and started this session
15:35with T3 triage. Machine facts. I say
15:40where the context is that I dumped when
15:42you ran the command which is just like
15:43basic data about T3 code on the machine.
15:46And then I tell the model to follow the
15:47playbook below.
15:49I tell it you're a support engineer
15:50working with us effectively working
15:52inside of a coding agent session to help
15:54debug things, unblock the user, and turn
15:56it into a well-written GitHub issue if
15:58one is warranted. Triage context file
16:00exists with all of these things. Here is
16:02what the agent has to do. I could have
16:04built a complex flow that inserts
16:08question one, then you answer, and then
16:10some hook comes in to ask the next thing
16:13or put it in the next stage. I was
16:14building all that. I found myself making
16:16a very elaborate T3 triage feature when
16:19I first started working on this.
16:21And then I realized the models are
16:23smart. They can do this, too. And
16:25instead, I put the whole flow that I
16:27want the user to go through in as a
16:30single giant prompt. First, it should
16:32ask what went wrong. The first message
16:33to the user should ask them to describe
16:35what went wrong in their own words as in
16:36they screenshot directly if they have
16:38any, ask follow-up questions when their
16:39descriptions are vague. Good repro steps
16:41are the most valuable thing you can
16:42extract from the convo. Then read the
16:44machine facts, check for a newer
16:46playbook. I actually have a publicly cuz
16:48it's open source anyways. I have the
16:50playbook linked in case it updates so
16:51that it gets new info if you're on
16:53nightly or whatever.
16:54Get the source cuz again, we're open
16:55source so we can clone the source to see
16:57if it can find the bug in the source
17:00code itself. Then it should investigate,
17:03check upstream to see if the bug is
17:04fixed and then offer outcomes to help
17:06the user,
17:07file the issue if there is an issue to
17:09file if it's not just a config issue on
17:11their machine, make sure you clean up
17:13all secrets or other data before you
17:14file issues with the data, and then
17:16prefer duplicates over new issues. So,
17:19go to an existing issue and comment
17:21there instead. This is all you need for
17:23a user to debug their problems. They run
17:26that one command, it throws them in
17:28Claude or Codex, and now they can fix
17:30their issue. This feature when I first
17:32started working on it was going to be
17:34thousands of lines of complex code. And
17:36then I realized it could be five lines
17:38of code and then 30 lines of markdown,
17:41and now it works way better. I can't
17:43tell you how much effort I was putting
17:44in trying to make pasting an image into
17:46T3 triage work so I could then route it
17:49properly before I realized like, "Oh, I
17:51can just have Claude or Codex ask you to
17:53paste the image instead. It's easier
17:55that way." Just run the command and then
17:57explain your problem to your agent. This
17:59is one of the two things I really wanted
18:01to push so you guys think this way
18:03because there's a lot of flows that are
18:05too dynamic, have too many branches, too
18:07many weird holes that a user can fall
18:10into to make a complex feature that
18:13supports everything they might need. If
18:15I knew all the ways T3 could fail, then
18:18I wouldn't need this feature at all cuz
18:19I would have just fixed it all. The
18:20reality is I don't. T3 code can and will
18:23have errors that prevent users from
18:25opening it, that prevent users from
18:27getting it working how they want. And
18:28having that just go through Quad Coder
18:31Codex instead makes it way more likely
18:33that when they hit those edges that they
18:35can be resolved without T3 code having
18:37the right feature to figure that out for
18:39them. So, if half the stuff we should be
18:41building should actually just be a
18:42markdown file instead, what's left to
18:45build? I don't know. Let's ask. I'll
18:47give an example of what I mean here. In
18:49this exact T3 triage window, I was
18:53having problems with a recent build
18:55flickering when I made new threads. I'm
18:58pretty sure it got resolved recently,
19:00but it was a lot of work because I don't
19:02think we log enough data around how the
19:05app itself is rendering. If I was to ask
19:08you to debug issues with rendering in T3
19:12code right now, is the data available to
19:14you to see what happened in the past? If
19:16not, how would you recommend we
19:18introduce that data so that you'll have
19:20more access to more useful info in the
19:22future? And I
19:24I do not get how people live in their
19:26terminals. I just voice to text it a
19:28paragraph and I can't read it. Get out
19:30of your [ __ ] terminals, guys. Get
19:32over yourselves. You're just wrong. It
19:33like I I was such a big terminal person.
19:36I can't do it anymore. I actually cannot
19:38do it anymore. Obviously, this is going
19:40to do a lot of additional steps because
19:42this is the whole triage flow, but
19:44eventually, it's going to tell me what
19:45it does and doesn't have access to and
19:47recommend things that I could expose.
19:49And I am regularly amazed at how few
19:51engineers realize they can do this.
19:53Here's another real example I did
19:55somewhat recently. I was trying to
19:57figure out what it would take to add
19:59more valuable computer use stuff to T3
20:01code, and I know the computer use in the
20:03ChatGPT Codex desktop app is great. So,
20:06I decided to just ask to describe in
20:09detail the computer use capabilities
20:10that you have access to. All of this
20:12info is in its context window. It's
20:14there, and now I'm asking it to give me
20:17the data and tell me what it is. And
20:20then I can use this info to go build it
20:22myself. And I was able to copy and paste
20:25its description of all the things it can
20:27do into Opus in T3 code and say, "Clone
20:30as much of this as you can." And it did.
20:32Still in a PR, we have some other fun
20:34plans, but like, do you know how cool it
20:36is that you can just ask it what it has
20:38access to? And if you notice it has less
20:41access than it does in a different tool,
20:43ask it to summarize the difference.
20:45Here's all of the capabilities it has.
20:46It can discover apps, it can open apps,
20:48it can read interfaces, it can see the
20:50interface to capture a screenshot
20:52instead of just getting the structured
20:53text data. It can use the mouse with
20:55click, double click, right click, drag,
20:56and scroll. It can use the keyboard. It
20:58can edit fields. It can use browser
21:00tabs, handle files, and even verify its
21:01results. It's able to read in two
21:03different ways through the accessibility
21:04tree as well as through screenshots. And
21:05now I have all this info about what it
21:08is able to do, and I got it from asking.
21:11And if you notice the model can't or
21:13doesn't do a thing you want, you can ask
21:15about that, too. Why didn't you add a
21:18screenshot to this PR? What tool would
21:20be helpful so you can add screenshots to
21:22future PRs? Why couldn't you figure out
21:25this bug? Why is this issue still
21:27happening? Can you run it yourself and
21:29figure out why this happened? Can you
21:31read through the transcript from this
21:32other thread and figure out what went
21:34wrong? You can prompt about your prompts
21:36and prompt about your programs. You can
21:37prompt about your systems. You can
21:38prompt about your questions. You can
21:40prompt about a whole lot of things that
21:41aren't engineering. I was prompting
21:43trying to collect all my MRI files for
21:45my doctors' websites. I could have built
21:47a program that would go through all the
21:49portals for all my doctors and collect
21:52and organize all the PDFs, or I could
21:54ask an agent to go do it. Apparently,
21:56this way of thinking is now brain rot. I
21:58would argue you'd say the same thing
22:01about email when it first happened.
22:02Like, "Why would you go to the doctors
22:05or send a letter? You can just email
22:08them." Well, that's silly. You're not
22:09going to get real advice from that.
22:11Well, yeah, there's a lot of things
22:12where it's a lot easier to send the
22:13goddamn email. And it's not that like,
22:15"I'm going to send the email and never
22:16see people again." It's I'm going to
22:18send the email for things that I
22:19wouldn't have went to go see. Do I spend
22:22less time hanging out with my friends in
22:23person than I did when the internet
22:26wasn't around when I was five. So
22:28amount, yeah, but I'm talking to 10
22:29times more people and most of those
22:31people are ones I never would have
22:33talked to cuz they weren't around before
22:34the internet and I had no way to reach
22:36to them. Similar with this. It's not
22:39that I am choosing to prompt instead of
22:41building, it's that I'm choosing to
22:42prompt the things I never would have
22:44bothered building. And then when I
22:46realize how powerful that is, I go one
22:47step further where I focus my building
22:50on creating the primitives and creating
22:52the workflows, the tooling, the
22:54pipelines, and the data pipes and access
22:58that my agents need so that my prompts
23:00can do more. And here is where we get to
23:02the silliest example by far that I I
23:04really think all of us need to do and I
23:07know a lot of us haven't yet. Y'all need
23:08to add your goddamn email to ChatGPT. I
23:11know this sounds insane. I put this off
23:13so long and I know it sounds even more
23:16insane that it changed my life how much
23:18it did, but it did. I have five inboxes,
23:21four of which I have to monitor
23:22actively. And I have spent so much time
23:25harassing the team at Superhuman to make
23:29it work the way it should. Superhuman
23:32was the best email client and it just
23:34just slowly rotted. And the Gmail
23:36website is garbage. Every other email
23:38app is even more garbage. I have been so
23:40close to making my own email app for
23:42like four years. I got close again
23:44recently. And when I hurt my hand and
23:47couldn't go through my email as easily,
23:49I begrudgingly tried the feature where
23:51you could link your emails, multiple of
23:52them at a time by the way, to my ChatGPT
23:54account. I went from checking my inbox
23:5710 times a day to like once-ish a day
24:01and now I just ask my agents instead.
24:04It's so much better. And now with tools
24:07like dot, I can tell it to watch out for
24:08a certain type of email. Like I could
24:10say, "Look out for emails from Amazon. I
24:13know that we're about to get a huge AWS
24:14bill." Or I can go even crazier. I can
24:17see the AWS bill email and ask my dot,
24:20"Hey, this seems really big. Can you go
24:23through my AWS dashboard and figure out
24:25why our costs are so high and help me
24:26reduce it?" And then have it spin up a
24:28bunch of other agents and other things,
24:30usually in my case T3 code. Now that
24:32I've connected the T3 code MCP to my
24:34Codex, I can have Codex and dots spin up
24:37Claude threads in T3 code. I've created
24:40the pipes to allow these things to
24:41connect and connected the data that my
24:44agents need to operate. And now I can go
24:46from it tracing an email for me to
24:49shipping real changes with other agents
24:51and other programs across my systems.
24:54And here is the craziest thing about all
24:57of this.
24:58Never felt more like an engineer. There
25:00were dips where this stopped. I've even
25:02been called out for some of these dips
25:04here and there. When you start to like
25:06glaze over the code and accept that the
25:08language being used or the frameworks
25:10being pulled in doesn't matter as much
25:11as it used to, you start to feel less
25:13like an engineer. These things you spent
25:15all of this time and all of your life
25:16caring so much about don't matter the
25:18way they used to and it sucks. But
25:20that's just the trough of despair
25:22because once you come out of that and
25:24you realize that for these agents to do
25:26the things we want them to, they need
25:29better systems to operate within. You
25:31realize that the clever [ __ ] that
25:34made me love engineering has never been
25:36more valuable. Silly things like
25:38realizing that question or that feature
25:40could just be a prompt. Things like the
25:42clever solution of adding a debug flow
25:45that just pipes you over to Claude code
25:47or Codex. Things like exposing your
25:49application's interface over MCP so
25:52other agents can access it and control
25:54it. Or adding web MCP to a dashboard you
25:57just built so that you can do more with
26:00it and access it in other ways.
26:02Engineering is so goddamn fun right now.
26:04I built like five Rust apps this year
26:06and have a way deeper understanding of
26:08modern memory management because I want
26:10to build for a future where our agents
26:13are running on computer that's
26:14effectively free cuz we can run it in
26:15isolates. And I have all of these crazy
26:18like out there engineering ideas that
26:21weren't possible because we didn't have
26:22the manpower to build them and they
26:24weren't particularly useful because
26:26there weren't enough writing code for
26:28these new primitives to be valuable to
26:30them. I'm solving these problems that
26:32didn't matter enough before and took too
26:34much effort to solve because suddenly
26:36the problem matters more and the
26:37solution's more accessible. And all of
26:39this comes back to the idea of throwing
26:42away the way we did engineering for many
26:44years in order to make better things
26:47with prompts, if I'm being real. And I
26:50cannot tell you how often I'm scrolling
26:52through the feature requests for T3 code
26:54or the issues we have on the repo or
26:56seeing the things people DM me that
26:57they're requesting. At least half of it
27:00is stuff that they could prompt for
27:01themselves. Not to extend T3 code, but
27:04just to use it. And this idea that a
27:06feature could just be the product itself
27:10and like the number of features that
27:11exist in T3 code because you can just
27:13ask your agent for it is crazy. But we
27:16have to build more primitives to expose
27:18those. For example, right now when I ask
27:21for a visualizer, it will give me an
27:23HTML page that I can open and go to,
27:25which is super cool and all, but I
27:27shouldn't have to leave T3 code to see
27:29it. I could open it in the in-app
27:31browser, which I actually have disabled
27:32for various silly reasons. Oh, there we
27:34go. Open in the integrated browser. Like
27:35I can do that here.
27:37But wouldn't it be nice if my agent
27:38could make its own visualizer in line?
27:41They have that in Codex. We don't have
27:43it in T3 code yet, but these additional
27:45primitives aren't new features in the
27:47sense it's not a new button the user
27:49clicks to do something. The point of
27:50this new tool would be to allow users to
27:53effectively build their own dynamic
27:55features. And that's a thing that I'm
27:58really excited about. The last thing I
28:00want to say is to the people who don't
28:02feel this right now, who do still feel
28:03like they're losing the thing they love
28:05and that engineering is getting less fun
28:06every day. I really do get it.
28:09Especially now that I've talked to more
28:10people who are in that boat. I
28:12legitimately think most of you are near
28:15the end of that piece though. Like if we
28:18did the curve of like how much do we
28:21feel like an engineer over time? When
28:23you first start, you probably don't feel
28:25very good. Then you start feeling pretty
28:26good about it. You realize you're
28:28actually kind of dumb. And then you
28:30slowly get better and better at it. Most
28:32of us have been through this already as
28:34engineers some amount, but now it's
28:36getting more screwed up because we kept
28:38getting better better engineering and
28:40then all of a sudden
28:42we felt this with AI. It's like the
28:44things I'm doing aren't solving complex
28:46systems or debugging code. Now I'm just
28:49sending prompts. But what you will
28:51realize over time is that the things
28:54that are worth building are much deeper
28:56and more complex now. I'm a product
28:59engineer. I build products that people
29:01pay money for with subscriptions and
29:03like make money through ad revenue. Hi
29:06y'all watching on YouTube. The problems
29:08that were worth me solving before were
29:10around how I would assemble pieces and
29:14how I would make user-facing solutions.
29:16Now I'm building my own operating system
29:19and my own compilers. Not because I
29:21never wanted to before and suddenly do.
29:24I'm doing it now because it makes more
29:26sense to. The problems that I could
29:28solve these ways matter more now and
29:31these are more viable to build now. So
29:34the incentive to build it has gone up
29:36and the complexity of what you can build
29:37alone has gone up. The amount of
29:39engineering I do on a given day is way
29:42way higher and the complexity of the
29:44problems I spend my time thinking about
29:45is way higher as well. Am I thinking
29:47about the details of every SQL query in
29:49my code base anymore? No, absolutely
29:51not. But am I thinking about how the
29:53connection method between the SQL
29:55database and the server layer works and
29:57if there are further ways I can optimize
29:59that and build my own connection layer
30:01to keep it warm without increasing my
30:03cost a bunch? Yeah, absolutely. Am I
30:05building my own tech stacks that you can
30:07run with NPX create T3 app right now?
30:11No. I'm building my own JavaScript
30:13runtime for my own cloud. I'm
30:15engineering harder than I've ever
30:16engineered and my brain is working
30:18harder than it's ever worked. If you see
30:21me scrolling past some cloud slop in a
30:24project that everything functions well
30:26and that's super well tested and think
30:28that I'm doing that cuz my brain rotted,
30:30you fundamentally don't understand how
30:32much more engineering work we can be
30:33doing. And I think a lot of the people
30:35critiquing AI developers for brain rot
30:38are doing so because they're here right
30:41now. And they feel awful because they
30:43had to spend their whole career getting
30:45to this high point that they were at
30:47before. They spent so much time getting
30:49themselves up to the point here. And
30:52then AI made it all feel worthless and
30:54useless and dumb. But once you get
30:56through that trough, once the valley of
30:59despair makes its way to the end, all of
31:02a sudden your brain's going to be
31:04working harder than ever. And I hope you
31:06all take the opportunity to rethink
31:07things and to live in this trough a bit.
31:10Spend some time down here. It sucks. It
31:12feels bad. It feels like everything
31:14you've done forever was worthless
31:15because the features you want to add are
31:16just prompts. They're not features. But
31:18once you hit the edge of that, when you
31:20see what the AI can do, you realize that
31:22there's so much more to build to get the
31:24most out of it. And that's how I want
31:26you all to think going forward because
31:28this was the unlock that got me so
31:29excited. Or you can go back to saying
31:31I'm paid off by OpenAI and that's the
31:32only reason I think this way. Sure,
31:34that's a lot easier for y'all and I
31:35can't wait for you to be unemployed if
31:36you keep thinking that way. But for
31:38everybody else that genuinely loves
31:39building, there has never been more to
31:41build and there's never been more reason
31:42to build it. Hopefully this inspires
31:43y'all. Go build something cool. And
31:45until next time,
31:46peace, nerds.

About this transcript

This page contains the full transcript of Your prompts kinda suck by Theo - t3․gg, generated from the public captions YouTube serves with the video. The transcript has 6,814 words across 934 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to choose a caption track available on the video.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, caption language selection, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.