Programming Feels Very Different

0:00 I don't care about programming languages the way I used to, which is a kind of strange thing to say, but it's true. I used to really care about all of the tiny little things that went into the stack of my projects, the framework I was using for the front end, the language I was using on the back end, the way they all fit together, you know, all of these things used to matter a ton. And strangely now they just don't matter, at least they don't matter as much. I want to be clear at the outset of this video that I'm not about to make the arguments that you can vibe code react into the void forever and it will be totally fine and you will be able to build anything with that. That's just not true. We are not there yet, maybe we will get there, but at least right now the AI has completely changed the way I work with and interact with and build software, but it hasn't replaced it yet.

0:47 But I want to start with a very specific example and that's Svelte. If you've been watching my channel for a while, you've almost certainly heard me rant and talk about how much I like Svelte, how much better it is than React and the other options and just how much I enjoy building with this framework. Very recently the SvelteKit 3 release candidate was released. This is a really dope release from the Svelte team that 2 years ago almost certainly would have been a video, but I didn't talk about it in a video. I barely even thought about SvelteKit 3, even though this has a lot of things that I cared a lot about. The thing you have to understand is that the amount of Svelte code that I write, quote unquote, has not gone down, it's gone up exponentially. I have way more random things and tools that are built with Svelte. My personal site is in it, all of my internal tooling is in it, anything I release to the public is almost certainly written with Svelte. I use it a ton, but I don't think about the little things the way I used to. And that's what I really want to go over here. I want to talk about the things that I do still pay a ton of attention to, as well as the stuff that I just don't really think that hard about anymore. Luckily there is one thing that I think a lot about, which is today's sponsor. Today's sponsor Railway is an all-in-one cloud provider that I can't really imagine building without. Whether it's a server, a website, a Docker container, a database or anything else, all of it can go right here, and the experience is excellent. You can see right here I have a little mini app put together. This is actually a thing that I'm using for screenshotting websites if I need to go grab some content for research, and you can see there are three parts here. The first part is this web project, which is a SvelteKit app running on Bun because they are the only cloud provider that has first-class out-of-the-box support for Bun, which makes it very fast, very memory efficient. It has the Bun web server, then it has a background browser worker, which is running a full Playwright instance to grab those screenshots. Then it has a screenshots bucket, which is just an S3 bucket that has the actual data stored in there. You can see these little lines right here connecting all these different services together.

2:39 That's Railway's private networking system. You can instantly network all your services together with zero setup. You get private connections at 100 Gbps of internal networking without any VPC configuration because one of the really cool parts about Railway is that they own their own infra. And because of their easy, powerful scaling systems, the same infra setup you use for the first draft of an internal app can be easily scaled out to millions of users all across the globe with basically no effort. Their CLI, MCP, and skills make it effortless for any modern agent to deploy whatever it needs to directly to Railway without having to do any extra work. I love building on Railway, and you will too at david7.link/railway.

3:20 Now, obviously, the main reason why this stuff isn't talked about as much anymore is the fact that AI, and especially the agents surrounding the AI, have gotten so absurdly good that they can kind of just abstract away a lot of this stuff for us. Little things like, you know, what format am I using, or how am I importing this thing, or even a lot of the ergonomic things that we used to care about a lot because we were the ones who had to touch this stuff, just don't feel that important anymore. And this also ties into a more meta thing here where, you know, the question of why am I not talking about Svelte anymore or go anymore any of these old things that I used to talk about all the time online. If you go on Twitter, you'll notice this, too. None of the discourse is on JavaScript frameworks.

