WAIT — Solo project — review before adopting

• Last commit 4w ago
• MIT licensed
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ No CI workflows detected
• ⚠ No test directory detected
• ⚠ Scorecard: default branch unprotected (0/10)

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests + OpenSSF Scorecard}

A deterministic, reproducible Python pipeline that classifies and analyzes 1,014 Y Combinator companies across 6 cohorts (Winter 2024–Winter 2026) using multi-axis keyword matching (AI pattern, product layer, buyer type, end market, wedge category). Outputs 16 publication-ready charts, 50+ CSV tables, and a companion Medium article tracking shifts in YC's AI positioning, vertical adoption, and founder signals over time. Flat, linear pipeline structure: main.py orchestrates the analysis; config/ holds three YAML taxonomies (cohorts, keywords, taxonomy); data/processed/raw_companies.json is the input dataset; src/ (implied but not listed in file manifest) contains classifier logic; outputs/ holds stratified results (16 PNGs, 50+ CSVs, 3 markdown narratives). No modular packages, no separation of concerns into subdirectories—everything flows from config through main.py to outputs.

Startup analysts, venture capitalists, and business writers who need reproducible, auditable trend analysis on cohort composition and positioning shifts. Specifically useful for founders wanting to understand how YC's taste in problem selection, product architecture, and AI application is evolving, and for researchers needing a fully open source dataset with traceable methodology.

Actively maintained single-project with 72.7KB of Python, published alongside a Medium article, no visible CI/CD setup or test suite in the file listing. Appears production-ready for publication (charts are finalized, tables exported) but lacks automated test coverage and integration pipelines typical of production systems. Likely a post-analysis artifact designed for reproducibility rather than continuous iteration.

Single maintainer (sjmoran) with no visible test automation, CI configuration, or issue tracking in the repo structure. Dependency stack is lean (5 packages: httpx, pandas, pyyaml, matplotlib, tabulate) and stable, but no lock file or version pinning visible in requirements.txt. Main risk: keyword taxonomy in config/keywords.yaml and cohort definitions in config/cohorts.yaml are hardcoded and not versioned, making historical reproducibility fragile if configs are updated retroactively.

Repo appears complete and published. The Medium article is live; all 16 charts and summary tables are generated and committed. No visible open PRs, issues, or active development branches in the file listing. This is a snapshot analysis published at a point in time (Winter 2026 cohort), not an ongoing monitoring system. Future work would likely extend to Summer 2026 and beyond cohorts as YC admits new batches.

git clone https://github.com/sjmoran/yc-ai-cohort-analysis.git
cd yc-ai-cohort-analysis
pip install -r requirements.txt
python main.py

After running, outputs appear in outputs/charts/ and outputs/tables/. The pipeline is deterministic—same input (raw_companies.json) + same config (cohorts.yaml, keywords.yaml, taxonomy.yaml) will produce identical results.

Daily commands:

python main.py

No dev server, no build step. The script reads data/processed/raw_companies.json, applies keyword classifiers from config/keywords.yaml and config/taxonomy.yaml, groups by cohort definitions in config/cohorts.yaml, computes trends and deltas, and writes 16 PNGs + 50+ CSVs + 3 markdown files to outputs/. Runtime is seconds to minutes depending on dataset size.

• main.py — Entry point orchestrating the entire pipeline: scraping YC data, classifying companies, analyzing trends, and generating outputs.
• src/classify_ai.py — Core deterministic multi-axis classifier matching companies against keyword taxonomies; foundational to all downstream analysis and reproducibility.
• config/taxonomy.yaml — Master keyword taxonomy defining AI pattern, product layer, buyer, end market, and wedge categories; changes here propagate to all classifications.
• config/cohorts.yaml — Cohort definitions (Winter 2024 → Winter 2026) mapping batch IDs and date ranges; controls temporal slicing of entire dataset.
• src/trend_analysis.py — Aggregates classified companies across cohorts to compute deltas, emerging categories, and term frequency trends; powers all comparative findings.
• src/visualize.py — Generates all 16 output charts (bump charts, heatmaps, stacked areas) and CSV tables from trend data; transforms analysis into deliverables.
• data/processed/raw_companies.json — Cached YC company roster (1,014 records) with descriptions; source of truth for all downstream classification and analysis.

