Incremental Computation

Incremental Computation · djuleayo https://316c0611.personalpage-ahl.pages.dev/tags/incremental-computation/ Hugo en You Should Not Outsource Your Topological Sort https://316c0611.personalpage-ahl.pages.dev/posts/topo-sort-ownership/ https://316c0611.personalpage-ahl.pages.dev/posts/topo-sort-ownership/ Sat, 20 Dec 2025 11:13:48 +0200 <h1 id="you-should-not-outsource-your-topological-sort"> You Should Not Outsource Your Topological Sort <a class="heading-link" href="#you-should-not-outsource-your-topological-sort"> Link to heading </a> </h1> Things are shifting quickly in software. Execution is no longer scarce. Parallelism is cheap. Spawning workers—human or AI—is trivial. What is no longer cheap is coherence: understanding what depends on what, and in which order work can safely progress. In that world, seniority is not about knowing frameworks or tooling. It is about owning structure. One structure, in particular, keeps reappearing. <hr> <h2 id="the-invariant-we-keep-outsourcing"> The invariant we keep outsourcing <a class="heading-link" href="#the-invariant-we-keep-outsourcing"> Link to heading </a> </h2> Topological sort sounds boring. Dependency graphs. Build order. Module resolution. For years, we happily outsourced this problem: <ul> <li>to module loaders</li> <li>to dependency injectors</li> <li>to build systems</li> <li>to frameworks</li> </ul> And that was fine—when execution itself was the bottleneck. But once you start orchestrating: <ul> <li>multiple worktrees</li> <li>multiple agents</li> <li>partially overlapping tasks</li> <li>incremental pipelines</li> </ul> …the dependency graph stops being an implementation detail. It becomes the control surface. <hr> <h2 id="what-breaks-when-you-dont-own-it"> What breaks when you don’t own it <a class="heading-link" href="#what-breaks-when-you-dont-own-it"> Link to heading </a> </h2> If the dependency graph lives outside your system, you lose more than convenience: <ul> <li>You can’t checkpoint progress meaningfully</li> <li>You can’t resume work without recomputation</li> <li>You can’t branch execution deterministically</li> <li>You can’t define clean contract boundaries between concurrent actors</li> </ul> You’re forced to “start over” more often than necessary—not because the work changed, but because you don’t know where you are in the graph. This shows up everywhere: <ul> <li>painful monorepo setups</li> <li>slow feedback loops</li> <li>brittle automation</li> <li>orchestration that feels magical instead of mechanical</li> </ul> These are not tooling problems. They are graph ownership problems. <hr> <h2 id="a-concrete-example-sessions-as-graph-cursors"> A concrete example: sessions as graph cursors <a class="heading-link" href="#a-concrete-example-sessions-as-graph-cursors"> Link to heading </a> </h2> Imagine a single source of truth: code, data, or input. You process it in stages: <ul> <li>tokenization</li> <li>preprocessing</li> <li>parsing</li> <li>semantic analysis</li> <li>domain-specific passes</li> </ul> Different consumers need different depths. But you do not want to reprocess from scratch every time. What you actually want is simple: <ul> <li>recognize how far the source has been processed</li> <li>continue minimally from there</li> <li>reuse everything that is already valid</li> </ul> That is not a caching trick. That is a cursor moving through a DAG. Call it a session. Call it an account. The name doesn’t matter. What matters is this: <blockquote> once you own the dependency graph, incremental progress becomes trivial.</blockquote> Without it, you fake it. <hr> <h2 id="why-this-matters-more-now"> Why this matters more now <a class="heading-link" href="#why-this-matters-more-now"> Link to heading </a> </h2> With AI agents, automation, and parallel execution: <ul> <li>execution is abundant</li> <li>retries are cheap</li> <li>recomputation is wasteful</li> </ul> The limiting factor is no longer doing work. It is placing work correctly. If you outsource topological reasoning, you: <ul> <li>lose observability</li> <li>lose control</li> <li>lose leverage</li> </ul> And no amount of tooling on top can recover that. <hr> <h2 id="the-real-claim"> The real claim <a class="heading-link" href="#the-real-claim"> Link to heading </a> </h2> This is not about implementing topological sort yourself for sport. It is about this: <blockquote> You should not outsource the authority over your dependency graph.</blockquote> Once you own it: <ul> <li>session management becomes natural</li> <li>incremental computation falls out</li> <li>agent contracts become explicit</li> <li>orchestration becomes deterministic instead of heuristic</li> </ul> Once you don’t: <ul> <li>everything becomes “best effort”</li> <li>progress becomes opaque</li> <li>automation becomes fragile</li> </ul> <hr> <h2 id="closing"> Closing <a class="heading-link" href="#closing"> Link to heading </a> </h2> Topological sort is not an algorithm problem anymore. It is a design boundary. Outsource it, and you outsource understanding. Own it, and higher-level abstractions finally become possible. That choice matters more now than it ever did. <h1 id="you-should-not-outsource-your-topological-sort"> You Should Not Outsource Your Topological Sort <a class="heading-link" href="#you-should-not-outsource-your-topological-sort"> Link to heading </a> </h1> Things are shifting quickly in software. Execution is no longer scarce. Parallelism is cheap. Spawning workers—human or AI—is trivial. What is no longer cheap is coherence: understanding what depends on what, and in which order work can safely progress. In that world, seniority is not about knowing frameworks or tooling. It is about owning structure. One structure, in particular, keeps reappearing. <hr> <h2 id="the-invariant-we-keep-outsourcing"> The invariant we keep outsourcing <a class="heading-link" href="#the-invariant-we-keep-outsourcing"> Link to heading </a> </h2> Topological sort sounds boring. Dependency graphs. Build order. Module resolution. For years, we happily outsourced this problem: <ul> <li>to module loaders</li> <li>to dependency injectors</li> <li>to build systems</li> <li>to frameworks</li> </ul> And that was fine—when execution itself was the bottleneck. But once you start orchestrating: <ul> <li>multiple worktrees</li> <li>multiple agents</li> <li>partially overlapping tasks</li> <li>incremental pipelines</li> </ul> …the dependency graph stops being an implementation detail. It becomes the control surface. <hr> <h2 id="what-breaks-when-you-dont-own-it"> What breaks when you don’t own it <a class="heading-link" href="#what-breaks-when-you-dont-own-it"> Link to heading </a> </h2> If the dependency graph lives outside your system, you lose more than convenience: <ul> <li>You can’t checkpoint progress meaningfully</li> <li>You can’t resume work without recomputation</li> <li>You can’t branch execution deterministically</li> <li>You can’t define clean contract boundaries between concurrent actors</li> </ul> You’re forced to “start over” more often than necessary—not because the work changed, but because you don’t know where you are in the graph. This shows up everywhere: <ul> <li>painful monorepo setups</li> <li>slow feedback loops</li> <li>brittle automation</li> <li>orchestration that feels magical instead of mechanical</li> </ul> These are not tooling problems. They are graph ownership problems. <hr> <h2 id="a-concrete-example-sessions-as-graph-cursors"> A concrete example: sessions as graph cursors <a class="heading-link" href="#a-concrete-example-sessions-as-graph-cursors"> Link to heading </a> </h2> Imagine a single source of truth: code, data, or input. You process it in stages: <ul> <li>tokenization</li> <li>preprocessing</li> <li>parsing</li> <li>semantic analysis</li> <li>domain-specific passes</li> </ul> Different consumers need different depths. But you do not want to reprocess from scratch every time. What you actually want is simple: <ul> <li>recognize how far the source has been processed</li> <li>continue minimally from there</li> <li>reuse everything that is already valid</li> </ul> That is not a caching trick. That is a cursor moving through a DAG. Call it a session. Call it an account. The name doesn’t matter. What matters is this: <blockquote> once you own the dependency graph, incremental progress becomes trivial.</blockquote> Without it, you fake it. <hr> <h2 id="why-this-matters-more-now"> Why this matters more now <a class="heading-link" href="#why-this-matters-more-now"> Link to heading </a> </h2> With AI agents, automation, and parallel execution: <ul> <li>execution is abundant</li> <li>retries are cheap</li> <li>recomputation is wasteful</li> </ul> The limiting factor is no longer doing work. It is placing work correctly. If you outsource topological reasoning, you: <ul> <li>lose observability</li> <li>lose control</li> <li>lose leverage</li> </ul> And no amount of tooling on top can recover that. <hr> <h2 id="the-real-claim"> The real claim <a class="heading-link" href="#the-real-claim"> Link to heading </a> </h2> This is not about implementing topological sort yourself for sport. It is about this: <blockquote> You should not outsource the authority over your dependency graph.</blockquote> Once you own it: <ul> <li>session management becomes natural</li> <li>incremental computation falls out</li> <li>agent contracts become explicit</li> <li>orchestration becomes deterministic instead of heuristic</li> </ul> Once you don’t: <ul> <li>everything becomes “best effort”</li> <li>progress becomes opaque</li> <li>automation becomes fragile</li> </ul> <hr> <h2 id="closing"> Closing <a class="heading-link" href="#closing"> Link to heading </a> </h2> Topological sort is not an algorithm problem anymore. It is a design boundary. Outsource it, and you outsource understanding. Own it, and higher-level abstractions finally become possible. That choice matters more now than it ever did.