A logo that was completely generated with AI, like everything else in the project. (Source: ChatGPT)

I don’t mind the term “vibe coding“, when used correctly. A lot of people (at least on Reddit) seem to think it means “any time you code with AI.” I prefer Andrej Karpathy’s original definition: ”

There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. […] I ask for the dumbest things like “decrease the padding on the sidebar by half” because I’m too lazy to find it. I “Accept All” always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. It’s not too bad for throwaway weekend projects.

Emphasis mine.

That last bit is key. For throwaway weekend projects, vibe coding is this magical state where you have an idea but absolutely no desire to setup boilerplate, read API documentation, or even want to deal with the plumbing. You just want the thing to exist.

A few evenings ago, I decided to put in a serious vibe coding session using one of my favorite tools, Claude Code via SSH through Blink on my iPhone (!), to create a CLI utility to help manage the endless number of branches I have on my machine, all because of our huge monorepo.

For reasons I’m not entirely sure about, I decided to use Python. A language I know approximately nothing about beyond “white-space matters”, “there’s probably a library for that,” and “print("Hello, world!").”

(Hey, I’d have to turn in my software engineering badge if I didn’t attempt to reinvent the wheel every so often)

So, picture this scenario: I’m staring at my terminal after I had just typed git branch. I’m looking at a screen with about 37 branches in various states of decay. And of course there are numerous unhelpful branches with names like, daves/no-jira/hotfix, daves/no-jira/hotfix-2, daves/no-jira/hackweek-project-cool. My terminal is just a wall of branch names, most of them mocking my organizational skills.

(By the way, what was hackweek-project-cool? I don’t know… I never committed any code to it!)

I needed a better way to manage this chaos. So naturally, instead of cleaning up my branches like a responsible developer, I decided to build a tool. In a language I don’t know. Using only Claude Code. What could possibly go wrong?

Claude Code is great. It never gets tired. It never gets angry. Even if I kept asking questions and piling more features on top.

• “Let’s make a shell script using Python to display Git branches.”
• “Ohhh, can we make it show which branches have uncommitted changes?”
• “Oh, oh! Add some colors, but tasteful colors…”
• “Hey, there are a lot of branches here. What if pressing shift + d deleted branches (but we should probably have a confirmation…)?”
• “You know what it really needs now? A loading spinner!”

After a few hours of asynchronous back and forth, we had a result! Git Branch Manager: a terminal UI that actually shows useful information at a glance. Navigate your branches with arrow keys, see visual indicators for everything important, and perform common operations without memorizing Git commands.

For me, those little indicators are game changers:

• * Current branch
• [modified] Has uncommitted changes
• [unpushed] Exists locally but not on remote
• [merged] Already merged (why is this still here?)
• ↓ Remote branch you haven’t checked out yet

One feature that I love: Smart stash management. When you try to switch branches with uncommitted changes, gbm asks if you want to stash them. But here’s the cool part: it remembers which stashes it created and gives you a notification when you switch back. Press ‘S’ and boom! Your changes are restored!

This process still blows my mind. I describe what I wanted in plain English, and Claude Code would translate these chaotic ideas into actual, working Python. “Make old branches look old” turned into color-coding based on commit age. “It should be smart about stashing” became an entire stash management system.

Installation is pretty simple, too. No pip, no dependencies, just curl and go:

# Quick install
sudo curl -L https://raw.githubusercontent.com/daveschumaker/gbm/main/git-branch-manager.py -o /usr/local/bin/git-bm
sudo chmod +x /usr/local/bin/git-bm

# Additionally, add as a git alias
git config --global alias.bm '!git-bm'

Now you can just type git bm anywhere. Pretty neat!

There’s also browser integration (press b on any branch), worktree support, and a bunch of other features I’m proud of, err, creating, despite not having touched the code.

Here’s the thing about vibe coding with AI: it completely changes what’s possible for a weekend project. I built a legitimate, useful tool in a language I don’t know and using standard libraries I’d never heard of.

If you asked me 6 months ago if someone with no knowledge could build useful tools or websites using AI prompts only, I might have said no. “You still need people who understand software engineering principles, who understand what the code is doing,” I’d (not so) confidently say.

But now… it’s getting crazy. Is this the future of programming? To be a glorified conductor who oversees an orchestra of AI agents? Maybe!