Add a new classification axis

1. Open config/taxonomy.yaml and add a new top-level axis (e.g., 'business_model') with its category list and keyword mappings. (config/taxonomy.yaml)
2. In src/classify_ai.py, update the classify_company() function to load the new axis from taxonomy and assign categories via keyword matching. (src/classify_ai.py)
3. In src/trend_analysis.py, add aggregation logic to compute cohort shares and deltas for the new axis (follow existing pattern for 'ai_pattern', 'buyer', etc.). (src/trend_analysis.py)
4. In src/visualize.py, add a new chart generation function (bump, stacked area, or heatmap) for the new axis and call it from main visualization routine. (src/visualize.py)

Add a new cohort to the analysis

1. Open config/cohorts.yaml and append a new cohort entry with batch_id, name, start_date, and end_date. (config/cohorts.yaml)
2. Run src/scrape_yc.py to fetch the new batch data and merge into data/processed/raw_companies.json. (src/scrape_yc.py)
3. Re-run main.py; classification, trend analysis, and visualization pipelines automatically incorporate the new cohort in all outputs. (main.py)

Modify or refine the keyword taxonomy for an axis

1. Edit the relevant axis keywords in config/taxonomy.yaml (e.g., add synonyms, remove false positives, adjust category definitions). (config/taxonomy.yaml)
2. Re-run main.py; the classifier reloads the updated taxonomy and re-classifies all 1,014 companies deterministically. (main.py)
3. Review outputs/tables/classified_ai_companies.csv and axis_shares_*.csv to verify impact of taxonomy changes. (outputs/tables/classified_ai_companies.csv)

Add a new chart or trend visualization

1. In src/visualize.py, add a new function (e.g., create_custom_heatmap()) that accepts the trend DataFrame and matplotlib figure. (src/visualize.py)
2. Call the new function from main() in visualize.py and save the output to outputs/charts/ with a descriptive filename. (src/visualize.py)
3. Run main.py to generate the chart; verify output PNG in outputs/charts/. (main.py)

• pandas — Efficient tabular data manipulation for 1,014 companies across 6 cohorts; native CSV/JSON I/O and groupby/aggregate operations.
• PyYAML — Human-editable configuration for taxonomies, cohorts, and keywords; deterministic parsing ensures reproducible classification.
• matplotlib — Publication-quality static charts (bump, heatmap, stacked area) suitable for Medium article and reproducibility archives.
• httpx — Modern async HTTP client for scraping YC company roster; handles timeouts and retries robustly.
• Python 3.10+ — Native f-strings, type hints, and dataclass support simplify data transformation and classification logic; no external ORM required.

• Deterministic keyword-based classification rather than ML model

  • Why: Maximizes reproducibility and auditability; every company label is traceable to a taxonomy entry and keyword match.
  • Consequence: Requires manual curation of taxonomies; less flexible for edge cases; but enables publication-grade transparency.

• JSON cache (raw_companies.json) instead of live scraping on each run

  • Why: Ensures reproducible datasets across runs; avoids YC website changes breaking analysis.
  • Consequence: Cache must be manually refreshed to include new cohorts; adds setup step but guarantees determinism.

• ---

  • Why: undefined
  • Consequence: undefined

Config versioning: If you update config/keywords.yaml after a run, re-running on the same raw_companies.json will produce different (inconsistent) historical results—the pipeline does not version or diff keywords. No env vars: The pipeline has no environment configuration; all paths are hardcoded relative to repo root, so moving data/processed/raw_companies.json will break the pipeline. Raw data sourcing: The repo does not include a script to fetch the 1,014 company records from YC; data/processed/raw_companies.json is assumed to exist. If you need to re-fetch or extend the cohorts, you'll need to reverse-engineer how the JSON was populated (likely via YC's public API or web scraping, not documented in this repo). No imports clarity: src/ directory is referenced in the README context but not listed in the file manifest; the actual source files may be in a different location or bundled into main.py.

