What I Found Auditing an AI-Built Cloud Migration
AI can write the code. It takes expertise to know if it’s right, and leadership to listen.
I recently audited an AI-driven cloud migration of a regulated enterprise SaaS platform. On the surface it looked like a success. Services were running in the cloud, features were shipping, and the migration had progressed far faster than a traditional rewrite.
Then I looked beyond whether the services were running.
I looked at whether the architecture still held, whether the system could scale safely, and whether the controls that made it compliant had survived the migration.
What I found was a reminder that getting software to run is not the same as engineering it to work reliably in production.
The setup
The platform is a multi-tenant regulatory SaaS system, where every action must be traceable, audit trails must be tamper-proof, and one client’s data must never be visible to another. It was built on a few non-negotiable rules. Each tenant had its own isolated database schema, all data access went through one controlled service, and internal services were never exposed to the outside world.
The platform was moved to containerized services on Azure, with the AI tools directed by people who knew the features they wanted but not every rule the cloud architecture depended on.
What I found
Services multiplied. Asked for a feature, the AI tended to create a new service rather than extend an existing one, and many carried leftover configuration from the old application server.
Everything was public. Every service endpoint was reachable from the internet, with no gateway in front.
Secrets lived in configuration. Credentials and API keys sat in container environment variables.
The governed data path was bypassed. Services connected to the database directly, skipping the one place where tenant isolation and audit capture were enforced, and the database began running out of connections.
Scaling broke assumptions. Caches and sessions held inside each instance stopped agreeing once more instances were added.
Get Rashmi Ramaiah’s stories in your inbox
Join Medium for free to get updates from this writer.
AI reviewed AI. Pull requests were written with AI and then reviewed with AI. The review step existed, but a change could reach the codebase without any person fully understanding it.
The most dangerous finding was the quietest. A proposed flexible data model stored the meaning of fields in a shared, editable table, so a later change could silently alter what historical audit records meant. In a regulated system, that is a compliance failure waiting to happen.
Why it happened
The tools were only part of the story. The bigger cause was a belief that if AI can write code, engineering is no longer needed. When an AI produced working code in minutes, it seemed natural to conclude that any change could be made in a day, and that months of careful engineering were an unnecessary cost.
The reality was different. Even a single UI change could take close to ten prompts before it worked, a change an experienced developer could have implemented in seconds. Each attempt cost money, and each one risked changing something else along the way. The money saved by not paying for expertise was spent on uncertainty instead, through repeated prompts, rework and fixes that often created more problems than they solved.
AI can generate code in minutes, but someone still has to judge whether that code is right. That takes expertise, the kind that comes from knowing the system well enough to see what a plausible-looking change will quietly break. And expertise only helps if it is heard. In this migration, the advice was given by people who knew the system best. What was missing was the willingness to listen. When a fast answer from a tool is valued above the judgement of someone who has already built and run the system, the problem is no longer technical.
There is often a double standard, too. Experienced engineers are told that AI can now code as well as they can. Yet when they deliver careful work, such as an audit or a design review, the question becomes whether they wrote it or an AI did. AI is trusted enough to replace experience, but experience is doubted the moment AI might be involved. You cannot have it both ways.
What I’d tell any team
I use AI tools in my own projects, and this is not an argument against them. The answer is not to stop using AI. It is to give it structure, and to make sure the people directing it are guided by someone who understands what it is actually producing. These lessons came out of this audit, but they apply to any team.
- Write down your invariants and requirements. A prompt is not a requirement. Record what must never break, and what each change must achieve, before anyone asks an AI to build it.
- Communicate as a team, not as separate prompts. Each person’s conversation with an AI is invisible to everyone else. Shared decision records keep the system from drifting in several directions at once.
- Reuse before you create, and stay inside the guardrails. Reuse existing code and services instead of generating new ones for every request. When a new service is genuinely needed, it must follow the platform’s established controls for tenant isolation, authorization, and audit capture. Any deviation requires an explicit architectural decision.
- Understand before you merge. If no one can explain what AI-generated code does, it doesn’t ship. Release through reviews and staging, not straight to production.
- Trust proven experience over confident output. AI answers sound authoritative. An engineer who has already designed and delivered the system knows what breaks in production. Give them real authority, and treat their concerns as a reason to stop and check.
- Choose stability over speed. Clients stay because the system works every day, not because a feature arrived early. In regulated software, one outage or data integrity issue costs more than any feature is worth.
AI accelerates whatever process you already have. With clear rules and real review, it’s a genuine multiplier. Without them, it multiplies risk, quietly, one reasonable-looking change at a time.
