Introduction
AI can help us write code fast, that's probably news to no one. But it can also help us configure and deploy a system more efficiently, in other words, it can do DevOps as well as development.
That's something I discovered while trying to deploy an event-driven microservices platform on AWS. Tasked with bringing a newly modernized platform to life on AWS but lacking both cloud and platform experience, I turned to AI for help.
Some context…
We were working for an automotive client that needed to modernize a platform. Using an AI-accelerated development process, we built a new event-driven microservices platform. It consisted of five production-ready microservices and more than 50,000 lines of code. One of the main requirements was that this platform integrate with the existing Dealers Touch Point (DTP) system via a SOAP API to receive customer financing requests. That meant cloud deployment was critical, we needed scalability and flexibility.
That's just the prologue. What follows is the story of how I partnered with an AI copilot to deploy the platform, and the lessons I learned bringing it live in just three days.
Managing architectural complexity
To start, let's look at the components I had to deploy. This was far from a simple sample app:
Five microservices. Each had unique requirements. One service, for example, needed Amazon S3 for document storage, another integrated with a third-party credit bureau, and a third used an external OCR function for document verification. This meant managing multiple sets of external API credentials. An event-driven core. Services were designed to communicate asynchronously using Apache Kafka. A React frontend. This was hosted on S3 and served globally via CloudFront. Containerization. The entire system was designed to run on ECS Fargate for serverless container orchestration, with images stored in ECR.
External dependencies and the mocking strategy
A major challenge was that we relied on third-party external systems for critical functions like credit bureau checks and OCR processing.
To reduce our dependency on these external APIs, we implemented a clever strategy: we built mock Lambda functions fronted by an API Gateway.
These mocks perfectly imitated the behavior and responses of the real third-party systems, and let the team build and test our services in a fast, isolated, and cost-effective environment.
AI as cloud architect: generating the Terraform blueprint
My deployment strategy was to split the configuration into two distinct parts: the foundational infrastructure (VPC, ALB, Kafka) and the microservices themselves. This approach would let us create a stable, reusable platform before deploying any application code.
To generate the Terraform code, I worked in my editor using the Cline VS Code plugin, which let me send detailed prompts to my LLM of choice, Claude. First, I tasked the AI with scripting the entire foundational infrastructure.
Once that base platform was live, I focused on deploying a single microservice. I again used the Cline and Claude combination to generate the Terraform configuration for its specific needs, an RDS database, an ECR repository, and an ECS Fargate service definition.
Human review before applying
Before applying anything, I meticulously reviewed the terraform plan output. This human-in-the-loop step was critical. I repeated the plan-and-review cycle until I was confident the changes were correct and cost-effective. This first microservice became our template.
Validating decisions with Gemini
To complement Claude's code generation, I used Gemini as a dedicated research analyst to validate my architectural choices.
This let me quickly confirm that S3 with CloudFront was our most cost-effective UI hosting solution, and that using Application Load Balancer listener rules was the standard, most secure pattern for our service-to-service communication needs.
Gemini provided data-driven confidence to move quickly on these critical decisions.
Key lessons
Cost and agility
Lesson 1: AI is a brilliant generator but needs a human cost accountant.
The initial AI-generated code was "enterprise-grade" by default: large Fargate tasks and Multi-AZ RDS instances. While robust, it wasn't cost-effective. My first and most crucial job was to act as a senior architect, meticulously reviewing every terraform plan to right-size the infrastructure and drastically cut unnecessary costs. This human oversight is critical for managing cloud spend.
Lesson 2: Agile infrastructure is a superpower for evolving requirements.
After deploying the first two services, a new requirement emerged: Service A needed to make a direct API call to Service B. Instead of a complex service discovery implementation, I simply updated our Terraform code to add new Application Load Balancer listener rules. Using path-based routing, I enabled secure service-to-service communication in minutes. This proved the incredible flexibility of an IaC setup, it could be adapted on the fly.
The operational limits of AI
Lesson 3: AI can't predict every operational pitfall.
The system was live and stable, but a few days later, a familiar cloud horror story began: the exploding bill. My CloudWatch costs were skyrocketing.
This real-world "pitfall" was a powerful reminder that AI doesn't yet have operational experience. The culprits were infinite Kafka retries, verbose logging, and cluster-level Container Insights, all requiring a human expert to diagnose and fix.
From code to cloud: the AI-generated README
One of the most mind-blowing parts of this process was that the LLM didn't just write the Terraform code. I asked it: "Create a step-by-step README for a developer to deploy this service."
It produced a flawless markdown file with the exact commands for our workflow, which used our Cline VS Code plugin, enabled with the AWS Terraform MCP server, to apply the configurations. It also included instructions for building a Docker image and pushing it to ECR. This AI-generated documentation became our official playbook.
A truly ephemeral, reproducible environment
The confidence this AI-assisted workflow gave me was immense. I could destroy the entire service and infrastructure stack with terraform destroy and bring it all back online perfectly a few minutes later.
This wasn't just a deployment; it was a truly ephemeral, reproducible, and resilient environment, built and documented with AI's help in hours, not weeks.
My final takeaway: AI + expert = unprecedented velocity
This experience was a deep glimpse into the future of cloud engineering. AI didn't replace me. It augmented me. It took on different roles, a code generator, a research analyst, a documentation writer, which let me focus on higher-value tasks: architecture, optimization, security, and cost control.
By pairing my expertise with AI's speed, I was able to deploy a sophisticated cloud platform with complex dependencies at a pace that would have been pure science fiction just a few years ago.
The future isn't about AI replacing developers; it's about developers who know how to wield AI becoming the most valuable players in the industry.
An earlier version of this article appeared on Medium.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Adservio.
STAY POSTED
Get our next analyses and field notes straight to your inbox.
