My Projects Started Leaning on Each Other

Oct 7, 2026 · 8 min read

i noticed a habit the other night. more and more, when i start something new, one of the first things i tell an agent is some version of “go look at how that other project does this and bring it over here.” the ridgeline and tree-cover horizons in Blue Ridge Skyline came out of TALON’s terrain work. the fog work in my GOES-19 ground station leaned on Blue Ridge Skyline. RepoAudit and PRISM ended up with almost the same LLM provider layer. it’s fast, and that’s the whole appeal: an agent can lift a module from one repo into another in a couple of minutes, and i get to skip straight to the part i actually care about.

and somewhere along the way it started to feel like everything was growing toward a central point. two of them, really.

what it felt like

the first one is code that looks at code. RepoAudit reads a repository and reports on security, architecture, docs, and how much AI is actually in it. PRISM watches running software and sorts problems into modules. there’s the agent-orchestration starter kit i’ve been building, and there’s a tool that reads my git history and writes me a digest of what i actually worked on. i feel like if i standardize what these produce and plug it into the kit, the pieces stop being four tools and turn into one thing: audit a repo, turn the findings into tasks, let agents work the tasks, keep watching, and report what changed.

the second one is land and sky, and TALON is the center of it. TALON was the heavy lift: fourteen western NC counties, 1m lidar, parcels, soils, hydrography, terrain metrics for every parcel. it took a long time and it was painful in the way first real full-stack projects are painful. but now that data exists, and i know what it can do, things that build on it come together in a fraction of the time. Blue Ridge Skyline went from an idea to a tool i’ve used in the field on real nights pretty quickly, the fog work came together fast too, and so did the satellite dish siting demo, which checks whether a GOES-19 dish on a given spot clears the terrain and trees.

so that was the feeling. but a feeling about your own codebase is just a feeling, and i spend my days as a QA engineer, so i wanted to check it.

so i sent agents to look

two read-only agents, one per cluster. each one got the list of repos and the same questions: what code has been copied from one repo into another, and has it drifted since? does any project read another project’s files or data? are there constants (regions, spot lists, physical values) defined in more than one place, and do they still agree? each wrote a full report with file and line references and came back with a short summary. the code cluster took about three minutes and the land and sky cluster took about four.

what they found was more interesting than what i expected, because the two clusters were wrong in opposite directions.

the code cluster was less connected than it felt

none of these projects imports another one, calls another one, or reads another one’s output. not one. everything that crosses between them is either a copy or a plan.

the copy that matters is the starter kit. the digest tool has an older copy of the kit in it, and the kit has moved on since then: one of the verification scripts is 159 lines in the old copy and 292 in the current one. the digest tool also grew a few scripts of its own that the kit doesn’t have. nobody made a mistake here. i copied the kit in, kept working on both, and they drifted apart.

the RepoAudit and PRISM connection turned out to be a migration plan from back in april, not code. the plan noted that i had built nearly the same LLM provider and token tracking design twice, in parallel, without porting anything (i genuinely didn’t remember doing that). it also pointed out something i hadn’t thought about at all: the two projects have different licenses, one noncommercial and one MIT, which has to get sorted out before any code moves between them.

so “intertwined” was mostly in my head and in my planning docs. the repos themselves barely know about each other.

the land and sky cluster was more connected than it looked

this one went the other way. Blue Ridge Skyline and the GOES-19 project both read TALON’s elevation tiles directly off the drive, and the little bit of math that turns a coordinate into a tile filename exists three times, once in each project. every Blue Ridge Skyline build runs on TALON’s python environment, which i had honestly forgotten about, and forgetting is exactly the problem.

then the constants. both Blue Ridge Skyline and the fog work trace sightlines across the terrain, and both apply a correction for how the atmosphere bends light over long distances. one uses 0.143 for that correction and the other uses 0.13. it’s a small difference, but it means the two tools can disagree about whether a far ridge blocks a view. the overlook lists don’t match either: the same named spots sit anywhere from about 100 meters to a full kilometer apart between the two projects, and Graveyard Fields is the one that’s a kilometer off. Blue Ridge Skyline’s list is the checked one. the fog spots went in as rough placeholders, and they’ll pick up the real locations as that work moves along. the region itself is written down seven times as a bounding box, with five different values, and some of them put longitude first while others put latitude first.

the dish siting work had its own version of this. its plan borrows the satellite look-angle code from Blue Ridge Skyline, but that code lives in a folder git ignores, so the original isn’t versioned anywhere. if i’d lost that folder, the copy would have been the only one left.

none of it is broken today. everything that reads the elevation tiles agrees right now. that’s sort of the uncomfortable part, though, because it agrees mostly by luck, and the first time i move those tiles or upgrade a package in TALON, two other projects break quietly.

why this happens with agents

copying used to be annoying enough that around the second time you’d stop and think “ok, should this live somewhere shared?” that friction was doing real work. with an agent it costs nothing, so you never hit it, and every single copy is a reasonable call on its own. the agent porting a module into Blue Ridge Skyline doesn’t know there are two other copies of it, it only sees the repo it’s working in. the drift isn’t one bad decision, it’s a lot of small decisions that were each fine.

the flip side is that the same kind of agent found all of this in under five minutes, which is not something i would have sat down and done by hand. i’m fine with that trade as long as i actually do the checking.

what i’m going to do about it

the rule i’m going with is simple. the first time a project needs something from another one, copying is fine. the second time, i make a note of it. the third time, it moves into the project that owns it, and everything else reads it from there.

by that rule, the tile math is already overdue. for land and sky, that means making TALON the owner on purpose instead of by accident. first a small module for the elevation tiles, so the filename math and the location live in one place. then one sightline function with one refraction value. TALON already had a parked plan for a visibility service that listed Blue Ridge Skyline’s satellite sightline as a preset, so i had apparently written this down a while ago and then went off and built it twice anyway. then one module for the region and the overlooks, using the checked spot list. after that, Blue Ridge Skyline gets its own python environment.

for the code cluster, the report pointed at three things worth standardizing: what identifies a repo, a snapshot (a specific commit plus a timestamp, so audit scores can line up with what i was working on that week), and what a finding looks like (severity, location, evidence, fix). but i’m not starting there. the digest tool is the first real consumer of any of this, and i’d rather finish it and let a working consumer tell me what the format actually needs than design it up front and get it wrong. the kit stays parked until the digest ships.

the feeling was right about which way things were heading. it was wrong about the details, in opposite directions for the two clusters, and checking took less time than writing this up. we’ll see how the third-copy rule holds up once i’m in the middle of building something and just want the thing from the other repo.