Blog / AI

The Cloud Engineer Who Automated Their Job, and What It Led To

By Saurav Sharma||4 min read

There is a version of AI automation that ends with you out of work, and a version that ends with a promotion. I made a short film that tells the second one, and this post is the walkthrough. It opens on a senior cloud engineer on a $200,000 salary who admits 90 percent of the daily job repeats: Terraform plans written a hundred times, CloudWatch alerts with known answers, Jira tickets that are copy-paste from last sprint.

Building the system, week by week

The story moves week by week. Week one, Claude Code goes into the terminal and starts drafting Terraform modules that are good enough to review instead of writing from scratch, saving about two hours a day. Week two, an agent watches the CloudWatch dashboards: when an alarm fires it pulls the logs, summarizes the root cause, and drafts a Slack message the engineer approves with one click. Week three, a RAG pipeline goes over the team's runbooks, so a question like how do we handle a Redis failover gets answered with links to the actual internal docs. RAG here means the model reads the team's own documents before answering, so the answer is grounded in real procedures.

The results, and the promotion

By month two the daily routine changes shape. The AI handled three alerts overnight and drafted two pull requests, and the engineer reviews everything in about 45 minutes. Pull request velocity is three times the rest of the team and incident response drops from 30 minutes to 4. The manager's one-on-one is not the one you brace for. She says whatever you are doing, I want the whole team doing it, and promotes the engineer to tech lead. Automating the floor did not shrink the role, it expanded what one person could cover.

Why I told it this way

I did not want to oversell it. The line the film lands on is that the real job is no longer writing Terraform or answering alerts, it is building the systems that write Terraform and answer alerts, and then building the things only people can: strategy, architecture, and judgment. Agents draft and investigate. People decide. It is one more layer on top of infrastructure as code, the same deploy, monitor, iterate loop cloud engineers already run.

The choice it puts to you

The turn in the story is a choice: keep the system secret to protect your advantage, or open source it inside the company and teach the team. The engineer picks the second, runs the workshops, and the whole department gets faster. That is the open question I wanted to leave people with, whether sharing your workflow makes you more valuable or easier to replace.

Work with me

I specialize in helping cloud engineers build this kind of automation without automating away the judgment that earns the promotion. If you want help deciding what to hand to agents and what to keep, book a call at cloudyeti.io/meet.

Book a call