The Art of AI

I stopped the work a few times before this article existed. I had explained what I wanted and asked AI to tell me how it understood the assignment. Its answer covered the broad direction, but I was still deciding what the assignment should become.

We began with a simple question: how should someone who is curious about AI get started? Past Life already had articles, case studies, and short, approachable pieces we call BYTS. I wanted a way into that work. AI Foundations was a plausible name. The Art of AI felt closer to the way I use it: learn the basics, understand the situation, and choose your next move with some purpose.

The name came quickly. The definition took longer. Was this a beginner series, a column, or one article we would keep revising? Which parts could AI develop, and which choices were mine? When I kept talking through the idea, AI sometimes treated the new context as an instruction to make something. I stopped it because we were still deciding what that something was. This article is the starting place we arrived at. I expect it to change as the work teaches me more.

That pause is part of the method. AI can make a draft much faster than I can untangle a poorly defined job. Spending time on the job first makes the speed useful.

The work beyond the screen

I learned to look beyond the screen while doing user experience (UX) work. On an early U.S. Bank project (opens in a new tab), the visible problem was a website whose visitors rarely moved beyond the page they entered. The work reached into the content: what people were looking for, how topics were named, which articles belonged together, and how someone could find a useful next page. The resulting redesign connected related material. It taught me that a page only works as well as the relationships behind it.

The same lesson became harder to miss at Sedgwick (opens in a new tab). I mapped the steps an adjuster took in the field alongside the information moving through the company's systems. One handoff did not appear on the map until we found three employees copying information between systems. Their work was the connection. A diagram of the software alone would have missed it.

These were UX projects, years before this AI work. I wasn't using AI to do them. They trained me to follow a task past its visible surface: through the people, information, decisions, and handoffs that make it possible. UX is where I learned to ask those questions. Systems design is how I use them now.

In Thinking in Systems (opens in a new tab), Donella Meadows describes a system through its parts, the connections among them, and what they work together to do. That gives me a practical test for an AI assignment. What are the parts of this job? How do they connect? What is the result supposed to accomplish? A prompt is only one part of the answer.

Give AI a system it can work within

Past Life is one part of a larger digital ecosystem. Its pages connect to articles, case studies, other projects, and people who may arrive with very different questions. When we built the Harman Industries (opens in a new tab) page, a draft that merely listed projects would have missed the point. I wanted someone to see why those projects belonged together and find a useful route forward. Once I described those relationships, AI could help build the page. I still had to judge whether the page made them clear. The page came together quickly; deciding what it needed to connect took longer.

The writing work has a similar structure. We have shared instructions for how an article moves from an idea to a draft, along with separate voice and editorial guidance for each project. We work on titles, check claims and links, keep track of which edition we are reviewing, and decide what is ready to appear on the site. Those pieces have taken repeated revisions to put in place. They let AI carry more of the work without making every project sound the same.

I have found it workable to use the same AI model across several projects. What has helped me most is giving each project enough context at the beginning and checking that the system understands the job.

An instruction as short as proceed can now carry a defined job through several steps we have already worked out. That word is not the method. The method is the context and the sequence behind it: what sources to use, what to produce, what to check, and where the result stops for review. Someone new to AI does not have to build all of that on day one. I didn't. But showing only the finished page would hide the work that makes it possible.

This article supplied a good test. At one point I said to write the articles we had discussed and publish the first five. Then I thought about the site a month from now. I wanted new writing in reserve, and I wanted to read drafts in a local version of the site before choosing what went live. I stopped the plan and separated drafting from release. AI could organize and write the material. It could not decide my publishing rhythm from an instruction I had just changed.

That is why I ask AI to tell me how it understands the assignment before I hand over a larger piece of work. I can correct the map while it is still a map. I can also say which decisions it should bring back to me. When we were naming this series, choosing the lion artwork, and setting the release plan, those were real decisions, not details for a draft to fill in quietly.

Work quickly, then see what happened

Once the assignment is clear, AI can research a familiar subject, organize material, draft an explanation, make a local page, or follow a reusable set of instructions for repeated work. That gives me more room to work on direction and on the choices that shape the result. It also means a misunderstanding can travel farther before I notice it.

We have already seen a small version of that risk in our website work. Instructions describing what a section should eventually contain appeared as the section's actual page copy. The page was filled, but the article it called for had not been written. The result looked complete until we read it as a visitor would. I wrote more about that in When the project outgrows the chat (opens in a new tab).

Review has to follow the work into its real setting. A convincing paragraph may make the wrong claim. A useful article may read awkwardly on a phone. A local page may work while the public page shows something else. I want to see what AI understood, what it did, and where I can change the direction. That is how the system stays useful as it gets faster.

I want to reach a point where I can direct more of this work by voice from the shop or the truck. We are building toward that; it is not a completed case study. The measure will be whether work moves through the system correctly while I can still see and correct what matters.

Where to begin

If you are just getting started, choose one small real task. Write down who will use the result, what information AI needs, which decision is yours, and where the finished work should go. Explain that to AI and ask it to tell you how it understands the assignment. Correct anything important, let it make one version, then check the result against the job you described.

That exercise is a doorway, not the whole practice. From there we can learn how to map a larger job, write instructions that travel well, decide what to trust, and build checks into repeated work. The older case studies show where my systems thinking came from; this series will show how I use it with AI now. Some articles will teach one basic move. Others will open up the process behind a real project.

I joke that my kung fu is strong when I can see the work, set up the next move, and recognize what needs correction. Some days it is stronger than others. The Art of AI is a living place to share what I learn as the system grows, and to make the next move easier for someone else to see.