4:00 Like remember back in the day when we would be debating whether react or solid or spelt was better and we would go to war over that and now it's whether fable or Astra is better. The landscape has completely changed and I think a lot of people have just kind of accepted a lot of tried and true technologies and just aren't really thinking too hard about them. I think for most people this is just kind of become react and react is the default that everyone uses. The models are really good at it and most people have just centralized down on that. I haven't. I again still use the hell out of spelt. I think it is great and something here I want to talk about briefly is you know, what makes a technology good in the age of AI because there is that conversation of oh, should we be building our languages and frameworks around AI models? What is the best code for AI to be able to write when humans don't have to write it or even read it anymore? And I think generally speaking as a soft rule, what is good for humans is also often very good for agents, but there are a lot of exceptions to this. A great example of this is full stack type safety. If you've been around for a long time, you'll probably remember TRPC. For those who haven't seen this before, this is a TypeScript library which gives you full stack type safety. You define and create this router on the server which has a bunch of typed endpoints with inputs and outputs. Like that's your back end. And then on the client, you will call those using react query or just some form of query to use what feels like RPC to call those with full stack type safety. And that resulted before AI in us being able to build much bigger, more complex things since our front end and our back end were tightly coupled together. Now that the models have gotten really good, full stack type safety is still great.

5:36 They benefit a ton from being able to check their work against types and run check commands, tests, lints. I'm sure you've seen the obscene numbers of unit tests that any modern frontier model will write. A lot of that is because it's a way for them to verify their own work. The thing is, models and humans have very different throughput capabilities. Humans, especially at the top end, have much better discernment than the models do, and that is still true at the frontier. I love Astra, I love Fable. They are not going to make better decisions than a seasoned industry veteran. They need to be able to steer them down the right paths, but a lot of the implementation details, like, okay, I have my back end here.

6:12 It's a bunch of API endpoints. Before, if you wanted to add end-to-end type safety, you would do something like tRPC, which made the entire thing seamless. It would automatically infer and generate the types based on the back end you wrote, then you consume it on the client with zero effort. Great. That's really good for when you're writing the code. You can still do that, but also you could just like write a normal REST API, have it generate the API docs or whatever, get those types, and then import those into the front end client, and just use the end-to-end type safety that way. It's less ergonomic, it's more code, it's grosser. If I was looking at it every day, I wouldn't like it, but since I don't have to deal with that, and I don't have to deal with those manual migrations, you can just let the LLM go through the legwork of doing it, these more ergonomic abstractions just don't quite matter as much. That extends down to programming languages as well. I've noticed this a lot, especially in one-off side project-y type things. Like, I have this one app here. I called it Sudo, and it is my local first Whisper flow type thing. It is a local dictation where, like, if I go in here and I'm like, "How many new releases has React had in the last year?" It's that. It's voice-to-text, very simple. You know what this is. The interesting thing about this is I wrote this entire thing using Astra. I had it generate all of this. It used a ton of computer use to put together all the components, make it nice. The first iterations were really bad. I kind of hated the UI. I didn't want to work with it. So, I sat there with it, and I was like, "Fix this, fix this, fix this." I sent it tons of screenshots with lots of markup on them, and it got it fixed, and it's in a polished state that I really like. It feels great to use at this point. All of this app is written in Swift. I have barely looked at any of the code for it.

7:45 I don't really know how it works. I don't know how to write Swift and yet it is here and it's great and it's good. As was shown recently with the whole bun migrating from Zig to Rust over the course of a couple weeks using just obscene amounts of I think what was Mythos tokens to actually do that port and it works and now it's better and faster and yeah, it's slop quote-unquote, but it is really good slop and it works really well. The languages are much more fungible. It's much easier to just take something in one language, use that as effectively a really big complex prompt and then port it into something else. In the first version of this, everything including the local model generation and management and the history and the preferences, all of it was orchestrated and managed by the single Swift app. Now with the new version, when I was looking at that I was like, you know, this is cool, but what if I wanted to run this on like one of my Linux boxes on the server and then have the inference happen there and not on my Mac so that like if I'm on my Mac Neo, which is a really nice great computer, but it's really weak and I can't run a 5 GB model on it with this thing, it's 128 gigs of RAM, I can eat the 5 gigs of overhead to do local dictation, it's fine, I don't notice it, I don't care. I would notice it on there. So what if I offloaded the server to something else? And when I was working with the models to create that server, we spent a long time planning and talking through how all of it would work and it ended up building it out, but one of the things I didn't specify was actually the language. And since I didn't specify a language, the model wrote out the entire server in Swift and that Swift server works on a MacBook or on a Linux machine, it's fine, but I don't really want it written in Swift.

