Take A Deep Breath, Because Your Computer Can't.

Alright, I’ve been talking a lot about how I want to make software. Most of this want doesn’t come just from the fact that I want this software to exist because I as a blind user don’t have an alternative, it also comes from the fact that the hype train will let you believe that anyone can create software now. I’m here to break it to you, this is not true absolutely. There is some truth to it, but the best lies have some truth to them.

Eleven years of finding workarounds as a blind user had me pretty used to accepting shitty software experiences. I was already accepting limitations, making music anyway, touring anyway, leading a band anyway. I wasn’t waiting to be rescued. I was living. And then this door opened and I walked through it and now I’m on the other side wondering if the room I left was actually the one I wanted to be in. This too is a lie, with some truth in it…

The main point I want to make before I get into why I still do this is that you don’t HAVE to do any of this. You are not being left behind if you don’t use any of this stuff. You don’t need to have a clanker organise all your tasks for you first thing in the morning if you don’t want to, you don’t have to optimise and automate your life. Living life and doing stuff is actually fun and there is more slop than success with almost everything when it comes to generative models. But if you’re like me and you’ve decided that you want to at least try this stuff, then brace yourself because there are risks and challenges.

The first and most important one is literally the most obvious one. The lack of knowledge. If you listen to the hype train, you would think you don’t have to use a single brain cell ever again. All the world’s knowledge is now just yours. Nope. When you see a clanker write out a 5 page PRD, or an 8 Phase plan, or throw a bunch of terms at you, or just simply execute a bunch of terminal commands on you and you don’t understand any of it, there are consequences. If you are doing something simple, like asking an agent to organise a spreadsheet, or organise your files, or arrange your to-do’s, the consequences are pretty non-existent for the most part. But with every step you go beyond that the consequences start becoming real. If you make a tool that sends emails on your behalf, well it really can and will send something absurd at some point. If you use it to make a non-static website, and you’re not careful, your payment access key could be public. If you’re making a local first fully encrypted app you could fall into using a dependency used by one singular person who also happens to be the creator of that dependency. This is what almost happened to me. I am using Kevin Jahns’ YJS to solve CRDT, which for my non-techie friends is how two people can edit a doc offline and get the same doc when they come back online. To transfer these across the client, your device, to the relay server, to the rest of the clients, your friends’ devices, I was about to use something called Sec Sync by Nik Graf. Weeks and weeks into the app one day, thanks to just being paranoid, I decided to look into each of the security critical parts of the stack. While this protocol is good and sound, it’s labelled as beta by its own creator. It also doesn’t allow for multiplexing, sending multiple documents over the same connection, and also doesn’t handle epoch rotation, changing your encryption keys when a new member is added or removed or a device is compromised. These were all things I would have had to hand roll on top of Sec Sync. And lil old Claude had been recommending this to me for months. Another example was me having to sit for 16 hours straight, and no I am not exaggerating. It was from 2 PM till 6 AM with like 2 coffee breaks, trying to debug Lexical, a document editor’s persistence layer. Many rounds later did I find out that one, my clanker had decided to hand roll the YJS implementation, decided to write its own transport layer instead of using HocusPocus, and most of all kept saying the bug was solved when it clearly wasn’t. The plain English summary of this is that it decided to write custom untested code for two of the most important parts, syncing the data and sending that data across. The solution? Well I had to go read the Lexical docs and how they implement bootstrapping a project and found that they also had their own implementation of sync that I could just use. I had to build a verification pipeline where the error logs, along with a script with two user accounts, was created every time, typed out “Am I A Dumbshit or did This work?” and only if the script closed the app and restarted it and the screenshots were the same would the loop stop. I’ve since moved off of Lexical in favour of Prose Mirror but boy was that tough. And the final example I want to give you is the most recent, when one day for some reason when I gave the command “clean up this worktree”, a command I’ve used multiple times a day for the last few months, Codex decided to rm rf a separate folder that was not in that worktree and was an untracked folder, completely git ignored, that had some .env files with API keys and my SSH keys and some planning and audit docs. Just poof. Gone. Deleted. The worst part was that I didn’t even have an inventory of the docs. I had a backup of the keys and tokens but the docs were gone, and the worst part is that I don’t remember every single doc that was in there.

You cannot not ask questions and push back on things you are given. These models are optimised to take the path of least resistance. They won’t feel sad when you sit for 16 hours and still don’t have a working product and they definitely won’t feel any pain. If you aren’t willing to peek under the hood at a high level and at least attempt to understand how systems work, there is not going to be any success trying to program a system. This means that you have to think of all the weird edge cases and make the model not skim over those, you have to do the work to figure out what all the jargon it’s spitting out at you means. A very common workflow I have is I will take something super technical sent to me from one clanker and paste it into another clanker and ask it to give me the plain English version of it. Then I sit there and poke holes in that till everything I can think of is closed. After which I get it to ask me anything open and point out flaws, which then I proceed to either debate and close or find solutions for. Once this plain English round of debate is done it then goes back into becoming technical jargon I don’t understand that then goes on to becoming code. It’s like, if I told you, when taking the insides of a coffee cherry and running them through the process of dehydration and high temperature processing to transform their colour, you then take it and run it through a stone utensil in which through manual force you break open its protections, transforming it into powder, and then run it through a high pressure machine and hot water into a small container. You’d probably go wait what?! But if I said, roast some coffee beans, grind them by hand and run them through an espresso machine into a small cup, you’d get it. To which you then have the option to push back and say, no I’m not a Silicon Valley hipster, I’m a broke musician and I will use an electric grinder and french press thank you very much.

If you’ve noticed, the things I am saying are things software developers do pretty naturally. They don’t need the plain English description, they don’t need to know that you have to run through the docs of a dependency, and they probably don’t ask their agent to clean up a worktree they can do in a single quick command anyway. If the hype train was real, and anyone could use these agents to create software, or it was just fully automatable end to end, can you tell me why every big tech company wouldn’t have fired every single person costing them hundreds of thousands of dollars a year and just hired a bunch of fresh out of college grads for cheap and given them all a bunch of tokens? If you’re coming up with an answer right now, and it’s not because it’s literally impossible, please write to me, I wanna know why you think so.

Even though over the last ten or so months I’ve learned a lot of technicalities, the number one rule I live by is - I don’t know anything. No matter how much the model tries to glaze me, how much it compliments my sharp thinking which are just obvious systems choices to me, how much it says what I am about to do is “revolutionary”, I still say nope, I’m a musician not a developer. This single rule makes sure I don’t trust anything blindly. -ahem-

That being said, there are some advantages to being a normie participating in code. The first one is I give zero fucks about what language I use. I look at what I am trying to build, do research on what the best language for that particular thing would be, and just use the language that would best suit it. The language should serve the product, not the other way round. It’s like you don’t play funk music with a ukelele. It’s not that you cannot, it’s just an uphill battle.

The other big advantage is that being a normie means we have some domain expertise about something that is not software. Like for example when I work on accessibility for my software, being blind as fuck helps. Or if I am working on my music notation app, being a musician helps. These things are highly underrated. I cannot tell you how many apps and websites I have used that have the worst applications of VoiceOver on Mac I have ever seen.

And lastly, the best benefit, the day you get sick of doing this you can just say fuck it I’m out. Like I said in the beginning, this isn’t your life, and don’t let it be either.

In the next post I’m going to go deeper into why I built Facets and what the process was like trying to take an open source web stack to a Tauri app. So if you want to find out why I am building Facets read the next one!