The problem

Datadog already had the traces. Spans, tool calls, and token counts were all collected. The problem was who could read them. Following a trace meant knowing how the agent was wired together, which ruled out the product managers and the subject-matter experts, and those were the people who could tell you whether an answer was correct in the first place.

So every conversation about quality came back to whether something felt better after a prompt change. We had no way to check, and no way to tell whether a change had made things worse somewhere we weren't looking.

How it works

What I built

• It reads production traces out of Datadog and rebuilds the whole interaction: what the user asked, which agents ran, which tools they called, and what came back. Multi-agent and multi-turn, assembled into something that can be read top to bottom instead of a span waterfall.
• The review interface lives in Backstage, the developer portal internal users already have access to. Users can now filter down to the interactions worth looking at, read them, annotate them, and score the agent's behavior.
• I built it for product managers and subject-matter experts, not just engineers. The people who know what a good answer looks like were the ones who couldn't see the traces.
• Dashboards roll up quality, reliability, latency, usage, and cost, so agent quality sits next to the operational numbers instead of in a separate deck.
• Scored interactions get curated into Datadog experiment datasets. Today's human judgments roll into tomorrow's regression suites.

The problem

Every new service needed infrastructure, and it took too much coordination and planning to keep from blocking a team waiting on infra work. An engineer would file a ticket, wait, and get back their environment or some customized Terraform module. Besides the teams left waiting, we were burning cycles on unplanned toil and error-prone work.

What I built

• A company-wide Backstage developer portal, built end to end, including custom TypeScript plugins for the service catalog, docs, dashboards, and scaffolding.
• Around 12 golden-path scaffolders that provision real production infrastructure: EKS clusters, AWS account vending, Lambda and API Gateway via SAM, Bedrock Agent runtimes, Secrets Manager entries, multi-environment ECR pipelines, and Istio + ALB internal ingress.
• Three control planes, split on purpose. Terraform for the long-lived infrastructure, ACK for IAM roles so IRSA could be granted on the fly, and Crossplane for resources born only at cluster bootstrap, like the per-cluster S3 buckets backing Thanos.
• Every path arrives wired: IRSA, GitOps delivery, and DNS managed in Terraform. Everything ships following the same patterns and organizational standards.

The problem

Every week the platform team lost time to the same thing: assisting with CI/CD issues. A pipeline fails, a team asks for help, you open the job log, you find a missing environment variable or a version that needs bumping, you push a four-line fix and wait for it to run again.

Open merge requests had a version of the same problem. One would sit with a conflict, or a failing job, or a review comment nobody had gone back to, and nothing surfaced any of it until a person happened to look.

What I built

• An internal AI engineering platform that carries work from a plain-English request, a Jira ticket, an incident, or a failing pipeline through to a tested, reviewable change. You reach it from the web, Slack, the command line, or from other AI tools over MCP.
• It finds the relevant repositories and ownership context from source, service ownership, Jira, GitLab, and Confluence, then routes to specialized agents for research, implementation, bug fixing, testing, CI investigation, operational triage, security analysis, compliance, or cloud-cost work.
• For code changes it provisions an isolated workspace, checks out the right branch, makes the change, runs the tests and validation, and opens a properly attributed GitLab merge request linked to the originating task. Tasks run async, so nobody sits watching a terminal.
• It keeps working after the first commit: monitoring pipelines, investigating failing jobs, telling real failures apart from known flakes, applying bounded fixes when authorized, and rerunning validation. QA evidence is pinned to the exact commit SHA, so a green run from an older revision can never be passed off as proof for newer code.
• An MR caretaker classifies every open merge request continuously, spotting conflicts, red pipelines, unresolved findings, stale work, and missing validation, then dispatches bounded remediation to keep it moving toward a human handoff. Approval and merge stay deliberate human decisions.
• Scheduled agents cover recurring operations: release monitoring, repository health, cost-anomaly review, security checks. On-call agents correlate alerts with service ownership, source code, deploys, and telemetry.
• The coding model underneath is swappable. The platform is the durable part: task state, workspaces, agent selection, tool access brokered over MCP with OAuth, credentials, retries, evidence, and audit.

The problem

Container builds took about 13 minutes (depending on the language/service). Across all of engineering, building many times a day, it was one of the most expensive things we ran. The AWS bill was climbing over the same period for reasons of its own.

What I built

• A remote BuildKit fleet with ECR registry-backed layer caching, which took builds from about 13 minutes to about 2.
• Two CI lanes across the core repos: a fast one for drafts, the full gate once an MR is marked ready. That also let agent-produced code iterate against real CI jobs for validation before anything reached the full gate.
• Terraform moved off laptops and into GitLab CI org-wide, with automated testing and validation, plan on merge request, and apply on merge.
• Cloud spend down 20% and holding, through KubeCost-driven optimization and application right-sizing. Earlier I designed a GCP demand-side platform that ran inside its performance requirements at about 40% under the cost projection.