Will AI replace software developers? The three best studies disagree, and the disagreement is the useful part

Will AI replace software developers? The evidence so far says no, but the more useful answer is more complicated. The three strongest studies of the past two years disagree with each other about who actually benefits, and the disagreement is not noise. It tracks what each one chose to measure, and that distinction is what should shape how you hire.

The strongest studies from the past two years do not agree on how much AI helps developers. A Science study covering 160,097 developers found that senior engineers benefited while early career developers showed no significant gain. A Management Science study based on three randomised controlled trials at Microsoft and Accenture found the opposite, with less experienced developers gaining the most. Research from METR found that experienced developers actually took longer when using AI on their own repositories.

These results are not necessarily contradictory. The studies measured different kinds of work, under different conditions and with different definitions of productivity. Other controlled studies have found substantial reductions in the time needed to complete complex software tasks, while finding little change in maintainability.

That distinction matters for hiring. The question is no longer simply whether AI makes developers more productive. The more useful question is which developers benefit, on which tasks, and under what conditions. Those differences are where the evidence becomes most useful for deciding how engineering teams should hire and work with AI.

In this article:

• What each study actually measured
• What the randomised trials say about speed, and why they split
• Why two of them disagree about seniority
• Why the junior on-ramp closed before the junior jobs did
• Whether three big developer surveys agree with each other
• The cost that arrives after the merge
• What this changes about who is worth hiring
• Conclusion
• FAQ

What do the best studies actually say about AI and developer productivity?

The strongest studies do not measure the same thing, which is why their results look so different.

At the level of the open source ecosystem, AI is already responsible for a substantial share of new code. A Science study by Simone Daniotti, Johannes Wachs, Xiangnan Feng and Frank Neffke used a neural classifier to identify AI generated Python functions across more than 30 million GitHub commits from 160,097 developers. The researchers estimated that AI writes 29% of Python functions in the US, while quarterly output measured through online code contributions increased by 3.6%.

Those numbers are important together. AI may now generate almost a third of Python functions, yet overall output has increased by only a few percent. At scale, AI is clearly changing how code is produced, but that does not mean it is multiplying developer productivity.

Controlled experiments, however, tell a different story. Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng and Tobias Salz ran three randomised controlled trials involving Microsoft, Accenture and a Fortune 100 company. Across 4,867 developers, the study found that developers using the AI tool completed 26.08% more tasks.

The result changes again when the developers are experienced and working in codebases they already know. METR's randomised trial involved 16 experienced developers working on real issues in repositories they maintained. Across 246 issues, developers with AI tools available took 19% longer to complete their work.

Therefore the evidence does not give us one simple AI productivity number. It shows that the effect depends heavily on what is being measured and who is doing the work. That distinction is crucial when deciding what AI means for software engineering teams and the developers they hire.

What do the randomised trials actually say about AI and developer speed?

The randomised trials show a striking patter. AI appears to help developers much more when they are working in unfamiliar code than when they are working in codebases they already know well.

At Google, Elise Paradis and eight colleagues ran a randomised controlled trial with 96 full time engineers on a complex enterprise task. They found that AI reduced the time developers spent on the task by about 21%, although the confidence interval was wide. The study was peer reviewed and published at ICSE SEIP 2025. However, the authors noted that a trial using Google's internal tooling in 2024 may not generalise to other development environments.

A preregistered two phase experiment by Markus Borg and seven colleagues produced a similar result. Published in Empirical Software Engineering in June 2026, the study included 151 participants, 95% of whom were professional developers. In its first phase developers using an AI assistant completed tasks 30.7% faster at the median. On the o0ther hand, habitual AI users showed an estimated 55.9% speedup.

METR's research points in the opposite direction. Its initial randomised trial found that experienced developers took 19% longer when using AI on issues from repositories they already maintained. A larger 2026 follow up involving 57 developers and more than 800 tasks moved in the same direction. In fact the returning participants took about 18% longer. However, its confidence interval ranged from 38% slower to 9% faster, so the result was not statistically significant. With no independent replication of this follow up, it is better treated as directional evidence than a settled finding.

The most useful way to reconcile these results is to look at task familiarity. Google and Borg gave developers tasks in codebases they did not already know. METR gave developers issues in repositories they maintained and understood deeply. An AI model has more to offer when a developer needs to learn an unfamiliar system, while an experienced developer working in familiar code may spend more time reviewing and correcting AI output.

