| ▲ | bastawhiz 10 hours ago | ||||||||||||||||||||||
The idea of gas town is simultaneously appealing and appalling to me. The waste and lack of control is wild, but at the same time there's at least a nugget of fascinating, useful work in there. In a world where compute is cheap and abundant and the models are a notch smarter, I think it's the start of a useful framework for what the future of augmented work might look like. I have no interest in using gas town as it is (for a plethora of reasons, not the least of which being that I'm uninterested in spending the money), but I've been fascinated with the idea of slowing it down and having it run with a low concurrency. If you've got a couple A100s, what does it look like if you keep them busy with two agents working concurrently (with 20+ agents total)? What does it mean to have the town focus the scope of work to a series of non-overlapping changesets instead of a continuous stream of work? If you don't plan to have it YOLO stuff in realtime and you can handle the models being dumber than Claude, I think you can have it do some really practical, useful things that are markedly better than the tools we have today. | |||||||||||||||||||||||
| ▲ | jsight 8 hours ago | parent | next [-] | ||||||||||||||||||||||
I put it in a VM and had it build a really simple todo app for me the other day. It wasted so many tokens that I can't help but agree with you right now. And I could certainly have done the same thing with beads and opus in approximately the same amount of time. However, the gas town one was almost completely hands off. I think my only interventions were due to how beta it was, so I had to help it work around its own bugs to keep from doing stupid things. Other than that, it implemented exactly what I asked for in a workable fashion with effectively one prompt. It would have taken several prompts and course corrections to get the same result without it. Other than the riskyness (it runs in dangerous permissions mode) and incredible cost inefficiency, I'd certainly use it. | |||||||||||||||||||||||
| |||||||||||||||||||||||
| ▲ | condiment 5 hours ago | parent | prev | next [-] | ||||||||||||||||||||||
If software engineers can agree on anything, it's that LLM experiences are wildly inconsistent. People have similar inconsistencies. We have different experiences, intellects, educations, priorities, motivations, value systems. And in software specifically (and institutions generally) we create methodologies and processes that diminish our inconsistencies and leverage our strengths. Gas town is a demonstration of a methodology for getting a consistent result from inconsistent agents. The case in point is that Yegge claims to have solved the MAKER problem (tower of Hanoi) via prompting alone. With the right structure, quantity has a quality all its own. | |||||||||||||||||||||||
| ▲ | hahahahhaah 3 hours ago | parent | prev [-] | ||||||||||||||||||||||
I feel like each of these things is going to be bitter lessoned by a model who you can just say "yeah get a bunch of agents together and clone twitter, get em to put requirements together first, ya know, measure once and all that. promise em a beer when done". | |||||||||||||||||||||||