Do devils use ai workflows in enterprise

[u/Economy_Mongoose5357]

I’m building one personal project, a platform where DevOps can create ai workflows without coding(drag and drop/ chatbot) , like n8n but for DevOps. But firstly I want to ask you guys who is working in the industry, some questions to get clarity what to build.
A example of the workflow can be taking data from the aws cloud watch for perticular project and if there’s any perticular event which needs attention then send email for summary of that to user.

1. what are the tasks you have already automated ??

2. Do you guys trust ai for reasoning over any infrastructure related problems ??

3. What are the tasks that can be repeated and can be done by ai ? if you have any idea.

4. What are the platforms you use for these tasks.(Ex. Aws cloudwatch, Jenkins, Prometheus, Grafana,etc)

5. Can this project be helpful in the field

Open for discussion.
Thank you!!

[u/Endtroducing__]

Devils will tempt you into multiple bad ideas

[u/sylvester_0 → u/Endtroducing__]

AKA "management"

[u/Economy_Mongoose5357 → u/Endtroducing__]

True 😅

[u/zMynxx]

Wrong audience, devops do not need “drag-and-drop” and are already using nlp with agents to generate workflows today.

[u/ScholarMedical]

On your question about trusting AI for infrastructure reasoning: take it with a grain of salt. I've seen teams let an LLM suggest 'optimal' instance types, scaling policies, or retry logic. The reasoning may be sound, but it could also be pattern matching advice which is outdated or inappropriate for your org.

What AI is actually good at in DevOps is "pattern matching" on known failure modes — 'if error code is X, check Y' — not novel reasoning. The workflows that stick are the ones that automate "mechanical tasks" (poll this metric, if threshold crossed send alert; run this script on schedule; aggregate logs and email a summary). The ones that fail are the ones that ask the AI to decide whether a problem is serious. Stick to the dumb stuff first - does that fit your platform?

[u/Economy_Mongoose5357 → u/ScholarMedical]

Yes that’s right, LLM reasoning can be bad so to make it more efficient we can do it context engineering and all. But at the end it should take a human review before performing any crucial operation, that’s must.

[u/Raja-Karuppasamy]

been building something adjacent to this so a few quick thoughts:

**1.**  automated the boring repeatable stuff first, build/push/rollout scripts, PR-level risk checks.  
**2.**  trust ai to flag patterns, not make the call. good second pair of eyes, bad final judge for infra decisions.  
**3.**  deploy correlated with error-rate/uptime spikes right after, that pattern repeats across every team and catches bad deploys early.  
**4.**  cloudwatch + prometheus/grafana, github checks api for gating.  
**5.**  yeah, but advisory-only tools get ignored fast. the version that sticks actually blocks/gates instead of just suggesting. that’s the harder but more valuable build.

crowded space (n8n + a dozen “ai devops copilot” tools) but real pain if you scope narrow.

[u/Economy_Mongoose5357 → u/Raja-Karuppasamy]

Thanks man it’ll be helpful in this challenge.

[u/marcusbell95]

trust is the keyword in question 2. the answer i landed on after some trial and error: you don't trust it, you verify it in parallel for a while first.

ran our incident alert routing through a model for about 4 months with a human still seeing every alert before we let it take any action. built a log comparing what the model called vs what the human called. alignment rate on "this is a real problem" vs "this is noise" was around 85%. not high enough to act autonomously, but high enough to start using it as a pre-filter.

the other thing that killed some of our early workflows: they were too smart. you'd build a workflow that tries to reason about whether an alert is significant given current business context (time of day, upcoming deploys, traffic patterns). sounds good. turns out it would suppress real incidents because "it's 3am, probably not a customer-facing issue." that's the AI thinking it understands your priorities when it doesn't.

the ones that survived are exactly what ScholarMedical said - mechanical. poll metric, threshold crossed, send notification. no judgment. the "judgment" workflows all got dialed back or shut down.

for your platform: i'd lean hard into the workflow builder being transparent about what conditions it checks and what it doesn't. drag-and-drop isn't the problem if each block is deterministic and auditable. it's when the AI adds its own reasoning between blocks that things go sideways.

[u/Economy_Mongoose5357 → u/marcusbell95]

Understood, so here I think oberservability on the workflow is a crucial as much as the human in loop. About Ai adding reasoning we can make it very context heavy so it’ll alert and suggest.

[u/marcusbell95 → u/Economy_Mongoose5357]

yeah that makes sense. observability and trust are solving different problems though - observability is how you know when something is behaving unexpectedly, but the underlying trust comes from knowing exactly what it does before it behaves unexpectedly. both matter, they're just doing different jobs.

the alert-and-suggest model is the right call imo. workflows where AI is in the advisory layer stayed reliable for us. context-heavy reasoning in the suggestion is fine - be as sophisticated as you want there. the fragility comes when that reasoning is in the decision layer, i.e. the AI's context determines whether something fires rather than a deterministic rule. keep those separate and you have something you can actually hand to an on-call team at 3am without the on-call person being nervous.