That explanation has not yet been tested directly. No study has used the same protocol and population across both familiar and unfamiliar codebases, so familiarity remains the strongest available explanation rather than a proven cause of the difference.

There is another finding from METR that may matter more for the future of development. Between 30% and 50% of developers in its follow up said they were choosing not to submit some tasks because they did not want to work on them without AI. That suggests developers can experience AI as valuable even when a controlled trial measures them as slower. Productivity is only part of the story. Once developers become accustomed to having these tools, removing them may feel like a loss even when the measured time savings are uncertain.

Why do two of the studies disagree about who benefits?

This is the part worth examining closely because both studies are peer reviewed and use serious methods. Their different conclusions are not necessarily a sign that one is wrong.

Science found that AI benefited experienced and senior developers, while early career developers showed no significant productivity gains. The researchers also found that experienced developers were more likely to expand into new areas of software development.

Management Science reached the opposite conclusion. Its experiments found that less experienced developers had higher AI adoption rates and saw greater productivity gains.

The difference is partly explained by what each study measured. Management Science measured completed tasks inside companies, where work was already assigned and defined. For a less experienced developer who might previously have been slowed by syntax, boilerplate or implementation details, AI can make it easier to complete more of those tasks. The Science study measured contribution behaviour across the open source ecosystem. That includes deciding what to work on and moving into unfamiliar areas. Those decisions require developers to understand where their skills can be applied and what is worth attempting. Experience can matter more when that is the bottleneck.

METR adds another perspective. Its participants were experienced developers working on repositories they already knew well. In that setting, the difficult part was not necessarily figuring out how to write the code. Developers already understood the system and had to judge whether AI generated changes were correct. That makes the time spent reviewing and correcting AI output much more important.

This also explains why evaluating AI assisted code in an interview can reveal more than a simple timed coding exercise. The closer the assessment gets to real development, where a candidate must understand existing code and judge the quality of changes, the more useful it becomes for testing whether someone can work effectively with AI.

The studies therefore do not need to be reduced to a winner and a loser. AI appears to help most when the bottleneck is knowing how to implement something. It has less to offer when the bottleneck is knowing what should be built or when an experienced developer already understands the code and must spend time checking the model's work.

For less experienced developers, that can mean completing more assigned work. For experienced developers, it can mean taking on unfamiliar areas more easily. For experts working in familiar codebases, the review cost can outweigh the time saved by generating code.

Why did the junior on-ramp close before the junior jobs did?

The junior on ramp may be weakening before the demand for junior developers has disappeared. One reason is that the place where many developers learned in public has become much quieter, and the decline has been particularly pronounced among newer users.

Data queried directly through the Stack Exchange API on 18 August 2026 shows that new questions on Stack Overflow fell from 110,788 in July 2022 to 1,394 in July 2026. That is a 98.7% decline over four years. The decline began before ChatGPT, so the change cannot be attributed to generative AI alone.

Two peer reviewed studies provide evidence for the part AI may have played. Gordon Burtch, Dokyun Lee and Zhichen Chen analysed developer communities on Stack Overflow and Reddit from October 2021 to March 2023. They found significant declines in Stack Overflow visits and question volumes, particularly in areas where ChatGPT performs well. Reddit communities did not show the same decline, which provides some control for a broader fall in online activity. They also found that the reduction in Stack Overflow participation was concentrated among newer users.

Junzhi Xue and colleagues reached a similar conclusion in research published in Information Systems Research in May 2026. They found that the introduction of large language models reduced question volume by about 14% on average, with larger declines over time. The effect was stronger for lower quality content and among less experienced users.

These studies do not prove that AI caused the entire collapse in Stack Overflow activity. They do show a consistent pattern across different analyses: newer and less experienced users are among those most affected. All three sources also concern the same platform, which limits how broadly the finding can be applied.

The labour market provides another relevant signal, although it does not establish causation. US employment in computer systems design and related services fell from 2,470,700 in July 2023 to 2,366,400 in July 2026, a decrease of 104,300 jobs, or 4.2%. The Bureau of Labor Statistics data does not attribute that decline to AI, and there is no basis for doing so here.

The more important issue for founders is what happens when the traditional apprenticeship route becomes less accessible. Junior developers have historically learned by working on real problems, asking questions and getting feedback from more experienced engineers.

