AI Development Revolution Part 3: Infrastructure
Building enterprise AWS infrastructure in weeks with AI. CDK stacks, production systems, and the cognitive cost of compressed timelines.
Enterprise Infrastructure at Startup Speed
Part 3 of the AI Development Revolution. This is the one that nearly broke me. The infrastructure got built in weeks. The cost came out of my body.
One mind holding everything
The usual way to build enterprise infrastructure is a team of specialists and a few months. I had myself and an AI, and I did it in weeks. The speed was real. So was the price, and the price was cognitive.
It meant long focused sessions, days at a stretch, for weeks. Debugging marathons every time an integration failed. The hard part was not any single problem. It was holding all of it at once: architecture, security, performance, cost, twenty-some AWS services that all touched each other. A team spreads that weight across people. Alone with the machine, it all sat in one head, mine. The body kept score. Back pain, eye strain, headaches, sleep that stopped showing up.
I wrote about that stretch at the time, in "The Multithreaded Mind". Running at machine speed while trying to keep human judgment intact.
What the commit log doesn't show
The oa-backoffice repo, by the numbers: 83 commits, 88,000-plus lines, 20-plus CDK stacks, 9 production domains, zero production defects. The numbers are true and they hide everything that mattered. Foundation layers for identity and networking. Compute and storage. Application layers tuned for global delivery. Security threaded through all of it. Every stack was a small lesson in balance, and every integration was a test of how long I could keep concentrating.
The authentication stack
"We need enterprise-grade authentication," I told the AI. Cross-account access, MFA enforcement, service-specific permissions, integration with the existing VPC. The response looked perfect. Architecture analysis, best practices, a complete CDK stack generated in one pass.
What actually happened was different. It missed security dependencies and I spent hours untangling circular IAM policies. Its "best practices" fought my use case, and I redesigned after the deployment failed. Code that worked in isolation broke the systems around it. It overlooked the VPC endpoint requirements, so authentication worked from the public internet and failed from inside the network.
What was sold as a quick implementation turned into a long debugging slog. The authentication infrastructure came out excellent. The path there was brutal. The lesson stayed: AI architectural suggestions need deep validation, and the productivity gain only shows up after you survive the learning curve.
The networking marathon
I sat down one session to build the complete networking infrastructure. I did not expect the real difficulty to be holding the whole picture steady while the AI kept handing me pieces.
The start felt like flying. VPC, subnets, route tables, all configured fast. Security groups generated quicker than I could read them, which felt like superhuman productivity right up until it was the problem. Then the load balancer integration broke assumptions I had already built on. The AI fixed each local issue and created system-wide ones doing it. I had to go down into AWS networking myself to check its recommendations. CloudFront configuration collided with the VPC setup, and the AI could not reason about how the two services interacted. Debugging that meant understanding both the generated code and the AWS internals underneath it.
Four hours in, it worked. I had rewritten three of the AI's modules where its patterns did not match mine. The win felt earned. The exhaustion was real. Testing then turned up performance issues it had not anticipated, and a security scan found five configuration problems in the generated code. The optimization at the end needed knowledge the AI did not have.
What made it possible was the hidden work nobody counts. Keeping a mental model of fifteen-plus services live at once. Checking every suggestion against the architecture in my head before it went in. Weighing each recommendation against performance, cost, and security. That is the part that empties you out.
The day it almost all went down
One day the log says 34 commits across three repositories, a lot of infrastructure moving across a lot of stacks. The log does not say how close the whole thing came to falling over.
It started well. Enhanced VPC routing, cross-stack resource sharing, monitoring and alerting added. I was confident and the collaboration felt smooth. Then the cross-stack dependencies broke the moment they deployed together. The monitoring stack could not reach VPC resources because of IAM, and when I tried to roll back, the rollback broke production. I went into agent mode for an emergency debug.
This is where the AI made things worse. Its "quick fixes" broke other systems. I had to read the CloudFormation templates by hand to find the root cause, and what I found was that it had built circular dependencies across four stacks. Once I isolated the wrong architectural assumption underneath all of it, I could see the shape of the fix. I rebuilt three stacks from scratch with the corrected design, exhausted, set on finishing before I lost another day. Performance testing afterward found things to optimize. Security scanning found gaps I patched by hand. The system worked. I was empty.
I took two full days off before I could develop again. A day like that is not something you can do twice a week. Blue/green deployments are what kept the next round from going the same way.
What got built, and what it cost in time
The security came out enterprise-grade. Identity and access with least privilege, private subnets and security groups and NACLs, encryption at rest and in transit, CloudTrail and GuardDuty and Security Hub for monitoring, SOC 2 and GDPR frameworks. A security architect might spend two or three weeks designing and implementing that. With the AI it was hours, but only because I was already holding the design in my head and validating every line.
Performance came from the AI pointing at the right places. CloudFront edge caching cut latency by about 60 percent. Auto-scaling tied to usage. Reserved instances and spot fleet for cost. For disaster recovery, multi-AZ failover, continuous backups with point-in-time recovery, and infrastructure as code that can rebuild the whole environment from scratch.
The zero-defect record was not luck. Every configuration got checked before deployment. Changes went out small and testable. Monitoring watched in real time, and rollback was immediate when something looked wrong. None of that is automatic. It is a discipline you keep paying for.
The economics, with the usual caveat
These figures are rough comparisons, not a quote. Real costs swing on scope, experience, region, and requirements. The point is the direction, not the decimal.
The traditional version of this needs a senior architect, several DevOps engineers, a network engineer, a security specialist, and someone to manage the coordination, all running across months. It lands in the six-figure range and carries real risk from integration and scope creep. The AI-assisted version was one developer at full allocation on a compressed timeline, a modest monthly AI subscription, and the AWS bill for dev and test. Five figures, weeks instead of months, and lower risk because the feedback was continuous.
What the savings actually buy is reach. A small team can build infrastructure that used to need a full department. A startup can match an established player on technical depth. One developer can ship a system that would have required a team. That is the part worth caring about. The money is downstream of it.
What I'd carry forward
A few things held up across every stack. The AI is good at designing one piece and weak at the seams between pieces. When its systems fail, debugging means understanding both what you meant and what it actually wrote, which is two problems at once. It buys you velocity and hands you the quality check as the new bottleneck. And the strategic call, the read on whether the whole shape is right, stays human. The machine did not have it.
I once called this kind of work "vibe coding", the line between what I bring and what the machine brings going soft. Infrastructure is where I felt how soft it really gets, and where the body told me the rest. It worked. It was not free.
Part 4 takes the same approach, build it, watch it break, keep a person reading every output, and points it at years of my own writing instead of AWS.
Next: Part 4: The Content Pipeline →
Series Navigation:
- Part 1: The Awakening
- Part 2: The Methodology
- Part 3: Enterprise Infrastructure (Current)
- Part 4: Content Revolution
- Part 5: Business Transformation
- Part 6: Future Implications
- Part 7: Advanced Patterns