Hacker News new | past | comments | ask | show | jobs | submit login Welcome to Gas Town ( steve-yegge.medium.com ) 174 points by gmays 16 hours ago | hide | past | favorite | 65 comments tokioyoyo 1 hour ago | next [–] Everyone keeps being angry at me when I mention that the way things are going, future development will just be based on "did something wrong while writing code? all good, throw everything out and rewrite, keep pulling the level of the slot machine and eventually it'll work". It's a fair tactic, and it might work if we make the coding agents cheap enough. I'll add a personal anecdote - 2 years ago, I wrote a SwiftUI app by myself (bare you, I'm mostly an infrastructure/backend guy with some expertise in front end, where I get the general stuff, but never really made anything big out of it other than stuff on LAMPP back in 2000s) and it took me a few weeks to get it to do what I want to do, with bare minimum of features. As I was playtesting my app, I kept writing a wishlist of features for myself, and later when I put it on AppStore, people around the world would email me asking for some other features. But life, work and etc. would get into way, and I would have no time to actually do them, as some of the features would take me days/weeks. Fast forward to 2 weeks ago, at this point I'm very familiar with Claude Code, how to steer multiple agents at a time, quick review its outputs, stitch things together in my head, and ask for right things. I've completed almost all of the features, rewrote the app, and it's already been submitted to AppStore. The code isn't perfect, but it's also not that bad. Honestly, it's probably better from what I would've written myself. It's an app that can be memory intensive in some parts, and it's been doing well from my testings. On top of it, since I've been steering 2-3 agents actively myself, I have the entire codebase in my mind. I also have overwhelming amount of more notes what I would do better and etc. My point is, if you have enough expertise and experience, you'll be able to "stitch things together" cleaner than others with no expertise. This also means, user acquisition, marketing and data will be more valuable than the product itself, since it'll be easier to develop competing products. Finding users for your product will be the hard part. Which kinda sucks, if I'll be honest, but it is what it is. reply CodingJeebus 21 minutes ago | parent | next [–] > It's a fair tactic, and it might work if we make the coding agents cheap enough. I don’t see how we get there, though, at least in the short term. We’re still living in the heavily-corporate-subsidized AI world with usage-based pricing shenanigans abound. Even if frontier models providers find a path to profitability (which is a big “if”), there’s no way the price is gonna go anywhere but up. It’s moviepass on steroids. Consumer hardware capable of running open models that compete with frontier models is still a long ways away. Plus, and maybe it’s just my personal cynicism showing, but when did tech ever reduce pricing while maintaining quality on a provided service in the long run? In an industry laser focused on profit, I just don’t see how something so many believe to be a revolutionary force in the market will be given away for less than it is today. Billions are being invested with the expectation that it will fetch much more revenue than it’s generating today. reply nonethewiser 42 minutes ago | parent | prev | next [–] The difficulty comes in managing the agent. Ensuring it knows the state of the codebase, conventions to follow, etc. Steering it. I've had the same experience as you. I've applied it to old projects which I have some frame of reference for and it's like a 200x speed boost. Just absolutely insane - that sort of speed can overcome a lot of other shortcomings. reply gensym 1 hour ago | prev | next [–] Gas Town is an appropriate name since using it is effectively pouring a tank of gasoline on a pile of money and lighting a match. reply NoImmatureAdHom 29 minutes ago | parent | next [–] Out of curiosity, how much money are we talking about? reply deepjoy 1 hour ago | prev | next [–] Not sure if anyone else noticed. The first commit on that repository was just about 3 weeks ago. https://github.com/steveyegge/gastown/commit/4c782bc59de8cba... Has to be close for the shortest time from first commit to HN front page. reply qcnguy 20 hours ago | prev | next [–] This is clearly going to develop the same problem Beads has. I've used it. I'm in stage 7. Beads is a good idea with a bad implementation. It's not a designed product in the sense we are used to, it's more like a stream of consciousness converted directly into code. There are many features that overlap significantly, strange bugs, and the docs are also AI generated so have fun reading them. It's a program that isn't only vibe coded, it was vibe designed too. Gas Town is clearly the same thing multiplied by ten thousand. The number of overlapping and adhoc concepts in this design is overwhelming. Steve is ahead of his time but we aren't going to end up using this stuff. Instead a few of the core insights will get incorporated into other agents in a simpler but no less effective way. And anyway the big problem is accountability. The reason everyone makes a face when Steve preaches agent orchestration is that he must be in an unusual social situation. Gas Town sounds fun if you are accountable to nobody: not for code quality, design coherence or inferencing costs. The rest of us are accountable for at least the first two and even in corporate scenarios where there is a blank check for tokens, that can't last. So the bottleneck is going to be how fast humans can review code and agree to take responsibility for it. Meaning, if it's crap code with embarrassing bugs then that goes on your EOY perf review. Lots of parallel agents can't solve that fundamental bottleneck. reply nikvdp 27 minutes ago | parent | next [–] You might like linear-beads[1] better. It's a simpler and less invasive version of beads I made to solve some of the unusual design choices. It can also (optionally) use linear as the storage backend for the agent's tasks, which has the excellent side effect that you as a human can actually see what the agent is working on and direct the agent from within linear. Despite it's quirks I think beads is going to go down as one of the first pieces of software that got some adoption where the end user is an agent [1]: https://github.com/nikvdp/linear-beads reply ac29 13 hours ago | parent | prev | next [–] >This is clearly going to develop the same problem Beads has. I've used it. I'm in stage 7. Beads is a good idea with a bad implementation. It's not a designed product in the sense we are used to, it's more like a stream of consciousness converted directly into code. There are many features that overlap significantly, strange bugs, and the docs are also AI generated so have fun reading them. It's a program that isn't only vibe coded, it was vibe designed too. Yeah this describes my feeling on beads too. I actually really like the idea - a lightweight task/issue tracker integrated with a coding agent does seem more useful than a pile of markdown todos/plans/etc. But it just doesnt work that well. Its really buggy and the bugs seem to confuse the agent since it was given instructions to do things a certain way that dont work consistently. reply laxori666 9 hours ago | root | parent | next [–] I tried using beads. There kept being merge conflicts and the agent just kept one or the other changes instead of merging it intelligently, killing any work I did on making tasks or resolving others. Still haven't seen how beads solves this problem... and it's also an unnecessary one. This should be a separate piece of it that doesn't rely on agent not funging up the merge. reply sbarre 33 minutes ago | root | parent | next [–] How long until Atlassian makes "JIRA for Agents" where all your tasks and updates and memory aren't stored in Git (so no merge conflicts) but are still centralized and shareable between all your agents/devs/teams.. And also auditable, trackable, reportable, etc.. reply danpalmer 1 hour ago | parent | prev | next [–] > Beads is a good idea with a bad implementation > Course, I’ve never looked at Beads either, and it’s 225k lines of Go code that tens of thousands of people are using every day. I just created it in October. If that makes you uncomfortable, get out now. reply dgunay 52 minutes ago | parent | prev | next [–] I am wondering if it would be a viable strategy to vibe code almost "in reverse" - take a giant ball of slop such as beads, and use agents to strip away feature after feature until you are left with only exactly what you need, streamlined to your exact workflow. Maybe it'd be faster to just start from scratch, but it might be an interesting experiment. Most of my struggles with using beads so far have come from being off the #1 use case of too many of its features, and having to slog through too much documentation to know what to actually use. reply skybrian 2 hours ago | parent | prev | next [–] Huh. I was going to try it, but maybe I need to vibe-code my own agent issue-tracker. Or did you find one that's good? reply xrd 1 hour ago | root | parent | next [–] Why can't you use an issue tracker that is built into the git control, like forgejo? It feels like it would be easy to use this with an API key, out or direct database access (I'm doing both with agents). If you self host, you've got a very standard and reliable issue tracker. Why does beads need to exist? What can't an agent do with that setup I've described above? reply NamlchakKhandro 5 hours ago | parent | prev | next [–] 100%. There's a lot of strange things going on in that project. try to add some common sense, and you'll get shouted out. which is fine, I'll just make my own version without the slop. reply mccoyb 23 hours ago | prev | next [–] The article seems to be about fun, which I'm all for, and I highly appreciate the usage of MAKER as an evaluation task (finally, people are actually evaluating their theories on something quantitative) but the messaging here seems inherently contradictory: > Gas Town helps with all that yak shaving, and lets you focus on what your Claude Codes are working on. Then: > Working effectively in Gas Town involves committing to vibe coding. Work becomes fluid, an uncountable that you sling around freely, like slopping shiny fish into wooden barrels at the docks. Most work gets done; some work gets lost. Fish fall out of the barrel. Some escape back to sea, or get stepped on. More fish will come. The focus is throughput: creation and correction at the speed of thought. I see -- so where exactly is my focus supposed to sit? As someone who sits comfortably in the "Stage 8" category that this article defines, my concern has never been throughput, it has always been about retaining a high-degree of quality while organizing work so that, when context switching occurs, it transitions me to near-orthogonal tasks which are easy to remember so I can give high-quality feedback before switching again. For instance, I know Project A -- these are the concerns of Project A. I know Project B -- these are the concerns of Project B. I have the insight to design these projects so they compose, so I don't have to keep track of a hundred parallel issues in a mono Project C. On each of those projects, run a single agent -- with review gates for 2-3 independent agents (fresh context, different models! Codex and Gemini). Use a loop, let the agents go back and forth. This works and actually gets shit done. I'm not convinced that 20 Claudes or massively parallel worktrees or whatever improves on quality, because, indeed, I always have to intervene at some point. The blocker for me is not throughput, it's me -- a human being -- my focus, and the random points of intervention which ... by definition ... occur stochastically (because agents). Finally: > Opus 4.5 can handle any reasonably sized task, so your job is to make tasks for it. That’s it. This is laughably not true, for anyone who has used Opus 4.5 for non-trivial tasks. Claude Code constantly gives up early, corrupts itself with self-bias, the list goes on and on. It's getting better, but it's not that good. reply anthonypasq 3 hours ago | parent | next [–] a response like this is confusing to me. what you are saying makes sense, but seems irrelevant. something like gas town is clearly not attempting to be a production grade tool. its an opinionated glimpse into the future. i think the astethic was fitting and intentional. this is the equivalent of some crazy inventor in the 19th century strapping a steam engine onto a unicycle and telling you that some day youll be able to go 100mph on a bike. He was right in the end, but no one is actually going to build something usable with current technology. Opus 4.5 isnt there. But will there be a model in 3-5 years thats smart enough, fast enough, and cheap enough for a refined vision of this to be possible? Im going to bet on yes to that question. reply mccoyb 34 minutes ago | root | parent | next [–] I think this read is generous: > something like gas town is clearly not attempting to be a production grade tool. Compare to the first two sentences: > Gas Town is a new take on the IDE for 2026. Gas Town helps you with the tedium of running lots of Claude Code instances. Stuff gets lost, it’s hard to track who’s doing what, etc. Gas Town helps with all that yak shaving, and lets you focus on what your Claude Codes are working on. Compared to your read, my read is confused: is it or is it not intending to be a useful tool (we can debate "production" quality, here I'm just thinking something I'd actually use meaningfully -- like Claude Code)? I think the author wants us to take this post seriously, so I'm taking it seriously, and my critique in the original post was a serious reaction. reply leftbehinds 3 hours ago | root | parent | prev | next [–] in 3-5years, sure, just like we are all currently using crypto to pay for groceries and smart contracts for all legal matters. reply anthonypasq 3 hours ago | root | parent | next [–] ... no one ever used crypto to buy things. most engineers are currently already using AI. such a dumb comparison that really just doesnt pass the sniff test. reply jbl0ndie 2 hours ago | root | parent | next [–] Not quite true. This pub's changed hands now but it was possible to pay in bitcoin for several years. https://www.wired.com/story/london-bitcoin-pub/ reply benregenspan 1 hour ago | root | parent | next [–] For anyone who takes doing their taxes seriously, this is a nightmare. Every pint ordered involves a capital gain (or loss) for the buyer. At a certain point you're doing enough accounting that you might as well be running the bar yourself (or just paying in cash)! reply fragmede 3 hours ago | root | parent | prev | next [–] Their green username is leftbehinds. Let them hold their wrong opinions based on outdated information. reply iamwil 23 hours ago | parent | prev | next [–] > For instance, I know Project A -- these are the concerns of Project A. I know Project B -- these are the concerns of Project B. I have the insight to design these projects so they compose, so I don't have to keep track of a hundred parallel issues in a mono Project C. On each of those projects, run a single agent -- with review gates for 2-3 independent agents (fresh context, different models! Codex and Gemini). Use a loop, let the agents go back and forth. Can you talk more about the structure of your workflow and how you evolved it to be that? reply mccoyb 22 hours ago | root | parent | next [–] I've tried most of the agentic "let it rip" tools. Quickly I realized that GPT 5~ was significantly better at reasoning and more exhaustive than Claude Code (Opus, RL finetuned for Claude Code). "What if Opus wrote the code, and GPT 5~ reviewed it?" I started evaluating this question, and started to get higher quality results and better control of complexity. I could also trust this process to a greater degree than my previous process of trying to drive Opus, look at the code myself, try and drive Opus again, etc. Codex was catching bugs I would not catch with the same amount of time, including bugs in hard math, etc -- so I started having a great degree of trust in its reasoning capabilities. I've codified this workflow into a plugin which I've started developing recently: https://github.com/evil-mind-evil-sword/idle It's a Claude Code plugin -- it combines the "don't let Claude stop until condition" (Stop hook) with a few CLI tools to induce (what the article calls) review gates: Claude will work indefinitely until the reviewer is satisfied. In this case, the reviewer is a fresh Opus subagent which can invoke and discuss with Codex and Gemini. One perspective I have which relates to this article is that the thing one wants to optimize for is minimizing the error per unit of work. If you have a dynamic programming style orchestration pattern for agents, you want the thing that solves the small unit of work (a task) to have as low error as possible, or else I suspect the error compounds quickly with these stochastic systems. I'm trying this stuff for fairly advanced work (in a PhD), so I'm dogfooding ideas (like the ones presented in this article) in complex settings. I think there is still a lot of room to learn here. reply mlady 3 hours ago | root | parent | next [–] I'm sure we're just working with the same tools thinking through the same ideas. Just curious if you've seen my newsletter/channel @enterprisevibecode https://www.enterprisevibecode.com/p/let-it-rip It's cool to see others thinking the same thing! reply vessenes 2 hours ago | prev | next [–] I put in 15 hours or so with gas town this weekend, from just around the 0.1 release. Think of as an extended bipolar-optimism-fueled glimpse into the future. Steve's MO is laid out in the medium post - but basically, it's okay to lose things, rewrite whole subsystems, whatever, this is the future. It's really fun and interesting to watch the speed of development. I've made a few multi agent coding setups in the last year, and I think gas town has the team side about right: big boss (mayor), operations boss (deacon), relatively linear keeper of truth (witness), single point for merges (refiner), lots of coders with their code held lightly. I love the idea of formulas - a lot of what makes gas town work and informs how well it ultimately will work is the formulas. They're close conceptually to skills. I don't love the mad max branding, but meh, whatever, it's fun, and a perk of the brave new world where you can make stuff like for a few hundred bucks a month sent to anthropic - software can have personality again, yay. Conceptually I think there is a product team element to this still missing - deploy engineers, product managers, visual testing. Everything is sort of out there, janky in parts, but workable to glue together right now, and will only improve. That said, the mad max town analogy is going to get overstretched at some point; we already have pretty good names for all the parts that are needed, and as coordination improves, we're going to want to add more stuff into the coordination. So, I'd like to see a version of this with normal names and expanded. Upshot - worth a look - if beads is any indication, give it a month or two or four to settle down unless you like living on the bleeding bleeding edge. reply thesurlydev 2 hours ago | prev | next [–] I had a lot of fun reading the articles about Gas Town although I started to lose track of the odd naming. Only odd because they make sense to Steve and others who have seen the Mad Max, Water World movies. I promptly gave Claude the text to the articles and had him rewrite using idiomatic distributed systems naming. Fun times! reply fragmede 1 hour ago | parent | next [–] Care to share that with the rest of the class? I'd love to hear what those idiomatic distributed systems namings are! reply dgunay 49 minutes ago | root | parent | next [–] Ran it through ChatGPT: Town = Central orchestrator / control plane Rig = Project or workspace namespace Polecat = Ephemeral worker job Refinery = Merge queue manager Witness = Worker health monitor Crew = Persistent worker pool Beads = Persistent work items / tasks Hooks = Work queues / task slots GUPP = Work processing guarantee Molecules/Wisps = Structured, persistent workflows Convoys = Grouped feature work units https://chatgpt.com/share/695c6216-e7a4-800d-b83d-fc1a22fd8a... reply fragmede 23 minutes ago | root | parent | next [–] Thank you! Is this the future? Everyone gets to have their own cutesy translation of everything? If I want "kubectl apply" to have a Tron theme, while my coworker wants a Disney theme. Is the runbook going to be in Klingon if I'm fluent in that? reply hi_hi 2 hours ago | prev | next [–] Are many, many Agents going to produce better quality outputs than 1 Agent? Assuming this isn't a parody project, maybe this just isn't for me, and thats fine. I'm struggling to understand a production use case where I'd be comfortable letting this thing loose. Who is the intended audience for this design? reply giancarlostoro 3 hours ago | prev | next [–] What's really amazing to me is this is how I've thought about building the same thing, by using beads... Glad someone in the hivemind did it. reply 22c 3 hours ago | parent | next [–] > I've thought about building the same thing, by using beads... Glad someone in the hivemind did it. Gas Town is from the creator of beads. reply giancarlostoro 3 hours ago | root | parent | next [–] This makes even more sense, it definitely feels like a logical step with beads. I use Beads a lot, its one of the few things I use with Claude Code. reply michaelbuckbee 2 hours ago | parent | prev | next [–] Late to the party, would love to know more of your workflow with how you're using beads. reply giancarlostoro 9 minutes ago | root | parent | next [–] I use Zed (this is completely optional since claude code can work 100% stand alone), Claude Code (I have Max) and Beads. I also take advantage of the .claude/instructions.md file and let Claude know to ALWAYS use Beads, and to use rg instead of "grep" which is kind of slow (if anyone from Anthropic is reading this, for the love of GOD use ripgrep instead of grep), a small summary about the project, and some ground rules. If there's key tickets that matter for the project I tell it to note them in the instructions. The instructions files the first thing Claude reads when you first open up a chat window with it, if you make amendments ask it to reread the file. Outside of that its trial and error, but I've learned you don't need to kick off a new chat instance very much if at all. I also like Beads because if I have to "run" or go offline I can tell it to pause and log where it left off / where its at. For some projects I tell claude not to close tickets without my direct approval because sometimes it closes them without testing, my baseline across all projects is that it compiles and runs without major errors. reply lifetimerubyist 3 hours ago | prev | next [–] If babysitting 30 claude agents is the future of professional programming I want zero part of it. reply smileson2 3 minutes ago | parent | next [–] I was hoping this stuff would lead to a world with less software over time not more of it part of me feels like the current crop of tools does nothing but reinforce and entrench past mistakes reply nonethewiser 28 minutes ago | parent | prev | next [–] I bet you type with a keyboard. reply gneray 3 hours ago | prev | next [–] > But first, before we get into Gas Town’s operation, I need to get rid of you real quick. WARNING DANGER CAUTION GET THE F** OUT YOU WILL DIE I have never met Steve, but this warning alone is :chefskiss: reply dang 3 hours ago | prev | next [–] (We re-upped this post because it hadn't made the frontpage despite lots of upvotes - which happens sometimes. This explains why some of the comments have timestamps that appear older than the post itself. I got tired of trying to make them line up, sorry!) reply toast0 3 hours ago | parent | next [–] > I got tired of trying to make them line up, sorry! IMHO, it's less disorienting to have the post dated after the comments than it is to see a comment you thought you wrote a couple days ago but is dated today. So you're welcome to stop trying to line up timestamps. reply dang 2 hours ago | root | parent | next [–] The problem is that it leads to endless confusion that ends up taking over threads. We tried it! Status quo sucks also, it just sucks less. Haven't yet figured out an actually good solution. Sorry! reply skybrian 2 hours ago | root | parent | next [–] How about recording two dates on the post, the original post date and the re-upped date, and then putting something like "14 hours ago; originally 2 days ago" in the post header? reply Philpax 2 hours ago | root | parent | prev | next [–] Agreed, although perhaps not as strongly; I remember seeing these comments from a few days ago, so I was feeling a little gaslit seeing the new timestamps and wondered if I'd hallucinated the original thread. reply mhitza 3 hours ago | parent | prev | next [–] What happens sometimes, artifical uplifting of posts, posts with high vote count that don't reach the frontpage, or both? reply dang 2 hours ago | root | parent | next [–] I meant the latter, but both! Re artificial uplifting a.k.a. re-upping, see https://news.ycombinator.com/item?id=26998308 and https://news.ycombinator.com/pool reply swah 1 hour ago | prev | next [–] Sounds like "madness" (or better, fun) but - if this work all converged into "something", wouldn't the product/system improve so much, that in a matter of days, really nothing would be left to do..? Most likely, tens of other bugs are being introduced at each step, etc etc, right? reply wredcoll 1 day ago | prev | next [–] Boy this smells a lot like early days of blogging about block chains, specifically ethereum and friends. It's not that there's nothing useful, maybe even important, in there, it's just so far it's all just the easy parts: playing around inside a computer. I've noticed a certain trend over the years where you get certain types of projects that get lots of hype and excitement and much progress seems to be made, but when you dig deep enough you find out that it's all just the fun, easy sort of progress. The fun progress, which not at all coincidentallly tends to also be the easy progress, is the type that happens solely inside a computer. What do I mean by that? I mean programs who only operate at the level of artificial computer abstractions. The hard part is always dealing with "the real world": hardware that returns "impossible" results to your nicely abstract api functions, things that stop working in places they really shouldn't be able to, or even, and this is the really tricky bit, dealing with humans. Databases are a good example of this kind of thing. It's easy to start off a database writing all the clever (and fun) bits like btrees and hash maps and chained hashes that spill to disk to optimize certain types of tables and so on, but I'd wager that at least half of the code in a "real" database like sqlite or postgresql is devoted to dealing with strange hardware errors or leaky api abstractions across multiple platforms or the various ways a human can send nonsensical input into the system and really screw things up. I'd also bet that this type of code is a lot less fun to write and took much longer than the rest (which incidentally is why I always get annoyes when programming language demos show code with only a happy path, but that's another rant and this comment is already excessive). Anyways, this AI thing is definitely a gold rush and it's important to keep in mind that there was in fact a lot of gold that got dug up but, as everyone constantly repeats, the more consistent way to benefit is sell the shovels and this is very definitely an ad for a shovel. reply _steve_yegge_ 2 hours ago | parent | next [–] I love this take. I think what you're describing is very much happened with the Industrial Revolution. It was just a bunch of powerful, dangerous machines at first, doing small jobs faster. Scaling it up took the whole planet and a long time. I think we are at the beginning of the second such journey. Lots of people will get hurt while we learn how to scale it up. It's why I've gone with dangerous sounding theming and lots of caution with Gas Town. I only think it takes 2 years this time though. reply WesolyKubeczek 3 hours ago | parent | prev | next [–] It's not a coincidence that all those articles and tutorials urge you to use agents to spend tokens and write more agents that spend more tokens and talk to even more LLMs, and write even more agents and wrappers... I don't know to which end. Probably to spend tokens until your wallet bleeds dry, I guess. Agents and wrappers that put you deeper into LLM spending frenzy is like the new "todo app". reply bigwheels 2 hours ago | prev | next [–] I tried it out but despite what the README says ( https://github.com/steveyegge/gastown ), the mayor didn't create a convoy or anything, the mayor is just doing all the work itself, appearing no different than a `claude` invocation. Update: I was hoping it'd at least be smart enough to automatically test the project still builds but it did not. It also didn't commit the changes. > are you the mayor? Yes. I violated the Mayor protocol - I should have dispatched this work to the gmailthreading crew worktree instead of implementing it directly myself. The CLAUDE.md is clear: "Mayor Does NOT Edit Code" and "Coordinate, don't implement." Maybe Yegge should have build it around Codex instead - Codex is a lot better at adhering to instructions. Pros: The overall system architecture is similar to my own latest attempt at solving this problem. I like the tmux-based console-monitoring approach (rather than going full SDK + custom UI), it makes it easier to inspect what is going on. The overlap between my ideas and Steve's is around 75%. Cons: Arguing with "The Mayor" about some other detached processes poor workmanship seems like a major disconnect and architectural gap. A game of telephone is unlikely to be better than simply using claude. I was also hoping gastown would amplify my intent to complete the task of "Add feature X" without early-stopping, but so far it's more work than both 1. Vibing with claude directly and 2. Creating a highly-detailed spec with checkboxes and piping in "do the next task" until it's done. Definitely looking forward to seeing how the tools in this space evolve. Eventually someone is bound to get it right! P.s. the choice of nomenclature throughout the article is a bit odd, making it hard to follow. Movie characters, dogs and raccoons, huh? How about striving for descriptive SWE clarity? reply nobodywillobsrv 5 hours ago | prev | next [–] It's nice to see someone else going mad, even deeper down the well. I don't known the details but I was wondering why people aren't "just" writing chat venues any commns protocols for the chats? So the fundamental unit is a chat that humans and agents can be a member of. You can also have DMs etc to avoid chattiness. But fundmantally if you start with this kind of madness you don't have a strict hierarchy and it might also be fun to see how it goes. I briefly started building this but just spun out and am stuck using PAL MCP for now and some dumb scripts. Not super content with any of it yet. reply mccoyb 10 hours ago | prev | next [–] There are no concepts in this blog post. It is the author's opinions in the form of a pseudo-Erlang program with probabilities. If one reads it like it is a program, you realize that the underlying core has been obfuscated by implementation details. I'm looking for "the Emacs" of whatever this is, and I haven't read a blog post which isolates the design yet. reply leftbehinds 7 hours ago | parent | next [–] excellent summary, thanks reply haburka 9 hours ago | prev | next [–] This is either a meme or the way everyone will code in 2 years, in both cases, it terrifies me. reply BoneShard 1 hour ago | parent | next [–] It's a sales pitch. Hype, sell it to faang for many billions. reply lifetimerubyist 3 hours ago | parent | prev | next [–] I was trying to be patient, hoping this entire thing would collapse sooner rather than later - but now I think I'm just going to start planning my exit from this industry forever. reply wffurr 1 hour ago | root | parent | next [–] Even if you do exit, all the software around you will steadily get worse and worse. Software engineering is already really bad, especially for consumer products, and all this vibe agent crud is only going to accelerate the badness. reply wiseowise 2 hours ago | root | parent | prev | next [–] Why would it collapse? reply ForHackernews 23 hours ago | prev | next [–] Naming your energy-guzzling "just throw more agents at it" thingamajig after a location in the post-apocalyptic Mad Max universe is certainly a choice. reply lostdog 1 hour ago | prev | next [–] There's a simpler design here begging to show itself. We're trying to orchestrate a horde of agents. The workers (polecats?) are the main problem solvers. Now you need a top level agent (mayor) to breakdown the problem and delegate work, and then a merger to resolve conflicts in the resulting code (refinery). Sometimes agents get stuck and need encouragement. The molecules stuff confused me, but I think they're just "policy docs," checklists to do common tasks. But this is baby stuff. Only one level of hierarchy? Show me a design for your VP agent and I'll be impressed for real. reply yowlingcat 1 hour ago | prev [–] Someone here has lost the plot and at this point I wonder if it is me. Is software supposed to be deterministic anymore? Are incremental steps expected to be upgrades and not regressions? Is stability of behavior and dependability desirable? Should we culturally reward striving to get more done with less. ...no, I haven't lost the plot. I'm seeing another fad of the intoxicated parting with their money bending a useful tool into a golden hammer of a caricature. I dread seeing the eventual wreckage and self-realization from the inevitable hangover. reply Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact Search: