«No escriguis prompts, crea bucles»: NeetCode separa el hype de la realitat dels agents de codi

I guess I'm losing it again, guys, because I really just don't get it. I'm trying my absolute best to keep up with what's going on, and I just don't get it. You might remember that not too long ago, the creator of Claude code, Boris, said that coding is largely solved. He's not writing code anymore. He's just prompting Claude to do that. And more recently, he's taken things a step further. Now, I would play this clip for you, but I've heard that I might get DMCA'd if I do that. But, basically he says that instead of prompting Claude now, he's actually not even doing that anymore. Prompts are actually dead as well. Like, not only was coding dead, but the new way of coding, which was prompting, that's dead, too. So, even though it was already dead, we just killed it one more time. And so, I want to talk about this new, like, this completely new way of doing things. He's not writing prompts, he's writing loops, okay? And that's very different, I suppose. That's the implication. At the beginning, he actually says that He says back in November, wasn't really using his IDE anymore. So, he just uninstalled it. Okay. I guess um you know, it hasn't rained in a few days. So, when I'm driving my car, I was just thinking it hasn't rained, so I I'll just uninstall my windshield wipers, right? Now, to me, this feels very performative. I'm just a neutral observer over here, just trying to understand. Okay, well, we all know like AI is progressing, coding is changing. So, I just I just want to understand, Boris. Okay, you're not prompting anymore. You said coding is largely solved. Now, we're not even prompting anymore. We're using loops. Like, why can't we get some like honest, clear communication? I don't have anything against Boris, and he's not even the only one. You can see the creator of Open Claw, who's now at Open AI, says the same thing. Here is your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents. Okay. And just a honest question of, "Okay, well, what's your workflow?" Nope, not going to answer. Okay, well, why would you even say that in the first place? It's like, "Okay, I thought you were trying to educate us." No follow-up tweet? Come

on. Well, okay, we actually did get a follow-up tweet, I think like 4 days later. Here's a simple loop. Tell Codex to maintain your repos, wake up every 5 minutes, and direct work to threads that makes it easy to parallelize, plus steer work as needed. I use a orchestrator skill combined with my triage plus auto review plus computer use skills, so some work can land autonomously. Again, I mean, the only thing, I don't know about you guys, but the only thing I feel like I learned from this, and and he doesn't even make it very explicit, is basically that in Codex, how you have like these threads, which are kind of like sessions, just like in ChatGPT, you can have one thread invoke and create other threads, which are independent and have their own context and all that stuff. That That's pretty cool. Like, probably could have just made a tweet saying that. I feel like that would have been more helpful than this tweet, but okay. Again, I'm just I'm just a neutral observer. We also had something interesting from Jared, creator of Bun, who I personally respect and trust a little bit more. But, if you go through this, starts with Jared, when he works on a large project now, the first thing he thinks is, "How can he structure his workflows with as many parallel clouds as possible?" Reply tweet, "I think similarly, except how do I structure this into workflows with as many parallel shot GPT-5.5s as possible. How do you orchestrate into specific parallel or serial steps? Ask and pray it does the right thing? Lots and lots of tmux sessions. Okay, so that basically implies that he's manually managing each of these parallel agents. And Jared replies, "Ah, yes, that was a good approach six months ago." Basically alluding to the same thing that Peter and Forest were talking about, that manually prompting is the old thing. Now, we just write loops that will write the prompts for you. And if you don't know, Jared recently ported Bun using AI, which I think was almost a million line code, basically like 700,000 lines of code in the language Zig, and he ported that from Zig to Rust, and I don't think it's been shipped yet. I think they're probably still going through some stuff, but he was supposed to write a blog post on how

