nickpapciak

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.

Potentially! But we do not do PR reviews at the moment. Is infra code reviews something you are interested in?

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.

Yes definitely! That's why we do believe the agents, for the time being, will act as great junior devs that you can offload work onto, while as they get better they can slowly get promoted into more active roles.

The personalities approach sounds fun to experiment with. I'm wondering if you could use SAEs to scan for a "startup codebro" feature in language models. Alas this is not something we get to look into until we think that fine-tuning our own models is the best way to make them better. For now we are betting on in-context learning.

Business requirements are also incredibly valuable. Notion, Slack, and Confluence hold a lot of context, but it can be hard to find. This is something that I think the subagents architecture is great for though.

thank you!

These are fair criticisms. I will say, while each of these examples are challenging problems for agents to carry out, I do believe they can be solved. Especially with a tighter integration with app code.

We are always trying to learn more based on our customer's feedback. What we've learned so far is that infra setups are all extremely different, and what works for some companies don't work for others. There's also vastly different company cultures related to ops. Some companies value their ops team a lot, other companies burden them with way too much work. Our goal is to try to make that burden a little lighter :)

Glad you mentioned this! We do use open source rule-based scanners internally to make it more deterministic. This is also a new feature, and we'd probably want to integrate with existing tools rather than competing with them. We do think there are some benefits of using LLMs though.

I think the power language models introduce is being able to more tightly integrate app-code with the infrastructure. They can read YAML, shell scripts, or ad-hoc wiki policies and map them to compliance checks, for example.

Lots of people have asked us this! We try to do more than just being an AI-enabled IDE by giving the agent access to your infrastructure and observability tools. So you can query over your AWS, get information about metrics over the past few days, etc etc. We also plan to integrate with more DevOps tools as our customers ask for them. We also try to be less like an IDE, and more like an autonomous agent. We've noticed that DevOps engineers actually like being engineers, and enjoy some infrastructure tasks, while there are others that they would rather automate away. Not sure if you have experienced this sentiment?

Also, auto-revoke right now can be handled by creating a role in Terraform that can be assumed and expires after a certain time. But we’re exploring deeper integrations with identity providers like Okta to handle this better.

Thank you! We currently mainly use Claude Sonnet and then Opus for more difficult tasks. We experimented with GPT 5 when it came out but we might need to do some more experiments to see if it’s better. Better evals is something we are working on before we experiment too much with different models!

Would love to! I think I just found and added you on LinkedIn

Glad you find it interesting. A surprising way people are using us right now has been people who are technical but don’t have deep infrastructure expertise, asking datafruit questions about how stuff should be done.

Something we’ve been dealing with is trying to get the agents to not over-complicate their designs, because they have a tendency to do so. But with good prompting they can be very helpful assistants!

LLMs are pretty awesome at Terraform, probably because there is just so much training data. They are also pretty good at the AWS CDK and Pulumi to a bit of a lesser extent, but I think giving them access to documentation is what helps make them the most accurate. Without good documentation the models start to hallucinate a bit.

And yeah, we are noticing that it’s difficult to convince people to give us access to their infrastructure. I hope that a BYOC model will help with that.

AWS has created a whole economy of companies whose job is to make the dashboard more tolerable. Hopefully our agents help with that haha.

That's an interesting approach. For us, we give it read-only privileges which gives the agent the context of your infrastructure, without giving it the capabilities to break things. But I do see a world where we give it more access, but add additional safeguards.

Totally agree, enterprise is where the most $ is to be made, but from what we've found they care a lot about doing one specific thing very well. This has been something we've been thinking about. For now we've enjoyed working with startups as they have very interesting challenges that only appear at smaller scale.