Some of that learning once happened in public communities such as Stack Overflow. If those communities are quieter and junior opportunities are also becoming harder to find, companies may have to provide more of that apprenticeship themselves. The learning pipeline has not necessarily disappeared. More of its cost may simply have moved inside the company, turning what was once a largely public learning system into a direct hiring and training expense.

Do the big developer surveys agree with each other?

On AI adoption, the major developer surveys are remarkably consistent. On trust, they are much less positive. That gap is more informative than the adoption figures themselves.

Stack Overflow, JetBrains and DORA used very different samples in their 2025 surveys. Stack Overflow found that 84% of respondents were using or planning to use AI tools in their development process. JetBrains surveyed 24,534 developers across 194 countries and found that 85% regularly use AI tools for coding and development, while 62% rely on at least one AI coding assistant, agent or code editor. DORA surveyed nearly 5,000 technology professionals and found that 90% use AI at work.

The surveys differ in their sampling and methodology, but their adoption figures fall within a relatively narrow range. AI use among developers is no longer an emerging behaviour that needs to be established. It is already widespread.

Trust tells a different story. DORA found that 30% of respondents had little or no trust in AI generated code. Stack Overflow found that 46% of developers distrust the accuracy of AI tools, compared with 33% who trust them. Only about 3% reported having high levels of trust in AI output. At the same time, positive sentiment towards AI fell from more than 70% in 2023 and 2024 to 60% in 2025, even as adoption increased.

Experience makes the gap wider. Stack Overflow found that experienced developers were the most cautious, with only 2.6% reporting high trust and 20% reporting high distrust. That aligns with the Science study's finding that experienced developers can benefit more from AI while also suggesting that they are less willing to accept its output without scrutiny.

There is no contradiction in that combination. A developer can find an AI tool highly useful while still believing that its output needs careful review. In fact, lower trust among experienced developers may reflect better calibration. They have more knowledge of the code, more awareness of failure modes and more ability to recognise when an apparently plausible change is wrong.

The surveys also have an important limitation. Stack Overflow, JetBrains and DORA all operate within the broader developer technology market, so a shared incentive to emphasise widespread AI adoption is worth acknowledging. Their findings on distrust, falling sentiment and incomplete workflow integration provide some counterweight to that incentive.

AI agents are also not yet as widely adopted as simpler AI coding tools. Stack Overflow found that 52% of developers either do not use agents or continue to use simpler AI tools, while 38% have no plans to adopt agents. That result comes from a single survey, so it should be treated as one survey's measurement rather than an established industry figure.

The broader picture is therefore clear. Developers are using AI at very high rates, but widespread use does not mean widespread trust. The tools have become normal long before they have become universally trusted.

Where does the cost show up?

The cost of AI assisted development often appears after the code has been generated. Delivery metrics can show that more work is being shipped, while missing the additional effort required to review, debug and stabilise it.

The 2025 DORA report captures the tension clearly. It found a positive relationship between AI adoption and both software delivery throughput and product performance, while AI adoption continued to have a negative relationship with software delivery stability. Teams can therefore ship more changes without necessarily making those changes safer to release.

The review burden provides one possible explanation. An August 2026 analysis of 33,228 pull requests across the vLLM and SGLang projects found that pull request throughput increased 21 times in vLLM and 17.9 times in SGLang. The authors estimated that bot authored pull requests accounted for less than 0.2% of that growth. The same analysis found comment density increased 4.2 times and 3.8 times respectively. Bots were estimated to explain between 15% and 20% of that increase.

The study also found that review cycles could become much longer. The P90 cycle time reached 16.8 days, compared with a median close to one day. This is an arXiv preprint rather than peer reviewed research, so the figures should be treated as indicative rather than established industry benchmarks.

Developer surveys show why this additional work matters. Stack Overflow respondents identified AI output that is almost correct as their biggest frustration, with 66% reporting it as a problem. Another 45.2% said debugging AI generated code takes more time.

That distinction matters. Completely wrong code is often easy to reject. Code that looks plausible but contains a subtle error can take much longer to understand and fix. AI can therefore reduce the time needed to produce a first version while increasing the amount of human attention required before that version is safe to merge.

The relevant productivity measure is not simply how quickly AI produces code. It is how much human work remains before that code becomes a reliable part of the product.

Does AI assisted code cost more to maintain?

The two strongest studies point in different directions, but they are measuring different kinds of cost.

