Who Is Still Driving?

Knowing how to catch an AI tool’s mistakes doesn’t tell me whether someone else could use it without that help. In my own work, a useful result can depend on me correcting the agent or changing its setup.

Using AI well takes practice, but people shouldn’t have to become AI engineers to use a product that promises to do a job for them. The builder needs to be clear about what the user still has to do.

---

Checking the work is part of using the tool

I was testing whether events from Google Calendar would reach a day-planning app on my iPhone. Screenshots of a pretend day couldn’t show that connection, so I asked an agent to create test events we could import. The appointments were made up, but we put them through Google Calendar and into the app on my phone.

I asked an agent to test a volleyball app from the organizer, captain, player, and spectator screens. It found that the existing tests reused one account for several roles, so they couldn’t show whether one captain was blocked from another captain’s work.

The agent built a test with separate accounts, and the practice tournament finished with workarounds for failed steps. The report kept those failures visible rather than treating completion as a clean pass.

---

Using a tool and building it are different jobs

Driving is a useful comparison because operating a car and designing one are different jobs. A driver needs to read the road and know when to stop; a passenger can reasonably expect to get somewhere without learning either job.

Much of what I do around agents is closer to working on the car. I change instructions, fix test setups, and add checks intended to catch repeated mistakes. Those are useful engineering skills, but they aren’t prerequisites for everyone who wants to use the result.

Someone choosing an app for one job may have no reason to learn how to build it. I’m already relying on a packaged product when I use Codex to build something else.

---

A good tool can give people less to learn

I’m helping friends who run a coffee trailer with some unpaid work that started as a website review. It grew into work on a small app for posting stops and handling booking requests. They should be able to tell customers where they’ll be without knowing how I instruct the AI, put the app online, or store its data.

Simple controls don’t settle this for an AI product, either. If the user must still check whether the AI made something up or finished an action, the product has left them with that responsibility.

In the tournament test, the setup disables real emails and payments and refuses to connect to the online app’s database. Whoever runs it can try the tournament without remembering those precautions, though they still have to notice the steps that fail.

---

Some mistakes belong to the tool

In “We Gave Everyone a Ferrari and Blamed the Engine”, I called for instructors, roads, and rules. But treating every failure as a training problem lets the tool off too easily.

The agent I asked to review my day planner produced a careful report that answered the wrong question, and I had to point out the mismatch. In the coffee-app work, I also had to identify unfinished pages after earlier checks had reported success.

These sessions show what this way of working asks of me, not whether an agent built for those tasks would do better. We didn’t run that comparison.

---

Say what the user still has to do

Before I rely on an agent, I want to know:

• What mistakes will I need to catch?
• What can I do if something goes wrong?
• How will I know the job is finished?

A product that needs an expert to catch its mistakes should say so before someone relies on it.

I can choose to spend time under the hood of my own systems. My friends should be able to publish a coffee stop and get back to serving coffee.