exactly he was able to do that migration. Perhaps there is some secret sauce we can learn from that, but it's been a few weeks and we still haven't gotten it. You know, the common theme I'm personally noticing, I don't know about you, is that we're just really not getting a lot of clear communication from these people who are the authorities and are the pioneers in telling us the direction that coding is going now. And if you're not able to keep up, well, sorry, you're going to be left behind. And so that's that's what it feels like to me, but don't worry. I'm going to make a genuine effort to try to understand this stuff. I did, and I'm going to tell you everything I know. Unsurprisingly, the reality does not match the hype or the marketing material that we're seeing. But quickly before we get into that, do you feel like you want to have a better understanding of the code that you're shipping, but that it's only getting harder to do that? Well, that's where today's sponsor, Code Rabbit, comes in. Code Rabbit is the first AI code reviewer I used, and you can see here I'm using it for a pretty big pull request that honestly should be broken up. And if I want to now review this, I'm going to go top to bottom through these 40 files that are changed in random order. Not only does Code Rabbit add comments that you can choose to address or not, but recently they added something called a change stack. It basically organizes all the changes into these little layers on the left side. So, rather than just going through files randomly, you're reviewing like ideas that are grouped together. So, files grouped together. For example, you can see here the shared contracts and type interfaces. So, if I want to review those quickly, I can do so just by looking at these first few files. And once I'm done looking at that entire layer, I can kind of move on to the next idea, which is more of on like the back end side. This is probably where I would want to spend more of my time. So, now what I'm going to go ahead and do is take a look at this part, which is focus mode. Probably that doesn't need to be directly in the first

PR. It could be its own feature PR. So, I'm going to comment, let's move focus mode into its own PR. And by doing that, I can leave a native GitHub or GitLab comment. So, if your teammates prefer staying on GitHub, they can do that. You can try it out for free at neatcode.fyi/coderabbit. So, I'm just a random guy. I don't know how to think for myself. So, I go on Twitter to see what the thought leaders are saying. And so, I'm not picking Again, I'm not a hater. I'm not picking on anybody. But, I see this this post, Loop Engineering, that came out not too long after some of those uh posts that we were seeing about loops, June 8th. And this is from a former director at Google Cloud. So, clearly more qualified than I am. And frankly, I did not find most of this very useful, and there's probably a reason for that. Let's go to this section. What one loop looks like. Okay, finally, somebody's being concrete. Stick it together, and a single thread turns into a little control plane. Here is one shape I keep using. An automation runs every morning on the repo. It prompt calls a triage skill that reads yesterday's CI failures, the open issues, the recent commits, and writes the findings into a markdown file or linear board. The thread opens an isolated work tree and sends a sub agent to draft the fix, and a second sub agent reviews that draft against the project skills and the existing tests. Connectors let the loop open the PR and the ticket. Anything the loop cannot handle lands in the triage inbox for me. The state file is the spine of the whole thing. It remembers what got tried, what passed, what is still open. So tomorrow morning the run picks up where today stopped. And look at what you actually did there. You designed it one time. You did not prompt any of those steps. That's the point that Steinberger and others are making. And it's the same loop in Codex or Claude code because the pieces are the same pieces. Okay, I'm going to take a deep breath. First of all, I don't know about you guys, but I read this whole damn thing. It has 2 million views. I mean, it's just AI slop, right? Like you guys can tell, right?

I mean, at the very least, at the very least, the person who wrote this used GPT or some LLM to rewrite it for them. Maybe it's their ideas, but the writing is clearly LLM. Look, build the loop, stay the engineer, automations. This is the heartbeat. I could be wrong, but I'm pretty sure nobody talks like that. Why does that even matter? Well, I guess because I don't know. I I just feel like I'm living in a freaking Looney Tunes episode or something because are we just going to pretend like this is like I don't know. Like I put it into an AI detector and uh it got pretty high scores. And now who knows, maybe this isn't accurate, but I don't know, man. I don't know. If If we're all just The reason that matters is because if this is just slop, then we're just like in this circular cycle of slop. We're just consuming our own slop, and Oh, my. That aside, what actually matters here here? Well, if you paid attention to that part, I I I don't know. Like, we're we're making it seem like this is some completely new paradigm, and so the the the main at the core what I'm like sensing, I'm understanding here is that this is a pretty simple concept. It's basically about setting up a prompt. I guess they're calling it a loop. Basically, about having a long-running task, aka a loop in this case, and that loop can run for a long period of time, I suppose, like until some kind of end state is met, or it could just run continuously, like a cron job, right? So, I don't know about you guys, but it seems pretty trivial to me. I'm being told I'm going to be left behind because I can't keep up, but conceptually, this is very trivial stuff, in my opinion. Like, let me give you an example that that would apply to like my site. Let's say I get a bug report. Now, wherever that is, maybe it's a GitHub issue, maybe it's like directly through my application, and this is stored somewhere. That's In my case, that's a database. Let's say it's for my actual application. So, I'm getting bug reports that are here. Now, typically, it's going to be me, right? I'm going to be the developer looking at the bug report, validating

