AI ENGINEERING · 8 MIN READ · SEPTEMBER 05, 2026

Your AI Agent Doesn't Know What Year It Is: A 24-Hour Census of 34,187 Repositories

I analyzed 171,796 dependencies across all 34,187 repositories created on September 4, 2026. Here is why your AI coding agent does not know what year it is, and why only strict compilers survived.

StackHal Field NotesUpdated September 05, 2026

On September 4, 2026, I conducted an exhaustive global census of every repository created across eight major programming ecosystems. Slicing the entire 24-hour UTC day down to 30-minute micro-intervals, I captured and cataloged all 34,187 newly created repositories. Out of these, 25,322 contained formal build manifests comprising 171,796 declared dependencies, while 8,865 were manifest-less standalone scripts and notes. The empirical data reveals a universal software supply chain hazard: because AI coding agents rely on parametric training memory rather than probing host environments, they systematically anchor greenfield software to outdated runtimes, deprecated packages, and superseded architectural generations.

The Cutoff Anchor Law In unconstrained repository scaffolding, the probability of a codebase targeting an End-of-Life (EOL) runtime or deprecated dependency is inversely proportional to compiler friction at build time, and directly proportional to historical token frequency in the model training corpus.

The 34,187 Repository Census Funnel

To establish clean empirical baselines, my ingestion pipeline accounted for every single repository created on September 4, 2026 across eight ecosystems:

  • Total Global Repositories Created: 34,187 repositories across TypeScript, Python, JavaScript, Java, C#, Rust, Go, and PHP.
  • Repositories with Declared Build Manifests: 25,322 repositories (74.1%).
  • Manifest-less Repositories: 8,865 repositories (25.9%) consisting of lone .py scripts, single-file JavaScript snippets, and exploratory notebooks.
  • Total Dependencies Analyzed Against Live Registries: 171,796 dependencies.
  • Repositories Targeting EOL Runtimes: 2,345 repositories (6.9% across all languages, but concentrated heavily in Go at 50.6% and PHP at 12.2%).
  • Repositories Shipping with Deprecated / Vulnerable Packages: 1,981 repositories (7.8% of manifest-bearing codebases), containing 2,187 flagged package instances.
Terminal capture of live SQLite census query across 34,187 repositories
Figure 1: Live terminal execution querying the census database across all 34,187 repositories and 171,796 evaluated package dependencies.
Cross-Ecosystem Dependency Age and Vulnerability Comparison
Figure 2: Cross-ecosystem comparison of median package age on day zero and percentage of repositories born with EOL runtimes or deprecated packages.

1. Declarative Toolchains vs Silent EOL: Go and PHP

In ecosystems where runtime versions are declared as simple configuration strings, models exhibit massive temporal drag because these constraints do not trigger compile-time errors during generation.

The Go Compiler Anomaly

In Go, toolchain constraints are declared plainly in go.mod. The Go project strictly maintains only the two most recent major releases (Go 1.26 and Go 1.27; Go 1.25 reached official End of Life on August 19, 2026).

Terminal capture of Go compiler EOL directives in new repositories
Figure 3: Live terminal capture verifying EOL compiler targets in go.mod files initialized on September 4, 2026, checked against Go's official release support policy.

Across all 575 Go repositories created yesterday:

  • 291 out of 575 repositories (50.6%) explicitly targeted an EOL Go compiler version.
  • 134 repositories pinned Go 1.25 (expired August 2026).
  • 59 repositories pinned Go 1.24 (expired early 2026).
  • 47 repositories pinned Go 1.22 (expired early 2025).
  • 51 repositories pinned Go 1.23 or ancient versions down to Go 1.14.
  • Only 283 repositories (49.2%) targeted supported compilers (Go 1.26 or 1.27).
Go Compiler EOL Distribution in September 2026 Census
Figure 4: Distribution of specified go directives across all 575 Go repositories created on September 4, 2026. Over half of all projects were born targeting obsolete compilers.

PHP Runtime Staleness

A similar pattern appeared in PHP's composer.json. Out of 353 PHP repositories created on September 4, 43 repositories (12.2%) explicitly demanded EOL PHP runtimes (PHP 8.0 or 8.1, both long retired from security support), while another 115 repositories pinned PHP 8.2 (which enters complete End of Life in December 2026).

2. Package Registries Under Cutoff: TypeScript & JavaScript

While Go projects failed at the compiler directive level, JavaScript and TypeScript projects suffered from package-level staleness. Across 15,913 manifest-bearing JS and TS repositories created yesterday, 1,773 projects were born containing packages officially flagged by npm as deprecated or carrying critical security CVEs.

