41–50 of 190 posts
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.
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.
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 Playbo…
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?
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.
That is the problem with software developers with expertise in software, but no deep domain knowledge outside the CS world.
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…
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…
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.
Earlier quoted context omitted.
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 prefe…
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.
But particularly for devops / systems focused work, you lose too much "test fidelity" if you're not integrating against real services / cloud.
Whats wrong with just using claude code for infrastructure? Works great tbh.
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.