The Mountain Doesn’t Prove the Trail

A few weeks ago, David Yamane, a sociology professor at Wake Forest University, posted a slide he uses to introduce his classroom policy on generative AI. On one side were the things he wants to emphasize in class: questions, process, understanding, intention, originality, curiosity, humility, empathy. On the other were things AI tends to emphasize: answers, products, pattern matching, optimization, recombination, efficiency, certainty. Like most classroom slides, it was deliberately binary. A slide shown on the first day of class has to establish expectations, not survive a doctoral defense.

I nevertheless spent something like two dozen conversational turns with an AI model taking it apart.

Then I read Yamane’s full policy, which complicated most of the objections. It allows some AI use, requires disclosure, makes students responsible for verification, and in some cases asks for “receipts”: the tool, prompts, responses, and a short account of what the student accepted, modified, rejected, or checked. A lot of what I thought was missing from the slide was already present in the document behind it.

Naturally, the machine and I produced a 2,400-word essay about this.

I kept it in draft for a few weeks, returned to it, read it again, and thought: naaah.

The problem was not that the essay was bad. It was coherent, specific, and in several places probably correct. The problem was that it had turned a long process of discovery into a polished postcard from the destination. What had interested me was the trip: criticizing the binary, discovering that the policy already answered some of the criticism, applying the distinction to my own use of AI at work, wondering how much authorship I could claim over an essay largely drafted by a machine, and eventually recognizing that I was asking a classroom heuristic to become a general philosophy of human-machine collaboration.

The finished artifact concealed most of that.

That experience has been sitting beside another one in my day job. I work in DevOps, where I have been using an agentic coding environment to help with a project spread across at least five repositories. One working specification has grown past five hundred lines. There is a separate to-do list. There are dependencies on IAM roles that need to exist before a CodeBuild project can really be exercised. Secrets Manager resources cannot be completed until an RDS instance exists, and that database belongs to work sitting on another team’s Jira board.

The third time I went through the exercise of provisioning a new ECS service, I expected the process to become simpler. Instead, the checklist got longer.

Part of that is experience. The first time through, a great many decisions are invisible because they are inherited accidentally. You copy an existing pattern, change the names, paste some Terraform between temporary editor windows, replace a few values, and keep going. Six months later, nobody can tell which settings were intentional and which were there because that happened to be the example you copied.

An agent can make those assumptions visible. It can produce a mile-long list of things that are technically undecided. That list can then be pruned with a surprisingly powerful instruction: use the current defaults. Suddenly a dozen supposed design questions collapse into one rule about convention.

This is useful. It is also a documentation factory.

Specs generate task lists. Task lists generate implementation notes. Investigations generate runbooks. Runbooks generate wiki pages. Pull requests acquire summaries. Incident investigations become Confluence documents. The ability to produce documentation is no longer constrained by the fact that somebody has to sit down and painfully type all of it.

The old scarcity was text. The new scarcity is knowing which text matters.

This is where I have started to invert an increasingly common claim about AI. I used to think that making finished products cheap would make process easier to see. If code, prose, images, or music can be generated quickly, then perhaps the valuable human work becomes obvious: framing the problem, setting constraints, judging the result, integrating it with the real world, and deciding what deserves to survive.

I now think that is only half true.

AI makes products cheap enough that process can become even harder to discern.

A five-hundred-line specification looks like evidence of process. So does a detailed runbook. So does a twenty-page incident report. So does a beautiful architectural summary written after the fact. But none of those things necessarily tells you what actually happened. The mountain of artifacts can obscure the path that generated them.

Suppose another engineer inherits my current project. There may eventually be thousands of lines of code and documentation available to them. The important questions are much smaller. Which choices were deliberate? Which simply inherited an existing convention? Which components were implemented but never integrated because an upstream dependency did not yet exist? Which claims were actually verified? Which parts were generated against assumptions that later changed? Why does this resource exist in this repository rather than another one?

A hundred pages of documentation can still fail to answer those questions.

The same problem appears in a much stranger form on my blog, The Grey Ledger Society. It began largely as a place to memorialize long conversations with machines. I would spend dozens of turns wandering through books, films, technology, games, work, history, or some combination of all of them, then eventually say something like, “memorialize this chat, please.”

Sixteen months later, the site has more than seven hundred posts.

That is an absurd quantity of artifact. It is also not necessarily a transparent record of process. A finished essay may preserve the conclusions of a conversation while erasing the branches that mattered most: the analogy that failed, the objection that changed the thesis, the model’s contribution that I adopted, the model’s contribution that I rejected, or the moment when something from my own experience suddenly reorganized everything else.

One recent post accidentally left one of those seams exposed. A bracketed editorial instruction remained in the published piece: this is the section nobody else can write. I had intended to remove it, pasted the draft into Ghost, went on a three-day trip, and forgot.

I am leaving it there.

Trying to clean it up now would imply a cleaner production history than the piece actually had. Human chatted with machines, machine helped synthesize the conversation, human pasted the draft, human got distracted, editorial scaffolding survived. That is not a defect in the provenance. It is the provenance.

The abandoned Yamane essay is useful to me now for the same reason. It is no longer something I need to keep revising. It is Exhibit C: an example of a competent product that failed to preserve the thing I actually cared about. The process was the interesting object, and the artifact flattened it.

None of this means every prompt should be saved, every chat transcript committed to Git, or every discarded branch preserved forever. That would simply replace one form of opacity with another. Exhaust is not provenance.

The more useful standard is whether somebody can reconstruct the decisions that still matter. What problem were we trying to solve? What assumptions governed the work? What did the machine propose? What did the human accept, reject, or change? What could actually be verified at the time? What remained blocked, uncertain, or dependent on somebody else?

AI makes it very easy to leave evidence that work occurred. That is not the same as leaving evidence of how the work became what it is.

When every process can generate a mountain of artifacts, the mountain stops proving that the trail was ever visible.