4 ms·

Coding is not solved, correctness is not a feature, it is the bare minimum. If your code does not do what it is supposed to do, you could as well have no code a

• zsoltkacsandi 22d ago
  That is very well put and summarizes what distinguishes real software development from vibe coding.
  • Dlemlo 22d ago
    I have seen so much production code with garbage code and massive bugs, the industry doesn't care for 'real'.
    • danbruc 22d ago
      They care in principle, for the most part bad code makes changes and extensions slow to implement and causes unnecessary production issues which costs time and money. But there is always the tension between implementing something quickly now and being able to implement things quickly in the future and unfortunately the preference is almost always quickly now despite everyone knowing that this is the way more expensive choice in the long run.
      • Dlemlo 22d ago
        Not even in principle. Like how often you had to fight a product manager to do this or that. "Does that code work?" "yes" "so lets ship it" "but its not good" "but it works right?"
        • danbruc 22d ago
          But they also ask why the next feature is taking so long, because of the mess we created with the last feature, and I would consider this caring in principle. Unfortunately this almost always filed as unavoidable.
      • hax0ron3 22d ago
        It isn't necessarily the more expensive choice in the long run. Let's say that companies A and B are direct competitors who start from the same point. Company A quickly codes a bunch of buggy software and ships it in a month. Company B takes its time and ships good, clean, well-organized, mostly bug-free code in five months. Company A makes money. Company B goes out of business and its code is useless, its nice qualities irrelevant. This is just a hypothetical example, I'm not saying that this is how it would necessarily go in all cases.
  • ahalay-mahalay 22d ago
    I’m pretty sure that same discourse was seen every mass production epoch, from textiles to electronics. Yet here we are, hand-crafted high quality things are rare and expensive.
    • Terr_ 22d ago
      > mass production epoch, from textiles to electronics I see this comparison a lot, and I think it's a trap, because it invites us to confuse scaling duplicates with scaling design changes. Duplicative mass-production was always core to software from the moment it first became "soft". A factory churning out 10,000 copies of the same book maps to 10,000 downloads of a single software release. The paper and bindings of the book may be below hand-crafted standards, but the words are largely unaffected. In contrast, LLM-coding is the design and prototyping stage. So if we want to learn from textiles/electronics, we shouldn't be thinking of acres of looms, but instead about fashion-design, custom tailoring, determining patterns for clothes, designing new appliances, choosing circuit layouts, etc.
• echelon 22d ago
  And all of these things will be solved one by one. It's astounding to me that people can see coding get solved and not think every single one of these tasks won't be solved too. Why do you not think these things aren't going to be completely automated? What makes these tasks special? Fable and Astra can one-shot video games with compelling novel game loops. They can do systems programming, distributed systems, robotics. I haven't found a weak point. Seedance 2.5 can make video better than the manual labor of VFX artists, 3D artists, and animators. Nano Banana and GPT Image can do a better job than graphics designers. LLMs just solved a Millennium Prize Problem, and there are probably more that will fall in the coming weeks. Just wait. All of these things will be solved. There is no "stopping point". Edit: Don't anticipate that 2036 will look anything like 2026. Will Smith spaghetti doesn't stay that way forever. Trillions of dollars will be spent on solving these problems. They will be solved.
  • dwroberts 22d ago
    I think the usage of solved is silly. Things get automated, they basically never get ‘solved’. Will all these things get automation? Yeah sure. But the idea that they will be perfect automated solutions applicable in all cases is just marketing, it’s not reality.
  • BowBun 22d ago
    > compelling novel game loops Tell that to the mountain of failed AI slop games on Steam! As a game dev, building compelling, fun games is not even something humans are good at doing consistently. The AI can build the tech, but it can't make something 'fun' yet (unless your bar for fun is simply that a tool created a thing).
  • danbruc 22d ago
    I have no doubt that AI will eventually be able to write essentially perfect code, I am just saying that we are still quite far away from that point.
  • sigbottle 22d ago
    May the iterative loop of adding new axes to evaluate on be a natural, healthy progression, instead of needing to frame it as an us-them problem? If you value humans intrinsically, this is necessarily the loop that will converge. I don't think humans have deep intensional a priori knowledge of the structure of reality. If we did, then we wouldn't need tools like AI because we'd be a superset of that. We can only observe and judge. If we don't value humans, then sure, I think AI is at the point where it can kill all humans (conditional on sentience and resources etc). Two ways to solve a problem - solve the problem, or eliminate the problem statement. Plenty of easier vectors to eliminate the "problem statement", than say, try to solve problems such as making human life better. If you do value the latter though, there will necessarily be human judgers. That's how it works.
• _s_a_m_ 22d ago
  Amen. I sometimes wonder if all programmers are now marketing people who know shit about software development and engineering.