• Deterministic keyword-based classification — This repo uses rule-based keyword matching instead of ML/NLP models; understanding that trade-off (interpretability + auditability vs. accuracy + nuance) is core to assessing the reliability of the 16 findings.
• Multi-axis taxonomy (faceted classification) — Companies are classified across 5 independent axes (AI pattern, product layer, buyer, end market, wedge) rather than a single category; this is why outputs include separate trend charts per axis and why a company can be both 'Fintech' and 'Autonomous Agent' simultaneously.
• Cohort analysis and trend deltas — The analysis compares metrics (e.g., 'agent' keyword adoption) across 6 ordered cohorts and computes percentage-point deltas; understanding how deltas are calculated (raw change vs. relative change) is essential for interpreting the 'findings' like '+16.2pp for agent'.
• Bump charts and rank-change visualization — Five of the 16 output charts use bump chart format to show how categories (e.g., end markets, product layers) shift rank cohort-to-cohort; this is a less common viz type and understanding its mechanics helps interpret which positions are rising vs. falling.
• Reproducibility and auditability in data journalism — This entire repo exists to back a Medium article with auditable CSV tables and traceable keyword matches; understanding the philosophy (every claim tied to a row, every label tied to a keyword, every chart to a CSV) is the project's core value proposition.
• Stacked-area and cumulative trend charts — Several outputs use stacked-area charts to show how the share of each axis value changes over cohorts; understanding compositional change (vs. absolute change) is critical for interpreting findings like 'vertical verticalizing from 59% to 71%'.
• Keyword drift and semantic rebranding — A core finding is that 'agent' terminology rose 16.2pp but the underlying autonomous-agent pattern only rose 11.8pp—implying 4.4pp of 'rebranding' or semantic drift; this concept (observing when terms are used differently across time) is crucial for trend analysis in startup ecosystems.

• airtable/yc-companies — Community-maintained Airtable base of YC company data; a potential alternative or supplementary source for the raw_companies.json dataset.
• openai/gpt-2-output-dataset — Demonstrates reproducible, large-scale text classification and analysis with published methodology; similar commitment to auditability and open sourcing.
• huggingface/datasets — Reference for versioned, reproducible dataset pipelines; if this project scales, Hugging Face Datasets would be a natural way to version cohorts and keyword taxonomies.
• ycombinator/ycdc-content — Official YC content and blog; the primary source for understanding YC's strategic priorities and how this analysis intersects with public statements.
• sjmoran/medium-articles — If the author maintains a repo of Medium article source files, this would be the sister repo for the article text, images, and drafting.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for src/classify_ai.py deterministic classifier

The repo's core value proposition is a 'deterministic, inspectable classifier' that produces traceable results. Currently there are no tests to validate that keyword matches in config/keywords.yaml reliably produce expected classifications across cohorts. This PR would add pytest tests that verify: (1) known companies are correctly classified into their axes (ai_pattern, buyer, end_market, product_layer, wedge), (2) edge cases like multi-axis matches are handled consistently, and (3) changes to keywords.yaml don't accidentally break historical classifications. Essential for maintaining reproducibility claims.

• [ ] Create tests/test_classify_ai.py with pytest fixtures for sample companies from each cohort
• [ ] Add assertions validating keyword matches against config/keywords.yaml produce expected axis classifications
• [ ] Test that the same company description produces identical output on repeated runs (determinism check)
• [ ] Add tests for axis priority/conflict resolution when a company matches multiple keywords
• [ ] Update requirements.txt to include pytest>=7.0

