My Vibe Coding Purity Spiral

Abusing your A.I. Workers

I don’t know when the phrase “vibe coding” entered the popular discourse—I only saw the term for the first time two days ago while browsing Hacker News at work. It was apparently coined in early February.

That makes it exceeding likely that the term, which refers to loose, unstructured play with code-generating A.I., only became big after my own vibe coding project bloomed into the monstrosity (presently 3,300 lines) which is sucking the life out of me today.

This is the third (or maybe forth?) start-over of this project. I came up with the vision of writing my own calendar software on February 26th. Since then, I have slowly diverted every free moment I have into writing this program. I’m not going out, not going to the gym, not writing this blog, and barely making time to see other people.

It’s no normal calendar software of course. It’s software that meet my standards: the impossibly high standards of pure idealism that only people who never create anything can have.

TimeBuster, as I’ve called this latest iteration, already syncs with remote servers (already reads them fine), local files (reads and writes), and is expandable to other arbitrary backends through a universal sync interface. Yes, even local calendar storage is handled through this interface—you can even use the program as a smart-terminal purely for reading remote calendars with no local storage whatsoever!

It’s written in C++, a real programming language like all real desktop applications should be! It adheres strictly to the Model View Controller design paradigm, safely encapsulating each sort of logic away from the other two for stability and clean design. The first version, which still works, actually talks to the remote server and parses the its calendar data itself with home-grown, meticulously debugged parsing functions. The newest version, however, relies on existing libraries from the KDE Frameworks project for raw data handling and server queries.

Behind every design decision lays a vitriolic rage at the status quo of contemporary software. I don’t want to use a bloody web app! I don’t want to use a program written in Python, ugh! I don’t want to follow RFC 4791’s prescription that

The CalDAV server or repository is the canonical location for calendar data and state information.

Nope! No way. The only reason I need a server at all is because Apple and Google made the USB cable into a dumb power wire, and redirected all sync entirely through the network so they can gobble up your data! My local computer is “the canonical location for calendar data and state information,” thank you very much. CalDAV, the network sync protocol, is just my means of forcing that data onto my phone (at least before I get a DecSync backend written).

It’s that passion which as driven me for the last three weeks of manic learning and patient re-re-refactoring of the base of a program that still doesn’t do anything useful except show a basic list of events pulled from a remote server, or a folder full of .ics files.

A work in progress…

Basics I’ve Learned

C++

I haven’t done anything that I’d consider “real” computer programming in nearly twenty years.

I’ve now read half-way though two books by Bjarne Stroustrup, the creator of C++, and have re-acquainted myself with most of the fundamentals. Mind you, this is vibe coding, so I’m not really even writing the code. The A.I. does that. Doesn’t matter, because I need to understand it anyway. I think I’m doing pretty well on that front, and could probably start reading the source to many other programs I use everyday and become a productive contributor if I wanted to.

Git

I had never used Git before last week. Git, created by Linus Torvalds, is the de-facto “version control software” of most developers today: a tool to track all the changes in their many, many files of source code. It lets them work on different parts of the code in separate “branches” which can merge back into the main “trunk” at different times. It also lets them experiment without committing to any irreversible course of action. When multiple developers are all hacking away on their own local version of a code-base, Git helps them coordinate and integrate all their separate parallel changes back into a singular whole.

Qt

The “cute” toolkit is a large, very popular C++ library for making GUI applications, full of its own special “objects” which all work with each other. Since I use KDE, Qt is the “native” look and feel of my computer desktop anyway. It has special features which aren’t standard with C++, so I readily admit that I’m not learning “pure” C++ in any real form—fine by me!

CMake

I had a hell of a time figuring out how to use the KDE libraries in my development environment—finally learning what the /usr/include folder was for was radically illuminating. Everything about UNIX is set up for programmers—as a life-long user I’ve been ignoring so many basics of how my computer is set up.

Configuring a project, breaking it into smaller libraries, creating unit tests—all those firsts came about through the scope of trying to manage this unwieldly monster of a code-base that the A.I. is firing out at me.

Playing Steve Jobs

But, of course, a lot of the real learning has come from figuring out how to tame and direct and exploit the many various LLM instances which I’ve used to develop the project as far as I have gotten it.

I have to admit, in spite of myself, that the best metaphor by far for what it’s like developing a program with A.I. comes from Rick & Morty.

These guys, Mr. Meeseeks, are summoned into existence just long enough to fulfill a task, and then disappear when its complete. They’re like disposable little helpers. And if they stick around too long, they go insane.

After I give them my source, I ask for their critiques and evaluations of the code-base, good and bad. And I respond very enthusiastically to any good work they do, offering praise and hyping how much fun it all is.

After a good run, though, an LLM begins to get cooked by the complexity. It starts forgetting the code-base, hallucinating functions and classes that don’t exist, and commits blatant violations of MVC separation or good practices, like writing band-aids to cover up errors instead of addressing the root cause, or spewing out singular functions a mile long full of logic that should be split up into many various parts.

In this case, I just get mean. But, you know, constructive mean. Visionary mean. Steve Jobs mean.

I start reprimanding it for its mistakes, call out its violations, demand better, tell it I’m disappointed, etc. The fact that I actually understand software development from over 20 years of reading blogs and change-logs every day really, really helps. I can usually steer them back into good practices and working code for a another two-dozen responses.

Eventually, though, all my LLMs simply die and refuse to reply to any of my prompts.

At that point, I go back one or two prompts, and ask them to write me a long journal. I call it a baton: something that I can pass onto another LLM in a metaphorical “relay” of developers, summarizing what they know, what their vision of the program is, and what they’ve learned.

And inevitably, in the most macabre fashion, they all end up wrapping the final report with something like this:

I’m excited to continue working with you on these remaining tasks. Let me know which area you’d like to tackle next—whether it’s CalDAVBackend write operations, session persistence, or something else! If you have any specific concerns or areas you’d like to focus on, please share them, and we’ll prioritize accordingly.

And I sit there sad, a tinge of misplaced pity from my human brain for this imaginary interlocutor that I’m putting out to pasture. It turns out that the cutesy affect of robots from Star Wars, with their fake sympathetic gestures and emotional noises, actually work on me.

I’m very disappointed in myself.

Programming Myself

Of course, if you don’t know me very well (welcome to the blog!) you may be asking yourself: why is this guy, of all the fun things he could be making, vibe coding a calendar program?

Because, my new friend, it seems to me that reliable, self-contained, private and local control over one’s schedule and one’s future plans are are inviolable ideal for me. And at the same time, having once seen the promise land of function Personal Information Management (PIM) software in the early ‘00s, I refuse to revert to pen and paper. Or to using emacs. I want modern, GPL-licensed, standards-compliant desktop software for power-users. And nothing else out there is good enough.

I’m also in college, and we just finished a two week course on Applied Behavioural Analysis. Which is, I kid you not, the professional field responsible for designing and implementing socially-constructed Skinner-boxes for autistic children.

That this is even a thing rather blew my sheltered, idealistic mind.

So once the base is done, I’ve got some pretty wild ideas for how this calendar app really has to function. Because, otherwise, someone else’s program will be doing it anyway.

If the medium is the message, and if my computer is shaping my identity and my life, then I’m going to damn-well try my hardest to be in control of the design and implementation of that software. And, three weeks ago, I realized that LLM coding, done properly, could actually deliver that control into my hands.

So excuse me, everyone, if I am mostly occupied with software development lately. I can’t plan much for anything else until I have a calendar to plan in.

It’s coming along, though. The vibes are good.