I can't believe he was right.  Remember back in March when Daario saidthis: "If I look at coding programming, which isone area where AI is making the mostprogress, what we are finding is weare not far from a world — I think we'llbe there in three to six months — where AI iswriting 90% of the code." At the time, Ithought this was one of the most absurdstatements I'd heard any tech CEO makein history. To be fair, hewas wrong; it actually took nine months. Boris is the developer in charge ofCloud Code. He did an update a few daysago talking about how originally, CloudCode was a side project, and now it haschanged how he writes code. Now hebarely ever opens an editor. Everysingle line that he has done in the last30 days across 259 PRs wasdone in Cloud Code and Opus. Literally,100% of his contributions to Cloud Codewere written by Cloud Code. Even here,like, yeah, he's an employee at thecompany; of course he’s going to saythat. But then I started using CloudCode with Opus more. I built the Chromeextension to lock me out of Twitter whenI don't have Cloud Code running toincentivize me to use it more. I built a whole new image generationstudio with a separate conversation view,where you can pick the photo you likeand do follow-ups with it, with a moredynamic editing experience. And then Imade it a mobile app, too. If you wantthe details on all of that, a wholeseparate video about how I use CloudCode is coming very soon. Make sure yousubscribe so you see that. But that'snot what I'm here to talk about today. Iwant to talk about what Daario said onthis panel, as well as the part rightafter that, which I feel is often skippedwhen this conversation happens and whatthis means for us as developers becauseeven if his timeline was slightly off,Daria was absolutely correct. And sinceI might not get paid for writing codeanymore, let's do a quick sponsor break. There aren't many companiesthat can proudly state that GitHub isscared of them, but today's sponsor isone of them. Depot is so much better atrunning your GitHub actions thatMicrosoft nuked the whole GitHub brandjust a few weeks ago, trying to tax youfor using it. They have since delayedthose changes, and even if they madeDepot is that much better. We're talkingabout real-world performance improvementsin the range of 37 times for a project likePostHog. And remember, PostHog's opensource. There's no magic tricks here. You can go look at the code yourself andsee when the action suddenly startedtaking this much less time. We'retalking a difference of over 2 hoursfrom a minute and 50 seconds to 4minutes. Let's be real super quick. Howmuch of your time are you wastingchasing down failing builds that arefailing for no reason? How much time areyou spending waiting for your builds tocomplete so you can actually merge thecode that you're changing? How muchhesitation do you feel to push up a newchange because you know the CI is goingto take another hour or two to runbefore you can do anything? Imagine lifewithout any of those problems. Imagineyou put up a PR and the build justworks. There's no random errors or failuresthat you hit because GitHubactions are unstable. Imagine they'rehappening in seconds instead of hours.Imagine life without the hell that iswaiting on CI. If you haven't tried themyet, you're wasting your time. Fix that. Now at soyv.link/depo.So, first and foremost, I want to gothrough Daario's whole statement withyou guys.>> I do have a fair amount of concern aboutthis. On one hand, I thinkcomparative advantage is a very powerfultool. If I look at coding programmingwhich is one area where AI is making themost progress, what we are finding iswe are not far from a world where AIis writing 90% of the code.Then, in 12 months, we may be in a world where AIis writing essentially all of the code. When he first made this statement, I dida response because the way this ismeasured is going to be really tough.First, we have to define what thecode is. What is 90% of the code? Are wetalking about the code people are paidto ship to production? Are we talkingabout the code being written atcompanies like Google and Microsoft andEnthropic? Or are we talking about allof code created from all of places?Because I would imagine that the amountof repos being instantiated and theamount of code being written by toolslike Lovable and Vzero and Bolt is significant. Of these types of things, just by sheernumber of lines, has changed the amountof code being written year-over-year ameaningful amount. I would be reallysurprised if we had less than 2x theamount of code written this year fromthe year prior, as in 2025 to 2024. Iknow it's 2026 now. I'm sorry, guys, butyou get the idea. 2025 probably had 2xthe amount of code or more written andproduced than in 2024. Does most of itgo in a garbage can? Sure. But way morecode came out. We can't disagree withthat. That's just table stakes. Wehave to agree, no matter what side we'reon, that way more code happened last year. That said, actual studies havebeen done on the numbers for realbusinesses. And according to Google'slittle AI summary thing, from realstudies,industry-wide, the number is a little bitlower. Apparently, 30% of code atMicrosoft is AI. Sundar said over 25%was written by AI as of late 2024. Idon't know if we've gotten an updatesince. Here's where things start to getcrazy, though. For senior devs, inrecent surveys, 32% report that at leasthalf their code is coming from AI. And more senior developers are the ones sayingthat lots of their code is coming fromAI. This is one of the biggest shiftsthat happened in 2025. It's no longerjust developers who are autocompleting some oftheir code. It's no longer justbeginners who don't have the skills thatare using AI to make up for a skill gap.It's now experienced developers usingthese tools to make up for a time gap.And I found myself doing the same. Thereare so many random ideas I have forsystems, projects, features, and juststuff I want to fix in my codebase. Asthe tools get better, the harnessesget better, and of course, the models get better, the idea that this random thingthat maybe I would have previously cut aJira ticket for, that would have sat in apit of backlog forever, now I can justthrow it at Opus, get some code, reviewit on GitHub, and merge it. There's alsoa problem here around what our jobs are.I ran a quick poll to see how muchpeople like code review. As we seewith the initial results, 50% say they hateit. Even though there are four optionsthat are neutral or better. Now that thepoll has continued, it’s fine, buttiring is going up. 26% saying hate it, 10% saying neutral,and 45% saying it's fine, but it'stiring. A very small percentage of developerslike or love code review. I'm in thissection. I would argue I'm in the "like"it section. I do enjoy code review. Iwish I could justify doing more of it,but my schedule is utter chaos. However, Ilike code review. I also think this isjust one of those things that you haveto get over over time as you become amore experienced developer. Not that youhave to get over using AI tools; youhave to get over your own time spentwriting code. I actually had a long chatwith Mark not too long ago. If you don't know, Mark is my CTO for T3 and all thefun things that we built. Mark, now thatwe have more staff, as in Julius is herefull-time in the US and Yosh stillcontributes throughout his week when hecan, Mark's time isn't best spentwriting code anymore. Previously, theflow was Mark would write most of thecode. Julius would go off and figure outwhatever weird problems, and I wouldcome in to do some steering and generalcode review stuff. Now, I'm more removedbecause there's too much going on.Running the company is a lot of work. And also not doing the best job as CEO.Trying to get more involved in thecodebase again, but it's not the bestuse of my time, which means Mark has hadto bump out a little bit too to do moreof the orchestration and code review,especially with the mobile app inflight, too. Managing the team, buildingthe mobile app, managing the team,building and maintaining the web app andthe servers and the back end, managingupload thing, managing all the otherservices that we maintain. He's notwriting code as much anymore. And asmost people will experience when thishappens in their career, that sucks.You suddenly stop feelingproductive when you're not writing codeanymore. And previously you wouldmeasure your success in a day by howmuch code you had written, how much timeyou spent in your editor, and how manyproblems you had solved. If you'respending your time in the GitHub PR taband not in your editor, you feel likeyou're not getting anything done. Andthe amount of times Mark would have acrazy day where he did a ton of code review, got a ton of stuff shipped,Those things felt like he didn'tget anything done simply because hewasn't in his editor at all. It becamelike an everyday occurrence, andhe was not loving that feeling becauseit sucks. I've seen this happen to alot of developers as they move towardsmanagement, towards tech leads, towardsroles where their job becomes lesswriting code and more orchestratingcode. This is part of what makes asenior engineer. This is the biggestreason I think we are seeing that shiftwhere more and more senior-plus devs arereporting that a majority of their codeis coming from AI. We are more used toreviewing code constantly. The averagedev still probably writes more code thanthey review. The devs who have gottenover that already, the ones who aremaintaining big open source projects,the ones who are running teams with alot of engineers, the ones who arebuilding systems that require lots ofpeople doing lots of disciplined work. Those are the people I've seen fallingthe hardest in love with these AI toolsover the last few months. The people whoare already over that hump and are usedThe biggest benefits right now aredays where I'll file like 20 pullrequests and go through them all onGitHub. I spend more time generatingcode and then putting it on GitHub thanactually reading it in my editor at thispoint. It's crazy. But that also sucksfor a lot of people. I know manyengineers, myself included, preferwriting code to reviewing it. In fact,from this poll, it seems like the vastmajority of developers very much preferwriting code to reading it. Iunderstand. But that's a thing that will suck about our jobs going forward. Moreand more of our job is going to bereviewing decisions and work that isbeing done by these tools, not doing thework ourselves. It sucks, but it is what itis. And those who are willing to makethat jump are going to see crazysuccess. It sucks when you start writingcode as a hobby. To be honest, it feels horriblehaving your hobby be automated. On onehand, I totally feel this. It has beenweird moving away. On the other, I havetwo points. The first is this is thenatural progression of an engineer asthey get better. You need to learn todelegate and do more talking andOrchestration and long-term planning, managing your team, and the development velocity are crucial factors. Changes going in and how they are being integrated are part of this.That is growth as an engineer. Once you are proficient at the code writing part, you have to improve at those other skills to keep leveling up.There's a cap on how much the code writing actually benefits you. The other aspect is that this is what we've been doing as engineers forever.We have been writing code to automate tasks that were once hobbies for other people.We have already disrupted many fields with code.It was only a matter of time before the enjoyable parts of our field began to erode. But I will counter this by saying that I'm having a lot more fun coding lately.It's much more enjoyable to see how far you can push these agents and the incredible things they can do.You also don’t feel bad when you throw away code that doesn’t meet your standards. The worst feeling ever is when one of your employees or teammates, or someone you care about,goes off on a crazy tangent, deep dives into something, builds a wild solution,and then for any number of reasons, it just doesn’t work. When you can't merge a project, you have to close the PR. It hurts. Itsucks. It feels so bad to throw awayhard work that one of your co-workers, peers, or friends did. But if it was anagent, I don’t care, I justclose the PR. So, I’m having a lot morefun with experiments. I’m having a lotmore fun trying things out, playing withnew languages, overhauling code bases,and experimenting with new stuff. I’mwriting comically more code than I’veever written. I threw together a 12,000line project in a day. What? 12,000 lines of code in a day. Accordingto various surveys, the averagedeveloper writes on an average daybetween 10 and 40 lines of thoroughlytested and debugged code. Opus and Iwrote 12,000. This might seem like cap,but when you average it out, this isvery real. I know everybody in chat'slike, "No, that’s stupid. That’sinsane." Now, if you do a PR with 250lines of code, you start working on iton Monday, you put up the PR on Tuesday, and ittakes two days to get thorough reviews.On Thursday, you finally have a goodenough review and have to go makechanges. On Friday, it ships. That was 5 days for240 lines of code. That is aboutright. And that’s hilarious. That isabsurd. This is the 10 to 100x peoplekeep talking about when it issignificantly easier to not just writethe code, but write the tests toautomate the testing process and set upend-to-end testing. GMO just posted aboutthis and the more I’ve thought about it,the more I think he might be right. AIcoding will result in the mostrigorously tested, type checked, andprovably correct code in the world. First, the testing and verificationfeedback loop helps preventslop. Yep. God, cloud code got so muchmore usable when the LSP was added. It’skind of broken, but it helps so much.But the second part, tests have alwaysbeen a chore, but who doesn’t love thepile of check marks that a high testcount gives you? Agents are glad towrite as many tests as we want. Yep, thepain of writing and maintaining tests hasgone down a ton, and I’m starting torethink my own relationship with testingfor my projects. This is one of thecoolest parts. It would take me way more time to write testing code than theActual code, because getting the testright is hard, tedious, slow, andannoying, and not actually the thing thatwe like doing. Now the agent can do thatpart, then do the implementation, andthen put up the code, and then do thefirst pass on the code review and catchany mistakes. Then you lookover the final pieces and give it athumbs up or down. It's a wholedifferent way of building, and it ischanging how I think about software. Back to the rest of the quote, becausethis is what I think a lot of peoplehave missed.But the programmer still needs tospecify what the conditions are for whatthey're doing. What is the overall app you’retrying to make? What’s the overalldesign decision? How do we collaboratewith other code that’s been written?How do we have some commonsense on whether this is a secure designor an insecure design? So, as long asthere are these small pieces that aprogrammer, a human programmer needs todo that the AI isn’t good at, I thinkhuman productivity will actually be. Enhanced. I really want to emphasizethat part because it's a huge part ofwhat I love about coding. It's not justthe process of writing beautifullines in my editor that I could stare atand smile and screenshot and tweet. It'sthe way I think about the system, theway the parts come together when theright abstraction works in the rightplace the right way, and it all comestogether well. When you pull togetherthe set of tools you want to use andthey come together the right way, or oneof them doesn’t quite work how you need,so you swap it out for something elseand it does work. And that feeling of cohesion when you get the right parts towork together, that’s my favorite thingwhen I’m writing code. When all of thepieces come together and the result issomething awesome. Both a thing thatyou’re confident in your ability tomaintain and also a thing that isactually pleasant to use for the productthat you’re actually putting together. Thisis awesome. I find this so fun. Itis different. It is strange. It’s afundamental change in how we write codeevery day. What does this mean about ourday-to-day work, about our careers? About the people that we hire? About thepeople we might have to fire? How is ourworkforce going to change? A lot ofpeople said this prediction obviouslywasn't true because Anthropic not onlydidn't fire 90% of their engineers,they're actually still trying to hiremore, but they also have been doing alot more coding. In fact, Darioactually mentioned this in a follow-upwhen people were questioning his takehere. Thank you to FaZe for fixing theaudio in this clip so we can actuallylisten to it. I would say maybe 70, 80, or 90% of the codewritten in Anthropic is written byClaude. You know, I said something likethis three or six months ago. People think ofit as falsified because they think of itas if we're going to fire 70, 80, or 90%of the software engineers. But whatreally happens is that the 10%we're still writing, you know, humansbecome managers of AI systems. There's ashift because of the principle ofcomparative advantage. So it looks morenormal than you think. I thinkeventually it all, you know, kind of eventually that logic may not hold, butthere's a sort of sci-fi sheen toThese predictions are looking at thefuture, that it's going to be weird, thatyou'll be looking through differentcolored glasses, that there will be, youknow, that it'll look like Star Wars orsomething. The often when thesepredictions come true, it's wild, butit's also, in a way, ordinary. Yeah,they're just building more, and thatmakes a lot of sense. And you get usedto it, and it no longer feels as crazy. And I'm even feeling that a bit too. Like when I'm just around inClaude Code, I don't necessarily feellike, oh, this all happened at once.It's when I left my computer and wastalking about it with friends that ithit me just how absurd it is that Ibuilt two projects without ever openingan IDE. Like, that's just crazy. That'sabsurd. So absurd that now Boris isagain doing all of his day-to-day workin Claude Code 2. And Darren made a posta few days ago about how you shouldtotally now be able to have one highlyskilled person doing the equivalent of10 engineers' work. Does this meanthat the industry will be slashed toonly the top 10% of engineers if that'sConcerned? I really like Simon'sresponse here. If code gets 10 timescheaper, the demand for code will go upby more than 10x. A whole bunch ofcompanies that previously couldn'tafford custom software will suddenly bein the market for it. And existingcompanies with multi-year road mapswill hire more to help get them throughit. This is known as Jevans' paradox. TheJevans' paradox is a phenomenon that occurswhen technological advancements make aresource more efficient to use, therebyreducing the amount needed for a singleapplication. But if the cost goes downand the demand is price elastic, thiscan result in demand increasing instead,causing the total resource consumptionto rise. And I think we're alreadyseeing this. There is definitely morecode being generated. There are definitelymore companies interested inbuilding their own internal tools thanI’ve ever seen. For example, at RAMP,the finance management company forstartups, they have been building theirown internal tool that uses open code to take some plain text description of workand execute it. Here is one where theyasked, "What are the 20 most commonSensory issues in core? Spin up childsessions fixing all of them." Andapparently it just worked. They lookedat the sensory issues and then spun up 20agents to go fix all of them, and thenfiled 20 pull requests. That's kind ofcrazy. This does mean you're spending alot more time reviewing code, but alsothe process of linking these things allup like this. And I’m certain that 90plus percent of the code in this inspect toolthat they made is probably vibe coded,too. This is the thing that is changing,that is crazy. And the more you dive inand play with it yourself, you’ll findthe way you think about these thingschanges. When you realize you can gojust spin up the tool and it’s not thatmuch work, you’ll try things youwouldn’t have tried. I’m consideringgoing as far as setting a minimuminference spend for my team. I mightmake it so everybody at T3 Chat isexpected to spend at least $200 a monthon inference so that they’re going to goout and try new strange [ \_\_ ]. I want tosee what they do when I put somepressure on them to spend more moneyrather than less because then they mightexperiment a bit more and do some. Crazier stuff. I'm probably going to dothat at this point. I've been thinkingabout it too much. I want to, I'mprobably going to. This fun report justgot linked while I was filming, and Iwanted to include it because it'sanother one of the reasons we have toreview the code that the AI is writing.AI code creates 1.7 times more problems. My initial question was, when was thispublished? Because that will change howI think about this report a lot. And Icouldn't figure it out, but everybody inchat was saying they could see it. Checkthis out. When I squash it down tomobile size, it shows the date, December17th. And when I zoom out, we get thissidebar that shows December 17th, 7minute read. But if you're zoomed in toomuch for the sidebars to fit, but notenough for it to trigger the mobilemode, you don't get to see the valuesthere. Just one example of a bug thatoccurs when you vibe code your UIs. JustFunny to see one of these bugs in thearticle about how you find up to 70%more of these in AI code than humanwritten code. This report was across 470PRs, including 320 that AI co-authoredand 150 that were human only using code. Rabbit's structured issue system acrossa bunch of open source projects. Andyes, AI does accelerate output, butit also amplifies certain categories ofmistakes. Surprise, surprise, you getthe idea. One interesting piece is thatthey only measured as per PR. Theydidn't do per line of code. Also, highissue outliers were more common inAIPRs. So, you would randomly have a PRthat had way more issues—1.7x theaverage, but it’s 2x at that 90thpercentile. So, when it does poorly, itdoes significantly worse. Cool information, andagain, more reason you need to be doingthe code review part. But this leaves uswith my biggest concern—the junior dev.And I’ll be honest, I don't know what wecan do about that. I built up theseskills by writing code for almost 20years. And those skills are stillessential in my day-to-day use of thesetools. Just knowing the intricacies of how CSS works and that scroll containers can bestrange in the browser—the number oftimes I've had to remind Claude Codethat it doesn’t have the ability to havea tooltip come out of a box when it hasany overflow rule set on it. I don’tknow if you know this, but if you set anThe overflow X rule on a box, you can't goout of it in the Y direction. So, if you havesome behavior where it has a bordercolor when you hover over it, that willget cut off. Or if you have a little Xbutton in the corner of the square,that'll get cut off. And I've had toremind Opus about this so many timesthat it suggested adding it for me to myglobal quad MD file. You need toknow these things to be successful withthese tools. However, these tools existingdrastically lowers the incentive tolearn these things because the cost ofdoing it wrong used to be really high. The cost of figuring it out wasalso really high. You would spend the time todo it. Now, if you don't know the reasonthese things happen, you can screenshotthe problem, show it to the model, andsay, "Hey, fix this." And there's a onein three chance it does it right, andthen you keep doing that over and overagain forever. The amount of these typesof issues will go down constantly. However,the amount of work we have thesetools doing is going up constantly. Ifit used to make one of these mistakesevery 100 lines of code, then it waskind of useful. Now, it's every thousand. Lines of code. Maybe they'll get toevery 10,000 lines, but it doesn't makethat bug any easier to solve with theAI. And I don't know how you get thatexperience now. I really don't. I'vebeen thinking a lot about this. I kindof want to do a follow-up on my junior dev videos,like, how do I think about this for early career engineersnow? And I don't know what to say orrecommend. I still think it's reallyimportant that you try to use thesetools, not as a way to do work you don'tknow how, but rather to break apart anddelegate work that you don't have thetime to do. That's when they're strongest: when you're using these toolsto multiply your own capabilities, notto work around your lack ofcapabilities. But I don't know how youget those capabilities anymore. At theabsolute least, you need to read thecode that you're generating, especiallywhen you're early and you're spinning upthings that are actual projects you wantto maintain over time. Writing codemanually is still a very good way tolearn, but honestly,I still think until you have gottenrelatively deep and are like multiple. Projects in building things that realpeople use, you should probablyprioritize using a chat app to askquestions. Or maybe you can shortcutthis and use something like Cursor anduse the ask mode where it doesn't changecode; it just answers questions to learnmore. Combine that with tab complete, andyou can keep leveling up yourunderstanding. But man, this stuff's changing fast.And the thing I never would have expected is that myskills as a senior dev, which are mostlyorchestration, planning, andmanagement of people doing things inparallel, matter now morethan ever, which is cool on one handbecause now a lot of devs are going to skill up on their talking skills. Likeprompting is more a communication skill than anend skill in so many ways. But also, likeyou might not learn the ins and outs thesame way. This is tough. I don't reallyknow what my point hereis other than to express how confused Iam still. Oh, [ \_\_ ] Lero's here. Yeah,apparently they're adding a teacher modeto Cursor, which is actually reallyreally exciting, especially ifthey let people do this on like aStudents in the student tier, like if they're in school,get it for free. Oh, that will beso good. Also, tools like Code Craftersare more useful than ever, in my opinion. Code Crafters, Bootup.dev, stuff likethat actually encourages realproject building. This is how you haveto learn now. The AI will make it soyou're less likely to get blocked andless likely to need somebody to helpcarry you through the hard parts. Yeah,I know this is going too deep. I probablyneed to think this through, like sitdown and really think about what worksand talk to some recent people who justgot into the industry, and then maybeI’ll make a dedicated video on this. Butright now, I don’t even know how to like organize my thoughts on it. One morequestion for you, as a viewer of thisvideo: If I were to ask you, where do youthink you fit in terms of intelligenceand capability writing code againstOpus? Would you consider yourself abetter engineer, roughly the same tier, or aworse engineer? Where do you think youfit? What answers do you think mychat would give? How do you think thesplit would be of those? Think about itfor a second. Would you put yourself where you thinkthe splits are for my own audience?Ready for the results?Sixty-one percent of my viewers think that Opus 4.5 isa better death than them. Sixteen percent chose thebailout answer. Thirteen percent said it was roughly as goodas me, and ten percent said it was worse. That's wherewe're at. These things are movingabsurdly fast. The way we code now is sodifferent from the way I coded at leastthree to four months ago, which is waydifferent from how it was at thebeginning of the year, and is waydifferent from how it was the yearbefore. But the speed at which thesechanges in my workflow are happening iscondensing. It's like every three monthsnow a massive change happens. Previouslyit was every six months. Then it wasevery year. Then it was every few years. It's crazy. Don't fall behind. I'm goingto do a whole dedicated video on how tokeep up with all of this in the nearfuture. I also have a video about my ownusage of cloud code that's coming verysoon. Keep an eye out for that. I'm veryexcited about that one. So yeah, keepplaying with this stuff. Keep trying newthings and keep doing your best to buildthe best possible tools and takeTake advantage of the tools that exist aroundyou. Don't write this stuff off becauseyou're scared of grifters or people likeme who happen to have invested in a fewof these tools, almost none of which Italked about today. Just focus onbuilding. That's what's going to get youthe furthest always. There is moreto be built than ever, and there aremore ways to build than ever, too. I'venever loved code as much as I do today,even if my relationship with it is verydifferent than it was a year ago. Irecommend that you reflect andgive these things a try. Let me knowwhat y'all think and how you're usingthese tools today., I can't believe he was right., YouTube, 01ked59f9z676w7r07kc7x53dj.