
Now that I’m publishing the majority of my thoughts on the business of the internet at Testset Media, I want to start repurposing this blog as more personal commentary. I don’t particularly like talking about myself, but I think it’s important that anyone who is coming here to get some sense of what RCD offers as a consulting partner or what M. Martin has to offer as a consultant (or contractor) gets what they were looking for.
To that end, I want to pick up where I left off almost a year ago on the subject of Vibe Coding. Starting with the obvious, it has been one helluva a year…
In the time since I started dabbling with this, Vibe Coding (or prompt engineering, or whatever the hell you want to call it) has developed into an actual professional skill and an actual industry faster than anything I have ever seen. This is partly a result of the big tech companies selling each other this crap in a way all too reminiscent of the lead-up to the dot-com boom/bust that left me peddling pot and building websites on the cheap back in the Nineties. But that explanation only goes so far. Clearly, there is a demand sufficient to motivate companies to build AI-driven products and an incentive for digital professionals to learn how to use them.
Of course, we’re all more than a little incentivized by what the self-proclaimed “stable genius” has done unto the economy and our 401Ks, but I think there is more to it than that. And I think that, as an early adopter who stepped away for a while, I might have some insights into what that “something more” might actually be.
I should start with a little context. I got re-involved with this technology after I was invited to become re-involved with Testset, and specifically tasked with completing the migration of a React/TypeScript Single Page Application site running on headless WordPress from Lovable to Builder.io. That application is, of course, Testset itself.
When I first started working on it, I would estimate that the site (which had effectively already been soft-launched) was somewhere around 80-90% functionally complete. There were a few features missing, a few features that were still buggy, some performance issues that needed to be resolved. I’d had no involvement with the original app design in Lovable. That was carried out strictly from a front-end design perspective and had turned out quite well.
But the problem with the notion that completely nontechnical business users can build complex sites and applications simply by drawing pictures and talking to an LLM is that it ignores the deep in the weeds headaches that keep project managers and dev team leads awake at night. It’s a little bit like the old consulting adage that 20% of your customer base can absorb 80% of your functional resource bandwidth – all it takes is one difficult client. One nit-picky problem buried deep in the bowels of AI generated code can easily take up all of your available bandwidth… assuming you know enough about what you’re doing in the first place.
Luckily for all parties, I sort of do know what I’m doing.
At this point, I would say that Testset is at around 95-98% of being functionally complete. Getting there took roughly a month of my time, which was mostly taken up by learning how to use Builder’s AI-driven interface, documenting the technology stack, and refreshing myself on the fine details of WordPress REST API. Given that almost every digital asset I’ve ever managed hovered at around that same 95-98% level, I’m not feeling too bad about it.
More than that… I would say I’ve actually been having fun.
Kudos to the team that designed Builder’s interface. It is streamlined and gamified enough to provide instant positive reinforcement when a problem gets solved. The agentic interface is just as relentlessly cheerful and flattery-prone as any other AI, but as a ‘virtual software engineer’ I give it some serious props. It is definitely a subject matter expert on the code it is expected to maintain, definitely understands the terms of art common to software development. Just like any human developer, I occasionally have to tell it “that’s how the business wants it, that’s how we’re going to do it” – but at least it doesn’t get pissy about it.
I consider this sort of work a socratic dialogue because that’s exactly what it is: a structured dialogue between two individuals trying to determine the truth or falsity of a given proposition – in this case, the proposition that your code sucks. It’s a dialogue with a ‘daemon’ in both the computing sense and the older sense that Socrates himself would have recognized: a nonhuman being with humanlike consciousness and more than human abilities.
That’s not to say that I consider LLMs truly conscious, any more than I consider ‘daimons’, in the strict sense, as inherently evil (we can thank Abrahamic religions for that misconception). I do tend to think of the oligarchic tech bros pushing this shit as being somewhat allied with Satan – but I’m hardly alone in that, and they have largely earned it.
The digital daimons I currently engage with in socratic dialogue on a daily basis are neither good nor evil. The technology they represent is certainly being used to do what I consider ‘evil’... but that need not be. The technology can be redeemed, just as a civilization careening toward its own collapse under the pressures of late capitalism is not quite yet beyond redemption.
Meanwhile, I am enjoying my socratic dialogues with daimons and learning more from them on a daily basis. If anyone out there would like me to apply the lessons I’ve learned on their behalf… Please let me know.
Cheers as always,
–MM