You're building a CI/CD pipeline for a small London digital agency -- eight people, four developers, four different ways of deploying to AWS, and a broken contact form that shipped to production last week because someone deployed from the wrong branch.
The discipline skills: building GitHub Actions workflows as pipeline-as-code, configuring secrets management with GitHub Secrets so credentials never appear in code or build logs, scoping a CI role's IAM policy to least privilege, integrating checkov and Infracost as automated pipeline checks, and designing a staging-to-production approval gate.
The AI-direction lesson: directing AI through a pipeline build means multiple concerns compete for context at once -- pipeline structure, secrets handling, IAM permissions, testing stages, deployment targets. Including everything in a single prompt produces bloated, unfocused output. Including too little -- asking AI to build a deploy step without the security policies -- means it generates with permissive defaults. You're learning to curate what AI sees for each task. The right context changes depending on whether you're reviewing IAM permissions, configuring deployment steps, or integrating scanning tools. Meanwhile, AI generates pipeline YAML that works but defaults to AdministratorAccess on the CI role, hardcodes secrets in environment variables visible to all steps, and uses latest tags that create non-reproducible builds. The same pattern from Terraform -- AI defaults to overly permissive access -- shows up in pipeline code. Your verification transfers to a new domain.
Your Role
You're the cloud engineer. Sophie needs every deployment to go through the same process -- no more one-off FTP uploads or git pull on the server. Her developers are capable. What they lack is a shared process.
Scaffolding holds steady from last time. You still get a brief with gaps you need to ask about. The difference is what's provided: a starter web application to build the pipeline around, but no pipeline template, no pre-built workflow, and no CI role policy. You direct AI to build the pipeline from Sophie's requirements and review what it produces.
What's New
Last time you audited existing Terraform, created reusable modules, ran security scanning for the first time, and introduced cost estimation from code. Everything was infrastructure you could review with terraform plan.
Pipeline code is a different animal. GitHub Actions YAML runs in a privileged environment with access to cloud credentials, container registries, and deployment targets. A pipeline with AdministratorAccess on the CI role deploys exactly the same as one with least-privilege permissions -- until someone compromises the repository. Security problems in pipelines produce no visible symptoms, just like Terraform IAM. The review discipline transfers. The domain is new.
The other thing that's new: maintenance. The pipeline you build will break. Dependencies update, tokens expire, action versions change. This is normal CI/CD reality, not a sign of bad engineering. For the first time, you're building something and explicitly planning for its ongoing upkeep -- because Sophie's team maintains this pipeline after you leave.
Tools
- Claude Code -- directing pipeline creation, secrets configuration, and security review
- GitHub Actions -- CI/CD pipeline platform, configured via YAML workflow files (new)
- GitHub Secrets -- encrypted secrets storage for pipeline credentials (new)
- Terraform CLI -- integrated into the pipeline as an automated step
- checkov -- integrated into the pipeline as an automated PR check (from P4)
- Infracost -- integrated into the pipeline as an automated PR cost comment (from P4)
- Docker and ECR -- container build and push in the pipeline (from P3)
- AWS CLI -- deployment verification
- AWS Console -- visual verification
- Git and GitHub -- version control and pipeline hosting
- VS Code + Terraform extension -- code editor
Materials
In the project folder:
- Sophie's Slack message (
first-contact.md) -- four developers, four deployment methods, a broken contact form, and gaps you'll need to ask about. - Starter project (
starter-project/) -- a simple web application with a build step and unit tests, representing a typical agency client project. This is what the pipeline builds, tests, and deploys. - Deployment Terraform (
starter-project/infrastructure/) -- S3 bucket, CloudFront distribution, and least-privilege CI-role IAM policy that the pipeline deploys to and through. This is what checkov scans on PRs and Infracost estimates. - CLAUDE.md (
CLAUDE.md) -- project context file for Claude Code with verification targets, tech stack, and commit conventions. Provided as a starting point; extend it with anything project-specific as you go.