Case Studies
The work, with receipts
Long-form write-ups of selected projects. Every number below is measured — the table under each study says exactly how it was tested, and what was simulated versus verified in CI or merged upstream.
01 · 2026
Cutting incident detection time 45% with an AI root-cause agent
PythonCoral MCPFastAPIDockerGitHub Actions
An enterprise AI agent that correlates logs, metrics, and traces through a Coral MCP query layer to rank root-cause hypotheses during incidents.
The problem
During incidents, engineers burn critical minutes manually correlating telemetry across disconnected tools while users stay impacted. The goal: compress the correlation phase to seconds without sacrificing accuracy.
The approach
- Orchestrated multi-source telemetry (logs, metrics, traces) behind a single Coral MCP query layer.
- ML models rank root-cause hypotheses and surface actionable insights to the responder.
- Validated behavior with failure injection across simulated incident scenarios.
Measured results
| Metric | Before | After | Change | How it was tested |
|---|
| Mean time to detect (MTTD) | Manual triage baseline | Agent-assisted triage | -45% | Timed across repeated simulated incident scenarios with injected failures |
|---|
| Automated tests | — | 281 shipped | +281 | CI suite counts on the production pipeline |
|---|
| Failure classes covered | — | Failure-injection suite | covered | Fault-injection test matrix in CI |
|---|
Methodology. MTTD numbers come from a simulated environment with scripted failure injection — not yet validated against live production incidents.
02 · 2026
Framework-level SSR fixes merged into Cloudflare vinext
TypeScriptReactNext.jsNode.js
Seven-plus production PRs fixing SSR context, routing, module resolution, and test coverage in a framework running at the edge.
The problem
SSR gaps blocked CSS-in-JS users (Apollo, styled-components, Emotion), and duplicated request-handling code hid security issues flagged by CodeQL.
The approach
- Extracted shared request-handling utilities into a single request-pipeline module.
- Exported ServerInsertedHTMLContext to unblock CSS-in-JS SSR consumers.
- Backfilled snapshot and E2E tests around entry templates and routing context.
Measured results
| Metric | Before | After | Change | How it was tested |
|---|
| Duplicate request-handling code | 1,627 duplicated lines | Single request-pipeline.ts | -1,627 | PR #258 diff stats, reviewed and merged upstream |
|---|
| CodeQL security findings | 6 open alerts | 0 in touched paths | -6 | CodeQL scan on the merged PR |
|---|
| Entry-template test coverage | 0% | 100% | +100pp | Coverage report from PR #345 snapshot suite |
|---|
| Tests added across PRs | — | 37+ unit, integration & E2E | +37 | Summed from merged PR diffs (#258, #151, #197, #620) |
|---|
Methodology. All numbers are from merged upstream PRs — diff stats, CI coverage reports, and CodeQL scans are publicly verifiable on GitHub.
03 · 2025
Instrumenting a service so alerts beat user reports
JavaSpring BootPrometheusGrafanaGitHub Actions
Full-stack observability pipeline: a 4-stage CI/CD flow plus Prometheus metrics, Grafana dashboards, and multi-channel alert routing.
The problem
Services shipping without instrumentation mean failures get reported by users instead of alerts — the most expensive way to find out.
The approach
- Built a 4-stage pipeline: build, test, security scan, deploy.
- Instrumented a Spring Boot service with Prometheus metrics and Grafana dashboards.
- Added synthetic testing and alert routing to multiple channels.
Measured results
| Metric | Before | After | Change | How it was tested |
|---|
| Pipeline stages | — | Build · test · security scan · deploy | 4 gates | GitHub Actions workflow definition in the repo |
|---|
| Detection path | User reports | Alert routing + dashboards | proactive | Synthetic checks firing alerts in test runs |
|---|
Methodology. Pipeline and alerting behavior verified through repository CI runs and synthetic test alerts.