151–160 of 245 posts
Earlier quoted context omitted.
The passive voice is doing a lot of work in your sentence.
We are perpetually just months away from software jobs being obsolete. AGI was achieved internally at OpenAI a year ago. Multiple companies have already re-hired staff they had fired and replaced with AI. etc.
See? I can do this too.
Earlier quoted context omitted.
Your problem is thinking that hype artists, professionals and skeptics are all the same voice with the same opinion. Because of that, you can't recognize when sentiment is changing among the more skeptical.
You are responding to some voices in your head, not to the context of the conversation. You're also presuming too much about what I'm thinking and being dead wrong about that.
Earlier quoted context omitted.
> in my head they are both mapped to the red "embedding" Sure. That's the point. These studies are a study of language per se . Not how language influences perception to a meanigful degree. Sapir-Whorf is a cool hypothesis. But it isn't true for humans. (Out of curiosity, what is "embedding" doing that "word" does not?)
Word would imply that this only happens when I translate my thoughts to a chosen human language (or articulate thoughts in a language). I chose embedding because I think this happens much earlier in the pipeline: the information of the exact shade is discarded before the scene is committed to memory and before most conscious reasoning. I see this as something happening at the interface of the vision system, not the s…
I'm curious if we have any evidence for this. A lot of visual processing happens in the retina. To my knowledge, the retina has no awareness of words. I'd also assume that the visual cortex comes before anything to do with language, though that's just an assumption.
> it's not that the words we know are the reason for how we can think, it's that what differences we care about cause both the ways we think and the words we use
This is fair. Though for something like colour, a far-older system in our brains than language, I'd be sceptical of the latter controlling the former.
I actually love the idea of totally new naming schemes for experimental software. Certain name types are so normalized (agent, worker, etc) that while they serve their role well, they likely limit our imagination when thinking about software, and it's a worthwhile effort to explore alternatives.
It's like Conway's Law. Both humans and agents arrive at roughly identical hierarchies for organizing labor. There is something inherent in the game of telephone required by limited working memory that requires this structure. Gas Town's only failure is not being familiar with prior art and coming up with very strange names for established patterns that already exist in large hierarchical organizations like governmen…
Earlier quoted context omitted.
try the tools. Really. If you are remotely interested in tech or AI, try the tools Copilot this is not. You may be trolling of course. There are huge steps between these various tools, if you try them, for a smidge of investment, it will become obvious what the trajectory is. It is like saying "I don't handwrite anything, I care too much about line spacing, I only use a dot matrix printer" when some one is trying to…
I'm not trolling. I'm just not aware of major differences between them. When I make a change with a Copilot Agent, it checks for issues, builds my project, runs tests, and iterates until things work. Multiple agents can do that in parallel. My impression was that this does more or less the same thing. That said, I'm definitely open to learning more about them both. What are the advantages of this in your experience?
Beads formalizes building a DAG for a given workload. This has a bunch of implications, but one is that you can specify larger workloads and the agents won’t get stuck or confused. At some level gas town is a bunch of scaffolding around the benefits of beads; an orchestrator that is native to dealing with beads opens up many more benefits than one that isn’t custom coded for it.
Think of a human needing to be interacted with as a ‘fault’ in an agentic coding system — a copilot agent might be at 0.5 9s or so - 50% of tasks can complete without intervention, given a certain set of tasks. All the gas town scaffolding is trying to increase the number of 9s, and the size of the task that can be given.
My take - Gas town (as an architecture) certainly has more nines in it than a single agent; the rest is just a lot of fun experimentation.
I think Yegge and Huntley are smart guys. I don't think they're doing a good job incubating their ideas into being precise and clearly useful -- there is something to be said about being careful and methodical before showing your cards. The message they are spreading feels inevitable, but the things they are showing now are ... for lack of better words, not clear or sharp. In a recent video at AI Engineer, Yegge comm…
Don’t be mad!
Also, beads is genuinely useful. In my estimation, gas town, or a successor built on a similar architecture, will not only be useful, but likely be considered ‘state of the art’ for at least a month sometime in the future. We should be glad this stuff is developed in the open, in my opinion.
I don't understand why people are making this so complicated. We have a battle tested SDLC. We don't need to reinvent this shit. We just need to make some affordances in the tools and processes we set up for the majority of the actors in the system to be agents (such as rationing human attention). Spec your software like an architect/po, decompose it into a task dag, then orchestrate for each lane and assemble all ch…
These operate in parallel. Maybe you SDLC does that, the effort of each human developer sitting in a planning meeting, getting jira tickets, doing individual code (or pair or whatever), reporting back in standup, coordinating the next step, getting it QA'ed... Yes, if your shop is well developed these work (10% of the time every time), but this is a structure to kick that all in to gear, as a repo, where all you need…
Earlier quoted context omitted.
Not sure you’ve actually tried using it, but beads has been an absolute game changer for my projects. “Game changer” is even underselling it.
I'm not entitled to your time of course, but would you mind describing how? All I know is beads is supposed to help me retain memory from one session to the next. But I'm finding myself having to curate it like a git repo (and I already have a git repo). Also it's quite tied to github, which I cannot use at work. I want to use it but I feel I need to see how others use it to understand how to tailor it for my workflo…
What agent do you use it with, out of curiosity?
At any rate, to directly answer your question, I used it this weekend like this:
“Make a tool that lets me ink on a remarkable tablet and capture the inking output on a remote server; I want that to send off the inking to a VLM of some sort, and parse the writing into a request; send that request and any information we get to nanobanana pro, and then inject the image back onto the remarkable. Use beads to plan this.”
We had a few more conversations, but got a workable v1 out of this five hours later.
Earlier quoted context omitted.
I'm not trolling. I'm just not aware of major differences between them. When I make a change with a Copilot Agent, it checks for issues, builds my project, runs tests, and iterates until things work. Multiple agents can do that in parallel. My impression was that this does more or less the same thing. That said, I'm definitely open to learning more about them both. What are the advantages of this in your experience?
It is worth an install; it works very differently than an agent in a single loop. Beads formalizes building a DAG for a given workload. This has a bunch of implications, but one is that you can specify larger workloads and the agents won’t get stuck or confused. At some level gas town is a bunch of scaffolding around the benefits of beads; an orchestrator that is native to dealing with beads opens up many more benefi…
> gas town is [...] an orchestrator that is native to dealing with beads
Thanks - this is very helpful in deciding when and where to use them. Steve's descriptions sounded to me like more RAM and Copilot Agents:
> [Beads:] A memory upgrade for your coding agent
> [Gas Town:] a new take on the IDE for 2026. Gas Town helps you with the tedium of running lots of Claude Code instances