All these tools to build something, but nothing to build. I feel like I am part of a Pyramid Scheme where every product is about building something else, but nothing reaches the end user.
Note: nothing against fluid.sh, I am struggling to figure out something to build.
One of my first professional coding jobs was in 2007 when Facebook first introduced 'Facebook Apps'. I worked for a startup making a facebook app, and EVERY SINGLE app company had the same monetization strategy: Selling ads for other facebook apps.
So the lifecycle of an app would be:
1) Create your game/quiz/whatever app.
2) Pay a successful app $x per install, and get a bunch of app installs.
3) Put all sorts of scammy "get extra in game perks if you refer your friends" to try to become viral.
4) Hope to become big enough that people start finding you without having to pay for ads.
5) Sell ads to other facebook app startups to generate installs for them.
It was a completely circular economy. There was not product or income source other than the next layer of the pyramid.
For problems that can be solved with only a small amount of simple code that is true. However software can become very complex and the larger/more complex the problem is the more important software developers are. It quickly becomes easier to teach software developers enough of your domain than to teach domain experts software.
In a complex project the hard parts about software are harder than the hard parts about the domain.
I've seen the type of code electrical engineers write (at least as hard a domain as software). They can write code, but it isn't good.
Every single time I try to get a domain expert at $job to let me learn more about the domain it goes goes nowhere.
My belief is that engineers should be the prime candidates to be learning the domain, because it can positively influence product development. There’s too many layers between engineers and the the domain IME
It is my experience that most of these business domain experts snore the moment you talk about anything related to the difficulties of creating software.
Yeah, I think the issue has more to do with the curiosity level of the participant rather than whether they are a business domain expert or a software engineering expert.
There’s a requisite curiosity necessary to cross the discomfort boundary into how the sausage is made.
Until a few months ago, domain experts who ciuldn't code would "make do" with some sort of Microsoft Excel Spreadsheet From Hell (MESFH), an unholy beast that would usually start small and then always grow up to become a shadow ERP (at best) or even the actual ERP (at worst).
The best part, of course, is that this mostly works, most of the time, for most busineses.
Now, the same domain experts -who still cannot code- will do the exact same thing, but AI will make the spreadsheet more stable (actual data modelling), more resilient (backup infra), more powerful (connect from/to anything), more ergonomic (actual views/UI), and generally more easy to iterate upon (constructive yet adversarial approach to conflicting change requests).
Programming is not something you can teach to people who are not interested in it in the first place. This is why campaigns like "Learn to code" are doomed to fail.
Whereas (good) programmers strive to understand the domain of whatever problem they're solving. They're comfortable with the unknown, and know how to ask the right questions and gather requirements. They might not become domain experts, but can certainly learn enough to write software within that domain.
Generative "AI" tools can now certainly help domain experts turn their requirements into software without learning how to program, but the tech is not there yet to make them entirely self-sufficient.
So we'll continue to need both roles collaborating as they always have for quite a while still.
I’ve been a year deep into my first job out of tech. There is a never ending slew of problems where being able to code, specially now with AI, means you have wizard-like powers to help your coworkers.
My codebase is full of one-offs that slowly but surely converge towards cohesive/well-defined/reusable capabilities based on ‘real’ needs.
I’m now starting to pitch consulting to a niche to see what sticks. If the dynamic from the office holds (as I help them, capabilities compound) then I’ll eventually find something to call ‘a product’.
Maybe have it build some toy apps just for fun! My wife and I were talking once about typing speed and challenged each other to a typing competition. the existing ones I found weren't very good and were riddled with ads, so I had Claude build one for us to use.
Or maybe ask yourself what do you like to do outside of work? maybe build an app or claude skill to help with that.
If you like to cook, maybe try building a recipe manager for yourself. I set up a repo to store all of my recipes in cooklang (similar to markdown), and set up claude skills to find/create/evaluate new recipes.
Building the toy apps might help you come up with ideas for larger things too.
I’m really enjoying these LLMs for making ad-hoc tooling / apps for myself. Things that I only need for a day or a week, that don’t need to work perfectly (I can work around bugs).
It’s really liberating. Instead of saying “gosh I wish there was an app that…” I just make the app and use it and move on.
I find myself building fun tools for myself and things that help with quality of life slightly, but I don’t need all this extra enterprise stuff for that. I actually find myself more likely to use something I built because I am proud of it, even if there is already something on the market that addresses my need.
Someone on HN pointed out how all the LLM companies are basically going “we made this thing, can y'all please find the billion dollar application for it?” and that really made a lot of things - namely why I’m frequently raising an eyebrow at these tools and the vague promises/demand that we use them - click into place.
Don’t get me wrong, I have found uses for various AI tools. But nothing consistent and daily yet, aside from AI audio repair tools and that’s not really the same thing.
Side note, been watching gold prospecting channels lately, there will be these dig sites/claims people go to, they'll do their thing, dig a hole, run it through some angled ramp water contraption... they get like nothing, it's the experience I suppose. But I was wondering what the owner gets from all these people showing up.
There are companies making a lot of money directly from software largely written by LLMs especially since Claude Code was released, but they aren't mentioning LLMs or AI in any marketing, client communications, or public releases. I'm at least very aware that we need to be able to retire before LLMs swamp or obsolete our niche, and don't want to invite competition.
Outside of tech companies, I think this is extremely common.
This type of software is mainly created to gain brand recognition, influence, or valuation, not to solve problems for humans. Its value is indirect and speculative.
These are the pets.com of the current bubble, and we'll be flooded by them before the damn thing finally pops.
Hey HN,
My name is Collin and I'm working on fluid.sh (https://fluid.sh) the Claude Code for Infrastructure.
What does that mean?
Fluid is a terminal agent that do work on production infrastructure like VMs/K8s cluster/etc. by making sandbox clones of the infrastructure for AI agents to work on, allowing the agents to run commands, test connections, edit files, and then generate Infra-as-code like an Ansible Playbook to be applied on production.
Why not just use an LLM to generate IaC?
LLMs are great at generating Terraform, OpenTofu, Ansible, etc. but bad at guessing how production systems work. By giving access to a clone of the infrastructure, agents can explore, run commands, test things before writing the IaC, giving them better context and a place to test ideas and changes before deploying.
I got the idea after seeing how much Claude Code has helped me work on code, I thought "I wish there was something like that for infrastructure", and here we are.
Why not just provide tools, skills, MCP server to Claude Code?
Mainly safety. I didn't want CC to SSH into a prod machine from where it is running locally (real problem!). I wanted to lock down the tools it can run to be only on sandboxes while also giving it autonomy to create sandboxes and not have access to anything else.
Fluid gives access to a live output of commands run (it's pretty cool) and does this by ephemeral SSH Certificates. Fluid gives tools for creating IaC and requires human approval for creating sandboxes on hosts with low memory/CPU and for accessing the internet or installing packages.
I greatly appreciate any feedback or thoughts you have, and I hope you get the chance to try out Fluid!
Why would you not put a description like this on your actual website? Your homepage does not explain anything about what this actually does. Are you really expecting infrastructure engineers to install your app with a bash command after only providing the following information?
Claude Code for infrastructure. Debug, act, and audit everything Fluid does on your infrastructure.
Create sandboxes from VMs, investigate, plan, execute, generate Ansible playbooks, and audit everything.
This is exciting. But I had to read and check everything twice to figure it out, as some already commented. Strong Feedback loop is an ultimate unlock for AI agents and having twins is exactly the right approach.
This allows the agent to make any changes in a production clone vs agents running on a production VM. For example, you wouldn't want claude editing crucial config on the chance it brings everything down vs letting it do in a cloned environment where it can test whatever.
> I didn't want CC to SSH into a prod machine from where it is running locally (real problem!). I wanted to lock down the tools it can run to be only on sandboxes while also giving it autonomy to create sandboxes and not have access to anything else.
This is already the modern way to run infra. If your running simple apps, why are you even spinning up vms? Container running platforms make this so easy.
I've noticed a lot of LLM-based tools that are essentially this sort of thing. Just a slightly more specific prompt wrapper around the core capability that can already do the thing. It's so bad.
Lol, that does sounds a little scary but if it works it works. Mainly I built this to prevent there being a chance that changes affect production. This is meant to be used with scale (say hundreds of VMs) vs 1. From a safety perspective running Claude Code with just a watchful eye would not fly in my environment, which is why I built something like this.
Yeah. The times I have let claude off the read-only leash, it's gone fine for me too (with stern warnings not to do anything stupid, and a close eye). But that's not really solving the same problem as this project, I guess. From what I can see this is using a safer and more reproducible method (and not k8s native, so it feels a little foreign to me).
I do the same. I was thinking about creating read-only kubeconfigs for him to make sure it can't do bad stuff but with a good SKILL.md, it works perfectly.
Clever solution. I think ops (like this) and observability will be pretty hot markets for a while soon. The code is quite cheap now, but actually running it and keeping it running still requires some amount of background. I've had a number of acquaintances ask me how they can get their vibe coded app available for others to use.
I really like this idea. I do a lot of kubernetes ops with workloads I'm unfamiliar with (and not directly responsible for) and often give claude read access in order to help me debug things, including with things like a grafana skill in order to access the same monitoring tools humans have. It's saved me dozens of hours in the last months - and my job is significantly less frustrating now.
Your method of creating ansible playbooks makes _tons_ of sense for this kind of work. I typically create documentation (with claude) for things after I've worked through them (with claude) but playbooks is a very, very clever move.
I would say something similar but as an auditable, controllable kubernetes operator would be pretty welcome.
The real problem is just the volatility for the employees. Unless Board of Directors/Owners punish downtime, you risk a dark pattern of uptime just being a nice-to-have when I can just replace any expertise with the next kid out of college + Claude.
So you really need customers to react. And this isn't theoretical - people have already lost their jobs and there's really, really good people in the market available right now.
I'm already using LLM to generate things and I'm not sure what this adds. The Demo isn't really doing it for me but maybe I'm wrong target for it. (What is running on that server? You don't know. Build your cattle properly!)
Maybe this is better for one man band devs trying to get something running without caring beyond, it's running.
But fluid lets AI investigate, explore, run commands, and edit files in a production-cloned sandbox. LLMs are great at writing IaC, but the LLMs won't get the right context from just generating an Ansible Playbook. They need a place to run commands safely and test changes before writing the IaC. Much like a human, hence the sandbox.
- The website tells less than your comment here. I want to try but have no idea how destructive it can be.
- You need to add / mention how to do things in the RO mode only.
- Always explain destructive actions.
Few weeks ago I had to debug K8S on the GCP GDC metal, Claude Code helped me tons, but... I had to recreate whole cluster next day because agent ran too fast deleted things it should not delete or at least tell me the full impact. So some harness would be nice.
Hey! Yes I updated the website with some more of my comments.
- RO mode would be a good idea
- Agreed on explaining destructive actions. The only (possibly) destructive action is creating the sanbox on the host, but that asks the user's permission if the host doesn't have enough resources. Right now it supports VMs with KVM. It will not let you create a sandbox if the host doesn't have enough ram or cpus.
- The kubernetes example is exactly what this is built for, giving AI access is dangerous but there is always a chance of it messing something. Thanks for the comment!
This lets AI work on cloned production sandboxes vs running on production instances. Yes you can sandbox Claude Code on a production box, but it cannot test changes like it would for production-breaking changes. Sandboxes give AI this flexibility allowing it to safely test changes and reproduce things via IaC like Ansible playbooks.
It should be. This is the least friction way to do so as server Linux operating systems still have not agreed on a common application format / package manager.
> It should be. This is the least friction way to do so as server Linux operating systems still have not agreed on a common application format / package manager.
Nowhere in your response did you mention security.
Many places have "dev", "test" "prod"... but IMHO you need "sandpit" as well.
From an ops point of view as orgs get big enough, dev wraps around to being prod-like... in the sense that it has the property that there's going to be a lot of annoyed people whose time you're wasting if you break things.
You can take the approach of having more guard rails and controls to stop people breaking things but personally I prefer the "sandpit" approach, where you have accounts / environments where anything goes. Like, if anyone is allowed to complain it's broken, it's not sandpit anymore. That makes them an ok place to let agents loose for "whole system" work.
I see tools like this as a sort of alternative / workaround.
Sandpit should be a personal (often local, if possible) dev environment. The reason people get mad about dev being broken for long periods of time is that they cannot use dev to test their changes if your code (that they depend on) is broken in dev for long periods of time.
Hey, I get it. I don't want LLMs on prod at all. I made this to let agents connect to production cloned sandboxes, not production itself. I hope this helps your concerns, but I understand either way. Lmk with any other questions.
All these tools to build something, but nothing to build. I feel like I am part of a Pyramid Scheme where every product is about building something else, but nothing reaches the end user.
Note: nothing against fluid.sh, I am struggling to figure out something to build.
One of my first professional coding jobs was in 2007 when Facebook first introduced 'Facebook Apps'. I worked for a startup making a facebook app, and EVERY SINGLE app company had the same monetization strategy: Selling ads for other facebook apps.
So the lifecycle of an app would be:
1) Create your game/quiz/whatever app.
2) Pay a successful app $x per install, and get a bunch of app installs.
3) Put all sorts of scammy "get extra in game perks if you refer your friends" to try to become viral.
4) Hope to become big enough that people start finding you without having to pay for ads.
5) Sell ads to other facebook app startups to generate installs for them.
It was a completely circular economy. There was not product or income source other than the next layer of the pyramid.
It didn't last long.
That is the problem with software developers with expertise in software, but no deep domain knowledge outside the CS world.
It is my belief with some exceptions it is almost always easier to teach a domain expert to code than it is to teach a software developer the domain.
In practice, does that happen? Usually companies try to bring the best of both and build from there.
For problems that can be solved with only a small amount of simple code that is true. However software can become very complex and the larger/more complex the problem is the more important software developers are. It quickly becomes easier to teach software developers enough of your domain than to teach domain experts software.
In a complex project the hard parts about software are harder than the hard parts about the domain.
I've seen the type of code electrical engineers write (at least as hard a domain as software). They can write code, but it isn't good.
Every single time I try to get a domain expert at $job to let me learn more about the domain it goes goes nowhere.
My belief is that engineers should be the prime candidates to be learning the domain, because it can positively influence product development. There’s too many layers between engineers and the the domain IME
It is my experience that most of these business domain experts snore the moment you talk about anything related to the difficulties of creating software.
Yeah, I think the issue has more to do with the curiosity level of the participant rather than whether they are a business domain expert or a software engineering expert.
There’s a requisite curiosity necessary to cross the discomfort boundary into how the sausage is made.
Until a few months ago, domain experts who ciuldn't code would "make do" with some sort of Microsoft Excel Spreadsheet From Hell (MESFH), an unholy beast that would usually start small and then always grow up to become a shadow ERP (at best) or even the actual ERP (at worst).
The best part, of course, is that this mostly works, most of the time, for most busineses.
Now, the same domain experts -who still cannot code- will do the exact same thing, but AI will make the spreadsheet more stable (actual data modelling), more resilient (backup infra), more powerful (connect from/to anything), more ergonomic (actual views/UI), and generally more easy to iterate upon (constructive yet adversarial approach to conflicting change requests).
> AI will make the spreadsheet more stable
Hallucinations sure make spreadsheets nice and stable.
That doesn't track at all IME.
Programming is not something you can teach to people who are not interested in it in the first place. This is why campaigns like "Learn to code" are doomed to fail.
Whereas (good) programmers strive to understand the domain of whatever problem they're solving. They're comfortable with the unknown, and know how to ask the right questions and gather requirements. They might not become domain experts, but can certainly learn enough to write software within that domain.
Generative "AI" tools can now certainly help domain experts turn their requirements into software without learning how to program, but the tech is not there yet to make them entirely self-sufficient.
So we'll continue to need both roles collaborating as they always have for quite a while still.
It's way easier to raise for dev tools than domain tools right now.
I want to make a business, but what is the business
Pretty much. I’m working on a few things with several people and I’m now constrained by their ability to find stuff to build.
I’ve been a year deep into my first job out of tech. There is a never ending slew of problems where being able to code, specially now with AI, means you have wizard-like powers to help your coworkers.
My codebase is full of one-offs that slowly but surely converge towards cohesive/well-defined/reusable capabilities based on ‘real’ needs.
I’m now starting to pitch consulting to a niche to see what sticks. If the dynamic from the office holds (as I help them, capabilities compound) then I’ll eventually find something to call ‘a product’.
Can I ask what do you do now?
Talk to people.
There are an infinite amount of problems to solve.
Deciding whether they’re worth solving is the hard part.
Maybe have it build some toy apps just for fun! My wife and I were talking once about typing speed and challenged each other to a typing competition. the existing ones I found weren't very good and were riddled with ads, so I had Claude build one for us to use.
Or maybe ask yourself what do you like to do outside of work? maybe build an app or claude skill to help with that.
If you like to cook, maybe try building a recipe manager for yourself. I set up a repo to store all of my recipes in cooklang (similar to markdown), and set up claude skills to find/create/evaluate new recipes.
Building the toy apps might help you come up with ideas for larger things too.
I’m really enjoying these LLMs for making ad-hoc tooling / apps for myself. Things that I only need for a day or a week, that don’t need to work perfectly (I can work around bugs).
It’s really liberating. Instead of saying “gosh I wish there was an app that…” I just make the app and use it and move on.
I find myself building fun tools for myself and things that help with quality of life slightly, but I don’t need all this extra enterprise stuff for that. I actually find myself more likely to use something I built because I am proud of it, even if there is already something on the market that addresses my need.
When there’s a gold rush, sell shovels.
Someone on HN pointed out how all the LLM companies are basically going “we made this thing, can y'all please find the billion dollar application for it?” and that really made a lot of things - namely why I’m frequently raising an eyebrow at these tools and the vague promises/demand that we use them - click into place.
Don’t get me wrong, I have found uses for various AI tools. But nothing consistent and daily yet, aside from AI audio repair tools and that’s not really the same thing.
Speak for yourself. I’ve been using Claude Code to build lots of customer facing things.
building is the easy bit, more than ever.
selling it is the hard part, nothing new there
Another option is to bring your coding skills to a industry not particularly known for using tech.
Sell the shovels!!
Side note, been watching gold prospecting channels lately, there will be these dig sites/claims people go to, they'll do their thing, dig a hole, run it through some angled ramp water contraption... they get like nothing, it's the experience I suppose. But I was wondering what the owner gets from all these people showing up.
They'll work for hours and end up with $4 of gold
There are companies making a lot of money directly from software largely written by LLMs especially since Claude Code was released, but they aren't mentioning LLMs or AI in any marketing, client communications, or public releases. I'm at least very aware that we need to be able to retire before LLMs swamp or obsolete our niche, and don't want to invite competition.
Outside of tech companies, I think this is extremely common.
This type of software is mainly created to gain brand recognition, influence, or valuation, not to solve problems for humans. Its value is indirect and speculative.
These are the pets.com of the current bubble, and we'll be flooded by them before the damn thing finally pops.
Hey HN, My name is Collin and I'm working on fluid.sh (https://fluid.sh) the Claude Code for Infrastructure.
What does that mean?
Fluid is a terminal agent that do work on production infrastructure like VMs/K8s cluster/etc. by making sandbox clones of the infrastructure for AI agents to work on, allowing the agents to run commands, test connections, edit files, and then generate Infra-as-code like an Ansible Playbook to be applied on production.
Why not just use an LLM to generate IaC?
LLMs are great at generating Terraform, OpenTofu, Ansible, etc. but bad at guessing how production systems work. By giving access to a clone of the infrastructure, agents can explore, run commands, test things before writing the IaC, giving them better context and a place to test ideas and changes before deploying.
I got the idea after seeing how much Claude Code has helped me work on code, I thought "I wish there was something like that for infrastructure", and here we are.
Why not just provide tools, skills, MCP server to Claude Code?
Mainly safety. I didn't want CC to SSH into a prod machine from where it is running locally (real problem!). I wanted to lock down the tools it can run to be only on sandboxes while also giving it autonomy to create sandboxes and not have access to anything else.
Fluid gives access to a live output of commands run (it's pretty cool) and does this by ephemeral SSH Certificates. Fluid gives tools for creating IaC and requires human approval for creating sandboxes on hosts with low memory/CPU and for accessing the internet or installing packages.
I greatly appreciate any feedback or thoughts you have, and I hope you get the chance to try out Fluid!
Why would you not put a description like this on your actual website? Your homepage does not explain anything about what this actually does. Are you really expecting infrastructure engineers to install your app with a bash command after only providing the following information?
True. Tried to make it simpler but clearly not a good enough job!
This is exciting. But I had to read and check everything twice to figure it out, as some already commented. Strong Feedback loop is an ultimate unlock for AI agents and having twins is exactly the right approach.
YOOO thanks niko! Currently reworking lots of wording to make it easier to understand!
So how is this different from deploying claude code on a VM and letting it run? You can sandbox it in any of the dozen ways already available.
What’s the differentiator?
This allows the agent to make any changes in a production clone vs agents running on a production VM. For example, you wouldn't want claude editing crucial config on the chance it brings everything down vs letting it do in a cloned environment where it can test whatever.
One allows middleman rent-seeking and the other does not so much.
> I didn't want CC to SSH into a prod machine from where it is running locally (real problem!). I wanted to lock down the tools it can run to be only on sandboxes while also giving it autonomy to create sandboxes and not have access to anything else.
This is already the modern way to run infra. If your running simple apps, why are you even spinning up vms? Container running platforms make this so easy.
So... I already tell Claude Code to do this. Just run kubectl for me please and figure out why my helm chart is broken.
Scary? A little but it's doing great. Not entirely sure why a specialized tool is needed when the general purpose CLI is working.
I've noticed a lot of LLM-based tools that are essentially this sort of thing. Just a slightly more specific prompt wrapper around the core capability that can already do the thing. It's so bad.
Lol, that does sounds a little scary but if it works it works. Mainly I built this to prevent there being a chance that changes affect production. This is meant to be used with scale (say hundreds of VMs) vs 1. From a safety perspective running Claude Code with just a watchful eye would not fly in my environment, which is why I built something like this.
Yeah. The times I have let claude off the read-only leash, it's gone fine for me too (with stern warnings not to do anything stupid, and a close eye). But that's not really solving the same problem as this project, I guess. From what I can see this is using a safer and more reproducible method (and not k8s native, so it feels a little foreign to me).
In Zed I just have it auto approve everything, macOS will scream if "Zed" tries to escape the folder its in anyway.
I let it read-only and gitops driven and find it's really good and feels pretty safe to get it to PR fixes. Run it with no permission checks
Yeah, I'm telling it to use aws cli to spin up instances, configure them, start servers, read cw logs etc.
I do the same. I was thinking about creating read-only kubeconfigs for him to make sure it can't do bad stuff but with a good SKILL.md, it works perfectly.
Him! That settles the Turing test debate.
Clever solution. I think ops (like this) and observability will be pretty hot markets for a while soon. The code is quite cheap now, but actually running it and keeping it running still requires some amount of background. I've had a number of acquaintances ask me how they can get their vibe coded app available for others to use.
I really like this idea. I do a lot of kubernetes ops with workloads I'm unfamiliar with (and not directly responsible for) and often give claude read access in order to help me debug things, including with things like a grafana skill in order to access the same monitoring tools humans have. It's saved me dozens of hours in the last months - and my job is significantly less frustrating now.
Your method of creating ansible playbooks makes _tons_ of sense for this kind of work. I typically create documentation (with claude) for things after I've worked through them (with claude) but playbooks is a very, very clever move.
I would say something similar but as an auditable, controllable kubernetes operator would be pretty welcome.
The real problem is just the volatility for the employees. Unless Board of Directors/Owners punish downtime, you risk a dark pattern of uptime just being a nice-to-have when I can just replace any expertise with the next kid out of college + Claude.
So you really need customers to react. And this isn't theoretical - people have already lost their jobs and there's really, really good people in the market available right now.
Thanks! Kubernetes is the next infrastructure primitive that I want to support but I'm glad you like. If you have any questions or ideas, lmk!
Ops person here.
I'm already using LLM to generate things and I'm not sure what this adds. The Demo isn't really doing it for me but maybe I'm wrong target for it. (What is running on that server? You don't know. Build your cattle properly!)
Maybe this is better for one man band devs trying to get something running without caring beyond, it's running.
Hey no problem! I'll work on the demo more. I discuss this in my comment here: https://news.ycombinator.com/reply?id=46889704&goto=item%3Fi...
and on the website: https://fluid.sh
But fluid lets AI investigate, explore, run commands, and edit files in a production-cloned sandbox. LLMs are great at writing IaC, but the LLMs won't get the right context from just generating an Ansible Playbook. They need a place to run commands safely and test changes before writing the IaC. Much like a human, hence the sandbox.
Hey Collin!
Interesting idea, few things:
- The website tells less than your comment here. I want to try but have no idea how destructive it can be.
- You need to add / mention how to do things in the RO mode only.
- Always explain destructive actions.
Few weeks ago I had to debug K8S on the GCP GDC metal, Claude Code helped me tons, but... I had to recreate whole cluster next day because agent ran too fast deleted things it should not delete or at least tell me the full impact. So some harness would be nice.
Hey! Yes I updated the website with some more of my comments. - RO mode would be a good idea - Agreed on explaining destructive actions. The only (possibly) destructive action is creating the sanbox on the host, but that asks the user's permission if the host doesn't have enough resources. Right now it supports VMs with KVM. It will not let you create a sandbox if the host doesn't have enough ram or cpus.
- The kubernetes example is exactly what this is built for, giving AI access is dangerous but there is always a chance of it messing something. Thanks for the comment!
agreed, the repo readme is far more informative than the website
Isn't Claude Code for Infrastructure just...Claude Code?
Hey, thanks for the comment. I answer this question in more depth on the website https://fluid.sh or this comment: https://news.ycombinator.com/reply?id=46889704&goto=item%3Fi...
This lets AI work on cloned production sandboxes vs running on production instances. Yes you can sandbox Claude Code on a production box, but it cannot test changes like it would for production-breaking changes. Sandboxes give AI this flexibility allowing it to safely test changes and reproduce things via IaC like Ansible playbooks.
It's pretty cool. What would be cooler is to have it as a MCP server... and then use claude code
Can't we just use Claude Code straight up?
Please at least write the README.md by yourself. It's excessively lengthy.
Whats wrong with just using claude code for infrastructure? Works great tbh.
I wish, for my work it would be a safety nightmare. I left a comment on this topic. https://news.ycombinator.com/reply?id=46889704&goto=item%3Fi...
An infrastructure tool's primary installation method should NOT be curl | sh
It should be. This is the least friction way to do so as server Linux operating systems still have not agreed on a common application format / package manager.
> It should be. This is the least friction way to do so as server Linux operating systems still have not agreed on a common application format / package manager.
Nowhere in your response did you mention security.
FUCK NO. Who in their right mind would let an LLM connect to prod?
Many places have "dev", "test" "prod"... but IMHO you need "sandpit" as well.
From an ops point of view as orgs get big enough, dev wraps around to being prod-like... in the sense that it has the property that there's going to be a lot of annoyed people whose time you're wasting if you break things.
You can take the approach of having more guard rails and controls to stop people breaking things but personally I prefer the "sandpit" approach, where you have accounts / environments where anything goes. Like, if anyone is allowed to complain it's broken, it's not sandpit anymore. That makes them an ok place to let agents loose for "whole system" work.
I see tools like this as a sort of alternative / workaround.
Sandpit should be a personal (often local, if possible) dev environment. The reason people get mad about dev being broken for long periods of time is that they cannot use dev to test their changes if your code (that they depend on) is broken in dev for long periods of time.
Agreed on all points. Local loops are faster and safer wherever possible.
But particularly for devops / systems focused work, you lose too much "test fidelity" if you're not integrating against real services / cloud.
Maybe at a greenfield startup. Where I work this idea wouldn't be entertained for a millisecond.
Hey, I get it. I don't want LLMs on prod at all. I made this to let agents connect to production cloned sandboxes, not production itself. I hope this helps your concerns, but I understand either way. Lmk with any other questions.
I think you would be very surprised at a) how useful it would be and b) how lax prod can be depending on the company culture and stakes.
why does it have to connect to prod in order to be useful?