Vibe Coding: From Hell to Heaven in One Insight

Source: Dev.to | Dec 15, 2025 (UTC)

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.

My Personal Takeaway

I’m an SRE who can now ship full-stack applications in days—not because I became a better programmer, but because I learned to combine my domain expertise with AI capabilities.

From one week stuck in vibe coding hell to shipping a production LLM platform in 3 days—that’s the journey AI enabled for me.

The key difference? Understanding that AI doesn’t replace expertise. It amplifies it. My SRE background in system architecture and performance optimization became more valuable, not less, when combined with AI’s implementation capabilities.

What excites me: I can now build things that were completely outside my skillset just months ago.

What I learned: Domain knowledge + AI assistance = force multiplier. But skip the fundamentals, and you’re just spinning your wheels.

This is just my experience from one engineer figuring out this new world.

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