You're designing the entire cloud engineering engagement for a Norwegian offshore wind company that is scaling its operations and has outgrown the infrastructure it built ad hoc over the last three years.
What you're practicing: a coherent system architecture for an organization that runs both on-premises operational systems and AWS workloads; an infrastructure-as-code foundation and a governance standard a 400-person company can actually follow; a tiny real footprint, provisioned and verified, that proves the engineering without paying to build it at scale; deployment, observability, and operational practices for the team that will run this; a cost model the board can approve; and an operational handover so the company is not dependent on one person. Everything you've built across this track, held at once.
What you're learning about the loop: AI builds each piece of this competently and confidently — the ingestion path, the data store, the compute tier, the governance document, the cost model, the runbook. What it does not have is a model of how the pieces relate. It will size something the obvious way and miss that the choice changes the cost model and the operations model and the monitoring at the same time. It will propose a service without checking whether it's available where this company is allowed to run it. It will wire components that look right separately and never verify they work together. None of these connections appear in any single prompt's answer, because AI optimizes the thing in front of it. You are the only thing holding the whole system together. That is the work.
Your Role
After this project you can take a sparse problem and produce a complete, coherent cloud engineering engagement — architecture through operations through handover — directing AI through the pieces while you hold the system that AI cannot.
Lars is a senior technologist with deep domain expertise and solid cloud knowledge. He is not a confused client. He needs the problem turned into something he can take to his board and hand to his team. The North Sea is unforgiving and so is his CFO: a design that doesn't scale, a cost model the board can't read, or operations the team can't run all fail the company.
This is the work with almost nothing provided. You supply the architecture, the structure of your own work, the standards, the verification, the cost model, the operations practices, and the documentation. The difficulty is not new content — every skill is one you already have. The difficulty is that nothing structures it for you.
What's New
Last time, for a Manila BPO, you lived a tool migration directly and built a reusable framework for the next one — proving the skill was the concept, not the tool.
This time there is no starter configuration, no working baseline, no template, no answer key, and no inherited estate to react to. There is a voicemail. One paragraph. Everything else comes from the discovery you run and the structure you supply.
The hard part: it is not any single deliverable. It is holding all of them coherent at once, while directing AI through work it produces piece by piece with no awareness of the whole. The valuable output here is not the architecture diagram or the Terraform — it's whether the engagement holds together, and whether the company can run it without you.
Tools
- Claude Code — drafts each component: the architecture, the IaC, the governance standard, the cost model, the runbook. You direct it and hold the coherence.
- Terraform — the IaC for the tiny real footprint and the expressed standards for the full design.
terraform validate,plan,apply,destroy. - AWS CLI — the budget guardrail, resource confirmation, and the describe-confirmed orphan scan at teardown.
- AWS Budgets — the guardrail, provisioned first, before anything else.
- Git / GitHub — the engagement repo; the architecture, IaC, governance standard, cost model, runbook, and README are committed deliverables.
Everything here you have used before. Nothing new is introduced.
Materials
In the project zip:
- Voicemail transcript (
voicemail-transcript.md) — the engagement opener from Lars. One paragraph. It is essentially the entire brief; the rest is yours to find. - EU region reference (
eu-region-reference.md) — a factual card listing AWS regions and the data-sovereignty note, so you don't have to guess region identifiers. It states facts, not the architecture.
There is no starter config, no baseline, no template, and no answer key. You author the engagement CLAUDE.md, the architecture, the IaC, the governance standard, the cost model, the operational practices, the runbook, and the AI infrastructure. The budget-alarm-first habit, the verification-by-stakes repertoire, the three-tag scheme, the describe-confirmed orphan-scan teardown, and the repo-handoff habit all carry forward — by now they are reflexes you run without prompting.