GPS: A Global Positioning System for AI Agents

Q: Every large engineering org has tribal knowledge. The people who know where to look, who to ask, which spreadsheet has the real numbers. What happens when agents inherit that same dependency on tribal knowledge?

Jeremy: They ask for help. Same as humans do, but faster and with less ability to recover independently.

The information that drives our decisions lives in five or more disconnected systems: ticketing, corporate directories, release schedules, and spreadsheets. Each one has its own login, its own query language, its own data format.

Right now, getting a straight answer to a question like “who owns the inference component and what’s their current bug load?” requires a person who knows that the team spreadsheet uses a unique naming convention, and that the component mapping lives somewhere else entirely. That person cross-references three systems in their head.

That tribal knowledge tax is real. Onboarding a new senior hire takes 12-16 weeks when tribal knowledge is high, versus 4-6 weeks on well-documented teams. Multiply that across enterprise development teams, and the cost is staggering.

Agents are only as good as the data they can reach. Tribal knowledge is, by definition, unreachable to them.

Continue reading “We probably need a GPS for Agents” →

A previous post described what a day looks like when your engineering system runs mostly on its own. This one is how to reason through the structure required to drive the behaviors we want.

Starting with a simple concept, the learning organization. Here is a system dynamics stock-and-flow diagram.

In the simplest terms, learning begets learning: 

What we’re actually tracking

Most engineering metrics measure what the system produced: PRs merged, tickets closed, features shipped. Those are fine for tracking work. They’re less useful for improving the system doing the work. For that, I want to use and augment the DORA metrics that were successful for my teams in the cloud services space.

Every metric we care about maps to one of the two loop types:

• Balancing loops create friction and slow things down. The metric targets are always down.
• Reinforcing loops create compounding improvement. The metric targets are always up.

Continue reading “Structure Dictates Behavior: golden signals for agentic development teams” →

What’s your working theory?

A software factory model for software engineering should be created. Not only does it make economic sense, it is a bounded unit that architects and CFOs can reason about. Centralizing to a factory model provides the exact fuel that a continuously learning, “agentic” factory needs – endless data, often easily labeled, governance and the network effects that keep reinforcing loops spinning.

There are a lot of “if” conditions between here and there. It will take hard work – but the trajectory is clear, and we can build structural advantage now.

Context Switching

The standard workflow for agentic AI looks something like this: an agent runs, hits something uncertain, and pauses to ask a human. The industry has formalized this pattern under the label “human-in-the-loop” (HITL), and most teams treat these interrupts as a safety feature. They’re not wrong about the safety part – the presence of people in the system is a feature, not a bug. But we can build guardrails and teach the systems to do far better than they do today.

Continue reading “Toward Zero Interrupts: A Working Theory on Agentic AI” →

We are entering a period where the initial “shock” of AI capabilities is fading, replaced by a ruthless reality: The learning period is well underway.

What do we do with a boundless new toolset? In 2026, the question isn’t “Can AI do this?” its: Who do you want to learn with?

Public “Oh 💩” Moments

The discourse on Twitter/X right now is a perfect barometer. You can see it in threads like this one, where the realization is the tools aren’t just toys; they are replacing the fundamental loops of software creation.

The follow-up replies indicate a lingering uncertainty and hesitation that must be confronted not with fear, but with measurement. While the industry processes that shock, the reality for the Code Shepherd is already here. Various data points support this shift, e.g.: GitClear’s 2025 AI Code Quality Research reveals that code duplication has risen 8-fold, and for the first time in history, the volume of copy-pasted code has exceeded refactored code. The “volume” is up, but the “shepherding” is the new bottleneck. This is not the same as reviews. Reviews are commodity within a quarter or 2. Evals are likely to be commoditized next.

For the unprepared, this could be a crisis. For the Code Shepherd, this is the baseline.

Continue reading “The “CEO Archetype” is the new 10x” →

Something strange is happening to original thinking. Engineers who’ve never met each other are arriving at eerily similar ideas within days of each other. Everyone is using the same tools to “think” now, and those tools are shaping thought in ways we don’t fully appreciate. When millions of people ask similar questions to the same AI, they get similar answers, and over time those answers start to feel like original ideas. Our stack of $20/month subscriptions are quietly commoditizing thought itself.

What’s unsettling is how fast this happened and how few people noticed. Everyone is focused on capability gains, on shipping faster, on keeping up with the earthquake.

Meanwhile a convergence of thought occurred at an astonishing rate. And, depending on who is building + running the models, convergence of thought sits uncomfortably close to control of thought. That’s not a conspiracy theory, just an observation about what happens when a few providers shape how millions of people frame problems and generate solutions.

What gets suggested to users is what they’ll pick, right? That in and of itself is a source of bias. This happened to me recently:

Continue reading “What’s it doing? A convergence of thought.” →