9:18 I'd rather have it in TypeScript so it's easier for me to see and understand and work with. I was like, okay, this isn't great. Let's move this over to TypeScript, plan it out, research it, use sub-agents, blah blah blah, you know the drill. It's been going off and doing it, it's almost done, it's working really well. Porting things between languages is now very easy to do. Same thing with frameworks like taking any of my Svelte sites and turning them into React or vice versa is also really easy to do. These things are just not as sticky or important as they used to be.

9:44 It's now more the higher level concepts of how it all fits together. What still really matters is like, okay, when you're architecting your service, are you using HTTP or web socket to send your data up and down from the client? How big are the payloads? Where does your database live? How does the architecture actually fit together? Are you going from the client to the server to the database? Are you going from the client to the database? How are you authenticating these things? How does it scale? All of these questions have always mattered, but now they become the thing where I've almost abstracted myself up to where I'm looking at the project at a higher level here. And a lot of the nitty-gritty implementation details just kind of fade into the background. And as such, a lot of things that I used to do a lot of, which would be, you know, using tons of libraries. A lot of my old projects, if you look at the package.json, I had probably 20 to 50 live Well, not 50, but like 20 to 30 libraries for some pretty mid-size projects, would just be sitting there doing their thing. And now I'm getting to the point where instead of doing that, instead of having a special package for everything, especially if it's something that's like under a thousand lines of code, I would rather have Astro just throw together a quick implementation for it, dump it in the lib directory, and then that's it. I have my own version of it, and I can get my package.json to be as small as humanly possible. I've been really trying to reduce the number of dependencies that I'm using because now that the models are here, these little things where before it was me saving myself of implementing some, you know, color wheel picker or something like that, now I can just have the model do it, and it'll do a great job, and I I don't really care anymore. So, I don't want to have that as a dependency. I want to keep my dependencies minimal.

11:16 I'm just centralizing these core technologies to sort of build everything. And for me, that's Svelte. Svelte is my preferred web framework. I use it for everything. Affect, I've talked about this in previous videos, I just love Affect for all of my TypeScript back-end stuff. It takes TypeScript from a good but flawed language filled with try catches and throwing and nonsense like that to what is a fully type safe functional errors as values dependency injection. Like all of these things are fixed within effect.

11:45 I don't want to go down the effect rabbit hole in this video. Go ask your agent about it or go look at one of my old videos. It's dope. It's really useful and it's also at the point where all it has all of the things built in to where I don't need to use that many dependencies anymore. But just and and if I'm lying on the internet, I apologize. Yell at me in the comments. But I'm pretty sure I remember seeing a post from one of the effect guys that they had gotten effect down to zero dependencies. Everything was just custom and handwritten. You don't have to have any peer depths for anything. I think they still have some dev dependencies, but for the actual like shipped version of it, no dependencies because they can do all of it with AI and that's awesome.

12:21 There is of course the flip side to all of this which I just kind of got into here on like with the Soto app, my voice to text thing. I just talked about how really understand how it all works and fits together. I can figure it out by asking the model and I know enough about programming and systems to figure it out pretty quickly if I spent the time to go read through it. But these things are becoming more black boxy and that kind of raises the question for me of okay, where's the line? Where is the line on what I do and don't need to read because one of the benefits of agents is you can spin up way way way more work in parallel instantly. But when you have 15 PR show up overnight because your agents were running, each of them is plus 2000 minus 100. Are you going to read every single line of every single one of those? You're almost certainly not. It's not feasible. It's very hard to actually do that. So you need some way to actually keep an eye on what's going on.

