Notes from the team on semantic call graphs, merge conflict architecture, provenance integrity, and what the record of software has to become when most of the code is written by something that isn't you.
Git's data model is an ancestry graph: strict, sequential, single-lineage. Great for human edits and reviews. Atomic's is a causal graph plus patch theory, which produces concurrency without coordination and provenance that's a structural property of the graph. Great for agent native source code management where context is critical.
Read the piece→Prompt engineering, then context engineering, then loop engineering. Each shift fixed something real, yet none answered the question that actually matters: how do you know an agent did what it was asked to do? Orchestration wrapped around probabilistic guesses isn't an execution model. What's missing is a proof model.
Read the piece→Before an AI coding agent can complete a task, it has to find the relevant code. In every standard agent today, that means grep, ripgrep, find, or directory listing followed by file reads, burning context before reasoning begins. The problem isn't the search tool. The problem is that the repository has no structural understanding of itself.
Read the piece→Git, the incumbent with 94 percent market share, was designed in 2005 for human developers editing text files. Two decades later, AI agents generate 41 to 46 percent of all new code, and one in four AI-generated pull requests produces merge conflicts that Git's line-level architecture cannot resolve without human intervention.
Read the piece→Long-form engineering and research: semantic indexing, merge conflict architecture, and provenance you can verify. No marketing, no recap threads.