Requirements in, infrastructure out: moving a managed service to agentic development

Earlier this year we helped a managed service provider move the development of its core platform, the Infrastructure as Code (IaC) that deploys and maintains customer cloud infrastructure and workloads on Azure, from Azure DevOps to GitHub Enterprise, and rebuild the way its team works around AI agents. Team members now ship real infrastructure changes by describing what they need. Senior engineers keep control through review and approval. This is what changed.

Where it started

The platform began as an Azure DevOps environment: infrastructure written in Terraform for the managed-services customers, validated and deployed through CI/CD pipelines in Azure DevOps. It worked, but it scaled with people, not with demand. One senior engineer could take on a limited number of complex tasks at a time. Delivery ran through hundreds of pipeline files, most of them customer-specific copies, so every cross-cutting change had to be repeated across all of them. Contributing meant knowing Terraform, the naming rules, the repository structure and its logic. Knowledge lived in one head.

The move

We first put the GitHub Enterprise itself under code, then moved the platform’s repository with its full history and migrated all pipelines to GitHub Actions in a single week. The hundreds of pipeline files collapsed into one reusable deployment template that fans out over every customer and environment from configuration, plus a thin workflow per feature. A change that used to be edited in every copy is now edited once. Onboarding a customer became a configuration file, and that file is created by an AI agent from a plain-English request raised as a GitHub issue.

Governance as code

Identity, teams and permissions come from Microsoft Entra ID and are created by code. Branch protection is set at organisation level and cannot be relaxed by a repository admin: every change needs an approving review, and production deployments pass through a human approval. The rules are the same for a person and for an agent, and a person is always in control.

One rulebook for people and agents

The team keeps one central set of instructions that every agent picks up for any task it performs: how the repository is organised, the naming conventions, which tools to use, how a change is tested and how a pull request is written. The same rules run as checks on every pull request and as hooks on every developer’s machine, so a rule that matters is enforced, not just written down.

These guardrails are what make it safe for less experienced colleagues to contribute: the agent follows the rulebook, the checks catch what it gets wrong, and a senior engineer has the final word.

The new way of working

Anyone on the team describes what they need as a GitHub issue, often drafted with GitHub Copilot, and assigns it to a coding agent. The agent opens a pull request. The checks run. A senior engineer reviews, asks for changes where needed and approves; the agent iterates in the same pull request. The merge triggers the deployment, and production still waits for a human approval. Nobody in the first step touches code.

The senior engineers use AI assistants interactively for design, debugging, review and operations, and that work lands as reviewed pull requests like any other.

What changed

• Velocity. In the first month after the move the agents delivered dozens of merged changes on their own, and they have kept delivering since. Today roughly a third of all merged changes are written by agents, and most are accepted after a single review round.
• Time to release. A well-described request typically goes from issue to merged change within a day, with the deployment following automatically, and many such requests are completed in the same day.
• Complexity. Hundreds of pipeline files became one template. Formatting, documentation and status reporting are done by bots. A failed nightly deployment opens its own ticket instead of waiting to be noticed. The senior engineers could have built all of this themselves; what AI changed is the time frame, finishing it in a window no human team could have met.
• Quality. Every change, by a person or an agent, passes the same checks and the same review. The rules live in the repository, and the audit trail runs from request to production.
• Team capacity. The engineer who used to write most of the code now reviews and decides. A second engineer’s contribution grew more than tenfold. Two more colleagues ship changes by describing them. The single point of failure is gone.

What it saved

As an estimate, the agent-written changes alone represent roughly two to three engineer-months in the first eight months, after subtracting the review time they need. The larger gain is harder to count: senior time spent on design and review instead of routine changes, and a backlog that no longer waits for one person.

What we learned

• Agents need enforceable rules, not prose. Every guideline that mattered became a check.
• The quality of the request decides the quality of the result. Writing acceptance criteria is the new core skill.
• Review is where seniority pays off. The team moved its best people to the point of most leverage.

We live by example

Our own infrastructure, documentation, website and GitHub organisation are run the same way: requests become issues, agents do the work, every change is a reviewed pull request behind automated checks, and a decision log and runbooks keep the audit trail. The page you are reading was produced that way.

AI does not replace seniority, and it does not rule it out. It multiplies what a team can deliver when the rules are clear and the senior engineers hold the final say. See what we offer in AI and agentic development and team enablement.