DORA Report: AI Code Review Time Jumps 441% | NeuralWired
DevOps & Engineering
DORA Report: AI Code Review Time Jumps 441%
By the NeuralWired Engineering Desk · Updated July 2026 · 11 min read
Your team ships AI generated code faster than ever. Your review queue is where that speed goes to die. New data from Google’s DORA team and a 22,000 developer telemetry study from Faros AI both point to the same uncomfortable number: median time spent in code review is up 441.5% as AI adoption climbed, not down. If you’re an engineering leader who assumed AI code review would fix the bottleneck AI code generation created, the 2026 numbers say otherwise, and you need to see them before your next tooling decision.
Every AI coding tool vendor is currently selling some version of the same promise: write code faster, review it faster, ship it faster. The generation half of that promise is real. The review half is where the story falls apart.
Faros AI’s “AI Engineering Report 2026: The Acceleration Whiplash” is the most current dataset available on this question. It draws on two years of telemetry from 22,000 developers across more than 4,000 teams, comparing each organization’s lowest AI adoption periods to its highest. The headline findings:
Median time to first PR review is up 156.6%
Average time spent in code review is up 199.6%
Median time in review overall is up 441.5%
AI code acceptance rate rose from 20% to 60%
Faros AI sells engineering analytics software built on DORA metrics, so treat this as vendor research with a stake in the outcome, not a neutral academic study. Still, the direction of the finding lines up with Google’s own 2025 DORA State of AI Assisted Software Development report, produced with GitHub and IT Revolution. DORA’s framing is that AI acts as an amplifier: it strengthens teams that already have solid engineering practices, and it exposes the weaknesses of teams that don’t. Roughly 90% of developers now use AI daily, according to the report, but nearly a third, 30%, say they have little to no trust in AI generated code.
That distrust has a name in the DORA report: the “verification tax.” Time saved writing code gets spent auditing it instead, and that tax lands squarely on reviewers.
A note on the “4.2 hours vs 90 seconds” claim you might have seen elsewhere. That comparison doesn’t hold up against any primary source we checked. Real human review times range from roughly 4 hours at Google internally to 3 to 5 days at typical enterprise teams, and AI review tools themselves range from about 30 seconds (GitHub Copilot) to several minutes for deep-index tools like Greptile. We’re using the sourced numbers above instead.
Why Review Time Is Exploding, Not Shrinking
Kent Beck, the creator of Extreme Programming and a co-author of the Agile Manifesto, put it about as bluntly as anyone in the industry has:
“We’re accumulating code faster than we are accumulating trust.”
Kent Beck, “Trust Factory” newsletter, newsletter.kentbeck.com
That’s the whole problem in one sentence. AI generated code is, by multiple accounts, superficially convincing. It’s idiomatic. It’s well named. It reads like something a competent engineer wrote. Which is exactly why surface level review, the thing AI review tools are best at, becomes less useful over time: the bugs living in that code tend to be structural, not stylistic. Faros AI’s analysis makes the point directly, arguing that the engineers with the deepest system knowledge are the ones spending their most valuable hours unraveling plausible looking code that should never have reached them in that state.
An independent academic study published on arXiv in December 2024, still the most cited empirical study of its kind as of mid-2026, tested an LLM based automated review tool in real production repositories. Average PR closure time rose from 5 hours 52 minutes before the bot to 8 hours 20 minutes after, a statistically significant increase. Results varied by project. One project’s closure time dropped from 6 hours 6 minutes to 3 hours 7 minutes. Another rose from 20 hours 22 minutes to 30 hours 51 minutes. Roughly 73.8% of the tool’s comments were acted on, and developers reported a modest quality improvement, but the bot also introduced faulty reviews and irrelevant comments that added friction of its own.
Stack Overflow’s 2025 Developer Survey backs this up from the sentiment side: 84% of developers use or plan to use AI tools, yet 66% say their biggest pain point is AI output that’s “almost right,” and 45% say debugging AI generated code takes longer than debugging their own. Sonar’s State of Code 2026 survey of 1,149 developers found 96% don’t trust that AI generated code is functionally correct, but only 48% say they always review before committing. That gap between distrust and actual review discipline is worth sitting with.
The Benchmark Problem: Nobody Agrees What “Accurate” Means
Here’s the part that should worry anyone about to sign a contract with an AI code review vendor: the bug catch rate numbers those vendors publish don’t agree with each other, and they don’t agree with independent testing either.
Tool
Vendor-reported catch rate
Independent benchmark result
Greptile
82% (own 50-PR benchmark)
24% (Martian benchmark)
GitHub Copilot
54% (Greptile’s benchmark)
Not independently ranked in same test
CodeRabbit
44 to 51% (varies by benchmark)
46% (Macroscope’s ranking)
Cursor BugBot
Not separately vendor-reported
42% (Macroscope’s ranking)
Macroscope
Self-reported top performer
48% (its own ranking)
Source: Augment Code’s tool comparison, which flags the discrepancy directly, and buildmvpfast.com’s 2026 tool roundup. There is currently no independent, consensus benchmark for AI code review accuracy. Every number circulating in vendor decks was either run by the vendor or selected by the vendor. Treat any single “catch rate” claim as a marketing input, not a procurement fact, and run a short pilot against known bugs in your own codebase before you buy anything.
CodeRabbit’s own analysis of 470 pull requests, worth noting as vendor data about a competitor’s output rather than its own, found reviewers spend 91% more time reviewing AI generated code than human written code, with three times more readability problems and 75% more logic errors.
What This Means If You Run an Engineering Org
If you’re a VP of Engineering, a Director, or a staff engineer sitting on a tooling decision right now, here’s the shift that matters. Review is the bottleneck now, not code generation. If you’ve been measuring success by PRs merged or deployment frequency alone, you’re getting a misleading picture, because DORA’s and Faros’s data both show throughput metrics improving at the exact same time that stability metrics, change failure rate and rework rate especially, get worse.
DORA’s response to this was structural: the framework expanded from four metrics to five in 2024, adding “rework rate” specifically because AI driven throughput gains were making the old four-metric picture insufficient. That’s the metric to start tracking alongside deployment frequency, not instead of it.
GitHub’s own product team has landed on a position that’s becoming the de facto industry norm: a human always owns the merge button. From GitHub’s official blog:
The team’s interviews with developers found something specific worth stealing for your own workflow: running a Copilot self-review before opening a PR eliminated roughly a third of trivial back-and-forth comments. That’s the actual win available right now, catching the small stuff before a human ever sees the diff, not replacing the human’s judgment call on whether the change should exist at all.
Jon Wiggins, a machine learning engineer at Respondology, put the accountability question in plain terms:
“If an AI agent writes code, it’s on me to clean it up before my name shows up in git blame.”
Jon Wiggins, ML Engineer, Respondology · via github.blog
Any team that’s dropped the human merge gate entirely should be treated as an outlier taking on real production risk, not a leading indicator of where the industry is headed.
The Contrarian Case: 19% Slower, Not 20% Faster
The single strongest piece of contrarian evidence in this entire dataset comes from METR, the nonprofit Model Evaluation and Threat Research group. Its randomized controlled trial, reported in MIT Technology Review, found experienced developers believed AI made them 20% faster. Objective measurement of the same developers found they were actually 19% slower.
That’s not a survey. It’s a controlled study, which makes it much harder to wave away than the productivity claims coming out of vendor marketing. Mike Judge, a principal developer at the software consultancy Substantial, described the gap between perception and reality from the inside:
“I was complaining to people because I was like, ‘It’s helping me but I can’t figure out how to make it really help me a lot.’”
Mike Judge, Principal Developer, Substantial · via MIT Technology Review
Is the “AI review saves time” story realistic on a 2026 timeline? Not straightforwardly. The one controlled academic production study we found (the arXiv paper above) showed AI review increasing PR closure time. Any claim that AI review is a simple time saver needs that caveat attached, because in the best documented empirical test available, it wasn’t one.
GitHub Code Quality’s July Launch: A Real Test Case
There’s a genuinely useful stress test coming. GitHub Code Quality, the governance and quality gate product bundling CodeQL analysis with Copilot code review, moves from public preview to a paid, generally available product on July 20, 2026. More than 10,000 enterprises used the preview. Pricing lands at $10 per active committer per month on enabled repositories, plus usage based consumption for AI powered features like Copilot code review and Copilot Autofix.
Watch what happens to review time metrics at organizations adopting this over the next two quarters. If GitHub’s human-gated model actually closes the gap the data above describes, that’s the strongest real-world signal we’re likely to get all year.
What to Actually Do About It
Track rework rate and time-in-review, not just deployment frequency. A team that ships faster while rework climbs isn’t actually faster.
Keep a mandatory human merge gate. This is GitHub’s own stated product philosophy, not just an internal best practice.
Run AI self-review before human review, not instead of it. GitHub’s data shows this cuts trivial back-and-forth by roughly a third.
Pilot any review tool against your own codebase’s known bugs before trusting a vendor’s published catch rate.
Cap PR size. Multiple sources point to growing PR size, not tooling choice, as the actual driver of review slowdown.
FAQ
Does AI code review replace human code review?
No. Every credible source, including GitHub’s own product team, treats AI review as a first-pass filter for mechanical issues like typos and unused imports, while reserving architecture decisions and merge accountability for human reviewers. GitHub’s official position is that developers will always own the merge button.
How much time does AI code review actually save?
Results are mixed and contested. Vendor claims report time savings, but the most rigorous data, DORA’s 2025 report and Faros AI’s 2026 telemetry from 22,000 developers, found overall review time increasing, with median time-in-review up 441.5% as AI-generated code volume outpaced human review capacity.
What is the most accurate AI code review tool?
There is no independent consensus benchmark. Vendor-run tests and independent benchmarks disagree sharply. Greptile scores 82% bug-catch-rate on its own benchmark but 24% on the independent Martian benchmark. Pilot tools against your own codebase rather than trusting a published leaderboard.
Do AI code reviews catch more bugs than human reviewers?
AI reviewers are strong at mechanical pattern matching, things like missing awaits or unused variables, but consistently weaker at architectural and cross-file reasoning unless built around full-codebase indexing. No tool currently matches an experienced human reviewer’s judgment on whether a feature should exist at all.
Is AI-generated code more likely to have bugs than human-written code?
Yes, per multiple 2026 sources. CodeRabbit’s analysis of 470 pull requests found AI-generated code produced 75% more logic errors and three times more readability problems than human-written code, alongside rising bug rates as AI-code acceptance climbed from 20% to 60%.
Where This Goes Next
Here’s what the 2026 data actually tells you, stripped of the vendor gloss: AI hasn’t made code review faster. It’s made code review the bottleneck the rest of the pipeline is now waiting on, and the tools built to fix that problem haven’t closed the gap yet. Median time-in-review is up 441.5% at the same moment AI review tooling has proliferated across the industry. Those two facts sitting next to each other are the story.
Over the next 6 to 18 months, watch three things. First, whether GitHub Code Quality’s July 20 general availability launch actually moves review-time metrics at scale, since it’s the first major product to bundle static analysis and AI review under one governance umbrella with real enterprise adoption behind it. Second, whether an independent, non-vendor benchmark for AI review accuracy finally emerges, because right now buyers are flying blind. Third, whether DORA’s rework rate metric becomes standard practice at more organizations, since it’s currently the best early warning signal available for exactly the kind of quality debt this article describes.
Our read: this signals a market correction is coming for AI code review vendors who’ve been selling speed as the headline benefit. The winners over the next year will be the tools that reduce rework, not the ones with the flashiest catch-rate slide.
Want data-backed engineering and AI coverage like this in your inbox every week? Subscribe to The Neural Loop at neuralwired.com/newsletter.
Best Programming Languages to Learn in 2026: What the Data Actually Says
TypeScript just dethroned Python on GitHub for the first time in over a decade. AI tools cut junior developer job postings by 25%. The honest, data-backed ranking every developer needs before choosing their next language.
NeuralWired Research DeskMay 23, 202614 min read2026 DataCareer Guide
In August 2025, TypeScript did something no language had managed in over a decade: it knocked Python off the top spot on GitHub. The margin was slim, roughly 42,000 contributors, barely 1.6% of a 180-million-user platform, but the symbolism landed across every developer forum worth reading. The era of “just learn Python” as universal career advice had quietly ended.
What makes 2026 genuinely different is that the question itself is evolving. It used to be, “which language gets me hired?” Now it carries a harder layer, “which languages will still require a human to write them in 18 months?” That’s not alarmism. SWE-bench verification rates jumped from 33% to over 70% in just two years. Google’s Sundar Pichai confirmed AI now writes more than a quarter of code at the company. These are not talking points. They’re operational realities.
+66.6%TypeScript contributor growth on GitHub YoY — Aug 2025
+7ppPython’s Stack Overflow adoption jump, largest single-year gain in a decade
−25%Drop in entry-level developer job postings in 2024
+15%BLS projected growth in software developer roles through 2034
The Shift Nobody Saw Coming
The programming language landscape had a stable power structure for years. JavaScript dominated developer surveys for a decade. Python rose steadily through the AI boom. Then 2025 delivered a genuine plot twist in each direction, back to back.
The 2024 GitHub Octoverse was the first signal: Python dethroned JavaScript for the first time in over a decade, fueled by a 59% surge in contributions to generative AI projects and a 98% increase in total generative AI project count. Then, barely twelve months later, TypeScript dethroned Python. In a platform of 180 million users, TypeScript added over 1 million monthly active contributors year-over-year, a 66.6% jump, reaching 2,636,006 contributors just ahead of Python’s 2,594,000.
Why TypeScript? The short answer is AI-assisted development. A 2025 academic study found that 94% of LLM-generated compilation errors are type-check failures. When teams are shipping AI-generated code into production, and 80% of new GitHub developers are using GitHub Copilot in their first week, TypeScript’s static typing catches a category of bugs that JavaScript cannot. Typed code and AI code generation are natural allies.
“We might be six to twelve months away from when the model is doing most, maybe all of what software engineers do end-to-end. I have engineers within Anthropic who say I don’t write any code anymore. I just let the model write the code. I edit it.”
— Dario Amodei, CEO & Co-Founder, Anthropic — Davos, January 2026
Our read: Amodei isn’t predicting the death of programming. He’s predicting the death of a particular kind of programming, the mechanical, specification-driven implementation work that entry-level roles have always been built on. The languages that matter in this environment are those where human judgment adds irreplaceable value: architecture, performance, security, domain logic. That reframe points toward exactly the same top languages, for different reasons than before.
2026 Language Rankings at a Glance
This table synthesizes GitHub Octoverse 2025, Stack Overflow Developer Survey 2025, TIOBE Index (May 2026), U.S. Bureau of Labor Statistics projections, and current job market salary data. No single source tells the full picture; this combines all of them.
#
Language
Primary Signal
US Senior Salary
Best For
AI Threat Level
1
Python
TIOBE #1 (21.81%); SO +7pp YoY
$98k–$188k
AI/ML, data science, automation
Medium–Low (core AI infra)
2
TypeScript
GitHub #1 by contributors (Aug 2025)
$95k–$180k
Full-stack, AI-product builds
Low (type safety + AI)
3
JavaScript
Stack Overflow #1, 66% usage, 13 yrs
$85k–$160k
Web, frontend, rapid prototyping
Medium (frontend commoditizing)
4
Rust
Most admired 10 years straight (72%); +35% job posts YoY
$130k–$235k
Systems, infrastructure, security
Very Low (perf-critical)
5
Go
TIOBE #8; cloud-native & DevOps
$115k–$195k
Cloud backends, DevOps, AI infra
Low (concurrency nuanced)
6
Java
TIOBE #3; enterprise bedrock
$95k–$175k
Enterprise, Android
Medium
7
C#
TIOBE Language of the Year 2025
$90k–$165k
.NET, Unity, enterprise
Medium
8
SQL
Non-negotiable second skill; PostgreSQL most admired DB, 3 yrs
$85k–$155k
Data engineering, analytics, backend
Low (query logic = human judgment)
The Top 8 Languages: Deep Dives
01
PythonThe Undisputed AI-Era King — With Caveats
Python’s position in 2026 is paradoxical: it’s simultaneously the most important language to learn and the most over-hyped entry-level career path. The TIOBE Index gives Python a 21.81% market share, a dominant lead no other language comes close to. Stack Overflow’s 2025 survey recorded its largest single-year adoption jump in over a decade: +7 percentage points. AI/ML job postings on Indeed are up 134% since 2020, and Python powers the overwhelming majority of that work.
The caveat: TIOBE CEO Paul Jansen noted in early 2026 that Python’s share has declined from a peak of 26.98% in July 2025 as domain-specific languages gain ground. Python’s explosive growth may be plateauing, when every data scientist already uses it, further growth hits a ceiling.
What the job market actually wants in 2026: not basic Python. Hiring managers want FastAPI, LangChain, experience building on LLM APIs, and Python used as infrastructure glue for AI pipelines — not just scripted data manipulation. The “learn Python in 30 days” bootcamp path leads to the most competitive segment of an increasingly AI-saturated entry-level market.
“Our goal is for Python to be a great tool that helps the ever-growing developer community build the world they envision. We couldn’t be more pleased to learn about Python’s continued rise in popularity on GitHub, especially coupled with the increased use of Jupyter Notebooks, data analysis, AI, and open source technology.”
— Deb Nicholson, Executive Director, Python Software Foundation — GitHub Octoverse 2024
TypeScriptGitHub’s New #1 — and the AI-Native Default
TypeScript’s ascent to the top of GitHub isn’t just a popularity story, it reflects a structural change in how professional teams ship code in an AI-assisted era. When AI tools generate your code, type errors become the primary failure mode. TypeScript catches them at compile time. JavaScript doesn’t. For engineering teams shipping AI-generated code into production, which describes most of them, this is risk management, not preference.
A critical context note worth having: the 42,000-developer margin between TypeScript and Python on GitHub is just 1.6% of the platform. TypeScript also compiles to JavaScript, they share the same runtime ecosystem. The JavaScript + TypeScript combined total vastly outscales Python in total GitHub activity. The “TypeScript at #1” headline is accurate, but that framing completes it.
There is a legitimate dissenting view from senior developers, particularly at smaller companies: TypeScript’s type system is over-engineered for teams under ten people, and the velocity cost of strict typing outweighs its benefits outside enterprise-scale codebases. Smaller startups often retain plain JavaScript for speed. That’s not wrong, it’s a real tradeoff, not a failure to understand TypeScript.
GitHub #1 · Aug 2025+66.6% YoYAI-nativeReact/Next.jsNode.js
03
JavaScriptStill the Most-Used Language on Earth
JavaScript has been used by 66% of all professional developers for thirteen consecutive years in Stack Overflow surveys. You can’t build a frontend without it, TypeScript compiles to it. You can’t run Node.js backends without it. The shift to TypeScript doesn’t reduce JavaScript’s relevance; it refines it. The JavaScript/TypeScript ecosystem combined still vastly outscales every other language by total GitHub activity.
The frontend commoditization threat is real: AI tools can scaffold basic React interfaces faster than most junior developers. But the JavaScript developer who understands the runtime, the event loop, and the performance model remains difficult to replace. The language isn’t the moat, the depth of understanding is.
SO #1 by usage · 66%13 consecutive yearsReactNode.jsVue
04
RustThe Highest-Paying Language — and the Most Honest Career Bet
Rust has been the most admired programming language in the Stack Overflow Developer Survey for ten consecutive years, 72% admiration rate in 2025. Job postings grew 35% year-over-year. US senior salaries run $130,000 to $235,000+, with top employers including Cloudflare, 1Password, and Figma. The salary premium exists precisely because the talent pool is small, only an estimated 709,000 developers use Rust as their primary language globally.
The admiration-to-adoption gap is real and requires honest framing: TIOBE still doesn’t rank Rust in its top 15 by search volume. The ownership model and borrow checker genuinely filter out casual learners, not as a flaw, but as the mechanism that produces the quality guarantees that make Rust worth paying for. For mid-career developers targeting systems programming, infrastructure, or AI inference infrastructure (where Rust is already displacing Python at companies like Cloudflare), this is the strongest long-term career bet in the entire landscape, if you can commit to the learning curve.
Most admired · 10 years straight$130k–$235k++35% job posts YoYSystemsSecurity
05
Go (Golang)The Pragmatist’s Systems Language
Go sits at #8 on TIOBE with strong and growing adoption in cloud-native backends and DevOps tooling. It’s the gentler on-ramp to systems programming compared to Rust, no borrow checker, a straightforward concurrency model, and a famously simple toolchain. Go developers working on AI inference roles command salaries roughly 37% higher than TypeScript counterparts in equivalent roles, per 2026 benchmark data. Best choice for developers targeting scalable backends, Kubernetes tooling, or infrastructure work, high ROI without a year-long learning cliff.
TIOBE #8Cloud-nativeKubernetesDevOpsConcurrency
06
JavaEnterprise Bedrock That Refuses to Die
Java’s trajectory is the cautionary tale about dominance not being permanence, and then the plot twist where it refuses to confirm the lesson. TIOBE had Java at 26.49% share in 2001; today it sits near 8%. That sounds like collapse. But Java remains TIOBE’s #3 language overall, powers the majority of enterprise backends globally, runs Android development, and is embedded in financial services and healthcare systems that aren’t being rewritten anytime soon. Java in 2026 is a stability bet, not a growth bet.
TIOBE #3EnterpriseAndroidSpringFintech
07
C#TIOBE’s Language of the Year — With a Defined Niche
TIOBE named C# its “Programming Language of the Year 2025” for achieving the largest year-over-year gain among tracked languages. This measures growth rate, not absolute dominance, Python still holds the top spot overall. But C#’s resurgence reflects Microsoft’s ongoing .NET investment and Unity’s continued reign as the dominant game development engine. If game development or Microsoft-stack enterprise is your specific target, C# is non-negotiable.
TIOBE Language of the Year 2025.NETUnityEnterprise
08
SQLThe Non-Negotiable Second Skill
SQL isn’t a language to learn in the way Python or TypeScript is. It’s table stakes. PostgreSQL has been the most admired and most desired database in Stack Overflow’s Developer Survey for three consecutive years. Every data role, every backend role, and every analytics role requires SQL competency. The fastest path to employability in 2026 — starting from zero, is Python + SQL, not Python alone. Don’t treat SQL as optional. It isn’t.
Non-negotiablePostgreSQL most admired DB, 3 yrs straightData engineeringAnalytics
The AI Disruption: What It Actually Means for Your Career
Here’s the uncomfortable arithmetic most career guides skip: the U.S. Bureau of Labor Statistics projects 15% growth in software developer jobs through 2034, roughly 129,200 new openings per year. Simultaneously, it projects a 6% decline in traditional “computer programmer” roles. Both numbers are accurate. They don’t contradict each other. The industry is growing at the top while contracting at the bottom.
Entry-level developer job postings dropped approximately 25% in 2024. Employment of developers aged 22–25 fell nearly 20% that same year. An IEEE Spectrum report from December 2025 found employers’ outlook for graduate hiring was at its most pessimistic since 2020, explicitly attributing the shift to AI handling tasks previously assigned to junior developers.
⚠ Critical Context
The “learn Python and get hired in six months” advice was accurate in 2021. It’s still true for the right Python skills, but the wrong version (basic scripting, vanilla CRUD apps) is the fastest way to build a portfolio that AI can already replace. The bar for “hireable” has shifted upward, not disappeared.
SWE-bench verification rates — measuring how well AI resolves real GitHub issues, jumped from 33% in early 2024 to over 70% by early 2026. That’s not linear progress. It’s an inflection point. GitHub Copilot reached 4.7 million paid subscribers by January 2026, up 75% year-over-year. Over 1.1 million public repositories now import an LLM SDK, up 178% year-over-year.
The pattern that emerges is consistent: AI is replacing tasks, not entire professions. It replaces the most routine, specification-driven implementation work fastest. What it can’t reliably replace, yet, is architectural judgment, security reasoning, performance-critical optimization, and deep domain expertise. The languages commanding the highest salaries in 2026 (Rust, Go senior roles, Python AI engineering) all map to exactly these categories.
AI is replacing the most specification-driven coding fastest. What remains is judgment, and the languages that reward judgment pay the most.
How to Choose: A Decision Matrix
The right language depends entirely on where you’re starting and where you’re going. Here’s the breakdown without the generic advice.
Starting from zero
Python, then SQL. Python’s syntax is the lowest-friction path to being productive. It’s the #1 language for AI and data roles, which are the fastest-growing job category. SQL pairs immediately for data work. JavaScript is the right alternative if you specifically want to build visible web applications from day one, seeing results in a browser sustains motivation. Avoid starting with Rust or C++, the time-to-productivity ratio is too low for beginners.
Mid-career switch or bootcamp student
Python + TypeScript is the highest-ROI six-to-twelve month combination in 2026. Python for AI-integrated backend work; TypeScript for full-stack product development. The portfolio you need isn’t a to-do app. It’s a project integrating an LLM API, handling real data, and demonstrating architectural thinking, even at modest scale. GitHub presence matters more than certifications in 2026’s hiring environment.
Mid-career developer (5–10 years in)
The language question is secondary to the domain question. Domain expertise in healthcare, fintech, infrastructure, or security is the moat AI doesn’t erode. That said: adding Rust or Go to a Python/TypeScript base positions you for systems and infrastructure roles commanding $140k–$200k+. The admiration-to-adoption gap in Rust (72% admired, small talent pool) signals a hiring premium that early adopters will capture.
Engineering manager or CTO
TypeScript should be your default assumption for new projects, 80% of new developers on GitHub use Copilot in their first week, and TypeScript produces fewer AI-generated compile errors. Audit your stack against the GitHub Octoverse 2025 finding: 80% of new library activity is concentrated in six languages (Python, JavaScript, TypeScript, Java, C++, C#). If your stack sits outside this cluster, your dependency maintenance burden is growing.
💡 Our Read
The safest combination for a career spanning the next decade: Python for AI/data work, TypeScript for product builds, SQL as the non-negotiable second skill, and a serious Rust study effort before 2027. That covers the three dominant trends without betting everything on a single paradigm.
FAQ: Best Programming Languages to Learn in 2026
The top questions Google surfaces on this topic, answered directly and completely.
Which programming language is most in demand in 2026?
Python leads job market demand in 2026, especially for AI, data science, and machine learning. The Stack Overflow 2025 Developer Survey recorded Python’s largest single-year adoption jump, +7 percentage points, of any major language. AI/ML job postings on Indeed are up 134% since 2020. For full-stack product roles, TypeScript is increasingly the default hiring assumption.
Is Python still worth learning in 2026?
Yes. Python holds TIOBE’s #1 spot at 21.81% market share and dominates the fastest-growing job category in software. Senior Python developers earn $98k–$188k annually. The caveat: entry-level Python scripting faces direct AI competition. Pairing Python with SQL and LLM framework experience (LangChain, FastAPI) is what the 2026 job market rewards.
Is JavaScript still relevant in 2026?
Absolutely. JavaScript is used by 66% of all professional developers, the most-used language for thirteen consecutive years per Stack Overflow. TypeScript, which overtook Python as GitHub’s #1 language by contributors in August 2025, compiles to JavaScript. The two are the same ecosystem. Combined, they outscale all other languages in total GitHub activity.
Should I learn Rust in 2026?
Rust is the most admired language (72%, Stack Overflow 2025) and offers the highest salary premium, $130k to $235k+ in the US, with job postings up 35% year-over-year. Best suited for developers targeting systems programming, infrastructure, or security. Not recommended as a first language: the learning curve is steep and the talent pool is deliberately small, which is exactly what drives the premium.
What programming language should a beginner learn in 2026?
Python is the consensus top recommendation: simple syntax, vast library ecosystem, #1 for AI and data roles, strong job market. Pair it with SQL immediately for maximum employability. JavaScript is the best alternative if you want to build visible web results from day one. Avoid starting with Rust or C++, the time-to-productivity ratio is too low for complete beginners.
Is Go (Golang) worth learning in 2026?
Yes, for a specific target. Go ranks #8 on TIOBE and dominates cloud-native backends and DevOps tooling. It’s the gentler path to systems programming compared to Rust, with Go developers in AI inference roles earning roughly 37% more than TypeScript counterparts in equivalent positions. Best for developers targeting scalable backend systems, Kubernetes, or infrastructure work.
What are the highest-paying programming languages in 2026?
In the US: Rust ($130k–$235k+), Go (strong AI inference premium), senior Python ($112k–$188k), and TypeScript in senior full-stack roles. Solidity (blockchain) reaches $120k–$200k but carries market volatility. Salary data from ZipRecruiter, Glassdoor, and RustJobs.dev as of April 2026.
Will AI replace programmers in 2026?
Not entirely, but specific roles are already disrupted. Entry-level developer postings fell ~25% in 2024, and AI generates over 25% of code at Google. The BLS still projects 15% growth in software developer roles through 2034, but simultaneously a 6% decline in traditional “computer programmer” roles. AI is replacing tasks, not entire professions, and raising the floor of what human developers must deliver.
Is TypeScript better than JavaScript in 2026?
For professional development at team scale, TypeScript is increasingly the default: it overtook Python as GitHub’s #1 language in August 2025, driven by the need to catch type errors in AI-generated code. For small projects or solo developers, plain JavaScript remains entirely valid. The debate is real for small teams, TypeScript’s strictness has a velocity cost that not every codebase justifies.
What programming languages are losing popularity in 2026?
Languages in confirmed decline include PHP (dropped from TIOBE #3 in 2010 to #18 by 2026), Objective-C (displaced by Swift), and Haskell. Java’s drop from 26% TIOBE share in 2001 to ~8% today is the canonical cautionary tale, but slow decline over decades isn’t obsolescence. Java remains essential in enterprise and Android. COBOL is maintained but not learned by new developers.
What Comes Next
The best programming languages to learn in 2026, Python, TypeScript, Rust, Go, are correct as answers. But the reason they’re correct has shifted. It’s no longer just about ecosystem size or job posting volume. It’s about where human judgment adds irreplaceable value when AI handles the routine implementation.
Python wins because building AI pipelines requires architectural and domain judgment, not just syntax. TypeScript wins because typed code is how teams safely ship AI-generated code into production. Rust wins because memory-safe, performance-critical systems are the last category AI handles poorly, and the salary premium reflects exactly that scarcity. Go wins because cloud-native infrastructure requires the kind of concurrency reasoning that AI still struggles to get right.
The developer who learns Python + TypeScript this year, pairs it with SQL, builds publicly on GitHub with AI-integrated projects, and starts a serious Rust track before 2027 isn’t playing defense. They’re building a profile genuinely difficult to displace, by an AI or a competitor.
Three things to watch in the next 6–18 months: First, whether SWE-bench rates cross 80%, the threshold at which Amodei’s forecast starts affecting senior roles, not just junior ones. Second, the October 2026 GitHub Octoverse, whether TypeScript’s 1.6% margin over Python holds, widens, or reverses. Third, Rust adoption in LLM inference infrastructure, if it normalizes at Cloudflare-scale companies, the salary premium will compound and early adopters will be positioned ahead of the hiring curve.
The Neural Loop
NeuralWired’s weekly intelligence brief on AI, software, and the future of tech careers, no filler, no hype, just the signal that matters.
Subscribe Free →
OpenAI’s Symphony Turns Linear Tickets Into Merged PRs — No Developer Required
Six weeks after its quiet release, Symphony’s 15,400 GitHub stars tell one story. The engineering teams frantically reading its SPEC.md tell another: autonomous coding agents have arrived, and they’re watching your Jira board.
On March 4, 2026, OpenAI pushed a repository to GitHub called Symphony with almost no fanfare. No keynote. No splashy blog post. Just a SPEC.md, a reference implementation written almost entirely in Elixir, and an Apache 2.0 license. Within four days, the repo had 8,700 stars. By late April it had crossed 15,400, landing it inside the top 3,000 repositories on all of GitHub.
What people were racing to read was a specification for something the AI coding space has been promising for years but hadn’t quite delivered: a system that watches your project management board, claims tickets automatically, runs isolated coding agents to completion, and files pull requests back to your repository without a human ever touching a keyboard. Not a copilot. Not a suggestion engine. An autonomous engineer.
The speed of community interest wasn’t accidental. Engineering managers have spent two years stuck in what practitioners now call “AI pilot purgatory” — tools that help but don’t eliminate the supervision bottleneck. Symphony’s bet is that the bottleneck isn’t AI capability. It’s the workflow. Fix the workflow, and the capability was already there.
What Symphony Actually Does
Strip away the hype and Symphony is, at its core, a ticket-to-pull-request pipeline. It polls a Linear board every 30 seconds, looks for eligible issues, claims them, spins up isolated coding agents powered by gpt-5.3-codex, runs each agent through implementation, and surfaces a finished pull request with CI status and a walkthrough video proving the work was done.
That last part, the proof-of-work video, is worth pausing on. It’s not a diff. It’s a screen recording. The agent shows its work the same way a contractor would: here’s what I built, here’s it running. That’s a deliberate design choice, not a feature tacked on for demos.
“A ticket moves across the board, agents implement, a verified PR appears.”
Nirant, AI Engineer, LinkedIn, March 8, 2026
Nirant’s framing is precise. The board moves. The PR appears. The developer never touched the ticket. That’s the entire value proposition, written in eleven words.
The system isn’t meant to handle every ticket in your backlog. Symphony’s WORKFLOW.md configuration caps concurrent agents at 10 by default and limits each agent to 20 turns per run. These aren’t hard limits, they’re tunable, but they’re sensible defaults that prevent a runaway agent from burning through your Codex API budget on a single misbehaving issue. The framework OpenAI shipped is an engineering preview, and those guardrails reflect a team that’s thought carefully about what happens when things go wrong.
Engineering Preview status: Symphony’s GitHub repository carries 6 total contributors as of late April 2026, with 4 active committers. The latest commit, on March 27, was a GitHub Actions workflow pin. The small team size signals that OpenAI is leading development directly, not handing it off to the community yet.
The Linear-First Design
Symphony’s reference implementation is built around Linear, the project management tool popular with fast-moving engineering teams. That’s not an arbitrary choice. Linear’s data model is structured, its API is stable, and its issue states map cleanly onto the ticket lifecycle Symphony needs to manage: open, in-progress, verified, closed. The SPEC.md suggests the orchestration layer is abstract enough that other issue trackers could plug in, but Linear is the only confirmed integration in the current release.
Unconfirmed: Some early coverage has reported Jira support as a near-term addition. As of late April 2026, this hasn’t appeared in the official repository or specification documents. Treat Jira integration claims as speculative until OpenAI confirms.
Under the Hood: Why Elixir?
The choice of programming language here is the most technically interesting decision OpenAI made, and it’s the one that got the most attention from practitioners who looked past the headline. 95.4% of Symphony’s codebase is Elixir. Not Python. Not TypeScript. Elixir.
If you haven’t spent time in the functional programming world, that might read as an exotic choice. It isn’t. It’s a very deliberate engineering decision that says a lot about what OpenAI thinks the real challenge of agent orchestration is.
“Symphony’s core challenge is not computation, it’s managing many long-lived, concurrent, failure-prone agents.”
Saran Menon, AI/Software Engineering Analyst, LinkedIn, March 9, 2026
Elixir runs on the BEAM virtual machine, the same runtime as Erlang. BEAM was built to power telecom switching systems that couldn’t go down. The core design principle baked into the runtime is this: when something fails, it fails in isolation and restarts cleanly, without taking anything else with it. In telecom that means a dropped call doesn’t crash the switch. In Symphony’s case, it means a hallucinating agent doesn’t kill the other nine agents working in parallel.
“When one agent crashes, and they will, it triggers a supervised restart with full error context while every other agent continues working. This is the kind of thing you’d spend months building in Python or TypeScript — process isolation, supervision strategies, graceful degradation. In Elixir, it’s a first-class language feature.”
sjramblings, Independent Developer — sjramblings.io, March 11, 2026
That’s the crux of it. The Erlang/BEAM supervision tree model, which Elixir inherits natively, solves the hardest operational problem in running autonomous agents at scale: graceful failure. You don’t want your orchestration layer to be a house of cards where one bad LLM response brings down the whole system. Symphony’s runtime choice means it isn’t.
⚡
Concurrency
BEAM’s lightweight processes handle hundreds of simultaneous agent runs without thread-management overhead.
🛡️
Fault Isolation
OTP supervision trees restart failed agents automatically, preserving all other concurrent runs.
🔄
Long-lived Processes
BEAM excels at processes that run for minutes or hours — exactly the profile of an autonomous coding session.
📡
SSH Worker Support
A March 11 commit added SSH worker support to the Elixir reference implementation, expanding deployment options.
Key Configuration Specs: The Numbers That Matter
Symphony’s WORKFLOW.md is worth reading closely if you’re evaluating deployment. The configuration parameters tell you exactly how OpenAI sized the system and where the costs live. Here’s what the current spec shows:
Parameter
Default Value
What It Controls
Why It Matters
Max Concurrent Agents
10
Agents running simultaneously
Caps API cost burn; tunable for larger teams
Max Agent Turns
20 per run
LLM calls before agent stops
Prevents infinite-loop agents on ambiguous tickets
Polling Interval
30,000 ms (30 sec)
How often Linear board is checked
Determines ticket pickup latency
Turn Timeout
900,000 ms (15 min)
Max time per individual turn
Allows complex reasoning without hanging processes
Read Timeout
300,000 ms (5 min)
Max time per I/O read
Prevents stuck file or network operations
Default Model
gpt-5.3-codex
LLM powering each agent
Tight Codex integration; not model-agnostic by default
License
Apache 2.0
Usage rights
Permissive; enterprise use without copyleft concerns
The 15-minute turn timeout is the number that surprises most people encountering it for the first time. It’s long. But when you think about what an autonomous agent actually does, reads context, reasons about architecture, writes code, runs tests, interprets failures, retries, 15 minutes per reasoning step is conservative, not generous. These aren’t chatbot responses. They’re engineering sessions.
Who Wins, Who Worries
Every new infrastructure layer reshuffles who benefits and who’s exposed. Symphony is no different, and it’s worth being clear-eyed about both sides of that ledger.
Engineering Managers
The upside is obvious: a team of 10 developers with Symphony running 10 concurrent agents is, in theory, shipping work that used to require 20 people. The risk is subtler. When Symphony’s Linear integration becomes the de facto entry point for all implementation work, the board becomes a single point of failure. An ambiguous ticket description doesn’t stall one developer, it wastes 15 minutes of Codex API time and produces a PR that needs to be thrown out. Ticket quality suddenly matters in a way it didn’t before.
Individual Developers
Senior developers who spend their time on architecture, system design, and code review are probably fine. The work Symphony automates, picking up a clearly-scoped ticket and implementing it to spec, is disproportionately the work of junior developers. That’s not a neutral observation. The industry needs junior roles to exist, both for the work they do and as a pipeline for the senior engineers of tomorrow. Symphony doesn’t resolve that tension. It sharpens it.
OpenAI
Apache 2.0 licensing looks generous. But Symphony is built to use gpt-5.3-codex by default, and every agent run is a Codex API call. The open-source release is also a distribution strategy. The more teams adopt Symphony’s orchestration model, the deeper Codex becomes embedded in their development workflows. That’s worth more, long term, than keeping the orchestration layer proprietary.
“Unlike traditional AI coding tools that act as co-pilots requiring constant human supervision, Symphony introduces a fully autonomous pipeline. Within four days of its release, the repository amassed 8.7K stars, swiftly scaling past 15.2K stars on GitHub.”
Epsilla Engineering Team — epsilla.com, April 18, 2026
Enterprise Security Teams
This is where the honest conversation gets uncomfortable. An autonomous agent that reads your codebase, interprets tickets, writes production code, and files pull requests has access to a lot of sensitive surface area. Symphony’s current documentation acknowledges security as an open challenge. Prompt injection, where a maliciously crafted ticket description manipulates an agent into doing something unintended, is a real attack vector. So is secret leakage: an agent that logs its reasoning steps could inadvertently expose environment variables or credentials it encountered during a run.
Security note: OpenAI has not published a formal threat model or security audit for Symphony as of late April 2026. Engineering teams evaluating deployment should conduct their own security review, particularly around agent execution sandboxing, secret handling, and PR review gating before any automated merge capability is considered.
The Market Symphony Is Entering
Symphony didn’t arrive in a vacuum. The autonomous coding agent market was valued at $6.4 billion in 2025, with projections putting it at $91.2 billion by 2034, a 38.5% compound annual growth rate. That’s not a niche. That’s one of the fastest-growing segments in enterprise software.
The competitive picture is equally crowded. Anthropic’s Claude Code, Microsoft’s Copilot Agents, and Google’s various AI development tools are all chasing the same prize. But Symphony’s approach differs in one important architectural respect: it treats the issue tracker, not the IDE, as the primary interface. That’s a different bet about where enterprise AI will live.
The autonomous AI coding agent market is growing at 38.5% CAGR, projected to reach $91.2 billion by 2034. Symphony entered this market in March 2026 with open-source licensing, immediately gaining 8,700 GitHub stars in its first four days, an adoption velocity rare for infrastructure tooling.
The key question isn’t whether Symphony works. The GitHub star count and community interest suggest it works well enough to attract serious attention. The question is where it breaks — which classes of tickets produce wasted runs, which codebases confuse the agents, which team workflows don’t map cleanly onto a Linear-centric model. Those answers will come from the teams now forking the repository and running their own experiments. The agent orchestration space is moving fast enough that a six-week-old framework is already prompting architectural decisions at production engineering teams.
What Symphony does to the broader agent framework conversation is force a vocabulary shift. AI developer tools that require engineers to prompt, supervise, and review every AI action are starting to look like a transitional technology. Symphony’s model, manage work, not agents, is a clean articulation of where the category is heading. Whether Symphony itself becomes the standard or gets leapfrogged by something built on its spec is an open question. The spec is the part that matters.
Frequently Asked Questions
What is OpenAI Symphony?
OpenAI Symphony is an open-source agent orchestration framework released in March 2026. It watches a Linear issue board, automatically claims eligible tickets, spawns isolated AI coding agents using GPT-5.3-Codex, and files pull requests upon completion, without requiring a developer to supervise the process.
When was OpenAI Symphony released?
Symphony was open-sourced on March 4, 2026, when OpenAI published the repository at github.com/openai/symphony under an Apache 2.0 license. Major media coverage followed on March 5, and the repository reached 8,700 stars within its first four days.
Why is Symphony written in Elixir?
Symphony uses Elixir (95.4% of the codebase) because Elixir runs on the BEAM virtual machine, which provides OTP supervision trees for fault-tolerant process management. When an individual coding agent fails, the BEAM runtime restarts it in isolation without disrupting other concurrent agent runs, a critical property for reliable autonomous orchestration.
How many concurrent agents can Symphony run?
Symphony’s default WORKFLOW.md configuration caps concurrent agents at 10, with each agent limited to 20 turns per run. Both limits are configurable parameters, not hard ceilings. The defaults are designed to balance throughput with cost control on the underlying Codex API.
Does Symphony work with Jira?
As of late April 2026, Symphony’s confirmed integration is with Linear. The SPEC.md suggests the orchestration layer is designed to be abstract enough for other issue trackers, but Jira support has not been confirmed in official documentation or repository commits. Some early coverage has claimed Jira integration is planned, but this should be treated as unverified until OpenAI confirms it.
Is OpenAI Symphony free to use?
The Symphony framework itself is free and open-source under the Apache 2.0 license, which permits enterprise use without copyleft restrictions. However, Symphony’s reference implementation is configured to use OpenAI’s GPT-5.3-Codex model by default, which requires a paid Codex API subscription. Agent runs generate API costs proportional to usage.
What are the security risks of using Symphony?
The main security concerns include prompt injection via maliciously crafted ticket descriptions, potential exposure of secrets or credentials encountered during agent execution, and the risk of autonomous code being merged without adequate human review. OpenAI has not published a formal threat model for Symphony. Enterprises should implement PR review gating and audit agent execution sandboxing before production deployment.
How popular is Symphony on GitHub?
As of April 25, 2026, Symphony had 15,400 GitHub stars, 1,300 forks, and a global repository rank of approximately 2,913, placing it in the top 3,000 of all repositories on the platform. It reached 8,700 stars in its first four days after release, an adoption velocity considered exceptional for infrastructure tooling.
The Bottom Line
Symphony is the clearest signal yet that the AI coding assistant era is giving way to something structurally different. For two years, “AI-assisted development” meant a developer with a better autocomplete. Symphony means a developer managing a queue. The code still gets reviewed. The PRs still get merged by humans, for now. But the middle step, picking up a ticket, understanding the scope, writing the implementation, running the tests — that step is now optional for a human to perform.
That’s not a claim about the future. It’s a description of what Symphony’s GitHub stars represent: thousands of engineering teams reading the spec and thinking, seriously, about how their workflows would have to change for this to run in production. Some of them are already running it. The commit history and fork count say so.
Whether Symphony specifically becomes the dominant standard or gets absorbed into a larger platform, Microsoft’s or Google’s or OpenAI’s own, matters less than what it proves. The agent orchestration layer for software development now exists. It’s open-source, it’s in Elixir, and it’s already watching your Linear board.
Watch For
01OpenAI’s first major Symphony update post-engineering preview, specifically whether gpt-5.3-codex remains the only supported model or the spec opens to third-party LLMs. Expected Q2-Q3 2026.
02Enterprise security audits and formal threat models for autonomous coding agents, Symphony’s deployment in production environments will likely trigger the first published security research on prompt injection via issue trackers.
03Competitor responses from Anthropic, Google, and Microsoft — each will need an answer to the “manage work, not agents” framing that Symphony has introduced to the enterprise AI conversation.
04Labor market data on junior engineering hiring in companies that have adopted autonomous coding agents at scale, the displacement question won’t be theoretical for much longer.
Stay ahead of the curve.
More on AI agents and developer tools at NeuralWired.
