Terraform, Fargate, and an AI Pair Operator: How Claude Code Works Inside Cosmo Engineering

Cosmo sits at the bottom of the loyalty stack. When a bank moves points into airline miles, the request lands on our rails. We validate it, route it, price it, record it, and settle it.

That position comes with an obligation. The base layer is the one part of the stack nobody else can compensate for. If a partner API is slow, we absorb it. If our infrastructure is wrong, everyone downstream is wrong with us.

That obligation shapes how we build. It also shaped how we adopted AI tooling. Over the past year, Claude Code has become part of how Cosmo Engineering works day to day — not a code generator bolted onto the side, but an operator working inside the same repository, the same review discipline, and the same approval gates as everyone else on the team.

The Shape of the Infrastructure

Everything we run is defined as code. There is no console-clicked resource in the critical path, and no environment that exists only in someone's head.

The platform runs on AWS as containerised services on ECS Fargate, across fully isolated environments for development, testing, and production. Each has its own network, its own data stores, and its own credentials.

Public traffic terminates at a public load balancer. The services themselves run in private subnets with no inbound path from the internet. Internal traffic between services goes through a private load balancer that acts as the central hub, with access rules written against service identity rather than broad address ranges. A compromised component cannot quietly reach the rest of the estate.

State lives in managed PostgreSQL with encryption, automated backups, point-in-time recovery, and deletion protection. Anything that does not need to happen inline — ledger writes, notifications, reconciliation — runs through queues, each with a dead-letter queue behind it and a defined reaction: recover automatically, redrive manually, or log and review.

Every service ships through its own CI/CD pipeline. Alarms, dashboards, synthetic monitors, a web application firewall, and threat detection sit on top.

The Terraform is layered. Keys and parameters first, then networking, then the shared platform — cluster, load balancers, databases, queues — then each service on top, each with its own isolated state. It is a deliberate design, and deliberately, unavoidably, a lot of moving parts.

Why This Kind of Work Resists Automation

Generic AI help has never been the hard part of infrastructure work. Writing a Terraform block is not where the risk lives.

The risk is in the knowledge around it. Which parts of the estate need re-applying when a shared module changes. Which service owns which database, and which of those names are historical rather than descriptive. Which code is still running and which was decommissioned two years ago. What order to roll a change out in, so access is granted before it is restricted rather than the other way round. Where a fast iteration loop is fine, and where a change needs a printed plan, a human read, and an explicit yes.

None of that is in the code. It lives in the heads of the people who run the platform. It is exactly the knowledge a new engineer — human or otherwise — takes months to pick up, and can do real damage without.

Writing the Context Down

The thing that made Claude Code genuinely useful for us was not a clever prompt. It was deciding to write that knowledge down in a form the model reads at the start of every session.

Our repository now carries a set of context documents next to the Terraform: how the architecture fits together, what each part of the estate manages and what a change to it affects, the operating rules, and — the one that saves the most wasted effort — a map of what is actually deployed, generated from live AWS rather than from the source tree.

That last one matters more than it sounds. Any large codebase accumulates dead code. An assistant reasoning only from source text will confidently raise issues about services that stopped running long ago. Grounding it in what is really running turned a noisy tool into a reliable one.

The rules are written down the same way:

• Never apply to production without a human reading the plan first.
• Always save the plan to a file, show it, get approval, then apply that exact plan.
• Never leave a rollout half-finished across the estate.
• Flag anything unexpected loudly rather than burying it in output.

These are the same rules we would give a new hire. The model follows them because they live in the repository, not because someone remembered to restate them.

What It Has Actually Changed

The clearest wins have been the work that is important, tedious, and easy to defer.

Wide rollouts. Tightening the access paths to our load balancers and databases touched a long list of components in a specific order across every environment. That work is not intellectually hard. It is a sequencing and completeness problem, and completeness is where humans quietly fail. Having an assistant that tracks every affected piece and refuses to call a rollout done while one is still outstanding has closed a category of drift we used to live with.

Safer database changes. Schema migrations used to be a privileged operation run from an engineer's laptop. We moved them into the deployment pipeline instead: a read-only preview of what the migration will do, then an approval gate, then the change itself under a strict time limit, with an audited emergency path for the rare case where something gets stuck. That redesign was worked through in conversation with Claude Code and is rolling out gradually.

Monitoring that keeps up. Per-service alarms, a consolidated production dashboard, and synthetic checks that exercise our own APIs on a schedule. Monitoring is the classic thing every team intends to expand and never gets to. Making it cheap to do properly is what got it done.

Standing security review. We run structured reviews across our service code — authentication paths, money-handling logic, idempotency, failure behaviour — with findings tracked in the repository and verified against live infrastructure before anyone acts on them. Not every finding survives that check, and that is the point. The discipline is in the verification, not the generation.

What We Did Not Change

Approval is still human. Production changes are still read line by line before anyone types yes. Nothing reaches production without proving itself in development first.

When we disagree with the model, we say so. When it pushes back with a real argument, we take it seriously. But accountability for what runs on the rails does not move.

The gain has not been fewer engineers. It has been a smaller gap between the infrastructure we know we should have and the infrastructure we actually have. Work that used to sit in a backlog for a quarter because it was unglamorous now ships in an afternoon. For a settlement network, closing that gap is the whole game.

Conclusion

Base-layer infrastructure earns trust by being boring: clear boundaries, reproducible deployments, honest monitoring, and no unrecorded changes. AI tooling does not replace any of that.

What it does — when you give it the same context and the same guardrails you would give a senior engineer — is make it much cheaper to hold the standard you already set for yourself.

That is how Cosmo Engineering uses Claude Code. Inside the guardrails, on the same rules as everyone else, on infrastructure that banks and loyalty programs depend on every day.

Learn more about how Cosmo can transform your loyalty infrastructure.