It’s 9 AM. A Jira ticket lands: “Our batch job is failing with AccessDenied on an S3 bucket.” The developer pasted an error log, half of it truncated, and tagged it urgent.
Here’s what I used to do. Open the ticket. Read it twice. Copy the role name from the error. Search through our Terraform repos to find the role’s permission set YAML. Read 80 lines of inline policy statements to figure out what it already has and what it’s missing. Cross-reference the resource against our IaC to check whether a resource policy exists. Determine whether this is a same-account or cross-account request, because the fix is completely different depending on that. Draft the HCL or YAML change. Match the existing code style. Make sure I’m not breaking anything. Create a branch, push, open a merge request. Thirty minutes, on a good day.
Here’s what I do now. I type /add-permission-to-role DIT-41250 and let the skill handle it.
Two minutes later, I’m reviewing a proposed change that explains exactly what it found, what it added, and why. I approve, commit, and move on.
This is the story of how AI-powered skills reshaped cloud support at our customer, and what that means for the business.
The Scale Problem
I’m a cloud infrastructure engineer at Develeap, embedded in the customer’s DI Cloud team. They are one of the largest AWS customers in Israel. We manage dozens of AWS accounts through Identity Center, hundreds of IAM roles, over a hundred team S3 buckets, EKS clusters, DynamoDB tables, and a user base that generates a steady stream of support tickets every day.
Our team maintains all of this through Infrastructure as Code. Every permission, every bucket, every role lives in Terraform and YAML files across multiple repositories. That’s the right way to do it. But it also means that every support ticket, no matter how simple, requires navigating codebases, understanding context, and applying changes that match existing patterns.
We built a ladder of solutions to handle this at scale. First, self-service tools where users handle common requests themselves, like joining a cloud group through an approval workflow with their manager. Next, automated agents that handle specific categories of issues. Then comes the layer I’m most proud of: AI Skills.
What Are Skills?
Skills are structured prompts, essentially instructions I wrote for Claude Code that encode our team’s expertise. Each skill knows which repositories to look at, which files to modify, what patterns to follow, what questions to ask, and what guardrails to respect. They read Jira tickets through MCP integrations, navigate our Terraform codebases, and propose infrastructure changes that follow the customer’s exact conventions.
Here’s what I built:
Add Permission to Role — Reads the Jira ticket, locates the role’s permission set YAML, analyzes existing inline policy statements, determines whether to add resources to an existing statement or create a new one, and proposes the exact YAML change. It respects least-privilege principles and even knows the difference between global and China partition ARNs.
Add Bucket Policy — Handles cross-account S3 access requests. It knows which roles already have baseline read access and don’t need bucket policy changes. It classifies each principal, finds the right policy statement to modify, and outputs the HCL change.
Cloud Permissions — For user-level permission updates like memory limits, timeouts, GPU access, and on-demand queue control. It reads the ticket, cross-references our Confluence documentation to identify the correct field, and outputs the exact CLI command for the operator to verify and run.
Create Team Bucket — Builds a complete Terraform entry for a new S3 bucket. It validates that the owner and budget group exist, recommends cost-optimal lifecycle policies, handles cross-account access, and inserts the entry in the right place.
Create Pext Bucket — Similar to team buckets but for processing output workloads. Handles retention policies, cross-account access, and knows which services already have wildcard write access so it won’t create redundant permissions.
Add IDC Group — Manages AWS Identity Center group assignments. It handles the two-phase deployment pattern required by Terraform’s race conditions, creates the correct YAML entries across multiple files, and even reminds you to update code ownership.
The list goes on. Every repetitive task that follows a pattern is a candidate for a skill.
The Human in the Loop
Let me be clear about what these skills don’t do: they don’t push code or make decisions autonomously. Every skill proposes a change and explains its reasoning. I review the diff, validate the logic, and decide whether to commit. The AI is my analyst and my drafter. I’m still the engineer.
This is exactly where the value is. Support tickets come in all shapes. Sometimes a developer writes two sentences with no error log and no resource name. Sometimes an automated agent creates the ticket and dumps an overwhelming wall of logs, stack traces, and metadata for what turns out to be a simple permission request. Either way, the skill cuts through the noise. It parses the ticket, extracts the relevant details, and explains what it interpreted and why it made specific choices. I can validate the output rather than spend ten minutes just figuring out what the requester actually needs. That’s a fundamentally different cognitive load.
And it’s not just about me. When a teammate who usually works on EKS needs to cover cloud support for a day, they can invoke the same skills and get the same quality output. The skills encode institutional knowledge. They flatten the learning curve. New employees can start handling real tickets in their first week instead of spending months absorbing tribal knowledge about which YAML file to modify and which naming convention to follow.
The Business Impact
Here’s what this looks like at scale. A permission ticket that took 25–30 minutes now takes 2–3 minutes of review time. An S3 bucket creation request that involved 20 minutes of validation, pattern matching, and HCL drafting is done in under 5 minutes. The cloud-permissions tickets that required cross-referencing Confluence documentation to identify the right field out of 100+ options now produce the correct CLI command in seconds.
Our SLA improved because resolution times dropped across the board. But the deeper impact is capacity. The same team handles more tickets, with more consistency, and with less context-switching fatigue. Support stops being a bottleneck for developers waiting on infrastructure changes. They get their access, their bucket, their permission, and they get back to work.
These skills are shared across the team. Anyone can use them, anyone can improve them. And building a new skill for a repetitive task is straightforward once you’ve done it once. It’s dramatically easier than building the final step of the automation ladder, a full self-service tool or a dedicated agent. You encode your expertise in a structured prompt, test it against a few tickets, and it’s ready.
What This Means
AI didn’t replace our cloud support team. It made each of us significantly more effective. The tickets that used to consume our mornings now take minutes. The ones that actually need deep investigation and debugging, the unexpected failures, the architectural questions, that’s where we spend our time now. The work got more interesting because the routine got automated.
For the customer, this means faster unblocking of development teams, more consistent infrastructure changes, and a support operation that scales with the organization rather than linearly with headcount.
For Develeap, this is what embedding AI into real operational workflows looks like. Not a chatbot. Not a demo. A set of skills running in production, handling real tickets, integrated into the tools and processes that already exist.
The skills keep growing. The team keeps improving them. And every new pattern we encode is one less thing standing between a developer and their next deployment.
