Over the past several weeks, I kept seeing something unusual in my GitHub followers. Not one suspicious account. Not even one suspicious batch. Repeated waves of accounts would appear with remarkably similar characteristics: dozens of newly generated repositories thousands of outbound follows rapidly increasing follower counts similar repository structures similar commit histories synchronized changes in account behavior Any one of those characteristics can have a mundane explanation. Together, they were worth measuring. So instead of trying to decide whether the accounts “looked fake,” I started treating the activity as an evidence problem. The result became CF-GH-FOLLOW-02, a public-only longitudinal investigation into what increasingly appears to be a repeatable GitHub account-development workflow. This post documents what I can establish from public evidence, what I can reasonably infer, and—equally important—what I cannot prove. ⸻ The first rule: don’t investigate the person The objective was never to identify whoever might be behind these accounts. That distinction matters. A GitHub username, commit author name, email address, profile picture, company field, or location is not automatically a verified identity. The investigation therefore separates four different things: Observation — what the public evidence directly shows. Inference — what explanation best fits those observations. Campaign/workflow linkage — whether separate accounts appear to participate in the same technical process. Real-person attribution — who actually operates that process. The first three can sometimes be investigated from public evidence. The fourth remains unresolved here. ⸻ August 26: five accounts arrive The investigation began with five accounts: alberto4442 lxl0825 fuad403273 hassenbrahim Belucking At collection time, they each exposed approximately 59–60 public repositories. Their outbound-following counts were already enormous: Account Following Public repos alberto4442 7,380 60 lxl0825 7,380 59 fuad403273 7,381 60 hassenbrahim 7,381 60 Belucking 7,695 60 The repository portfolios were even more interesting. Across the five accounts there were 299 repositories, with essentially the entire visible portfolio generated inside a narrow window. Median intervals between repository creation events were roughly 340–346 seconds. Three accounts had identical programming-language sequences across all 59 comparable repository positions. The first 100 accounts followed by all five were also identical. For all ten account pairs: Jaccard similarity = 1.000 That was enough to reject the idea that I was simply looking at five unrelated developers who happened to follow me around the same time. But it still wasn’t the strongest evidence. ⸻ The artifact that connected the accounts I sampled repository histories from each account. Every sampled history contained the same commit trailer: Co-authored-by: nancodero nancodero@proton.me The repositories also repeatedly used the same merge grammar: Merged PR #1 Automatically merged pull request #1 And the same pull-request structure: Initial Setup and Codebase for with bodies following the pattern: This PR contains the initial setup, code implementation, and configuration for . That is much more useful than profile similarity. Profiles are easy to copy. Commit-history artifacts describe how repositories were actually produced. Then the templates started leaking information across account boundaries. Sampled READMEs belonging to different owners contained hard-coded references to another cohort account. Later generations produced similar leakage involving unrelated displayed personas and author identities. This strongly suggested that the visible profiles and the repository-generation process were separate layers. ⸻ Then an older investigation suddenly became relevant The nancodero trailer was not new. A previous August 9–10 follower wave had already exposed six repository owners associated with the same artifact: RashidSaeedAlMazrouei18 ElvinHasanov3d badiranssen Seo-yeonLee KevinWong455 9Michael-Cooley Those accounts had originally appeared during another unusual follower burst. Their repository histories contained the same: nancodero nancodero@proton.me artifact. That changed the unit of analysis. The August 26 accounts were no longer just one strange five-account cluster. They were another generation of a workflow already observed weeks earlier. ⸻ Four older accounts disappeared When I returned to the six earlier accounts on August 27, four returned HTTP 404: Account State Followers Following Repos ElvinHasanov3d 404 — — — Seo-yeonLee Live 1,024 899 51 KevinWong455 404 — — — 9Michael-Cooley Live 1,021 893 53 RashidSaeedAlMazrouei18 404 — — — badiranssen 404 — — — A 404 does not tell me why an account disappeared. Deletion, suspension, rename, or another visibility change can produce similar observations. So I recorded exactly what the evidence established: Four previously observed usernames no longer resolved publicly. Nothing more. But the two surviving accounts had converged on another interesting state: roughly 1,020 followers, 895 following, and 51–53 repositories. That looked very different from the newer accounts with thousands of outbound follows. It suggested a possible lifecycle. At the time, however, I did not have same-account longitudinal evidence proving that transition. So the lifecycle remained a hypothesis. ⸻ Then the August 26 accounts changed Eventually, the same five accounts gave me the longitudinal evidence I was missing. All five underwent a major outbound contraction after previously occupying the roughly 7,400–7,800-following range, dropping into approximately 1,329–1,423 following. Their repository inventories remained essentially unchanged. That was important. The accounts had not simply vanished. Their social graphs had changed dramatically while their generated portfolios remained in place. One account gave an especially useful measurement. For alberto4442, I was able to completely enumerate its public graph after pruning: Following: 1,417 Followers: 1,556 Reciprocal: 1,413 That means: 1,413 / 1,417 = 99.7177% or approximately: 99.72% of the accounts it still followed also followed it back. That does not prove the pruning algorithm. I do not have a complete frozen copy of its pre-pruning following set, so I cannot identify exactly which relationships were removed. But it creates a strong testable hypothesis: The contraction may preferentially preserve reciprocal relationships. That is much stronger than simply saying the account “looks like a follow-for-follow account.” It gives us something measurable. ⸻ Another generation appeared A later generation contained 14 additional owners, including: sannejanhvb niransukdev mhassanqjlh ahmedbouugm mhassanxglx mbauerheabz jsmithtikie sullivanolivia minjukimdev jansensanne kwameagyeham erikjohygkl ananyasukhumvit anabauzttnd These accounts again exposed the exact nancodero artifact. Their repositories used the same merge grammar. Their generated projects again followed recognizable skeletons. And repository operations were interleaved between owners rather than completing one account at a time. That matters. A simple process like: generate account A finish account A generate account B finish account B does not fit the observed chronology particularly well. The public history instead looked more like a scheduler or parallelized generation process multiplexing work across several owner namespaces. Again, that is a workflow inference. It is not operator attribution. ⸻ August 28 gave us a particularly useful generation Five more accounts appeared: irenascent vinamega RobbyDwk nahladzulula cahcacah They exposed 60–61 repositories each. Their repository histories again contained: Merged PR #1 Automatically merged pull request #1 Co-authored-by: nancodero nancodero@proton.me The generation also showed interleaved repository naming rounds involving projects such as: Yarn* Zen* Zephyr* distributed across multiple owners. Several representative immutable commit objects remain publicly accessible: irenascent/ZephyrYarn 9404ead160e4f2434656d9f08e237780941be9f8 vinamega/ZephyrState 09d7f0d586e0afb66f0bf089a841a18361b5ad1f RobbyDwk/ZephyrRift 6a01a7c5bff62c03e395f757ebf8ba1de4275f35 nahladzulula/ZephyrQuill c66dfd255a812f1cf4d8c5a3378aa1f6a6c7667b cahcacah/ZephyrIris 492860a52c17bb7547993ba89a1e714877c741dd These are useful because the evidence does not depend entirely on mutable profile pages. The commit objects preserve the shared generation artifact. ⸻ Their social graphs then accelerated Initially, these five accounts had very few followers: Account Followers Following Repos irenascent 17 843 61 vinamega 17 799 60 RobbyDwk 17 799 60 nahladzulula 16 637 60 cahcacah 18 843 60 Their repositories were already populated. Then their outbound-following counts expanded toward approximately 7,700. Follower counts climbed by hundreds. The repositories stayed fixed. That sequence is important: repository generation ↓ portfolio reaches target state ↓ large outbound-follow expansion ↓ follower acquisition The repository-building phase appears to precede the major social-growth phase. ⸻ Then all five followed me Immediately before this event, my public follower set contained 110 accounts. At the next collection it contained 115. The five additions were exactly: irenascent vinamega RobbyDwk nahladzulula cahcacah No interpretation of GitHub’s endpoint ordering was required. This was a set difference: previous follower set vs. new follower set Five additions. Five technically linked accounts. The entire generation entered together. That provides a useful clue about my position in this system. The workflow was already underway before these accounts followed me. Their repositories existed. Their generation artifacts existed. Their social acquisition had already started. So the evidence does not currently suggest that I am the origin of this activity. A more conservative explanation is that my account exists somewhere inside a reusable target population. Why it is there remains unknown. ⸻ Six more accounts repeated the sequence Another generation followed: emilybarru lgomesappj minseochoj harutosati whitakeroliver amurrayeqc Initially, they exposed only around 11–12 public repositories each. Then something unusually clean happened. Every account gained exactly 67 public repositories. The final inventories became: 79 79 79 79 78 78 Across those owners, I recovered 466 exact-trailer merge commits across 466 repositories. The repositories again used the same nancodero artifact. Then the social phase began. The six accounts moved to roughly: ~613–627 followers ~7,600 following 78–79 repositories while their repository inventories remained stable. And then my follower set changed again. A complete public enumeration moved from: 111 followers to: 117 followers The six additions were exactly those six accounts. Again: repository generation ↓ social acquisition ↓ coordinated entry into my follower set At this point, the repeated timing was becoming much harder to explain as independent organic behavior. ⸻ The newest generation made the workflow even clearer On September 4, another group surfaced: tmokoenassz lschmidtday carlosgarjd akhalifazar canilmazdev elghazikhalid amanioumaaa denizkayadev rahulkumfqs srisawatanan htanakaazwp minhokingkim emilywrightdev Thirteen accounts. Twelve exposed 17 repositories. One exposed 16. Owner-scoped searches recovered: 219 exact-trailer merge commits across 219 repositories. The observed production window ran from approximately: 2026-09-04 13:57:27 UTC through: 2026-09-04 18:02:54 UTC Every recovered merge used the familiar structure: Merged PR #1 Automatically merged pull request #1 Co-authored-by: nancodero nancodero@proton.me The repositories were again produced across multiple owner namespaces during the same bounded period. ⸻ The identity leakage continued too Some of these accounts display one persona while their repository histories expose another hard-coded identity. For example, one profile displays: Anna while sampled repository history contains: thabomokoena@lazato.fun Other commits across the workflow have used addresses under: lazato.space lazato.fun These mismatches are valuable technical artifacts because they suggest that profile presentation and repository-generation identity are not consistently bound together. They are not evidence that any displayed name, email identity, or domain identifies the real operator. That distinction remains critical. ⸻ Then the generations connected through the social graph The newest accounts provided one of the strongest cross-generation observations so far. I successfully collected follower sets for eight of the new owners. Every one contained all five members of the August 28 generation: irenascent vinamega RobbyDwk nahladzulula cahcacah Seven reciprocal following sets were also recovered. Four new owners had the exact same six-account following set: irenascent vinamega RobbyDwk nahladzulula cahcacah aibers That is more informative than finding generic high-degree follow-back hubs in multiple graphs. The five August 28 accounts had already been independently connected to the repository-generation workflow through Git artifacts before this social-graph relationship was examined. Now an older technically linked generation appears directly inside the initial social graph of a newer technically linked generation. That creates a cross-generation bridge using two different evidence classes: Git history + social graph Neither depends on the other. ⸻ A lifecycle is emerging Across the generations, the observations increasingly fit the following sequence: account creation ↓ automated/interleaved repository generation ↓ repository inventory reaches a target state ↓ older workflow accounts seed newer accounts' social graph ↓ large outbound-follow expansion ↓ hundreds or thousands of followers accumulate ↓ GnomeMan4201 is followed during the acquisition phase ↓ large-scale following-list pruning Not every generation is currently at the same stage. That is important. A newly generated account should not be expected to already have 7,000 following or 1,500 followers. Lifecycle-stage differences should not be confused with evidence against linkage. The strongest linkage comes from higher-order technical artifacts such as the exact commit trailer, merge grammar, repository-generation morphology, interleaved chronology, template leakage, and cross-generation graph structure. ⸻ What I think the evidence supports At this point I assess the following with high confidence: Multiple account generations participate in a common or closely related automated repository-generation and reputation-acquisition workflow. I also assess with high confidence that: Mass following and reciprocal relationships materially contribute to the social growth observed in at least some of these accounts. The alberto4442 measurement is particularly strong: 1,413 reciprocal relationships out of 1,417 accounts followed or: 99.72% after the major pruning event. The evidence also increasingly supports a phased lifecycle rather than a static account template. What changes between generations can be as informative as what stays the same. ⸻ What the evidence does not support There are several conclusions I am deliberately not making. I cannot establish that one human controls every account. I cannot establish that nancodero is the operator. I cannot establish that identities appearing under lazato.space or lazato.fun correspond to the operator. I cannot determine why four earlier usernames now return 404. I cannot establish the exact algorithm responsible for pruning. I cannot establish the exact timestamp at which every account followed me because GitHub does not publicly expose follow-event timestamps. And I cannot establish that my account is being individually targeted. The current evidence fits something less dramatic and more operationally plausible: My GitHub account appears to be a recurring member of a target population consumed by successive account-growth generations. Why remains an open question. ⸻ Why the longitudinal evidence matters A screenshot can show that five accounts look similar. That is weak evidence by itself. A repository can show that two accounts use similar code. Also weak by itself. A high-degree follow-back account appearing in multiple follower sets is weak because such accounts naturally create enormous overlap. The case becomes more interesting when independent evidence classes begin converging: shared immutable Git artifacts + shared repository morphology + interleaved generation chronology + cross-account template leakage + synchronized repository counts + synchronized social acquisition + cross-generation graph seeding + coordinated entry into the same target follower set + same-account longitudinal pruning The individual observations are not equally strong. Their intersection is what matters. ⸻ The next experiment The strongest next test is straightforward. Before another mature account undergoes pruning, freeze its complete public follower and following sets. Record: GitHub numeric account ID login collection timestamp followers following complete follower IDs complete following IDs repository inventory Then wait for the contraction. Afterward, collect the same graph again. That would let me divide the original following set into: retained relationships removed relationships and directly test whether reciprocal relationships are disproportionately retained. If they are, the current 99.72% observation moves from a strong post-event clue toward direct behavioral evidence of the pruning mechanism. If they are not, the hypothesis gets weakened. Either result is useful. ⸻ Closing This investigation started because several GitHub followers looked unusually similar. That observation alone would not have justified much. The useful part came from refusing to stop at appearance. Freeze the baseline. Record the account IDs. Preserve the repositories. Compare the graphs. Follow the immutable artifacts. Keep negative results. Treat disappearing accounts as unresolved rather than inventing explanations. Separate technical linkage from human attribution. And wait for the system to change. Once you have longitudinal evidence, what initially looked like a collection of strange profiles starts becoming something much more measurable: a repeatable workflow. That is the part I am interested in documenting.