Michael Tran, Milad Hashemi, Parthasarathy Ranganathan and colleagues analysed 3.52 million production code changes over twelve months. They reported a 5% to 8% increase in compute resource consumption associated with AI generated code. They also identified higher rates of interface and coupling burdens, copy and allocation overheads, and greater use of explicit loops instead of optimised standard APIs.

That study is an arXiv preprint from August 2026. It examines one enterprise codebase and has not yet been peer reviewed, so its findings should be treated as an early signal rather than an established benchmark.

Borg and colleagues tested a different question. In the second phase of their preregistered experiment, participants took the code produced during the first phase and evolved it without AI assistance. They found no significant difference in completion time or code quality. Their Bayesian analysis suggested that any effects from earlier AI use were small and highly uncertain.

The difference matters because maintainability has more than one dimension. Borg's experiment tested whether another developer could understand and modify the code under controlled conditions. Tran's analysis looked at the resources required to run production code over time. Code can be readable and easy for another developer to change while still using more memory or compute than necessary.

The peer reviewed evidence therefore deserves more weight than the preprint. For now, the strongest conclusion is that there is no measured human level maintainability penalty from AI assisted code under the conditions tested. There is also an early signal that AI generated code may carry higher running costs, but that finding comes from a single enterprise codebase and has not yet been independently replicated.

For engineering leaders, the distinction is important. Reviewing whether code is understandable is not the same as checking whether it is efficient in production. AI may perform well on the first question while creating costs that only become visible after the code is running at scale.

What does a code intelligence graph show that a diff cannot?

A diff shows what changed. It does not show everything that change touches. For a founder or reviewer trying to understand future maintenance costs, that second question can matter more.

code-review-graph is one example of this approach. It describes itself as maintaining a persistent map of a codebase so AI coding tools can focus on the parts of the system that matter. The project was created in February 2026 and is actively developed.

The underlying idea matters more than the specific tool. Instead of treating a repository as a collection of files that an AI tool searches whenever it needs context, a persistent code graph records how different parts of the system relate to one another. A question such as "what depends on this interface?" can then become a traversal through those relationships rather than a search across individual files.

That distinction becomes important when AI generated code changes interfaces or introduces new dependencies. A developer who cannot see those relationships may produce code that works locally while creating additional coupling elsewhere in the system. A graph can make that wider impact visible before the change becomes someone else's maintenance problem.

The same principle applies to AI coding agent audit trails. The final diff tells a reviewer what the agent changed. The audit trail can show how it arrived there, which files and tools it used, and what decisions occurred along the way.

For a founder who cannot personally inspect every line of code, the reviewable artifact therefore needs to be larger than the diff. It is the change together with its dependencies and potential blast radius. That wider view is what makes it possible to understand not only what AI built today, but what that decision may cost the engineering team later.

Why do developers keep using tools that measure as slower?

Because developers may be getting value from AI that conventional productivity studies do not measure.

METR's own research highlights the problem. Between 30% and 50% of participants in its follow up said they had chosen not to submit some tasks because they did not want to work on them without AI. These were the same developers whose measured completion times were slower when AI was available.

That suggests the tools may provide value beyond the time required to complete a specific task. Developers may use them because they make it easier to begin unfamiliar work, reduce the friction of getting started or make tasks feel more approachable. A timed productivity test can measure how long a submitted task takes. It cannot easily measure the value of making developers more willing to take on the task in the first place.

The public conversation around AI coding has also changed. Monthly English Wikipedia pageviews for the article on vibe coding fell from 407,695 in March 2025 to 45,442 in July 2026, an 89% decline, according to data from the Wikimedia pageviews API.

Interest in the phrase has therefore fallen sharply while AI adoption among developers has continued to rise. That is an important distinction. The technology may be becoming less interesting as a story precisely because it is becoming more ordinary as a tool.

When a technology stops generating headlines but remains embedded in everyday work, its value is no longer necessarily captured by whether it makes a single task faster. AI coding tools may already be moving into that stage. They are becoming part of how developers work, even where controlled experiments show that they do not always make individual tasks faster.

What does this change about who is worth hiring?

It shifts the value of a developer away from producing code and towards deciding what should be built, how it should work and whether a change is safe to ship.

