6 ms·

Control the Ideas, Not the Code

• m_ke 3mo ago
  I tried really hard to do this, but it turns out the models don't care about your ideas and want to do what's popular in their training data, so they will happily ignore anything you try to force down their throats, especially as context length grows or if you hit compaction. So to make best use of the models steer them down familiar paths, mention common pattern and frameworks, use popular packages and languages that have the high median quality online. I started my project with a few simple interface definitions and a short design / architecture doc that I include in the AGENTS.md file, but no matter how hard I try all of the models just end up ignoring it and sprinkled new seeds of variants of the same stuff all over my code base, that with each new session grow new branches.
  • logicprog 3mo ago
    I do highly unusual, off the beaten path projects with AI. For instance, a game engine written entirely in LuaJIT, but allocating almost all data structures using CFFI, a very unusual, custom object-orientation DSL I designed myself, and that uses SDL3's SDL_gpu library to do all rendering, a ton of GLSL 4.6 compute shaders cross compiled to SPIR-V and Metal (which constraints what GLSL can be written), and is a hybrid tile-oriented and 3D engine. Another example is my Emacs-like live-modifiable image-based editor, again in LuaJIT+CFFI, with a kqueue+atomic lock-free ring buffer+pthread based actor model, each running a separate LuaJIT interpreter, with a custom advicing system, event bus, async/await implementation riding on the event bus, a custom process management and IO library, and testing via Tmux. Even DeepSeek V4 Flash mostly does fine with this, once it's built a few memories in the memory system. Let alone something like DSv4-Pro or GLM 5.2. All I can say is skill issue.
    • m_ke 3mo ago
      It's not an issue of usual vs unusual, I'm saying the models are way better at writing and maintaining django or react code bases than your own hand rolled architecture that you define in some docs that it has to learn and keep in context. All of the models do an amazing job making local edits and working in small greenfield projects but once you get to full production systems with close to a million lines things start to rot. The code still works and the models are able to make progress but all of a sudden you have 3-4 different versions of your concepts sprinkled in random corners of your code base. My second point is that the models are way better at things like Rust or Lua than Python or JS, because the average person producing code in those languages has way more programming experience, so the code quality of training data online in those languages is higher than the programming 101 medium blogspam type content you see in more popular intro languages.
      • logicprog 3mo ago
        I haven't hit nearly a million lines, that's true, these projects are "only" 20k and 45k lines of code or so, respectively; however, I do have directed acyclic graphs of worker agents, managed asynchronously by the agent I chat directly with, do huge architectural refactors (the most recent, was to update everything in the codebase that used the sychronous Lua standard library `io` functions to use the asynchronous, multithreaded IO system I created for the editor — at least, everything that could use the new library, which I kept deliberately simple in a few ways, and everything that wasn't already temporary, but you know) and that's turned out quite well, and at least for me, 45k sloc is nothing to sneeze at, especially since with a green field project there's less examples to keep them on track. I do regularly check in to make sure it's using my design to the fullest, as well.
        • noopprod 3mo ago
          [dead]
      • justincormack 3mo ago
        At 600k lines of Rust, not finding those issues yet. You can search for different versions of same concepts, I mean you need to refactor a lot anyway.
        • Chu4eeno 3mo ago
          Did you actually manually review the 600k lines of code? And the reason LLMs tend to produce such insanely large codebases is partially what the comment you're replying to explained, they duplicate everything all over the place.
          • SR2Z 3mo ago
            "You are violating the DRY principle with code like <blahblah>. Look through the codebase in depth, and identify possible places to consolidate common logic." Yeah, there's no substitute for taste, but this is not that big of a deal. I infinitely prefer repeated code to crappy, leaky abstractions. Let the model generate some slop, then tighten it up either by hand or with more prompting.
    • saghm 3mo ago
      > All I can say is skill issue. I don't necessarily disagree with the overall point you're making, but I think calling it a "skill issue" is a bit reductive. These are relatively new tools that are changing quickly, and the amount of flexibility in how you can use them is a lot higher than pretty much anything else we've built up patterns for in the industry in recent years. Rather than dismissing people who express having trouble producing the results you can, I feel like we should be giving lifting others up by providing insights into how we're able to do those things when we know that they're possible. Otherwise, how do we know it's truly a "skill" issue and not a "knowledge" issue, and the only thing stopping them is that no one has helped them understand?
      • logicprog 3mo ago
        In my experience, because as you say, the flexibility of these tools and how you engage with them is so broad, and how much the nuances of thay engagement can often matter, the only way to teach someone how to do what you do with them is to sit down and pair a program with them. Barring that, any instructions you could give would massively under-determined what they actually try as a result of your instructions, and so it ends up being an infinite loop of them just coming back and saying "it doesn't work." So in the end, people really just have to discover how these things work for themselves.
        • saghm 3mo ago
          That's a completely reasonable take. I wouldn't have any issue with a nuanced comment like that. My issue with your above comment is that it's a lot more arrogant than nuanced.
          • noopprod 3mo ago
            [dead]
          • logicprog 3mo ago
            That's fair, I think my point is there's a nuanced theory behind my choice to be rude, which is essentially "you need to experiment more, be more open minded, really work at it, and then you'll see what others are seeing, it isn't impossible." It's like Dark Souls, nobody can beat it for you, or teach you how to use dodge rolls, you've gotta build that skill yourself, and blaming the tools won't help.
    • ssivark 3mo ago
      > All I can say is skill issue I know nothing about you or your code, but till you make your code + workflows public and have all of it reviewed / critiqued (so that other can replicate the performance), it's hard to accept it as a serious case study. For all we know, this could just as well be a severe case of Dunning-Kruger.
      • InkCanon 3mo ago
        Not specifically about the comment you replied to, but there has been an absolute Cambrian explosion of plausible sounding projects that use really complicated words that are just AI psychosis. Recently there was someone who posted a huge Lean proof on GitHub supposedly of proving P=NP. The problem is AI is really good at deluding people if that person doesn't have domain specific knowledge. AI severely makes dunning Kruger worse
      • fzeroracer 3mo ago
        I've found this to be more consistently the case than not. People almost never post their project and in the rare cases that they do, it's usually some shambling mess that doesn't actually function. They put together a keyword soup post that sounds good on an AI generated resume but falls apart upon investigation.
        • logicprog 3mo ago
          Its hard not to feel insulted here. "Projects using AI like this don't exist, and if they do, they're broken and the people who made them have psychosis." However, although I haven't tested my projects cross machine, or cross platform yet (my editor only works on MacOS because it uses kqueue), I would be happy to take an unedited video demonstration of both, I assure you they both run.
        • jryle70 3mo ago
          > People almost never post their project and in the rare cases that they do, it's usually some shambling mess that doesn't actually function It's funny because you chose to target the one who is pro-AI, who has since posted their code, and not the GP who is against AI, who also didn't post any code to support his opinion that "it turns out the models don't care about your ideas and want to do what's popular in their training data". Do you see the irony?
    • atoav 3mo ago
      It is easier to get an LLM to tell an unusual story using the most popular phrases than have it tell a common story using off-kilter uncommon phrases. The big arc is easy to get using an LLM, getting it to do the details correctly, that is the actual hard part. So in my cases I (by other people's account a legendarily patient person) lost my cool trying to get a LLM to write CSS in a way that makes any sense if you have a design background. I ended up rewriting the whole CSS by hand, because it is inconsistent, piecemeal and just doesn't make sense. Yeah let's make everything bold and important. Yeah let's write internal implementation details into a label in the UI. I decided to use LLMs as an aid to my own thinking, not as a replacement.
    • dominotw 3mo ago
      things you described are not "highly unusual" in the way gp comment is describing. you are just remixing bunch of stuff. Thats the type of thing ai is really good at.
      • logicprog 3mo ago
        The GP was just talking about not using common languages like TypeScript and frameworks like React, which is a bar of unusual that seems arguably far lower than mine, especially since I literally defined special custom DSLs with unusual semantics, and used libraries like SDL_gpu with little to no pre-existing training data. So this seems like shifting the goalposts. Also, what would be highly unusual to you?
        • dominotw 3mo ago
          > The GP was just talking about not using common languages like TypeScript and frameworks like React i dont see anything like that in that comment.
          • logicprog 3mo ago
            "It's not an issue of usual vs unusual, I'm saying the models are way better at writing and maintaining django or react code bases than your own hand rolled architecture that you define in some docs that it has to learn and keep in context. All of the models do an amazing job making local edits and working in small greenfield projects but once you get to full production systems with close to a million lines things start to rot. The code still works and the models are able to make progress but all of a sudden you have 3-4 different versions of your concepts sprinkled in random corners of your code base. My second point is that the models are way better at things like Rust or Lua than Python or JS, because the average person producing code in those languages has way more programming experience"
      • Chu4eeno 3mo ago
        The most esoteric I've seen from an LLM was this light rendering fix in a TempleOS game engine: https://gitgud.io/CrunkLord420/cyberchud/-/commit/c49879751c90a1a6b1e5fe213e604746472544d2 https://gitgud.io/CrunkLord420/cyberchud/-/commit/c49879751c... Though it's still cheating with a compatibility layer, I don't think claude touched any HolyC.
    • mpweiher 3mo ago
      Maybe the key difference is that you are so far off the beaten path that there simply are no examples of what you are doing that the models "want" to emulate? I've also had reasonable success with the models generating fairly idiomatic Objective-Smalltalk, my own language of which there are likely few to no examples in the training data. I do steer them towards my own sample programs.
    • rstuart4133 3mo ago
      > All I can say is skill issue. I regularly see claims by people that they have produced large, reliable bodies of code using vibe coding. Unfortunately, no vibe coded project I've used comes anywhere close to code reviewed by a human. Admittedly, my sample size is very small: things like claude-code, OpenClaw, and the occasional project I see mentioned here. But compared to the things I used regularly like GNU coreutils, Firefox, Linux, vim, git and the hundreds of other software projects I use daily, vibe coded apps are in a different ballpark. Vibe coded apps of a few 100k lines often glitch several times a day, the traditional ones that have several orders of magnitude more lines often don't fail in several years of use. AI is now being used to assist in creating and maintaining these traditional bodies of software, of course. It looks like it has enhanced productivity as open source contributions have grown by 20% or so, and we've only just started to learn how to use it. I haven't noticed any degradation in quality. It may be too early to tell, but I suspect the engineers involved wouldn't let that happen. As you say, it's a skill issue - it takes considerable skill to produce reliable maintainable code. But I suspect that wasn't the skill you are referring to.
  • throwaway613746 3mo ago
    [dead]
  • cyanydeez 3mo ago
    right, the model will listen to you for ~32k context; half of that is just getting them into the "downhill" path for being a coding assistant. You can throw in whatever your heart's desire and if it's a single fix, it might listen to you; but treating it like a smart-IDE basically means it'll follow whatever dominant pattern is in the training data. If we had smart capitalism (the SAME PROBLEM) we'd realize what we want are per-framework or per-OS models that simply are 80% how to english and 20% the tools we need for a given project. But that's no where the money is.
    • m_ke 3mo ago
      yeah I tried rules, hooks and forbidding things like pip / python3 but it just led to the model failing to do what it wants and a bunch of token churn trying to get around my more rigid constraints. main problem is that the harness files get loaded into context early in the session and slowly wash away as new information comes in.
      • cyanydeez 3mo ago
        i've been playing around with https://github.com/bytedance/deer-flow https://github.com/bytedance/deer-flow and they seem to figure out how to get around context sizing issues and has a more automated prompt system. Essentially the problem with current hanrsses is they just can't find/evict context and want to ensure KV cache isn't evicted. If they evict the old prompt and tried to keep all the proper rules, then you get token churn anyway, as what you want is an entirely new chain of events where your rules/guidance sit at the front of the model chain. What we're getting to is there really isn't an economical way for cloud models to do it; you can do it with a local model, but at comfortable speeds, you need smaller sized. I think a good harness via Qwen3.6-35B-A3B is possible, as the token gen is only 3B since that's the active parameters. So it's mostly that to keep rules pinned to the top of the context will either bloat the model or it'll evict the KV cache.
  • _doctor_love 3mo ago
    The key is to remove degrees of freedom from the agent. IMHO this is the really hard work of agentic engineering. You need to strongly constrain what the agent can even do in the first place to force it into a certain area. That runs the danger of putting the model out of distribution, of course, so it takes some experimenting. I'm working on a Ruby project where - on purpose - I'm disallowing any frameworks other than what's standard Ruby. So no Rails or Sinatra, just the inbuilt Webrick web server. Initially it was hard to keep the model on the rails but as I've learned more it gets easier. That said, it's clear to me that the model pulls very strongly in familiar directions in terms of how it writes code, i.e. a lot of what gets written still ends up looking "Railsy" even though my learning project doesn't use it.
  • iwontberude 3mo ago
    It makes everyone more average and same-y. It’s a good average, better than bad, but I cringe everytime I see someone claiming it’s a force multiplier for their personal expression. Bullshit.
• inigyou 3mo ago
  As a reminder, Redis was widely replaced by its non-vibe-coded fork Valkey.
  • logicprog 3mo ago
    Do you have any evidence for Valkey "widely replacing" Redis, instead of just rapidly gaining adoption as well? Additionally, it's important to clarify that the replacement was 100% over licensing issues — iirc predating the vibe coding entirely — not the use of AI to code, and that furthermore, no one has to my knowledge pointed to any flaws in the Redis codebase even correlated with AI use. So this is a disingenuous framing.
    • inigyou 3mo ago
      100% of the employers I worked for since the time of Valkey had replaced Redis with Valkey.
      • dominotw 3mo ago
        i am currently working on this exact migration at my company. aws also kind of pushes valkey so ppl seem to choose the default.
        • antirez 3mo ago
          Sure, it costs less, and AWS is in a dominant position. Users here are playing the side of the bully since they don't care about what is right and wrong with the hyperscalers. "BSD is better than AGPL!" And give money to the wrong side of the history. Nor that I expected anything better, the single person has a given sensibility, the mass, as a whole, do whatever is in a given moment convenient or believed to be more pure (license wise). However thanks to that, you will see how little progresses we will have (and we are having) in the space of open source system software with very open licenses. Developers of software mostly are not happy to bring OSS to the success to see them used by hyperscalers to capture all the value. However I did it again, with DwarfStart, to release code under the BSD license: even in the current situation, I think it is better to give back than to have a personal gain, but this is a position that very little folks can afford to take. However: this conversation is completely out of topic but people instead of talking about AI and code, which is a tabu, will move the conversation to personal attacks and shit like that.
• witx 3mo ago
  Follow the vibes
• alexpotato 3mo ago
  For some background on me to set the context for the following opinion: - been a SRE/DevOps at banks/hedge funds for almost 20 years - now work in L1 crypto - have been coding since I was 12 and have also been using frontier models for the past year (including running multiple agents at the same time etc). My thoughts: The models are indeed amazing. They can read large codebases, find bugs, infer the root cause of an issue from partial logs etc etc. They do still hallucinate. WAY less than they used to but it's still non-zero. In a way that's worse b/c the model will spit out a complex piece of software and say "Yep, no mistakes. I even wrote tests and they all pass!" You might think "Phew, that's great!" but in the same way we've all found bugs in production code written by smart people, there will be bugs here too. I say this not to imply that you have to read all of the code. I say if only to underline that for big complex systems, the "let's write unit tests for the parts that ABSOLUTELY HAVE TO BE CORRECT" is still just as important as it ever was. I'm thinking of examples like: - the order and execution handler of a trading system - avionics flight controls - healthcare related medical devices - etc As an example: I was working on a complex system. I wasn't sure if the LLM code was actually correct so I wrote up a quick script that I checked, line by line, to be 100% sure it was working as I expected. I then used that script to double check the LLM. I didn't read all of the code the LLM created. The sense of "ok, now this works" was astounding. I'll add, a lot of the developers I work with are going this "hybrid" route too where they will have the LLM write code and tests but then go back in and double check. In closing, a lot of these big rewrites with LLMs are possible only b/c the devs KNOW, FOR A FACT, that the unit/integration tests are correct. I'm still not convinced that you can have LLMs write all of the code and all of the unit tests and be 100% sure that it's all correct. (I will admit that this has always been difficult and even the pre-LLM days were not a guarantee that all of the code wa s correct)
  • hollowturtle 3mo ago
    You can have almost 100% tests coverage and green tests and still have a plane crash and LLMs shilling with you that everything is ok. To me it seems we havent learned yet tests coverage means nothing without solid code
    • notpachet 3mo ago
• qiaobax 3mo ago
  [dead]
• preetham_rangu 3mo ago
  [flagged]
• zetalyrae 3mo ago
  There are no "ideas" independent of expression.
  • falcor84 3mo ago
    What do you mean? Are you arguing that it's impossible to fully translate things? Would you argue that "apple", "manzana", "pomme", "mela", "maçã" etc. all refer to different ideas?
    • jgeada 3mo ago
      "Apple" is a generic name, that does not actually really express anything particularly specific. Eating apple, cooking apple, cider apple, pig feed? Granny Smith, Honeycrisp, Red Delicious? All apples, wildly different, all common. Even within the more commercially available variants there are significant differences: https://www.jessicagavin.com/types-of-apples/ https://www.jessicagavin.com/types-of-apples/ Heck, just for cooking apples there are huge number of different varieties: https://en.wikipedia.org/wiki/Cooking_apple https://en.wikipedia.org/wiki/Cooking_apple Yea, "apple" as an idea doesn't really express anything concrete without lots more context. And without more context, Apple may even mean something that isn't even a fruit, but still popular: www.apple.com
      • falcor84 3mo ago
        > "Apple" is a generic name, that does not actually really express anything particularly specific. ... > "apple" as an idea doesn't really express anything concrete without lots more context. I understand where you're coming from and appreciate the nuance, but can't help to feel that you've moved the goalposts from the earlier: > There are no "ideas" independent of expression. I never meant to claim that ideas have to be concrete or specific, if anything, the best thing about an idea is that it is not any of those. And it's clear to me that you did perfectly understand what I meant by: > "apple", "manzana", "pomme", "mela", "maçã" as you then said "isn't even a fruit", so I was able to effectively communicate to you the abstract idea of a particular type of fruit. Communication of ideas does work to promote coordination of actions (in this case a comment thread on "the same topic"), and while flawed and fuzzy, I don't see how it could function if there were no ideas independent of expression.
• pixlmint 3mo ago
  It's kind of ironic reading a post with such bad grammar written by someone that seems to be so pro-AI
  • krupan 3mo ago
    I didn't want to say that out loud, but you are right and it's unfortunately hard to understand some of what he's trying to say
    • pixlmint 3mo ago
      Exactly. And I don't want to encourage him to have the AI write the whole text, just to let it proofread what he wrote. It's a natural language processing tool. Let's use it for that.
  • antirez 3mo ago
    I'm against using AI to write text targeting other humans.
    • hbcdbff 3mo ago
      I appreciate the human writing, fwiw
    • pixlmint 3mo ago
      [dead]
  • thraxil 3mo ago
    You realize he's not a native English speaker, right? His English grammar is better than my Italian, so I don't feel the need to criticize.
    • krupan 3mo ago
      There's a difference between criticizing and saying, "I'm sorry, I don't understand what you are trying to say."
• kamranjon 3mo ago
  Some of the most exciting engineering work is happening in the DS4 repo - and I'm watching it almost like a sports game. When the DSpark paper came out[1] the next day we had folks attempting to implement, working together, validating their failures. Eventually their work being synthesized into a PR[1] that admits performance is not ideal. Something antirez alluded to in one of his videos (speculative decoding is a great boon, but mostly for large labs hosting and serving many requests at once, and maybe not so effective for local inference). There's recent work into "directional steering"[3] that has made it's way into per-session directional steering overrides thanks to audreyt[4]. There's support for the new Hy3[5] model also thanks to audreyt[6]. There's Pre-M5 optimizations[7] in the queue thanks to ivanfioravanti who also helped with some of the initial M5 optimizations. I haven't watched a repo like this since llama.cpp and whisper.cpp in the early days (though llama.cpp is pretty exciting right now with the SYCL improvements that are flowing in for the new Intel GPUs). The DS4 repo is a really interesting place to watch folks who heavily code with agents collaborate together in a way that seems pretty effective. I've been really enjoying it. [1]: https://arxiv.org/abs/2607.05147 https://arxiv.org/abs/2607.05147 [2]: https://github.com/antirez/ds4/pull/502 https://github.com/antirez/ds4/pull/502 [3]: https://arxiv.org/html/2406.00045v2 https://arxiv.org/html/2406.00045v2 [4]: https://github.com/antirez/ds4/pull/148 https://github.com/antirez/ds4/pull/148 [5]: https://hy.tencent.com/research/hy3 https://hy.tencent.com/research/hy3 [6]: https://github.com/antirez/ds4/pull/523 https://github.com/antirez/ds4/pull/523 [7]: https://github.com/antirez/ds4/pull/555 https://github.com/antirez/ds4/pull/555
  • antirez 3mo ago
    Thanks! And sorry for not yet merging many of those. The problem is, I'm dealing with tensor parallelism for the CUDA and Metal-RDMA fork right now, so was not albe to care about PR / issues for a lot of time.
    • zozbot234 3mo ago
      I don't want to sound overly dismissive, but for quite a few practical cases pipeline parallelism with micro-batches will be a likely win over tensor parallelism. Of course this inherently comes with a requirement to take batched inference seriously for local use, at least in special cases where this doesn't put too much of a requirement on memory capacity. By comparison, tensor parallelism is probably good wrt. making memory- and KV-cache hungry models like GLM 5.2 and perhaps Kimi genuinely viable in a non-trivial local inference scenario.
• danceparty 3mo ago
  Very uncomfortable to read. The proposed idea of not reading the code you ostensibly wrote, doesn’t just challenge the traditional workflow or methodology, it challenges the identity of a programmer itself. For experienced, respected programmers like antirez perhaps reading and writing code truly has just gotten in the way of the ideas, but I cannot identify with that perspective. The devil is in the details, reading other peoples code (and code the LLM writes) evolves the idea itself, and changes my understanding of it. My view on this is so biased by the direct relation of code I read and write to feeding myself and my family (the vast majority of my programming is for a paycheck) that suggestions of removing myself from the process feel grim, not exciting.
  • wongarsu 3mo ago
    For complex code changes or bigger features I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions, etc. It's not that you spend less time refining ideas, you just do it at another level of abstraction But that does come with tradeoffs, and it's not the right thing for every project. But when it does work it does increase the amount of work you get out in the same time
    • qsera 3mo ago
      >For complex code changes or bigger features I often spend hours with an LLM refining architecture The problem here is that the LLM hallucinates, so * it will tell that something is a bad idea, even when it is not. * it will miss good ideas. But here is the thing. Even discussing with a rubber duck can do wonders to your thought process. So may people who are noticing the usefulness of this procedure might be actually just doing a slightly better rubber ducking...
      • wongarsu 3mo ago
        Yes, a better rubber duck is a decent description The LLM will often miss the most obvious simplifications. And if I ask it to present me with six approaches how we could solve a problem, chances are we will settle on number seven or eight, both my ideas after rejecting all the other six. But those first six were still valuable for coming up with the version we actually settle on. Making the rubber-duck talk is genuinely useful. And the rubber duck is actually pretty good at the localized grunt work, so you can spend more time talking with it about big-picture stuff
• rbehrends 3mo ago
  I am not sure I'm buying this. The raison d'être for our existing software engineering methods is that humans make mistakes and we needed to contain the effects of these mistakes; and without an appropriate methodology to do that, software defects will just accumulate over time. Worse, once they show up, nobody understands the code well enough to do anything about them, or at least not without considerable time investment. This does not change with agents doing the coding. Coding agents make mistakes also. Not very often nowadays, but neither do competent human programmers. And without a methodology to keep problems in check your agentic code will also accumulate software defects over time and result in code that becomes less and less maintainable, because you have no mental model of the software. Antirez is correct in pointing out that slop existed before we started to use LLMs for programming; I've worked with my share of really ugly legacy code myself. But the problems do not magically disappear in the LLM age, no matter how good your model is. They remain, as every model is ultimately a heuristic (albeit a very powerful one), and no heuristic is 100% accurate. This does not mean that coding agents are useless; used correctly, they can be enormously powerful accelerators for the software development (and validation!) process, because combining your strengths with those of a modern LLM is generally a substantial net gain. But that must still happen as a part of an approach that results in maintainable software with minimal defects. Personally, I primarily use agents as virtual pair programmers these days, which I find very useful. This is an iterative process with relatively small and contained changes, where "looking at the code" is just part and parcel of following along and building a mental model of the resulting piece of software.
• krupan 3mo ago
  I think the gist of what the author is saying is, AI is not good enough to just give one vague prompt to and let it go, but it's good enough for you to give it a "design" and then not worry about the actual code it writes. But you need to do a lot of QA still. And you still need to learn to code and write some code, I guess so you can give the LLM good instructions? But if giving good enough instructions requires some level of coding skill, how are you going to gain that skill if you don't do much programming or reading code? It all sorta feels like an old guy (he says he's old in TFA) who forgot how he got to where he is today trying to give advice. Be careful what you believe, young programmers.
  • antirez 3mo ago
    Never comment till you read the whole post, since your question is exactly addressed at the end.
    • krupan 3mo ago
      The end is where you said people should still learn to program, I wouldn't know that you said that without reading to the end.
• hbcdbff 3mo ago
  This position assumes that purely LLM-written codebases are able to scale infinitely. IMO there isn’t enough evidence for me to feel comfortable in that judgement. Anecdotally, I find that pretty often LLMs (even bleeding-edge models) write unidiomatic/unscalable/poorly-abstraced code when working in large codebases.
• jgeada 3mo ago
  Ideas are a dime a dozen. All of us have half a dozen of what appear to be good ideas every. Execution matters, testing and sanity checking matters, actual engagement with users and iteration matters. Sure, we're reducing the cost of idea -> prototype to near zero (well, as long as tokens are free or nearly free), but that just means we now have mountains of throw away code, within which there may a gem or two. Nothing yet has replaced the curating of ideas that good teams do as a matter of course.
  • lantry 3mo ago
    I think "idea" is getting overloaded here. The article isn't talking about new feature/product/tool ideas, but about what concepts to use to build those features. e.g. what data structures and algorithms to use. So your last line agrees with the article, I think. They are saying that it's still important to curate ideas, and no longer important to read the code; the time you would have spent reading the code should be spent curating ideas.
    • jgeada 3mo ago
      Curating ideas requires experience and taste. Can you really develop that without looking at code? Compare Steve Jobs vs Joni Ive curating as a prime example of how taste without practical experience and context can lead things astray. And the worst of it is that it can take a while for the problem to be easily noticeable.
    • nimonian 3mo ago
      I completely agree with this you. The article is NOT about product ideas. Your parent has misunderstood the article.
  • nadzzz 3mo ago
    [dead]
  • p2detar 3mo ago
    > Sure, we're reducing the cost of idea -> prototype to near zero (well, as long as tokens are free or nearly free), but that just means we now have mountains of throw away code, within which there may a gem or two. This doesn't strike me as wrong, but where the rubber meets the road. Let me give you an example. My superior with close to zero programming skills, sat down with Claude and "wrote" a Django backend with SPA React frontend that enables user directory sync from one source to another and then exposes an API for other services to consume. It supports RBAC, 2FA, extensions for directory sources, dashboard with stats and what not. Everything packed into docker containers ready to deploy on the cloud. Again, the person is very skilled as a consultant, but lacks programming skills whatsoever. I did a code review, prepped a list of things to fix and he did fix them with Claude again. Later on, he used Claude to rewrite the Python backend to Go. I did no code review on that part. Fable was used in several iterations to test for security issues before each release. Long story short, this service is now running in the cloud and the customer uses it to solve their problem. We got a couple of other customers on the line as well. You tell me what to do with that.
• andsoitis 3mo ago
  > Matteo Collina yesterday asked me, in reply to my tweet: but didn’t you say that you check all the AI generated code for Redis? And this is a good question indeed. Yes, I do, but this is, at this point, something I need to do but that I believe to be mostly pointless, partially once GPT 5.5 was released, but now with Fable and GPT 5.6 Sol even more. Yes: I identify things that I don’t like how they are coded, but if I open other Redis files written by other Redis contributors there is far worse, and not since they are not good coders, but because it is a matter of taste. I wonder why he HAS TO ("I need to...") review the code even if he thinks it is pointless? Is that because his employer, Redis, requires it?
  • antirez 3mo ago
    Because Redis is not "my project", it is a piece of software many relies upon, so I use, for that software, what the community at large agrees to be ok: AI-assisted coding with human careful reading and evaluation of every line.
    • andsoitis 3mo ago
      One thing I've been thinking about is what a new SDLC ought to look like in the age of agentic engineering, since the "old" workflows are likely suboptimal (e.g. PR reviews). Have you given it some thought?
  • iparaskev 3mo ago
    He is the creator of redis.
  • simonw 3mo ago
    I also got a hint from this that he worries the community would reject features in Redis (and Redis itself) if they expected that the code has not been human-reviewed. I'm facing this with some of my own open source projects: I feel a responsibility to manually review the code because I don't want to damage the reputation of those projects by shopping code I haven't looked at myself, even where I'm confident that it works and is well structured already.
  • 3mo ago
• titularcomment 3mo ago
  I believe issues will arive with AI in the near future in terms of their performance. Disagreeing with the author, I think code quality pre-AI, in certain languages, were golden. They all contained bugs but they were written in a way that bug sources would be more or less obvious and most but not all top open source software had linting guidelines, code styles & friends to help make it ingestible. Perhaps these helped said project's maintainers a great lot, but it absolutely SAVED AI when it came to training data. These top-quality repositories with thousands of lines of great code combined with hundred thousand lines of mixed quality code was the perfect formula for the big data churner™. Now what? All those repos, inflated with stars are generated by one of the 5 LLMs out there. There has been extended discussions about deterministic behaviour in LLMs, and I'm no ML engineer but to me this drop in entropy will surely cause backtracking in code quality. Of course there a vast array of improvements that can be made outside of training data, but the whole psychology attached to LLM marketing, in my opinion, obstructs those improvements. You could train a better suited way of input for LLMs, set cutoffs and posttraining in just the right places and everything but you gotta think it through. How many of those who ask their favourite LLM everything think anymore? How much of our current knowledge is safe from AI hallucinations or subtle nudges? AI has changed the world of coding, but the current state in Anthropic HQ will determine if it will just be mid-quality codegen or accelerationist fever dream.
  • xpct 3mo ago
    I think it's related that we as humans see when something becomes hard to reason about, and decide to refactor it. I'm not sure whether an LLM with full ownership of a codebase could do that, for its own benefit. I do see a world where models could be trained on it, but I imagine it will be more expensive, because it requires including future rewards about the models' own later efficiency.
• efficax 3mo ago
  Code is not literature. It's not poetry. It does not express the human spirit. Code is a machine made of symbols. Engineers do care about the beauty of their machine designs, but in the end what matters is whether the machine performs its function correctly, efficiently, affordably. What's wonderful about software is that the function of software is to take input data and produce output data. Every aspect of it is measurable, if we build it to be measurable, because it's data all the way down. The future of software development is not reading code. It's specifying an outcome, success and failure conditions, and iterating until that outcome is reached. Throw out your software engineering "code quality" manuals, your SOLID and your Clean Code. It doesn't matter now.
  • krupan 3mo ago
    This argument is so old and tired. It started long before LLMs. People thought senior engineers could write a detailed spec and then the actual coding could be outsourced to just any bunch of cheap programmers. It never worked. A detailed enough English specification doesn't look very different from code written in our current high level programming languages
    • efficax 3mo ago
      You build your outcome conditions and specifications in code as well. And you iterate on them too. I'm not talking about waterfall development. It's something else. You can spend a day just prototyping, spiking, experimenting, and then use that to refine what the outcome can be, doing more work that way than you could in a week before. I think it's crazy to think that software development processes aren't going to change.
      • skydhash 3mo ago
        Reaching the correct outcome is easy. That’s what happy path means. The time sink is all the error cases, ensuring that one of the transition in the system does not result in an unsatisfactory outcome. That’s why we read code. Because only there the correct and incorrect cases are clearly separated.
• esafak 3mo ago
  I agree that not having to read the code is the future but I struggle to get there because the AI, like humans, can make mistakes (not follow instructions). For example, I might ask the AI to render a scene using a physical model, and we might come to an agreement at the plan stage, but then it will go off and cut some corner in implementation. So the question is how to reliably verify compliance. If you merely tell another AI to check it properly implemented the plan it too can miss bugs, so you need to put all your effort in making the acceptance tests foolproof, and this is easier said than done. You need a defense in depth approach, using the type system, unit tests, formal verification (if you can), linting, etc. It is an open question how to optimally allocate your correctness efforts for a given budget but, as models get smarter, it is clear to see that the amount of human diligence needed to achieve likely correctness for a given task (say, in LOC) is going to tend to zero (https://metr.org/time-horizons/ https://metr.org/time-horizons/)
• aledevv 3mo ago
  >if you control the ideas of your software, looking at the code itself is suboptimal and often pointless. This requires developers to have absolute and unconditional Trust in the LLM. It's not easy to trust it completely to the point of completely ignoring the implementation details of the code. In one of Salvatore's discussions, he mentioned that he hasn't even opened a single file of DS4. This is a courageous choice. But the real question is: if the younger generation stops writing code, how are they supposed to develop that "forma mentis" (mindset) that allows them to reason about design and architecture? It's only by *writing* the code that you gradually internalize development and design patterns, specifically by clashing with the "brutality" of bugs and solving implementation problems. P.S. I read Wohpe. It's fascinating how back in 2022 (I think?) Salvatore already wrote down many insights that have actually come true (including, for instance, the ban on "strong artificial intelligence"...). So I suppose that the future will touch the very development of humanity (like the Genesi project :) )
  • aerodexis 3mo ago
    We're all project-managers now. The trust required of the LLM is no different than that that required when a PM trusts a dev-team to implement correctly. As a PM, you need to understand testability and write that into the requirements.
  • flockonus 3mo ago
    [flagged]
• iparaskev 3mo ago
  I agree that in the end the most important thing is to have the correct mental model of the code, and there is no need to know every implementation detail if you can ensure with other means that they address your requirements. An issue I can can see with not reviewing the code (especially code someone else wrote) is how do you create the mental model? Can a design.md file replace the process of slowly understanding the data flow by reading?
• qsort 3mo ago
  I'll admit I have a bit of a skill issue here. I'm letting go of reading every single line, especially within well-scoped modules that don't affect anything else. On the other hand I struggle to form the mental model required to "control the ideas", as it were, without reading at least some critical sections of the code and without grasping how the fundamental data structures relate to each other. Are we saying that opening the editor is basically a mistake?
  • justincormack 3mo ago
    No its fine. The problem is trying to read all the code. Reading some is fine. I tend to focus on public APIs, and key areas. But not the thousands of lines which arre tests or will be refactored.
  • noopprod 3mo ago
    [dead]
• craigmart 3mo ago
  I strongly agree with antirez. I believe that an intellectually honest programmer should recognize where their knowledge and experience is mostly beneficial, and at this point (and we've seen clear signs for some time) coding is largely solved. Which doesn't mean that you can just prompt at a very high level, but that iterating with the LLM over decisions, designs and tests, will essentially allow you to not write a single line of code by hand. Software engineering is not just coding, and it involves a whole set of other tasks requiring direction and creativity that can greatly influence the quality and impact of the software. The most common arguments against this view seem to arise either from ideological resistance, which I understand given how painful it can be to see one’s job at risk or an important part of one’s identity taken away, or from generalizing a small number of experiences with LLMs to the technology as a whole. In the latter case, those experiences may also be heavily conditioned by the user’s inexperience in working with LLMs, or by the specific use case in which they were applied. There are still certain tasks that not all models can handle reliably as of now, however some can (usually the most expensive), and they will likely continue to improve over time.
  • devin 3mo ago
    "coding is largely solved" and "self-driving is largely solved" smell exactly the same to me. ETA: I bristle deeply at your idea that anyone who doesn't agree with you is letting their emotions get the better of them. Perhaps the world is not as black and white as you're painting it?
  • xpct 3mo ago
    What does it mean for coding to be solved, and software engineering to not have been solved? If it implies there's now a set protocol that can be followed to reach good results, how has that not been the case before? If it means that we can reach better results than before, then how do we know that can't be improved further? Or does that mean we should know how English language, instead of computer code, maps to computer instructions?
  • noopprod 3mo ago
    [dead]
  • 3mo ago
• brunocalza 3mo ago
  > Then I compared the implementation, for correctness, to other systems, finding that other implementations sometimes contained more errors. I researched more, and found that the local inference world is full of subtle errors that accumulate and damage the model output, issues in the attention implementation causing performance slopes after the context is over a certain limit because indexed attention implementations are broken (do more work than they should, for instance), and so forth. I agree 100% that AI helps a lot with that. But I feel like there's something missing between "AI helps a lot with that" and "I believe reading code is mostly pointless". I genuinely wonder how the above can be accomplished without reading any code.
  • dionian 3mo ago
    he said he read it though, and check the last line
  • am17an 3mo ago
    Having looked at his code, I doubt this.
    • throwdbaaway 3mo ago
      Yeah antirez made a lot of big claims in that paragraph. Sounds like a case of AI psychosis.
  • __MatrixMan__ 3mo ago
    > I genuinely wonder how the above can be accomplished without reading any code. We can't see the code for the laws of physics, and yet experiment by experiment we've come a long way. That's not usually going to be the most efficient way to understand code, but I've found that it's pretty useful to be one of the few empiricists in an organization full of rationalists (software engineers are typically rationalists in my experience). I wouldn't propose that we dispense with rationalism altogether, but it does seem that the we'll benefit by achieving a better balance than we've traditionally had.
    • 3mo ago
• qsera 3mo ago
  >What’s the point of scanning function by function, line by line? Because a critical bug could be anywhere, even in a simple function. Particularly when it is written by an LLM. Who knows when it chooses to have a bad hallucination?
• adverbly 3mo ago
  Never thought I'd find myself questioning Antirez, but I have many questions about this post and overall attitude. For example: > Yes: I identify things that I don’t like how they are coded, but if I open other Redis files written by other Redis contributors there is far worse, and not since they are not good coders, but because it is a matter of taste. Why is the attitude here about keeping the floor up rather than raising the bar? Why can't we have better code with AIs? Its not impossible to do! When I implement things by basically pairing with the AI, I end up with better designs/architectures/code than I could have written by myself. It sounds like some people think of the AI code paradigm as one where there will be fewer but better devs producing code/designs of lower quality than they could individually produce, but that is higher quality than the average dev could produce. Is that really better than a world where AI raises the average across the board at the expense of a bit of speed? At the very least, it seems like a far less risky and less disruptive way to still capture significant benefits from AI.
• devin 3mo ago
  The people who I see who are "getting along just fine" in this current mess are either True Believer™ types, or are semi or fully retired and don't need to care particularly strongly which way any of this goes from an employment perspective (meaning: I know people in this group who refuse to use LLMs and people who have attitudes like the author of this article, with similar levels of experience). I think on one level you can look at these folks and say "well, they may be able to see more clearly because they aren't so wrapped up in it all" but I've done a lot of self-reflection and I simply don't think this is true.
• hollowturtle 3mo ago
  > In 2022 I published, before ChatGPT existed, a book preannouncing many things that now happened and other things that I believe will happen, so I feel like I can say this without sounding egocentric Not egocentric but surely full of himself > This is why yesterday, on X, I said that I believe many programmers at this point have less impact they could have because they look at the code. I truly believe into that. I have great impact because I own the code and I read it when I generate it not the contrary > How are you supposed to review 5k lines of code every day? I have the feeling we will just lose the battle and start to randomly die inside crushing planes or sinking ships thanks to unreviewed code. Or lose money, or whatever you can think of many examples. > The working day is 8 hours. If you read the code, it is a tradeoff. You are doing less of what today is the most important part of your job, that is, asking yourself: what I’m doing with this software? What are the new directions I want to take? And also, think at new ideas, features, optimizations tricks. And doing a lot of QA. Guess what when we hand coded we did all these points every day, now we can't because we need to go 100x faster, understand nothing that came out from the slot machine and, cherry on top, we should focus on QA instead of pushing high quality code first. I'm really worried by the direction the industry is taking and how dangerous these "influencers" are, especially in Italy where I see he has a big follow up. We lied on a mountain of slop before LLMs sure but at least some systems were still reliable, today you can already see nothing is reliable not even the simplest service like Spotify, programmers are already not verifying the output.
• deleted 3mo ago
  [deleted]
• davidw 3mo ago
  What I'm curious about is how a young programmer in, say, Sicily or Finland or somewhere who is a student or doesn't have a lot of spare cash, is going to deal with a world where everything is predicated on access to expensive tokens controlled by megacorporations, or where even 'open source' models require fairly expensive hardware to run.
  • debugnik 3mo ago
    I think about that too. Had I grown up thinking that I need to pay a subscription to build software, I wouldn't have tried to get into engineering at all. As a teen I wanted to learn electronics and robotics, but I couldn't afford the parts to build anything so I taught myself programming and CS instead, and that's the only thing that helped me slog through academic education. I can't imagine making the same choice again today. Nowadays I worry that software engineering is about to become short-lived right after I've entered the workforce, in which case I'll regret the time I spent to get to this point based on a false hope.
• deleted 3mo ago
  [deleted]
• gabrieledarrigo 3mo ago
  I highly respect Antirez, and as an Italian fellow programmer, for me, he's like a legend! Although reading this article makes me quite sad; I consider myself an average, mediocre programmer, but I enjoy writing code since it's a way to build the mental model of a problem and to solve it iteratively. I obviously use agents and all the new fancy tools, but if a great programmer like Antirez says that it's over, I think I'm not so faithful about my future as an engineer.
  • Zsfe510asG 3mo ago
    All AI stocks are plummeting right now. Go your own way and don't listen to tech predictions, no matter how much you revere a person. Often they are all wrong.
  • hollowturtle 3mo ago
    From another Italian fellow: stop following people and do your own thing, it will be worth it no matter what influencers says
  • deleted 3mo ago
    [deleted]
• softwaredoug 3mo ago
  This article feels too black and white > How are you supposed to review 5k lines of code every day? Maybe there’s grey areas of reviewing 10% of the code, ensuring tests actual are meaningful, the big ideas are correct etc. I personally find that more efficient to do by looking at some code than a proxied description of the code. > “how is exactly the design of that part? How does it work?” Isn’t code and syntax often, but not always, a more precise way to see that? Won’t it depend on what you mean by “how does it work”? I’d prefer pseudo code in some cases and actual code in other cases. There are times line by line details matter. There are times when bigger ideas matter. It’s all like saying you run a car factory and should only ever give out the big ideas, never take a wrench to a car and figure out of if the factory builds cars to your expectations.
• chr15m 3mo ago
  Actions speak louder than words. > "didn’t you say that you check all the AI generated code for Redis?"... Yes, I do For important code (Redis) he is still reading the diffs. > but: try it yourself, you will discover you can’t just say “implement XYZ” and see it working. Yes, good software still requires engineering today.
• mpweiher 3mo ago
  For "code", substitute "object code". For "ideas", substitute "code in a higher level language". At least if we actually want to control the ideas. Right now, with those ideas expressed only in English, our control is limited. What LLM coding does is generate lots of code from a fairly small English (natural language) prompt. If you look closely, I think you'll see that this is two processes: 1. Translate from fuzzy English to precise machine-executable language 2. Translate from high-level description to lots of low-level code. Although these two are still pretty great when they are mashed-together, I think they'd be even better, lots better, if we could separate them. But today we cannot.
• TZubiri 3mo ago
  Author is redis dev. Seems deep in vibecode mode Genuine question, is redis actually used by competent engineers? The idea of a separate networked process to store and retrieve variables from memory sounds like something a first year engineer would do when they learn about a hot tech netflix uses before they learn about fundamentals like what a heap and a stack are.
• fnoef 3mo ago
  Very egocentric piece. Almost reads as “I’m so cool, I did so many cool things, and most things other people did is way worse than even the slop that my LLM prompting skills are capable to produce”. Also “ You have to understand how things work, what is the best design, how to reach a certain level of performance.” - how does OP propose to understand how things work or what is the best design if you don’t actually go and build things or read the code? I hope the answer is not “reading mythical man month” or “watching YouTube video tutorials”.
  • nimonian 3mo ago
    This is pretty unfair. If the author didn't establish some context there would be someone else here saying "Check out this dilettante telling me what to think." I have a degree in mathematics followed by twenty years in software development (pillory me, if you like). My conclusions after 6 months of using LLMs every day are remarkably similar to the author's. I increasingly think in shapes, architectures, data structures and ideas; less and less in lines of code. And I fully understand his point that, once the architecture of an idea is settled, reading LLM code does not feel worse than reading human generated code. Especially if you have a strong style and conventions guide. The idea is the hard part, and it's the right place to focus your effort.
    • fnoef 3mo ago
      I bet you had to solve math equations and prove math stuff to get your degree, am I right? Now imagine I tell you that you could have just prompted LLMs with “please solve the is and make no mistakes”, would you think you’d be able to get your math degree? The point I’m trying to make is that it’s very easy to tell everyone “don’t read the code, just focus on architecture” when you have decades of experience behind your shoulders, where you HAD to read the code, iterate, learn from your mistakes, read code written by others, and actually writing and making stuff yourself to gain that experience and understand architecture. How do you expect people to learn all this stuff that you know if don’t want them to actually do the work but instead “control the idea”, whatever this means? It’s just baffles me that people don’t see this.
• Zsfe510asG 3mo ago
  I think this blog post could use a disclaimer that Redis has AI offerings and would like to expand in the vector database market. The fact that the author addresses the young makes me feel uncomfortable. Gen-Z knows that currently almost all blog posts have an ulterior motive and are worded in a way that claims to be in their best interests. Do not listen to well-known programmers who use their non-AI earned fame to steer you into the unknown future. The AI stock market is already collapsing as we speak and these recommendations aren't worth much.
  • hollowturtle 3mo ago
    Totally agree. But I have the feeling damage has already been done, like full oop back then. To be precise I don't think oop was a total mistake, rather being maximalists about it was a mistake like with AI. I am so pessimist that I believe sooner or later we will testify the first death because of ai unreviewed code. I hope I'll be wrong
  • lioeters 3mo ago
    You're right. It's disappointing to see an established name, which I used to respect as a voice of an experienced programmer, pivoted to a different field and purpose. There's no substance or personality there anymore, only a kind of indirect marketing for how to drive an overhyped code-generation service provided by a corporation. From out of the ruins other voices of reason, talent and expertise will surely emerge, but it will be difficult to find and listen amidst the public pollution and industrial megaphone drowning them out. The mainstream culture has been enshittified, and healthy creative subcultures have yet to grow into their stride.
• waynecochran 3mo ago
  ... I believe many programmers at this point have less impact they could have because they look at the code. I think my strength is now more in my ability as a mathematician and a writer than as a programmer. Being able to write detailed specs and doing QA by testing is far more productive than looking at code.
  • hollowturtle 3mo ago
    Right don't do that then when you have a floating point problem or an integer overflow let's see if your ability as a mathematician helps or if you need to know the machine and the code
    • waynecochran 3mo ago
      That is the part Claude can handle and actually does. In fact, recently claude automaticaly converted some spline generating code to double precision and did some other refactoring as well after it realized poor results thru tests it generated on its own! I was gobsmacked!
      • hollowturtle 3mo ago
        Unimpressive slot machine, it will betray you sooner than later and pay a real price
        • waynecochran 3mo ago
          I am shipping sophisticated computer vision code that is more reliable and better tested than ever before. This isn't some vibe coded bullsh*t. This is me writing detailed mathematical specs and it do all the heavy lifting.
• m3kw9 3mo ago
  This will be true because LLMs will increasingly generate better code faster and will outpace your patience to read the code while being entice to move forward faster because of partial trust. Like an engineer that you direct to do things, you as a technical manager can only review so much. It will drift till we are just asking it to review and give you a overview for you to review.
  • krupan 3mo ago
    Everyone's a prophet now
    • m3kw9 3mo ago
      i use it daily and it's what is trending towards
• erelong 3mo ago
  > looking at the code itself is suboptimal and often pointless yeah I was having a convo with AI about this recently I was like, I recognize AI tools are useful, but I don't end up using them as much as I'd like to and the conversation kind of went towards acknowledging how dramatic the shift has been from using search engines to get ideas about how to manually code, to just sharing ideas for other people to maybe implement in their own way using AI So, there were all kinds of buzz phrases that popped up like about "prompts as source code" and "spec driven development" and "context engineering" which just kind of confirmed for me that I think some of my "slowdown" with coding with AI has been due to a shift from this manual coding with search engine assistance to sharing ideas and letting AI do the actual coding Manual review akin to skimming while reading and then reading in depth specific passages that need "deeper focus" is probably something to consider keeping doing
• amatheus 3mo ago
  Do I have to look at the text of the article (words, letters, punctuation) to get to the ideas in it? Do ideas exist outside of the code where they are embedded? If the ideas live outside the code how confident can I be confident the code as written embodies the ideas? These are the things I keep thinking about.
• yomismoaqui 3mo ago
  Problem is that in our job we are conflating several things that are different: - Coding: Writing instructions in a programming language. Example: writing a function that calculates the total price of an order. - Programming: Designing a solution, writing the code, testing it, and fixing problems. Example: building a small application that manages orders and payments. - Software engineering: Creating and maintaining reliable software systems using structured processes, architecture, testing, documentation, and teamwork. Example: designing an online store that can support millions of users and be maintained for many years. It seems like in the future coding will all be done by machines and we can use our brain for the other 2 things.
• hegstal 3mo ago
  Humans are fallible, so we review the code. They "hallucinate" and produce mistakes and go in the wrong direction. We evolved an entire discipline around processes, tools, reviews etc. to help remedy (not solve!) this. For some reason, the moment those humans are being replaced by fallible, stochastic machines, we decide to just throw the baby out with the bathwater entirely and no longer leverage critical parts of this pipeline? Because it's inefficient and we're bottlenecking the process? The magic of LLMs has quite literally bought us more cycles to do this stuff, not less! I use the things every day to an extreme degree and still I don't think I will ever quite understand the leaps in logic required to arrive at this position.
• deleted 3mo ago
  [deleted]
• rendonroman 3mo ago
  [dead]
• klustregrif 3mo ago
  [dead]
• IAmGraydon 3mo ago
  I think this is a possible future, but we are nowhere close with the current tech. It makes too many mistakes currently. I could envision a future where the hallucination and error rate is brought down to a very small number, but trusting your codebase completely to an LLM at this point has a 100% chance of eventually becoming a problem.
• cadamsdotcom 3mo ago
  Strong agree, but in a subtly different way.. I still read the code; but I work to make a trustworthy agent, so I can skim read at review. For a year+ I've been gaining leverage by codifying guardrails. Insanely intricate (and fun to create) lint scripts that catch things like python imports inside functions instead of the top of the file, or dumb use of dict return where the return should be a pydantic model, or the agent dumbly using the ugly default Tailwind color classes instead of my design system colors. It's fun codifying "how we work around here" and it's been great for keeping dumb AI mistakes off my radar. Last week I busted out my text editor and typed (typed!) a section into CLAUDE.md on my philosophy - my why. "We do test driven development because we have a computer that can instantly validate your code." "We don't modify code until we have created and witnessed some other thing that durably proves the need for our change." Etc. etc. Well the agent leveled up suddenly and dramatically. It was a real mind opener. One of those banger realizations. I'd been leaving tons of power on the table. When backfilling tests, it suddenly started mutating production code and rerunning to witness tests go red - something it calls "teeth". It doesn't just assume tests work and move on! I didn't ask for that, it was latent in the model. I no longer have to remind it to run new eslint rules first to prove they're correct. Sometimes it even proposes new lint rules and checks to tighten its guardrails. What I learned that maps to what @antirez is saying: With everything about agents, stop operating at a level of "what". The what is the agent's job. Stop operating at a level of "how" too! Just focus on not hoarding your "why". Tell your agent where your ideas come from, why they matter. Do not just think the why in your head. Write it down! Put it in CLAUDE.md. Offload it into the system! Your tools will level up. Even if it's not about the harness. Building product features? Tell it what you think the users will do. And why. It might codify the UX closer to how you'd have. Tell it what other UIs you've seen and like - it probably knows about them and can just code that - less detail needed. And it'll bring the code closer to what you'd have written. And bring you closer to that holy grail, LGTM skim-review.
• mrsalty 3mo ago
  Antirez's take is bold, and probably very scary for most programmers (and especially for their managers), but I think he's mostly right. I'd even go further: people who don't adapt to this change will be soon left behind, because today things are moving blazingly fast. This doesn't mean AI-generated code is safe. The key point here (which AR explains well in his latest YT video on his way to the gym :D) is that you still need to master the CS fundamentals. Which means: - People who master the fundamentals will use AI to move much faster. - People who don't master the fundamentasl and vibe code will evetually hit a wall, but most importantly - People who master the fundamentals but review all the code will move much slower. Innit?
  • AnimalMuppet 3mo ago
    Maybe. Depends on how solid the code is in the directions that matter for that code. Does security matter? Real-time performance? Never losing a transaction? Never leaking memory? What matters for the code you're trying to write? Future maintainability? How good is AI at producing code that does not fail in the directions that matter? People who master the fundamentals but review all the code will move much slower. But they'll be more successful in the medium to long run if they're catching things that matter. (If they aren't, of course, they're just wasting time.)
    • mrsalty 3mo ago
      >Does security matter? Real-time performance? Never losing a transaction? Never leaking memory? What matters for the code you're trying to write? Future maintainability? The assumption I believe is: if you are experienced enough you will instruct your agent(s) to address all of these during your iterations.
      • AnimalMuppet 3mo ago
        [dead]