DothYsTainGk

• DothYsTainGk 29 Aug 2026 11:56 UTC

  3 points

  0

  in reply to: jefftk’s comment on: AI Tweets

  I suppose you are right. Fiction rarely labels whether a given AI system is meant to be general or not.

  There’s definitely AI stronger then LLMs in fiction and AI weaker than LLMs in fiction and I cannot show that when people think of AGI they think of the examples stronger than LLMs.

  So let me make another argument:

  • Even careful and thoughtful people are generally bad at predicting what other people believe outside of trivial examples. See for example thoughtful Democrats being often unable to articulate accurately what thoughtful Republicans believe and vice versa.

  • Whether or not other people believe LLMs are AGI is not a trivial example

  • We’re generally worse at predicting what people 20 years in the past have thought about some issue unless we have specific evidence (e.g. a written record) than we are at predicting what our contemporaries believe

  • We have no specific evidence (e.g. a written record) about what people in 2006 thought AGI would look like exactly and if it matches LLMs

  • So we cannot accurately predict whether or not people in 2006 would’ve generally considered LLMs to be AGI

  • And it’s especially not “clearly” or “obivously” the case they would’ve seen 2026 LLMs as AGI

• DothYsTainGk 29 Aug 2026 8:36 UTC

  2 points

  −1

  on: AI Tweets

  I don’t know if the metaphor is “goalpost moving” or “frog boiling” but if you dropped a top model into 2006 it would very clearly be “AGI”.

  I don’t know how we could check who’s right but I don’t believe this is true at all, much less clearly true.

  All depiction of AGI in fiction I know of is stronger than today’s LLMs are and I think that is the central example people would compare LLMs to. I can provide some examples.

  My favorite example is the sci-fi roleplaying system Eclipse Phase from 2009, as it has both AGI and non-general AI called Muses, with Muses very similar to today’s LLMs. The people writing the rules tought clearly Muses are not AGI and Muses are stronger than todays LLMs, though not by much.

  And just generally, if you showed todays LLMs to people in 2006 and asked it “do you think this machine can do all/​most intellectual tasks about as good or better than humans” people would, for the most part, probably disagree.

  There’s still many intellectual tasks LLMs do not perform well at and people in 2006 were smart enough to notice. Also probably motived to find those so they can dismiss LLMs being AGI, which is something I think people don’t actually want to believe.

• DothYsTainGk 3 Aug 2026 20:18 UTC

  1 point

  0

  in reply to: Jonathan Moregård’s comment on: The Art of Ship­ping Slopware

  Thanks for clarifying. I think “we could try what OP proposes, if it sucks it’s probably not that expensive to LLM-rewrite in cleaner” is a reasonable argument.

  Personally I’m just less certain than you are I feel. If I had to bet on it I would assume that the things you listed are objectively useful, not just for humans. But I’m not actually any sort of sure of it, and if a bunch good new studies came out tomorrow showing that LLMs do extremely good without linters or immutability or something I would not be surprised either.

  Same with clean, good, cheap LLM-rewrites. Sounds reasonable enough but we haven’t seen much of it yet and I’d not be surprised if there were cases in which it absolutely failed.

  So personally I’d rather give the whole thing a bit of time for data to come in to validate whether our intuitions are actually correct, or just reasonable but ultimately false guesses.

  Guess at the pace this thing is moving I’m SOL however.

