David Fant’s framing, amplified by Alex Lieberman: “Coding w AI is solved bc all context is in the git repo. Knowledge work is difficult bc context is spread out.”
This reframes why engineering leads AI adoption: it’s not because engineers are smarter or models are trained on code — it’s because engineering has a solved context centralization problem (git). Knowledge work’s context is distributed across “Granola, Notion, Hubspot, ERP, emails, Slack, random spreadsheets, SOP docs.”
Lieberman identifies three axes where knowledge work fails compared to code:
- Distributed — context scattered across tools with no unified repository
- Unstructured — no schema, no types, no consistent format
- Unverifiable — “What is a good/bad idea? Is the content in your voice or not? Does it feel like slop or novel?” No unit test equivalent.
His claim that “building an ingestion engine… is the first, and frankly, easiest step” is notable — the hard middle is self-organizing schema (“whether it’s a thoughtful filesystem à la Obsidian or an OpenClaw-esque memory structure”). At scale, “compaction and cleaning become wildly important to avoid the needle in the haystack problem.”
Ivan Zhao names the same gap from the org side: in knowledge work “humans are the glue, stitching all that together with copy-paste and switching between browser tabs,” and code’s edge is that “you can verify it with tests and errors” while a strategy memo has no such check. His prescription is the structural flip — AI is steel for organizations — when software carries the context, human communication stops being the load-bearing wall: once software carries the context, human communication stops being the load-bearing wall that caps org scale.
Connects to Context is the product, not the model — whoever centralizes domain context wins. Also connects to Files are the universal interface between humans and agents — the file system IS the context centralization mechanism for engineering AI tools.