Atlas

What it is

Atlas is an event-driven engineering management platform I built for a professional services firm's engineering org. It tracks the full lifecycle of engineering work, from PRD intake through deployment, and computes DORA metrics from real delivery events. The core is a Go service exposing 33 REST handler groups and over 95 endpoints, backed by PostgreSQL, Redis, and Apache Pulsar. Six Python AI agents handle PRD extraction, sprint planning, risk analysis, DORA insights, code review, and search indexing.

Two frontends serve different audiences: a React + Vite admin dashboard with 13 pages for engineering managers, and a Next.js portal where non-technical staff submit PRDs and track requests. An MCP server with 14 tools lets LLMs query and act on the system directly.

Every request moves through a finite state machine: draft, submitted, in_review, approved, in_progress, in_staging, deployed, completed, with rejection, blocking, and cancellation paths. Transitions are transactional with row locking, and each one appends to an immutable audit trail.

Why it matters

Engineering managers need delivery data they can defend in front of partners. Atlas computes all four DORA keys (deployment frequency, lead time at P50 and P90, mean time to restore, change failure rate) from deployment events, and rates performance against the 2023 DORA report bands. The insights agent turns those numbers into plain-language explanations, because the product principle is that data tells a story rather than filling gauges.

Feature intake stops being a chat backchannel. Requests go through time-boxed voting (default 7 days, default 60% approval threshold), and a Temporal workflow closes the vote at the deadline and auto-creates a PRD for approved items. Submitted PRDs are then extracted into epics, stories, and risks by an agent instead of a manager's afternoon. GitHub and Jira stay in sync through webhooks plus a 90-day API backfill.

Architecture decisions

Go for the core, Python for the agents. The FSM and audit trail want strict transactional semantics and small attack surfaces, so the Go services ship as stripped, reproducible distroless binaries with no shell. The agents iterate against the Claude API, where Python and fast edits matter more than binary size.

Apache Pulsar carries events; Temporal carries anything long-running. Vote auto-close, DAG execution, and backfills are durable workflows, not cron jobs. The visual workflow builder (10 node types, cycle detection, draft to validated to published lifecycle) compiles to Temporal executions rather than a homegrown runtime, which was the deliberate omission: no bespoke workflow engine to maintain.

Two frontends on purpose. The admin app is a dense power tool; the portal is a guided flow for partners submitting requests. One shared app would have made both worse. HelixDB indexes extracted PRDs in the background for semantic search, and the MCP server is a first-class surface: the same 14 tools a human workflow uses, exposed to LLMs under the same OIDC authentication.