What I did?#
After some (probably too ambitious) vibe coding experiments in the past and the hype around the new Claude and Codex models in full swing, I found myself strong-armed to give it another shot. To not be too overambitious (again!) and aiming for a working result despite me having limited tokens (I am on the Claude Pro plan), I decided to vibe code a plugin for the note-taking app Obsidian that will sync all my notes to an S3 bucket in the cloud. That way I will always have the same versions across all my devices. (I am currently using Obsidian Sync for exactly the same use case, but I’d really like to save those 5 Bucks a month and also not be limited to syncing a single vault anymore.)
Disclaimer: I’m still not 100 on the terminology though, as Vibe Coding has that really bad… well, vibe… about it to be this extra lazy way of not even thinking a lil’ bit, making it also kind of a slur for some. On the other hand, Agentic Engineering sounds so extra and bougie which I don’t dig.
Knowing what I want to build, I decided to approach it a bit naive and raw-dogged the following prompt without putting too much thought into it and see what happens:
Write me a plugin for obsidian that will sync vaults to a
cloud object storage on ovh cloud. It has to support syncs
in both directions.
Let’s see how that went!
What went smoothly?#
It did take a little time, some additional input from my side and as it seemed a shitton of tokens (which most probably can be attributed to my lack of prompting skillz) for Claude to produce a plan for implementation which I then had to approve.
After that, the magic kicked. Claude started writing a couple Javascript files, attempted to build, failed, but immediately provided a fix and repeated the whole thing 1 or 2 times until the build went through. That was it! It still plotted some installation instructions, I created an extra Obsidian Vault for testing and BAAM, the finished plugin was there and just did what it was supposed to. No Cap!
Features#
In addition to the limited specs I fed it, Claude even provided a couple extra features that made the result look pretty good:
- a nice configuration form to configure the S3 bucket in use (I would have been fine for my own use to have that hard-coded)
- full integration into the Obsidian UI with a manual sync button, a progress bar and result messages showing how many files were up- and downloaded
- both a manual full sync and a configurable sync after every file write
- conflict resolution strategy
Race to 100#
After some more testing and checking out the final code it produced, there were still some minor improvements to tackle:
Error on Mobile#
At first, the download of files on mobile did not work and failed with only plotting the number of failed files, but without insights on the error itself. I manually changed the following line of code to get the actual error messages:
const msg = `OVH Sync: ${result.errors.length} error(s). ${result.errors}`;
The error was about receiving Uint8 when a Blob type was expected, but after having the error, I could feed it into Claude and it provided a working fix immediately.
Library Use#
When checking the code, I found a lot of custom implementations around signing stuff, which felt off to me, so I asked it if there was no standard library for that. While it admitted that there actually was one with @aws-sdk/client-s3, it was under the impression that it was non-compatible with the mobile version. After briefly checking the Obsidian Plugin docs myself, I expressed my doubt concerning that situation which led Claude to check again itself, confirming that actually yes it should work indeed and then refactoring the whole thing to use said library. This led to a reduction of ~150 lines of code. Neat!
Security#
At last, I found the data.json file within the plugin installation which is used to store the plugin configurations and last sync times of all files. And that triggered my security spidey senses right away, cause among the configurations are the Access Key and Secret Key for the S3 bucket. Credentials as cleartext are No Bueno!. Again, checking the Obsidian Plugin docs, I found that there is something called Secret Storage to avoid exactly that problem. I asked Claude about it and after doing its own research, it explained to me what happens at Secret Storage under the hood (for example, this only writes to LocalStorage on Android) and we agreed that it was still an upgrade to plaintext within the configuration file. It immediately applied the proposed change, including a migration of already configured secrets to Secret Storage (another extra Feature!) and I could confirm that everything still works.
Bottom Line#
Those new models (Opus 4.6 for me) are no joke! I can clearly see how they are able to produce a lot of working code mad quick and almost on their own. Yet, I still see the value of a human-in-the-loop, as we’ve seen with some of the above issues that were missing to make the result a 100%. Still, paradigms of creating software will change and a lot of new questions will need to be tackled. Some that come to mind after my first experience are:
- Trust boundaries along the Supply Chain
- Shift of Software Quality away from the code itself and towards processes of producing it
- Efficiency concerns - letting agents deal with certain tasks repeatedly vs. building a custom solution for that workflow with the help of the agent