My feedback: it seems like this tool isn't really like aws-nuke, but the copy keeps comparing it to aws-nuke, extending further into this HN post. aws-nuke doesn't need delete permissions (you just can't do the "delete" step, obviously), aws-nuke makes you decide what to delete, aws-nuke doesn't need confidence scoring since it shows you everything in the account, and aws-nuke is open source. From your list of key differences, the only one that aws-nuke doesn't already do is the one that doesn't make sense for aws-nuke. This is, IMO, a problem with your list and not with the app: there are differentiating things CleanCloud does that you can focus on instead.
IMO, don't mention aws-nuke at all. This isn't the same kind of product as aws-nuke, which is explicitly the "One-click cleanup workflows" category in your "Not designed for" box. Your tool is for accounts that I'm not trying to nuke. So why invite the comparison? These tools are not intended for the same use case.
Spitballing here, I'd think you would want to lean into the cost savings aspect of deleting orphaned resources. aws-nuke is about cleaning out disposable AWS accounts. CleanCloud is about cloud cost optimization on real production/staging accounts.
A final note: it seems like the name CleanCloud is already used by a laundry service provider. You still have time to pick a different name for which you can take the top Google spot.
Can you explain tmux's contribution here? I'm confused why this process wouldn't work just the same if CC directly executed the program rather than involving tmux. Are you just using tmux to trick the program under test into running its TUI instead of operating in a dumb-stdout mode?
I had a really hard time getting anything like that to work (you can't just read stdout and write stdin, because you're driving a terminal in raw mode), but it took like 3 sentences worth of Claude prompt to get Claude to use tmux to do this reliably.
I tell Claude code to use an existing tmux session to interact with eg a rails console, and it uses tmux send-keys and capture-pane for IO. It gets tripped up if a pager is invoked, but otherwise it works pretty well. Didn’t occur to me to tell it to take screenshots.
For Claude, it's enough to prompt "use tmux to test", that usually does the work out of the box. If colors are important I also add "use -e option with capture-pane to see colors". It just works. I used it regularly with Claude and my TUI. For other agents other than Claude I need to use a more specific set of instructions ("use send-keys, capture-pane and mouse control via tmux" etc.)
Since I have e2e tests, I only use the agent for: guiding it on how to write the e2e test ("use tmux to try the new UI and then write a test") or to evaluate its overall usability (fake user testing, before actual user testing): "use tmux to evaluate the feature X and compile a list of usability issues"
Also many CLIs act differently when invoked connected to a terminal (TUI/interactive) vs not. So you’d run into issues there where Claude could only test the non-interactive things.
"In essence" but terminals do stuff to render stdout that you do not want a LLM to have to replicate, I think. If your TUI does stuff in fullscreen or otherwise with a bunch of control codes, that is simple work for a terminal but potentially intractable for a LLM.
My website's contact form has a reCAPTCHA and it still gets spam sent through it (though vastly less). They pass the reCAPTCHA somehow. My contact form literally only emails me and they still do it.
Yeah those are pretty spendy. I know one comes with extra guaranteed bandwidth which is kind of handy if you’re sharing a small number of cache nodes among a lot of servers. But we were doing okay running r6 for cache, though my coworker who knew the ritual for migrating them did eventually get a little boost out of switching us to r7’s. The latency wasn’t great and I don’t think faster network cards would have helped that. There was already plenty of incentive for us to do per-request promise caching to avoid pulling the same keys multiple times in a request but that was necessary because the business model forced the architecture to tolerate nondeterminism. The cost per request was what eventually killed them (the economy dipped and customers ran to cheaper vendors), but I’ve never seen a company survive being stupid for as long as this place did.
I'm not sure any humans were behind the email at all (i.e. "do that yourself"). This seems to be some bizarre experiment where someone has strapped an LLM to an email client and let it go nuts. Even being optimistic, it's tough to see what good this was supposed to do for the world.
It’s a marketing gimmick. Whoever did it wanted to trade on the social currency of the tech-famous people they sent public shout-outs to, hoping it would drive clicks, engagement, and relevancy for the source account from which it originated, either as an elaborate form of karma farming, or just a way to drive followers and visibility.
It's also possible that the entire goal was nothing more complicated than stirring up shit for fun. By either metric it must have been a massive success judging by all the attention this is getting.
I've actually been following this project for a long time and it's none of the above. They're simply testing what a set of frontier models can do when given a goal and left to their own devices.
I agree this outcome is very painful to see and I really feel for Rob. It's clear people (myself included) are completely at breaking point with AI slop.
In this specific case though it's worth spending 30sec to read the website of AI model village to understand the experiment before claiming this was sent by Anthropic or assigning malicious intent.
This is the equivalent of releasing a poorly tested and validated self driving vehicle into general traffic. Of course nobody would ever do such a thing...
This hasn't mattered in 20 years for me personally, but in 2003 I killed connectivity to a bunch of Siemens 505-CP2572 PLC ethernet cards by switching a hub from 10Mbps to 100Mbps mode. The button was right there, and even back then I assumed there wouldn't be anything requiring 10Mbps any more. The computers were fine but the PLCs were not. These things are still in use in production manufacturing facilities out there.
I think OP is making two separate but related points, a general point and a specific point. Both involve guessing something that the error-handling code, on the spot, might not know.
1. When I personally see database timeouts at work it's rarely the database's fault, 99 times out of 100 it's the caller's fault for their crappy query; they should have looked at the query plan before deploying it. How is the error-handling code supposed to know? I log timeouts (that still fail after retry) as errors so someone looks at it and we get a stack trace leading me to the bad query. The database itself tracks timeout metrics but the log is much more immediately useful: it takes me straight to the scene of the crime. I think this is OP's primary point: in some cases, investigation is required to determine whether it's your service's fault or not, and the error-handling code doesn't have the information to know that.
2. As with exceptions vs. return values in code, the low-level code often doesn't know how the higher-level caller will classify a particular error. A low-level error may or may not be a high-level error; the low-level code can't know that, but the low-level code is the one doing the logging. The low-level logging might even be a third party library. This is particularly tricky when code reuse enters the picture: the same error might be "page the on-call immediately" level for one consumer, but "ignore, this is expected" for another consumer.
I think the more general point (that you should avoid logging errors for things that aren't your service's fault) stands. It's just tricky in some cases.
Google allows minified extensions and doesn't require you to provide the original unminified source. I've never provided Google the real source code to my extension and they rubber-stamp every release. The Chrome Web Store is the wild west--you're on your own.
Mozilla allows minification but you're required to provide the original buildable source. Mozilla actually looks at the code and they reject updates all the time.
IMO, don't mention aws-nuke at all. This isn't the same kind of product as aws-nuke, which is explicitly the "One-click cleanup workflows" category in your "Not designed for" box. Your tool is for accounts that I'm not trying to nuke. So why invite the comparison? These tools are not intended for the same use case.
Spitballing here, I'd think you would want to lean into the cost savings aspect of deleting orphaned resources. aws-nuke is about cleaning out disposable AWS accounts. CleanCloud is about cloud cost optimization on real production/staging accounts.
A final note: it seems like the name CleanCloud is already used by a laundry service provider. You still have time to pick a different name for which you can take the top Google spot.
reply