• DothYsTainGk 3 Aug 2026 16:30 UTC

  1 point

  0

  in reply to: Jonathan Moregård’s comment on: The Art of Ship­ping Slopware

  The points your making do not seem to adress the discussion I believe we’re having, so it seems likely we’re talking past each other.

  I’ll try to give a brief summary of what I believe the point of dicussion is and why I believe your points do not address it. I may be wrong in this, if so hopefully you can use this to tell me why your points are relevant.

  To oversimplify a bit for brevity, I believe the chain of argument goes approx as follows

  • OP: Having LLMs write human-maintainable code, what we’d call “good and readable code”, is a bad goal and we should not bother with it

  • Me: If you do that it’ll look fast at first but maybe you’ll end up with something that is also LLM-unmaintainable. That would be bad, how sure are we this does not happen?

  • You: Bad LLM-code can be rewritten as better LLM-code, but this does not matter, because it is possible to have LLMs write human-maintainable “good and readable code”, better than humans probably

  • Me: Having to LLM rewrite your LLM-written codebase may well result in code just as unmaintainable, just with one more feature. Also: I know LLMs need not produce slop, but OP suggests we intentionally have the LLMs produce slop

  • You: Slop can be reimplemented as non-slop, and LLMs are better at it than humans

  To which I answer: I believe we’re discussing what happens if we followed OP’s suggestion, which rules out having LLMs write good-for-humans code, as that would not follow OP’s suggestion. So how good LLMs are at writing good-for-humans code is irrelevant, OP specified we should produce slop and that is the world we’re considering.

  Or is your argument that if we try out the “embrace the slop” thing and it ends up not working we can move back to “reject the slop” fast and easy using LLMs?

  If so it was not clear to me that your suggestions are for after we tried OPs approach, found it failed and have given up on it. After giving up on OPs suggestion it is clear to me that the approach you propose could be attempted. It is just incompatible with following OPs approach at the same time

• DothYsTainGk 3 Aug 2026 7:16 UTC

  4 points

  1

  in reply to: Jonathan Moregård’s comment on: The Art of Ship­ping Slopware

  If I understand correctly, you propose that if the LLM ends up creating slop that works but is unmaintainable, then we could use that codebase as the starting point for reimplementation?

  That seems plausible, but the question is, should we assume that reimplementation will be more maintainable? After all, the first codebase was presumably generated in a similar fashion and did end up unmaintainable.

  I’m not confident this is true, but I can imagine a world in which reimplementing codebases larger than, say, 300k LOC by LLM results in unmaintainable slop, no matter how often you do and redo it.

  You say that we should scaffold the LLM so it writes good code, and personally I agree. But wasn’t OPs suggestion exactly that we should not care about making the LLM write code humans perceive as good? I understand that to mean we’re supposed to pass on the suggestions you mention and embrace some new way of LLM-first convention yet-to-be-established.

  And that is what I’m worried about: Intentionally saying “No” to writing code humans can read and understand.

  As for the fact that there are bad human programmers: This is certainly true, but kind of besides the point of discussion I feel.

• DothYsTainGk 2 Aug 2026 18:08 UTC

  7 points

  1

  on: The Art of Ship­ping Slopware

  I’ve been wondering about that.

  Basically it’s been possible for a long time now, to not care about maintainability of your codebase and the result would be faster progress in implementing features.

  This is deemed, in my view, the correct approach for some parts of the job: building a POC and writing a one-off script are two examples of tasks for which caring about maintainability is wrong most of the time, as maintainability costs significant time and effort.

  There have also always been people that believed that caring about and investing in maintainability was wrong for large, long-lived projects intended to run in production. I believe the consensus view is now mostly, that these people were in the wrong. But it took a long time to form that consensus. I’m sure cowboys who push the first thing that works to straight to production still exist, but at least in my circles people generally believe that investing in maintainability of software is generally worth it for long-lived projects.

  Now I believe you’re correct to point out that maintainability for humans and maintainability for LLMs may not be the same thing. I would assume, that a codebase that is maintainable for humans is generally also maintainable for LLMs, though perhaps not optizmized for LLM usage. I’m not sure the reverse is true and suspect it is not.

  In any case, I do not know if we have the data yet, on whether or not it’s worth discarding old practices. To get back to the cowboy programmer that just writes code and pushes it straight to prod, that looks fast at first and eventually you reckon you have a big ball of mud you can never change again without breaking something somewhere. Do we know this does not happen with LLMs, too?

  Because once you commit to the bit and say “human maintainability is no longer my concern”, then you will get code that is not maintainable by humans. If it then turns out that it is not maintainable by LLM either, then you have code noone can maintain. Whereas, if you have the LLM write code that a human could maintain as well, then you’re guarded against this particular kind of failure mode. But of course that’s slower and more expensive in the short term.

  So I guess my question is: How sure are we that we’re not setting ourselves up for failure a year or more down the line? Because if what you propose is a mistake we will probably only notice it in the long term.

