neurons firing from a keyboard

thoughts about devops, technology, and faster business from a random guy from dallas.

Carlos learns to vibe code, Day 1

Reading Time: Approximately 3 minutes.
View this post on GitHub.

So, I don’t like LLMs. I’m optimistically terrified of their long-term impact to society.

I also know that I’ve grown to like stuff that I’ve held strongly-negative opinions on, like vim, Ruby, Kubernetes (I was a huge Kubernetes hater when it first got popular!) and Golang after forcing myself to use them for two weeks or so.

Given how you can count on finding somebody using ChatGPT to look something up on any given day in some public space, I determined that it was time to give Big AI™ it’s two weeks.

I’ve been introducing ChatGPT and Kagi Assistant into my web search workflow. It’s going okay, though it still gets things wrong a fair amount of the time.

However, I’ve decided to trust fall my way into letting LLMs into my professional life. I’m putting on my Oakleys and going full speed into Vibe Coding.™

This post series will document my adventures into using Claude Code to author an app I’ve been wanting for myself for a long time: an IFTTT-like app for syncing my online presence based on external events.

Best case: Claude Code becomes life and I spend the rest of my six-month career as an AI influencer.

Worst case: I have some shiny stuff to put on my resume.

The App

My first vibe code experiment

Many years ago, I wrote a simple Ruby app that changes my Slack status based on the names of trips in my TripIt account. As a DevOps consultant that traveled every week, I needed a service like this to tell other people where I was without having to do so manually in Slack.

The app relied on two other services that I also wrote:

  • A service that authenticated into my employer’s Slack workspace and handled status getting and setting, and

  • Another service that authenticated into my TripIt account and retrieved trip details.

My Ruby app hit scaling limitations fairly quickly. Adding new event sources and status handlers, like Google Calendar and WhatsApp, became cumbersome to impossible. Life and work hampered progress, too. Over time, my app became more crusty, more outdated, and, most importantly, more unscalable.

I took a week-long solo vacation to Portland many years ago to rewrite my status handling app into something more event-based. While I learned a lot about sync.WaitGroups and the limitations of goroutines and channels, I only got as far as building the framework for the app. I didn’t have enough time to write the listeners and handlers. Life and work took ofter again, and the rewrite staled once again.

Anyway, I’m going to build the rewrite, come hell or high water! And I’m going to outsource the task to my new mandatory best friend, Claude.

Approach

This is the roadmap for how I’m going to do this:

  • Go almost all in and purchase a $20/month Anthropic subscription (I’ll upgrade to the $200/month Max subscription if this goes really well)

  • Use a basic prompt describing my design, requirements and acceptance criteria

  • Use another prompt to write code to deploy infra components into AWS.

  • Slowly incorporate agentic capabilities by adding some tools to handle deployment.

If this goes well, I’ll re-attempt all of this with another project I have in my to-do list, but with a local LLM running on a beefy Mac studio that I’ll acquire.

Alright! Enough stage setting! Let’s get to work.