No flesh, bone or friction

Narcissus and Echo. Frans van der Neve @ The Met, Open Access

If you spend your days reading on the internet, this must be catching your attention.

I have noticed it goes like this with me: before I even weigh the content of what I am reading, I look for signs that it was not written by the person who signs it.

Right now, in fact, I do not blame you if you are doubting this text.

It is not just me. Plenty of people are bothered by the tics that give away the use of AI in a text. The poor em dash was the first to be unfairly tarred.

I have always been one to learn a bit of everything, and when AI became more available I did not think twice before diving in. It does not matter which tool it is; what interests me is how I can use it to do better what I always do.

Having experimented so much, I have lived through situations in which it helped and got in the way in equal measure.

No excuses for not stretching the rope

A few weeks ago we delivered a branding project in which technology was a central pillar.

With the strategy and the naming settled, the most promising path for the visual language was a concept that varied as its parameters combined: quantity, thickness, spacing and animation speed.

Exploring all of that by hand, drawing grid after grid and doing the animation, would have been tiring. Of course it could be done, and we would have done it. Another way out would have been to call in a programmer to build a tool; but the most likely outcome would have been a more conservative solution.

In almost 15 years, I have made and directed projects with very good people. Along the way I understood that a good idea is rarely the problem. Nor is there any lack of will to explore. The problem is that nobody likes doing boring work, so we test a few dozen variations and stop.

In that time I saw many promising things look like less than they were, only because there were not enough resources to get them there.

This project could have gone the same way. To stretch the rope as far as it would go, we tried to automate the generation of the combinations of variables by creating a control panel for the parameters (a parametric interface1). We did all of it with an AI coding assistant.2

Within a few hours, we had a working pilot.

We had already tried this in other cases, so we knew it pays more to adjust little by little than to try to hit the bullseye first time.

Of course it is different from having a flesh-and-bone programmer working alongside you. An experienced person makes fewer mistakes because they avoid driving the wrong way out of sheer excitement. The coding assistant does not: while it filled gaps we had not foreseen, it created others in the absence of concrete direction. There is no denying that some happy accidents happened; in that space between excitement and lack of technical rigour, good things came out.

The biggest challenge was not letting that wandering change the course of the project without our noticing. It sounds trivial, but it is a crucial point of governance.

Two days and thousands of variations later, we arrived at a highly detailed control panel that helped us create everything from the symbol to the animations, the graphics and the supporting elements of the language.

Parametric interface: each slider controls one parameter in real time

Parametric interface: each slider controls one parameter in real time

Beyond the time saved, it is great fun to be able to turn round and say "what if it were like this, or like that?" as many times as we like and watch the chain of results unfold. We could have done the same by hand, but instead of thousands we would have stopped at dozens of tests.

AI did make many things faster. Using the tool, we become braver in the face of what seemed too laborious or too distant.

Just do not be fooled: before, during and after the machine played its part, months of project went by and many people racked their brains so that there would be something to iterate on.

That is what a tool is for.

AI is far from handling everything on its own, but on its own it is killing off several excuses for not trying to solve the same old problems better.

Banana skin

One of the magical effects of being able to "ask" so easily is that, for better or worse, the technology hands you something.

When I think of the most relevant projects we have done in the last 15 years, the most uncomfortable moment came when, as I presented a project to the other teams serving the client (marketing, architecture), the group resisted an idea I was defending on behalf of my team. People questioned me, and that resistance made me dig ten times deeper until I reached a place not even I imagined I could reach.

That day I had called everyone to our office, which was in an old building, with no lift, in the city centre.

The group climbed two flights of stairs to see our wall covered in papers from the process. Nothing staged, because I was in the habit of asking the team to stick the progress up in the office while the process was happening, a sort of stone-age Miro.

Everyone sat at a round table and I shared our vision in the presentation. When I opened the floor, we began discussing details, until the banana skin arrived.

Imagine, after all that, hearing the following sentence, in a tone of disdain and with a look of disgust:

"The client will not approve this."

In the same meeting, another person said, without the look of disgust: "I find it a bit childish."

All I could think was: "Bloody hell, are you not on the same team as me? Why on earth are you burning the idea?"

My immaturity at the time made me feel that people were against me.

It has taken me until now, as I write about it, to look back far enough to understand how that dynamic helped me improve professionally. Much as I have understood that people were putting my idea to the test, I still disagree with the way they did it.

When I told this to a more experienced friend, he said my problem was having too little "corporate mileage".

He was right. I thought good ideas spoke for themselves and that I did not need to stand up for them actively.

Lesson learned, and not only because the original idea was approved by the client. The project is out in the world to this day. And far be it from me to romanticise rudeness dressed up as high standards; what made me improve was the valid point buried in there, and the disdain did nothing for it.

I did not enjoy being in that situation. Even so, I am certain that a part of it is what is missing when we decide to make AI our creative partner: friction.

Without friction there is no spark.

The tool does not challenge you the way a person would. You can make the pushback an instruction in your skill, but the tool will not doubt what you ask in a way that leaves you provoked by it. Without that possibility, you lose the chance to make use of what happens in disagreement.

It was quite a stroke to use a dialogue box to imitate a conversation. However much it looks like a real chat, and you may give the bot a person's name if you like, it will lack a face for you to want to punch. No LLM will challenge you like someone sitting with you at the table, who lives alongside you and understands your patterns beyond what you type.

The machine can imitate the questions a person would ask. What it cannot imitate is the openness to take the risk of being changed by the answer. It has nothing at stake, because it does not coexist with you. At most, the risk is all yours when you let it dig in your place.

The people who questioned me took a risk; they were going to keep meeting me, looking me in the face until the end of the project, and still they exposed themselves in that way. That is a social risk that cannot be calculated. At the very least, they cared enough to stand by that position.

Those people exist. That is why you brood, so long afterwards, over not having reacted differently. As I have done here in this text.

You will never brood over the output of your AI.

You know the machine's provocation will not find you at the next meeting, once you close that little window.


Notes

  1. A parametric interface is a digital system that allows projects to be created and altered using mathematical variables, rules and algorithms (parameters) instead of manual modelling.
  2. An AI coding assistant is a tool that uses artificial intelligence to generate and correct code from commands in natural language.