it, and then possibly fixing it, and then shipping it. But now, I'm a super genius, guys. I'm on the level of Boris. I don't write prompts anymore. I write loops. So, what I'm going to do now is I'm going to say, "I'm not going to look at bug reports anymore. I'm going to go straight to Codex or Claude or whatever, and I'm going to tell my agent that how about every 24 hours, I'm specifying this, every 24 hours, I want you to be the one that reads all of the bug reports, and then for each of those bug reports, I want you to spawn another sub-agent. So, let's just say these circles are like our bugs. And so, I'm going to spawn a sub-agent for every single one of those bugs, and then each of those sub-agents is going to have its own context, and it's going to validate and attempt to fix that bug. Maybe it's going to open a pull request, and then uh I don't know how to finish that drawing, but let let's say uh for that bug, we have a PR. And then me, the developer, I am the human in the loop, and I will be the one to decide whether that's merged or not. At least that's one way to do it. Okay, so I don't know about you guys, but like oh is this what everybody's talking about? I guess this is one possible thing, and there are details that go into this, and those details, I guess everybody's just glossing over, are pretty important. For example, how exactly like are the details? Like like what would I tell the agent to set up a system such as this? Well, I would tell let's say I'm doing this in Codex, just knowing what we now know about threads, I would tell I would give this to one Codex thread, like I'm I'm using one thread, but then that thread would spawn these sub-threads every 24 hours, depending on like the bugs. So, I would probably specify that, because I want the thread to be uh independent. I want each of these threads to be independent. And so now, if they're independent, and if they're working on the same code base, I don't want those changes to conflict. So, okay. So, I'll put those changes in a separate uh work tree. That's a GitHub

or a Git concept, which is basically like a at a high level just like a fresh copy of a repo, kind of like a branch, but you can have multiple work trees instantiated at the same time. Um with branches, you can really only check out one branch at a time. So, we're saying some of these fundamentals are still important. And now, in terms of how uh is the agent going to read these bug reports? Like in my case, right? It's in a database. So, there are multiple ways it could do that. I could have my agent like directly read the database, like some kind of query. And then, once an issue is fixed, so let's say I fixed this issue, well, then we can mark it resolved. And we could manually just do that in the database. That's a potential way to do it, but I guess an alternative way to do that would be maybe give the agent a better API because potentially this could be error-prone. The same way it would be for a human. If I'm a human and manually writing a query and then manually running like an insert statement on my database to update that uh bug as resolved, kind of error-prone, right? So, maybe rather than doing that, I know agents actually are pretty powerful nowadays. I can give each of these agents access to its own browser. As a human, when I'm looking at bug reports, I'll probably be using some kind of UI interface. I could give it access to the browser, give it the credentials, so then it can have a better API. It can be less error-prone. Okay, so those are two ways to do it. Which way is better? I might have an opinion. I might look at some of the tradeoffs, but maybe I'll just test both to see which one is better cuz a browser uh is going to be a little bit slower for an agent to interact with versus just raw dogging like the SQL. I I mean, I'd be happy to sacrifice speed and performance just to like not have some random uh might get my database dropped or whatever, right? So, okay, I guess this is one thing. I mean, another thing would be this is obviously an example of something that's going to run potentially forever, not literally, but if it's going

