As this week’s article is going out, I am boarding a cruise ship in Miami to embark on my favorite boat trip in the whole wide world: The Cruise to the Edge. CttE (as it is called among insiders) is a floating progressive rock festival and this year’s edition features a few of my favorite bands: Airbag, Lifesigns, and of course: Marillion (potentially the first band ever to name an album after their domain name).
Progressive rock is difficult and innovative music, so much so that another one of my favorite bands, IQ (who will sadly not be on the boat this year), saw themselves forced to release an “introductory album” with some of their more “accessible” songs to help people find their way to the music, because a 24 minute and 29 seconds epic like “Harvest of Souls” is perhaps not very accessible to an audience that has been trained on three minute pre-AI slop with a predictable structure (verse, chorus, verse, chorus, guitar solo, chorus) and equally predictable chords and melodies.
Progressive rock is not only often very innovative, it is also technically very complicated, with songs often changing keys and time signatures multiple times within a single composition. Musicians get to that level of technical mastery by lots of practice and, pardonnez le mot, fucking around a lot. Really, anything that you want to become very good at requires you to spend a lot of time doing all sorts of things, not all of which are going to work out well, or at all, for that matter.
More than a decade ago, I was honored to co-host a group of visiting executives from a major Dutch insurance company who were visiting the Google Zürich office. They were interested in learning how to be innovative because it was well known that we were and the insurance industry, as a whole, is not. At events like this, I get to recycle a perfect quote from my friend Doug, who famously said: “I am innovative because I am not efficient.”
Doug’s quote came to mind the other day when I was asked to turn up something called a “RAP cluster.” RAP is an internal OpenAI infrastructure for a purpose that is irrelevant to our discussion, but our researchers sometimes need RAP to do their very innovative things in one of our AI training clusters. We have a decent runbook for turning up RAP clusters which, as these things go, contains lists of action items such as making namespaces, creating identities, modifying network ACLs, changing DNS entries, bringing up pods, and other equally boring but necessary things. Even though there was a bit of time pressure, I decided to use my new-found prowess with Codex, which I wrote about last week. I pointed Codex to the runbook (through an MCP server) and asked it to create a skill for itself using the built-in skill creator. Codex happily obliged because, unlike me, AI agents are never grumpy and so within a few minutes it had digested the runbook and created the “rap-cluster-turnup” skill. So far, so good.
I then put the new skill to work to create the new RAP cluster. However, running new skills for the first time is strangely akin to running new software for the first time: There are bugs, omissions, and unexpected side effects. Debugging a skill is closely related to debugging software; maybe it is even correct to say that debugging skills is exactly the same as debugging software.
All of this took time and, if I am honest, I am pretty certain that I could have turned up the RAP cluster faster by hand. This brings to mind a classic XKCD comic about how much time you can afford to automate a routine task. Without divulging how much time it takes to bring up a RAP cluster and how often we do this, I can say with some confidence that this investment was probably not worth it in terms of efficiency, not even in the long term. But, here comes Doug’s quote again: “I am innovative because I am not efficient.”
As a faithful subscriber, you will know that last week I wrote about my recent experiences with Codex and that one of the topics I briefly discussed there is that we all need to learn what these powerful new AI agents are useful for. There is really only one answer for how we are going to figure that one out, which is to employ a strategy called FAFO: Fuck Around and Find Out.
We find ourselves in a time where literally no one knows exactly what to use AI agents for and how to use them optimally. Is using Codex for these sort of turnups a good idea? Is creating a skill from existing documentation a good idea? Will the resulting workflow be faster to execute? I don’t know and really nobody does. To the point that I know anything about how to use anything at all effectively, it is because I have always spent a lot of time fucking around and finding out. So I need to do just that again.
When Java came, we were all under the impression that this was a technology for writing better web based front-end applications. I started writing a few applets and pretty soon figured out that this was a terrible waste of time because the applets were big, slow, and looked terrible. If I hadn’t wasted a bunch of time fucking around with Java, I would have never known, or maybe only after everyone else had found out, which is no way to stay ahead of the competition.
When I first heard of Linux, I spent a few hours copying dozens of 3.5” floppy disks and weeks toying with it on my laptop, trying all sorts of advanced things such as printing and running X-Windows. This eventually led me to dump Windows entirely on my work laptop in favor of Linux, which was documented in a 1998-1999 article series called “Living Without Windows”.
We now find ourselves in a situation where we have a powerful new technology that clearly can do lots of things very well, but it is not at all clear exactly what the limits of this technology are, how to use it effectively, and what to use it for exactly. So what to do? The answer? FAFO: Fuck around and find out!
Figuring out how to use AI agents in your organization is not a top-down problem. Some problems definitively are top-down problems. If you want to start a bank in England you can be certain that there is someone who knows exactly how to do just that, probably Dave. You can hire a Dave and then let them drive a program of things to do and presto, you got yourself a bank.
AI is not one of these things.
I regularly come across companies that have tasked an executive with defining their “AI strategy”. These executives commission studies, write policies, and regularly rock up at company all-hands to explain that AI is really important and that they are in the middle of figuring out how the company can use AI. This is of course a slow moving train to nowhere. The executives have no idea what the work processes of the people at the bottom of the corporate hierarchy really are like, so how are they going to move beyond the blandest possible advice on how to use AI tools? Not infrequently, they start “competence centers”, which I always found weird because what is the whole point of that? That the people in these centers are competent? What does that make the rest of the staff? Incompetent (by definition)?
Integrating AI into your company is a bottom up problem. Instead of a Harvard grad aided by an army of McKinsey consultants creating Powerpoint presentations about how many people you can let go when using AI (hello Block!), you “just” need to give everyone access to advanced AI tools and wait for the miracles to occur. People are incredibly innovative and you only have to unleash them and wonderful things are bound to happen.
But please put up some guardrails though and make sure that people that get access to these tools understand when and how to send privacy or business sensitive data to the model.
“But, but, then these people will just fuck around with these tools and that is not very efficient”, I hear some of you think. Yes, you are right, they will fuck around and for a while they will not necessarily be very efficient. But can you afford to be so efficient that you cannot innovate anymore? Remember, experience is what you get when you are expecting something else 🙂. Instead of being efficient, be more like Doug, be innovative!
