Three projects, three months

In March I built my first AI tool to ship a project I would not have finished on time without it. In April I built a better one for a delivery ten times larger. In a week and a half I start a third project where I will arrive at the day-one workshop with a current-state map already in hand, produced by the tool before the client knew to ask for it. Three projects. Three months. Each tool better than the last because the project before it taught me what the next one had to remove.

This is the piece I wanted to write first because it is the piece that explains the rest. Every other instrument I have built since March sits inside this arc. The arc is the thing.

March: the audit, stitched together at the desk

The first project was a UX audit on a nationwide shipping distributor's commerce site. Large surface, short timeline, the kind of engagement where the manual audit would have taken most of a week and the deck on top of it another two days. I did not have most of a week. I had a few days.

So I built the tool. The first version. A pipeline that crawled the site, pulled out the patterns I would have looked for by hand, and produced findings I could roll into a deck. It worked. It also did not work, in the specific way that the first version of anything does not work. The outputs needed enough review and correction that I was effectively running the audit twice: once with the tool to get a first pass, and once by hand to verify what the tool had returned before any of it went to the client. The final presentation, I stitched together manually at my desk, choosing which tool-produced findings were sound and which needed to be rewritten or thrown out. Time savings were real. They were not the time savings the tool would eventually deliver.

The deeper thing I noticed, sitting there at midnight stitching slides, was that the tool was built wrong in a way I could now see. I had spent too much of the build on cloud bridges between services that did not need to talk to each other. I had fought enterprise firewall constraints by adding more integrations instead of by removing them. The architecture I had reached for was a copy of what I knew how to do as a software engineer, not what the work was actually asking for. The tool worked, but it worked because I was working alongside it doing the second pass by hand.

I shipped the project. The deck went to the technical team's backlog. The bugs the audit identified got prioritized and fixed. The client was happy. I knew, by the time the final slide was placed, that the next version of the tool had to be built differently.

April: the orchestrator, built right the second time

The next project came fast. A global consumer brand, several brands under one parent, three personas, three channels, a multi-sprint agent implementation. Build team of dozens. Design work on the critical path. The manual process would have taken months. We did not have months.

I built the second tool. This is the one I have written about elsewhere as the orchestrator. Single orchestrator with sub-agents per task. Transcript reader, flow writer, persona mapper, channel adapter, renderer. A manifest as the source of truth. Local. No cloud bridges that did not need to exist. No integrations I could not justify. The Figma connection got built and then got deprecated when I realized I did not need it. The plug-ins came out. Each week the integration layer got thinner.

The architecture I had reached for in March, I now built without. The architecture I had been missing in March, I now built in. Sub-agents with judgment, an orchestrator that routed between them, a manifest that held the state none of them owned individually. Three of us used it: another experience architect, the solutions architect, and me. Build time per section dropped from a couple of days to a couple of hours. We did next-day follow-ups after refinement meetings. We designed with real personas instead of one default persona, because the new tool made the harder version cheap enough to do.

I noticed something the March project had hidden from me. The manual audit work I had done in March was not wasted. It was the reference set. The hours I spent at the desk choosing which findings were sound and which were not taught me what correct looked like in this kind of work. The orchestrator's outputs got good fast because I knew, from the March project, what good looked like. The painful version of the work was the training data for the version that came next.

The longer version of how the orchestrator works and what it taught me is the next essay.

Late May: the discovery, produced before the workshop

The third project starts in a week and a half. A CRM implementation for a global warehousing company. Discovery phase, current-state mapping, the part of the engagement where the team usually arrives at the day-one workshop with a list of questions and uses the workshop to gather what the questions point at.

I am not arriving with questions. I plan to arrive with a draft current-state map already produced, by the orchestrator running against the materials the client has already shared. Account hierarchies, process documents, integration inventories, user role descriptions. The tool reads what is available, produces a first-pass map of how the business sells today, and I bring that map to the day-one workshop as a starting point instead of a wish list.

The workshop is no longer for gathering. It is for correcting. The client sees the draft, marks where it is wrong, fills in what the tool could not see, and we leave the workshop with a corrected current state instead of with raw notes that someone has to turn into a current state over the next two weeks. The two weeks become design time instead of synthesis time. That is real leverage, applied earlier in the delivery cycle than the previous two tools could apply it.

The tool is not new. The orchestrator pattern is the same one I built in April. What changed is where in the delivery cycle the tool is being applied. The first project paid the cost of manual review at the end. The second project caught up to the work in the middle of the sprint. The third project gets to start work that the client has not yet asked for.

What the arc compresses to

The thing a designer reading this should leave with is short. The tools compound. You build them while doing the work, you accept that the first version will need manual cleanup, and you iterate fast enough that by the third project the tool is doing work the client did not yet ask for.

There is no separate research phase. There is no quarter spent figuring out the right architecture and then a quarter applying it. There is the next project, and the tool you will use to ship it. The work is the training data. The constraints of the delivery are the design brief for the next tool. The architecture you reach for in the first project is the architecture you remove in the second, because the first project showed you which parts you did not need.

I cut my teeth on AI delivery in March. I built the second tool in April. The third project starts in a week and a half, and I will arrive at it from a different place than I arrived at the first. Not because I studied the field between projects. Because I shipped the first one badly enough to learn what the second one had to remove.

What this is part of

The essays that follow this one are about the instruments themselves. Each one is its own piece. The arc above is what they have in common.

The instruments compound on the same clock as the work. The work is the brief. The brief produces the instrument. The instrument changes what the next brief can ask for. None of this requires a research budget or a sabbatical or a separate methodology phase. It requires shipping the rough version, paying the manual review cost the first time, and noticing what to remove for the next one.

That is the practice.