Terminal capture of npm deprecation warnings and dual-era package hallucination
Figure 5: Live terminal inspection of dual-era package hallucination (both @studio-freight/lenis and lenis pinned in the same manifest) and critical Next.js CVE pins.

The top offending dependencies pinned in brand-new codebases included:

  • Vulnerable Next.js Releases (400+ repositories): Models repeatedly pinned next@14.2.5, next@14.2.15, and next@^15.1.0, all of which carry active npm deprecation advisories for known remote code execution and server-side request forgery CVEs.
  • Dead Component Libraries: recharts@^2.12.7 and recharts@^2.15.0 were injected into 150+ brand-new repositories, despite maintainers officially deprecating the 1.x and 2.x lines in favor of Recharts v3.
  • Abandoned Tooling: eslint@8.57.0 (deprecated legacy major version) and eslint-plugin-markdown@2.2.1 (deprecated in favor of @eslint/markdown) appeared across hundreds of initial commits.
  • The Tailwind v3 Generational Regress: 3,406 out of 15,913 repositories (21.4%) pinned tailwindcss@^3.4.x, retaining legacy tailwind.config.js files rather than the modern CSS-first Tailwind v4 architecture released in January 2025.

3. Python: The Long Tail of Stale Packages

In Python, the median dependency age was 236 days (~8 months), but the distribution displayed a massive long tail reaching beyond 1,800 days (~5 years) for foundational libraries. Furthermore, 551 Python repositories explicitly declared EOL or EOL-imminent runtimes in pyproject.toml or Dockerfiles (including Python 3.8, 3.9, and 3.10).

Because Python tools historically tolerate loose version specs, agents frequently emit unpinned or weakly constrained requirements.txt files that default to years-old dependency trees.

4. The Compiler Shield: Why Rust Resists

The most revealing contrast in the census came from Rust. Across all 623 Rust repositories created on the same day:

  • Zero repositories targeted legacy editions: 100% targeted either the 2021 edition or the modern 2024 edition.
  • The median dependency age was only 47 days: Compared to 274 days in TypeScript, 337 days in JavaScript, and 236 days in Python.
  • The deprecated package rate was just 1.0%: Only 6 repositories contained a yanked crate.

This contrast illustrates the power of compiler friction. The Rust compiler and cargo resolve dependencies strictly. If an AI model outputs an obsolete macro crate or a broken API from 2022, cargo check fails immediately. This forces the human or autonomous agent loop to update the manifest before committing to git.

In contrast, Go compiler directives and dynamic npm or PyPI manifests fail silently. They install without build-time complaints, allowing temporal decay to slip into production repositories undetected.

empirical-census-2026-09-04.summary
Global Greenfield Software Census 34,187 REPOSITORIES ACCOUNTED FOR
GO EOL RUNTIMES 50.6% 291 / 575 repos on go <= 1.25
MANIFEST DEPRECATIONS 2,187 Flagged across 1,981 repos
TAILWIND V3 INERTIA 21.4% 3,406 repos stuck on legacy v3
RUST COMPILER SHIELD 47 Days Median dependency age (0% EOL)
Exhaustive 24-hour census conducted across 30-minute micro-slices for all public GitHub repositories created on September 4, 2026.

The 2026 Engineering Playbook: Defeating Cutoff Inertia

If you use AI coding assistants or autonomous coding agents in 2026, you cannot trust raw model memory to scaffold new projects. I recommend implementing these four concrete practices:

  1. Explicit Environment Injection: Never prompt an agent with "Create a Go/Node/Python project." Anchor the prompt with active environment details: node --version, go version, and python3 --version must be injected into the system prompt or agent context.
  2. CLI-Driven Scaffolding over Manifest Generation: Require agents to invoke official CLI initializers (e.g. npm create vite@latest, uv init, cargo new) rather than generating package.json or pyproject.toml from parametric memory.
  3. Mandatory Day-Zero Audit Gates: Wire automated dependency linters (npm audit, pip-audit, govulncheck) into pre-commit hooks and CI gates to reject deprecated packages before code review.
  4. Pin Modern Runtimes in Project Contracts: Maintain explicit .node-version, .python-version, and go.work files in repository roots to prevent agents from guessing obsolete runtime targets.

Primary sources & data: GitHub 24-Hour Census (Sept 4, 2026, N=34,187) | Go Release Policy and Milestones | Node.js LTS Schedule | End of Life Software Tracker | npm Registry API