☆ Yσɠƚԋσʂ ☆

  • 12.6K Posts
  • 13K Comments
Joined 6 years ago
cake
Cake day: January 18th, 2020

help-circle







  • At the end of the day technology is going to advance, and the rational thing to do is to figure out how to use it effectively. Yes, a lot of technology gets abused all the time, our society as a whole is incredibly wasteful. But I see technological progress as a net positive, if anything I think the problem is with our social structures and broken incentives. And that’s what we should focus on fixing.

    For me, these tools have unarguably save a ton of time and frustration every single day. For example, I had to work on a Js project recently for work. I haven’t touched Js seriously in at least a decade and I’m not familiar with the ecosystem, libraries, language quirks, and so on. If I had to figure all of that out from scratch previously, I simply would not have been able to take on this project. LLM completely papered over all that for me. I know how to structure programs, I can read Js just fine, but I didn’t have to spend the time searching and internalizing all these little details of how to run tests, which npm modules I’d need to use, what React lifecycle hooks I’d need, etc. It made the project far more enjoyable to work on, and I was able to deliver it as fast as using languages I’m intimately familiar with.

    The thing is that I did have to spend the time to actually use the tool effectively, to develop intuition for tasks it can do well and those it can’t. How to get it to write code in a way I can understand and review effectively, how to see when it’s not doing what I want and correct that. Just like any tool, you have to spend the time to actually learn it to get value out of it. If you start with the premise that you dislike the idea of the tool, then it’s guaranteed that you’re not going to have a good time using it. But it’s a mistake to extrapolate that other people aren’t getting actual value out of it based on that.

    Meanwhile, the whole context of this discussion is running local models which are tools that are available to the common person, and do not result in any capture of labor that I can see. You could make this argument with using proprietary models that you rent from a vendor, but it simply does not hold with ones you run locally.



  • GC has little to do with web page bloat though. In fact, that’s precisely where human agency comes in to design things in a sensible way. And I see little evidence to support the claim that stochastic automation leads to worse code myself. I use these tools every day, that’s completely contrary to my experience. I get the impression that you’re starting from a conclusion and coming up with a narrative that fits it rather than actually trying these tools out and seeing how to work with them effectively.





  • Having done development for over two decades now, I’m really not learning anything useful when I make yet another CRUD end point on a server, or a new widget. The reality is that most coding tasks are highly repetitive and we’re just writing the same boiler plate in slightly different contexts. Being able to offload boring and repetitive tasks to a machine is what automation is for.

    I’d rather spend my brainpower on things I find interesting like the overall architecture and the problem being solved while leaving writing implementation details to the LLM. It’s not like you stop solving problems when you use an LLM for coding, you’re just focusing on different things at that point.

    It’s also worth noting that this argument isn’t new. I’m old enough to remember how writing assembly by hand was what real coders did or how using GC was cheating because you shouldn’t offload memory management to the computer. In each case it turned out that using better tools let us build more interesting things in the end and freed up human thinking from boring and repetitive work.



  • The US wouldn’t be capitulating right now if they were in a position to continue the war, and Israel can’t do shit on its won. They will absolutely try to keep the war going, but they’re running up against material limits here. I also doubt Trump himself really matters all that much here, there’s a huge amount of political capture by Israel in the US, and this lobby is going to push for war no matter what. But US economy and military industry isn’t capable of continuing it.








  • Pinprick attacks on refineries don’t actually have a big impact. They get a lot of media, but they don’t actually cause major disruptions for more than a few days. If you look at the size of oil refineries you’ll quickly realize that a single drone isn’t going to do much to them. This sort of propaganda is aimed at people who have no clue how this stuff actually works, and just look at pictures of smoke and think Russian oil production has completely stalled while in reality it’s largely unaffected.







  • I don’t mean you turn the program itself into a genetic algorithm. I’m saying that the agentic loop for producing code acts as one. The code itself is just regular code. And the loop isn’t really any more inefficient than what you do as a developer. It almost never happens that you write perfect code on a first try in practice. You’ll write some code, run your tests, look how it did, and iterate. That’s precisely the same process the agent follows.

    The difference from a typical genetic algorithm is that the LLM is not just randomly generating text that eventually fits into the shape you specified. It’s generating code that’s already close to what’s intended most of the time, and it just needs a bit of massaging to get completely right. That’s the feedback loop here.


  • I find I kind of look at the whole agentic harness setup as a genetic algorithm. Your tests and specs are the fitness function for the program you’re evolving, and the LLM is the mutator. At each step it generates some output, it gets tested against the fitness function, the LLM gets feedback and iterates on it. Eventually something working falls out in the end. The better you can define the selection criteria the more you box the agent in the better results you get.

    The trick I can recommend for getting the model to code is to ask it to come up with a phased plan composed of focused features, and then to build each feature on its own branch. That way you have a clear unit of work that does a specific thing which makes it much easier to review the code. Can also recommend tools like https://github.com/Fission-AI/OpenSpec for making specs to box the model in when it works.






  • You can run the Gemma 4 and Qwen3.5 MoE models with as little as 12 GB of VRAM at 30-40 tps (Q4/Q5), and they both blow GPT-4o and DeepSeek R1 out of the water. But 64gb RAM is also not really out of scale with the cost of a shop tool in other trades. If you’re a professional that’s confident in a positive return on the investment, or just a hobbyist with the luxury budget for a “shop” that cost is well within consumer market. That’s not everybody, of course, but it’s not some inconceivable fantasy.

    The key point is that local models continue to get more efficient and usable. You need high end consumer grade hardware today, but given how fast improvements are happening, it’s entirely likely that you’ll be able to get the same capability on even smaller hardware in a few months.