Category Archives: AI

Code Is Database

Indexes, not scans

This looks surprisingly like a database problem. A database doesn’t scan every record; it uses indexes to go straight to the data.

Agents mostly scan, and inside a repository that works well. Identifiers are precise keys, grep is fast, and nothing goes stale. Databases are similar: on a small table, the query planner picks a full scan because it is cheaper.

The plan changes across an API boundary. An SDK consumer often has no source to scan, and the knowledge it needs most (what to avoid, which default applies, what comes next) is often not in code at all. Thousands of consumers also pay for the same exploration again. Many reads, few writes: the classic case for an index.

If MCP starts to address this for applications, what is the equivalent for libraries and SDKs?

The missing read side

We already have one half of a database for code. Version control systems like Git are the write side: the source of truth that preserves history, integrity and distributed changes. But Git is optimized for writing and storing code, less for finding and using it.

Software architecture has a name for this split. CQRS (Command Query Responsibility Segregation) separates the write model, built for consistent changes and transactions, from the read model, built for fast queries. For code, the read side exists only in fragments: code indexes like Sourcegraph’s SCIP, Aider’s repo map, generated wikis like DeepWiki, documentation servers like Context7, llms.txt and AGENTS.md. Most of them are organized by code structure or by page, not by intent. Each solves part of the problem, and their growing number shows the need is real. What’s missing is a common model: a standard read model for agents.

The closest thing we have to a read side today is documentation, but it is built like a write model. Reference docs are essentially normalized: each fact lives in one place, organized by code structure and connected by cross-references. That works well for humans learning a system.

For an agent solving a task, it means expensive joins: the method on one page, the parameter type on another, the coordinate system somewhere else. Every join costs tokens and time.

Samples are the exception. A good sample is already denormalized, built around a task, with everything needed in one place. But samples usually cover only the happy path of the most common tasks. The long tail of the API, where an agent needs help most, is left to the reference docs.

So reference docs have the coverage but the wrong shape, and samples have the right shape but not the coverage. An agent-facing read model needs both: denormalized like a sample, organized by intent rather than by class hierarchy, and as complete as a reference.

A single entry might look like this:

intent       geocode parcel
description  returns the cadastral parcel containing a point
call         parcels.queryAt(lon, lat, crs)
verified     test_parcels_query_at · commit a1b2c3d · 2026-09-28
tolerance    exact point-in-polygon; p95 &lt; 40 ms; CRS: EPSG:4326, EPSG:5514
fails when   point on a shared boundary → returns first match only
crs          default EPSG:4326, degrees

One open question is who owns the vocabulary. An agent may ask for “point in parcel” when the entry says “geocode parcel”. The vocabulary could come from the library author, from a domain standard (for geospatial, OGC already names many spatial operations), or be learned from what agents actually ask for. Either way, intent isn’t an exact key, so this part of the read model behaves more like a search engine than a B-tree.

Materialized views

Denormalized data drifts. Databases fix this with materialized views, derived from the source and refreshed as it changes.

The agent layer should work the same way: generated from signatures, samples, docs and tests. An entry whose test fails goes stale. Entries can also grow from use: a successful agent scan becomes a candidate, kept only if it passes a test.

Producers write into the write model; consumers query the read model. Each role needs a different structure.

Producer agent writes to the write model (Git); on commit, a materialized read model indexed by intent is refreshed; consumer agent queries the read model.

Figure 1: Two roles, two models. The same agent can play both.

From software development to “Software Manufacturing Intelligence”

Engineers select parts from catalogs with precise specifications: dimensions, tolerances, materials. A capability read model is that catalog for software.

A catalog is only as good as its measurements. A part’s datasheet doesn’t describe what the part is meant to do; it states what it was measured to do (load, tolerance, operating range) and under which standard. A capability entry needs the same evidence: the test that proves the call works, the commit at which it last passed, the tolerances it holds (accuracy, latency, supported inputs), and the known ways it fails.

This is the metrology of software manufacturing. Producer agents can generate entries cheaply; what makes them trustworthy is that each one is measured, and re-measured on every commit.

A software factory might be very similar to a physical one. Before anything is manufactured, someone has to find out how. That happens in an R&D prototype workshop: the problem is explored, several hypotheses are tested in parallel as cheap prototypes, and a diagnostic loop refines them until one path is proven. Then operational software manufacturing actually starts.

Takeaway

In the workshop, agents scan, write and test. They are producers, and the write model serves them well. In manufacturing, agents assemble proven parts. They are consumers, and they need a catalog: what each part does, where it fits, when not to use it, and evidence that it still works. Today every agent rebuilds that catalog from scratch, for every task.

R&D explores, manufacturing assembles, metrology makes the assembly trustworthy. Git gave code its write model. Agents now need the read side.

AI Gambling Zones

AI Coding Agents and Team Knowledge Depreciation.

Leave a reply

AI coding agents are useful. However I keep wondering whether trade-off is limitation in knowledge flow inside teams. A team can become faster at producing output while becoming worse at building shared understanding. And that shared understanding depends not only on what the team knows, but also on the social fabric through which knowledge moves : trust, explanation, mentorship, disagreement, and shared ownership. If that weakens, the long-term cost may be larger than we think. I think of it as the risk of “team knowledge depreciation”: trading long-term learning and collective understanding for short-term gains in speed.

This is, in some sense, a more grounded follow-up to my earlier , over-excited post “Developer Twin”.

1. AI may optimize for local speed while weakening global understanding. A patch gets written faster, but fewer people understand why it exists, which trade-offs were made, and what it may affect elsewhere. Individual throughput and collective intelligence are not the same thing.

2. The biggest risk may not be code quality, but knowledge flow. Teams do not work only because individuals are smart. They work because knowledge moves between people and gets recombined into a shared view of the system.

3. A team does not need everyone to understand everything. But it does need a healthy way to reconstruct the whole together. That shared reconstruction may become weaker if too much work shifts from human-to-human exchange to human-to-AI interaction.

4. Documentation can serialize rules, but not fully transmit judgment. Skills, playbooks, prompts, and agent instructions can capture explicit knowledge. They do not fully capture the painful experience from which engineering judgment is formed.

5. Mentoring a person compounds. Steering an AI often does not. When you invest in a junior engineer, the team may get that investment back over time. With current AI systems, much of that effort is spent in the moment.

6. Faster delivery can hide a weakening learning culture. A team may ship more while learning less. Over time, that can turn into a quiet form of knowledge capital depreciation: accumulated expertise is consumed faster than it is renewed. The deeper question is what kinds of team behavior AI quietly rewards, and what kinds it replaces.

7. The real challenge is not just building faster systems, but preserving the human mechanisms that make learning possible. Speed matters. But so do explanation, mentorship, disagreement, review, and shared ownership.