• perchard 22d ago
  second sentence of the article: "Just because the code is formally correct doesn’t mean that it is not introducing unnecessary abstractions, creating duplicates, or just making bad decisions overall. This is not a groundbreaking observation, most people who have vibe-coded a project, have realized that each additional feature can sometimes lead to an explosion of lines of code (LOC)."
• gedy 22d ago
  "Coding" is just a poor term for this, as there's so much room to weasel different meanings out of it. At every company I've worked in past 20+ years the "coders" were engineering a product from wrong or unclear requirements and specs from non-technical people. The act of coding was secondary (but an important throttling function to make us stop and think about what is even possible or makes sense.) Never did FAANGs, so YMMV. Really doubt we are near that being solved with non-technical folks + LLMs. I'm seeing people gleefully rebuilding products with the exact same blind spots in their understanding/logic using LLMs. Claude, etc are not seemingly able to "AGI" around goofy asks. The CSS looks a little nicer than their legacy products though, lol.
• chucksmash 22d ago
  Correctness is not a binary thing though. I doubt many people here are brave enough to claim their code does what is supposed to do in every conceivable case. Maybe you have high confidence in the correctness of parts of the code. Correctness of an application is murky though. Things we build are never fully correct, merely correct enough. Like maybe you're responsible for the UI in a web app and you're using your expertise to ensure it gracefully handles display across browsers and a gamut of screen sizes/form factors. But are you also verifying how it works when localized with an RtL script? Are you checking every change you make against CJK?
  • danbruc 22d ago
    Sure, every sufficiently large codebase will have bugs somewhere, but it will work correctly at least something like 99.999 % of the time after ironing out the bugs on the common code paths. But that does not change the fact that being [mostly] correct is the lowest bar you have to cross.
• binary0010 22d ago
  I just setup a large refactor with Astra and was feeling super lazy and let it mostly do it without my usual extreme micro managing. The refactor ended up adding 22,000 loc. I went in there and quickly read through it, laughed my ass off. Reverted the work tree. Micromanaged a new refactor. Net lines of code for something really elegant and easy to reason about was -3k loc in the project. In case you are wondering why vibe coders are doing 30k loc a day, this is why.
