Given the levels of autism exuded by this blog, one might assume (and be correct in doing so) that I’m quite the fan of Star Trek. One of the running themes therein is the notion that technology progresses at a rate not necessarily coupled with societal advancement. In other words, we (hello, fellow humans) run into problems when technologies are made available to folks that do not have the maturity to use them wisely. This is not to say that it is necessarily appropriate to stall scientific endeavors across the board (for that decision itself is one that is necessarily only made by a society mature enough to consider the notion in the first place); rather, we ought to strive for societal wisdom. And that’s what this particular rant is about: wisdom as it pertains to the obvious shift toward artificially intelligent and other autonomous systems.
There is much to say about various ethical concerns in the use of artificial intelligence and in the deployment of autonomous systems in the work force. We could spend quite a while talking about workers that are displaced or laid off due to decisions by their respective companies to replace them with automated robots or kiosks or whatnot. We could talk for quite a while about thievery of art and other creative products that obviously puts artists, musicians, and authors at an even greater economic disadvantage than they already were. We could even chat about the ecological impact of the training of large language models and the like. But so many other writers, most of who are more literate than I, have already tackled these topics. (This is not to say that what I’m going to be focusing on hasn’t already been tackled… but hell, let me come up with an excuse to keep me motivated enough to finish writing this damn piece.)
What I want to say is this: autonomous technologies (and I’m going to hereafter lump AI into this) tend to be deployed and utilized without any regard to the human tendency to avoid double-checking work at all costs. What do I mean by this? Within the context of computer science, most developers (seem to) enjoy writing their code, but those same developers care very little to test it. One measure of the maturity of an organization’s application development team is whether a dedicated Quality Assurance team exists—simply because developers are so bad at properly testing their own software. Part of this is because it simply isn’t fun to test software, unless you’re a QA masochist… but in many cases it’s simply that one’s familiarity with the codebase prevents proper detection of bugs that might exist in the new system. And you see this outside software development circles as well—for example, book authors employ editors even though they themselves have meticulously poured over their own drafts.
I think you can probably see where I’m going with this, but just to make it fairly clear I’m going to provide three examples in which products and methodologies were developed and released with (presumably) the best of intentions, but without proper attention paid to human nature as it pertains to active testing of those products and methodologies: (a) artificial intelligence, (b) autonomous vehicles, and (c) test-driven development. And now that you’ve read what I’ll be griping about, presumably you’ll say to yourself “ah, <redacted> is merely an old man shaking their fist at children on their lawn, forever yelling about that new-fangled music and lingo of the youngins.” And, while I can certainly say that I look forward to the day I find the opportunity to scare children off my lawn, I’m always eager to discover new music and learn new language. And, I don’t inherently hate the following technologies—but I do wish folks would be wiser with them. Let me elaborate.
Wisdom in Vibe Coding
I’ll begin with artificial intelligence, as at the time of this writing it seems to be fairly ubiquitous. In particular, the use of GPTs in what folks are dubbing “vibe coding” which, I suppose I’ll just drop the quote from Andrej Karpathy, who publicly coined the term back in February of this year:
There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like “decrease the padding on the sidebar by half” because I’m too lazy to find it. I “Accpt All” always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. I’m building a project or webapp, but it’s not really coding—I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.
Now obviously any software engineer worth their salt ought to look at this and have alarm bells going off in their head, or at least hold some level of suspicion toward anyone that claims to purely vibe code. And yet, it’s hard to deny that the trend is setting in, and it’s hard to deny that LLMs can be extraordinarily useful in building out boilerplate, learning new languages, or even in the static analysis of existing code. So given that vibe coding is certainly entering the workforce, whether senior software engineers rebel or not, one ought to ask how to engage responsibly.
And the key here is this—how do you go about vibe coding while retaining your identity as an esteemed software engineer? Well, first I’d imagine one ought to try to distinguish between a computer programmer and a software engineer. Perhaps unsurprisingly, the answer is simple: computer programmers merely write and perhaps debug code, whereas software engineers plan and design software, document their product, and fully test their codebase. Yes, documentation and testing—that’s the major distinguishing factor. And this is where vibe coding can really kick a dev in the ass… a dev that doesn’t care about what distinguishes software from computer code is likely to not test what an LLM spits out.
So if you’re, let’s say, managing an organization that is considering the adoption of AI in the workforce, I would strongly recommend including policies and training that cover those additional safeguards. Quite frankly, they ought to look very similar to how one might properly establish a traditional QA team. But, the temptation to skip these safeguards is always present, as I’ll try to point out in the next section here.
Wisdom in Autonomous Vehicles
I think you might be able to consider me a technology minimalist. But I have a specific meaning for this: I really think technology should be used to solve problems, and shouldn’t be used to create problems. Technology ought to exist to serve the user, and not to create problems for the user. I personally wear an automatic winding analog watch—not a smart watch. Why? I want to know the time, and I don’t need to be connected to the internet every second of the day. In the same way, I want technology in my home and in my car to serve me and to solve specific problems… not to create more work.
So take an autonomous vehicle, for example. Those new(er) features that augment human effectiveness at the wheel? That’s great. Automatic braking in the event that a user (driver) is about to rear end the vehicle in front of them, or the little lights on mirros that detect cars that are passing too closely? Those are fantastic—they merely enhance the driver’s experience. But fully self-driving vehicles are problematic—they replace the driver entirely. And really, the companies that build these cars will tell you that the driver ought to be paying attention to the road anyhow, but then what’s the point? I would argue that it’s harder to pay attention at the wheel when the user isn’t actually driving. And the reason for this is mildly adjacent to our discussion on software engineering and vibe coding—humans do not inherently like to test things. People (who touch grass regularly) don’t have the time to micromanage things, and would rather be doing more fulfilling things with their time. When you’re micromanaging an autonomous vehicle, you’re essentially testing it. Get what I’m getting at? Again, technologies should enhance and not replace folks.
Wisdom in TDD
I’ll say that these sorts of issues are not just present in automation. Rather, they exist in nearly any methodology that serves to make something easier without considering human nature. Test Driven Development (TDD) has been a large gripe of mine for a while for similar reasons. Essentially, TDD is a process used in object- oriented programming (OOP) that entails developers writing unit tests before writing unit code. The order of development matters—my criticisms here are not of writing test cases—those are super helpful in general. But TDD seeks to force developers into a box where they’re not seeing the forest for the trees, where they’re forced into a paradigm that might cause Malvina Reynolds to write another smash hit. Born out of an idea to make things easier, it requires users to properly follow a particular workflow in order to reap the benefits.
I suppose my notes on TDD, and really all of the above, are commentaries on problems that folks tried to solve by releasing tools instead of fixing underlying procedural issues. Think of your favorite economic model that has historically not worked across the world, and when you go to defend it you go “oh well, it was just never implemented properly!” when in reality, your model simply had a tendency for abuse because it required people to adhere to a ruleset that simply was not intuitive. Or, think of a traffic pattern that has a lot of wrecks, even when the signs are very clear—you could go “oh, well this system is great and people just need to read the traffic signs!” and that’s all well and good except that people just don’t do that. And so you can’t release a piece of technology, or a methodology, or a workflow with the expectation that it’s just going to execute in stellar fashion if you’ve attached the onus of proper operation soley to the user.
So what can you do instead?
Well, those technologies are going to stick around. We may see a decrease in their prevalences as people stop to care when the next hot thing comes out, but they’re not going to disappear from the workforce any time soon in entirety. So the best thing you can do is make sure that you are carrying out the responsibilities assigned to you by the framework, and to train others to do the same, and to perhaps keep an eye out for (or build, if applicable) better technologies that are harder to abuse. Computer science—and really, the advancement of technology—does not happen in a vacuum. So, while societal and technological progression may not be coupled, society and technology most certainly are.