Coding with Cursor (internal session)

I thought it would be useful to show folks Cursor internally, how we use it. Everyone uses it differently. When I was working on this, for example, it's very nice. So you hit— this just autofills. You hit divider and then it goes through. So that's nice. Type, only one character, and imagine all these things can change. If you're working on a new feature as an engineer, you're going to get a lot more benefit out of this. But as a designer, I feel like it's not that useful because you're making more systemic changes, you're not building stuff from scratch most of the time. I prefer using Command+K. I almost exclusively use Command+K. The way Command+K works is you hit Command+A and Command+K gives you this text box and then you type into it. So this I find is very useful because I wanna take something that I've been working on in like v0 or Figma. It's very helpful if I'm making big iterations on stuff. This is another helpful thing if you're stuck, just hit debug with AI and you'll often be able to help yourself get unstuck. A lot of people are scared of coding. It's quite scary. I wanted to show an example of what the world is going to look like when we are fully in Next land. Shortest is a project I started working on last week, but I wanted to show everyone how simple it can be compared to what maybe people are used to in our older projects. This is shortest, something I built to write tests. It's going to be open source. So we're gonna work on it publicly. So this is the entire app in Next.js. And so you'll notice that there's no routes. It's just app and then the URL structure, the routes are all determined by this. And a bunch of magic. There's a lot of magic in Next.js, similar to Rails. There's a lot of middleware that you don't have to think about as long as you're using the default patterns, which you may not like. But as I've been working on stuff, it really feels like Rails. People with experience building stuff who are trying to abstract away the stuff you don't wanna think about. So for example, everything, if you notice, this is a homepage, but it's in the dashboard folder. And the reason it works like this is these brands. So if you wanted to say something, but not that strongly, you would say, "Have AI write your tests faster than ever," right? Something like this. That's the mimic. And so this basically just puts it up another level. So this just treats it as an index. And you can nest these if you want. There's some other magic that you can do with like square tags and things like that. This is why Next exists. Next first started because Guillermo was annoyed about routes and was like, why? You already have the file system. Why can't you just use the file system? And I really like this because what it means is if you're in any part of the project, for example, this is the dashboard/dashboard. You basically know exactly where to go because this mimics, okay, this is index, right? This is slash. And then so it's gonna be dashboard. And then you have layout and you have page. So everything, I don't even think you need the layout. You just need page. So this is another really lovely thing is that with Rails, you could have index.html, but you could also have show.html, edit.html, et cetera. Because you are treating the file system as the routing, you will only have one page that is actually being rendered per folder, right? Because inherently every folder is its own route. And so you can basically always assume that the page.tsx is the equivalent of that index.html. And this is really nice. They also have a layout.tsx. And so if you wanted, if you wanted to separate the layout from more of the content, you can do this and it automatically wraps the page.tsx in this stuff. So let me see if I actually have anything here. See if it works. No pull requests found. Cool. Well, this is ugly. So I just search for this. This is often what I recommend people do is search the file system for where you wanna go. You'll see that there's another really nice thing. Like you end up with these like kind of bulkier files because you're doing a lot more in the pages, but it's really nice because all of the UX can live in a single place. And as a designer, it's annoying when you're trying to work on something and there's 7 different files you have to update. So I like having, for example, a page.tsx and instead of having like Loading.tsx, Error.tsx, et cetera. All of this is in one file. You can think of this almost like guard statements in Ruby on Rails, right? Where you're basically just doing guard statements on the front end. If it's still loading, just render this. Some people also think that this is ugly and repetitive. Oh, what if we had a component that just did this part and this part? But I just think that it obscures what you're actually trying to do. You want to be able to effectively read this and know what the UI is going to look like. To a large degree. And as I mentioned, I love Command+A, Command+K. So I could say, okay, I don't really like this. It's— I think it should be centered. Like maybe how we have Flexile, like the placeholder with the dotted line and like a little icon and all that kind of stuff. If you go to Flexile like this, right? I basically want something like this. So I can just take a screenshot of it. I can just Command+A, Command+K and say, You can paste in an image and say, improve the no pull requests found to look more like this with— and I don't know, I don't like coding, frankly. So this is— I like basically don't write code at all. I'd much rather type English. This is basically how I write 100% of everything. To look more like this with icon at the top and center it. Etc. Also, make— add a list of things that could be leading to this. For example, I got an email from somebody who used to work at Gumroad back in the day, and he said, love it, trying it out. How do I add it to my GitHub repo? I'm signed in. I don't see any instructions, right? So I can basically to take this and say, a friend said, I replied. So this should be listed as a reason. What would I want to do? Sure, you're assigned to Pull requests. Another reason. Two more. I like three, rule of thirds. And then you hit edit and it just goes through. And the nice thing about this is I just go do something else and I just go and answer a bunch of emails. This is a very good app, by the way, Luma. It's clearly built with Tailwind and Next. You can just tell by how smooth it is. And then I can go back and it's done. And instead of actually reading the code, because who likes reading code, I can actually just test it. And so this is what it did. It's better. And so I can accept the changes. I could also follow up. One issue that I have with following up instructions is the more context you provide it, the more hallucinating it gets. So what I prefer doing is once I like my first iteration, if I don't think it should go through the whole page. I'll accept the changes and then I narrow it down. Right. And so just to review the code, just for the less, less technical people, just to see actually what it did. This is one thing, by the way, I love about React. It's like this alone is like infinitely times better. But imagine you wanna add an icon to Gumroad. You have to go to Figma, then you have to export the SVG. Then you like add it to the codebase. You have to decide where in the file system you wanna put it somewhere. Then you have to import it. Then they have to make sure you're using like the right image_url, or is it dash and you forget, and then you have the full path, or, and then you have a typo in the string and it doesn't render and you have to like view source to see like what's the mistake. And then you have to like run, you run some command to see all the routes, like just all this stuff. And what are you doing? All I want is a git pull request thing, right? And it chose this. I didn't say what kind of icon or what text or anything like this. I was basically just the product manager. And so it pulls in this icon from this Lucid React library that we've imported. And think about a git pull request icon. Like that's so specific, yet it has it. So effectively everything you'll need is in this thing. And so anyways, it imports the thing and then it goes to that no pull requests found paragraph and it replaces it with this thing. And this is basically why I wanted to move to Tailwind and why I think everyone hopefully now sees that it's like the right move is that it pulls the design system from the code instead of having to think about Figma or even look at a CSS file, which it's not gonna really understand because all the global cascading effects, it's impossible to look at CSS and understand what it's actually gonna do. It looks at this and says, okay, these are the kind of tags that are already being used, right? The error already has this kind of layout basically to it. And then so it copies that, right? You can see that this is like flex call item center justify center h-full. And then this is similar flex flex item call, et cetera, et cetera. It puts in the icon. I don't know how, like I've never looked at Lucid React. I would have to like Google this and figure out how to actually include it, but it includes it like this. You can guess what it's doing, right? Based on just reading this heights. 16 pixels, I assume, with gray margin-bottom: 4. And then boom, it does all this, which is— it's super nice. Think about how much time this would take to type. It would take 5 minutes. And of course this takes time too, but I'd much rather think about actually like what we're trying to do. And actually I didn't even read what are the other things. Make sure you're assigned to a pull request. Awesome. That's the one that I said. I like how it did this two-level thing because it, I don't know, it's just nice. Make sure you're signed, check up your GitHub account. Yeah. I personally think these are probably not super useful. So this part I probably won't use AI. It's probably faster for me to just delete these. And then another amazing thing about all this stuff is you get built-in hot reloading. I highly recommend, by the way, everyone use Simple Browser. So if you do Command+Shift+P, that's like the VS Code It's not cursor-specific. This is VS Code. You can run these packages that, you know, you have installed. So one of them is Simple Browser. That's default installed. You can just put in this. And then ideally it should be— sometimes it doesn't work, but ideally it should render the entire app. It definitely works for frontend stuff. But the dream is that you have one thing on, on one side. And one thing on the other side and you just can iterate here. So yeah, sometimes it doesn't work. It worked for Antwork. So anyway, but definitely try this because this, imagine you're a designer, you can like in real time see this update, which is freaking awesome. And so this is better, but I just wanna do one quick thing before we move on, which is go find, I wanna add like kind of that dotted roundy thing and I wanna center it on the screen. And so imagine if you could just listen to me and do those things. Wouldn't it be nice? Soon, soon. But here it is. No pull requests found. So I want to just say— I'll just highlight all of this and the same thing, Command+K and say vertically center the error message. It's not really an error message, but and then, and add a dashed border around it. Not gonna say the color or anything like that, but let's see if it did it. Ooh, it probably didn't do it because it's adding it to the div, the whole div, which is gonna affect all the pull requests too. It probably does fix that, but it's wrong. So this time this context is small, so I'll use follow-up instructions. It's already bound to what I'm trying to change. Within the page and say almost don't update the list of pull requests, only vertically center the no pull requests found bit. Also, I still wanted it to be full width. I think it's weird that it goes like this. Keep it full width. So hopefully it should get it. We'll see if it gets this one. Ah, didn't get it. It's still not centered. One more time and then I'll move on. Still— honestly, it's not bad. I'd probably just ship it because I'm too lazy, but you can see it updates in real time. There you go. Awesome. It worked, right? So that is pretty cool. It fixes an issue. That someone reported. And then I can just— actually, the right— I'm trying to get better at not writing any code. And so in theory, you should be using this feature, which has built-in source control. You also, by the way, can see like all your stuff here. Everyone should download this. This isn't the script, but there's nothing here. But everyone should be using this because it's amazing. All comments show up in line. It's pretty freaking awesome. But let me just say, add improve placeholder or no PRs found with that error message. I'm gonna probably want to do a different branch, so maybe I need to check out a different branch, or do I— can I— I don't want to commit on main. How do I change it without writing code? Oh, there you go. Awesome. Create new branch, no PRs found, and then I have to commit. It's probably going to fail. Because it always fails for some reason. Let's see if it works. It worked. Go to the repo. Why didn't— oh, I didn't create the thing. Why do I have to do— hit this button? There you go. Create. Let's see if this works. So think about it, like, I don't even have to leave. Ideally, if simple browser is working, it's annoying. That's not working, which I guess why they don't promote it much. It's probably like a beta feature. But imagine I don't have to leave VS Code. Like, I can just work our cursor. I can just work and get stuff done, and all of this is here. All the features you want, by the way. You can basically do every single thing. You can, you can assign people. You can do all the things you want to do, and it works, which is pretty awesome. So yeah, I would recommend using this. If you want, you can open it up in GitHub and it'll all be there. And then you could, this is often actually when I review the code, like I just work and then I come in. Oh, it just, it also got that change that I did earlier. So yeah, that's an example of some stuff. There's also something called cursor rules, which is pretty cool. So if I open up the Flexile thing, I think it's here. So cursor rules I wanted to cover is basically a way of, this is stuffing the context every single time. All of this stuff is getting sent to, to the AI to respond so it knows more. Ideally, we're using normal stuff, so we don't— this is all— you could basically assume that all this is custom to Gumroad, right? Because otherwise you can just assume the AI would know it. But basically all of this stuff is because we're using Vue instead. If we're using Next, basically it knows all, a lot more of this stuff. We probably wouldn't need this. We could delete. A lot of this. We don't need to think to add a feature, right? You shouldn't need any of this basically. So think about how much less the AI has to learn every single time it wants to do a request. If we're, you know, one stack all using Next.js. So ideally the goal is to delete this file, right? Because it's able to just know based on the context, but for now we're not there yet. There's a lot of technical debt. Yeah. So that's, that's cursor rules. Helen, for example, had this thing. Cursor. Did I mention that? Oh yeah. So for example, if you're annoyed by Cursor doing stuff and you keep having to fix it, because the goal is that basically Cursor in one prompt should do exactly what you want to do. And so if you keep having to fix things after Cursor has done a thing, like I do notice this sometimes, it's, it, in my case, it uses single quotes often and then I have to convert to double quotes, which is not a big deal cuz I just hit save and it does it. You can basically just add these. So you go, for example, these two cursor rules. So you don't have to code. I use Cursor for everything. Like, all everything I write is basically I write in Cursor. It's nice. Like, I don't have to read the file. I don't have to like figure out all this energy, like cognitive load that you have to use. You don't have to use, which is really cool. So for example, you can notice this as an example of this, it changed this, like, whatever you call this fancy curly to a non-fancy curly, which is probably good. You generally want to avoid fancy curly. It's a scare code. So you could say you could add that or not or whatever. So yeah, think about how fast, you know, you should be shipping. And if you're, if you're really taking advantage of cursor. So I covered cursor rules. Oh yeah. I wanted to COVID test writing and give a pitch for shortest. Tests are annoying. A lot of people, you build the feature, you design the feature, and then the tests fail and you're like, okay, great. I can't actually move forward. Something is wrong. And so let me just kind of give you an example of that. So an example of that would be, let's say I have one test in this repo. So I'll go back to shortest. Forgot to terminate. I forgot to terminate everything, right? Imagine how many annoying things are gonna happen. When I do npm run dev. It's not gonna— oh, it worked. Why did it work? Who knows, but probably because Next is awesome. So it works. Let's— can I even sign out? Do I have a sign out feature? Oh yeah, we also use Clerk. So imagine all the code. Think about how there's no login. There's no— this is literally the entire app. Let me add— let me open This is the API. This is another thing I love about Next, the how the API setup is fricking amazing. But we use Clerk. So none of this is in our codebase, right? Where, where all of the auth is done by Clerk. And the way that works is something called ClerkProvider. And as I mentioned before, there's like the layout. Why would you want layout if you have page? And one reason is you probably don't want like a designer working on Shortlist to think about, oh, the fact that every single thing is wrapped in a ClerkProvider and an HTML and a body. They probably, you probably only want them thinking about the page itself, right? Which is this. And so that's, I think, probably why they set it up like that. It's, I almost think about it like engineers should be thinking about layout often and designers should be thinking more about page. The other really nice thing is they don't have a, you may notice there's no components folder. Like if you go to helper and we'll compare the helper file system to this and see how much simpler it could be once we're fully in Next.js and all our tech debt is gone, but all the components that matter are right here in the file itself. So you know where they're gonna be. So I just merged something, so nothing is gonna show up here, but let me log out. When I log out, I'm back here. How does it know? How does it know? You can see this thing is popping in because I'm not logged in. How does it know? It knows by this Clerk provider. So Clerk provider is basically a wrapper that you put around your entire app and then it gives you some functions that you can use. Yeah, I'll definitely go. I know there's a lot, by the way, like I'll go through a lot of this and, and yeah, take questions, of course, and all that good stuff. We're already 30 minutes in. That's crazy. But, yeah, so basically Clerk is nice because every— if everything is rendered by a single language, which is this sort of TypeScript TSX file, you can basically take advantage of all sorts of useful— anything in the React ecosystem effectively you can plug into any page, even the favicon. Imagine the way favicons work. Who's— who loves updating the favicon.ico file? Nobody. This is the favicon for Shortlist, right? Which is— I just put a scissor there. And the way it works is there's a custom image response And it's just code. It's just TSX. It literally just renders the scissor. It's just the scissor Unicode. If you're like, oh, this is too small, you make this 32 font size. It's bigger now. So imagine like going to Figma, updating it, saving it, exporting it, Googling like PNG to ICO format converter. Then there's like a gazillion ads you have to go through. Instead, you're just doing this. The nice thing here is if you have— because it's a TSX file, you can actually— they're all composable. So, if you wanted to use— I think for Ify, if you wanted to use— oh, yeah. All of these are also TSX files. So, it's not an image. You can add more and more logic to all this stuff. If you wanted to use the icon here and also put it here, you could actually do that, right? Or in an email or in the Twitter card. In all of it, you only need one component. But imagine, you know, something like Gumroad, the emails are rendered differently, that the favicon is rendered differently, that the Open Graph image might be rendered differently, that the product pages are rendered differently. It's a lot. And so all of this is in a, is a, is in a single place. And that enables all this cool stuff like using Clerk to basically manage all the auth. So if you like Google for auth, yeah, there's not much in here, right? And it's pretty awesome on the front end that you don't have to think about it. I definitely think we should switch everything to it. Like I didn't have to worry about GitHub Auth and all this kind of stuff. But anyway, let me, let me change something and show you this test, this testing feature. So let me just say, I want to get rid of this your thing. So I'm going to go back to main. I know I'm writing code. It's very bad. I know it's muscle memory. I'm sorry, but let's go to this and go change, change this. And you can see there's a test that tests for that. So it is going to fail. But I'm just going to say, have AI write tests faster than ever. And I'm going to open a branch, new home page, and I'm going to commit. And I'm lazy. Maybe this is faster than AI still, but it shouldn't be. There should be tab for all this stuff, I feel like, too. And go back, open the PR, assign it to myself. And then this test will run and fail. Oh, by the way, this is another amazing thing about Next. All the test files are in the place that you're testing. That makes so much more sense in my opinion than having a separate spec folder that has everything and then you have to like manually map everything over. It's just no, if you wanna test the page, it's just You just add .text, test, right? Super simple. And it's awesome. And so this is gonna fail because it looked for write your test. It doesn't exist. And for the people asking about, about not using Shortest, let's say just doing it manually, but basically how do you write tests? Where's the thing from Andy here? I never seen it. Never. I never seem to have it make tests correctly and end up spending quite a while trying to fix failing tests. Would love to see how you do it so I can change my approach. So basically what I did in Shortest, and I open source Shortest so you can actually read like the code behind it. Actually, I have it right here, but you can see basically what it does. Oh, this is another beautiful thing. Every route in the API, it says route.ts. So every page is page.ts. You have the layout, which is TSX, and then you have route, which is .ts, right? Is super, super simple. Like, you— I know exactly the URL I need to hit, which is /api/generate-tests, and you're done, right? Route is /github/api/github/callback/webhook/drive/checkouts, etc. It could even be better, and it will get better because all this should be type-checked anyway, but we'll get there. And so this is the generate tests file. So you can basically— this is how it's set up. You are an expert software engineer. Update existing tests in order to get the PR build back to passing. And then it looks at your PR diff and your existing test files and it responds with them. And then I do some stuff to actually get it to, to commit the code, right? So imagine I made this change and if you do a git diff, I guess git diff is gone cause I committed. But if you, it's a pretty small change, right? I'm just changing the single file page.tsx. So I can just open page.tsx. And then I'll just go into this. It already highlights the current file. I can just add the page.test, which should be, you know, if you're using this file structure, should be pretty obvious, like, where the tests are gonna be. Currently, it's not like that in our other code bases, but I do think we should probably switch to something like this and say @prdiff. So, this is just gonna basically load in, like, the actual diff with main branch. So effectively this stuff it's gonna know about, because right now all it knows is the whole file, right? It doesn't know actually what you've changed in Git. So you can just add that and say fix tests. Let's see if it works. Did it work? Personally, this is why I like Command+A Command+K is because I wanna see the changes. It's a little bit hard to see what the changes are. I don't like reading, like I have to read all this to actually know what the changes are. And here you have to hit apply. And then it'll do it. It even chose to add some new tests. So probably, I don't know why it did, but it decided to go crazy on this. This is probably gonna fail, but you can see the actual thing that it did fix. Have AI write tests. It updated write your tests to have AI write tests and faster than ever. It added some bunch of crap. So yeah, it worked, right? Pretty cool. I prefer not doing that. So, I'm gonna reject these changes and just show you what I would normally do, which is I would just open the test file up, highlight the whole thing, hit appliqué. I don't know if you have access to PR diff, which is maybe why they don't like using it, but like update tests to match h.26, right? This should probably work. And then what I like about this is you can see what it's doing kind of in real time. Similar thing, it decided to do a bunch of random crap. But if you're just trying to fix the test, you notice, don't add any new lines of code, only update tests. The cool thing is if I learn this, if I'm like, oh, this is a problem, then I can actually go to shortest and include it. That's better. It still went off the rails a little bit. Literally, I said don't add any new lines of code and it still did that. AI's uncooperative. But yeah, anyway, that's basically what I do to write tests is like, it's just often easier. And then if you wanna really highlight, you just say, I changed this to that. I changed X to Y. Please update tests to match, right? Stuff like that. Basically you have to list all the changes you've made and then this kind of prompt should work decently well. Yeah. So for example, it's if Jack's saying, don't change things I didn't tell you to change. Maybe if that keeps coming up, then you can, there's two ways to do it. You can either add cursor rules if you wanted to. So in this case, because it's open source and I want to teach people stuff, I might want to do that. So to create a new file from terminal, you just do touch .files, and then you could just put it in here and then you could say, what did I say? Don't update tests. So cursor rules, very helpful. And the cool thing is everyone benefits, right? If you improve the system, it ends up in the Git repo and then everyone else doesn't have to think about it. And that's like a big thing for me is I basically want to delete all of our docs. Every single thing should be— and you cannot tell, I deleted a lot of stuff already, but most— more and more stuff, like all this stuff, it's like a human has to learn It's like really annoying. I think, I don't know if people enjoy reading this kind of stuff, but like, for example, like this is process specific, right? It's not really code. Like it's separate PRs and stuff, which almost makes me think we should just get rid of that. Like this is technical debt. Like we need to do this because we have a big massive database for Gumroad, but we don't really need to do this for our other projects. All this is Gumroad specific actually. And, but yeah, the goal is basically delete the whole file. That's the goal, because ideally there's no onboarding. Onboarding should be basically nothing. You're just using standard stuff, and if you're using standard stuff, the AI is gonna know and assume basically the right stuff. So let me go back to the components thing that Jack asked about. So, yeah, if you open up like helper, for example, right? And you're like, okay, I want to make a change to— why is there a source file? I don't know. Source folder. You're like, all I want to do is find the dashboard. And mailboxes, mailbox slug. Inbox. You can see all these, by the way. This is using that thing that we were talking about before. So this is basically an ID. And so you can see if I go to helper.ai and go to— I think it should see how it matches. Helper here, mailboxes, and then mailbox slug maps to flexile, which is a string. And, and then it keeps going, right? So this, because this is a, this, there's nothing that after that. So in this case, you'd say, okay, I have a page, but then this page is doing, is getting, it's like components, utils, URLs, or here it's like components inbox. So then you have to go back and then you have to go find the, oh, it's not here. It's one more. Oh, here it is. Components. And then you have all your components and then you have icons. I don't know why they're here. It's just like a lot of different places you have to go to find out what you wanna do, which I just think is very annoying. And what I love about Shortlist is that it's all in one place, which is the— there's no components folder because you can assume that if it's not a layout, a page, or types, like a TS file, you can assume this is a component, right? You can just basically assume that everything else is a component and it's very like component component-first way of thinking. Do I still have my PR here? Yes, I do. Awesome. So it should now, if I log in— so this is all Clerk because we should be focused on what's unique to the apps we're building. It should show up here. Oh, it's centered. It's up to fix this later, but you can see this. Let's see if this actually works. Probably won't, but very early. This is really the component. It's this pull request, right? And so I pulled it out and have it. And that, that way, when I do cursor stuff, I don't have to, like, it doesn't have to think about the overall layout. It just has to think about pull request. And then I can just work on this big file. And I love this. And the other really nice thing, if we're using ShadCN, is, is that there are components, right? At the end of the day, there's this checkbox. Right. But the checkbox is not Gumroad specific. Oh, it worked. The checkbox actually worked the way I would've done it. It's lazy and like it technically fixes it, but the AI did it better when I was, when I had cursor to it. But the components, like where is this component? Like that, this checkbox, this, all this stuff, there's like all this UI and then there's no components. And the reason is they're outside of the app folder. Because they're not specific to the app and actually they're in this components UI. And so we use something called ShadCN, which is what v0 does. And so you can see this checkbox is here. It uses Radix, like all this stuff, like hundreds, thousands of lines of code, probably for this single checkbox. Cause there's like all these browsers that have to work. Think about how many browser bugs you have to think about. And then what it does is it just imports that checkbox or that button or whatever. From that file. And then that way all of the components, and you should basically never have to touch these components. We should never touch the components UI. This is chat CN. Everything we do should basically be referencing it. And if we wanna have our own components that are specific to what we're building, pull request, you import all those from it, right? So if you wanted like a very unique, Raul said Composer. So let's say I wanted to use Composer. And say, I want— what's here? This is why I don't like it. You have to go back and see, but like right now we just use the button and with some Tailwind classes. This is a nice thing. You don't have to have a button component if you're just using Tailwind, right? Cause you're just like injecting some Tailwind class. But let's say you do, you want to have a very like big padded button, big and chunky. And you don't— you want, you want to do that for all things. So you just do this and say, I want all my buttons to be big and chunky. So make a new button component that uses ShadCN's button, which is here, right? And hopefully, given that this is using the latest and greatest ShadCN, Next 15, partial pre-rendering, all this stuff, there's very little technical debt given I started the project a week and a half ago. It should do this pretty well. So Do I have it running locally? Yeah, this is all local. Awesome. So, let's see what happens. By the way, chat now does a lot of this. So, you can reuse this. And so— think it will work? Oh! Chunky button. It's here. Look, think about that. I didn't have to do anything. We got a big chunky button. And the cool thing, by the way, this is very important to know about Cursor, is I didn't save. I didn't have to think about saving. And the reason is basically what Cursor does is it sets up a shadow workspace, saves the files. Actually, it saves the files so that your browser shows them, right? Because the browser doesn't know about Cursor, but then it basically keeps all of your changes, all of your like the delta of your changes basically in a shadow workspace. So you don't actually have to hit accept. You can actually iterate. Let's say I don't like this. I don't like— I don't know, it should be big and in the center, like big, make them big and always 100% width. This is a stupid example, but you can iterate with cursor similar to v0 and it'll keep doing stuff. You could keep seeing what it's doing. And in theory, it'll work. Yeah, it's working, doing its thing. I wouldn't recommend— oh, it went back. What? It worked for a second. And then once you're happy, you hit Accept All, and then you can, you can see the changes it made, but you can tell why I don't like it. I have to do all this extra work to just see the changes it made and learn. I want to learn what's actually happening. So I created a chunky button. Chunky button. Where's my chunky button? Chunky button. Right? And think about how awesome this is. This is awesome. This is the only thing that's unique. So, all of the button-specific browser configurability stuff is in button.tsx, which is ugly and has all the variants and destructive and ghost and link and all the stuff that we've had to come up with manually for all of our stuff. Large, small, default, blah, blah, blah. We don't have to think about any of this, right? We just have to think about ChunkyButton and ChunkyButton because it's app-specific. It's our app only. Doesn't live in components. It lives in app components. If we're only using one place, you could just move it over here, all that kind of stuff. And even tells me what to do, bigger, chunkier, full width. Pretty cool. Right. And so this is like totally the right way to build web apps in my opinion. And it's freaking awesome. So yeah, so that is A lot of stuff. I covered that. And then v0 for ideation, just really quickly, I want to cover this thing. So let's go back to main and stash my changes. I'm going to log out and say, okay, I like this, but I want to come up with something else. I can go here and I can say, okay, let's say I want pricing. There's no pricing section. I guess there is a pricing section. What does this do? I don't even know what this does. There's no pricing. Okay, so let me do pricing. Let me— this is a good example. So where is it going to be? Pricing page, right? There's a custom submit button, and the reason there's a custom submit button is because you want— they're like, this Next starter kit has this like really cool loading animation and all that stuff that I messed up. But let's say I wanted to come up with a new thing. I could just take a screenshot. Go to B0. Project source real quickly. I could even drop in my Tailwind CSS file. Tailwind.config. There might not be much in here. What's in here? Yeah, there's some stuff. Yeah, there's not really much in here, so it's not really gonna be helpful. But let's say there was, let's say we had it or we have a global CSS file or something like that. You can just drag these right here. Oh, it doesn't support CSS. Wonderful. Should support Tailwind though. So drag them down. I have some feedback to send the team and then I say add. 2 more pricing cards to this layout, one on the left, one on the right. Okay, let's riff on this. Let's see how good it does. It's not going to get perfect. It's not even close, but it's really helpful in my opinion at working on Wow, it just like pops in. That's not bad. That kind of takes the get started or whatever. And then the cool thing is what I really love about it, there's a couple things I really love about it, but you can add it to your code base really easily. So this is what I love about it is because we're using ShadCN components, we can take advantage of this. You just run that single command and it pulls it in. And it'll appear in our codebase in no time at all. I did this with here and then I, I hit that thing, it popped it into this page and then I was able to pull it in. Eventually what they need is a way to go the other way around where you can import a component you already have into Vue Zero, edit it, and then import it back. But if you look at Twitter, their Vue Zero account, and I feel like this is my job as CEO, it's like investor hat, think about where the world is going, not at the exactly what things are going now, but like you can just see how fast they're shipping features every day. They're shipping features. So this thing is getting way better, way faster. If you use it like a year ago and you're like, that sucks, then you're probably right. And it sucks less now. Let's say you wanna add dark mode. And this is, what does that mean? Does it mean just dark mode using the browser? Does it, is it gonna add a button to actually implement dark mode? I don't know. But it's fun because you get a little bit more variety in what is gonna actually happen. But my assumption is gonna add a button. But yeah. Yeah. ChatGPT is basically like SwiftUI for the web. If you can think about it, like it's one level of abstraction. Like no one should be thinking basically about HTML, CSS, you know, anymore. Everything JavaScript, basically TypeScript. So let's see if this works. Yeah. Pretty cool. Right. I actually added dark mode to antiwork.com and I actually think this is better because if I go here and show you what that looks like, I don't have an icon, for example. I actually like— actually, this icon thing is fun because it's easier to test so I can just copy the moon, sun exists in this library and just go here and say I don't know what it's gonna do. It might do some weird stuff. I'll go through and do it all. And again, think about how much code, how much cognitive load you'd have to do to actually edit all of these things. It's insane how many small things are changing. Oh, it worked! Crazy. And so I know it took me like would have taken me like 15, 20, 30 minutes or something. I'd have to design my own icon if Lucid Charts didn't— Lucid React didn't exist. And all of a sudden I have this cool, fun thing and I can just ship it. Let me just quickly say this. Yeah, so the role is basically— this is the way I think things are developing. I've already talked about this before, but just a reminder, I think this designer position that we used to have is getting split into brand designer and design engineer. And I put some names of like people who are in this category. So you can see Jack is doing a lot of design systemy type stuff, but then also design engineering stuff. Someone like Karen, who we work with on like the Gumroad logo and stuff, only really wants to do this, right? So there's, and then it's like almost more roles than before. Then you have design engineers who are doing a lot of product engineering and design and front end and stuff like that, uh, which is like probably the largest category, cuz ultimately that's a lot of why people pay for our products. But then there's more of a systems engineer. The systems engineers are pure migrating to Next.js. It's gonna be hard for Jack and Caro probably to do that. And so you need systems engineers to think about those kinds of problems. And then basically everybody else except Steve, Steve is his own special role, is a support engineer basically, which is like a support ticket comes in. Often support tickets come in because like they can't do the thing they wanna do or there's a bug. And so if there's a bug, then ideally the engineer can actually fix the bug and use AI and Chris and all these sorts of things to, to do that. And then Steve does risk and fraud, which is its own unique N-of-1 role. But over time, this becomes Iffy, and then Iffy is basically Steve as a service, but even better because it's powered by Steve. Hopefully that was helpful for everybody. This is only the beginning. It's only gonna get crazier and crazier. So yeah, I understand it. There's a learning curve and it's like being back in college or something, but I have a better than losing your job to AI. I think Jack, you had a question about design reviews. Yeah.

