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.
aabajian 30 minutes ago [-]
That is the problem with software developers with expertise in software, but no deep domain knowledge outside the CS world.
tempest_ 7 minutes ago [-]
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.
nerdsniper 16 minutes ago [-]
I’m really enjoying these LLMs for making ad-hoc tooling / apps for myself. Things that I inly 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.
jrvarela56 18 minutes ago [-]
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’.
mindwok 21 minutes ago [-]
Speak for yourself. I’ve been using Claude Code to build lots of customer facing things.
aspectrr 2 hours ago [-]
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!
amanzi 11 minutes ago [-]
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.
redrove 60 minutes ago [-]
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?
jondwillis 35 minutes ago [-]
One allows middleman rent-seeking and the other does not so much.
levkk 26 minutes ago [-]
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.
hebejebelus 21 minutes ago [-]
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).
giancarlostoro 19 minutes ago [-]
In Zed I just have it auto approve everything, macOS will scream if "Zed" tries to escape the folder its in anyway.
hivacruz 19 minutes ago [-]
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.
levkk 37 seconds ago [-]
Him! That settles the Turing test debate.
hebejebelus 38 minutes ago [-]
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.
lfx 1 hours ago [-]
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.
esafak 16 minutes ago [-]
An infrastructure tool's primary installation method should NOT be curl | sh
baalimago 42 minutes ago [-]
It's pretty cool. What would be cooler is to have it as a MCP server... and then use claude code
ekaesmem 30 minutes ago [-]
Please at least write the README.md by yourself. It's excessively lengthy.
tobi_bsf 38 minutes ago [-]
Whats wrong with just using claude code for infrastructure? Works great tbh.
1 hours ago [-]
lijok 1 hours ago [-]
FUCK NO. Who in their right mind would let an LLM connect to prod?
qudat 11 minutes ago [-]
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.
xyzzy123 19 minutes ago [-]
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.
locusofself 53 minutes ago [-]
Maybe at a greenfield startup. Where I work this idea wouldn't be entertained for a millisecond.
jhickok 51 minutes ago [-]
why does it have to connect to prod in order to be useful?
Rendered at 20:50:21 GMT+0000 (Coordinated Universal Time) with Vercel.
Note: nothing against fluid.sh, I am struggling to figure out something to build.
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.
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’.
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!
What’s the differentiator?
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 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.
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.
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.