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.
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’.
I am in the same boat but I recently found I could also use these tool so reverse engineer stuff as well. For example I purchased this label printer from china and was unsatisfied with the printing quality under Linux. So I "coded" a go script to print via BLE instead of CUPS [1]. To do this I de-compiled the android app that comes with the printer and instead of spending hours going through it I just told an Agentic AI to do this for me.
I am now so deep into the rabbit hole that I have made a version that runs entirely in the browser and an ESP32 version. I have now also taken the printer apart to find that the built in BLE is an external module and I could interface directly with the printer by replacing it with my own custom PCB...
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.
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.
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.
In macroeconomic, you have an aggregate production functions that represents output for a country or something. In many of these function you'll have a parameter for technology, it acts as a multiplier over inputs, so the greater the measure of technology the greater the output. Quite a few of these also exhibt a characteristic where output drops if technology increases too fast. To illustrate this, imagine a scenario in real life that kind of looks like a rapid evolution of some kind of technology of home phones, to cell phones, to smart phones at a rate faster than people know how to make use of them, while also spending money adoption making the intermediary adoptions quite wasteful.
I think we see an aspect of this here, a lot of things we took for granted are changing, shared assumptions are being challenged and it's a period we're all relearning new things. To some extent spending too much time diving on the current iteration of AI tooling might be for nothing if gets invalidated by another sudden jump.
With all these new tools people are building, I can't help but feel they are building foundations on moving soil.
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.
If infirmation arbitrage is the game then it's now a race to distribution channels and trust.
Also what does society need? Smart workers and people who believe in the system... so where does that leave us? We need to make something that would better enable children to want to grow up in the world and participate. Otherwise were doing nothing of value and in a death spiral
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.
Everybody wants to build infra. Automate something which is known and well understood. Hoping someone else will use it to solve end user's problem which is hard to understand, messy and often highly contextual.
To summarize: Everyone wants to automate stuff. Most people do not want to touch boring, large problems.
This is not even AI - it's pre-AI, and everyone has continued to try to create things that other people can use as a dependency, just on a much higher pace.
I've found writing simulations that my childhood brain would have LOVED to see run fun and fulfilling.
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.
> 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.
And you thought the costs for burning tokens was high... let's amp it up by spinning up a bunch of cloud infra and let the agents fumble about.
DevOps is my gig, I use agents extensively, I would never do this. This is so wasteful
An agent that runs things in remote sandboxes to set things up doesn’t really fit with Infrastructure as Code.
Lately I have been setting up Pulumi stacks in ephemeral AWS accounts managed by AWS Organizations and working on a Kubernetes cluster locally with Tilt. So far, Claude is pretty good with those things. It seems to have pretty good knowledge of Pulumi, basic knowledge of Tilt, and good knowledge of Kubernetes. It’s a little out of date on some things and needs reminding to RTFM, but it can get a lot done by itself. If it were a real point of friction, a cheat sheet (sorry, “skill”) would be enough to solve the majority of issues.
The example you provide seems to be more along the lines of SSHing into remote boxes and setting things up manually. That’s not really helpful when you want to work on repeatable infra. You try to distinguish yourself from generating Terraform etc., but actually that’s what’s valuable in my experience.
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.
Making clones of production isn't trivial. Is your app server clone going to connect to your production database? It is going to spin up your whole stack? Seems a bit naive.
A better approach is to have AI understand how prod is built and make the changes there instead of having AI inspect it and figure out how to apply one off changes.
First I’m personally never going to create infrastructure in the console. I’m going to use IAC from the get go. That means I can reproduce my infra on another account easily.
Second if I did come across an environment where this was already the case, there are tools for both Terraform and CloudFormation where you can reverse your infra to reproducible IAC.
After that, let Claude go wild in my sandbox account with a reasonably scoped IAM role with temporary credentials
- 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.
> LLMs are great at generating Terraform, OpenTofu, Ansible, etc. but bad at guessing how production systems work.
Sorry, that last part is absolutely not the case from my experience. IaC also uses the API to inquire about the infrastructure, and there are existing import/export tools around it, so I’m not exactly sure what you are gaining by insisting on abandoning it. IaC also has the benefit of being reusable and commitable.
So this is a client/server thing to control KVM via libvert and provision SSH keys to allow LLM agent access to the VMs?
How does the Ansible export work? Do the agents hack around inside the VM and then write a playbook from memory, or are all changes made via Ansible?
If Ansible playbooks are the artifact, what does features does Fluid offer over just having agents iterate on an Ansible codebase and having Ansible drive provisioning?
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.
I use Pulumi for work, and their AI solution (Pulumi Neo) works amazingly well in troubleshooting cloud issues. It's informed of the cloud state and recent changes right from their platform, which is pretty amazing. Compared to using Azure CoPilot for the same purposes, Pulumi Neo was faster in generating responses, and these responses were actionable and solved my issues. CoPilot was laughably useless comparably.
This general idea is exactly why I love nix. The immutability of it is powerful. It can be useful for both running your agents in a certain environment AND your agents are useful at writing your nix config. I expand on this in a blog post here https://jamesst.one/posts/agents-nix
This is really cool, I don't want to think about infra tbh just want to build. Is there a wold where an on-prem version of this exists? I buy a box, install shell script, and it just works?
Great idea! A few weeks ago a non-technical client of mine decided to optimize his AWS infra bill with the help of AI. The costs went down significantly along with the application.
[+] [-] falloutx|1 month ago|reply
Note: nothing against fluid.sh, I am struggling to figure out something to build.
[+] [-] cortesoft|1 month ago|reply
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.
[+] [-] aabajian|1 month ago|reply
[+] [-] jrvarela56|1 month ago|reply
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’.
[+] [-] sschueller|1 month ago|reply
I am now so deep into the rabbit hole that I have made a version that runs entirely in the browser and an ESP32 version. I have now also taken the printer apart to find that the built in BLE is an external module and I could interface directly with the printer by replacing it with my own custom PCB...
[1] https://sschueller.github.io/posts/making-a-label-printer-wo...
[+] [-] mierz00|1 month ago|reply
There are an infinite amount of problems to solve.
Deciding whether they’re worth solving is the hard part.
[+] [-] nerdsniper|1 month ago|reply
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.
[+] [-] headcanon|1 month ago|reply
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.
[+] [-] Forgeties79|1 month ago|reply
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.
[+] [-] akst|1 month ago|reply
I think we see an aspect of this here, a lot of things we took for granted are changing, shared assumptions are being challenged and it's a period we're all relearning new things. To some extent spending too much time diving on the current iteration of AI tooling might be for nothing if gets invalidated by another sudden jump.
With all these new tools people are building, I can't help but feel they are building foundations on moving soil.
[+] [-] berkanunal|1 month ago|reply
https://substack-post-media.s3.amazonaws.com/public/images/6...
[+] [-] closewith|1 month ago|reply
Outside of tech companies, I think this is extremely common.
[+] [-] whattheheckheck|1 month ago|reply
Also what does society need? Smart workers and people who believe in the system... so where does that leave us? We need to make something that would better enable children to want to grow up in the world and participate. Otherwise were doing nothing of value and in a death spiral
[+] [-] unknown|1 month ago|reply
[deleted]
[+] [-] mym1990|1 month ago|reply
[+] [-] abhisek|1 month ago|reply
To summarize: Everyone wants to automate stuff. Most people do not want to touch boring, large problems.
[+] [-] greymalik|1 month ago|reply
[+] [-] Aperocky|1 month ago|reply
This is not even AI - it's pre-AI, and everyone has continued to try to create things that other people can use as a dependency, just on a much higher pace.
I've found writing simulations that my childhood brain would have LOVED to see run fun and fulfilling.
[+] [-] thewhitetulip|1 month ago|reply
AI is a product in search of a killer feature
First AGI was anyday going to come. Gpt5 had showed intelligence apparently
Then got started adult chat with paying customers
[+] [-] agumonkey|1 month ago|reply
[+] [-] hmokiguess|1 month ago|reply
[+] [-] aspectrr|1 month ago|reply
[+] [-] fnord77|1 month ago|reply
[+] [-] dubeye|1 month ago|reply
selling it is the hard part, nothing new there
[+] [-] zurtri|1 month ago|reply
[+] [-] imiric|1 month ago|reply
These are the pets.com of the current bubble, and we'll be flooded by them before the damn thing finally pops.
[+] [-] mindwok|1 month ago|reply
[+] [-] baby|1 month ago|reply
[+] [-] aspectrr|1 month ago|reply
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|1 month ago|reply
[+] [-] verdverm|1 month ago|reply
And you thought the costs for burning tokens was high... let's amp it up by spinning up a bunch of cloud infra and let the agents fumble about.
DevOps is my gig, I use agents extensively, I would never do this. This is so wasteful
[+] [-] JimDabell|1 month ago|reply
Lately I have been setting up Pulumi stacks in ephemeral AWS accounts managed by AWS Organizations and working on a Kubernetes cluster locally with Tilt. So far, Claude is pretty good with those things. It seems to have pretty good knowledge of Pulumi, basic knowledge of Tilt, and good knowledge of Kubernetes. It’s a little out of date on some things and needs reminding to RTFM, but it can get a lot done by itself. If it were a real point of friction, a cheat sheet (sorry, “skill”) would be enough to solve the majority of issues.
The example you provide seems to be more along the lines of SSHing into remote boxes and setting things up manually. That’s not really helpful when you want to work on repeatable infra. You try to distinguish yourself from generating Terraform etc., but actually that’s what’s valuable in my experience.
[+] [-] gardnr|1 month ago|reply
> Safety. I didn't want CC to SSH into a prod machine
The call to action:
> curl -fsSL https://fluid.sh/install.sh | bash
The reason this is ironic: https://x.com/sheeki03/status/2018382483465867444
[+] [-] levkk|1 month ago|reply
Scary? A little but it's doing great. Not entirely sure why a specialized tool is needed when the general purpose CLI is working.
[+] [-] redfloatplane|1 month ago|reply
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.
[+] [-] turtlebits|1 month ago|reply
A better approach is to have AI understand how prod is built and make the changes there instead of having AI inspect it and figure out how to apply one off changes.
Models are already very good at writing IaaC.
[+] [-] keyle|1 month ago|reply
[+] [-] raw_anon_1111|1 month ago|reply
First I’m personally never going to create infrastructure in the console. I’m going to use IAC from the get go. That means I can reproduce my infra on another account easily.
Second if I did come across an environment where this was already the case, there are tools for both Terraform and CloudFormation where you can reverse your infra to reproducible IAC.
After that, let Claude go wild in my sandbox account with a reasonably scoped IAM role with temporary credentials
[+] [-] lfx|1 month ago|reply
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.
[+] [-] JohnMakin|1 month ago|reply
Sorry, that last part is absolutely not the case from my experience. IaC also uses the API to inquire about the infrastructure, and there are existing import/export tools around it, so I’m not exactly sure what you are gaining by insisting on abandoning it. IaC also has the benefit of being reusable and commitable.
[+] [-] jaimex2|1 month ago|reply
Next month - 'Sorry I caused a $200,000 bill...'
[+] [-] chickensong|1 month ago|reply
How does the Ansible export work? Do the agents hack around inside the VM and then write a playbook from memory, or are all changes made via Ansible?
If Ansible playbooks are the artifact, what does features does Fluid offer over just having agents iterate on an Ansible codebase and having Ansible drive provisioning?
[+] [-] stackskipton|1 month ago|reply
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.
[+] [-] bluelightning2k|1 month ago|reply
[+] [-] dengsauve|1 month ago|reply
[+] [-] jamesmstone|1 month ago|reply
[+] [-] wayeq|1 month ago|reply
what could go wrong..
[+] [-] baalimago|1 month ago|reply
[+] [-] IBCNU|1 month ago|reply
[+] [-] Zanfa|1 month ago|reply