The evidence points in that direction from several angles. If AI can generate 29% of Python functions while overall output increases by only 3.6%, code generation is clearly not the only constraint. If less experienced developers can complete more assigned tasks while early career developers show little gain in deciding what to work on, then knowing what to build becomes more important. If experienced developers become slower on familiar code while review activity increases sharply, teams need more capacity for judgement and verification. If AI adoption increases delivery throughput while reducing delivery stability, someone still has to decide when a change should be rolled back.

Those are judgement problems. Better models may reduce the amount of code humans have to write, but they do not eliminate the need to decide whether that code is appropriate. In some cases, producing more AI generated code makes that judgement more important because there is simply more output to review.

This changes how founders should think about junior hiring. The evidence does not suggest that companies should stop hiring junior developers. It suggests that one of the traditional ways juniors developed into stronger engineers has become less reliable. Public technical communities once provided a place where inexperienced developers could ask questions, receive corrections and gradually build expertise. If that apprenticeship now happens less often in public, companies have to provide more of it themselves.

Hiring a junior and assuming that experience will somehow arrive through the wider internet is therefore a weaker strategy than it was several years ago. A company hiring juniors needs to be prepared to create the feedback loop that turns them into capable engineers.

That makes depth of vetting more important, particularly when AI has made code generation easier. RocketDevs, for example, says it assesses developers for 6 to 8 hours and rejects more than 98% of applicants, with its published pricing starting at $9.99 per hour. The relevant question is no longer simply whether a developer can produce code quickly. It is whether they can understand the consequences of a change, recognise when AI output is wrong and exercise enough judgement to know when something should not be shipped.

The same principle applies when hiring specifically for AI engineering. The skills required can differ from those of a conventional software engineering role. Responsibility also remains with the people and organisations deploying the system when an AI agent makes a damaging production change.

A trial period is therefore more informative than a hiring decision based entirely on interviews or claims about technical quality. Testing a developer on your own codebase gives you a chance to see how they reason about unfamiliar problems, review AI generated work and respond when the first solution is not the right one.

If the scarce resource is no longer code generation, the hiring advantage belongs to teams that can identify good judgement before they make the hire.

Conclusion

The real question is not whether AI will replace software developers. It is what happens when writing code becomes cheaper than deciding what code should exist.

The evidence points in the same direction. AI adoption is already widespread, yet its productivity benefits vary sharply by task and experience. It can help developers complete assigned work faster, but it can also make experienced developers slower when they are working in codebases they already know. As more code is generated, review and reliability become more important.

That changes what companies should value when hiring. The developer who produces the most code is not necessarily the most valuable. The scarce skill is judgement: knowing what to build, understanding what a change will affect and recognising when AI has produced something that should not be shipped.

This does not mean companies should stop hiring junior developers. It means they need to take responsibility for their development. As public developer communities have become quieter, the apprenticeship that once happened there increasingly needs to happen inside the company.

For founders, the hiring lesson is simple: do not hire for typing speed in a world where machines can type faster. Hire for judgement.

AI is making code cheaper. That makes good engineering judgement more valuable, not less.

Frequently asked questions

1. Will AI replace software developers in 2026?

No. The strongest available evidence points to a changing role rather than the disappearance of software developers. AI is estimated to write 29% of Python functions in the US while overall output increased by 3.6%. Three major developer surveys put AI adoption between 84% and 90%. At the same time, human developers still authored more than 99.8% of pull requests in a large observational study, even as throughput increased sharply.

2. Does AI make developers more productive?

It depends on what is being measured and whether the developer already knows the codebase. Randomised trials at Microsoft and Accenture found a 26.08% increase in completed assigned tasks. A Google trial involving 96 engineers found that AI reduced completion time by about 21% on an unfamiliar enterprise task. METR found that experienced developers working on repositories they already maintained took 19% longer with AI.

These results are not necessarily contradictory. They measure different types of work under different conditions. AI appears more useful when developers need help figuring out how to complete an unfamiliar task. It can be less useful when experienced developers already understand the system and must spend time reviewing its suggestions.

3. Does AI help junior or senior developers more?

The two strongest studies disagree. Management Science found that less experienced developers gained more in terms of completed tasks. Science found that senior developers benefited while early career developers showed no significant gain, particularly when it came to expanding into new areas of software development.

The most plausible explanation is that AI helps when the main difficulty is knowing how to implement something. It offers less help when the harder problem is deciding what should be built or what is worth attempting.