to run periodically every single day ongoing. And it might be super useful. This is a system I've actually already set up. So, I guess I'm I guess I'm a super genius. Like I'm looping. Are you guys looping? Because if you're not doing this, you know, you're left behind, I guess. Another potential thing would be like a bounded thing. For example, some kind of migration, right? Like what a Jared did. I guess that's also considered a loop. Not I'm not the subject matter expert here, though. So, take that with a grain of salt. The number 100% is very hard to reach. Let's say like the agent was correct 95% of the time on each iteration. If we have 10 iterations, it's not multiplied by 10. This is basic math here. Now, I'll need a calculator to actually give you the result, but conceptually, the the concept here is one that I'm pretty familiar with. It's just a basic concept called exponential decay. I'm sure some of you might know it. Like you have 95%. That's the number 0.95. 10 iterations would be raising it to the power of 10. And I think like I'll need a calculator again to do this, but conceptually, it took me the human to figure to to speci- to do this, to set this this loop up, I I guess you could say, but it's 0.5. So, it's like The point I'm making here is just that unless the agent is going to do it perfectly with perfect accuracy, the crap is just going to compound and get worse and worse the longer you let it go. And this is And this part is my favorite. The creator of Flask, I guess agrees with me a bit. I decided to do some experiments with looping over the weekend. The only cases where they work so far for me are A, review. I think what he means is have setting up like a loop that reviews the work and if there's issues with it, will fix those issues. That's definitely one that I I use as well. Like anytime I create like a big change, I'll basically tell it like run Code Rabbit or some other review tool and keep continuously running that tool and addressing the issues until there are no more addressable issues left. Reasonable approach. AI can be pretty decent at identifying issues. If

someone uses them for actual implementation on a medium-sized project, would love to have something to look at. I completely agree. And Jared replies and he says, "In my opinion, loops work best around a task queue. More like a for each rather than a while." So, this is the part that just I won't say pisses me off, but bothers me a little bit because weren't you just saying that that like implying that we should be looping now? But now now only two or three weeks later, now we're discovering the limitations? That's how you know that this is just a like everybody's just waiting to see how this plays out. There are no experts on this stuff. There are only people who pretend to be experts. And by the way, he used a analogy here. In case some of you guys are vibe coders and you don't know what a for each and what a while loop is. Well, a while loop is just something that runs continuously until like a condition is met. Kind of like an agentic loop if you're a vibe coder. A for each is a loop that goes through predefined sequence. And he's saying that actually loops are like implying at least that they're not suited for the latter, like the while case. That if you just like let it run loose, that's actually not like the best way to use it. Okay, I mean, fair enough. I wish he would have said that 3 weeks ago, but maybe he didn't know that 3 weeks ago. Okay, fair enough. I spent a lot of time talking about some of the takes that I didn't like, so I'd want to close with a couple takes that I think are a lot more fair and balanced. I think this one from Mitchell Hashimoto, who I think is very like balanced on this stuff. He's not like for or against AI, but he'll call out a lot of the BS. And he basically says that he got an agent loop where he was trying to optimize a renderer, and he got it down from 88 milliseconds to 2 milliseconds. And he says it sounds good, right? No, it's not. And then he goes on to explain why in the rest of the post. I'll link this in case you want to read it. There's one other thing, which is this talk

from Google. I'll also link it. I won't go through all of it, don't worry, but I would recommend you guys consider doing so because I thought it was actually very fair and balanced. I'm not just saying that because it's Google making it. I'm not trying to say there are good guys or bad guys. I'm not trying to say Anthropic is the bad guy. I think it's more about looking at the incentives of who's talking. When you see Boris talking or anybody from Anthropic, unfortunately, they have some pretty strong incentives to build the hype, and Google does not have the same incentives to build hype for agentic coding. Only really, when you think about it, OpenAI and Anthropic too, mainly. I guess Cursor as well, but they've been I think pretty fair about things. And so, you know, if you're wondering why you're not seeing like any of the other companies hyping this stuff up as much, well, that's why. It's not like everybody else is dumb living under a rock and knows nothing about coding or agentic coding. It's just that they're being a bit more honest, I guess. But there was one segment about this on going on how fast you should go when building software. And speaking of rollbacks, do you guys know why rollbacks work today? Basically, it's because you release software slightly slower than it takes you to defect or to detect a problem in production. If you can release software really, really fast, faster than you can detect anything is wrong, what does that mean for your rollback posture? Every rollback will now have to contend with multiple conflicting changes landing on top of it. So, it's not just enough to release faster, we have to consider the whole system, the rollback as well. That's a really important safety valve. >> It took him like 30 seconds just to make a very good take, and a take that you kind of wonder if you're just you're terminally online scrolling through Twitter pretending like you're learning something new every day about coding, but you're missing some of the most basic stuff that nobody on Twitter is talking about because everybody's too busy creating their slop posts or just vague posting and not telling you anything. And I just I'm just tired of it. I'm sorry. Not being a hater, but I'm really just tired of it.