The Architecture of Advice: Inside the AI High-Fidelity Loop

In the last post I looked at the sheer volume of AI-assisted engineering: 55,000 turns of professional capital recovered from a single month. But once you have the data, you stop asking “how much?” and start asking “what kind?”

So I ran a high-fidelity thematic enrichment pass over 466 sessions from the corpus and started mapping what I’m calling the architecture of advice: the hidden patterns that define how AI actually influences a multi-repo technical portfolio.

The five gravities

When you look at the technologies discussed across the month, the work clusters into five gravity wells. None alone dominates, but together they form the actual structure of the multi-repo portfolio:

Five gravities, in order of session frequency: workflow / version control, AI tooling, mobile (Swift / iOS), framework (Ruby / Rails), and infrastructure. The next two sections take the top finding (Git as workflow coach) and the framework finding (Rails as architectural anchor) in turn, because those are the two gravities that surprised me most.

The AI isn’t just a code generator across these gravities. It’s acting as architectural anchor for the Rails core, workflow coach at the Git layer, mobile collaborator in Swift, and AI-on-AI peer when I’m tuning local inference. Each gravity gets a different mode of collaboration. The conventions of each layer are doing real work in the AI’s reasoning, and the model has clearly absorbed them.

The workflow coach: Git and hygiene

Inside the Git/VCS cluster, the single tool that did the work was git itself. Of the 347 April sessions where the Vault captured a technologies_discussed field, git (the command, separate from GitHub or the CI surface) appeared in 169 of them: 48.7%. It’s the single most-mentioned technology in the corpus, ahead of Rails, Swift, Bash, and any individual AI tool.

The pattern is the surprise. I tend to think of AI as solving the hard problems. Its most consistent value across this month was enforcing the boring ones:

• “Switch to the develop branch.”
• “Stash or discard uncommitted changes before pulling.”
• “Run rails db:migrate for the database schema updates.”
• “Push the feature branch and open a PR; don’t merge into main directly.”

The AI has become the senior engineer who never forgets to check the branch before a push. A persistent, automated conscience for the messy reality of human development. I’m faster because I have a partner who pattern-matches me into hygiene I would otherwise skip when tired.

The recommendation-decision loop

Hundreds of specific recommendations surfaced in the corpus. What’s interesting isn’t just that the AI gives advice, it’s the granularity of that advice. In a single month, I saw the model shift fluidly from high-level infrastructure (“set up a background-job processing system”) to hyper-specific performance tuning (“set SIDEKIQ_CONCURRENCY=10 on Heroku”).

But advice is cheap. What matters is the conversion rate. By extracting decisions_made alongside recommendations, I can see exactly where the AI and I reached synthesis. In the best sessions, the model proposes a technical pivot (say, “tune the transcription prompt for handwritten letters”) and within 20 turns that recommendation becomes an architectural decision committed to the codebase. In the worst sessions, recommendations pile up untouched, and the session ends with more open threads than answers.

The knowledge boundary: what AI can’t answer

The true jagged frontier shows up in the open questions: sessions that ended without a decision. When I clustered them, they all shared a theme: context-rich strategy.

The AI can write the code to fix a bug, but it still struggles to evaluate the security risk of a complex PR holistically, or to define the emotional core of a user experience, or to root-cause a slowness whose answer requires deep familiarity with the production environment.

These gaps aren’t failures. They’re the interface points where human intuition is still the primary driver. At least until the model has read every line of my codebase, my support tickets, and my customer interviews. We’re not there yet.

The knowledge multiplier

The Librarian experiment changed how I think about AI as a tool. Less like a search engine, more like a knowledge multiplier.

It amplifies the ability to maintain a complex multi-repo portfolio by acting as anchor (the framework gravity), coach (the workflow hygiene), and tireless technical peer (the recommendation engine). By keeping the capital (the decisions, the recommendations, and the open questions) I’m not just building products. I’m building a high-fidelity knowledge graph of my own professional evolution.

When Anthropic announced “dreaming” for Managed Agents (agents that schedule reflection time between sessions to refine their own memory) they’re betting on the same intuition. The bet I’m making is that the version of this where you own the memory is the one that compounds for a builder.

The advice is good. The gravity is strong. The frontier is still wide open. The question is what you do with the capital, and where you keep it.