Slowly drowning in slop

At my day job, I've reach a state of our codebase and issue tracking that I can come on Monday, asked my agents "/brun-backlog" and will do a dozen merge request in the morning. Most of it is the code I would have wanted, if not better and with a few added skills and I can cut the verbosity and "too much" code.

So I've been like, "Hmm, maybe it's time to vibe a side project after all?". My goal was like to let the AI do stuff I know well how to do and dig more into "new stuff", namely atproto and SolidJS. It was also a good occasion to test different models, skills etc. Boy, was I in for a ride. A tiresome one.

The first 80% and Mat Pocock's skills

The app in question is what is now https://askimut.at/ (source). After I unblock a little OAuth problem with Nitro and the [::1] trick, everything went pretty smooth. I asked for a SolidStart app with atproto login and it worked fine. I coud login and post a few things in a mere hour. It was just matter of "adding features" was it?

But as I tried to a bit more of a local setup, try to refine libraries etc. I realized I would need more written down specs. Nothing new here, but I installed Mat Pocock's skill which seemed great and indeed are an execellent basis. The reverse questionning is actually pretty clever. It will make sure the agent understand and you both are aligned. There were definitely some choices that were more obvious to me, had more intent. Ultimately I learned quite a few atproto things through those grilling sessions, because it had search for answers through docs. At first, I really liked that. The DDD part is really great too and actually something I missed in earlier projects I realized, even without AI. It really felt like software engineering.

It's great until you realize you've reinstored a tech meeting. Fair enough, at some point it might be needed anyways, but you already start to clearly burn more time here and sometimes the itch of "just let me code that already" was scratching. Problem is, AI tends to be extremly rigid about the process. But fine, I did it for the experiment. More importantly, it's not exactly the most exciting tech meeting ever. More often than not, the questions are vagues, full of jargon and kinda empty. Very AI-ish, to no one' surprise. There's even a skill to deslopify the questions a bit. At first I tried to fight it sometimes, turning down some questions. But quickly, I fell into "whatever, if you need an answer on that, I'll give you the first one. Everything is settled anyways".

And this is how, slowly, my boat was floating but in water that got thickier and thickier, without me realizing it.

The feature that collapsed it all

At one point I wanted a feature that let would show a litte "syncing to the atmoshpere" bagde for the time between when a post on the users PDS was sucessful and when it was reindexed in my database. The tech problem was Jetstream on long lived websocket but low traffic and send to UI isn't exactly straightforward nor common place. The SSE architecture seemed OK, until I realized it would have to wake the iddle websocket, re-read the database and so on every 30s. That's millions of reads per day… for one message.

But well, it's early stage, architectural problems happens. Fine, we'll fix it. And this is where my the water turned into ooblek. Trying to diagnose the problem went to hell and apparently hell is full of "seams", "armed components", "streamlined" and I was making tons of "sharp remarks" etc. And don't get me wrong, AI debugging is great, prints tons of stuff quickly, parse the print at the speed of light, I don't miss any of that. But navigating that ocean of empty words was something else. The agent confidently went through polling, then removed Jetstream and installed Tap (I knew this was wrong but whatever), then went to back to Jetstream with websocket ping pong until… I stopped this maddness.

The problem was there was too many moving parts in a not too common stack and the agent couldn't cope with that and compensate with Jargon. The essential part was it was never able to express doubt. Second thing, if you look at todays polling solution it isn't great either and for a reason: there's no commonly accepted, practical and simple way to do that. That's fine, it happens and I'm glad I learned that. But I really could have done without the ocean of empty words.

An impeccable failure

But that wasn't even the worst part. Messy problem have messy endings, just AI way maybe? Sure. But on markup and CSS part, I decide to use impeccable. On paper it sounded great, especially for me. You put your intent into words, so that your design is consistent. Fits really well the DDD part too, be clear on what you say to your agent. I had I expectation since I often picture vaguely the kind of feeling I want, but have a hard time turning that into a real design.

This turned my dev experience into the worst of the novlang marketing dystopia ever. You know that feeling when you're supposed to meet a "designer", who turns out to be a marketing and communication person and after 15 minutes you're wondering wether they understand anything they say. That on AI-roids but can't align a 3 column grid.

I tried to make it work badly, because I wanted to know if once settled, with a good architecture, with precise words for places on the page it would be easy to move things around. I just drowned into jargon. Until I decided to do it by hand once and for all and uninstall this crap.

It's no surprise that layout is pretty to express in natural language, more then in a visual way—Figma, to name it. But still the number of people swearing by Impeccable is suspiciously high.

It's faster, not THAT much faster and necessarily where it matters

So what to make of that? Again it changed a bit how I work with agents and where I think code vs. prompt balance is. And it's definitely not full prompt, both because text isn't the best format for everything and because there are things you need to setup precisely.

So the obvious thing first, sure it's faster to get to something "working", but it's still far from "one prompt and done". The more you approach the "end", the further it gets. That being say, if you take the hype away, that's not necessarily a bad way to do things. It's more of a top down way of making software. You make something that work, knowing the parts are very, very rough and you refine, refine, refine, basically down to "hand-writing level" on the part that matters. It's not bad actually, having that works actually motivates me more to improve it than building that "just perfect library that will unlock everything after" and nothing gets built.

The main highlight was the difference in effeciency between this fully vibed, uncommon stack project, compared to my Django + React CRUD search/filter app that has an handwritten backbone. Sure AI will navigate the second at the speed of light, will burn tickets in autopilot mode. There is kind of tipping point where AI will drown in its own slop, maybe taking you away with it. And this might explain why we're seeing so many "I redid this in 15 minutes with AI, in a week Salesforce is done", but Salesforce is still here. That "week" can still extend to inifinity, AI or not.

Again the rubber duck power is here and turning the AI into "let's check you're really sure you know what you want" is really great and saves a lot of time. It's quite the mental workout too, which is good, and will definitely require some skills on your side too. But when I drowned into the word soup, when , I was probably trying to replace a meeting with a real person by a grilling session with the AI. This is again a well know pitfall of coding with AI: your personnal productivity gains don't replace collective intelligence. And yes, your side project is probably stuck because you need help from someone eles on it. We all know this, and we all know deep inside of us that this "someone" isn't AI. But it's tempting to try isn't it?

Anyways, if like me you don't really believe into fully vibing a project from scratch, it's still great to try and really try to find clever way to stick to it. I just know better where my energy should go, what I should do myself. I also know better where the "genius" who has solved the company's problem will fail, hehe… but that's for the next blog.