Skid Marks Around the Curve

Sometimes I see skid marks on the highway, usually somewhere around a curve, and wonder what happened there. You don't get the accident, the near miss, or the driver explaining what they were thinking. You get evidence that something was moving quickly, encountered a constraint, and changed direction rather abruptly.

I've been seeing a lot of skid marks at work lately.

I use an agentic IDE for infrastructure and DevOps work. Recently I pointed it at an API repository, four repositories containing libraries that API depends on, and the Terraform repository that deploys it, then asked a deceptively simple question: what does this thing do?

It did remarkably well. It traced endpoints, routing, dependencies, calls into a database, and deployment configuration. It established that the database interaction was read-only. It could follow symbols across repositories much faster than I could have by opening six VS Code windows and periodically forgetting which one contained the thing I had been looking for ten minutes earlier.

What it couldn't tell me was why the API mattered.

The next morning I was pointed toward about five internal documentation pages containing product history, project scope, and architecture. Feeding those into the investigation filled in more blanks. What remained were questions for developers and technical leads: Who actually depends on this behavior? Which parts are historical residue? Why was this boundary chosen? What assumptions are still current?

I don't regard that as the machine failing. If anything, it got me to the interesting questions unusually quickly. Instead of approaching someone with "Can you explain this API?", I can arrive having already reconstructed much of its machinery and ask about the parts that apparently aren't recoverable from the available record.

But then I wonder what happens if everybody does that.

A former colleague recently described an assumption at another company: with agents, you can do X twenty times faster. My immediate reaction was that the choke point gets saturated twenty times faster too. If I can get through repository archaeology, Terraform analysis, and a first implementation in a fraction of the previous time, I arrive sooner at the DBA, security reviewer, platform engineer, technical lead, or whoever owns the next decision.

Is that an efficiency gain for the system, or a load transfer?

I have another infrastructure proof of concept spread across several repositories. Agentic tooling has helped me produce a specification more than eight hundred lines long, plus a separate three-hundred-line task ledger. Those documents contain scope, exclusions, IAM boundaries, acceptance criteria, evidence, rollback procedures, dependencies, and unresolved questions. Three days after the specification first appeared in Git, I was staring at it wondering how it could possibly be only three days old.

Without the agent, much of that information probably would have existed in temporary editor windows, copied snippets, browser tabs, and my head. Making it explicit is plainly useful. But the process also became fast enough that the task ledger fell behind the implementation when the agent hit its usage limit before updating it.

At what point does documentation stop making a process legible and become another system whose state has to be synchronized?

This isn't an abstract concern when the same accelerated project is waiting on humans. One piece depends on a database another team has not yet deployed. Another depends on roles being provisioned. I requested production credentials through the approved password-management system more than a week ago and still don't have them.

Those delays are not equivalent. A database owner deciding whether a migration can be run safely is exercising judgment and authority that I don't particularly want automated away. A security reviewer considering blast radius is doing something similar. A credential request sitting unanswered for eight days is different, but from my side I can't necessarily tell why. Workload? Priorities? Ambiguity? Process? Somebody forgot?

The agent makes the boundary easier to reach without necessarily making what lies beyond it easier to understand.

There is another complication. Perhaps twenty-times-faster work doesn't merely send the same amount of work downstream more quickly. Maybe it creates more work. If writing a detailed specification becomes cheap, do we start asking for more specifications? If investigating a service takes an hour instead of a day, do we investigate things we previously would have left alone? If producing five plausible changes takes the time that once produced one, have we increased throughput or manufactured four additional review requests?

And what about verification? The agent that analyzed those six repositories was fast and thorough, but speed isn't the only relevant measure. Some of its findings could be checked directly against code. Others became more credible when compared with architecture documents. Still others required people. The work did not disappear so much as change shape: less searching, perhaps, and more deciding whether what had been found meant what it appeared to mean.

This is why I'm becoming wary of describing the human part of technical work as a "layer." It looks more like a weave. Ownership is embedded in repository boundaries. Risk tolerance appears in IAM policies. Organizational history survives in defaults. Authority lives in approval paths. Tacit knowledge sits in people's heads, but some of yesterday's tacit knowledge is today's pull-request discussion or Confluence page, waiting for a sufficiently capable tool to find it.

Agentic tooling may be making that weave more visible simply because I am traveling through the codified portions of the system faster than I used to. I don't yet know whether that makes the human parts more important, more overloaded, or merely harder to ignore. I suspect the answer depends on which skid marks you stop to examine, what was around the curve, and whether anybody bothered to record what happened there.