← Previous Next →

Driving AI creatively

I think we’re all a bit afraid of being driven over by the machine.

It is easy to agree that we people need to take control of the machine.

There are various angles, levels, and ways to be in control of it. I’m going to talk about just one of them:

We are creative

At this point I will recommend a really good book about creativity, by Dr Peter Court, “Distilling Creativity”.
My Goodreads review says:

This is a good book, an easy and fun read.

All the pertinent info is presented easily, without the usual host of poorly written stuff by someone with a plumb in their throat trying to sound intelligent. And failing.

If you think you are not creative, you’ll come away realising you are, with a few extra tools to bulldoze away your blockages.

Or if you know you are somewhat creative, you’ll come away more confident, humble, and ready to play with your ideas again.

I highly recommend this book. Not just for writers, but for any type of creative.

No matter what you are creating, your creativity is a gift from God which no machine has. If you want to be in control, you need to know and use your edge, and it is this: your creative talent.

The following are at least some of the creative aspects of software engineering:

Note that you do these things before you start coding, and often you do these things with others (collaboratively).

I’ll briefly digress from the creative stuff to the engineering part of “controlling the machine”.

The machine (e.g. an AI agent like Claude Code) won’t do a good job of writing good code unless you direct it well. You know how you want the code written, but you don’t want to have to explain the same things over and over to it in long prompts. So you put the restrictions, directions, and a detailed description of the process into “skills”, and in fact I have one skill that calls up all my other skills, and I think of as a "workflow". This instructs how to take the design specs and other human-created documents, and start work on it. First, split the work into logical chunks, and then use a process for each chunk. Look at the initial work from an adversarial standpoint: does it fulfil and adequately test every aspect of the design? If so, write the code. Test it. If it’s an API, use a security review skill, then a code review skill, then a fresh eyes overview skill, fix problems found at any of these stages. Then let a human review it.

We’re finding less and less issues in the human review, and when possible I use this as feedback to tweak the workflow. We’re not there yet, but at some point we will be able to remove the human code review... but not ever the design review.

So, you can see that soon the human input will be the creative part at the start.

If you are a C-level manager, think about this: you need to empower your people to be creative, rather than busy. Emphasise the value of architecture and design, and put those in your organisation who are creatively active already, in the power seats working the levers of the machine.

Let them, encourage them, require them, to spend time honing the design up front, and expect them to be collaborative. Make sure the design is presented in various ways so that people can understand it. A UX/UI designer will need it expressed differently to how a product designer will want to understand it. A software engineer will need a more detailed design spec. An architect will want to see the architecture. They all must collaborate and sign off on each other’s ideas. Don’t use AI for this! Get people writing, drawing, reading, and talking.

Spend time here, and then when this info is fed into the workflow, then they can have a coffee, do something fun, and dream up the next idea - all the while monitoring the workflow.

Allow a few wide throws to be wasted. In the end, one wild idea may end up being the next best thing.

← Previous: Your Voice Next: What's all this got to do with creative writing? →