←back to thread

65 points nickpapciak | 2 comments | | HN request time: 0.001s | source

Hey HN! We’re Abhi, Venkat, Tom, and Nick and we are building Datafruit (https://datafruit.dev/), an AI DevOps agent. We’re like Devin for DevOps. You can ask Datafruit to check your cloud spend, look for loose security policies, make changes to your IaC, and it can reason across your deployment standards, design docs, and DevOps practices.

Demo video: https://www.youtube.com/watch?v=2FitSggI7tg.

Right now, we have two main methods to interact with Datafruit:

(1) automated infrastructure audits— agents periodically scan your environment to find cost optimization opportunities, detect infrastructure drift, and validate your infra against compliance requirements.

(2) chat interface (available as a web UI and through slack) — ask the agent questions for real-time insights, or assign tasks directly, such as investigating spend anomalies, reviewing security posture, or applying changes to IaC resources.

Working at FAANG and various high-growth startups, we realized that infra work requires an enormous amount of context, often more than traditional software engineering. The business decisions, codebase, and cloud itself are all extremely important in any task that has been assigned. To maximize the success of the agents, we do a fair amount of context engineering. Not hallucinating is super important!

One thing which has worked incredibly well for us is a multi-agent system where we have specialized sub-agents with access to specific tool calls and documentation for their specialty. Agents choose to “handoff” to each other when they feel like another agent would be more specialized for the task. However, all agents share the same context (https://cognition.ai/blog/dont-build-multi-agents). We’re pretty happy with this approach, and believe it could work in other disciplines which require high amounts of specialized expertise.

Infrastructure is probably the most mission-critical part of any software organization, and needs extremely heavy guardrails to keep it safe. Language models are not yet at the point where they can be trusted to make changes (we’ve talked to a couple of startups where the Claude Code + AWS CLI combo has taken their infra down). Right now, Datafruit receives read-only access to your infrastructure and can only make changes through pull requests to your IaC repositories. The agent also operates in a sandboxed virtual environment so that it could not write cloud CLI commands if it wanted to!

Where LLMs can add significant value is in reducing the constant operational inefficiencies that eat up cloud spend and delay deadlines—the small-but-urgent ops work. Once Datafruit indexes your environment, you can ask it to do things like:

  "Grant @User write access to analytics S3 bucket for 24 hours"
    -> Creates temporary IAM role, sends least-privilege credentials, auto-revokes tomorrow

  "Find where this secret is used so I can rotate it without downtime"
    -> Discovers all instances of your secret, including old cron-jobs you might not know about, so you can safely rotate your keys


  "Why did database costs spike yesterday?"
    -> Identifies expensive queries, shows optimization options, implements fixes

We charge a straightforward subscription model for a managed version, but we also offer a bring-your-own-cloud model. All of Datafruit can be deployed on Kubernetes using Helm charts for enterprise customers where data can’t leave your VPC. For the time being, we’re installing the product ourselves on customers' clouds. It doesn’t exist in a self-serve form yet. We’ll get there eventually, but in the meantime if you’re interested we’d love for you guys to email us at founders@datafruit.dev.

We would love to hear your thoughts! If you work with cloud infra, we are especially interested in learning about what kinds of work you do which you wish could be offloaded onto an agent.

Show context
solatic ◴[] No.45112941[source]
My 2 cents (DevOps Engineer with a decade of experience, MBA, optimistic about tools like Claude Code and pessimistic about what I'm seeing here):

You need to be very clear about the persona who you're building for, what their pain point is, and why they're willing to spend money to solve it. So far it seems like you took an emerging technology (agentic workflows), applied it to a novel area (DevOps), built a UX around it, and tried to immediately start selling. This is the product trap of a solution in search of a problem.

Are you trying to sell to large companies? The problem that large companies have is cultural/organizational, not tooling. For any change, you need to get about a dozen people to review, understand, wait for people to come back from vacation, ping people because it fell off their desk, sign off, get them to prioritize, answer questions again from the engineer the task was assigned to, wait for another round of reviews and approvals, and maybe finally somebody will get the fix applied in production. DevOps is (or at least, it originally used to be) focused on finding and alleviating the bottlenecks; the actual process of finding data or applying changes is not the bottleneck in large companies and so therefore it is not a solution to the pain point that different folk in large companies have. If your value proposition is that large company executives could replace Infrastructure employee salaries with a cheaper agentic workflow, you need to re-read my prior point - if large companies have all this process and approvals for human beings making changes, why would they ever let an agentic workflow YOLO the changes without approval? And yes, I know, your agent proposes Terraform PRs for making changes to keep a human in the loop - but now you slayed one of the Hydra's heads and three more have popped up in its place: the customer needs the Terraform PR to be reviewed by a human committee, some of whose members are on vacation, some of whose members missed the PR request because they had other priorities and it fell off their desk, etc. etc. Doesn't really sound like you solved anything. The fundamental difference between what you built and something like Claude Code is that Claude Code doesn't need a human committee to review on every iteration it executes on an engineer's laptop, only the review of the One Benevolent Laptop User who is incentivized to get good output from Claude Code and provide human review as quickly as (literally) humanly possible.

Are you trying to sell to small companies that don't have DevOps Engineers? What's the competitive space here? The options usually look something like, (a) pay a premium for a PaaS, (b) spend on the salary for your first DevOps Engineer in the hopes that they will save more on low-level infra bills compared to their salary, so you're posing now (c) some kind of DevOps agentic workflow that is cheaper than a DevOps Engineer salary but will provide similar infra cost savings? So your agentic workflow will actually lift and shift to better/cheaper infra primitives and own day-to-day maintenance, responding to infra issues which your customers - who aren't DevOps Engineers, and don't know anything about infra, and are trying to outsource these concerns to you - which your customers don't know how to handle? I would argue that if you really did achieve that, then you should be building an agentic-workflow-maintained PaaS that, by virtue of using agents instead of humans, can undercut traditional PaaS on cost while offering a maybe better UX somehow. If you're asking your customers to review infra changes that they don't understand, then they need to hire a DevOps Engineer for the expertise to review it, and then you have a much less interesting value proposition.

replies(1): >>45113121 #
nickpapciak ◴[] No.45113121[source]
That’s actually a really interesting point. We started out building out basically an “agentic PaaS” exactly as you described, but quickly found difficulty in securing more customers and moving up-market (from seed stage to series A+) for it. Because a PaaS did not have sufficient abstractions + the customers were too afraid to give us control, because even if it was their cloud, if we went under there was a sense that they “lost” their deployment platform. (This was the sentiment we were able to piece together from talking to many people).

Right now most of our value, as you said, is in augmenting an infra engineer at a growth stage company to limit some of the operational burdens they deal with. For the companies we’ve been selling to, the customers are SWEs who have been forced to learn infra when needs arise. But overall they are fairly competent and technical. And Claude code or other agentic coding tools are not always sufficient or safe to use. Our customers have told us anecdotally that Claude code gets stuck in a hallucination loop of nothingness on certain tasks and that Datafruit was able to solve them.

That being said, we have lost sales because people are content with Claude code. So this is something we are thinking about.

replies(1): >>45118878 #
1. solatic ◴[] No.45118878[source]
So if you want to target an infra engineer at a growth company, usually in growth companies where there is only one, maybe two infra/non-product engineers, I would recommend that you start from the following axioms:

  1. Infra engineers always want to apply changes by themselves, but tooling can always recommend changes
  2. What are all the kinds of work that infra engineers would love to do, that *do* add value, but that they haven't built yet because they can't prioritize it?
  3. How do you build an agent that:
    a. Understands architectural context
    b. Offers to set up (i.e. Terraform PR) value-adding infra
    c. That the human infra engineer can easily maintain
    d. That the human infra engineer will appreciate as being value-adding and not time-wasting or unnecessary-expense?
Maybe the key isn't to provide an agent that will power a PaaS; maybe the key is to give early infra engineers the productivity to build their own in-house PaaS. Then your value-add above Claude Code is clear, because Claude Code is a generic enough tool that it doesn't even make any recommendations; because a DevOps agent works within an axiomatic framework of improving visibility, reducing costs, improving release velocity, improving security, etc., so it can even start (after understanding the architecture, i.e. by hooking up MCP servers and writing an INFRA.md) by making recommendations and then just ask the customer if they like the PRs it is proposing. Does that resonate with you?
replies(1): >>45120446 #
2. nickpapciak ◴[] No.45120446[source]
Yes, some of this definitely resonates. We really want the agents to suggest their own, novel projects, beyond security or cost optimization. I think this is more feasible for coding agents to do in infra rather than dev work because a lot of the dev work depends strictly on what the customers want, whereas infra work can be more internal and developer focused so there’s opportunities to suggest improvements to the internal system.

I think in the near-term, however, the problem we have identified is that while developers at growth stage have been vastly accelerated, the infra engineers have not been. So our tool is almost helping them “catch up” to the new rapid pace of development. This is dangerous due to the complexity and need for infrastructure to be robust, hence why we are really focused on making it safe to use.

At larger enterprisey companies, AI has not yet been an extreme productivity boost for the developers like it has been for growth stage companies. But I do believe that an enterprise adoption wave is coming.