Vibe Coding: From Hell to Heaven in One Insight

As an SRE, I can spin up production infrastructure in my sleep. Terraform? Give me 2 hours and you’ll have a complete ECS cluster and services with monitoring, networking, and CI/CD pipelines. But application code? That was not my domain.

Until AI changed everything.

I want to share two real-world projects where I learned to leverage AI—one spectacular failure, and one surprising success.

Project 1: The Slack App That Humbled Me (Hell → Heaven)

Week 1: The "Vibe Coding" Disaster

I decided to build a Slack application. The infrastructure? Done in 2 hours. The application code? That’s where hell began.

My approach was simple: describe what I wanted to AI, copy-paste the code, deploy, and ship.

It didn’t work.

Error after error. I’d paste the error back to AI, get new code, redeploy. Rinse and repeat. After one week of this back-and-forth, I couldn’t move forward even one step.

I was stuck in what I now call "vibe coding hell"—blindly following AI without understanding the fundamentals.

Week 2: The Breakthrough

I stopped. Took a breath. Went to Slack’s official SDK documentation and actually read it.

I learned:

• What features Slack offers
• How the SDK modules work
• The proper workflow for Slack apps

Then I went back to AI—but this time, I gave it clear architectural instructions based on my understanding. The app was done in 3 days (including learning time and one complete rewrite when I misunderstood terminology).

After that? Any new feature took minutes to implement.

The Lesson

You can’t outsource understanding to AI.

Software design and architectural decisions still come from humans. AI is a powerful assistant, but you need domain knowledge to guide it effectively.

The key insight: AI amplifies your capabilities when you provide the right direction.

This made me wonder: What happens when you combine domain expertise with AI assistance?

My second project showed me the answer.

---

Project 2: Building a Production-ready LLM Platform in 3 Days (Pure Heaven)

I had an idea: build a complete inference platform to host LLM models and fine-tuned variants.

My knowledge level: I learned the term "inference" the night before I started.

Timeline: 3 days to production-ready.

What I Built

• Infrastructure (1 hour via Terraform): Complete cloud stack
• Frontend Web UI: Full-featured interface
• 2 Backend Inference Services: Hosting different LLM models
• Automated Training Pipeline: End-to-end data processing
• Performance Optimization: 28-30 seconds → 3-4 seconds per query (pure software tuning, no hardware upgrades)

The Breakthrough

With my SRE background (system architecture, performance optimization, infrastructure patterns), I could guide AI effectively. I understood the options AI presented and could make informed decisions about:

• Architecture patterns
• Performance trade-offs
• Infrastructure design
• System integration

AI drove 80% of the implementation, but I drove 100% of the architectural decisions.

This is the power of combining domain expertise with AI assistance—you become a force multiplier.

---

What I’m Starting to Realize

After these experiences, I’m starting to see patterns (though I’m still figuring this out):

The Role Feels Different Now

I’m not writing as much code manually anymore. Instead, I’m spending more time:

• Thinking about architecture and design
• Giving AI clear direction on what I want
• Validating and refining what it generates
• Making trade-off decisions

It reminds me of when we went from manually configuring servers to writing Infrastructure as Code. The skill shifted, but we didn’t become less valuable.

My Domain Knowledge Actually Became More Important

Here’s the ironic part: My Slack app failed because I tried to skip learning the fundamentals.

The LLM platform succeeded because my SRE background gave me the mental models to guide AI effectively.

AI doesn’t replace what you know—it multiplies it.

I’m Becoming a "Conductor" More Than a "Coder"

I’m spending less time on implementation details and more on:

• Designing the overall system
• Choosing the right approaches
• Ensuring quality and performance
• Making sure pieces fit together

It’s similar to how an orchestral conductor doesn’t play every instrument but ensures everything works together harmoniously.

The Work Is Shifting, Not Disappearing

From what I’m seeing, engineering work is moving toward:

• Higher-level problem solving
• Architecture and design decisions
• System integration and orchestration
• Performance, security, and quality validation

The grunt work of writing boilerplate code? AI handles a lot of that now.

---

Coming Next: I’m planning to build a full stack of application in Rust—a language I’ve never learned. This will test whether the principles I’ve learned apply across domains. Stay tuned.

---

Follow me for more cloud architecture insights, SRE war stories, and practical lessons on thriving in the AI era.

Previous article: AWS SRE’s First Day with GCP: 7 Surprising Differences