Essays • AI and engineering • • 8 min read

AI Development Revolution Part 3: Infrastructure

Building the Organic Arts back office on AWS with AI in weeks, CDK stacks for identity, networking, compute and security, and what holding all of it in my head cost.

Isometric illustration of blue database and server blocks linked by glowing lines, two orange blocks highlighted, hands typing on a laptop in the corner

Enterprise Infrastructure at Startup Speed

Part 3 of the AI Development Revolution, the one that nearly broke me. The infrastructure got built in weeks and 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 and so was the price, and most of the price was paid in attention.

It meant long focused sessions, days at a stretch, for weeks. Debugging marathons every time an integration failed. No single problem was the hard part. The hard part was holding all of it at once, the architecture, the security, the performance, the 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 comes to 83 commits, 88,000-plus lines, 20-plus CDK stacks and 9 production domains. 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. Each stack had its own balance to find, and the integrations were where I found out 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. What came back looked perfect, an analysis of the architecture with best practices all over it and a complete CDK stack generated in one pass.

What actually happened is that 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.

The quick implementation turned into a long debugging slog, and the authentication infrastructure that came out of it is excellent. What stayed with me is that the AI's architectural suggestions need deep checking, and the productivity 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 and subnets and 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, and I had earned the tiredness that came with it. 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 work that never shows up in a commit log. I kept a mental model of fifteen-plus services live at once and checked every suggestion against the architecture in my head before it went in, asking what it would do to performance and to cost and what it would open up, and that is the work 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, with enhanced VPC routing and cross-stack resource sharing going in and monitoring and alerting added on top. 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.

Here 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 and security scanning found gaps I patched by hand. The system worked and 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. 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 checking the parts where a mistake would be expensive.

Performance came from the AI pointing at the right places, CloudFront edge caching to bring content closer to readers, 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 reliability came from checking every configuration before deployment, sending changes out small and testable, watching the monitoring in real time and rolling back the moment something looked wrong. None of that is automatic and you keep paying for it.

The economics, with the usual caveat

These figures are rough comparisons, nothing you could price a job from. Real costs swing with scope, experience, region and requirements, so read them for the direction.

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 comes to 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 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, and one developer can ship a system that would have required a team. I care about that more than the money, which comes after 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. The velocity is real and the bottleneck moves to checking the work. And the strategic call, the read on whether the whole shape is right, stayed mine. 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 and it was not free.

Part 4 takes the same approach, building it and watching it break with 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:

AWS AI development DevOps