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?
Yo, fluid is built with on-prem in mind, specifically VMs. This is my initial use case for it. I am currently working on a remote version of fluid, where instead of CLI tool, it would be more of a codex/claude code app with a UI where you can install a server and then command hundreds of agents at once to work on infrastructure. Is this what you had in mind?
this is not the way to do devops, we have IaC, reviews, and promotion for a reason it's clear infra level decisions are well beyond what LLMs / agents are capable of today, this is area is too high risk, devops is slow to adopt new tooling because of its role and nature
wow, you downvoted me. this is still devops. we use cloud-init to setup the vm. i run the underlying hardware infrastructure and we've automated the provisioning such that we have an api that can start/stop compute at will. even bare metal. the point of this is that the current $/token model is awful, especially if you're using a lot of tokens. it should be $/minute. pay for what you use.
this is not the way to do devops, we have IaC, reviews, and promotion for a reason it's clear infra level decisions are well beyond what LLMs / agents are capable of today, this is area is too high risk, devops is slow to adopt new tooling because of its role and nature
wow, you downvoted me. this is still devops. we use cloud-init to setup the vm. i run the underlying hardware infrastructure and we've automated the provisioning such that we have an api that can start/stop compute at will. even bare metal. the point of this is that the current $/token model is awful, especially if you're using a lot of tokens. it should be $/minute. pay for what you use.
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.
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...
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.
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 dom…
Conversely, good developers can now leverage LLM’s to master any domain.
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.
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 dom…
Conversely, good developers can now leverage LLM’s to master any domain.
Hhmm I think that's more difficult than using these tools for creating software. If generated software doesn't compile, or does the wrong thing, you know there's an issue. Whereas if the LLM gives you seemingly accurate information that is actually wrong, you have no way of verifying it, other than with a human domain expert. The tech is not reliable enough for either task yet, but software is easy to verify, whereas general information is not.
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 th…
Hard disagree with hard parts of software are harder than domain. I don’t know your story, skills, or domain. But this doesn’t match my experience and others around me at all.
Really depends on the domain. I've been in jobs where the domain was much harder than my job as a software engineer, but I've also been in jobs where I quickly got to understand the domain better than the domain experts, or at least parts of it. I believe this is not because I'm smart (I'm not), but because software engineering requires precise requirements, which requires unrelenting questioning and attention to details.
The ability to acquire domain knowledge quickly however, isn't exactly the same as the ability to develop complex software.