A rubber duck, even on acid, won't take your job

I still remember pretty clearly. It was 2011, and I was sitting in my Certificate IV in Programming course or it might have been the start of a diploma and we we’re doing our “Project Management” unit. It wasn’t the worst class, and we had a great teacher, who’s name I wish I still remembered. But one day he turned to us, fresh blood in the world of tech and told us point blank “You won’t have jobs in a few years”.

I remember being baffled? What did he mean? Why the hell were we doing this course. He went on to elaborate that all the programming jobs would be outsourced to other countries, and we wouldn’t need to write code. I pushed it to the back of my mind, determined to write some code and find the challenge I was looking for, which would become the recurring theme which would guide the bulk of my career.

Jump to a few years later, the startup revolution back by zero interest rates was in full swing. And wouldn’t you know it, he was wrong. We were very much needed. This pattern would continue throughout my career - there was no code, then outsourcing again, and each time we were told “You won’t have a job”, and each time we were needed even more.

As software engineers, this is something we hear every few years, and this AI revolution is no different. AI - by this I mean our current iteration using LLM’s - is such a powerful tool. I often like to refer to it as a Rubber Duck on Acid. Often times when I’m stuck I’ll whack what I’m up against into the LLM, and watch what comes out. If it’s gibberish, usually that jogs something to help me get out of my funk. If it’s good, it launches me into a flow state where all kinds of work gets done.

I rely heavily on AI dev tools in my day job. I have very strict rules for myself using it at home on personal projects, or when learning something, which I think I’ll include in a future post. They really can do amazing, almost sci-fi like things. I often use an approach called the “Gold Master approach”, where I’ll take a PR that has established a pattern, turn it into a git patch and then direct the LLM to implement something using that, to amazing results. As a side note, big shout out to Sourcegraph for creating Amp - far an away that’s the tool I’ve used thus far and will.

But they’re exactly that - tools. Tools for you, as the software engineer, to use and apply as needed. AI can gather a lot of context, and it’s a sight to behold. Despite this, It’s not going to have all of the context that you as the engineer has. It’s not going to go out and try to learn why something isn’t performing at the level you’d expect, why a particular bug exists in the system, or why a design choice was actually made unless you’ve written it somewhere in the codebase. AI will tell you what it thinks you want to hear. This works great for boiler plate code, patterns you’ve written a thousand times in your codebase like with my Gold Master approach, or even when you break ideas down into really simple steps, but for novel ideas it’s not necessarily come in and save you.

To lean back into another story, I once spent a lot of time in a startup that produced both hardware and software. We had issues with a batch real-time clocks, which are small integrated circuits that kept time, which you would install on boards, that procurement had obtained. They would often drift and we spent months reading data from it, trying to figure out what was happening. To make a long story short, after stacking printer boxes high on an office chair, and aiming a desk heater at a series of test boards, we were able to determine which parts were faulty, track down the manufacturer and never buy them again. We were also able to write some code to accommodate this, and replace anything we could. This took us getting desperate and really understanding our system. AI, as it stands, wouldn’t be able to direct you to do this. It might tell you the readings are off, but it’s not guaranteed to understand everything that goes into the system, or that you have a dodgy supplier, or how to write code to accommodate for the elements.

The same is true in a pure software context. AI can offer a lot of really interesting ideas, but unless you actually understand the system and what you actually want it to do, you’ll spin your wheels. You can see this when you’re using these tools and you can’t quite eloquently explain what you need, or if you don’t break it down enough. It starts generating slop that doesn’t actually help you, and sends you backwards. We all I’m sure have a story of having to unfuck a system when we let AI run free. Or when you try to give it everything, and the context starts decaying, which again causes slop to be generated.

AI is not a silver bullet. It’s not going to solve all of your problems, or write all of your companies code. It’s a power tool that will help you build more. When you combine it with your context, your understanding of the system, your hard earned skills, that’s when the magic happens. That’s when the Rubber Duck on Acid really shines.