Okay. How do we look at the role of keeping the quality, like the overall design quality, as the amount of shipping that's happening? Sometimes I'll see something in production and be like, ooh, that's not good. Do I— is that just more of a pedantic design tendency that I have to just be like, everything needs to be perfect? Do I— because what I, I could switch into two modes. One mode, which is just like everything is like the polish has to be absolutely perfect. The other mode is whatever, just like we're shipping. If the customers are happy, great, right? Like it may not be a great looking product. And this is if things got way out of control, right?

Yeah, totally.

We didn't have that. How do you look at that going forward as we move along?

Yeah, I think Basically, I'm trying to get to a place where we almost have the best of both worlds, where we are really relying on components. You saw the sort of Flexile transition. Flexile used to be like very design systemy, but there was actually quite buggy because of all the nested CSS stuff. Yeah. And it was even arguably more visually buggy while we were transitioning to components, but now because we're using components for everything, it's, there's, it's almost like bug-free visually. Yeah. And then the really nice thing about Tailwind, and so basically I want, if we're relying on this one, you can think about ShadCN, and then on top of ShadCN, we have our own component using those pages and layouts referencing really pages only should be referencing components. And then layouts are really just some larger kind of stuff. Ideally what it means is that like one designer should be able to contribute to the shipping process. So the quality of stuff is higher because it cursor, you can go in and update Tailwind classes. Yeah. But then also what I really, I wanna get to a place where designer or engineers feel comfortable basically shipping all the way to production. And that may lead to some jankiness or some like inconsistency, but ideally it's so easy and fast to actually update and fix the issue that it's still better than basically the old system, which is like very slow moving development, but everything is pixel perfect. Like right now, for example, if you find a visual bug on Gumroad, you basically have to give an engineer the task, right? Because it's just like too much complexity. But if you find a visual bug on Flexile, right, you just like search for that Tailwind class or chunk of Tailwind classes. Yeah. Fix it, fix it yourself. And that's actually why I got rid of Wilfred and staging and all these things. Basically, we should be relying on our test suite. We should trust it and we should, we still have future branches for staging effectively. And then if— and Vercel has all this stuff built in, by the way, like all of our DevOps stuff around that just goes away. But then ideally people can just fix the stuff in— like I should, if I see a bug, I shouldn't tell anyone. I should just fix the bug. Like the idea of right now people have to get help from other people is I think of basically technical debt. Like I tweeted today, Ruby on Rails is more technical debt. A few people got annoyed at me. Obviously if you wanna use Ruby on Rails, that's fine. We obviously use it. But I think for building complex web apps where if you have Cursor do something and it can't do it, I think that's technical debt. Like, AI can do everything at this point in software engineering. And so the only thing it can't do is things that are our fault, not the AI's fault. So that's why switching to ShadCN, having a folder structure that mimics what people are used to now, and, and anything you do for AI is going to be amazing for hiring because Every new grad that's interested in Next.js and building complex web app, everyone building complex web apps uses Next.js. No one is, I wanna build a really cool AI app. I'm gonna go use, who's 19 years old or something, and is gonna go use Ruby on Rails, right? I mean, that are people who are already familiar with Ruby on Rails. Yeah. I didn't want to switch. I didn't wanna learn typing. I didn't wanna do any of that. And then Cursor came out. I was like, oh, I don't even need to. Great. Cursor can just do it for me. 10 years from now, we're gonna live in a future in which none of us will basically be doing what we currently do. I don't know what that future looks like necessarily, but I know it's not gonna be what we currently do. I'm not gonna be writing tests and like typing colon slash and all that kind of stuff. You should basically be able to tell the AI, hey, there's a bug, a visual bug on this page on Flexile. It, this padding should be half of what it is. That's all you should be able to tell Cursor or even GitHub at some point. Maybe we don't even need Cursor. We can go back to just use GitHub and then It just updates the files. I really think most of what we should be doing as humans is QA on AI. You should be PMing the AI and then the AI does the work and then you QA it. If you think about a plane, often the human pilot takes off and lands, the AI does everything in the middle. And that's how I think about everything. You still have to come up with the idea of what you want to do. The AI doesn't have agency. Then the AI should be doing all of the hard work and then at the end you're coming in and QA, was that the right decision? And then you can iterate, chat with it, all that kind of stuff. Yeah. But yeah, I think the components would really help a lot with, with like visual inconsistency and stuff like that.

