Semantic analysis of 69,156 real tickets from the Spring Framework project reveals three tiers of AI readiness — and shows how the balance shifts as a project matures.
Data source: Spring Framework Jira archive, 2003–2021 · Embeddings: OpenAI text-embedding-3-large · Clustering: UMAP + HDBSCAN
As Spring matured, the automatable work got done and what was left became genuinely hard. By 2020 nearly 70% of new tickets were architecture-level problems — security enhancements, JPA edge cases, distributed messaging, framework internals. The routine work didn't disappear — it was resolved. What remained required real expertise.
This is not a story about AI making engineers redundant. It is the opposite. As AI absorbs the repetitive tier, engineers are left with the work that is hardest, most impactful, and most valuable to their careers. The triage tool that routes work correctly becomes more critical as adoption grows, not less.
AI automation doesn't shrink the escalate pile over time — it accelerates through the easy work and exposes the hard problems faster. The triage tool becomes more valuable as adoption grows, not less.
The Assist tier having the lowest density is the key signal — these are the genuinely ambiguous tickets that sit at the boundary between known and unknown territory. That is exactly where a human in the loop adds the most value: not rubber-stamping AI output, but catching the cases where the AI is confidently wrong.
To validate that this is not a Spring-specific quirk, we ran the same analysis on the full Apache Software Foundation Jira archive — 25+ projects spanning Spark, Kafka, Hadoop, Cassandra, Flink, and more.
Same classification across 25 Apache projects reveals that domain complexity — not just team size — determines the tier mix.
| Project | Auto | Assist | Escalate | Tickets |
|---|---|---|---|---|
| OFBIZ | 59% | 32% | 9% | 12,470 |
| YARN | 49% | 39% | 12% | 10,769 |
| HDFS | 49% | 39% | 12% | 15,588 |
| SPARK | 44% | 42% | 14% | 37,443 |
| HBASE | 43% | 40% | 17% | 26,421 |
| KAFKA | 32% | 49% | 20% | 12,312 |
| FLINK | 39% | 40% | 21% | 25,492 |
| IMPALA | 29% | 39% | 33% | 11,031 |
| AMBARI | 9% | 59% | 32% | 25,384 |
| CASSANDRA | 9% | 83% | 8% | 17,115 |
OFBIZ (business app) automates 59% of its work. CASSANDRA (distributed database) has 83% in the assist tier — every change is novel but not necessarily critical. AMBARI and IMPALA have the highest escalate rates, driven by infrastructure complexity. No two projects share the same profile — exactly what task2vec maps.
Without reading a single roadmap document or running a single survey, ticket data alone reconstructs what a team actually builds, where its expertise concentrates, and which direction its work has been drifting. Here is what the two archives tell us.
69,156 tickets across 80+ sub-projects. The distribution reveals a deliberate platform strategy: own the abstraction layer between application code and everything else — every database, every messaging system, every security protocol.
The 12 Spring Data sub-projects (JPA, MongoDB, Redis, Cassandra, Elasticsearch…) each have their own project key. That is a deliberate architectural bet visible purely from ticket structure — no roadmap document needed.
1,014,926 tickets across 350+ projects. The domain breakdown reveals a single thesis: build the distributed systems that move, store, and process data at scales single machines cannot handle.
Big data alone accounts for 15% of all tickets — Spark, Hive, Hadoop, HDFS, Impala. Add streaming (Kafka, Flink, Beam) and distributed databases (Cassandra, HBase, Ignite) and over a quarter of the Foundation's work is the data pipeline stack.
Every one of these insights — what the team builds, where expertise concentrates, which direction work is drifting — came from ticket metadata alone. No interviews. No surveys. No process changes. Connect your Jira or GitHub and task2vec produces the same map for your team in minutes.
Across 1,084,082 tickets from two completely independent codebases — Spring Framework and 25 Apache projects — the same three-tier pattern emerges. Roughly 25–31% of work is safely automatable, 30–52% benefits from AI assistance with human review, and 17–48% requires senior engineering judgment. The exact ratio depends on project domain and maturity. What does not change is that all three tiers are always present — and without a tool to tell them apart, teams route work by guesswork.
Paste any ticket and see which tier it falls into — scored against 40 k real Spring outcomes. No rules. No LLM. Pure historical signal.
Score a ticket →