Adventures in Vibe Coding

First off, who came up with the term Vibe Coding. It's stupid. You will accomplish nothing if you are going on a "vibe". I feel like Inigo Montoya - I don't think that word means what you think it means. But I digress.

I have been experimenting with AI assisted coding for a while. More like playing around with it. Needless to say, I have found it lacking. I checked in with some professional coders that I know and, to my surprise, found that many of them were using AI tools, but mostly to do simple stuff or give them ideas of how to solve a problem. So, while I still think it would be literally insane to create a mission critical application using so-called vibe coding, I figured I'd give a chance for something less dramatic.

Previous experiments didn't quite work out, but given some recommendations from folks I respect, I thought it worth another go.

The Project

To be fair to AI tools, I wanted to pick a project that it has a reasonable chance of accomplishing. I set down the following criteria for such as project as:

• Must be simple enough that a moderately experienced programmer could accomplish it. 
• Should be a well-known and, hence, easy to define problem. I was not looking for creativity or magic.
• Needed to be short. A subset of "simple", a relatively short program would be unlikely to have too much complexity and would be easy to debug.
• Should do something useful. Why bother with something esoteric when you might get something out of it.

I decided I wanted to port the Linux BASH script screenfetch to Powershell in Windows. Powershell is very useful for accessing Windows system information and screenfetch is a useful Linux tool for extracting system information. A Windows screenfetch would not be overly complex, would be useful, likely short, and has a relatively narrow and well-known problem domain. There was also a direct example to work from, thereby giving the AI tools a leg up.

The First Pass

Having used Microsoft Copilot and ChatGPT for coding projects before, I did not have a lot of confidence in either. I tried a different AI agent that I had heard good things about called Qwen. I initially wanted to try out Claude Code but had to have a subscription for that and I'm cheap about these things. I told the Qwen AI app that I wanted to recreate screenfetch for powershell and Windows and that it needed to be as close as possible to the original. Obviously, I said it better than that.

Qwen wrote the script which I downloaded and ran. It puked. Sigh.

Fixing the AI

I then created a project in Github, added a Readme with some basic placeholder text, and accessed it all in VS Code. Some quick debugging found that the Qwen code had used deprecated functions and, worse yet, functions that did not exist at all in Powershell. In other words, it made up things such as system calls and environment variables. That was a big miss, but predictable.

The best I can tell is that Qwen couldn't discern between code with errors and good code that it had ingested. I suspect it spit out someone's mistake. It was easy enough to find out where the errors were, use Powershell documentation to find the actual commands to call, and fix it so that it ran. Problem one solved. 

Incidentally, when I asked Copilot to fix the code, it came up empty. I don't think it was just a Qwen problem so much as a general AI ingesting problem. AI has no good way to know good code from bad when it ingests it and hence will spew bad solutions as well as good. This was ironic because Copilot and Powershell are both Microsoft products.

That said, the structure of the script was good, and it worked with my fixes. Qwen got me off to a good start and hence accelerated development. This suggests, as my developer friends said, that AI tools helped with simple tasks, but could not be relied upon to write code that was correct and reliable. AI provides a head start but is not trustworthy.

Documentation

The next task I gave AI was to write documentation. Documentation is something I'm very good at and am able to judge well. I asked Copilot to do the following:

write documentation for the Screenfetch.ps1 script that includes a description, proper usage, explanation of functionality, and limitations.

It did a pretty good job. Good, mind you, not great. The text it created was accurate, though not complete. Copilot didn't seem to understand where to put more explanation or emphasis. Unlike a human, it also couldn't think beyond the basic parameters of the prompt. 

For example, Copilot correctly showed how to run the script... in one way. The better way was to add the location of the script to your PATH command so that it could be run like a system command. That's how the original screenfetch works. I added that part. Copilot also didn't predict other ways, other than from within the powershell shell, that this might be run. I added instructions on how to run the script from the old-fashioned command line shell, cmd. 

The most useful part of the documentation was the limitations section. It correctly listed several limitations of the script which, in turn, suggested useful changes to the code. This is a powerful feature. If AI can analyze limitations of code, it is much easier for a human to identify changes that may not yet be tied to a requirement. Anticipating future requirements is very useful indeed.

Evolving Code using AI

With those limitations in mind, I decided to make some changes to the code. There were three areas to focus on. First, the original code didn't exactly replicate what was in the Linux version. It left out GPU and Packages entries. Second, as pointed out by Copilot, it didn't report on multiple disk drives, only the first fixed disk. Third, the graphic that Qwen had created was nonsensical. It was a weird ASCII blob that bore no relation to anything representing a Windows OS icon. 

I tried the last task first. I used Qwen, OpenGPT, and Copilot to create an ASCII representation of the current Windows logo. They came up with garbage. Just random ASCII characters. I ended up coding this by hand which is exactly the type of drudgery that AI is supposed to save us from. It seemed an easy enough task, but alas, nothing seemed to get it close, let along correct.