So that, so one thing I'll see, like in helpers, I'll see we have a button component and then I'll see someone, and I'm not even saying it's one in particular, but I'll start to see it where it's, oh, someone just created a random inline button. Yeah, but AI did that, and for some reason AI didn't realize that there was a button because there was no context given. So now we have a whole bunch of one-off things everywhere that ends up being technical debt, because then someone will go update the button component and say, wait a second, why don't the other— these other buttons change? I think that's fine. It doesn't eliminate the debt though, that's the thing, you know what I mean?

Yeah, that's the thing. That's why I think the thing is that basically AI makes it much faster to get rid of technical debt. And if you get rid of technical debt, AI allows you to ship 10 times faster. So effectively, like, we should— the engineers should be spending 50 to 80% of their time reducing technical debt because all of these problems are effectively a reason, like, just the fact that we have a lot of technical debt. And so the AI looks at the technical debt and thinks it's what is good, right? Like, it doesn't know the difference between technical debt and good code. It just assumes— it's kind of like a new engineer joins and starts doing weird shit. You're like, no, no, you're not supposed to do it that way. Like we do all these custom logic, right? And so I think the vast majority of the effort of engineering should basically be on migrations, technical debt reduction. Because if once we get helper to a place, and that's often what I'm working on, once we got helper to a place where it's all using ShadCN components, button, we might have a helper button, but we may not even need it to be honest. I think ShadCN has thought of, if you think about, if you look at toasts, for example, yeah, toasts, we have one thing. But if you look at how ChatGPT does toasts or combo boxes or tables, it's like hundreds of lines of code. Like, it just, the amount of, so like all of the things we've thought through and variants and sizing and all that stuff, like icon on the left, we have a hero icon prefix, all that stuff is just handled by basically ChatGPT, but even better. And so my guess is we won't even need a button component. Component, honestly, in a, yeah, once we switch to ShadCN, we shouldn't even need it.

