ATLAS: one platform for 4,000+ engineers

Before the platform, a new engineer's first useful commit was 40+ days away, and most of that time was setup: the right tools, the right versions, the right access, learned from whoever sat nearest. The company's tooling was discovered in a browser, installed from a wiki, and run in a terminal, and nothing connected the three.

Delivery had the same shape. Pipelines ran across seven tools (uDeploy, Ansible, Terraform, AWS CodePipeline, Jenkins, GitHub Actions and Harness), each with its own templates. When the company moved from on-premises Checkmarx to Checkmarx One, the platform team updated template after template and then worked with application teams to update thousands of individual pipelines. One change, multiplied by seven tools and every pipeline built on them.

A CLI, the HIG CLI, in use on 4,000+ machines, and a desktop agent active on 2,000+ devices. The agent connects the browser to the CLI: a button on the platform's site runs a native command on the engineer's machine. Both ship as a standard software package.

Guided onboarding that never leaves the browser until it needs to. Three built-in walkthroughs: one sets up the machine with the CLI in a terminal embedded in the site, one opens a chat window on the site that talks to Copilot through the CLI on the engineer's own machine, by way of the desktop agent, and one opens VS Code and walks through the extension and the parts of the editor that matter on day one. Beginner and advanced CLI walkthroughs follow, refined and certified by the platform's team in India, and the AI engineering team is writing new ones for enterprise AI tools such as the AWS and Jenkins MCP servers as they are onboarded.

A local setup catalog where engineers install what the company has already vetted: 120+ skills, 10+ MCP servers and 10+ agents, discoverable in one place instead of in someone's chat history.

Policy as configuration. OPA-backed policy decides which tool versions run on which CI platform and which scans run where, so compliance is a config change rather than a template edit. And one build command that builds any project the same way locally. That build system was my manager's work, designed and built in parallel to the rest of the platform; my part was learning it and bringing the team along, and ATLAS is built around it.

The need for this part was concrete before it was a design. During the GitHub Enterprise Cloud migration, usage analysis kept turning up pipelines that teams had built outside the program's knowledge, and for the whole of the migration the inventory was a spreadsheet updated by hand every day. The platform needed a way to see for itself: real-time pipeline monitoring, observability, compliance and controls, and enough discoverability that application teams could keep their own pipelines current and retire the stale ones. That capability is being built into ATLAS today.

Telemetry was first-class from the start, not an afterthought: the CLI shipped with OpenTelemetry instrumentation on day one, the IDE extensions followed early, and the desktop agent after that, so the platform has had monitoring dashboards and usage statistics for as long as it has had users. Pipeline events and that CLI, IDE and desktop telemetry flow through Amazon EventBridge into AWS, with DynamoDB holding the live, lookup-shaped data the dashboards read. An in-house health status page, Statuspage in style but covering internal and external tools and fully customizable, lets anyone in the company subscribe to alerts, so a platform problem announces itself before the tickets do. And MCP servers and out-of-the-box skills let AI agents query and operate the enterprise CI/CD systems safely against the same data.

What it has not produced yet is a result. The Firehose delivery that lands the full history in Snowflake is being stood up now; its purpose is ML analysis of where developers lose time, and that analysis has no findings yet. Incident and ticket reduction is not instrumented directly, so there is no figure here, and I would rather leave the gap than invent one. The data has found a use the platform team did not build, though: another team's tool for triaging and root-causing incidents in real time reads the platform's data to add context to each incident and show the engineers involved what happened and why.

The unified surface reached 1,000+ active engineers in its first 90 days. The desktop agent reached the same number in a day, because it shipped to everyone who already had the CLI. A new machine now goes from unboxed to productive in hours, against the 40+ day baseline.

This section is plans, not results. The remote build server is in progress: the same build command with a --remote flag will run on platform compute instead of the laptop, and on every push and pull request for real-time feedback and analysis.

That is the path off the seven pipeline tools. With builds on platform compute and policy already in configuration, pipelines consolidate onto one platform with OPA controls built in. The Checkmarx One migration is the kind of change that would then be a reconfiguration in the CLI, applied once, rather than a campaign across tools and teams. The 95,000+ pipelines the platform supports today are the population this is designed for; none of it is claimed until it lands.

Ship the next surface to the people who already have the last one. The desktop agent got a quarter's adoption in a day because it did not ask anyone to start over.

Put policy in configuration before you consolidate anything. Once tool versions and scans are config, the tools underneath become replaceable.

Make discovery a product surface. A catalog of 140+ vetted skills, servers and agents is the difference between AI tooling that exists and AI tooling that gets used.

Make telemetry first-class on day one. Instrumenting the CLI with OpenTelemetry before it had its first user is the reason there has never been a week without usage data, and it is what makes the data readable by agents at no extra cost.