What Happens Now?  Over the last few decades, code hasalways been really expensive. It's gonedown some amount from when we were doingpunch cards back in the day. But for themost part, code has been an expensivething. That's why so many companies hadto employ such a large number ofexpensive engineers. It's why we wereall pressured to go to college to learnhow to code so that we could make themargins work a little better for thosecompanies. That's why we've heard of allthese crazy salaries being taken home bythese people throughout our entire livesfor the most part. I still remember backin high school, where I was pitched thisconcept of Google being the coolestplace in the world to work. And here weare today and everything is changing.Code is no longer this super expensivething that we don’t have a lot of. Ifanything, code is now prolific. There ismore of it than ever. But software, thething that we actually want the code toprovide for us, has become even moreexpensive as a result. It is reallyweird to see this shift happening inreal time. Yes, this is an AI thing, butit goes deeper than that. The softwarewe use is fundamentally changing becauseThe code underneath it is too. I'd go as far as to say this is similar to whencompilers happened, where all of a suddencode wasn't this really hard to reasonabout stuff that had weird syntaxmanaging memory. C made it so you couldwrite code that was a much easier thingto understand as a human. And we stoppedthinking about the assembly code overtime. I think we're going in the samedirection with software as well, wherethe software is the thing we care about,but the code underneath matters less andless. I just saw this article written byChris, and it inspired me to go deep on thistopic. It's a thing I've been thinking alot about. The higher level of thethings we use matters more than ever,but the details are starting to matterless. This hurts me as a developer whocares a lot about software, but it alsoexcites me as a person who cares aboutthe experiences that they use everysingle day. Do you know what you shouldbe using though? Today's sponsor. Guys,it's 2026. Why are we still writing ourdatabases like we're in the 90s? Why arewe running a SQL database so far awayfrom our own servers that we can't trustit to do fast stuff? If we wanted to do a real-timeexperience, like people sharing cursorson the screen or a multiplayer game, whyis our database such a limiting factorin all of these things? Well, the reasonis that you haven't tried today'ssponsor yet, SpaceTime. These guys arefrom the game industry. They know how tomake things that are performant withinsane amounts of throughput for smallsets of users and big ones, too. Theyput a ton of time into building adatabase platform to run their MMO andrealized it's useful outside of theirgame. And then they realized it's usefuloutside of gaming. And here we are today with them shipping a full TypeScriptclient as well as Rust and C#, by theway, so that you can write TypeScriptcode that will run on the same box thatthe data is on. That just changes thedynamics of everything. We're talkingabout paradigms where a user can justhave their cursor's location written tothe database and everyone else can seeit with sync, by the way, without havingto do anything special at all. Thingsthat you would normally never do becauseit will blow up the database just don'tmatter with a model like this. Your table definitions in TypeScriptare awesome. They give you fullstack type safety, too. As you guysknow, I love that. You can then createreducer functions. And funny enough, thedefault language is Rust. Just click theTypeScript button, and you can see it'sliterally five lines of super simpleTypeScript. We have our table. We thenhave our reducer, where a user can nowinsert a new user with an ID and a name. You can even identify the sender to knowwho is the one hitting this thing,because again these queries can faceusers directly. They can just query andmutate the data in the database, and thecode in the database are the same thing.So it all flies. They even have a Reactlibrary that works fully with their Oplatform. Pretty cool to have fora database that's much more focused onthe lower-level stuff. But that's partof what makes FaceTime magical. Theybuilt these rock-solid, super performantprimitives so that you can build ascalable, super performant application.It's one of those products that unlocksthings you could never have builtbefore. And honestly, I'm so excited togo build with it myself. Check them out. Now at sidv.link/basetime.Huge shout out to Chris Gregory forletting me read this article and use itas a reference point for the stream andvideo. I'm super excited to dig in. Thisis a thing I've been thinking a lotabout, and it's such a good way offraming it, too. The barrier to entryfor building software has collapsed. Thebarrier to building something thatmatters hasn't moved an inch. Yep. CloudCode and Opus 4.5 have poured fuel onthe hype. LM tools existed before, butthey're better than ever now. So, a lotmore people are paying attention. Butwe're not entering a golden age of SAS. We're entering an era of personaldisposable software, where engineeringshifts from writing code to shapingsystems, and engineers are stillrequired for exactly that reason. Thisdisposable software piece in particularis something that's really exciting tome. Programs that weren't worth writingbefore because the use case was toosmall and the effort was too high noware absolutely worth it because buildingit is cheap. The thing that's expensiveis figuring out what exactly you wantand specking it out. Down a markdown file, what exactly do youwant? You can get the code much easiernow, which is super cool. The shift inmodern development. Cloud code is takingover my feed right now. Open code moreso mine, but I feel you for sure. What’sinteresting isn’t just that devs arejumping on it; it’s that builders andmakers who previously relied onplatforms like Lovable or Repl.it aremigrating to it. I don’t necessarilyagree there. I think what’s much moreinteresting is that senior andexperienced developers are starting toembrace it too because they are bothseeing the value of these disposablepieces of software. And also they are soused to orchestrating people that cloudcode just feels like another person thatyou’re orchestrating that is way morecapable but way less good at planningand figuring out what it wants to do. Lovable and Repl.it are still totallyviable for shipping fast. But we’reseeing a clear shift as peoplerediscover the inherent beauty of a CLIfirst workflow. When you move theinteraction into the terminal, theabstraction layer thins out. You aren’tjust following a managed UI’s happyPath. You're the one in control. Ifeel like, especially now that I'mhopping between different CLI tools,I feel more restricted than ever. Evensomething as simple as typing in theinterface is frustrating. The option deletedoes something different between CLA code andOpen code, and it's so annoying. Just forexample, I'm going to open up Opencode and Claude code in a randomdirectory. I'm going to type something. Then I'm going to create a new line,type something else, another thing, and starttyping one more thing. Watch what happens when I press option delete. Itdeletes the new line. It should onlydelete to the last alphanumeric character. So, ifI do something like this, the optiondelete should stop at the end of thekebab casing. It doesn't always do that.I'm command-z-ing right now, andit doesn't bring it back. Whereas here,option delete keeps me on the new linelike it should. It doesn't delete thenew line. And if I command Z, oh no,Command Z also doesn't work here. That’sannoying. I hate all of this. Ijust want a real input box so badly. Iknow terminals better than most people. I have been a T-Mux person since I wasLiterally, 14. Well, I was a GNU screenperson because I'm old enough that I wasa GNU screen person, and now I'm a T-Uxperson. I'm trying to wean myself off it,and it's been really tough. Thatsaid, when I'm writing things withmultiple lines, which is very often withthese tools, I hate using the terminalas my input. It's just bad. And a partof why it's weird in open code isthey're using the alternative view modein the terminal, which means they're notusing the standard buffer. And thestandard buffer is what gives you thesestandard behaviors. They have to reimplement all of those behaviors inopen code in order for it to behavewell. That's also why their UI is somuch better than cloud code, becausethey're not just writing into thestandard buffer. But it means that weirdthings I'm used to behaving certain waysin my terminal have to be manuallyreimplemented. I don't feel incontrol as a result. I don't feel like Ihave this level of control over myinstances the way I do in moretraditional software. That said, I havebeen using the CLI things a lot more,and they're cool as hell. I don't necessarily agree with the point thatthe CLIs are giving you this level offull control. This is the part I care alot more about, though. The collapse ofthe barrier to entry. What are peopleactually building with these tools? Ifyou look around, the answer is almosteverything. Even just shipping isabsurd. Pete already had his hundredmillion dollar exit from a big company,so he doesn’t have any traditionalreason to care a whole lot about whatcan make money, but he isn’t lettingthat slow him down. He’s putting outmore software than ever, and it’s allentirely free and open source, andthere’s so much cool stuff in here. Claudebot's the one that's taking theworld by storm. A personal favorite ofmine is Codex Bar, which should besomewhere in here. Oh, it’s number threethere now. It used to be lower. CodexBar is how I keep track of my remainingrate limits across all of my differentsubscriptions for AI stuff. Super cool. The amount of software Pete has shipped injust the last few months is absurd. Andif you look at his GitHub contributionchart, it is actually hilarious. He hasa screenshot of it because I think he brokeIt. Yeah, he's doing like 530 commits onsome days because he just spins thingsup and ships them. Really now, finallyit comes down to how good are yourideas and how well can you describethem? As the author puts it here, theanswer to what are people building? Almost everything. In fact, we'vereached a point of saturation. On onehand, we're witnessing the truedemocratization of software creation.The barrier to entry has effectivelycollapsed. For the first time, non-devsaren't just consumers of software; theyare the architects of their own tools. Istill think we're not quite there yet.There are certain things that will helpus get there. What I'm more interestedin is the really skilled developers likePete and how much more they can ship byusing their existing orchestrationabilities and mindset and multiplyingthat using these AI tools. In the past,if you had a specific problem, you'dspend hours searching for a SAS productthat solved 80% of it. Yep, been thereso many times. Today, the workflowshifted. People are opening a CLI or avoice interface and simply describingwhat they need. Personal software, things likesubscription trackers tailored tospecific budget styles, Chromeextensions that solve very niche dataentry problems, fitness apps with aninterface exactly how the specific userwants it. I've built all of these thingsand more in just the last few weeks.This is a massive shift. Software isbecoming a personal utility that yougenerate rather than a commodity youbuy. This is a thing I think a lotabout. One of the craziest stats tothink about, and I there is no way tomeasure this sadly. How many times isthe average line of code run when youare paid to write code in a realcodebase at work? How much do we expectthat code to run? This is a weird thingto think about because it's not justimportance. When I was at Twitch, Iwrote some very important software thatonly needed to run once for a migration. I wrote some really important softwarethat only runs a few dozen times a weekbecause admins internally were usingthose pieces of software. I also wrotesome things that really weren't tooimportant that run literally thousandsof times a minute because they areFacing users, there are millions ofthose users. That all said, almost allcode that was being written was used atleast a few times, and the average pieceof code, especially the piece of code beingwritten by a professional developer, wasoften run quite a bit. This is shifting. The number of lines of code that arebeing output in a given day has gone upexponentially because these tools makeit so cheap to output code. And the vastmajority of that code will be run zeroto one times. The vast majority of it.It is going to bring down the averageimmensely. It doesn't matter that there’s abunch of code that is run millions oftimes a second if there are millionsmore lines of code that are never run atall. This idea that a given piece ofcode is being run way less isfascinating to me. Another way ofthinking about it is given a specificendpoint, what code runs. Traditionally,when you hit an endpoint, there isspecific code bound to that endpoint.There might be a switch statement orsomething that chooses which sub code,which functions run as a result of theshape of the request. But the actualpayload, the binary that is executing. When you hit that endpoint, it is relativelystatic until you ship a new update. Ithink that's going to change too, wherethe average request is going to resultin code existing that might not havebefore it. And that's a crazy idea. Theidea that a user can do a thing, and theresult isn't that an existing binary isexecuted to solve some problem, butmaybe the endpoint generates new codespecific to the shape of the payload.That something new is created upon thehitting of that endpoint. It's just aweird inversion of how software's workedour entire lives. That is just, it's acrazy thought to me. The closest thingwe've had before is I could send like apayload of JavaScript text to anendpoint that would execute it andsend me a result. But the idea of anendpoint no longer meaning a one-to-onebinding with an existing piece of code,an existing binary, and instead beingdynamic based on the shape of therequest, and the user is just, it's[ \_\_ ] with my brain a lot, and I wantedto talk about it here because it isfundamentally different from howsoftware has worked all of our lives. This idea that code is expensive enoughThat a given endpoint should run thecode that we put all this time and moneyinto, and that the average line of codethat a person is being paid to write isvaluable enough that we should beholding it strong and maintaining it fora long time. That’s over. Now, this is ahuge fundamental change in how softwareworks, that has been keeping, I want tosay "keeping me up at night," butit’s got me thinking in a very differentway than I have historically. From SASto scratch pads. This is another one ofthose things I feel a lot; wherehistorically, I’ve been the guy who goesand tries out the new SAS, tries out thenew database tool, the new framework,all of those things. I’m not doing thatanywhere near as much anymore. When Ihave an idea, or I see somethinginteresting, I hop into my cloud codedirectory on my computer. I just havethis CC sandbox where whenever I havean idea, I go screw with it and see whatcomes out of it. It’s been really fun toplay with. And instead of going to finda solution online to a problem that Ihave to go subscribe to and test out, Ijust stick around in cloud code and itworks really well. Building a full linear clone in Elixiras an experiment in a Ralph loop in thebackground that's been going for 21minutes and is still going. Excited tosee how that comes out. We're entering anew era of software development wherethe goal isn't always longevity. Foryears, the industry has been obsessedwith building platforms and ecosystems.Absolutely agree. The tide is shiftingnow. It's towards something moreephemeral. We're moving from SaaS toscratchpads. Yes, languages like Rustwere built for the name to Rust. Thepoint of Rust is that once you rewritesomething in Rust, you don't have to worry about it anymore. Is it moremaintainable? Yes. But it's also waymore reliable and robust. And when youwrite code properly in Rust, you don'thave to worry about it collapsing theway other things do. Memory leaks,probably not going to happen. Weirdone-off runtime errors that you didn'tcatch in the code. Probably not a thingif you use all of the guards and thecheckers and things within the Rustecosystem properly. The Rust compilermakes it way less likely you make thetypes of mistakes that require software. To be iterated on and replaced. Thatmattered a lot when software wasexpensive. Now that it's cheap, it'squestionable if it matters at all. Thereare certainly places where those thingsmatter, like in your kernel for yoursystem or in medical software or inembedded systems that you can't changethe code for. But a random HTTP servicein Rust? Come on. A lot of this newsoftware isn't meant to live forever. Infact, it's the opposite. People areincreasingly building tools to solvesingle specific problems exactly onceand then discarding them. I did thisfour times in the last two days. This is soreal. It's so cool realizing these weirdproblems you have. Like I was setting upa new Linux box, running a 5090 to dosome local inference stuff a few daysago. Well, yesterday I built it, and Iwas having a lot of annoying problemsgetting it configured on the network. SoI spun up cloud code to go solve it and ended up writing a bunch of scripts toset it up itself. Because funny enough, itdidn't have sudo access. So it wroteall of these scripts, like thousand-plusline scripts to configure the exactthing I wanted once, so I could run oneI command my machine to set up, and thenthrow away the code and never thinkabout it again. That's wild. That issuch a different way of doing things. Inever would have cared enough to do thattype of thing before. This is softwareas a disposable utility designed for theimmediate now rather than the distantlater. What makes this viable today is aspecific technical philosophy: CLI firstinterfaces, local data, and zeroonboarding. When you remove the frictionof signing up, configuring a database,or navigating a complex UI, the cost ofcreating a tool drops so low thattemporary becomes a feature, not a bug. Yep. Like if you have to go learn a newlanguage, framework, tool, orecosystem to try out an idea orsolve some small problem, you're justnot going to do it if it’s not big enough. Andthe size of the problem that’s worth solvingwith code has gotten way, way smaller.That’s one of the coolest things.Everybody has this threshold in theirhead. Like if there are problems thatare large but easy to solve, obviouslyyou’re going to try and solve them. Ifthere are problems that are difficult tosolve and not that big, you’re obviouslyI'm not going to try and solve them. Everybody has a line somewhere here.Some people literally just do ithorizontally. I've seen this before,where there's a certain type of personthat doesn’t really care about how harda problem is. They just care about howmuch it bothers them. And if it bothersthem enough, they'll fix it no matterhow difficult it is. Somebody likeLinus Torvalds is a good example herewhere the problem of source codemanagement was annoying enough that hedecided to fix it. The problem of nothaving access to Unix was annoyingenough that he decided to fix it. He doesn’t really think about how hard itis. He just thinks about how much itbothers him. There are also people whoare the opposite; they only thinkabout how difficult it is to solve. If aproblem is easy, it doesn’t reallymatter how big or small it is. They’lljust solve it anyway because it isn’ttoo hard for them to do. Most peoplehave a sliding scale more like this;where as the problem gets moredifficult, the size of the problem hasto increase accordingly. Everythingin this area here, they are down to solve. Because the size of the problem isbigger than the difficulty. Buteverything in this section here is lesslikely to be solved because the problemis annoying or tedious, and the size ofit isn’t very big. What’s been fun forme is this area of problems that aren’tvery big but are hard enough that Iwouldn’t bother with. That’s beeneradicated. This whole section here isso fun to just vibe and code it out. Likewhen you’re trying to transcode a bunchof random old files, or you’re trying tofind a picture of your dog, or you’retrying to reconfigure your Zsh scriptsto do something different on yourmachine. Problems that maybe cost you afew minutes every couple of weeks that justweren’t worth dealing with beforesuddenly can be solved. And what’schanging right now is the size of thedifficulty of the problems these toolscan resolve is just growing constantly. Opus was arguably a shift where thisline went from here to like here. It’shard to find the limit of what Opuscan’t do given the right tools, theright prompt, and the right set of evalsthat it can use throughout itsdevelopment process. That’s crazy. This is also why we’re getting more andmore of these small one-off things andwhy people are using these tools in suchcool ways to just solve a random problemthey have. I know I’m doing this a ton. I’ve never written so much software thatI never bothered even putting in a gitrepo. It’s crazy to think that themajority of the code I’ve written in thepast month—well written—is not even ina git repo because I don’t care; becauseit’s just there to do one thing once. I’m probably at like 50,000 lines ofcode that I’ve just thrown away afterusing it once in just the past coupleweeks. It’s crazy. As Chris says here,if it takes 5 minutes to spin up acustom solution for a one-off task, youdon’t need it to persist. You don’t careif you need it again in the future. Youjust regenerate it the same way. Whocares? The contrast with the traditionalSaaS model is stark. SaaS is inherentlybuilt to optimize for retention, lockin, and expansion. It’s a business modeldesigned to keep you inside theecosystem and grow your footprint. Bespoke tools, on the other hand,optimize for immediacy and control. Value as a customer. They only careabout solving the task at hand. In manyways, this is a return to howspreadsheets were originally used. Thatis such a cool comparison. Spreadsheetsare the start of so many incredible,revolutionary things in software. One ofmy favorite talks ever is RethinkingReactivity by Rich Harris. I still goback to this every year or so, just tolet it break my brain again. And a hugepart of the intro for this video istalking about spreadsheets and howpowerful they were, even when softwarewas still in really early days. And somuch of what we’re talking about now does definitely remind me of the oldspreadsheet era in a really cool,nostalgic, but also powerful way wherespreadsheets made computers go from thisthing that hardcore nerds could do, likesilly games with, and like solve somecomplex math problems with, into a usefultool for day-to-day people. Managing theinvoices for their business or keepingtrack of the schedule for their hairsalon. Spreadsheets made it possible foranyone to do whatever they needed thatinvolved numbers and timings on acomputer without having to write. Software and knowledge of how code works. Youdidn't open a spreadsheet to build apermanent multi-year database, using it asa scratch pad to reason through aproblem, calculate a result, and moveon. In this new landscape, cloudcode is Excel for developers, a powerful,flexible utility for solving immediateproblems rather than Shopify forfounders, which is built to be apermanent foundation for a business.It's about getting the job done rather thanletting the tool go. I absolutely agreehere. This is one piece I think alot of people are missing. If you happento be one of those people working onproblems that involve cloud code, codeex,cursor, open code, whatever struggleswith even the best models, I would wantto see more, because I just haven't seen muchthere that isn't a prompting issuehonestly. But even if you are one ofthose people in one of those spaceswhere it's hard to use these tools tosolve real problems, there are peoplelike Linus Torvalds, the creator of Linux. That doesn't mean these toolsaren't useful to Linus, though. Infact, he's even been contributing toCode that matters for the actualpackages, but code for things likevisualizing his weird audio extensionthing that he's building. Code toconfirm the work you're doing works orto test out a theory or to experimentvisualize. All these types of thingsthat used to be really annoying to dowent from really annoying to trivial,especially in places that you might notunderstand. Well, like if you're a webdev or even a kernel dev that doesn'tknow Python, well, using these Pythonlibraries is now trivial. But in orderto do that, you have to do this reallyimportant thing that a lot of devs seemto struggle with: letting go. You haveto be okay with the fact that the majorityof the code being written by you isgoing to be thrown out. Most of it won'teven be run at all. Some of it will berun once and then thrown away after. It's a weird feeling, but once you getover it, life gets way better. But thisis where the thesis of the article comesin. Generating software quickly is onething. Making it survive contact withthe real world is a whole differentthing. Code is cheap. Software is stillexpensive. In the current AI-native era, code has becomecheap, but software remains incrediblyexpensive. LMS have effectively killedthe cost of generating lines of code,but they haven’t touched the cost oftruly understanding a problem. We’reseeing a flood of these apps that werebuilt in a weekend, but most of theseare just thin wrappers around basic CRUDoperations and third-party APIs. Theylook impressive in a Twitter demo, butthey often crumble the moment they hitthe friction of the real world. I wouldsay this depends a lot on what the roleof the program is. Like we havevibecoded a bunch of things for mycontent channel. In particular, Ben isgoing hard on rebuilding all of ourinternal tooling for managing things like which sponsors are on which videosand how well those videos areperforming. That is more than holding upto our real-world test. Could that scaleto thousands of users? Maybe not. But itis a piece of software that is resilient,that is on the cloud, and that we are usingevery day without issue. So there’s abalance here again of how manyusers, how deep are the problems thoseusers are experiencing, how much varietyIs there a difference between the users and how doesthe software we write scale againstthat? But problems that are reallyspecific to you, that don’t need to havethese other considerations, can be morethan real-world ready. But it depends onwhat world you’re talking about. The cost of software isn’t the initialwriting; it’s the maintenance, the edgecases, the mounting UX debt, and thecomplexities of data ownership. These fast solutions are very brittle. Thesubscription tracker you codedbreaks the moment a bank changes theirCSV export formats. The Chrome extensiondies the second a target website’s DOMshifts. The fitness app becomes unusableas soon as a user needs robust offlinesupport or reliable data sync. For the latter, use Convex. It helps a lot. Onthat note, though, actually I think a lotof these problems can be solved bybetter tools to fix these things. Like the CSV format change could be anintermediary tool that will reformat the CSVusing AI or detect when the formatchanges and adjust accordingly. Like these inputs and outputs being moredynamic is a thing I expect to see inthe future where if an error rate isDetected on this input or output that itcan adjust the code accordinglyautomatically. That I could absolutelysee happening and being really, reallycool. Or things like offline support andsync, those come down to the primitivesyou're using to build the data layer. And if those primitives evolve enoughthat they work right out of the box,these problems are solved just by usingthe right tools. And more and more, Ithink that's going to start happening. Chris has been seeing lots of doomsayingon Hacker News, Reddit, and Twitterabout the end of engineering. Thismisses the point entirely. We aren'twitnessing the end of the profession.We're entering a new era of it. I agreehere. I don't know what this will looklike long term though. Like how manyengineers do we need for this? What aretheir day-to-day tasks like? Everybody asks mewhat I think software development will be likein 2030. I don't know what it'll be likein March. But I know it will bedifferent because it's very differentnow than it was three months ago. And if youhaven't felt any differences, then youhaven't tried these things enough. Thevalue of an engineer is shifting away fromThe how of syntax and the what and why of systems. Real engineeringlies in the abstractions and thearchitecture, as well as thecommunications and the orchestrationacross all of it. Like who is working onwhat, when will it be done, and what do weexpect from this. All of that is askill that leaders have that traditionalprogrammers don’t. And leveling up thereis super important. I just filmed avideo all about that—about why seniordevs are liking these tools more. It’sall about knowing how to structure asystem that lasts, understanding why aspecific rate limiting strategy isnecessary, knowing how to manage adistributed cache, and knowing exactlywhen not to store environment variables. Man, environment variables are possiblythe single biggest problem a lot ofthese tools have. That andauthentication, authorization, and allof the layers around it make all ofthis more annoying than it should be.I’m hopeful that we’ll see leaps andbounds type solutions that make thisstuff way better in the near future.We’re not there yet. It often feelspowerful because it hides theComplexity. But as an engineer, your jobis to manage that complexity, not ignoreit. The tools have changed, but thefundamental requirement for engineeringrigor has never been higher. I don'tknow if this will change or not. I'vebeen thinking about this a lot. Like ifthe models get twice as good again, willthat rigor matter as much? I don't know. I actually don't. Maybe the models don'teven need to get better. They just needbetter tools to recognize when they'redoing things wrong or bigger contextwindows to keep track of what they'redoing right. I don't know. But then wehave the distribution illusion. There'sa flip side. With the barrier to entrygone, the noise level has reached anall-time high. My feeds are currentlyflooded with AI entrepreneurs claiming 5figure monthly recurring revenue numbersfor apps they built in an afternoon.Most of these are [ \_\_ ] and failsuper super fast. Even just today, I waslooking for ways to manage all of myvibe coding stuff in parallel. And Ihave been sent three options that seemto have just appeared all at once. Wehave Autoclaude, which lets you have aKanban board for managing all your tasks. Code instances, Vibe canban, which issimilar to Open Codeexand all the other solutions too. Andautomaker by Webdev Cody, good friend inother awesome YouTube channels worthwatching. He's ahead of us on a lot ofthese things. He's almost perpetually sixmonths to a year ahead. He built thiswith similar goals. These are all opensource projects that do roughly the samething that seem to have just appeared inthe past week or two. And this is goingto keep happening as more and morepeople spin these out, and distribution is going to matter more and more. Howfast you can write code and how well youcan write code matters less, and how faryou can distribute that code, howrelevant the thing is, and howwell you can communicate that to theworld matters more than ever. Also, it's goodto see you in chat, Cody. Hope you'redoing well. Seriously, go give Cody afollow on YouTube if you haven't. If youhaven't subscribed to me, subscribe tohim first, then hit the subscribe button forme. But he's so far ahead of this. But anyways, it turns out the authoragrees. These claims are highly suspect.When you see a creator with no existingDistribution and no clear moat claiming10K MR on a weekend project is usually aplay for engagement rather than areflection of business reality. Some ofthese stories are probably true, but inmost cases, they aren't actuallyblueprints for technical innovation. They're marketing case studies. Theseindividuals succeed because they havemastered the art of capturing attentionin a crowded landscape, not because theyhave an AI co-pilot. Yep. These otherskills matter more and more. Again, Ijust filmed this video and it's crazyhow relevant a lot of my points are now.But the idea of capability being thething that matters for engineers justisn't true anymore because AI has leveledall of our capability up. What'shappening is people are realizing theother parts matter more than theythought before. If you don't have theability to be clear in what should bebuilt to delegate across these agents toorchestrate the whole thing and thenexplain to the world why it matters, it doesnot matter how much code you cangenerate. Previously, we would holdthese engineers up high because theircontribution charts were impressive. Nothing they were doing was useful. Ifyou can't communicate the value of thethings you're doing and be very clearand concise in why I should use yourthing, nothing else matters. And justbumping your capability up a ton doesn'tsolve any real problems. We've enteredan era where the ability to generatecode is no longer the bottleneck. Thereal challenge has shifted todistribution. Hi, good time to have aYouTube channel, isn't it? By the way,if you're building something reallycool, you raised money and you don'tknow how to get it to people, my DMs areopen and you can get my email forpotential sponsorship stuff on my YouTube channel very easily. YouTubeatt3.gg. This is what I'm here for. Moreimportantly though, distinguishing thegenuine utility from the get-rich-quickposturing that has become so prevalentin the industry. I have done so much ofthis for brands, like the majority ofthe sponsors I bring on the channel, Idon't do an ad after they pay me, atleast not immediately. Most willeventually do the ad, but I'll oftenhave to do three to six months of backOnboarding, fixing their go-to-market,helping them rebrand and structure thepitch for their product. It takes a lotof time to do that for some companies. And it's crazy; almost half of thebrands I've worked with have, through theprocess of me refining the pitch, rewrittentheir whole homepage just to match abetter way of describing what they'reactually here for and why you shouldcare. The question of why you should care is a muchmore important question than everto answer because you have morecompetition than ever. If you have agreat idea that’s hidden underneath yourinability to talk about it, somebodylike me can just come in, steal theidea, vibe code an alternative, and communicateit better, putting you out of business.Being good at talking and describing whyyour product matters has never been more important. If a brand has me up to sponsorand their product just isn't there, ortheir marketing just isn't good, and Idon't know how to help them describe it,it might be easier for me to just stealthe idea, go vibe code my ownalternative, and sell that than it is forme to teach the brand how to domarketing. These people haven't stumbledUpon a secret shortcut. They've simplyfound a way to execute their existingadvantage faster, and they potentiallyunlocked it in the first place iflearning to code was rightfully too bigan undertaking for a side project idea. Here's where my hot takes are going tocome in. I don't think you could besuccessful at selling software if youaren't highly motivated. If yourmotivation led to you becoming a greatprogrammer, awesome. If that motivationis strong enough that it can now bringyou to learning how to communicate aboutyour ideas better and show people anddistribute the things you're buildingbetter, awesome. But if coding was toohard for you to learn, now you can codefor free. The rest is just as hard, ifnot harder. Explaining an idea conciselytook me as much time to learn asJavaScript did. And if anything, I amcontinuously learning with both, but I'm learning more about communication andclarity every day than I am aboutJavaScript. And if you aren'twilling to sit there and learn thosehard things, you're not going to goanywhere. If you learned how to code 10When you were motivated, and nowyou've just been coasting for 10 years,it's over. If you don'thave motivation, you're not going to goanywhere. I felt this a lot because I ama content creator. I'm going to sharea little bit of an anecdote here, butit’s one that’s important to me. It’s areal interaction I had. We’re going to start this with a weird poll. You’re ina plane. Imagine you’re flyingsomewhere on a passenger aircraft. The pilotis suddenly incapacitated.They had a heart attack. They fainted. Somethinghappened. Can you land the plane? Yes,maybe, or no? If you know how peopleanswer this, don’t spoil it in chat. I wantto see what you actually think. And you,the viewer, too, think this in yourhead. If you’re on a Boeing 747 or somethingsimilar and the pilot goes unconscious, can you gointo the cockpit, assuming you have theability to go in, sit down, and everything’sfine there? Can you land the plane? Less than half of my audience is saying no.Here’s the harshreality: if you’re not alreadycertified, you’re not going to land thatairplane. They land themselves. Like specifics, making surethe right flap is down the right amountbased on your current velocity. It helpswith a ton of that. Ninety-nine percent of you won'teven get the radios working.You're not going to land that plane. The reason I asked this isthat most people assume they can do athing that is highly skilled if they hadthe opportunity. Most people think theycould be a successful founder if onlythey had enough followers on Twitter andthey knew how to code. Most people thinkthey'd be a great Google employee, butlearning to code is too hard. Mostpeople think they'd be a great YouTuber,but editing video and OBS are too hard. If only these tools were easier to use.If only video editing was lesscomplicated, then everyone could be aYouTuber, because that's the hard part.That's the first problem you ran into.The radio thing even happens to anextent here too. If the airplane radioswere easier, everyone could land theplane. No, you can't. Berealistic here. Thirty-four percent of men answer yes tothis question. Fun fact, the majority ofmen think they can land the plane. Ibring this up because of a realThe conversation I had was abouta year and a half, maybe two years ago. I was talking to a developer andhe said, "Basically, I’m looking todiversify my income sources. I’m goingto pick up YouTube. Any advice for me tohave a successful channel with as littleeffort as possible?" The way I raged,I had multiple witnesses to the secondversion of this conversation because hefollowed up the next day, which isreally funny. I’m thankful I did because Iwould have gone insaneotherwise. Do you know what hisreasoning was for thinking he could dothis? Well, I kind of like cameras andtalking's pretty easy. I don’t see why it would be hard for me to be aYouTuber. Seems like it’s pretty easywhat you’re doing, Theo. Yeah. So, wherethis really fell apart was when I askedhim a quick question. What YouTubechannels do you watch? Do you know whathe answered? Honestly, I don’twatch YouTube very much. Thisinteraction has haunted me for 2 years.Because this is how most people work.This is how most people think. Theylegitimately believe that whatever thething in front of them right now isThat's in the way is the only blocker. And if they could just get that out ofthe way, it'd be so easy. Like aftersaying this, he didn't even let me startto interrupt saying, "If you don't knowhow YouTube works, this is probablygoing to be hard." He quickly says,"I don't watch YouTube that much. Whateditor should I start using?" Are youjoking? I justYeah, I don't know if you guys know thisabout me. I watch a disgusting amount ofYouTube. When I'm not at aconference or in meetings all day, I'lldo six to eight hours of YouTube a day.Like, straight up. I love the platform.I love watching other creators. I watcha lot of YouTube. And I did thatfor a decade and a half before I everthought to make a channel of my own. Ididn't even want to. My channel happenedaccidentally because I was doing Twitterspaces and wanted to show people in amore visual way what my stack was. So, Idid a live stream and then reuploaded onYouTube so I had something to link to. And now I have this YouTube channel thatbasically runs my life and mybusinesses. This was not something Ichose to do. This is something I had toI had specific problems I wanted to solve, and all of those ledto me being here. None of the bestYouTubers chose to be a YouTuber. Theyended up here. Other things they wantedbrought them here. This guy caredtoo much about camera equipment andvideo editing software to realize thathe didn't care about YouTube. It's justinsane to me. The reason I did theairplane thing just now is because thesecond time this guy had theconversation with me, there was a cameraDP standing next to me. Somebody whocame from the Hollywood world, switched over to software dev, whooverheard this whole conversation andfelt like he was going mad. As soon asthis person walked away, he pulled measide and was like, "What doeseverybody just think that way?" Like,how does somebody actually believe theycould just be a YouTuber when they don'tknow anything about it? I asked atfirst, "Do you think you could land anairplane?" He's like, "No. Whycould I land an airplane? I did videoand now I do code." It's like, watchthis. Then I went around the table andasked every single person at the table. "Do you think you could land a plane ifthe pilot's incapacitated?" Every singleone said yes or maybe. Nobody else saidno. This is the delusion. It's kind of aDunning-Kruger effect, but it's deeper thanthat. Most people think that they wouldbe incredible at whatever thing they seein front of them if only this randomthing directly in front of them wasn't alittle too hard to get over. CodeBradley in chat here said, "As someonewho's been in marketing for 15 years,everyone thinks they could be a goodmarketer." Ready for a real honestymoment from me? I didn't think I couldbe. One of the first things I wasplanning on hiring for T3 tools, aka ping, aka now T3 chat. I was planning onhiring a marketer really early because Ididn't think I would ever be able tobuild that skill. That and sales. Turnsout I’m okay at those things. Actually,I would go as far as to say I'm pretty damngood at those things. But I had to learnthose and scale up in them out of need.I didn't go in thinking I could do it ifonly my inbox was easier to manage. No,I went in humbly expecting to struggle withthe thing and slowly got good. So, allof that was a tangent because I don'tI necessarily agree that unlocking theaverage person's ability to code isgoing to push them past the next step. If the friction of learning a videoeditor or learning how to set up and useOBS or figuring out what camera youshould use is enough to keep you frombeing a creator, if I hand you solutionsto all of those problems, you're goingto be a [ \_\_ ] creator still. If you're sounmotivated that learning how to codewas too much friction for you to go dothe thing, you're going to be a [ \_\_ ]founder and marketer and business personas well because there are just as manyhard friction points you'll hit. Many ofwhich are even harder when it comes to marketing and distribution. You're justnot going to succeed there. Ifyou don't believe me here, then youdon't have a following yet. Go make aTwitter account and get to 10,000followers. Hit me up when you're done.There's a useful framing for this shift.AI has effectively removed engineeringleverage as a primary differentiator.Yes, this has been a weird one for mebecause I have had a specific set ofedge skills that basically don't matteranymore. A valuable asset in my previous jobs wasthat I could come in and take a projectthat was way behind and get itback on schedule without compromising onquality or capability. I am reallygood at taking a long roadmap,figuring out what to cut and shiftaround in order to make it actuallydoable in a reasonable amount of time.I’ve always been the fast ship guy, andthat doesn’t matter anymore. I was avery rare type of engineer before thatthat everyone can be now. Claude Code doeswhat I did at Twitch, faster, moreefficiently, and cheaper. And that’swild to think about. That was a ton ofmy leverage. I would just ship thesolution faster. If you can go prompt in cloud code and get the solution outjust as fast, that doesn’t matteranymore. Thankfully, I’ve also leveledup these other skills around marketing,communication, distribution,orchestration, and all these other thingsthat matter even more. So, the fact thatI don’t have a unique lever here anymorebarely even matters. But all of myfriends who worked this way too are[\_\_]. When any developer can use anLLM to build and deploy a complexThe feature in a fraction of the time itused to take, the ability to write codefast, especially, is no longer thecompetitive advantage it once was. It isno longer enough to just be a builder. I couldn't agree more. Instead, successnow hinges on factors that are muchharder to automate. Taste, timing, anddeep intuitive understanding of youraudience matters way more than ever. Youcan generate a product in a weekend, butthat is worthless if you're building thewrong thing or launching it to a roomfull of people who aren’t listening. Yep. Or even better, an empty room,which is what most of y'all do, and thenyou complain that the algorithm is sobad. If only the algorithm was better,everyone would know about my slop app.Good luck with that. In this newenvironment, the code has become theeasy part. The hard part remains exactlywhere it's always been: finding a way toget people to care. Another way of framing this is that previously code washard enough that you needed a lot ofcoders once you had someone in somethingthat was worth caring about. If it turnsout Twitch is worth caring about, ittakes a lot of engineers to build all. The pieces. So for every one person whounderstands this and cares enough aboutthis to do all of the other parts, youneed a team of 10 to 20 engineers to dothe rest. Now that part isn't asimportant, or at least it's not asimportant in the same ways as it was, andis much easier to automate. The hardpart still exists, but if you're just anedge, you are just the accessory to theleaders who are actually getting thething out there. You're useless now toan extent. And that sucks. And this iswhere I think a lot of the insecurity iscoming from; it is that 20 to 1 ratio of 20 good engineers to one person whounderstands the thing that they'rebuilding. That ratio went from 20 to oneto like one here. So when I was theother 19 engineers, I don’t know. I’mnot trying to hire them. So who winshere? First, you'll have domain expertswho are stuck with boring, repetitiveproblems. Then there are internal teamsbuilding throwaway tooling, the kind ofscripts and internal apps that need towork immediately rather than lookperfect. There are whole billion dollarcompanies that were built just aroundthis. My co-founder Mark, my CTO, wasWorking at Retool before he joined mycompany. Retool was a way to build mucheasier internal dashboards that accessdata across all the different placesthat your company might have data from. So some internal support team that needsbetter visualizations of how much usagea user has on their account when they'redoing support. Some random person onthat team that's not even an engineercan whip up something in Retool tomanage it. Now with vibe coding and allthese other tools, the ability for acompany or even an individual to do thesame thing reduces the value of a toollike Retool. They got to a very, veryhigh valuation very, very fast becauseeveryone needed tools like this. They were getting contracts witheveryone from Philips and Pinterestto Stripe and Amazon, which is a wildrange. But now, it barely matters. They aretrying desperately to catch up with allthese other AI alternatives that nowexist. That market is huge — huge enoughfor Retool to become a multi-billiondollar company. It's also addressed wellenough now for Retool to be strugglingto survive. Power users also see aThey are looking to replace brittlemanual workflows with something morerobust. Finally, it's a win for thoseengineers who prioritize ownership ofthe solutions over high-gloss polish. And yes, tools like Opus 4.5, ClaudeCode, and Cursor are genuinely usefulfor engineers. They are remarkably goodat removing boilerplate, implementingfeatures, and writing unit tests. One ofmy favorite use cases lately, especiallysince starting a new job, is generatingpersonalized documentation andwalkthroughs of features to get up tospeed on product codebases and how allthe nuances work. It's been extremelyhelpful in getting up to speed. Yeah,it's so nice having AI that canunderstand a large codebase well enoughto give you useful insights. But here'sthe reality. LMS are far from perfect atwriting code, even if it compiles firsttime. Even with the high qualityprompting and clear rules, these modelswill still make mistakes. Speaking assomeone who uses these tools every day,you cannot simply trust the outputoutright. You still have to review thecode as if it were a pull request from ateammate. You have to read the logic. Check the assumptions and often makemanual edits to get it right. I amstarting to drop this part. I'll justtell the model what it did wrong, and itwill fix it. I am suspicious thatthe amount of this will go down more andmore, especially again to go back to mychart earlier. If the problem size issmall enough, I'm not going to botherreading that code. If theproblem size is big enough and thedifficulty is big enough, I'll probablytake the time to read the code. But itvaries and how you think about thesethings will vary a lot. After all,you'll likely be sending this to a teammate for review and maybe CodeRabbit, I guess. Okay, to be clear,tools like Code Rabbit, Grappile, and allthese AI code reviews do those beforeyou send it to your teammate becausethey will catch small annoying mistakesthat your teammate shouldn't be dealingwith. I know those companies sponsor me.I don't care. They're super useful.AI code review is a way to notwaste your team's time doing a codereview. Super useful. Your teammatesstill should review the code,absolutely, but they shouldn't beReviewing it for small syntax mistakes. They should be reviewing it forunderstanding of the codebase forreducing bus factor and making sure whatyou’re doing is aligned with the goal ofwhat needs to be done. AI isn’t great atthat, but it’ll catch all your stupid[ \_\_ ] syntax and weird one-off errorsmuch better than a human will. Don’twaste people’s time with that [ \_\_ ].This is a really good question. Is itfair to make them review something youdidn’t even write or bother to check?Humans, no. AI, absolutely. Letting anAI review code that an AI wrote isawesome, and you should absolutely dothat. These tools help you move faster,but they do not replace the need for acritical eye or your years ofexperience, and they do not understandthe overall problem space better thanyou. The hype makes it look like we’reentering a golden era of SAS. We aren’t. We’re entering an era of personalsoftware, tools you generate to solve aproblem, and then move on. With $20, afew hours of spare time and a bit ofpatience, almost anyone can ship afunctional app. We’re entering the eraof personal software, where the gapBetween an idea and a working product isnarrower than it's ever been. In thisnew reality, engineering expertiseremains incredibly valuable, but thenature of the role is shifting. Relevance is not fading. Instead, it'sabout leveraging these tools to build ata higher level than was previouslypossible. True expertise is now requiredto steer these systems and provide thetechnical oversight that LM lack. WhileAI is undeniably good at writing code,it remains poor at architecting,maintainable, distributable, andscalable systems. This is wherenontechnical leaders who think they canfire their development teams are makinga significant mistake. Until we see thearrival of an artificial intelligencethat renders this entire discussionmoot, believing that technical expertisecan be replaced by a prompt is astrategic error. I fully agree here. Building robust software still requiresa human who understands the underlyingprinciple of the craft. A different wayof framing this is that hard problems are stillhard, and motivating yourself throughthem is the key. A highly motivated vibecoder will take the time to figureFiguring out why things are breaking andlearning them will be way more valuablethan an experienced engineer who’s kindof checked out and is just not payingattention to the code they’re merging. Motivation is going to be the keydifferentiator. Do you care enough toskill up in the areas you don’t know?Because if you’re willing to sit thereand ask endless questions to the AI tofigure out where your knowledge gapsare, figure out what might be goingwrong, and try all these differenttheories, the patience and diligence,and resilience will matter morethan ever. If you’re already burntout and can’t find excitement inwhat these tools enable, you just feelfrustration and tired, you’re probablynot going to survive this transition.You need to have the motivation to pushthrough. You don’t just need the skills.I would argue you could build thetechnical expertise faster than everwith enough motivation, but you can’tget that motivation by just having theexpertise. The bottom line is that whilethe tools have changed, the fundamentalsof good engineering have not. The barrier to entry may be gone, but judgment,taste, and responsibility are still thejob. I absolutely agree. This was afantastic article. I know I didn't agreewith all of it, but the framing wasincredible, and the majority of it ismore than on point. I have a feelingI'll be keeping a close eye on Chris andthe other things he does. It turns out he'salso a big Elixir and Live View fan. Ilove Elixir, so I'm hyped. In fact, as Imentioned before, this whole time I havebeen running this gigantic project inthe background, which looks like itactually finished in 35 minutes and 50seconds. So, I'm going to go play withthat. I got nothing else to say here.Stay motivated, keep building, and keepdoing cool things., What Happens Now?, YouTube, 01kf10jd664q88bjwr5eajfet5.