I Learned AI by Building Something Useless

Every executive I know has an opinion about AI. Considerably fewer have built anything with it.

I wanted to understand how large language models actually assemble automated tasks, and how those tasks become something closer to an agent. Reading about it was not going to do that, and neither was another certificate. So I built something.

The useless thing

I built a predictive model for opening-weekend box office and Best Picture outcomes. Title metadata, trailer performance, search trend data, release-window competition features.

It has no commercial application. Nobody is paying for it, and I am not selling it. I chose the domain because I have spent twenty years in it, which meant I could tell immediately when the model was wrong in a way that mattered and when it was wrong in a way that did not. That judgment is the whole value of building in a field you know.

You do not learn where the tooling breaks by reading about it. You learn by hitting the break yourself.

What I actually learned had almost nothing to do with box office. It was about the shape of the work: how much of it is defining the task precisely rather than writing instructions, how quickly a workflow becomes brittle when the inputs vary, where a model produces a confident answer that is wrong, and how you design a process that catches that before a human sees it.

Those lessons are domain-independent. That is the point.

The useful thing

Several months later a client had a billing problem. Their invoicing process ran more than twenty days by hand: warehouse order exports, reconciled against rate cards, assembled into invoices, checked, corrected, sent. Every month. It consumed a meaningful share of a finance function that had better things to do.

The obvious framing is "automate the invoicing." That framing produces a brittle script that works until the first unusual order and then quietly produces a wrong invoice, which is considerably worse than a slow one.

The useful framing came from the useless project. The real deliverable was not automation. It was the business-rules layer: the documented, explicit statement of how an order becomes a line item, what the exceptions are, and which ones a machine must refuse to guess at.

What that looks like in practice

• Exceptions are flagged, never guessed. The system's most important behavior is knowing when to stop and ask a person
• Reconciliation is built into the process, not bolted on afterward as a check somebody might skip
• Sign-off stays with a human, because an invoice is a legal document and confidence is not accuracy
• The rules are written down. That document outlives any particular tool and is the durable asset

Two delivery paths were designed and compared, from a scheduled low-code task to a tested production build, with the trade-offs made explicit rather than assumed. The work has since been shaped into a four-stage offer: assessment, pilot, production build, managed support.

The actual argument

The useless project is what made the useful one possible, and I do not think that ordering is incidental.

If I had come to the billing problem straight from a certificate, I would have reached for automation and probably shipped something that worked in a demo. Having already built a thing end to end, failed at it in several instructive ways, and watched a model be confidently wrong about something I knew the answer to, I understood that the job was to design where the process refuses to proceed.

That is not a technical insight. It is an operating one, and it is the kind of judgment that only comes from having done the work rather than read about it.

Where this fits

This is the same move I have run for twenty years, pointed at a capability rather than a market. Find the thing that is not being used, find the application somebody will fund, build the infrastructure that makes it deliverable, then write it down so it keeps running without you.

The sequence does not care whether the asset is a cinema lobby, a studio workflow, or a model you taught yourself to build on a weekend.