And that's what I was saying, like, it's, think about all the people at Google and Microsoft who made those like system browser buttons, like somebody had to make, those are essentially like old school Shad CDN, right? Because there is, yes, but the problem is they're different across every platform. That was always the bane of every developer designer.

People are like, why ShadCN? Why Clerk? Isn't this just the next whatever? And I'm like, yeah. And if there's a better one that comes by, we'll switch to that. Yeah. I'm not saying this is like the perfect thing, but it's better than what came before. Bootstrap, basically ShadCN is very similar to Bootstrap. But if you act, it's just like Tailwind. A lot of people are like, oh, Tailwind. And I'm like, just use Tailwind and it feels good.

I love it.

Yeah. So fun. And ShadCN is like that. Like whenever I just use everything, I'm like, wow, they thought about everything. And I think it's because basically like Vercel basically invented a lot of the way of— Guillermo specifically invented a lot of the way to do real-time streaming of the backend and the frontend, all these things. Like he did Socket.IO before, sold that to WordPress. And so I literally think like Vercel, vercel.com is like the biggest user of Next probably. Maybe they have some other ones, but if you just play with vercel.com, that's like the best example of what you can do. With Next.js. And effectively, if the only things we should be doing are the things that Vercel has not yet done. So for example, like Vercel doesn't have like document generation for lawyers. So Flexile will, we'll have to build it, write the code for that. But like they've done a button, they've done a search, they've done a combo box. Yeah. And the cool thing is once you switch to ShadCN, for example, all keyboard shortcuts are built into ShadCN. So every, if you wanna add a keyboard shortcut to a button, and you just have Cursor do it, it'll be like one little thing. It'll be like keyboard shortcut R and it just, it'll show the keyboard, it'll show the icon. It'll like all, it'll work. It'll do everything. All of the stuff that like Maya has to think about accessibility, we don't have to think about accessibility at all. We should not be thinking about accessibility. That's not Gumroad's, that's not unique to us, right? We should really, ideally every line of code, like why are we using Clerk instead of just doing our own auth? It's like, but why would we do our own auth? That's— Josh was like, can you do this without Clerk? And I'm like, actually I could, because you just clone another starter kit that has auth. It's not that hard to have an email password table, but we should be outsourcing to Clerk. And this is a very— I think people don't really realize, like, this is like the new form of API is React components, which is like anything that you should think about needing to do. Often has a backend component and a frontend component. So for example, there's the GitHub API, but then you need to design the login with GitHub button. But now we're moving to a world in which actually both of those things are effectively being third-party, and so the frontend and the backend. And the reason that's possible in Next and in no other language is because Next is a full-stack framework, right? It's written in Node, so it can run on the server, but it's also written— it's TypeScript JavaScript being run on the the frontend so they can do all of this middleware magic that no one, no one could do really. And I personally believe, like my hot take that I won't tweet is I think everything will be built on Next.js in the next 10 years, all the way from your personal website to GTA 7, literally. Because if you wanna build GTA 7, why wouldn't you just wanna go to a URL, hit play, log in with whatever, and then start playing the video game. And people say, oh, it's not performant. Actually, JavaScript is only twice as slow as C. So it's completely fast. The only, and you can always push data and computation to the GPU or to the CPU. So we're going to live in a world probably in 5 years where like everything is built with Next. Everything is happening locally and then it's just synced to the database via a very trivial auth layer. Right. So for example, like every Gumroad account, every time you go to Gumroad, you should only be basically referencing a SQLite database that's stored in your browser. Which is how your iPhone works, right? Your iPhone has thousands of SQL. Every single app has its own SQLite database or whatever, and then it syncs, right? If you, you know, if you want offline access, it syncs with iCloud or whatever. That's how Gumroad— every web app— that's what Vercel's trying to do. They're just trying to take native app development, which has been around for 30, 40 years, and make the web that good. But it's hard because it's all decentralized. So imagine you go to gumroad.com, it loads a tiny skeleton. And then that component can render super freaking fast, and then it can render all this stuff within it. But you as a developer don't have to think about any of that. You can just build antiwork.com. Like, I just built antiwork.com, and I just built it. And if I wanted to add a database to it, I could. But if I used HTML, CSS, then— and I want to add a database, I couldn't. And I don't want to think about a server. Who wants to think about servers? So you're just building websites and apps. I got started, I became an engineer because of iOS, because I didn't have to think about the server. I could just think about what I'm building on the client. And then there's a tiny thin layer, which is just basically persistent state, right? If you get a new iPhone, like all this code exists just so you can log into two computers at the same time. So I personally think we're going to head to this world where basically every user has their own database and basically it just syncs. Cloud is just hosting a gazillion user databases. That wasn't possible because spinning up a database was very expensive and slow. So you had one database that you started at the beginning and then you put all your users on it. But imagine if it's like infinitely fast to spin up a database, which it is if you're using SQLite or Postgres, then all of a sudden, why not give every user their own database? Think about how much code— if you wanna do a search query in Gumroad, like on your own analytics, think about how much code exists to make your analytics fast. None of that code needs to exist if you have your own database. Because no user has enough data to make it slow. What the problem is, every single user is on the same database, which means every single purchase is on the same table, which means you can't just do real-time analytics for free. You have to do all of this caching. And like, literally, Chris— and Chris even told me, because I don't know if I'm gonna have a job— it's up to you. You have to change your current job. Yes, will completely be gone, but he's excited about doing a lot of stuff. There's a lot of stuff to do. Like, we have $50,000 a month of AWS that we want to save Right. There's plenty of stuff, but the work we currently do is gone. If you're answering support tickets, that's gone, right? If you're doing fraud and risk review on a, like a first pass basis, that's gone. You might have a second pass basis, maybe one day that'll be gone. Then you'll have a third pass basis. You're like, basically once, for example, once you have a design system, wow, that job's done, right? Like, you no, are no longer doing that. You're just like building more and more features. I think a lot of designers will be product managers just using the design system and AI to build features. Engineers come in and QA it and make sure that it's like secure. Like even with Shortest, I got a DM from someone at Vercel who's, hey, by the way, you probably want to put this route behind auth. And I'm like, that's what I need engineers for, right? But ideally I want everyone to be able to do more.

