Platform Engineering: Can We Do Better with AI?

In my last posts I argued that AI for platform engineering is a different problem: two problems, in fact. The creation of valid declarative configuration, and the evaluation of the path that moves a running estate from one valid state to the next. What should the system be, and how does it safely get there. And I argued that regulated change management demands document first, then apply: stochastic processes may author; only deterministic processes may apply.

This post is about how I learned to do those two things, because the way I learned them is the whole point.

I have spent the last two decades at this layer. Global cloud infrastructure at Salesforce, a multi-cloud platform across AWS, FedRAMP and GCP at SentinelOne, CDN and DNS systems at Microsoft that became Azure products. Over those years I built up a set of structures and processes that meet the expectations of security, compliance, finance and product stakeholders, and that do not break as they scale. It took research, experience, and a large number of failures. Every one of those failures changed how I do the job. None of them was free.

If I was an AI agent, we would call this process "reinforcement learning". So can we use the same process that has educated me over the decades to train an agent?

Challenges of the system today

The system we run today has three challenges that should bother anyone paying for it.

It was designed for yesterday's problems. The definition of good evolves over time, while what we build does not. Once something is built, we are hesitant to change it, and often it is genuinely difficult to change: downstream dependencies have been made on the way it works today, and every one of them is a reason to leave it alone. Meanwhile the target moves. Standards are raised: the availability that satisfied the business two years ago is a floor now, not a ceiling. New compliant regions are delivered, and what counts as valid changes for every workload that will ever run there. Coarse rules get refined: the blanket prohibition that was right on day one meets a legitimate scenario it never anticipated, and the honest response is not an exception scribbled in the margin but a more nuanced rule that distinguishes the cases.

A compensating control tells the story best. A control cannot be implemented on schedule, so a compensating control goes in beside it: extra monitoring here, a tighter path there, approved as a stopgap. Then the original control lands. In a human system, the compensating control stays. Nobody is sure who put it there or what it was compensating for, so the safe move is to leave it, and the estate accretes another restriction that answers a problem nobody has anymore. Multiply by a decade and you get archaeology: rules whose reasons have to be excavated before anyone dares change them.

The artifacts are the solution, not the problems they solved. What remains in the platform is a conglomerate of the decisions that were made, not the reasons why they were made. The why lives at best in old documents, but the nuance lives in the heads of senior engineers, who may no longer be at the company. When one leaves, the company loses a policy paid for in years of incidents and years of nuanced trade-offs negotiated across every stakeholder: security, compliance, finance, product. The trade-offs stay behind in the configuration; the why leaves with the person. The next engineer undertakes an archaeology expedition, piecing the why back together from tribal knowledge and whoever was in the room at the time. Golden modules, review boards, restriction sets across the stack are a snapshot of the policy at the moment someone encoded it: frozen weights, no learning rate.

The learning loop is slow and painful. The reward signal arrives mostly as pain: the incident, the audit finding, the migration that destroyed data because an in-place change was not what the tool actually did. And pain at that price teaches the wrong lesson: it disincentivizes change itself. Every modification risks stepping on a landmine buried by a decision nobody remembers, with the consequence front-page news, so the rational move is to touch as little as possible, causing the system to atrophy and struggle to meet today's needs. One person's loop runs at one person's pace: the estate grows, the change rate grows, the learning slows as the environment gets more complex. A genuinely new scenario can outrun it entirely, arriving faster than the system can evolve to meet it (enter Shadow IT). And every company runs the same training run from scratch, paying the same negative rewards to converge on approximately the same rules.

What is an AI agent's role in platform engineering?

Where the industry is going is already visible: take a human role and use AI in that role. Translate an intent into configuration changes. Evaluate the risk of a change. Generate the Terraform to create the resources you want. Investigate why something broke and propose a solution. Each is a human job description with AI assisting in the seat, or filling it.

But what made the human in that seat useful was never the task. It was judgment based on global information: the unique needs of one application, the CEO doing a live demo this afternoon, the business risk of letting a development environment connect to production, the operational benefit of following an existing path instead of reinventing one for a new service. None of that arrives with the task. The agent can do the task; it does not have the judgment of whether the task should be done.

And the swap creates a new problem at exactly the layer that matters. As AI becomes capable of doing much of the work, at a scale no human team could match, how does a human retain the ability to judge without rubber-stamping? A person reviewing a firehose of AI output holds the title of judge and the function of a stamp.

I think the industry is building a local maximum. There will be short-term value, but it will not be sustained value, and it misses the larger opportunity. The seats exist where they do because a human judgment rate could match the change rate. Now the change rate can be machine throughput, and the system as designed does not function. Swap tasks piecemeal from human to AI and you have a faster version of the same machine, with thinner judgment at the gates. The opportunity is to rethink the system that solves the platform engineering problems, not to swap human tasks for AI tasks one seat at a time.

The question is not "can we make an AI a platform engineer." It is "how do we solve the platform engineering problem when we have AI as a new capability." Not a new employee. A capability with a different shape from a person: tireless, parallel, cheap to iterate. So what is AI's role in platform engineering? The shape of the system itself changes: instead of optimizing for a combination of humans and deterministic processes, as we have done for the past 20 years, it optimizes for the combination of human judgment, AI's breadth of knowledge and tireless goal seeking, and deterministic process reliability.

If we get this right, what do we get?

1. The decades of experience encoded in each platform engineer's head, shared and learned from across the industry, continually learning from new experiences.
2. Lower cost evolution of the platform over time.
3. Fewer platform incidents.
4. Higher confidence that governance controls are enforced.
5. Humans judging risk at a scale and granularity they can be accountable for.

The businesses that get this right will move faster, provide stronger guarantees to their customers, and operate at lower cost.

This is where I see Cloudstrate landing: platform engineering in the AI era, not AI bolted onto the human era. Continually evolving to handle new technologies, new requirements, new failure modes. Not a perfect static platform, but a platform that learns from the industry and from your own business requirements and scars.