Add validation script for config/taxonomy.yaml consistency across outputs/tables/*

The repo outputs 30+ CSV files and 16 charts, all derived from three config files (cohorts.yaml, keywords.yaml, taxonomy.yaml). There's no automated check that ensures output column headers, axis names, and category labels remain consistent with the taxonomy definition. This PR would create a validation script that runs post-pipeline and checks: (1) all CSV files in outputs/tables/ use only axis values defined in taxonomy.yaml, (2) cohort names match config/cohorts.yaml, (3) no orphaned categories appear in charts. Prevents silent data inconsistencies.

• [ ] Create src/validate_config.py to load and cross-check taxonomy.yaml, cohorts.yaml, and keywords.yaml
• [ ] Add validation logic that scans outputs/tables/*.csv and outputs/MEDIUM_ARTICLE.md for undeclared axis values or cohorts
• [ ] Integrate validation check into main.py as a final step before outputs are considered valid
• [ ] Document expected taxonomy structure in a new docs/CONFIG_SCHEMA.md file
• [ ] Add --validate-only flag to main.py for CI/pre-commit usage

Extract shared charting utilities from src/visualize.py into src/chart_lib.py

The outputs/charts directory contains 16 distinct PNG charts (bump charts, heatmaps, stacked areas, etc.), all generated by src/visualize.py. This single file likely contains repeated matplotlib boilerplate (color palettes, font sizing, legend placement, axis labeling conventions). Extracting shared utilities would: (1) reduce duplication, (2) make it easier for contributors to add new chart types with consistent styling, (3) enable centralized control over branding (colors, fonts) across all outputs. This is a refactoring that improves maintainability without changing output.

• [ ] Analyze src/visualize.py and identify repeated patterns: color scheme definitions, cohort color mapping, figure size settings, axis label formatting
• [ ] Create src/chart_lib.py with reusable functions like get_cohort_colors(), apply_default_style(), format_axis_labels()
• [ ] Refactor src/visualize.py to import and use functions from src/chart_lib.py
• [ ] Update any docstrings to reference src/chart_lib.py as the source of styling truth
• [ ] Verify all 16 output PNGs remain visually identical after refactoring

• Add unit tests for keyword classifier determinism: Create tests/test_classifier.py with pytest to verify that running the keyword matcher on a fixed sample of 50 companies always produces identical axis assignments. This would catch regressions if config is accidentally modified.
• Document data source and collection methodology: Write a DATA_COLLECTION.md file explaining how raw_companies.json was populated (API endpoint, scrape method, data schema), with example curl/script so future cohorts can be added reproducibly.
• Create a config validation schema and README: Add config/validate_config.py using pydantic or jsonschema to enforce that every keyword in keywords.yaml maps to valid axes defined in taxonomy.yaml, and document expected YAML structure in CONFIG_GUIDE.md.

The codebase is relatively low-risk for a static analysis and reporting tool. Primary concerns are unverified external data ingestion (web scraping), loose dependency version pinning, and potential YAML deserialization issues. No hardcoded credentials or obvious injection vulnerabilities detected. The project lacks infrastructure (no Docker/API exposed), reducing deployment risk. Recommendations focus on hardening input validation, dependency management, and secure YAML handling. No critical vulnerabilities identified; security posture is acceptable for an open-source analysis pipeline.

• Medium · Unverified External Data Source (Web Scraping) — src/scrape_yc.py, data/processed/raw_companies.json. The codebase includes src/scrape_yc.py which likely performs web scraping of Y Combinator data. Without input validation and sanitization of scraped content, this could introduce malicious data into the pipeline. Scraped HTML/JSON could contain embedded scripts or malicious payloads if the source is compromised. Fix: Implement strict input validation and sanitization on all scraped data. Validate JSON structure, sanitize string fields, and consider using a content security policy. Lock dependencies to specific versions and verify data integrity with checksums.
• Medium · Overly Permissive Dependency Pinning — requirements.txt. The requirements.txt uses loose version constraints (>=X.Y) without upper bounds. This allows transitive dependency updates that could introduce breaking changes or security vulnerabilities. For example, httpx>=0.27 and pandas>=2.0 could pull in patched versions with incompatibilities or unexpected behavior. Fix: Replace >= constraints with pinned versions or narrow ranges (e.g., httpx>=0.27,<0.28). Use tools like pip-audit and Dependabot to monitor for security advisories in locked dependencies.
• Low · Potential YAML Deserialization Risk — config/*.yaml, pyyaml>=6.0 dependency. The codebase loads YAML configuration files (config/cohorts.yaml, config/keywords.yaml, config/taxonomy.yaml). If these are user-controlled or modified by untrusted sources, unsafe YAML deserialization could execute arbitrary Python code via pyyaml. Fix: Use yaml.safe_load() instead of yaml.load(). Ensure config files are treated as immutable and not writable by application runtime or untrusted processes. Add file integrity checks (e.g., checksums) for critical config files.
• Low · Missing HTTPS Enforcement in HTTP Client — src/scrape_yc.py, httpx>=0.27 dependency. httpx is used but there's no visible configuration enforcing HTTPS or certificate pinning. If scrape_yc.py makes requests to Y Combinator or other sources, man-in-the-middle attacks are possible if not explicitly configured. Fix: Explicitly configure httpx to verify SSL certificates. Avoid setting verify=False. Consider implementing certificate pinning for critical external endpoints. Log and validate all HTTP responses.
• Low · No Visible Access Control or Authentication — main.py, overall architecture. The project is a public analysis pipeline with no apparent authentication, authorization, or rate limiting mechanisms. While appropriate for an open-source analysis tool, if this were deployed as a service, it could be subject to DoS attacks or unauthorized data manipulation. Fix: If deployed as a service, implement rate limiting, API authentication, and input validation. For local/batch use, ensure proper file permissions and environment variable access controls.
• Low · Potential Path Traversal in File I/O — src/visualize.py, src/report.py, main.py (file operations). The codebase reads and writes files (data/processed/.json, outputs/tables/.csv, outputs/charts/*.png). If file paths are constructed from user input or config without validation, path traversal attacks (e.g., ../) could access or overwrite arbitrary files. Fix: Validate all file paths using os.path.abspath() and enforce that they resolve within expected directories. Use pathlib.Path for safer path manipulation. Never construct paths from unsanitized user input.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Read in the suggested order before editing unfamiliar code. The reading-order list is computed from the actual import graph, not LLM guesses; reading bottom-up materially reduces wrong-edit risk.
3. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
4. Cite source on changes. When proposing an edit, cite the specific path/to/file.ext:Lstart-Lend you're reasoning about, the same way RepoPilot's own RAG cites code in https://repopilot.app/r/sjmoran/yc-ai-cohort-analysis.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live sjmoran/yc-ai-cohort-analysis repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sjmoran/yc-ai-cohort-analysis.

What it runs against: a local clone of sjmoran/yc-ai-cohort-analysis — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in sjmoran/yc-ai-cohort-analysis | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 55 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sjmoran/yc-ai-cohort-analysis. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sjmoran/yc-ai-cohort-analysis.git
#   cd yc-ai-cohort-analysis
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of sjmoran/yc-ai-cohort-analysis and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sjmoran/yc-ai-cohort-analysis(\\.git)?\\b" \\
  && ok "origin remote is sjmoran/yc-ai-cohort-analysis" \\
  || miss "origin remote is not sjmoran/yc-ai-cohort-analysis (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "main.py" \\
  && ok "main.py" \\
  || miss "missing critical file: main.py"
test -f "src/classify_ai.py" \\
  && ok "src/classify_ai.py" \\
  || miss "missing critical file: src/classify_ai.py"
test -f "config/taxonomy.yaml" \\
  && ok "config/taxonomy.yaml" \\
  || miss "missing critical file: config/taxonomy.yaml"
test -f "config/cohorts.yaml" \\
  && ok "config/cohorts.yaml" \\
  || miss "missing critical file: config/cohorts.yaml"
test -f "src/trend_analysis.py" \\
  && ok "src/trend_analysis.py" \\
  || miss "missing critical file: src/trend_analysis.py"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 55 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~25d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/sjmoran/yc-ai-cohort-analysis"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Computed from the actual import graph (no LLM). Read in this order to learn the codebase from the foundation up — each step builds on the previous ones.

1. src/scrape_yc.py — Foundation: doesn't import anything internally and is imported by 1 other file. Read first to learn the vocabulary.
2. src/classify_ai.py — Foundation: imported by 1, no internal dependencies of its own.
3. main.py — Built on the foundation; imported by 0 downstream files.

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.