We All Fell for It…  🔗 **Source:** [We All Fell for It…](https://www.youtube.com/watch?v=lNVa33qUzZ8) AI code is here and it's here to stay.Who hasn't seen the productivity gains?We're talking CEOs of companies doing37,000 lines of code every single day. Imean, what else is there to our lives asdevelopers? If we can put out that muchcode, why would we do anything else?This totally isn't going to come back tobite our asses, right? It’s not likewe're going to lose all our skills as werely on the slot machine more and more,and as a result, the slot machinebecomes a slot machine and nothing everworks how it's supposed to. Thisdefinitely isn't currently happening andpeople definitely aren't starting tonotice, right? Oh, Aenta coding is atrap. This sounds like it's going to bea very, very fun article. I have a lotof thoughts here, as you guys can guess. On one hand, I love coding. I lovebuilding things. I care about thenitty-gritty of syntax. I've builtentire stacks around my specific techpreferences that have went so viral thatThey helped build my entire career onplatforms like this. On the other hand,I very much enjoy these AI coding tools. So much so that they've fundamentallychanged how I think about tech and thethings that I build. And I've neverspent less time actually writing code. In fact, if I open up my code editorright now, I'm not even looking at codein it. I'm looking at a prompt file andthen a bunch of CSVs for the data forall of the runs that I'm currently doing,with agents. I'm barely looking at codeanymore. There are things I'm doing moreof, which is cool. Like I've nevergotten so good at git in my life. I' venever used SSH and remote boxes as muchas I do now. I'm trying out all sorts ofnew things. I am learning all sorts ofnew technologies, but I also feel someof my skills atrophying, and I findmyself, when something doesn't work, justrolling the slots again and again, hopingthat this time might be the one where Iget the output I'm looking for. That lever costs a lot of money. Younever know what you're going to get, butat the very least, you know what you'regoing to get in our sponsor break is areally cool company like this one. Areyou the type that pays attention to whattool calls your agents make? Because I am.And I’ve noticed that there’s one thingthey tend to do a lot: curl. Thefrequency at which I see my agentsmaking curl calls to get informationabout web pages, documentation, and moreis honestly kind of funny, especiallybecause of the frequency at which itfails. Because it turns out a lot of theweb doesn’t respond with the realcontents when you hit it via curl.Whether it's an empty HTML page thatrequires JavaScript to populate thecontent or something that’s hiddenbehind a capture or a firewall or someoff layer of some form, there’s a goodchance your agents are going to struggle if they’re relying on doing curlexclusively. It’d be really nice if youCould just wrap your curl request insome way where it won't fail on those uhoh, it's on the screen already, isn'tit? Yeah. Today's sponsor is Browserbase, and they just added a new fetchfeature that makes it easier than everto get the real content from anywebsite. If you want it as HTML, JSON,or even markdown, they'll handle it allfor you. Instead of curling the site youwant directly, you make a post requestto the API.base.com/fetchendpoint. You pass it the body with theURL you want, and then all it needs isan API key, and it will now be able toscan that site reliably for you and getyou what you want. On the pages thatrequire JavaScript to run, they have youhandled, too, because Browserbase canspin up real browsers in the cloud. That's why they exist. That's how theygot their whole name. They provide realbrowsers for your agents to do realthings on the web. Whether it's clickingbuttons, signing in, gettingInformation, running JavaScript, andmore, they have you covered. Going to bereal with you guys, though, there weresome use cases a cloud browser wasn'tgreat for, like search. Oh, is it on thescreen again? I need to stop doing that. The search stuff is really cool, too.Adding a real way for your agents to dosearch and get the context they need tounblock themselves is incredible, andthat's why so many companies rely onthem for it. So if your agents needbetter searching, better fetching,better curling, or just better access tothe web through a real browser, look nofurther than Soy. Browserbase. Back towhere we were. Agentic coding is a trapwritten by Lars Fay. I'm actually reallyexcited about this one. Multiple peoplewho I trust sent this to me to take alook at. I haven't read it yet, so weget to go through this together, andhopefully we'll have interesting thingsto add. Remaining vigilant aboutcognitive debt and atrophy. Interesting. That the angle here is cognitive debtand not technical debt. I already have afeeling I'm going to like this a lotbecause I've personally found tech debtis actually one of the coolest things todeal with with AI. It's actually kind ofamazing how willing models are to goafter tedious tasks like making a newlint rule work across your wholecodebase or updating a package thatbroke the definitions for a thing thatoccurs in 5,000 places. I have donecrazy work for tech debt in my life thatjust required so much brute force andmanpower it wasn't worth it. Like I Istill vividly remember a time at Twitchwhere we were doing a migration for ourGraphQL layer that broke I think it was8,000 or so TypeScript files. So we tookall the ones that were now broken, put them in a Google sheet and would assignchunks to different engineers to gothrough and manually update on theshared branch to try and get everythingup to date. Like those are the types ofThings we used to do by hand that oftenwould get left, and the tech that wouldjust sit there because the process offixing it was too much manpower to beworth it. AI is phenomenal at thosethings. So whenever I see the like AIcauses tech debt argument, I getfrustrated because it also solves a lotof the same tech debt that it canpotentially cause. But cognitive debt isa much, much more interesting idea. Solet's see what Lars has to say. Startswith a quote. AI does the coding, and thehuman in the loop is the orchestrator. This is the sentiment being hyped uparound the industry currently.Traditional coding is all but dead.Inspect driven development is thefuture. Okay, I really think we're goingto agree if he's talking [ \_\_ ] on STDalready and we barely started. Oh boy. You generate a plan and disconnect fromwriting any code. The agents know betterand handle all the implementation. Youare there as the expert to provide goodTaste, review the outputs, andconstantly steer the agents to executethe plan that you meticulously puttogether. How meticulous are you guyswriting these plans out to be? Because I, Idon't believe you. I don't believe anyof you are actually putting that mucheffort into the plans if you're notwatching the agent when it runs after. Yeah, there's another angle Icould talk about with the expert thinghere. I'm not going to go into it yetbecause I want to read a bit more first, butI already have so many thoughts. Theworkflow takes many shapes at thispoint, but in general, it's a processwhere someone defines the project'srequirements simultaneously at a microand a macro level. Very, very good callout here. They generate a plan, and thenthey pull the slot machine lever overand over, iterating and reiterating withoften multiple agent instances untilit's done. All the while, putting agrowing distance between theOrchestrator and the code that isactually being generated and committed. Coding agents are helpful and powerful,but there's already some quantifiabletrade-offs that need to be discussed.First, we have an increase in thecomplexity of the surrounding system tomitigate the increased ambiguity of AI'snon-determinism. Very real problem. Second, we have the atrophying of skillsfor a wide swath of the population. I'mdefinitely starting to see this. Third,we have vendor lock-in for individualsand entire teams. Cloud code outageshave already had entire teams atstandstills. Yep. And fluctuating andincreasing costs to access the tools. Anemployee's cost is fixed. Tokens are aconstantly moving target. Yeah, I dothink that the demand going up iscausing our brains to fall out a bitwith the costs increase. I don't thinklong-term, the cost for agentic work isgoing to keep going up. The same way Ithink people are going to do more withAI and use more tokens, but the cost ofintelligence at a given level isconsistently going down. Flashbangwarning. I talk about this a lot withthe new GPT models because they are moreexpensive per token. So if you'remeasuring a given input and output thatare the same work between the old andnew models, 5.5 is 2x more expensive. It's double the cost for input andoutput tokens. But if you compare perlevel of intelligence and the number oftokens generated, things get much moreinteresting. GBT55 is the highestscoring model on artificial analysis. Itis at 60 points whereas the previousgeneration with Opus 47, Gemini 31 Proand GBD54 were only at 57 points. Meaningful improvement, but I'm going toadd something to this. GBT 5.5 low aswell as GPT 5.5 medium. And here'swhat's super interesting. 55 mediumscores the same as 54x high. And 55 lowstill scores very well, too. Comparableto Claude's sonnet 46. But when we goBack down to the cost efficiency, thisis the cost that artificial analysispaid or would have paid if they weren'tcomped to run their entire benchmarksuite. Opus 47 is the most expensive byfar at 5 grand, even though it's lesssmart than 55. But remember, 55 mediumand 54x high are the same level ofintelligence. 54x high cost $2,800 torun this bench. 55 medium cost under1,200. So if that level of intelligencewas enough for you, your cost just gotcut in more than half. You're now atless than 50% of the cost to do those same tasks as you were at before. Thatis a very, very meaningful change. Sure,the best model in the world got slightlymore expensive, going from 2,800 to3,300, but that same tier ofintelligence from before, the one thatcame out 2 months ago that we weretotally happy with, is now less thanhalf the price. And if you're okay withgoing a little bit dumber, not even muchdumber, just like sonnet levels, thePrice drops all the way to $500. Anotherrising of the price. And this model 55Low is as smart as 46 Sonnet Max, whichis the second most expensive model at$4,200. And this model came out veryrecently as well. So again, if we lookat this based on the intelligence levelper dollar, the cost per IQ point herehas dropped by 8x in just a few months. Sonnet 46 came out earlier this year,$4,200 to run this benchmark, 51 pointson the bench. 55 Low, which I wouldargue is a much smarter and nicer towork with model. Same level ofintelligence and eighth the price. So, Ijust wanted to jump on that because Idon't necessarily agree that the costsare increasing in the sense that everymonth if you do the same thing thenumber goes up. It's that we are doingmore with tokens. So, the amount oftokens we're using is going up, butwe're also finding ways to get moreintelligence per dollar. So, the costper task and the cost per level ofIntelligence is going down. So, we needto be realistic about those differences. It doesn't mean that companies aren'tgetting a little screwed here becausethey hired a bunch of developers. Theypay their devs, I don't know. Let's saythe company pays their devs 5 million a year.Last year, they paid 100k in cursor. Thisyear, they've already paid half a millionin cursor, and they're only a few monthsin. That is a legitimate cost thatthey are eating. That sucks. So, on thebill, it does look like prices are goingup, but by the metrics on how things areactually changing and improving, muchless so. We're just using the AI more.Just want to jump on that because I agreewith almost all of the rest of this. Being successful with this approach tocoding agents hinges on a rather crucialelement, which is that only a skilled developerwho's thinking critically andcomfortably operating at thearchitectural level can spot the issuesin these thousands of lines of generated Code before they become a problem. Yet,in an ironic twist of fate, it's theindividual's critical thinking skillsand cognitive clarity that AI toolinghas now been proven to impactnegatively. This is all around the termcognitive debt, which is a really goodphrasing. Many relevant people likeSimon Willis and Martin Fowler aredescribing the experience of cognitivedebt directly. They talk about gettinglost in their own projects and findingit harder to confidently add newfeatures. They can move faster, but theylose the deeper sense making thatconnects decisions to intent and theintent to the code. So, my hot take onthis is that if you weren't alreadyexperiencing a bit of it, you weren'tshipping fast enough. I can't tell you how many projects I had that I wentreally hard on for a month, got to apretty good state, then had to go dosomething else, came back to it, and hadno idea what the [ \_\_ ] was going onAnymore. This is, this is inherently theway humans work when they're doingenough different things. You can't keepthe details of all of the context ofstuff in your head. The problem is Iperceive it here is that more peoplebecame theos because of AI. I used toship like five plus projects a yearbefore AI cuz I just loved buildingthings and putting them out there forpeople. That took a lot of not likeexpertise in the traditional sense, butit was just like the way I built, theway I thought about things and how Iwould cut project scope down to get adeliverable, usable version as efficiently as possible. Hell, this iswhy I made the T3 stack. I wanted to beeasier to build things with confidencerapidly that would work reliably withouthaving to fully understand all of thepieces. I was kind of an early vibecoder. Not because I was using AI towrite all my code, but because as soonas it worked, I would move on to theNext thing, and forget what the hell I had just done. It was just likewilly-nilly deleting giant chunks ofcode, writing code mods to updatethousands of things, hoping that itworked and just checking if the buildcame out correct in the end. I have beenslinging far too many lines of code formy levels of expertise for my entirecareer. And it's fun seeing everybodyelse have the problems that I have hadfor the better part of a decade now. Specifically, around remembering whereeverything is in the codebase, and havingconfidence when you review code thatthings are actually changing the rightway. I would also argue, and many wouldpush back on it, but I understand bothsides, that my ability to do this wasnovel and potentially exceptional. It nolonger is. The thing that made mespecial on a team is that I couldunblock and make things move and hitdeadlines that didn't seem possiblebefore. I was a bargaining chip at myJob where my team would negotiate withother teams to lend me to them tounblock something that they werecomplaining about, so they would unblockus on something we had to do. Verycommon that I would be traded around tomake things move faster. Now you can just prompt your way through it. Theissue is, I had to work to get there. Youcan argue whether or not I was an expert,and that's why I could do this. But youcan't argue that it was a novel thingthat I could do this. It was novelenough that I was paid exceptionallywell and had a really good careerbecause I was able to jump between a lotof things, and I could deal with thecognitive load and the cognitiveshifting going between all of thesedifferent things. Now everyone is doingit, and most people aren't built for this,and it sucks. There's a separate problemthat combines with this, though. Thereason I could do this is, I deeplyunderstood the building blocks I used to. Build in this way. I might not rememberexactly how I assembled the things, butI knew the pieces I used to assemblewell enough that I could infer why aproblem happened based on my knowledge.AI disincentivizes youfrom learning about the pieces. And Ithink that's the biggest problem. Humansare very pain. Feeling dumb hurts. Whenyou're trying a thing and it doesn'tmake sense, you feel pain. When you trya thing and it just goes as expected,you feel good. AI has made it easier toavoid that pain and feel that reward. And what used to be a upfront cost youwould pay to learn the pieces, and thenyou could get the reward of solving thepuzzle, is now a slot machine. And yourchoices are to go learn the pieces so thatyou can actually solve the puzzle,or keep pulling the slotmachine until hopefully the correctanswer comes out because each pull hurtsa lot less than reading the docs for alanguage you don't understand. Learning a library that doesn't map withyour mental model properly or debuggingsomething that feels hopeless. I learnedabout this from skateboarding. Thereason most skaters give up beforelearning to ollie, much less kickflip,is because it feels so bad. You hate thefeeling seeing others so effortlesslyjump on their skateboard, olliedownstairs, and do all these fancytricks, and you can't even get the boardto come up off the ground with you. Andthen maybe you try a little too hard,and you hit your shin really hard, andnow walking's uncomfortable for a fewdays. Most people give up before theylearn those tricks because the pain isso great and the feeling of stupid andincompetence is so strong that theydon't want to push through it. At leastin code, you didn't have the physicalpain. You just had to feel dumb. AndI'll be real, I kind of miss feeling dumb. I haven't gotten to that as much latelyand I try to find ways to likeIntentionally picking languages I don'tknow, like Rust, when I build a newproject, so that I have to not get it andstart learning things about it. Butevery time I start feeling dumb, I feelthe itch. I feel the temptation to pullthe slot, to just do one more run inhope that maybe this time it'll generatea solution, and now I don't have to learnthe thing. And I think other people justdon't have the same willpower. And Idon't think that is that exceptional athing. I don't think it was evennecessary before. But your, your abilityto say no, as a developer, has nevermattered more than now. And yourwillingness to feel stupid, to gothrough the details and not let the AIbail you out is a superpower. Personally, I have been learning a lotmore than I've ever learned because ofthis. Both because I'm learning allabout AI and the business sideespecially, but also because I'm findingmore fun in things that I felt too dumb. In before. Like I'm getting way deeperin cryptography. I'm making cryptographychallenges. I never thought I'd be ableto do that. I was always fascinated byit. Now I'm doing it and I'm askingquestions about it and I'm having backand forth with the agents and now Idon't feel as bad bothering my friendsabout it because I'll exhaust the AI'scapability to answer my questions first. And now when I bug a friend that isdeeper in the space, I'm asking betterquestions. Then there's also the aspectof fear here, and I have a feeling we'lltalk about that later, so I'm not goingto dive into that just yet. Let's getback to the article, 'cause it's alreadymaking me talk too much. The nextsection is called "Not Just Anotherabstraction."A common refrain we hear inthe community is that programmers arejust quote moving up the stack and intoa different type of abstraction. Whetheror not, these tools really are anabstraction layer in the first place isNot a settled matter. A high level ofambiguity is not a higher level ofabstraction. Woof bars. What he'sreferring to here is the idea that we'vealready done abstractions. Like we usedto do punch cards and then assembly madeit so we didn't have to poke the holes in the cards. Then C happened and it wasmuch easier to write and then generatecode that was assembly for differentsystems. Then we got C++ which wouldinclude a lot of the things that youwould have to build yourself previouslyin C. Then we got languages like Pythonand JavaScript that didn't even have tobe compiled. They just ran in a virtuallayer, a runtime that was built in theseother languages. We kept abstractinghigher and higher up. And let's be real,how many JavaScript developers can readassembly? I mean, let's be real. Howmany JavaScript devs can even readJavaScript at this point? But you getthe idea. These abstractions would keepyou from knowing as much about theLayers below. But the best engineers hadstrong incentives to learn at least onelayer above and below where they were. All the best C++ devs I know are veryfamiliar with V8, the JS runtime. Allthe best JavaScript devs I know are veryfamiliar with V8 and its quirks. The midones don't understand the things aboveand below them. But the great ones tendto be at least one layer, maybe two orthree, above and below where they tendto live. But is natural language anotherone of these abstractions? Is markdownto JavaScript what JavaScript is to C++? I used to think it might be, but I'mlearning now the answer is probably no. Let's see what Lars has to say aboutthis. If we put the abstractionconversation to the side, it is truethat programmers tend to be weary of newlanguages and new ways of programming. When Fortrren was released, programmerswere skeptical of it as well. They hadsimilar claims. It was likely tointroduce more bugs and instability. Writing assembly more directly was moreefficient. Later, there would bediscourse around the integration ofcompilers, introducing too much magicinto the process. These were normativearguments around the fear of what mightbe lost if these new technologies wereembraced. The difference with what ishappening today is that those previousfears were speculative and theoretical.In just the short few years that AItooling has existed, we've already seensignificant impacts. These aren't justjunior devs, but even those with adecade or more of experience. Here aresome posts that he grabbed from Reddit. Losing my ability to code due to AI.Hello everyone. I don't see it come up alot, but even after a few years ofcoding, using AI on a regular basis forover a year has made me feel a lot moreinsecure about my coding abilities. Ifeel like my skills are reallydeteriorating while simultaneouslyfeeling like there might be no need toKnow how to code at all. Handlingfeeling dumber or like losing skills due to the need of using AI. Recently, mycompany started enforcing using only AIfor all software dev. That's a terribleidea. Erase the code. I love that thisdev is so deep that code autocorrects tocodeex. It writes the code, then agentsreview the code, etc. We're supposed tobe architects who only look at outcomesand not the code. For context, I have 9years of experience. I'm 31, a father ofa 1-year-old, so let's agree that a sideproject after hours is not an option. Every time I use AI to do everything, Ifeel like I'm losing my skills, that I'mbecoming a worse professional, etc. Especially that if you want to get a newjob, you're mainly and mostly gradedbased on your technical skills. LettingAI do 100% coding fried my brain. Help. AI reliance and cognitive decline. Ifind myself using more and more AI tospeed my efficiency. Whether it'sorganizing a schedule or a quickScreening of code to actually writingsmall snippets. There are definitelypeople experiencing this. I was afraid Iwould experience this and somehowhaven't. I, I know I keep making the samecomparison over and over again. I thinkthe fact that my job wasn't just codingand hasn't been for a while prepped mebetter for this. I've had a team ofengineers for the better part of adecade at this point. And realizing mybest use of my time isn't being in theweeds writing the code. It's helping theteam execute more effectively whileunderstanding the system well enough tohelp them debug when things go wrong. Iwrite less than 5% of the code acrossour products, but I solve over half theoutages. And I'm really proud of that. My understanding of the system has goneup, not down over time. And the AI toolsare helping me maintain thatunderstanding and guide my team betteras we architect our systems. I would betmy ass that every single one of theseFour people have never had to manage ateam before. I also see Chris TitusTechch in chat with a similar experiencehere. He's coming from a CIS admin andinfra background. Most of his codingabilities used to revolve aroundscripting, and now with AI, it's reallyopened so many doors. He could jump intolow-level languages he would have neverhad time to before. And that's what Iexperienced too. There's a lot of thingsthat weren't worth me learning becausethe friction of going through the longwindow of dumb and the burden I would beto other people asking questions was toohigh. AI has lowered that to the floor. So, the right mindset here can make youway more productive and way more capableof learning in a way that's really cool.I'll say that less experienced engineerslike junior engineers, careertransitioners, or people that just didn'tget it before, they're getting a littlemore screwed here. My chat sent me thistweet from Austin Kennedy, who's 22 yearsOld. He thinks Claude Co isdeteriorating his brain. Every singleday for the last six months, he's hadsix to eight quad code terminals open,waiting for a response to so he can hitenter 75% of the time. It's donesomething to him. Apparently, hisfriends bring it up pretty frequently. None of them feel as sharp as they usedto. Don't know if it's just us or othersin their 20s who are feeling the samething, but something he's been thinkingabout. Yeah, if you didn't get throughthe years of friction to reallyunderstand these things, you're going toget addicted to the slot machine. I'veseen a lot of people falling for this inparticular. Also, the worst ones arethe ones who have always been reallyinsecure. The people who I'll bereally crude here. The people who don'thave impostor syndrome. They are justimposters. And I've seen some horrifyingexamples of this. People who have beenlike working at Google for four years. That don't know how to use SSH. LikeI've seen this a lot. And those peopleare now addicted to the slot machine.And they went from being kind of bad,but like at least they could write somePython here and there to just a netnegative on the team. Funny enough, I'veseen that same person instinctively goto ChatGPT and ask where they lefttheir keys because they're so used toasking it everything. This archetype ofperson, I would argue, was neverparticularly useful. And the AI is justcontinuing to erode their already erodedbrain. The gap between the great and notgreat engineers has grown massively, andAI has accelerated that. And again,examples from people in the industrysaying that the juniors on their teamare shipping really fast, but they don'tknow how to debug anything they didn'tactually write the code for. This devhired a junior who learned to code withAI. He can't debug without it. Don'tknow how to help him. AI debugging. Underrated. It's a specific skillseparate from building with AI. I don'tthink you should be debugging without AIat this point because if you have a bugand it's affecting users, everything youcan do to increase the likelihood thatyou solve the problem is something youshould be doing. So, when I had anoutage a few days ago on Ping, our videoproduct, I haven't touched that codebasein 4 years minus like testing agentsupgrading it every once in a while, butit was built on the OGT3 stack, a stackthat I invented. I know the layers verywell. I know where the failures can be. So, I grabbed the first error I hit. Ipasted it into a codeex instance andimmediately went back to the browser totry and get more info and debug it. Iended up figuring out roughly what itwas. It was Prisma getting a null for anID when it was trying to do areferential integrity check to get datafor a join that it was doing, and it justgot a null and failed as a result. The time I had figured this out, theagent that was running had its ownentirely different theory, but I didn'tcare. I opened up another tab in T3 codeand asked a different question. Which ofthese table referential integrity checksis the most likely to have a problem, andI switched over to fast mode. While itwas running, I was going through thecode and going through our error logs. Isaw the notification that the requestwas done. I went and checked, and it saidthat it was very likely to be the linkbetween the user table and the join forwhich users are in rooms. I knew what Ihad to do at this point. I had to removeall of the links between the rooms andthe user that were for this dead user. Ididn't want to write the SQL querywrong. So I told it what our schema wasand asked it to write the query toremove all the rows that match thisparticular pattern. And then it worked,and then I was done. So I did aroundthree AI agent requests while I was. Doing this debugging, I don't even knowwhat the first one output. I just had itrun in the background while I wasdebugging. I found a much more likely rootcause, asked a second agent about that.It correctly identified what table theproblem would be from. I asked it towrite a query to figure out what row wasaffected. It did. I pasted it. I got theright result. I pasted the results backinto my agent. It told me what query torun to clean it up and then it wasfixed. This was me and the AI going backand forth, sharing our understanding of the capabilities of my system and whatwe were experiencing in order to debugmore effectively. Note that this wouldnot have worked at all if I didn't knowthe system already. I also would havetaken much longer to solve this if Ididn't have AI and I would have beenmore scared about my solutions because Ididn't want to go write the [ \_\_ ] SQLfor this when I was at an event inMiami. Yeah. So, I am very okay withUsing AI in the debugging process. Anybody who says otherwise is eitherstupid or of bad faith. The problem ispeople leaning on AI because they don'tunderstand the system and their refusalto learn the system because it makesthem feel dumb results in them onlygetting anything done with AI. Differentproblems, and I want to be very clearwith the distinction here because againthese tools are really useful when youknow what you're [ \_\_ ] doing. Back tothe article, Lars says it is actuallydifferent this time and I agree. This isdifferent from a C++ dev moving toPython or Java because, as he says, theydidn't complain about brain fog whenthey made the move. They complainedabout the awful object-orientedprogramming patterns that they had toadopt in Java. When a CIS admin moves toAWS, they don't feel like they're losingtheir ability to understand networking. On that note, there’s a lot of peoplewho would argue Verscell cost them theirNetworking understanding, but differentconversation for a different time. Asenior engineer losing their coding edgeand becoming rusty over time as theymove into managerial roles and practicecoding less often is not a newphenomenon. This was the naturalprogression of expertise. An engineerwould put in decades of codingexperience, with lots of friction, and theirexperience would be logged, and thatwould result in them having the time andexperience necessary to solidify theirskills and wisdom, and they could applythat wisdom when their job became lessabout syntax and more about higher-levelarchitectural decision. Thoseindividuals are not only exceedinglyrare, but you won't get the next wave ofseniors if we're all abdicating thefriction of writing, problem solving,and debugging. Ding, ding, [\_\_] ding. This is the concern I have. I ampredisposed to being good with this [\_\_]because I already coded in a way thatRelates to this. And then when I movedto leadership positions and I wasadvising at many different teams whilealso coding and being in the weeds, too,I got to build these skills reallyearly. And I'm super thankful for thepeople I worked with for letting astupid [ \_\_ ] 22-year-old step wayoutside of their role to start steeringarchitectural decisions and helping inoutages that they shouldn't be near. Being involved in like P1 instances thatthey should have nothing to do with andlearning not just how things work, butmore importantly, how they fail. I'mreally [ \_\_ ] proud of my debuggingskills. My team's almost annoyed thatlike I can come into a codebase I'vebarely touched in years because there'ssome outage and say, "Oh, it's probablythat." And I'm right like 70% of thetime. And if I'm not, I get it rightwithin the next three tries. Usually mysystems understanding and my ability tolike link one, two, and three to formThe picture. That's what I'm good at. And I wasn't initially. I had to buildthat skill up because I was doing toomany things at any given time,and I was lucky enough to be surrounded withpeople that were cool with me steppingway outside of what I should have beendoing. I will say that with the rightmindset and focus, I do think the skillsI built can be built independently now if you build a big enough system and putthe effort into understanding where itfails. On the other hand, the incentivesfor that are going down and the interestin building your fundamentals is goingdown with it. I used to be the personthat would push back on learning likefundamental CS. Like I didn't think youneeded to go memorize all of thedifferent sorting algorithms and all ofthe different like big O notations fordifferent solutions to various problems. Like I don't think most devs should needto know how to inverse a binary tree.But the moment you have to, you shouldBe able to figure it [ \_\_ ] out. Andthis is always my take. The fundamentalsdon't matter until they do. And youshould be in the right mindset to learnthem when it makes sense to. When youhave a problem that benefits from it. Ifsomething is slower than it should be,and you notice that your sort algorithmtakes too long, it's time to learnbetter sort algorithms. I don't know ifthat take of mine will carry over tothis era. I would hope that when you're running into problems because you'refetching all of your data through useeffects, that you'll look into how otherpeople do it and you'll find ReactQuery, but I think it's more likely theagent just does it for you and you neverlearn the difference. I suspect thatbecause I've already seen a lot ofengineers do that even before AI. Thenumber of engineers I saw making theircode comically worse by fetching all oftheir data in these weird patterns thatwere super inconsistent and unreliable. Across their codebase that wouldn't useReact Query because they don't want tolearn another new thing. [ \_\_ ]You're basically unlearning. It is lesscode and less effort. It is a simplewrapper for async functions. It couldn'tbe easier. But the idea of another thingto learn was enough of a turnoff for theaverage low IQ dev that they wouldn't[ \_\_ ] bother. And now that person'sbeen given a lever they can pull to makeit matter even less. That sucks. AI isgoing to take bad devs and make thematrocious. But I do still hold a littlebit of hope that the devs who love this,who really care about how things work,not just the feeling of them working,will take advantage of these tools toaccelerate how quickly they learn andgrow. And I have already seen this. It'sa small number of people, but I havethem in my community. People who are doing way more than they should be attheir young age without any real careerexperience yet because they're buildingThings bigger than they have any right to, and they're curious about why they'rebreaking, and how to solve the problemsat fundamental levels that I love. Ilike this framing here, too. What'shappening now is a trend where devs whohave never had the longevity or the 30plus years of friction that lead to thedeep understanding are being moved tohigher level workflows requiring thosesame skills to manage the AI agents thatthe senior engineers took decades toobtain. Yep. I'll go a step further. Youhad to be a good engineer to have a bigcode base. Either you were hired to helpin that big codebase, or you built ityourself. There was an intelligence andcompetence requirement, like a friction that was necessary, like a you have to bethis tall to come in type thing. You hadto be this competent and this experienceto build real work before. Now Claudecan get you into a position where you'remaintaining a code base that is biggerthan any engineer with 5 years ofExperience would be comfortable with andyou learned how to code a month ago ifyou even actually learned. That is thebiggest issue is there's devs who areway out of bound for where theircapabilities are, and they're not usingthe tools to learn to better theircapabilities. They're using the tools toreach past their capabilities, and thenjust throw up their hands when thingsbreak. Another great point from ChrisTitus Tech. He's on fire. He'd expandthis and say that if you do open sourceand have contributors, it will help point out the mistakes. I'll go evenfurther than you are here, Chris. Opensource maintainers are massivelyoutperforming average devs in the AIworld because they're used to slingingslop and dealing with random [ \_\_ ]from various capabilities and levels ofengineers, many of which know betterthan them, many of which know less thanthem, all of which are opportunities tolearn. And this is actually why I thinkYou're an exceptional dev despite notbeing a dev because you're doingsomething way harder. You're trying tofix Windows, but aside from that, you'realso trying to, like, maintain these reallegitimate open-source projects peoplerely on every day. I say as a person whorelies on Windows till every time I do a newWindows install, which is far too often. That puts you in a position where youlearn so much more, and those detailsmatter so much more. You've effectivelylet yourself gain five years of real-worldexperience every year with the stuffthat you do, even though you're not anengineer in the traditional sense, whichis silly and dumb. And one of the manyreasons I want to help you get, make more[ \_\_ ] money. So, yeah, if you're doingreal open source stuff that people relyon and use, whether you're a contributoror even better, a maintainer, that ishelping go through stuff, your level ofexperience for where you're at in yourcareer will be significantly higher than. You would otherwise expect. Like I knowpeople who have one year of experiencethat is mostly open source work thatruns circles around somebody with fiveyears of experience at Microsoft. Theauthor does remind us that seniorengineers aren't immune. Simon Willis,the creator of Django, good friend ofthe channel, one of the best people inthe AI developer space for talking abouthow this actually affects us as devs. Hehas 30 years of experience. He's beencoding since I was born. He reportedthat he doesn't have a firm mental modelof what the applications he builds cando and how they work, which means eachadditional feature becomes harder toreason about. And I can absolutelyunderstand that. The skilledorchestrator problem buried in a recentstudy by Anthropic was a surprisinglyhonest moment when speaking about therisks of engaging with coding agents ona regular basis. One reason that theatrophy of coding skills is concerning. The paradox of supervision is thateffectively using Claude requiressupervision, and supervising Clauderequires the very coding skills that mayatropy from overusing AI. A director ofsoftware engineering at LinkedIn who has50 engineers reporting to them hasnoticed it proliferating throughout theorganization and requested his team tonot use them for quote tasks thatrequire critical thinking or problemsolving. To grow skills, people need togo through hardship. They need todevelop the muscle to think throughproblems. How would someone question ifAI is accurate if they don't havecritical thinking? Yep. I don't knowwhat it looks like to build these skillsnow. It's very different from how itused to be. I'm sure there are new waysto, and I'm sure they're even moreeffective using these tools, but I don'tknow what that looks like because Ialready have the skills. I can'tproperly reset to my brain before I knew. All of these things. There's also thequestion of what constitutes thisoveruse. We already have evidence, bothdatadriven and anecdotal, that theseskills can atrophy and dissipate ratherquickly, sometimes even within months.This is the contradiction that has manyAI boosters talking out of both sides oftheir mouths. The use of coding agentsis actively diminishing the very skillsneeded to effectively manage the samecoding agents. LMS accelerate the wrongparts. Oh boy, this is going to be a funsection. This one's going to be so much fun that I'm going to make you waituntil the next ad is done. Sorry aboutthe interruption. As we were, LMaccelerate the wrong parts. Contrary tothe current narrative that is beingespoused, we didn't necessarily need towrite code faster, especially code thatwe didn't fully understand, andparticularly in huge swaths that wecouldn't review in reasonable timeframes. Before AI, a good dev's priorityThe list might look like the following. First, understanding of the code and itsrelation to the codebase. Second, if thecode is aligned with the documented andefficient standards. Three, as few linesof code as needed to accomplish the goalwhile maintaining readability. And four,turnaround time. I don't agree. It dependson what type of good dev you'rereferring to here because there's a lotof things that make a dev good, andeveryone will disagree on what thoseare. Some people think a good dev issomebody who writes meticulouslydetailed specs and writes five unittests per line of code. Others mightthink a good dev is the person whounderstands the user and the codebasewell enough to make the two meet. Othersmight think the best dev is the one whocomes up with a novel solution that isfar outside of the way anyone elsethinks that no one understands until 5years later and then we're all using it. I think good devs are people who solveReal problems. I like working with devsthat understand the code base, that arewriting code that is well aligned andstandard, that are writing as few linesof code as possible, which is actuallyvery rare. There's a lot of great devsthat don't even do this and have goodturnaround time. But I have found thatany one of these skills at the upper endis novel enough that it makes youunique. Like if you write reallyefficient code, that is a thing you'reknown for. Like I know Mark, my CTO, is the code golfer. One of his favoritethings is to see if he can do a wholeadvent of code problem in one line ofJavaScript. And then turnaround time, asI mentioned before, was one of myskills. And it was enough that itboosted my career meaningfully that Icould come in, find the things that madethe road map unnecessarily complex, helptrim and get like really locked into thething we actually wanted to build. So weweren't distracted by all the things. That took most of the time and broughtnone of the value. So I would say agreat dev has all of these skills, but agood dev is somebody who has the rightcompromise between them. The problem isthat agentic coding and LMS in generalare inverting this list. Yeah, most devsshould not be allowed to code fast. ThatI agree with. As somebody who coded fasta lot, watching others try to keep upresulted in a lot of pain. And thesolution was often for me to slow down,not because my code was getting buggy,but to get everybody around me to stop trying to keep pace because when theydid, everything fell apart. And AI nowhas everyone trying to keep pace and noweverything is falling apart. Theircapabilities and usage tend to focus onspeed by increasing the amount of codethat can be generated in a specifiedtime frame. Speed's a natural byproductof high aptitude. When it's forced, italways leads to lower accuracy. Okay, Ido love this framing. Actually, this isPerfect. I earned my right to the speed. Y'all haven't yet. Okay, many of youhave. I'm actually really impressed withhow competent so much of my audience iswhen I meet you guys at events andthings. I'm blown away with the [ \_\_ ] somany of you are doing. Your annoying assco-workers have not earned the right toship fast yet. And the result is slump. Julius on my team has absolutely earnedthe right to ship fast. He's shippingfaster than I ever have and is pushingthe limits of what agents can do, butalso is very meticulous about how thingsare structured more than almost anybody. And as the author says, the integrationof AI tools does not tend to focus muchon deeper understanding or conciseness.And I want to be really clear becauseevery time I mention something likethis, the response is, "Oh, we needbetter tools that do that. Those shouldmake a lot of money." And then I getfive people coming up to me at theOpenAI GBT 5.5 event trying to get me toInvest in their company making AIeducation products to help people learnbetter with AI instead of just use theAI. Who do you think makes more money? Casinos or people selling books aboutcasinos?There's pretty obviously one that doesmuch better. I have been burned on somany education investments, even theones that were doing revenue, that Ijust don't believe that people want thisat all. Given the option of a slot thatmakes you feel good and a lesson thatmakes you feel bad, 99% of people aregoing to pick the prior. There is nobusiness building this, which sucks. That human nature in capitalism preventstools that educate you from beingsuccessful. But that's your guys' faultas users, not the business's fault. Doesn'tmatter how good the business does. Ifusers don't want it, it won't work. Believe me, I'm speaking from a lot ofexperience here. It is absolutelypossible to use these tools if you'reDetermined enough in a way that willactually make you learn more andunderstand systems better. But that'snot how they're being used. While lotsof companies have forced mandates, soyou have to be doing more with AI, andthey have crazy leaderboards and stuffthat are incentivizing bad usage, andall the hype around that isdemonstrating just how bad things aregetting. Coding equals planning. This isgoing to be a fun section. There's adivide between developers that isn'thighlighted as much. Some of us plan andthink better with code. Thinking andworking in code isn't just meaninglessdrudgery. It forces you to think aboutthings on a technical level thatinvolves everything from security toperformance to user experience tomaintainability. I very much agree here. I like planning in code. A thing I talkabout a lot is what got coined at Twitchis the theo method. Instead of writing aspec, assuming we know how everythingWorks, that is super long and tedious,and then building the product andrealizing the spec doesn't make anysense, I would start with a reallysimple, minimal implementation that wasthe minimum viable shape of the idea. And in building that in just a few days,often I would learn a ton. Sometimes itwould even be good enough if we couldship that as is. Other times I wouldfind all of the things that make itannoying to implement and then I canwrite a good spec based on what I learn. Death Fudge put it perfectly in chat.Write once, throw it away, and then buildit, right? Absolutely. And if AI helpsyou do that, awesome. I did this so muchit got coined under my name at my lastcompany that I worked at traditionally.It is really powerful to get in theweeds first. Is you can't really do thatin coding without coding. I write muchworse plans when I'm not in thecodebase. That's just reality. And whenI'm working with my team, I'll often doA first pass before proposing the thingto the team so I have like my roots tobase my proposals on. And guess what? Plan mode is not that. Plan mode is notthat at all. In a recent interviewdiscussing specri development, Dax, thecreator of Open Code, which is an opensource coding agent, no less, is quotedas such. It's also worth noting Daxisn't the creator of Open Code. He's aDevril at Open Code. Here's what he hadto say. When working on something new orsomething challenging, me typing outcode is the process by which I figureout what we should even be doing. I havea really tough time just sitting therewriting out a giant spec on exactly howthe feature should work. I like writingout types. I like writing out how some of the functions might play together. Ilike playing with the folder structureto see what the different conceptsshould be. And this is all stuff I thinkmost people, most programmers havealways done. I don't agree there. YouWould be amazed how many programmersdon't do any of this. They just waittill the ticket is cut properly, and thenthey spend way too long writing adocument and then hope they can getpromoted before they even finish thefeature. Most devs don't do this becausemost devs are roughly average or worse. Good devs do this, but most devs don't.I do agree with him that we shouldn'tnecessarily stop doing this. There's nogood reason to, and it's how we figureout what to do and how to do it right. The one big viral disagreement with here,though, is that when you get it wrong,it's never been cheaper to fix it. Ialways had a sense of dread when I wouldcommit to a new folder structure or anew way to do type systems or a new wayto do data fetching because if I'mwrong, getting it out as hell. Now I canget it out in a for loop, and that'sawesome. It has made my willingness toexperiment with these things go up a tonand I'm trying patterns I never would. Have tried before 'cause they had way toohigh a risk of being [ \_\_ ]. But theyturned out to work really well, and I'msurprised, but it never was worth theeffort before. So again, there’s twosides here. Back to the article. Whatyou say is often not what you mean, andLLMs fill in ambiguity with assumptions,or even worse, hallucinations, which leadsto more review, more agent revisions,more tokens burned, and moredisconnection from what is beingcreated. Inversely, you can marvel atthe most beautiful, unambiguous, perfectlystructured prompt you ever written, andthe LM can still output a hallucinatedmethod because it’s fundamentally a nexttoken prediction engine, not a compiler. You cannot replace a deterministicsystem with a probabilistic one andexpect zero ambiguity. As a JavaScriptdev, I am offended. Oh boy, this will bea fun section. Vendor lock-in. When I wasbrowsing LinkedIn during the cloudNoticed numerous posts highlighting thatcertain devs and engineering teams wereat a standstill. Their workflows, theirown coding abilities, had alreadyreached a point where they were largelydependent on these vendors. What used tobe a skill that they could execute withjust a keyboard and text editor suddenlyrequired a subscription to an AI modelprovider. I haven't self-plugged in abit, so please permit me to do it thisone time. If you're experiencing vendorlock-in right now, that is your fault. There are lots of great tools, and Iwill obviously plug my own with T3 code,that don't just give you the ability toswitch between models. They give you theability to switch between subscriptionsand providers. There is no world inwhich Claude, Codecs, Cursor, and OpenCode are all down at the same time. Andit's actually quite valuable to hopbetween these things. I can't tell youhow many times I've had GBT 5.5 debugOpus slop and how many times I've hadOpus, come in and make a slightly betterUI for some GPT 5.5 code. A lot of devsare doing this wrong. They are relyingon one thing way too hard.The same waythat a lot of devs rely on US East1 toohard.The difference is that somehowAnthropic is less reliable than USEast1, but it's the same problem.Andthere's lots of good open-sourcesolutions to this problem.Again, T3Code is a fully open-source desktop appand web app now, too, that you can useto run all of your agents on yourexisting subscriptions and hop betweenthem at a moment's notice.I have hadtimes where Claude was down and I wantedto use it, but I hopped over to GPT 5.5and was fine or even hopped over toCursor, where they were using Opus modelsthrough other providers and also werefine. You can also deploy Claude onthings like Amazon Bedrock, which hasway more reliability and better uptimethan you would get out of using Claude.So, I don't love this vendor. Lock-in point. I think, like all things,reliability is your concern as a dev.The problem here isn't that we're allstuck relying on one thing. It's thatstupid devs have nothing else to do whentheir thing goes down, so they complainabout it online. An interesting pointhere is that you can't predict yourtoken cost. Model providers are heavilysubsidized, and the models themselves arebuilt on shifting sands. Every new modelfollows the same pattern ofhigh benchmarks followed by hype,followed by the reality of usage, andeveryone complaining about them beingnerfed and burning through 2x or 3x asmany tokens to get the same job done. This is a cloud complaint. This isabsolutely a cloud complaint. Like thisis not how it works at open land. Youguys are just so deep on cla code thatyour brains are falling out. Everyone,whatever side you're on, if you're aClaude Code diehard or a Claude Codehater, Claude Code specifically hasRuined the discourse about so many ofthese things. Oh, don't quote that. ThatPrimagen video, not that video. Not theone I had to tear to pieces because it wasso wrong. Oh, no. Don't quote that. Thisarticle was so good up until this point. You know how much your employees cost,but you have no idea how much your tokencosts will be day-to-day, month-to-month,year to year. If all of your costs arefixed, you don't have a real [ \_\_ ]business. I've never worked with acompany that is doing well that hadentirely fixed costs. Everything isflexible. Everything fluctuates. Computer costs skyrocketed because oftariffs and RAM being more expensive.Egg costs skyrocketed for restaurants. Afixed cost business is a failingbusiness. Generally speaking, I'm justgoing to skip this paragraph because Idon't agree. To be frank, I generallythink vendor lock-in arguments arecompetence failures. Good vendors makeit easier to do less work and the moveOut of a given vendor is just theadoption of the work you avoided doing. So the example I often give is Verscell.Moving off of Versell is easy. You justhave to write the code you hadn'twritten yet. I don't write code thatonly works on Verscell. I write codethat works on Versel that is missingpieces that I didn't have to writebecause I was using Verscell andVerscell handles it. When I leaveVerscell, I have to go add those piecesback in. Using cloud code means I don'thave to write the code by hand. Leavingcloud code doesn't mean I can't writecode anymore. It means I have to gowrite it myself again or use any of the15 other providers. Like there's so manyoptions. I just I don't like thisargument. Vendor lockin is not the rightframing for all of this. So let's go tothe last section here. Demoting AI'srole and certainly not advocating fortyping all code out manually. Programmers have always been looking forWays to create code without having towrite it. That's why we have things likeemit the autocomplete system that is inVS Code for shorthand. I always hatedEMTT personally, but each [their] own. Theyalso have traditional autocompletesnippets as well. I used to be like thebiggest anti-nippid and template guy. AImeans I don't have to care anymore,which is great. Even Cobalt was designedto encapsulate more instructions withless writing by using English-like wordssuch as move and write. BigQuery's mottowas write less, do more. LMS are anotheraddition to this array of codegen tools. What I'm advocating for, though, isleveraging LM's and coding agents as asecondary process, a way that doesn'tsacrifice the individual skill at thealter productivity. You can flip thescript and lean on them to brainstormthe planning parts of the process whilestaying actively engaged throughoutimplementation. Delegating to them on anas-needed basis. You can leverage theProductivity gains and mitigate thecomprehension debt. I'm going to gothrough his workflow and then I'm goingto discuss mine and my framing thatmight be a little different. He uses LLMto help generate specs and plans whilehe facilitates the implementation. It's an inversion of the orchestrationflow. He's still manually codinganywhere from 20% to 100%, depending onthe task. I use LMS to investigate butnot to write the plan. That'sinteresting. I very often am writingpseudo code when I do engage with themodels. Closing the distance between therequest and generate code. Yep,absolutely. I love writing pseudo code.I like doing it back and forth on pseudocode too, where I’ll have the modelgenerate the pseudo code. I’ll makerecommendations. We’ll go back andforth. I’ll be like, "Okay, that’s good.What does it look like in my codebase?"He also uses the models as delegationutilities for ad hoc code generation andInteractive documentation as well asresearch tools so that he can constantlyask questions, iterate, refactor, andgain clarity. Okay, now we're cooking. We'll go back there in a sec. He nevergenerates more than he can review in agiven sitting. If it's too much toreview, he slows down and splits thetask up, manually refactoring whenneeded to ensure a comprehensiveunderstanding of the end result. Andhe'll never ask an LLM or agent toimplement something that he's never donebefore or couldn't do on his own, exceptperhaps purely for educational ortutorial purposes and often discardedafterwards. Okay, he's dancing around aconcept here that I don't even know ifhe has embraced yet. The harsh realityis that most code wasn't worth writingbefore if it wouldn't be run thousandsof times. Any task that code can solve,a human can too, just not necessarily asefficiently. But if I only have to dothe thing once and it would take aThousand lines of code, it wasn't worthwriting that code. I would just do thething by hand. The important thing to dois to think about how important each function that you're writing is. Is thecode that you're writing code that'sgoing to be run thousands of times a dayby your users? Or is it code that'sgoing to be run once in a migration? Ormaybe you're doing some data analysisand you want to dig something outof 500,000 rows in a CSV, and you're onlygoing to run the code once. You justwant to get this info. Understanding howfrequently a piece of code is going torun is essential in understanding howimportant that code is and how importantit is to understand that code. And onceyou've internalized this, you can gofurther with it. When you realizethere's a lot of code where the qualitydoesn't matter because you're justrunning the thing one time and notthinking about it again, you're going tostart writing code for things youWouldn't have before. I have written somuch code for [ \_\_ ] stuff like one-offcalculators for checking numbers from one specific task I did, or writing a2000-line JavaScript file to manageassets on my NAS when I’m in the middleof transferring a bunch of files between[ \_\_ ]. Those things were never worthwriting code for before, because it would befaster to just sit there and do the taskyourself. Now, all of a sudden, it is waymore valuable to write code for thosethings. And that has been the biggestshift for me, is using the AI to writecode that otherwise wouldn’t have beenworth writing, and at the same time, usingAI to better understand the code that isworth writing. The harsh reality is thatmost people who are working with agentscan’t tell you which code is running atall, much less which code is running alot, and which code is run once. And ifyou don’t have that level ofunderstanding, you need to fix that. Butonce you have this understanding, and youCan think through the work you're doingin this range, you're going to find more value on both ends of that spectrum. Onthe end where you're writing code to runpersonally just a couple of times, you'llbe doing way more in solving way moreinteresting problems in more interestingways. And on the other side, the mostcomplex code can be explained to youwith an agent, and you can find the hotpaths and learn more about how it'sarchitected. And if there's somethingwrong with it, you can use the agent toadjust things at massive scales, like youcouldn't before. And I have found that Iuse AI entirely differently for the codethat is run a lot and is shipping tousers versus the code that I'm using forone-off tasks. And realizing this, andrealizing you can do better in bothareas with AI, is the powerful unlockI've been trying to help more of youhave. The author titles the nextsection, I'm not going faster, but I'mdoing better quality work. Why not both? is my challenge. Faster for the one-offthings, faster to solve problems, fasterto do stuff that wasn't even worth doingbefore, but improving the quality inthings that required too much manpower,improving the quality in things that youdidn't understand fully and now can. Getting more versions of a thing outbefore solidifying the one you want tocommit to. The code that matters shouldbe better quality because of AI. And thecode that doesn't should be 10 timesmore prolific because of AI. We shouldget both. And when those two getconfused with each other, everythingfalls apart. Let's wrap this up becausethis was an awesome article. I'll bereal. I want to let him have the lastword. The productivity gains from thesemodels are real. And so is the frictionand understanding that came fromengaging with the work on a tangible andfrequent basis. Despite countless failedattempts at trying to democratize codingwhile not understanding coding, we'reFaced with the reality that you cannotunderstand code without engaging withit. It's also become clear that if youdon't keep engaging in writing it, you can lose touch with that understanding,which will in turn make you a lesscapable orchestrator in the first place,rendering this phase of AI coding astrange and needlessly stressfulinterlude. Perhaps I am worrying toomuch, but history contains lessons. Thisall feels similar, though, like anotherlarge experiment we're running onourselves. We've been through a similarperiod with the introduction of socialmedia without understanding thelong-term implications, and we're nowfaced with attention deficit amongstmany other issues on a wide scale. Thistime we're gambling with something muchriskier. He ends with a quote fromJeremy Howard. People who go all in onAI agents now are guaranteeing their ownobsolescence. If you outsource all yourthinking to computers, you stop. Upskilling, learning, and becoming morecompetent. I absolutely agree. This is aphenomenal article from Lars. Definitelyrecommend checking out his blog. It'llbe linked in the description if you wantto see his other posts. This is far fromhis only great blog post. Definitelycheck out his indispensable value in AIera post as well as everyone candelegate now just from this year alone. Very thankful to Lars for writing this.This is an awesome read, and I hope youlearn something from it. Don't let theAI take away your thinking. Let itadvance your thinking, and you can buildbetter, smarter things as you learn moreand solve more problems. If AI isn'tmaking you smarter, you are using itwrong. And I highly recommend youreflect before you lose those valuableskills. It's a really important time tobe on top of these things now more thanever, and letting those skills atrophywill hurt your career long term. That'sall I have to say on this for now., We All Fell for It…, YouTube, 01krbkpyej4x739mkr3d9j9mjt.