How we use Ariane and Claude to compress local and staging environment work, and what that does to the price of a build.
When developers talk about AI in their workflow, they tend to talk about the visible part. Writing functions. Refactoring. Generating tests. The demos are flashy because the output looks like the output you would have written, only faster.
But the part of software work that quietly eats whole days, sometimes whole weeks, is not the code itself. It is the environment around the code. The local setup. The docker-compose that does not start. The staging server with the missing environment variable. The migration that worked in dev and broke in pre-prod. The feature flag that nobody documented. The third-party service that needs a different credential rotation in each environment.
At HDL we have spent the last two years building Ariane, our internal AI delivery layer, with Claude as the core model inside it. Over the last twelve months that work reshaped the least glamorous part of how we build: the environment around the code. Not as a code-completion toy, but as a peer in the parts of the job most agencies still treat as drudgery. The result is uncomfortable to talk about publicly, because the numbers sound exaggerated. A new project that used to take a senior developer a day and a half to bootstrap locally now takes thirty minutes. A staging environment that used to take a half-week to provision properly takes an afternoon. A bad container or broken migration that used to derail a sprint is usually resolved before the affected developer finishes their coffee.
This post is about how, specifically.
Why are dev environments such a quiet productivity drain?
Every Nordic agency that bills hours has the same hidden line item. It is not on any client invoice but it eats into every margin: the cost of setting up, maintaining, repairing and synchronising development and staging environments. Across a typical client project, environment work is somewhere between fifteen and thirty percent of total engineering time. None of it is visible to the customer. All of it is paid for, somehow.
The reasons it stays expensive are well known:
- Every project has a slightly different stack.
- Container orchestration is fragile in ways that surface only on someone else’s machine.
- Staging data is a permanent problem: too much and you leak production privacy, too little and the bugs only appear post-launch.
- Secrets management is hard, and the wrong solution costs you in audit complexity later.
- Environment-specific bugs surface late, often days before launch, and consume disproportionate effort.
The combination is corrosive. It is the work that erodes both delivery speed and developer goodwill at the same time. It is also, as it turns out, exactly the kind of work where a capable model like Claude becomes a force multiplier.
Listne to the post?
What does Claude actually do in our local development loop?
The mental shift took a few weeks. Inside Ariane, Claude is not a code generator we ask to ”write us a Dockerfile.” It is a fluent collaborator we talk to about the actual state of our system. The change is in how we frame the work.
Here is what that looks like in practice across our Helsingborg team.
Bootstrapping a new project. When a developer joins a new HDL Flagship build, they used to spend the first day cloning, configuring, troubleshooting and reading internal docs that were six months out of date. We now keep a Claude Project per client codebase inside Ariane, with the README, environment templates, recent commit history and architecture notes loaded as context. A developer types: ”Walk me through getting this running on my machine, latest macOS, I have Docker and Node 20 installed.” Claude produces a tailored runbook in the developer’s own language, anticipates the friction points specific to that stack, and answers follow-up questions as they actually hit them. What used to be a Slack thread of ”have you tried…?” between senior and junior is now a private conversation between developer and model.
Fixing the broken container. Most container failures look the same on the surface and have radically different root causes. The old pattern was: paste the error in Slack, wait for a senior, lose ninety minutes. The new pattern is: paste the docker-compose log into Claude with the relevant config files, get a hypothesis-driven answer that names the likely cause, the second most likely cause and the diagnostic command to confirm which one. Most of these are resolved in a single conversation. The developer ships, the senior keeps their flow, and the institutional knowledge is captured in the project’s running history.
Generating realistic seed data. Local environments without realistic data produce bugs that only emerge in staging or, worse, in production. We use Claude to generate context-aware seed datasets: product catalogs that match the client’s actual taxonomy, user fixtures with realistic Nordic names and postal codes, order histories with believable seasonality. A task that used to take half a day of fixture-writing now takes an hour, and the data is good enough that staging bugs surface earlier, when they are cheap to fix.
Writing the boring infrastructure that nobody enjoys. Migration scripts, GitHub Actions workflows, environment validation scripts, Makefile targets, dev-only API stubs. This is the kind of work that everyone agrees is necessary and nobody volunteers for. Claude is excellent at it, and the marginal cost of doing it properly the first time has collapsed. Our internal scaffolding has improved more in twelve months than in the previous five years, because the cost of writing a small helpful tool fell below the cost of complaining about not having it.
Living documentation. This one surprised us. We now end every meaningful environment change with: ”Update the project README and the onboarding doc to reflect this change.” Claude does it, in the project’s voice, in five minutes. The documentation gap that has plagued every agency since the invention of the README is, for us, mostly closed.
What changes in staging?
Staging is where the advantage compounds further, because staging is where the work is least repetitive and most context-dependent.
Provisioning new environments. When we spin up a new staging instance for a client, usually on Kepler Cloud, occasionally on client-controlled infrastructure, we describe the target environment to Claude in plain language and iterate on the generated Terraform, ansible playbooks or Kubernetes manifests in real time. The first attempt is usually eighty percent correct. The remaining twenty percent is fast to refine because Claude understands the diff between what was generated and what was tried. The work that used to need a dedicated DevOps day is folded back into the project pod.
Diagnosing the environment-specific bug. This is the bug that worked yesterday on your machine and fails today on staging, and the difference is almost always one of: a missing env var, a different runtime version, a permissions issue, a CORS configuration, a TLS handshake, a network route or a cache that did not invalidate. We have a conversation template inside Ariane for these. Paste the staging logs, paste the relevant config, describe what you expected. Most diagnoses land inside three messages. We have stopped doing the dance of ”let me ssh in and have a look” for anything below medium severity.
Pre-launch checklists, generated and walked through. Before a Flagship goes live, we run a checklist of forty-something items: performance budgets, security headers, monitoring hooks, error tracking, accessibility audits, third-party integrations smoke-tested, GDPR cookie defaults, robots.txt configured, sitemap submitted. The list used to live in a Notion doc that aged poorly. We now generate it per project from a base template, with Claude tailoring it to the actual stack and integrations, and the team walks through it together with the model assisting on the items that need investigation rather than just checking.
Why does this matter commercially?
This is not a productivity post. It is a pricing post in disguise.
The reason HDL can deliver an HDL Flagship build in eight to twelve weeks at a fixed price is that the unsexy parts of the project have stopped consuming the time and risk they used to. We have not gotten faster at writing front-end code by a factor of three; the model only helps modestly there. We have gotten dramatically faster at everything around the code. That is where the compression lives.
For clients this translates into three things:
- Predictable timelines. Our project schedules used to have a hidden buffer for environment surprises. That buffer has shrunk, and the timelines we promise have shrunk with it. When we say a Flagship ships in ten weeks, we mean it.
- Higher-confidence staging. Clients see a working staging environment in week two, not week six. They give feedback earlier, when it is cheap to incorporate. The product that goes live is more right because it was iterated on more.
- A team that is not exhausted at launch. This sounds soft but it shows up in the work. Our delivery team has more energy at the end of a project than at the start of one, because the corrosive parts of the build are no longer corroding them.
The same logic carries through everything else we ship. HDL Intelligence engagements, where we put a production AI capability inside an existing business, hit their six-to-ten-week timelines for the same reason: the work around the work is no longer the bottleneck. HDL Commerce stores onboard in weeks rather than quarters because the staging and migration scaffolding is largely solved. HDL Operate, our continuous operations retainer, costs less per client to run because the monitoring, patching and incident-response loops are themselves AI-augmented.
What this means if you are a Nordic brand evaluating partners
There are still many Swedish digital agencies that bill the way they did in 2019. The dev environment work still happens, the hours are still being logged, but the agency hopes you do not look at the line items too closely. That model is not dishonest, but it is increasingly hard to defend when an AI-native team next door is doing the same work in a fraction of the time.
If you are a performance, outdoor, marine or sport brand thinking about your next digital flagship or your next connected product, you are not actually buying code. You are buying a delivery team that can ship on time, at a fair price, with real quality. The teams that will do that consistently over the next three years are the ones that have rebuilt their workflow around models like Claude and the rest of the new toolchain, and made it repeatable. The teams that have not will spend the next three years explaining their invoices.
We have written elsewhere about our productized offer. HDL Flagship for new digital homes. HDL Intelligence for putting AI inside an existing business. HDL Commerce as a platform alternative to Shopify Plus and Centra. HDL Operate as the continuous operations partner that keeps everything running once you have launched. The reason we can sell those at fixed prices, with fixed timelines, is the kind of internal work this post describes. The model is in the workflow, not just in the demo.
If you want to see what that looks like in your business, the cheapest door in is an HDL Discovery Sprint. Two weeks, fixed price, you walk away with a finished architecture, a real plan and a real price. No proposal theatre, no estimate inflation, no hourly games. That is the new way to start.
The studios that ship in 2026 are the ones that took the unsexy parts of the work seriously. We did. The result is in the calendar, the invoice and the launch.