And the— there's a couple things, a lot of that's great. And I, I think the one thing that I always bragged about Gumroad was Maya. I always said it was the only company I ever worked with that cared about the quality of the output of the design. And that was because of the design system. Now, regardless of how we implemented that through a lot of nested CSS, which to me was super confusing, but it worked on the outside. It really worked. Cause I would demo it and I'd say, look, no matter what pixel I touch on this app, it will be according to— that's because Maya was a great gatekeeper of that to bring it up and say, hey, you're not component, you're not. And she would call me out on it. And that's what I love. So I think it's almost training the UI, training the AI to be like, hey, you asked for an inline button. I guess it's QAing itself because it shouldn't create an inline button.

Like ideally, no. Yeah. Like the reason you need Maya is because she understands all of the nested stuff.

The whole thing in her head. Yeah.

Yeah. And the only reason bugs exist is because engineers can't keep the entire codebase in their head. Otherwise, every time you ship something would be perfect. Perfect, but what if AI eventually will be able to have the entire codebase in its head? Yeah. And so it will basically, that's why I think it's so critical to keep the technical debt to like basically zero, because that's the thing it'll never really be able to understand. Like what's technical debt, what's not technical debt. And the, yeah, basically like the issue with, I think the nested CSS, it's basically you gain incredible consistency, but what you also have to take is brittleness. Which is if it breaks, it really breaks basically. Versus with Tailwind and stuff, it's 90% of a design system, but then you get 10% of the bugginess of, oh yeah, you might have a button over here that's like a bit different or a button over here that's a little bit different. But I do think, by the way, what's gonna happen is like you'll just have the buttons that you can just click. And I don't wanna think about components. I wanna build my app and then I hit a button and the AI looks at the whole code base and says, okay, you have these 7 buttons over here. This is green, this is red. You should be using, ideally everyone like should be using ChatCM. So every component you see that isn't, you should just convert to ChatCM and wrap, wrap it. And then very quickly, I think the AI will basically resolve a lot of these tensions because if you, and actually Maya was like, hey, we should switch Gumroad to Tailwind. Think about the 180 on that. Amazing. There's a credit to her because it takes a lot of effort. A lot of, it's hard to rewrite your prior.