Next, I asked Copilot, from within VS Code, to add the GPU detection and account for multiple fixed disks. It actually did this without trouble. Copilot plugged in the code, VS Code showed both the original and changed code and let me decide if I wanted it or not. I was able to run the new code before accepting it. Definitely a win for Copilot and AI.

Next, I asked it to add the number of applications to the script. It did so without error. Interestingly, it still labeled it as Packages, as it is int he Linux version. Linux Packages and Windows Applications are not the same. Packages not only includes applications but also system and other shared libraries. Applications are a subset of packages. For Windows, packages are not important compared to applications. I left it in that way, however, so that it looked like the original screenfetch. I admit I'm on the fence on this one though since you would have to read the (human updated) documentation to know the difference.

Evaluation

Damn! For something simple like this, AI tools had a big effect. I would say that I was able to create this script in less than half the time it would have taken me otherwise. Given the initial and subsequent output, the narrow problem domain and existence of a known model were critical to its success. 

Therein lies the AI Achilles Heel. It needs an existing model to work from. If I was porting code, AI would be a lot of help. If I was doing something creative from scratch, it would have been a little help, perhaps as I was adding features later, but not nearly as much. Adding snippets of code seems to be easier than either wholesale creation or overhaul. 

The other problem is that a developer has to have enough experience debugging the equivalent of someone else's code. It's much easier to understand code you wrote than code someone else wrote, or in this case, something else. If you can't trust the code, this is a serious problem.

AI tools for coding are improving. You still need an expert behind the wheel, need to keep things simple, and the problem domain narrow. AI is a tool not a replacement for human coding. Use it as such.

Breaking Workflows with New Features

I use Microsoft Edge as my primary browser. Don't judge me. I used to use Firefox but found many websites that would not work properly with it. I switched to a Chromium based browser called Ulaa (from Zoho) that was excellent. Unfortunately, with Edge so embedded in Windows 11, I experienced too much inconsistent behavior, and quite honestly, Ulaa was not keeping up with new and useful browser features. So, I begrudgingly switched to Microsoft Edge. 

Edge has a neat feature called Workspaces. This is like a tab group but can be called up with one click. Unlike a tab group, it maintains the current state of the set of tabs. So, if I open a new tab and leave it there when I close the Workspace, it is present when I open the Workspace again. Workspaces are dynamic whereas tab groups are static. Workspaces also open the tabs into a color-coded separate window, visually and spatially separating the tabs into their own space. I use this feature constantly.

What happened recently to Workspaces, provides us with a great example of what is terrible about software today. You see, Microsoft has been retooling Workspaces under the cover, causing the user experience (UX) to change. That can be good, but forcing changes to workflows is disruptive and irritating. In the case of Workspaces, it no longer will maintain a fixed list of Workspaces. Instead, it now insists on what is called Most Recently Used, or MRU, ordering. That means whatever you used most recently goes to the top of your list of Workspaces, even if you only use this Workspace occasionally. I find MRU a silly way to order something. A fixed but adjustable list defines a workflow. Ordering items as Most Frequently Occurring items makes sense in that it highlights something you use a lot. MRU ignores the wishes of the user and frequent usage patterns. It places emphasis on the wrong thing.

This is not a debate about ordering schemes. It's about changing UX without taking into account the end user. It's about not maintaining backward compatibility in workflows. It is about an abrupt forced change in user behavior, without the ability to either ease into it or continue with the old ways. In effect, Microsoft is telling people who use this highly touted feature how they should work. 

If a software vendor introduces a new feature, they don't do it just for fun. They are hoping that his new feature will keep you using their product. If you don't use their product, they can't make money from it. That's why I stopped using both Firefox and Ulaa - they didn't keep up with the features that make my work easier. Once lured into using a feature, however, you can't abruptly and capriciously change key elements of it. Once your workflow has adopted this feature, changes to the feature can become changes to your workflow. In this case, instead of enabling my workflow, Workspace changes have altered and disabled parts of my workflow. 

For me, the most likely solution will be to abandon Workspaces altogether. The MRU ordering is counterintuitive and counterproductive. I can do something similar with tab groups, though not quite the same. When software companies make changes like this, they sabotage their own features. I can imagine the product manager who made these decisions realizing that use of the feature has dropped dramatically and, instead of admitting that he greenlit a change that was terrible, will say no one uses Workspaces and sunset it. I doubt that anyone will want to admit that they themselves sabotaged their own feature.

This is not just a Microsoft or software problem. For those of you who remember New Coke, you know what I mean. It just happens faster and quieter in software. All of sudden something stops working and everyone is confused. End users think they did something wrong and finally, abandon the new thing in frustration.

Oh, and Copilot lied about it and kept telling me how to "fix" my problem. Sudden changes to my workflow and gaslighting all in one package. Nice!