4. Should I still hire junior developers?

Yes, but with a different assumption about training. Research has found that the decline in public developer question and answer activity has been concentrated among less experienced users. New Stack Overflow questions fell from 110,788 in July 2022 to 1,394 in July 2026.

The free apprenticeship that once happened through public developer communities has therefore become much less reliable. Companies hiring junior developers may need to provide more of the mentoring, feedback and practical learning that previously happened in public.

5. Is AI generated code more expensive to run or maintain?

These are separate questions, and the evidence differs for each. A peer reviewed experiment involving 151 participants found no significant difference in how easily developers could later evolve code that had been produced with AI assistance.

A separate August 2026 preprint analysing 3.52 million production code changes reported a 5% to 8% increase in compute consumption associated with AI generated code. It also identified structural costs including additional coupling and unnecessary copies. That study has not been independently replicated.

The current evidence therefore does not show a measured human maintainability penalty under the conditions tested. It does suggest that AI generated code may carry additional machine running costs, but that finding remains preliminary.

6. Do developers trust AI generated code?

Mostly not, and trust appears to be falling even as adoption rises. DORA found that 30% of respondents reported little or no trust in AI generated code. Stack Overflow found that 46% of developers distrust the accuracy of AI tools, compared with 33% who trust them. Only about 3% reported high levels of trust.

Positive sentiment towards AI also fell from more than 70% in 2023 and 2024 to 60% in 2025. The most experienced developers were the most sceptical. That does not necessarily mean they find AI less useful. It may mean that developers with more experience are better at recognising when generated code needs to be questioned, tested or rejected.

That is the honest case for vetting depth rather than a slogan about quality. We run 6 to 8 hours of assessment per developer against a 98%+ rejection rate and a Top 2% acceptance bar, starting at $9.99/hr. The process is not looking for people who produce code quickly, because that is no longer scarce. It is looking for people who can tell you what a change will break.

The 14-day money-back trial exists so you can test that on your own codebase rather than take it on faith. Start with a vetted developer.

Sources

• Simone Daniotti, Johannes Wachs, Xiangnan Feng, Frank Neffke, Who is using AI to code? Global diffusion and impact of generative AI, Science, 22 January 2026. 30 million+ commits, 160,097 developers.
• Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng, Tobias Salz, The effects of generative AI on high-skilled work: evidence from three field experiments, Management Science, 27 February 2026. Three RCTs, 4,867 developers.
• Elise Paradis, Kate Grey, Quinn Madison and colleagues, How much does AI impact development speed? An enterprise-based randomized controlled trial, ICSE-SEIP 2025. 96 Google engineers.
• Markus Borg, Dave Hewett, Nadim Hagatulah and colleagues, Echoes of AI: investigating the downstream effects of AI assistants on software maintainability, Empirical Software Engineering, 9 June 2026. 151 participants, preregistered.
• METR, Measuring the impact of early-2025 AI on experienced open-source developer productivity, 10 July 2025, and We are changing our developer productivity experiment design, 24 February 2026.
• Gordon Burtch, Dokyun Lee, Zhichen Chen, The consequences of generative AI for online knowledge communities, Scientific Reports, 6 May 2024.
• Junzhi Xue, Lizheng Wang, Jinyang Zheng, Yongjun Li, Yong Tan, Can ChatGPT kill user-generated Q and A platforms?, Information Systems Research, 21 May 2026.
• Stack Overflow Developer Survey 2025, AI section.
• JetBrains, The State of Developer Ecosystem 2025. 24,534 developers, 194 countries.
• DORA, Announcing the 2025 DORA report. Nearly 5,000 technology professionals.
• Stack Exchange API, monthly new-question counts for Stack Overflow, queried 18 August 2026.
• US Bureau of Labor Statistics, series CES6054150001, all employees in computer systems design and related services, retrieved through the BLS public API on 18 August 2026.
• Wikimedia pageviews API, monthly English Wikipedia pageviews for vibe coding.
• Jiada Li, Xuesong Ye, Olamide Olowoniyi, Engineering signals of human-AI collaboration in the agentic coding era, arXiv preprint, 14 August 2026.
• Michael Tran et al., Characterizing the quality profile of AI-generated C++ in production, arXiv preprint, 6 August 2026.
• code-review-graph, repository metrics via the GitHub API, accessed 18 August 2026.

James Hitch, COO at RocketDevs