• DothYsTainGk 9 Jul 2026 20:50 UTC

  2 points

  0

  in reply to: Elias Schmied’s comment on: Refram­ing LessWrong-style de­ci­sion the­ory as “com­mit­ment the­ory”

  I though the answer was “assume you’re simulated and follow FDT to save real-you the trouble of ever getting into this situation in real life”. Out of the all arguments to take the bomb this is the only one I’ve ever heard which I can at least understand where it’s coming from.

  If that is not the FDT response then, I guess I don’t know why you’d ever really blow yourself up. I did read the whole post, including rereading the example against just now.

  But what I got from it was mostly the insight that FDT kind of answers a different question than CDT, in that it’s goal is to shape what situations you end up in, not necessarily how to get the best result out of a given situation.

• DothYsTainGk 9 Jul 2026 6:46 UTC

  3 points

  0

  in reply to: alexfeghhi’s comment on: Refram­ing LessWrong-style de­ci­sion the­ory as “com­mit­ment the­ory”

  I believe they way it works is that FDT tells you to make the bad decision (here: suicide) if faced with the actual situation, but the argument is that you won’t get into the situation at all or less often because you’re playing FDT.

  By the time you find yourself facing the problem in which FDT recommends killing yourself something’s already gone wrong, because the situation ought to be prevented by playing FDT in the first place.

  But of course the question always is: should you actually find yourself in the decision problem, despite being an FDT-agent that ought to never get here, should you still follow FDT?

  I’d argue the answer is “lol no” but I believe the argument in favor is to assume you’re just “hypothetical you”, evaluating the situation without having to bear the cost. E.g. you’re just a simulated version omega spon up to check how you’d react in this decision, not “actual you” who’s faced with the decision. After all “actual you” is not supposed to even get into the situation. If you truly believe that, then chances are you’re not you, because that’d mean omega is wrong, which is extremely unlikely.

• DothYsTainGk 9 Nov 2025 15:34 UTC

  1 point

  0

  in reply to: julius vidal’s comment on: Pythia

  As an agent when you think about the aspects of the future that you yourself may be able to influence, your predictions have to factor in what actions you will take. But your choices about what actions to take will in turn be influenced by these predictions.

  To achieve an equilibrium you are restricted to predicting a future such that your predicting it will not cause you to also predict yourself taking actions that will prevent it (otherwise you would have to change predictions).

  Do you have an example for that? It seems to me you’re describing circular process, in which you’d naturally look for stable equilibria. Basically prediction will influence action, action will influence prediction, something like that. But I don’t quite get it how the circle works.

  Say I’m the agent faced with a decision. I have some options, I think through the possible consequences of each, and I choose the option that leads to the best outcome according to some metric. I feel it would be fair to say that the predictions I’m making about the future determine which choice I’ll make.

  What I don’t see is how the choice I end up making influences my prediction about the future. From my perspective the first step is predicting all possible futures and the second step execution the action that leads to the best future. Whatever option I end up selecting, it was already reasoned through beforehand, as were all the other options I ended up not selecting. Where’s the feedback loop?

• DothYsTainGk 11 Jul 2025 21:30 UTC

  1 point

  0

  in reply to: Gordon Seidoh Worley’s comment on: Mea­sur­ing the Im­pact of Early-2025 AI on Ex­pe­rienced Open-Source Devel­oper Productivity

  (I’ll admit, there’s another reason for programmers to want to use AI even if it did make them worse at their jobs: it outsources some of the most unpleasant programming labor, so even if it’s slower, it’s worth it in the eyes of a programmer because their experience of programming feels better when they use AI because they didn’t spend a lot of time doing tasks they didn’t enjoy doing, like typing out the code changes they already figured out in their head.)

  Basically that’s proposing to take the programmer job description and move it from hands-on write the code yourself to hands-off review and adjust the code the AI agents are writing.

  Many people currently employed as programmers actually do enjoy the hands-on part and I suspect that even those doing it mostly for the money tend to like it more than code reviews. Code reviews are probably just below writing documentation and writing tests on the list of things most programmers don’t like doing.

  Now, personally I don’t mind writing tests and don’t mind doing code reviews myself, probably more so than most people I’ve worked with, and yet if that’s what the job morphs into I’ll probably change careers, circumstances permitting.

  What I could see is that, as the job description changes, the kind of people who get into the job also changes with it. And there’s certainly people who do think like you describe. Just not many of them in my bubble.