DevOps Engineer specialising inAgentic DevOps Workflows

I wanted to know what it felt like to let an AI agent do the infrastructure work while I supervised.

So I built the whole system. CLAUDE.md for project memory. Skills for on-demand execution — /scaffold-terraform, /tf-plan, /tf-apply, /deploy. Subagents for specialised roles. MCP servers for live AWS and Terraform awareness. Safety hooks so nothing destructive could happen without my approval.

Then I gave the agent a task: deploy a live website to S3 and CloudFront. It planned, it applied, it deployed. I reviewed and approved at each stage.

It worked. And it changed how I see this profession.

I took the same application I deployed with a team and rebuilt it alone. My crew this time was AI.

Five MCP servers: Terraform, AWS, Cost Estimator, Library Docs, and Jira Integration. Two repositories with clear separation — the app repo is read-only, the infra repo is mine to build. Domain-specific rules for Terraform, Kubernetes, Helm, ArgoCD, and pipelines. Jira-driven development where Claude reads the epic acceptance criteria and builds against them.

Full observability. Security hardening throughout.

An 11-person team. 8 Spring Boot microservices. Two sprints. I was the Team Lead and Kubernetes Engineer.

I wrote the Kubernetes manifest files, managed namespaces, ConfigMaps, Secrets, and Ingress. The team integrated AWS Secrets Manager via External Secrets Operator so nothing sensitive ever touched the codebase, wired up GitOps with ArgoCD, built the GitHub Actions CI/CD pipeline, and made the whole stack observable with Prometheus, Grafana, and Zipkin distributed tracing.

When it went live, it worked. That's the standard.

Three tiers, strictly separated: Next.js on the front, Node.js for business logic, MySQL on RDS at the back. All of it provisioned with Terraform, none of it clicked together in a console.

The part worth talking about is the security model. An internet-facing ALB takes public traffic, an internal ALB carries service-to-service. Every tier accepts traffic only from its verified upstream security group, never from an IP range. If one tier is compromised, the blast radius stops there rather than spreading sideways through a subnet.

I modelled the whole thing on paper before provisioning a single resource, which kept the applied footprint close to the design. Then I wrote a complete guide so anyone could follow the same path.