Bottom line: my Git branches have never looked better, and I didn’t have to spend six months learning Python to make it happen! So, if you’re buried in branches like I was, give gbm a shot: github.com/daveschumaker/gbm

Now if you’ll excuse me, I need to go stare at my beautifully organized branch list again.

P.S. Yes, I realize I could have just cleaned up my branches manually in less time than it took to build this. But where’s the fun in that?

In both my work and personal coding projects, I generally have a number of various branches going at once. Switching between various branches (or remembering past things I was working on) can somethings be a chore. Especially if I’m not diligent about deleting branches that have already been merged.

Usually, I do something like:

> git branch

Then, I get a ridiculously huge list of branches that I’ve forgotten to prune and spend all sorts of time trying to remember what I was most recently working on.

daves/XXXX-123/enable-clickstream
daves/XXXX-123/impression-events
daves/XXXX-123/tracking-fixes
daves/XXXX-123/broken-hdps
daves/XXXX-123/fix-contacts
daves/XXXX-123/listing-provider
daves/XXXX-123/revert-listing-wrapper-classname
daves/XXXX-123/typescript-models
daves/XXXX-123/inline-contact-form
daves/XXXX-123/clickstream_application_event
daves/XXXX-123/unused-file
daves/XXXX-123/convert-typescript
daves/XXXX-123/convert-typescript-v2
daves/XXXX-123/similar-impressions
daves/XXXX-123/update-node-version

At least 75% of those have already been merged and should have been pruned.

There has to be a better way, right?

Thanks to the power of the Google machine (and Stack Overflow), I found out, there is!

> git branch --sort=-committerdate

Hot diggity dog!

daves/XXXX-123/clickstream-filter-events
main
daves/XXXX-123/convert-typescript-v2
daves/XXXX-123/update-node-version
daves/XXXX-123/similar-impressions
daves/XXXX-123/convert-typescript
daves/XXXX-123/clickstream_application_event
daves/XXXX-123/unused-file
daves/XXXX-123/typescript-models
daves/XXXX-123/listing-provider
daves/XXXX-123/inline-contact-form
daves/XXXX-123/revert-listing-wrapper-classname

That list is now sorted by most recent activity on the branch.

Alright. Even though this is better, that’s still a lot of typing to remember. Fortunately, we can create an alias:

> git config --global alias.recent "branch --sort=-committerdate"

Now all I need to do is just type git recent and it works!

Nice.

A recent post on Hacker News highlighted the benefits of detailed commit messages in git.

Usually, my git commits look something like this:

> git commit -m "fix: component missing configuration file"


…which isn’t all that helpful. (Related: see XKCD on git commit messages)

I decided to try and utilize this newfound knowledge in my own git commits and I quickly ran into an obstacle. Simply using > git commit opens up vim. Which, I really don’t want to use. (I’m sorry!)

This is something I should already know how to do, but I had to do a Google search to learn more. It turns out, you can change the default editor in git. This makes it much more convenient! How do you do it?

git config --global core.editor "nano"

Replace “nano” with your preferred editor of choice. Now, running > git commit opens up your editor and you can make detailed commit messages to your heart’s content!

I’m always searching for better ways to improve my workflow, increase productivity, and just generally learn new and exciting things. (Besides, it’s part of having a healthy growth mindset.)

We’ve had some big changes on our team during the past year and I’ve felt like I’ve needed to step up when it comes to reviewing code that my fellow colleagues write. While searching for some ideas on how to improve my code review skills, I discovered a blog post from 2018, entitled “Code Review from the Command Line“.

This blew my mind and really helped reframe how we engineers should approach code reviews:

When I ask that other people review my code, it’s an opportunity for me to teach them about the change I’ve just made. When I review someone else’s code, it’s to learn something from them.

Jake, the author of the above post, goes on to describe his setup and custom tooling for conducting an interactive code review.

He uses custom git alias to see which files have changed and how many changes there are, a custom script that visualizes how often the files within the pull request have changed over time, and another custom script that can visualize the relationship between changed files.

All of these go above and beyond the call of duty for reviewing code, but it’s stuff that decreases friction and can make a sometimes tedious process much more enjoyable.

I’ll be implementing some of these ideas into my own workflow in the near future.