Contact
Open to work · APAC · remote · hybrid Auckland --:--

Closing the gap between it works and it ships.

viewing as

See it in 60 seconds
scroll down, or press Menu

01 — the gap

Most systems work on a laptop. Far fewer ship reliably, every day, to millions of real customers. The distance between those two things is where I've spent the last seven years. I rarely remember the clever fix. What I remember is the pattern that meant nobody ever had to fix it again.

← it works chaosorder it ships →

02 — Frankfurt · Lufthansa via IBM · 2018–2020

Keeping a global airline's digital experience in the air.

In plain EnglishI kept the Adobe platforms behind Lufthansa's website and customer campaigns running, and made sure only the right people could change them.

My first production job was DevOps Engineer at Lufthansa, running Adobe Experience Platform, which serves their customer-facing site, and Adobe Campaign, which runs their customer campaigns. Both were business-critical and used by teams on every continent.

  • Instances, deployments, upgrades, certificates. All handled with minimal disruption to live operations.
  • Access governance. Roles and permissions across globally distributed teams and agencies, with monitoring and audit checks.
  • Under the hood: Adobe Experience Platform and Adobe Campaign instance management, deployment scheduling and upgrades across timezones, and certificate lifecycle management.
  • Why it mattered: one wrong permission could expose customer data or push a campaign live in the wrong market.
Adobe Experience PlatformAdobe CampaignAccess governanceRelease mgmtGerman 🇩🇪

03 — London & New York (remote) · Burberry, Macy's via IBM

Turning deploy day from a gamble into a standard.

In plain EnglishI made releasing new software safe and routine for two global retail brands.

At Burberry, each client team was shipping in its own way. I built the CI/CD and infrastructure automation, then set the deployment standards every pipeline had to meet. At Macy's the stakes were retail uptime, so I automated operations in Python and Bash, with monitoring that caught anomalies before shoppers did.

  • Deployment standards that made pipelines measurably more reliable across client teams.
  • Automation first for high-availability retail systems, with alerting tuned to catch anomalies early.
  • Under the hood: quality gates, image scanning, canary releases and automated rollback, rolled out across Jenkins and GitLab.
  • Why it mattered: defects caught where they're cheap to fix, not in front of customers. Recognised with the Burberry Shining Star.
CI/CDJenkinsPython · BashMonitoring🏅 Shining Star

04 — Mumbai → New Zealand · Vodafone NZ via Infosys

Multi-cloud Kubernetes that survives a bad day.

In plain EnglishI kept a telco's systems online across two clouds, and broke things on purpose to prove they could recover.

This was a telco on AWS and Azure at once. I built CI/CD pipelines with Jenkins and Docker, ran multi-cloud Kubernetes with Terraform and Ansible, and did the root-cause analysis when things broke. Then I broke things deliberately, as a Gremlin-certified chaos engineer.

  • Multi-cloud K8s on AWS and Azure, fully managed as infrastructure-as-code.
  • Incident RCA with Nagios and Splunk to keep production reliable.
  • Under the hood: EC2, S3, ELB and RDS provisioning, probes, autoscaling and failover, plus Python and Bash automation versioned in GitLab.
  • Why it mattered: failures got found on a Tuesday afternoon, not at 3am. SLOs made reliability something you could negotiate.
KubernetesAWS · AzureTerraform · AnsibleSplunkGremlin ×3

05 — Auckland · One NZ via Infosys · 2023 → now

Teaching operations to think, and to wait for a human.

In plain EnglishI build AI assistants that spot outages early, find the cause, and suggest a fix. A human always approves it.

I'm a Site Reliability Engineer for generative and agentic AI. I build the AI-native observability layer and incident agents behind One NZ's Journey Reliability Engineering, which was featured in the Financial Times. The agents run grounded DQL on Dynatrace Grail, correlate journey health across OpenShift, MuleSoft and Kafka, and act on customer impact before it turns into an outage.

“An observability agent that hallucinates incidents is just an anxious colleague with API access.”
  • Agentic AI: multi-agent workflows with tool use over MCP, connected to enterprise data platforms.
  • RAG and LLMOps: hybrid search, reranking, golden-set evals, tracing, prompt versioning, guardrails, and cost and latency tuning.
  • Legacy → cloud migration: −30% opex (~$150k/yr), −60% maintenance, provisioning cut from 2 days to 4 hours.
  • Under the hood: Python/FastAPI, Claude and OpenAI, LangGraph, vector DBs, Ansible Tower, Terraform and Azure DevOps. I'm also the DevOps platform admin across Git, Jira, Splunk and Nagios.
  • Why it mattered: 75% faster issue resolution, with responsible AI (personal data, access control, prompt-injection awareness) built in from day one. Named a One NZ Champion.
MCPClaude · OpenAILangGraphDynatrace GrailRAG · evals🏆 One NZ Champion

06 — the receipts

Reliability, converted into business value.

$0ksaved every year after the One NZ legacy → cloud migration
0%faster issue resolution with real-time dashboards and AI triage
0%maintenance overhead, and −30% operational cost
2d4henvironment provisioning with Ansible Tower accelerators
FeaturedFinancial TimesJRE × One NZ × Infosys
AwardsOne NZ ChampionInfosys Star of the Quarter · Burberry Shining Star
CertifiedGremlin Chaos ×3Generative AI · AZ-900 · Cyber Security in SDLC · Adobe XP
Community2,500+ followerswriting about AI that actually matters

07 — how I think

Notes from the field.

keep scrolling, or use the arrows →

on observability agents

“An observability agent that hallucinates incidents is just an anxious colleague with API access.” We spent most of the effort keeping the AI grounded.

— on the FT-featured JRE work
on AI coding agents

The model is rarely the bottleneck. The context around it is. Treat context as an engineering surface: snapshot it, version it, review it.

— context engineering
on benchmarks

Every benchmark the community optimises against eventually degrades. The pressure to show progress ends up corrupting the scoreboard.

— on the SWE-Bench Pro audit
on AIOps

The goal isn't fewer engineers. It's fewer 3am wake-ups for the same repeat failures.

— Kubernetes is learning to fix itself
on conferences

The talks are fine. The useful part is someone telling you quietly, over coffee, what they tried that didn't work.

— NZ Tech Expo ’26
more on LinkedIn

Sharing AI that actually matters, and helping PMs ship faster and break less.

linkedin.com/in/darshilkothari7 ↗

08 — the lab

Don't take my word for it. Break something.

Pick one on the left and follow the numbered steps. Six pieces of production work, rebuilt as live simulations that run entirely in your browser. The data is representative, but the mechanics are the real ones.

Pretend something breaks, then watch an AI find the cause.

  1. 1Pick a problem
  2. 2Press Inject fault
  3. 3Watch the AI investigate
  4. 4Press Approve remediation

Problem. One customer journey crosses 6 systems. When it breaks, everything alerts and people argue about where the fault is.

Built. Agents on Dynatrace that run grounded DQL over MCP, cite evidence for every claim, and ask a human before acting.

Value. 75% faster resolution, with customer impact handled before it becomes an outage.

journey-agent.live · prepay-topup● nominal
journey success99.4%
agent idle · waiting for signal…
time to root cause--manual ≈ 25–40 min (illustrative)
evidence-linked claims--no citation, no claim

09 — handshake

Let's ship something that stays up.

Auckland, New Zealand · open to APAC, remote and hybrid · English, German
Built with three.js, GSAP and plain JS. No trackers, and every simulation runs in your browser. ©

60-second read

Darshil Kothari: SRE, Platform & Agentic AI Engineer

EmailCVLinkedIn