Everything we knew about software has changed — Theo Browne, @t3dotgg ​

AI Engineer · 16 min · 247 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

  1. 00:01[music]
  2. 00:17Hello, hello.
  3. 00:18Fantastic to see you guys here.
  4. 00:20I still can't believe they're letting me take a stage at something like this, a YouTuber apparently, but can't wait to share a bit about how I've been thinking because if I'm being real,
  5. 00:31kind of going through some AI psychosis.
  6. 00:33Who here would classify how they feel right now as some form of AI psychosis?
  7. 00:37I want to see some hands.
  8. 00:39The Those who don't have their hands up yet, don't worry.
  9. 00:42We'll get you there by the end of this talk if I do everything right.
  10. 00:45In order to talk about this, I want to start with a bit of a personal journey of my own.
  11. 00:49And I'm going to go through this the way anybody does in modern timelines, with the models.
  12. 00:54Who here used Sonnet 3.5 when it was the creme de la creme, the cream of the crop model available to us?
  13. 01:01It was unbelievably better than what we had used before, right?
  14. 01:04Like having used all of these different models and trying them in tools, Sonnet 3.5 was a big moment for me because it felt like these models could suddenly complete much more end-to-end
  15. 01:14tasks, like actually get real work done that takes multiple steps.
  16. 01:18And then we got Opus 4.5. Who felt or I'll go a different way differently here.
  17. 01:23Who didn't feel a big jump when they switched over to Opus 4.5?
  18. 01:28That's a relief.
  19. 01:28There were not too many hands because Opus 4.5 is probably when my psychosis started in November and December of last year.
  20. 01:34Having a model that couldn't just write the code and call tools, but could go way further.
  21. 01:39A model that could test the work and actually get it into a good state and complete tasks that take hours instead of minutes.
  22. 01:46It was unbelievable.
  23. 01:48And then we got Mythos.
  24. 01:49Who here has had a chance to play with Mythos and Fable so far?
  25. 01:54We agree it's a pretty damn good model, right?
  26. 01:57But why?
  27. 01:58It's not just better at coding.
  28. 01:59If you handed a prompt that you would have handed to these other models before, it's not going to feel that different.
  29. 02:05I think of these almost as eras now, where Sonnet 3.5 is the tool call era.
  30. 02:09Not that it was the first model that could do tool calls, rather it was the first one that did them consistently and reliably enough in context of a code base where you could use this for day-to-day coding work.
  31. 02:20Then we got Opus 4.5, which was able to do much longer running tasks without losing track of what it's working on.
  32. 02:26It's no longer, "Okay, build step one."
  33. 02:28and then it does it.
  34. 02:28Then you say, "Okay, can you build this next part?"
  35. 02:30and then the next part.
  36. 02:31You can just tell it what you want, and it could figure it out a lot of the time.
  37. 02:35Mythos is another jump to orchestration.
  38. 02:39It feels to me like it's the first model that doesn't just understand your code base, but it understands itself.
  39. 02:44And it knows how to spawn additional models and break up work in a way where it could be completed more reliably and then verified afterwards.
  40. 02:51And if you tell the model to do that, it will just do it.
  41. 02:53You don't need some custom tooling, some custom system, some fancy software factory.
  42. 02:58You just need to prompt it to go a little further.
  43. 03:00I think you'll be surprised how far it can go.
  44. 03:03What I'm trying to say here is we need to go bigger.
  45. 03:06You're not going to see the benefits going forward if you're not pushing the model further, you're not pushing yourself further with what you're building.
  46. 03:12Most of the Jira tickets I closed in my previous job could be trivially solved with a model like Opus 4.5. My previous work would not benefit from a model like Mythos.
  47. 03:22If the models are going to keep getting better, and at this point I'm confident saying we they I was wrong when I claimed that we were hitting a wall before.
  48. 03:29The models are getting better faster than we are.
  49. 03:31So, we can't necessarily get better.
  50. 03:33So, instead we have to go bigger.
  51. 03:35In order to do that, we have to get over ourselves.
  52. 03:37This was really hard for me as someone who spent a long time writing software.
  53. 03:42Who here has written code for more than 10 years?
  54. 03:45I want to see hands.
  55. 03:46That's the majority of the people here.
  56. 03:49I don't want to think about how long I've been writing code for.
  57. 03:51But I have been building up all of these strong opinions since I started.
  58. 03:55I was using GNU screen and eventually tmux back in the day.
  59. 03:59I learned how to use those tools and SSH and get before I even wrote code.
  60. 04:02And those have all been really ingrained in my workflow.
  61. 04:06I think back to the old days in a weird way.
  62. 04:09Hear me out.
  63. 04:10Let me talk about iOS for a second.
  64. 04:12Who owned an iPhone back when they looked like this?
  65. 04:15iOS 6 or earlier?
  66. 04:17How have you guys written code for 10 years when a fourth of you are that old?
  67. 04:21I'm confused.
  68. 04:22Hopefully, you're all Android people or something.
  69. 04:25This is how iPhone apps used to look.
  70. 04:28You might notice it's different from how they look now.
  71. 04:30It looks less like an app and more like somebody took a picture of a compass and put it in the phone.
  72. 04:35This is how apps used to look.
  73. 04:38But, now they look like this.
  74. 04:40And most people look at that and they're like, "Oh, that's an obvious downgrade.
  75. 04:44That's so much worse.
  76. 04:45Why would Apple ever do that?
  77. 04:46This is the downfall of Apple and the beauty of their design."
  78. 04:49I'm going to fight you guys on that.
  79. 04:51iOS 7 was Apple moving away from trying to convince you that these devices can replace the old tools we used to rely on.
  80. 05:00The compass had to look like a compass because the compass had to replace the physical compass that you relied on.
  81. 05:07The books app had to look like a bookshelf with real pages that turned because I had to convince you it was a reasonable alternative to buying a book and reading the paper version.
  82. 05:17Apps had to be designed to convince you to use them, not to be useful.
  83. 05:22And iOS 7 represents the shift to not focusing on convincing you anymore.
  84. 05:28Apple won.
  85. 05:29By that point, everyone knew their iPhone could do all of these different things.
  86. 05:32The point of iOS 7 was to stop convincing and start embracing.
  87. 05:37Start making a better interface.
  88. 05:38And this interface, as much as we might not like how it looks, it's so much more useful.
  89. 05:42You have clear indications of the difference between what direction you're you're on and where you're currently pointing.
  90. 05:46That red block is a super nice way to know that you're not in the direction you intend.
  91. 05:51The current direction you're facing is way clearer, too, with the giant 228 at the bottom.
  92. 05:56You just get way more info here than you did before.
  93. 05:59It's so much clearer.
  94. 06:01Even if we don't like it because it's not the thing we're used to, we got over it.
  95. 06:08We're currently in our skeuomorphic phase as software developers.
  96. 06:11Skeuomorphism is this design aesthetic trying to represent the way things used to look, the physical goods that we relied on, and try to make them digital.
  97. 06:21We're doing this right now with software.
  98. 06:23We're pretending our terminals are the ultimate interface when they're not even good interfaces.
  99. 06:27And I'm saying this as someone who loves their terminal deeply.
  100. 06:30Natural language has no place in a terminal, but we pretend it does because the terminal's familiar.
  101. 06:35It's what we It's what we're used to.
  102. 06:37It's what we love.
  103. 06:37It's where we like to think of ourselves when we're thinking about coding.
  104. 06:41Who here's an aspiring Vim user that like wishes you could use Vim, or even does?
  105. 06:47I know we've all had that Vim phase where we all tried.
  106. 06:51This is just how we are as devs.
  107. 06:52We care so deeply about these things.
  108. 06:54We care so deeply about our tools, the systems we pick, the frameworks, the languages.
  109. 06:58We like to think it all matters.
  110. 07:00And we've blinded ourselves in this.
  111. 07:02We think things that just don't make sense when you take one step back.
  112. 07:06Like, why can't we commit our environment files?
  113. 07:10It sounds stupid when I put it on a slide like this, but I want you to really think about this for a second.
  114. 07:14When I have a team of engineers that are working on a project, why do I have to build another system to share this specific file, but all the other files can go and get just fine?
  115. 07:24It's dumb.
  116. 07:25It's just how Git was built because it was built for a very specific thing, and then it took over our industry, and it took over our brains, and we aren't letting go of that.
  117. 07:33There's a lot of these things in our heads that we have to start fighting.
  118. 07:38We have to take the step back and think, is this how we do things cuz it's right, or is this how we do things cuz it's just how we've always done it?
  119. 07:46And as you start to think more about this, you'll realize there are so many things that we do this with.
  120. 07:51Like, why do we qualify ourselves by the languages we know?
  121. 07:55I used to think this was a junior thing.
  122. 07:56Like, I could can't tell you how many times I had a junior engineer I was talking to who was like, "Oh, you're a coder?
  123. 08:00What languages do you write?
  124. 08:01I write JavaScript."
  125. 08:02I thought this was a junior problem, but then you talk to senior engineers who are like, "Oh, he writes JavaScript.
  126. 08:06He's not a real developer."
  127. 08:08We care too much.
  128. 08:09We pride ourselves in these things.
  129. 08:11They're our identity.
  130. 08:12These weird facts, these weird choices, these things that feel essential just don't matter that much anymore.
  131. 08:20And they didn't then, and they matter less now.
  132. 08:22We got away with it because it was so hard to find engineers that we could just tell the company what we were doing, and they couldn't really say no cuz the alternative is spend 6 months trying to hire someone else.
  133. 08:31They're not going to do that.
  134. 08:33And along that note, why are we so scared of deleting code?
  135. 08:37I cannot tell you how many times I've been in a conversation with someone where the solution is to just delete it and reset, but we have such a bad sunk cost
  136. 08:47mindset in this industry.
  137. 08:49We care so much about the code we wrote, and we care so much about it still being there that I feel bad working with my team sometimes when somebody files a PR that isn't quite the right solution, but they spent a week or two on it.
  138. 09:00Like, who here has guilt merged a PR before?
  139. 09:02Where you just felt bad because somebody put a lot of work in, it's not quite the right thing, but you merge it anyways cuz the alternative was a conversation you didn't want to have.
  140. 09:12Why do we do this to ourselves?
  141. 09:14One of the nice things about ages you don't have to feel bad when you shut down their work, but we we just care too much.
  142. 09:20It's the point I'm trying to make.
  143. 09:21And the things we care about are not necessarily the things that matter anymore, and I hope we can finally start to challenge some of these.
  144. 09:29Going to get a little more personal here by showing some of the ideas I've built cuz the goal here is that when you guys go out of this talk,
  145. 09:36you have a better mindset for coming up with ideas that make sense now by rejecting the things that made sense before.
  146. 09:44These are three of the things that I have built or are currently working on.
  147. 09:47We're going to go from the bottom up.
  148. 09:49I built a Reddit scraper because making good memes is hard and I would rather just steal them from Reddit and went pretty well.
  149. 09:55It was a side project.
  150. 09:56It would take me two to three days.
  151. 09:57Would just scrape Reddit, top posts on programming humor, put them in a nice format for me so I could go copy paste them onto Twitter.
  152. 10:04Zoom for streamers was a startup I went through Y Combinator with.
  153. 10:07It was called Ping.
  154. 10:08I wanted to make it easier for live content creators to do high-quality collaborations in the software they already used, OBS.
  155. 10:15The full stack cloud is let's just imagine Vercel, but it goes further each direction.
  156. 10:20They have off built in, but they also have databases built in.
  157. 10:22These are all things I've wanted that I benefit from existing, enough so that I tried to build all of them.
  158. 10:29The bottom two I built in 2021.
  159. 10:31The top one I'm working on right now.
  160. 10:33These are also kind of tiers, different levels that we can build at.
  161. 10:38If I was to try and categorize them, I would call the bottom one side project, call the middle one startup, and call the top one too big.
  162. 10:46It just doesn't make sense.
  163. 10:48Well, this is how I would have categorized this even just a year ago.
  164. 10:52But things have changed.
  165. 10:54Now that the models are bigger, the tiers have shifted.
  166. 10:58Everything is now one tier lower.
  167. 11:02And this is a crazy thing for me to process.
  168. 11:04The fact that what used to be a startup is now a side project.
  169. 11:08In fact, some of the startups I've talked to even at an event like this, their whole startup could have arguably been a side project or this bottom tier, which there's a weird gap there.
  170. 11:17What's that?
  171. 11:18It's the G brain tier.
  172. 11:19It's a markdown file.
  173. 11:21Do you know how many companies are at this event where their whole product could just be a markdown file?
  174. 11:27It's insane.
  175. 11:28[applause]
  176. 11:28And like, okay, seriously though, the fact that you can now execute markdown by just piping it to Codex or Claude is unbelievable and I think most of us haven't fully appreciated how insane that is.
  177. 11:41I had a service that would triage all of my PRs, have them all get reviewed with AI and then help me prioritize.
  178. 11:47That service is a markdown file now.
  179. 11:49I just literally wrote like, go to these four GitHub repos, look at all the open PRs, figure out what the current status of the work is, and then help me prioritize it.
  180. 11:57And then when you're done, go update the static HTML file and send it to S3 and give me the URL.
  181. 12:02And every morning at 9:00 a.m. this runs on a cron and around 9:15 to 9:20, my markdown file generates me my work for the day.
  182. 12:09What the hell?
  183. 12:11How are we actually here now?
  184. 12:13I Try that if you have it, by the way.
  185. 12:15You'd be amazed how many of these types of things can exist that are literally just a markdown file running on a cron.
  186. 12:21But what about Okay, two more things I want to change about this, though.
  187. 12:26First is the full stack cloud.
  188. 12:29This is mine.
  189. 12:30Don't do it.
  190. 12:30Like bit coming soon.
  191. 12:31Very excited.
  192. 12:32I wouldn't want to compete with me on this one.
  193. 12:33Trust me.
  194. 12:34It's going to be really cool.
  195. 12:36But there's still something else.
  196. 12:38There's a gap here.
  197. 12:40And I'm going to be real with you guys.
  198. 12:41I don't know what goes in this gap.
  199. 12:43I don't know what too big means anymore.
  200. 12:46Is it training your own model from scratch?
  201. 12:48Is it building your own operating system?
  202. 12:50Is it trying to compete with NPM and Node directly?
  203. 12:53I don't know.
  204. 12:54I don't know what too big is right now.
  205. 12:56And that's scary, but it's also exciting.
  206. 12:59It means I need to keep pushing myself to go bigger than makes sense in order to find these limits.
  207. 13:06But what does that even mean?
  208. 13:07What does it mean to think bigger in this scenario?
  209. 13:12I would argue that bigger's probably the wrong word for most of how I'm thinking here.
  210. 13:17It's time to think wider.
  211. 13:20What I mean by this is spectrum and I'm sorry I have to do a diagram.
  212. 13:23If you watch my videos, you understand.
  213. 13:26There's breadth and depth to any piece of software.
  214. 13:29The breadth is the range of things that your software covers.
  215. 13:33And the depth is the number of features in a given area.
  216. 13:36Let's look at a company like Vercel.
  217. 13:39Vercel does not offer all of the features that AWS does.
  218. 13:41They never will.
  219. 13:42It doesn't make sense.
  220. 13:44But Vercel offers deeper But Vercel offers deeper features in the space they're in, which is full-stack front-end leaning servers.
  221. 13:52If you're a front-end developer and you're not using Vercel, you're feeling some amount of pain because they're just further ahead with this.
  222. 13:58So much so that even the agents prefer it.
  223. 14:00And this was kind of how you had to build your startups.
  224. 14:03Because if you were competing with a company like AWS, you're never going to have all of the features they have.
  225. 14:08You're never going to cover the range that they cover.
  226. 14:11It'd make no sense to try because you don't have the thousands of engineers they do doing that.
  227. 14:18At least you didn't.
  228. 14:21But now things have changed.
  229. 14:22All of a sudden, that range is viable in a way that it never was before.
  230. 14:27I'm not saying you can build something as reliable as RDS.
  231. 14:31I'm saying that you can build a database platform into your product in a day or two of work with enough prompting and enough effort.
  232. 14:37And if you build your stuff right, if you play your cards correctly, and you think about things the right way, you'll realize that you can build enough across a spectrum of things you care about
  233. 14:48to enable most users to at least start trying the thing.
  234. 14:51And when they have features they need in a given vertical that you don't support, it's not your problem.
  235. 14:56As long as you build it right.
  236. 14:58Because they can build the features that are missing themselves.
  237. 15:01If you architect your systems and you architect your products in such a way that users can do things that they you never would have guessed.
  238. 15:08Like Slack accidentally did this because Slack is now the platform people run their agents in half the time, which is crazy.
  239. 15:13Slack sucks.
  240. 15:14It's not a good product, but it's the right shape for people to build the features they want into it through the somewhat functional Slack bot APIs.
  241. 15:24This is all crazy cuz I'm basically sitting here telling you like it's time to compete with Slack.
  242. 15:28It's time to build your own AWS.
  243. 15:29It's time to challenge Salesforce directly.
  244. 15:32It sounds stupid, but I'm going to be real.
  245. 15:35If your idea doesn't feel stupid, it's cuz your idea's not big enough.
  246. 15:40That's all I have to say.
  247. 15:41Thank you so much, AIE.