Adventures Spotify's AI Playlists

I've not been shy about how I feel about generative AI, especially for coding or writing. Much if it is too error prone to be useful on its own while the errors can be hard to find and fix. I'm also not keen on the copyright issues. My own book was ingested and used by Anthropic without my permission, possibly creating a non-permitted, derivative work. 

Creating a playlist, on the other hand, seems like the perfect AI application. There's no truly wrong song to have in a playlist, even if my own choices would be different. Artists whose songs are part of the playlist will get paid when I listen to their songs in the generated playlist. And yet...

Most generated playlists, at least in Spotify, tend to have the same songs recycled over and over. There's rarely the "Wow" factor that comes with an unexpected choice. Redundancy and a lack of surprise make for a mediocre playlist. It lacks soul. Spotify has used AI to generate static playlists, likely from internally generated and QA tested prompts. They tend to be blandly efficient and based on whatever I'm listening to at the moment. Just listened to Metallica? Now, my AI generated "daylist" will a be heavy metal focused. Old school punk and New Wave? I get more old school punk and new wave. As Dom DeLuise said in History of the World Part 1, "Nice. Not thrilling but nice." 

Still, I was very interested to try out the new Spotify prompted AI playlist feature. The idea is to start off with a prompt that could generate a playlist such as Unexpected Genre Adventure or Vinyl Nights in Tokyo. By using your own listening data as a part of the prompt, you should, in theory, get something personalized yet fitting within the framework of the prompt. More interesting, though, is that you can customize the prompt to make it slightly different and more interesting. 

I started with the prompt that was titled My Life as A Movie.  The prompt was:

Make me a playlist for when I’ve got main character syndrome. The world’s spinning, the lighting’s perfect, and every step feels like a movie scene. I want songs that make ordinary moments feel epic: walking, staring out windows, overthinking, winning, losing, all of it. For every song, tell me what scene we’re in right now—what’s happening, what it looks like, what I’m feeling. Build it like the soundtrack to my life, focusing on songs I would like based on my listening history. Do not repeat artists.

That's pretty cool. Your own personal movie soundtrack. I decide to make one small change by adding "90s romcom" to the first sentence. This was meant to be a constraint. The playlist shouldn't have music from after the 1990s or else it wouldn't make any sense. In addition, they had to be songs typically found in Rom Com of the era. Granted this made things both easier - narrowing the domain of songs - and more difficult - discerning what should be in a 90s Rom Com.

I hit generate and encountered the first problem. It took forrreeeevvvvver. As in hours with no playlist. What was it generating? A literal lifetime of music? Clearly, I needed to add a constraint on the number of songs. Second time around I added " Keep playlist to 100 songs." to the end of the prompt and very quickly had a playlist of songs that pretty much fit the bill. Mostly. Sort of. Kinda.

See, it didn't quite get the 90s part of "90s Rom Com". So, while Mr. Brightside by The Killers fit the playlist well, it's clearly post-1990s and hence doesn't really fit the prompt. Also, songs were scattered across at least three decades. It should have been a tighter range. Soundtracks for most movies either contain period proper songs, in this case the 90s, or pick a time period that the exemplified the main vibe of the movie. For example, the Rom Com "When Harry Met Sally" uses jazz standards, performed by the amazing Harry Connick Jr., to place the movie outside of any particular time. "Say Anything", on the other hand, uses all contemporary songs. The most iconic scene in the movie only works because the main character is using a time appropriate and theme appropriate song Peter Gabriels "In Your Eyes." The Spotify generated playlist, by contrast, is all over the place, from staples of 70s Classic Rock to 90s Alternative to early 2000s Garage Revival. 

That's not to say that the playlist isn't good. It's quite good, in fact. And there are surprises which make it actually interesting to listen to. A segue from 1979 by the Smashing Pumpkins to Simple Man by Lynyrd Skynyrd was completely unexpected and yet, it worked both musically and for mood. 

A fun feature is the notes that accompany each song. They describe the "scene" in the movie. I especially liked the minutia of notes such as "Kitchen scene: parent's voicemail advice plays while burn grilled cheese and life feels clearer." That's so ridiculously specific and no average human would think of it that way. 

So, what's the final verdict? Spotify's prompted AI playlist really works - mostly, sort of, kinda. It can create a viable playlist. Songs dovetail well with no major shifts in tempo or weird transitions. The notes on the songs are delightful, especially when they begin with "Hungover grocery aisle chaos". That's just fun.

Unfortunately, the AI engine doesn't ask for clarity for the prompt such as "Do you only want songs from the 90s?" or "Is there a genre you want to focus on or exclude?" which seem like something it should do. It's inability to balance the length of time it takes to generate a playlist with the number of songs is also puzzling. Anyone using this service needs to think to put a limit on the number of songs in the prompt or watch it take hours to create something a human could do in a few minutes.

I'll give it a B+. With a few refinements, it could get a grade of A.