13:09 And I've gotten pretty good at scanning code bases for what I kind of like to think of as smells for whether or not it's doing something right or wrong. I also spend a lot of time just talking back and forth with the models being like, okay, how did you implement this? How did you implement this? How does this piece work? Like how is auth implemented here? Where are all of the checks happening? Can you show me examples? And it will point me at all the different files. I also, when I'm reading like a diff in a PR, I'll often look for like key tells. A great example of this is the old data loading patterns within Svelte where to use a load function which would on page request run some async function on the server to load data, then return that to the payload alongside the like actual client-side stuff. So, it's like SSRing the page. I don't want to do things that way. I want to use the new remote functions primitive. I can just look at a diff, see a load function, realize, "Nope, this isn't right. You should be doing it this way." I will give it some context on what remote functions are and the way I like them done, and then tell it to go fix it. And then I will look at the new diff, I will take a look at the remote function, make sure all of it is reasonable and makes sense, and then we're good. I I I don't know. I've never worked at a big company or on a big team, so I'm probably not the right person to speak on this, but I have noticed that over time as my projects grow bigger and bigger, I love the idea of deeply understanding every piece of it, but I've also found myself falling down bad rabbit holes where in trying to understand and track every single little thing, I end up just never getting anything done. And eventually you do just have to rely on a lot of the abstractions, and a lot of the work here is making sure that the changes that are being made make sense within the context of those changes. So, I'm not going to review the off implementation on every single PR, but I am going to review the way it is being used on every PR. And to be clear, if it's the PR that's making the off implementation, I will definitely look at that. If it's the PR that is just adding in an off guard, I'm just going to trust that off guard works, which is the way you would probably do it if you were handwriting it anyway. I wish I had some great answer on here's where you should and shouldn't read code. Here's how you should and shouldn't use these agent search some prescription or wisdom or whatever, but I truthfully just don't have it. I don't know what the perfect right way to use these things is. I find myself pushing them really hard in one direction, just like not reading the code, letting it go do its thing, building as much as possible, and I get really good results out of it. But I also go deeper into a lot of that code and I find things that I really don't like and some architecture changes that I want to make to improve the way the system functions that benefited a ton.

15:32 But, then there's also the question of like, okay, these benefits that I'm getting, it is making the code cleaner and more readable for me, but it didn't fundamentally change or improve the product. Sometimes it does. I often find some performance things or some ways of using the technologies in such a fashion that it will produce better outputs, but that's not always the case. Sometimes it is just me changing things for the sake of changing them for me, even though maybe I don't matter as much in the way the code works. I don't know.

15:59 My generous interpretation right now is that I think we are just getting to a new level of abstraction where it's less about the line-by-line detail and it's more about the higher level composition of functions, services, programs, and things that actually matter and are useful. Because, regardless of how good the models are right now and as they're almost certainly going to get, we are, at least until things like discernment are solved, you're still going to run into like the early versions of this app. I don't have screenshots of it. I should have taken them, but this app looked and felt horrible the first time I went into it. The preferences section was really hard to read and understand.

16:37 It had 12 different sections with strange spacing, strange headings, everything was misaligned. It was not good or anything that I would be comfortable sticking my name on and putting out there. But, by sitting here and spending a lot of time with it, I got it to a state where, while imperfect, I am much happier with actually using this day-to-day. There's still little things like I noticed I don't like this little void down here. Like, what is this doing? I don't want that. Like, most of this is fine cuz it's been through the polishing passes, but, you know, that's where I'm working now. I'm working on making sure the UX is good. I'm working on making sure the way everything is laid out is good. And sometimes when I ask the models what their opinions on these things are, they have really good ideas that are better than my own. Yeah, I don't know. I don't know where all this is going to go. I just know that the way I looked at and worked with technology a year ago is very different. And there's a sadness to that, the thing that I will really miss there, but there's also the fact that I'm sitting here in front of one computer doing a bunch of work with agents, and I'm also doing a bunch of work on a ton of other computers because I can now suddenly use all of my computers as these like magical boxes that I just talk to. If I want to install a new program, I want to make a new thing, or I'm tired of the way something works, I just change it. I just do it. The ceiling for what is possible, especially for smaller teams, has just raised exponentially, and there is something very beautiful and exciting about that. I'm loving it. I'm enjoying it. I recommend you do the same. The best way to deal with this stuff is to just embrace it and see what is actually possible. Yeah, I don't really have anything else. If you enjoyed this video, make sure you like and subscribe.

18:04 I'll talk to you again soon.