• Supermancho 22d ago
  > Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability My experience is a little different. For higher abstraction languages the output is largely acceptable in my work. I always consider that LLMs don't know what I don't tell them and they have limited context to work from. Coding issues I often identify: * Efficiency. Marginal by default. Coding efficiency problems often appear because LLMs dont usually consider the entire codebase or future plans (although they do guess at some futures). Sometimes they write/name things in ways that are lazy/wasted cycles. Most of the time, they don't. * Security. Marginal by default. I say they do pretty good. Considering all the failure modes, not so much. * Maintainability. Marginal by default. Mostly due to the careful consideration of modularity, upgrade paths, etc. while often taking wildly different approaches to solutions without having specific broad instructions. Even then, there can be big gaps in quality. * Observability. Not acceptable by default. There's usually some consideration and can often one-shot. * Portability. Not acceptable by default. Good, if you specify what those targets are. Regardless, testing validates this above the coding and models are very good at hitting functional test targets. This is less of an issue in something like Java ofc.
  • bla3 22d ago
    This sounds roughly right to me, except for "maintainability". In my experience, agents really don't like deleting code unless you explicitly ask for it. If you're not careful, you end up with new better implementations of things but with the old implementation still around in perpetuity. Humans do this too of course.
    • ACCount37 22d ago
      Humans had to get it drilled into them that "+12 -440" is a damn good line stat, and that keeping around dead code is bad, especially in the age of version control. Not too surprised that LLMs also don't "get it" by default?
    • Supermancho 22d ago
      The shadow of Chesterton's Fence is relevant. The LLM doesn't know why code exists, if it doesnt start traversing up the scope of a project. Even then, it can't be sure that the code isn't a dependency of something else outside the project (especially if there's a side effect). I'm not sure it's ever going to be easy to address this concern in a straightforward and portable way. I do sometimes see duplicate functions, which is troubling.
• danielvaughn 22d ago
  Yes. I use these models day in and day out, on all sorts of tasks. I cannot believe I hear people say that coding is solved.
  • dnikolovv 22d ago
    Right. It feels like we're living in a parallel world or something. Can agents code? Sure. Can you let them code on their own for a serious production project? Not a chance.
    • heaney-555 22d ago
      Plenty of serious production projects are doing exactly that. Are you using GPT-6 Astra, or something older?
      • margalabargala 22d ago
        You and the person you are replying to are talking about different things. Agents cannot be given a high level goal and then left unsupervised, for hours, without making some dumb decisions.
        • danielvaughn 22d ago
          Right. The only way I'd feel comfortable doing that is if I spent an inordinate amount of time writing very detailed specs, so in terms of labor offset I'm not sure the juice would even be worth the squeeze there. In other words, a sufficiently detailed spec is nearly indistinguishable from code. What people seem to be wanting is for an agent to infer vast complex data from terse simple data, which I think is probably impossible on a philosophical level. There's real information loss in language, and compute can only make guesses at the end of the day. I really don't see how we bridge that gap.
        • dnikolovv 22d ago
          That's exactly what I meant.
• mr_roboto 22d ago
  You come across as someone who has never worked on a real software project. Humans create tons of bugs on a regular basis. AI is already better than most programmers.
  • OtomotO 22d ago
    AI is the average of all programmers. It's just that many (I guess that includes me? :D) assumed that they are better than the actually were.
    • ipsod 22d ago
      A team of programmers is "worse" than their best member. Worse quality of code, worse thinking. You can usually get more done with a lot of mediocre hours of work than a few brilliant hours, though. AI I've used isn't a better coder than I am - it's just got a lot more hours in an hour than I do.
  • whatever1 22d ago
    Better at writing one piece of code, maybe. Better at writing code within a huge system, definitely not. Maybe in the future, but as of Astra, Fable 5.1, the answer is still no.
    • user43928 22d ago
      Disagree. I have 200k LOC now plus 100k in tests, and it is still performing like it was four months ago when I started to seriously use AI. If anything, it works more reliably today with the smarter models.
    • econ 22d ago
      I'm definitely not experienced enough to know but I read people are having it write somewhat elaborate documentation beforehand. Have it figure out which parts of the code may be touched, what other things will be affected and which uncertainties it has. Basically a full report before giving permission for any code to be written/modified. Again, I haven't seen it, don't know how common this is nor how effective. Though it sounded interesting.
• deleted 22d ago
  [deleted]
• einrealist 22d ago
  And there is another problem: LLMs generating too much code, code that is doing more than was asked. And that cannot be fixed by tests. Usually, we create tests for wanted behavior and expected exceptions. But we don't create tests for undesired behavior.
  • user43928 22d ago
    Have you worked with Opus 5? Its documentation about what the code does not do could fill whole books. UI copy being full of slop explaining what the software does not do is another problem. I am not convinced that a lack of negative test cases is an issue. I do agree it generates too much code most of the time.
    • lukeschlather 22d ago
      Documentation is important. I would say Opus' propensity to write documentation that documents non-features is part of the problem being discussed. And the problem isn't just that it says what the software doesn't do, most of the things it claims are in fact meaningless, it's not even clearly describing something the software shouldn't do.
  • flyinglizard 22d ago
    Code cost is almost down to zero. If you move the point of “just leave it to the machine” from the compiler (where humans used to do the coding) to the high level logic (now with LLMs) then in most cases more code does not really matter. Like, why build and maintain an abstraction where the LLM could implement this many times over each time with different subtleties? Why use a library with its own constraints when you could have exactly what you want? Why use cross platform frameworks when you can just one shot the thing to N different platforms? It’s not even slower. You can have code that’s larger yet more performant (stripping away abstractions can do that). From time to time I try to do a pass of coalescing flows and cases and removing dead code to reduce the context and prevent the LLM from tripping over itself. But if it’s exclusively LLM maintained code I don’t care too much if there’s more of it.
    • 22d ago
• gchamonlive 22d ago
  It's not solved, I agree. But if we pretend it is we can prepare for when it actually becomes solved, if ever, and measuring sloppiness is a worthy pursuit even if we never "solve code".
• glenstein 22d ago
  I think this is a two things can be true situation, where our colloquial meaning of coding is not quite adequate to indicate the full range of criteria that really matter, but also, that criteria as a totality (maintainability, reliability etc) is something that can also be targeted and optimized for. This reminds me a bit of a PhD Comics webcomic that confidently claimed we would "never" cure cancer, on the grounds that cancer is not one thing. And I don't know that we will ever actually cure cancer, but that wouldn't be the reason. Correctly noting the problem space is bigger than a layperson would initially appreciate is a lot of things, most of them helpful, but the one thing it's not is a formal a demonstration of optimizing against the problem space as a whole.
• bigstrat2003 22d ago
  Yeah, the author leads with a blatantly false claim that models are almost perfect at generating code. They are not. They write pretty bad code, worse than any capable human would.
• anon-3988 22d ago
  Look, we are comparing against the average developer here And yes, they are obsolete
• ryandrake 22d ago
  This has been a problem in the software industry for a loooong time, though. Too many developers see "It works" as the end state, a signal that you're done. "It works" is just step 1.
• deleted 22d ago
  [deleted]