It really is.

Yeah. There's like actually a, and they just. Basically you have to use it to see it is a, it's like a, it's not just like an incremental change. You have to fully lean into it, but effectively, like I think Vercel, because they have layout.tsx and then the components, ideally it almost should solve itself where like the design system is baked into the fact that we're architecting things like in that way. And then you shouldn't see as many like padding issues or like spacing issues. And then ideally if you do, It should just be incredibly quick. Like I think, imagine if we host something on Vercel, Vercel knows all the code and they're rendering all the, all of it. Right. So imagine it's not gonna be too long until you can literally right-click as a designer on something and just say, fix this, do this. And it'll open a GitHub PR. Literally. That's not even years away. I think like 1 year from now, because they're building v0, they're building, like they're doing all this stuff. I think Vercel is like the next AWS. I think it has mass, mass potential. I think everyone said the exact same thing about what people say about Vercel now. It's super expensive. It's not gonna scale. Every single person said that about AWS basically. And if you log into AWS today and you look at our hosting provider bill, like AWS is no longer the frontier technology company that it was. It used to be. Bezos doesn't even, is not the CEO of the company anymore. So that should be evidence enough. But Guillermo's like the new, it basically Vercel, I think is the new AWS, but it's like a— AWS started as a cloud server compute company. And so that's baked into the paradigm. They sell servers basically. And so serverless is basically Vercel is like the AWS of serverless. But because it's for serverless, you can have third-party APIs that do both the backend and the frontend. So like all of a sudden your auth is like 7 lines of code. And then by the way, think about all the code that Razan is writing for Gumroad, for Rollup. For teams, for organizations, for permissions. All of that is handled by Clerk. None of that code. And then if 5,000 companies use Clerk all slightly differently, but because by the way, it's frontend, it's all open source by definition, it's in the browsers. All of a sudden the AI's gonna know exactly how to use Clerk. But the problem is if we have our own permission system that it might be better even then, but the problem is AI's not gonna know it. Then we have all these cursor rules that are like, oh, do this in this way and do that in that way and do that in that way. But if you imagine you just built a feature and it automatically said, oh, this feature should only be— it just knew, oh, this is like an accounting-related feature. Clerk, in the separate part of the codebase, we have an accountant role and we don't show this button for accountants. Therefore, this new feature that I built also should do the same thing and it will just do it. And all of a sudden we can just get rid of almost 95% of our onboarding documentation. Because right now we have an onboarding doc that is, this is how permissions work. This is how roles work. This, and none of that should exist. If you have to put together a doc for what you've built, like you fucked up basically, right? Like something like, for example, like you shouldn't need a design system documentation file that says how the design system works. It should be obvious from the design system. And what's gonna happen? I'm so excited for this. I want Gumroad to be the first company to embrace this way of working. But we're gonna have a design system in Figma. We're gonna pair that with Code Connect with our actual code base, and it's gonna be wrapped around ShadCN. And then all of a sudden, when you go to v0 and you generate something or you go to Figma, it'll all be 100% consistent because that's the dream. The dream to me is you can make a change in our Figma design system, hit save, and it'll know, okay, change this in the code base. Or you can make a change in the code base and it'll error out when you try to push because it'll say, hey, you made this change in the code base, but actually you have to first make that change in Figma. And so all— think about all the stuff in the Figma, like we can't publish our design systems because they're not accurate, right? But Code Connect and all this stuff will basically make it 100% consistent. And then you can go to v0 or any tool and just say, hey, this is the Figma design system. You already know we're using ChatGPT. You already know this is how it's used because that's all that code's being pulled. And then you can say, hey, add a pricing page to Gumroad or add, change this thing or add a footer or do that or whatever. And it'll just do it. And it'll be, and then you just hit one button to commit and push. And even like the, I don't know, there's so many things that I think are just so—

how does Cursor, would Cursor eventually have the VO interface? That's where I'm like, oh, do you copy and paste from VO, then go back in the Cursor, paste it in, then commit?

Eventually, yeah, because Vercel and basically Vercel has access to your GitHub. So eventually it will. Anyway, I do have to run. Stupid 2 o'clock. That's good. I'll post, I'll edit this a bit and post it and catch you guys soon. Thanks, man. Yeah, thank you.