AI coding agents can now plan, edit, and test their way through a codebase with little supervision. Yet most developers still keep them on a short leash. Part of the reason has nothing to do with what agents can do. It is about what they might cost. In SlashData's Q3 2026 AI Developer Tools Benchmark, a third of professional developers (34%) say that difficulty estimating cost before a task runs limits how much autonomy they give AI agents. That makes unpredictable cost one of the three most common brakes on agentic development, in a market where only 7% of developers say nothing holds them back. And it is landing just as the pricing models behind these tools are being rewritten. The flat fee is giving way to the meter In the space of a few months, the leading vendors have moved agentic coding towards usage-based pricing: OpenAI moved Codex usage on ChatGPT plans from per-message limits to token-based credits on 2 April 2026. Anthropic briefly tested removing Claude Code from its $20 Pro plan for a small share of new sign-ups in April, reversing the change within a day after developer backlash. Explaining the test, the company said that "usage has changed a lot and our current plans weren't built for this." GitHub moved every Copilot plan to usage-based billing on 1 June 2026, replacing premium request allowances with a monthly allotment of GitHub AI Credits that paid plans can top up. Cursor went through a similar transition a year earlier, when its June 2025 switch to usage-based pricing ended in an apology and refunds. The logic is easy to follow. A code completion is a small, bounded request. An agent working through a multi-step task reads files, calls tools and reruns tests, and the cost grows with every step. Flat subscriptions were not built for that. Metered pricing aligns what users pay with what vendors spend, but it also moves the uncertainty from the vendor's balance sheet to the developer's. What developers told us The three most common barriers to agent autonomy: risk of agents accessing secrets or sensitive systems (40%), too many concurrent changes for humans to review effectively (36%) and difficulty estimating cost before a task runs (34%). Base: 2,040 professional developers using AI developer tools in agentic modes. Source: SlashData AI Developer Tools Benchmark (Q3 2026). When asked which factors currently limit how much autonomy developers are willing or permitted to give AI agents, the three most common barriers have one thing in common: each is about control, not capability. Developers are not saying agents cannot do the work. They are saying they cannot yet bound what an agent will touch, how much it will change, or what it will spend. Until they can, the rational response is to keep a human in the loop: approve each step or review at checkpoints, narrow the scope, stop the run early. Uncertainty about cost turns directly into less autonomy. It would be easy to assume this only worries developers paying out of their own pocket. It does not. Most users of the leading tools have company-paid access, but a company-funded budget is still a capped one. In SlashData's interviews with engineering leaders, a common pattern emerged: teams allocate a fixed amount of tokens to each developer, developers often run out before the period ends, and securing more is a struggle. Whoever pays, the developer is the one who has to decide whether a task is worth the spend before letting an agent run with it. The same concern shows up when developers think about leaving a tool. 15% say that lower or more predictable cost would be enough to make them move most of their work to another AI developer tool in the next six months. Output quality remains the bigger trigger, but most developers already use more than one tool, so moving work elsewhere takes little effort. The wider warning sign This is not only a developer-tools problem. Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value, or inadequate risk controls. The common thread is that a cost nobody can forecast is a cost that is hard to defend in a budget review, no matter how good the output. For engineering leaders, an agent that might finish a task for a little or for a lot is harder to approve than a slower tool with a known price. Predictability is a product feature For vendors, the implication is that pricing is no longer just packaging. It is part of the agent experience. Developers will hand more work to agents when they can answer three questions before pressing go: roughly what will this task cost, what is the most it can cost, and what did it actually cost once it finished? That points to capabilities that are as much about trust as about billing: Pre-run estimates, so a developer can see the likely cost of a task before an agent starts. Hard caps per task, per developer and per team, so a runaway session stops instead of surprising someone at the end of the month. Clear warnings before limits are hit, rather than a session that simply halts mid-task. Usage reporting that ties spend to outcomes, so engineering leaders can defend the budget. With the largest vendors moving to metered pricing, the question now is who makes the meter easiest to read. In a market where, as our benchmark shows, the leading tools are closely matched on satisfaction and productivity, the vendor that makes agent costs predictable may find that developers give its agents more room to work and use them more as a result. These findings come from SlashData's AI Developer Tools Benchmark (Q3 2026), a survey of 2,063 professional developers who use AI developer tools, benchmarking 19 tools across adoption, satisfaction, productivity, trust and agent autonomy. Find out more about the full report.

The return depends on developers' experience, and the bill lands on junior hiring AI has permeated software development, and the vast majority of developers now use it to support their coding workflows. According to SlashData’s Developer Nation Q1 2026 survey, the most common use case is using AI chatbots to answer coding questions (53%). Crucially, 42% of developers use AI-assisted development tools or agents directly integrated into their coding environment, a significant jump from 30% in the Developer Nation Q1 2024 survey. Other activities, like adding AI functionality to apps (22%), building models (9%), or fine-tuning hyperparameters (8%), remain less common. This piece focuses on that 42%, and reports on how the return on these integrated tools is measured, and who actually delivers it. Leadership measures AI by time saved: 40% cite it first Let’s start with the view from the top of software engineering organisations. Leadership is convinced. Among developers in leadership roles (such as VP or CTO) who use AI tools, 75% report that the benefits of AI are greater than the cost of effort, against 5% reporting that the cost of effort is greater than the benefits. The most cited ROI metric for AI is ‘time saved or improved productivity’ at 40%, closely followed by ‘improved quality of output’ at 38%. The question is whether developers report on those KPIs, and whether every developer reports the same. Chart 1. How developers in leadership roles measure AI ROI. Extract from The state of AI ROI measurement in software teams (p.17), Developer Nation Q1 2026. Base: 2,341 developers in leadership roles. Code quality improves for 7 in 10 developers, time saved divides them 7 in 10 developers report better code quality. Asked to what extent using AI-assisted development tools changed their workflow, 70% of respondents declare that it has either greatly or somewhat increased the quality and consistency of their code, against 10% declaring a decrease. On time saved, developers divide. 49% declare that these tools have either greatly or somewhat decreased their time spent on repetitive tasks, against 38% declaring an increase. A second measure of time shows the same division. On time spent reading documentation or forums, 40% declare a decrease and 40% declare an increase. So the two KPIs part company. Quality of code improves across the board. Time saved is close to a wash. Something inside that average is worth looking at, and seniority is one answer. Chart 2. Effect of AI development tools on developer workflow. Extract from How developers work with AI development tools (p.27), Developer Nation Q1 2026. Base: 4,346 developers who use AI development tools. AI saves time in proportion to seniority: 62% of the most experienced report gains An average close to zero can be made of two cohorts pulling in opposite directions. That is what is happening here. Repetitive tasks: 2 in 3 seniors report saving time, against 2 in 5 juniors. Among developers with 0-2 years of experience, 42% declare that AI-assisted development tools have greatly or somewhat decreased the time they spend on repetitive tasks, against 44% declaring it has greatly or somewhat increased. Among developers with 16+ years of experience, 62% report a decrease against 25% reporting an increase. Same tool, opposite outcomes. The variable is the developer holding it. Documentation: 1 in 2 seniors report saving time, against 1 in 3 juniors. On time spent reading documentation or forums, 32% of the 0-2 cohort report a decrease against 48% reporting an increase. For the 16+ cohort the figures reverse, at 51% against 26%. Here too, the share reporting a decrease in time spent rises steadily with years of experience. AI shortens the search for developers who already know what they are looking for. A clear majority of the most experienced developers report gains on both time measures. Among the least experienced, roughly as many report spending more time on repetitive tasks as report spending less. On documentation, the balance tips towards spending more. On the KPI leadership cites most, time saved, AI appears to pay out in proportion to the hands-on experience brought to it. Chart 3. Reported change in time spent on repetitive tasks (left) and reading documentation or forums (right), by years of experience. Read the full analysis in How developers work with AI development tools, Developer Nation Q1 2026. Base: 4,203 (repetitive tasks) and 4,200 (documentation) professional developers who use AI developer tools. Talent debt accrues quietly: junior developer hiring in the US sits 20% below trend If the return on AI is delivered by experience, a business case built on time saved quietly favours senior hiring over junior hiring. The Stanford University AI Index for 2026 (p. 222) may already show the shape. Measured against the headcount each cohort would have reached had hiring continued at its pre-AI pace, employment of 22-25 year old software developers in the United States sits 20% lower since 2022, while the 41-49 bracket sits 15% higher. If that divergence continues, experienced developers become invaluable, while the current generation of young graduates risk becoming unhirable. The return is conditional. What AI pays out depends on what the developer brings to it, and that is acquired by doing the work over years. With junior headcount already thinning, the experience mix that produces today's AI ROI may not be the one organisations are working with in a few years. The avoided cost behaves like a loan. The principal is the junior salary not paid today. The interest is what a scarce senior hire costs in five years, in a market where every competitor is short of the same profile. It would not fall due this quarter. It would fall due the first time a senior developer leaves with no internal successor. SlashData tracks these patterns across every wave of Developer Nation. Get in touch to discuss what the full dataset shows.

Key takeaways SlashData is launching SlashData Intelligence for Software Engineering Leaders, a recurring research programme for CTOs, CPTOs, CEOs, VPs and SVPs of Engineering. Each Developer Nation wave will examine a major decision facing engineering organisations, combining open-access research with deeper premium intelligence. The first release explored AI ROI measurement. The next will investigate the future of developer teams, combining quantitative evidence with recurring interviews with software engineering leaders. Readers can follow the research, speak directly with SlashData analysts, and help shape future topics. Internal telemetry cannot tell you where the market is Engineering leaders are confident about AI. Their evidence is thinner than their confidence. The questions facing software engineering leaders are becoming harder to answer from inside their own organisations. Which AI investments are actually delivering value? How should that value be measured? How will AI change the structure of development teams? Which skills will become more important? Where are other engineering organisations investing, experimenting or pulling back? Internal metrics can answer part of this. Vendor information can answer another part. But leaders also need an independent view of what is happening across the software industry and how their organisation compares. That is the idea behind SlashData Intelligence for Software Engineering Leaders: a recurring research programme designed around the decisions senior engineering leaders are being asked to make. SlashData has been studying developers and the software economy for 20 years. The Developer Nation survey provides a global view of how software is built, which technologies developers adopt and how practices change over time across more than 10 different technology branches. Each wave reaches more than 10,000 developers worldwide, with its 31st edition alone reaching more than 11,880+. This new intelligence series takes that evidence and focuses it specifically on the questions that matter at the engineering leadership level. Explore SlashData Intelligence for Software Engineering Leaders The first question: can engineering organisations prove AI is paying off? The first research release examined a question that has quickly moved from experimentation to the boardroom: how do organisations know whether their AI investments are delivering? The free report, The AI ROI Measurement Gap, and the deeper premium report, The State of AI ROI Measurement in Software Teams, analysed responses from 2,341 professional developers in leadership positions. The findings revealed an important distinction between confidence and evidence. According to SlashData's 31st Developer Nation survey of 2,341 professional developers in leadership positions, 80% use AI-assisted tools and 75% of those consider them valuable relative to cost and effort. Our data suggests that although 88% say their organisation measures AI impact or ROI, only 39% of those measuring use formal or automated processes such as recurring KPI tracking, dashboards or automated monitoring. The accompanying webinar explored what that gap means for engineering leaders trying to justify investment, compare their measurement maturity with peers, and build an ROI case that finance and executive leadership will accept. This is the role the new series is intended to play: helping leaders understand where the market actually is, what separates common practice from more mature practice, and what that means for their next decision. The next wave: how AI is changing team size, structure, and roles The next research wave will turn to a broader organisational question: the future of developer teams. AI is changing more than individual workflows. Engineering leaders are now considering what it means for team size, role composition, seniority, governance, validation, productivity expectations and the capabilities their organisations will need over the next several years. SlashData will examine these changes using large-scale Developer Nation survey data alongside recurring qualitative interviews with software engineering leaders. The aim is to connect measurable shifts across the market with the reasoning behind the decisions leaders are making inside their organisations. The research will explore questions such as how AI may reshape team structures, which engineering skills and roles are likely to become more important, how organisations are balancing automation with review and governance, where junior developers fit in the process, and how expectations of software teams are changing. One research wave is not enough The value of this product line is intended to compound over time. Each Developer Nation wave will bring a new topic relevant to senior engineering leadership, with open-access findings alongside deeper premium intelligence, supported by formats such as webinars, analyst briefings, blogs, or other content. Over successive waves, that creates something more useful than a collection of standalone reports: a continuing view of how engineering organisations are responding to AI and the wider changes reshaping software development. For leaders making decisions in a market that is moving quickly, the goal is simple: provide an independent benchmark outside their own company, their vendors, and their immediate peer group. Learn more about SlashData Intelligence for Software Engineering Leaders If your organisation is currently making decisions around AI investment, engineering productivity or the future structure of software teams, speak directly with SlashData’s sales team and analysts. And the research agenda itself is open to input. If there is a question you think software engineering leaders need better independent evidence on, suggest a topic for a future research wave.

Key takeaways 79% of developers adding AI functionality to their applications use open models, ahead of 71% for closed models. The two are largely complementary. Half of developers use both at the same time, while 29% use only open models, and 21% use only closed models. The production gap: only 51% of developers using open models run them in production, compared with 63% for closed models. Production rates for closed models climb steeply with organisation size, from 54% at small businesses to 73% at large enterprises. Rates for open models barely move, from 53% to 57%. What developers using open models actually struggle with: deployment, scaling, maintenance Among developers adding AI functionality to their applications, more use open models today than closed ones, 79% against 71%. However, open models lag in production. Only 51% of developers using open models run them in production, compared with 63% for closed models, and open models trail slightly at the pilot stage as well (60% vs 65%). Developers are ready for open models, but the ecosystem around them may not be. According to the global survey that SlashData and Mozilla ran together in May 2026, covering 1,494 developers adding AI functionality to their applications, open models are the most widely used of the two families. It is important to note, though, that for many developers this is not a choice between one and the other: 50% of developers use both, while 29% use open models only, and 21% use closed models only. Adoption of open models is highest in Greater China and East Asia, at 89% each, against a global average of 79%. However, production rates for open models (51%) are noticeably lower than for closed models (63%). The data reveals that model performance is not what explains the difference, as it ranks among the least cited challenges for developers using open models. Some of the most common difficulties reported are the complexity of deployment and scaling, ongoing maintenance and updates, and managing the infrastructure and its costs. All of these point to the operational side rather than the models: the burden of owning the stack. That ownership brings real benefits, but it also introduces a set of problems that a hosted API absorbs on the developer's behalf. Additionally, SlashData found that, among professional developers, production rates for closed models climb steeply with organisation size, from 54% at small businesses (2 to 50 employees) to 73% at large enterprises (1,001 or more). For open models, however, production rates remain relatively flat across organisation sizes (from 53% to 57%). Open models lead on adoption, 79% against 71%, but reach production less often, 51% against 63%. Production rates for closed models climb with company size, from 54% at small businesses to 73% at large enterprises, while open models stay flat, 53% to 57%. SlashData and Mozilla global survey, May 2026, 1,494 developers adding AI functionality to their applications; the company size split is based on 954 professional developers. The next gains sit around the model, not inside it If the barrier were resources or in-house expertise, large enterprises would show the same lift for open models that they show for closed ones. They do not, which suggests this is not a gap that individual organisations can buy their way out of. For open model providers, foundations and tooling vendors, that flat line is the finding to act on. The demand side is already there: 79% of developers adding AI functionality to their applications are using open models. The loss happens further down the funnel, between working with a model and running it in production. The work likely to move production rates for open models sits around the model rather than inside it: the harness, hosting and serving infrastructure, upgrade and versioning paths, and better tooling. These map closely onto what developers using open models report as their main challenges, while model performance ranks among the least cited. Based on the data from this survey, those areas are likely to shift production rates further than additional gains in model quality. Commission your own research Need data-backed insights for your next thought leadership report?

The 32nd Developer Nation survey is now in the field, gathering insights from more than 15,000 software developers worldwide. Here are some of the key trends and insights you can expect from SlashData in Q3 2026, including builders, developer productivity, cloud adoption, and the future of software development. Meet the builders: shipping software without a developer background The biggest change on our 32nd wave is the onboarding of “builders” into our survey, a new group we’re tracking for the first time. Builders are people without traditional developer experience or backgrounds who are using AI tooling to build applications or services. As we discussed in our whitepaper, we’re looking at those building for personal use, those augmenting their internal workflows, and those building consumer-facing applications. Builders represent an emerging segment of the wider developer ecosystem rather than a replacement for traditional software developers. SlashData will be able to provide a picture of who these people are, how they engage with AI tools and the ecosystem, how AI has changed their working lives, and where they overlap with the traditional developer audience. How AI is reshaping the day-to-day Beyond builders, this research wave also digs into how AI is changing the way existing developers work. Spec-driven development, where developers define detailed requirements, constraints, and expected outcomes before AI-assisted code generation, is one of the new “buzzwords” being pushed to describe this shift. Our research will provide a clearer read on how prevalent the approach actually is, and for those doing it, what goes into their specs and how they feel about the approach philosophically. There’s also a lot of talk about the developer role shifting from writing code to reviewing it. It’s unlikely many developers dreamed of reviewing code all day, so SlashData is aiming to understand how prevalent AI code review really is, and who’s sending developers this AI-generated code (other developers, management, non-developer staff), and whether they integrate it, correct it, or scrap it outright. The future of developer teams: skills, seniority, and the junior developer squeeze With so much focus on how AI is reshaping developer life, we’re asking developers directly where they think the future of development teams is going: what skills they expect to matter, how they feel the current implementation is going, and the impact on junior and emerging developers. Combined with expanded developer wellbeing metrics, the aim isn’t just to say where developers think the future is heading, but how they’re feeling as they cruise towards it. Why DORA metrics stop short of developer productivity Where the future-of-teams work captures what developers predict and feel, SlashData is also going deeper on how effectiveness itself gets measured. This wave continues our move into metrics that extend beyond traditional DORA software delivery metrics, looking at what actually drives developer productivity, happiness, and effectiveness within organisations — split across organisational practices and benefits, and the value and meaning developers draw from their work. The goal is a wider, more holistic understanding of what it means to be an effective, happy developer, not just a faster one. Tracking the technology developers rely on: cloud provider preference and on-device AI SlashData continues to track the technologies developers use and integrate release over release, and this wave adds two areas we see as important drivers of where things are headed. Small, on-device models have fallen out of the spotlight as large open-weight models capture media attention (such as DeepSeek and Moonshot AI’s Kimi K3), but for many analysts, on-device AI is where the future of LLMs actually lies, so we’re assessing its scale in 2026 and asking developers where they see the best use cases emerging. Alongside this, we’re interrogating cloud provider preference across application types (including AI agents and generative AI services, alongside web/mobile applications, data analytics, CDNs, and serverless), aiming to sidestep vendor benchmarks and spec-sheet marketing in favour of what developers actually choose when given a free hand. Want early access? Reach out to the SlashData team, a leading research firm focused on the developer economy, to flag which of these you’d like to hear about first, or to make sure you’re kept in the loop when the data lands.

You don’t need another AI hype post, so I will keep the intro part short and sweet. Too sweet, actually, because I will be sharing the freshest possible data from the 31st wave of our independent survey, which reached more than 11,500 respondents from 95 countries around the world. Based on the findings, we produce a 6-piece report series that delves into key developer trends for Q1 2026 and beyond. They're all free and available here, btw. In this post, we’ll look at 2: AI in the Developer Workflow The AI ROI Measurement Gap AI in the Developer Workflow Generative AI has entered the developer toolkit, but how deeply has it actually embedded itself into the work? This report examines how developers are using AI across their workflows: which tasks they are turning to AI for, how much of each task they are willing to hand over, and where the gap between adoption and reliance reveals the limits of current tooling. Code generation is the most widely used AI-assisted task, with 49% of developers using AI for it, yet fewer than half of those are letting AI handle the majority of the work. Drawing on survey data from developers actively using AI-assisted software development tools, the findings move beyond headline adoption figures to examine the texture of AI use across more than a dozen distinct development tasks. The result is a more honest picture of where AI is genuinely accelerating developer work, where it has found a willing audience for tasks developers are happy to offload, and where capability gaps are suppressing the trust needed for deeper reliance. For organisations evaluating or expanding AI tool adoption, the data offers a practical lens for calibrating expectations, informing governance, and identifying where human oversight remains essential. For those building the next generation of AI developer tools, it maps the frontier clearly: the tasks with high demand and low trust are not side thoughts; they should be the roadmap. Key Questions Answered in the AI in the Developer Workflow report What tasks are developers using AI tools to assist them with? How much of each task are developers handing over to AI tools? Which tasks do developers trust and rely on AI tooling for? Which tasks are the current suite of AI tooling falling short? The AI ROI Measurement Gap Artificial intelligence (AI) has long been embedded in technology organisations, powering systems such as search engines, recommendation algorithms, and fraud detection tools. However, it is now far more visible and strategically prioritised, with generative AI chatbots, coding assistants, and enterprise automation tools bringing it to the centre of business planning. As AI investment scales, a new pressure is emerging: the need to justify it. Boards want evidence, finance teams want numbers, and developers caught in the middle are discovering that believing AI works and being able to prove it are two very different things. The vast majority (80%) of developers in leadership roles (technology leaders) are using AI-assisted tools, and 75% rate them as valuable. This report examines how developers in leadership roles – hereinafter referred to as technology leaders – are experiencing and evaluating AI value today. We examine how they rate what it delivers, whether they measure it, and how rigorous those measurements are. The findings are drawn from 2,341 professional developers working in leadership positions in SlashData’s 31st global developer survey. This report provides an overview of the headline findings. For a full deep dive, including breakdowns by role, sector, region, and agentic AI maturity level, see the full report, The state of AI ROI measurement in software teams. Key Questions Answered in the AI ROI Measurement Gap What share of technology leaders are using AI-assisted tools? What share of those using AI-assisted tools are measuring their value or ROI? How is the AI ROI structured in terms of maturity, and how does that differ based on company size? How does AI ROI maturity level affect technology leaders’ evaluation of AI assistance? About the author Stathis Georgakopoulos, Head of Marketing at SlashData Stathis leads product marketing and loves building helpful content that turns complex research into practical decisions. He focuses on setting the table for launches and campaigns, and has a soft spot for content marketing.

This is a transcript with the key highlights from the live webinar on software development Q1 2025 trends. You can watch the full presentation in the following video. Natasa Ljikar:  Welcome to today’s session. We’ll be going over insights on developer tools usage and measuring AI tools ROI. SlashData is a technology-focused analyst firm exploring the broader software development space as well as evolving AI technologies. The data we’ll be discussing comes from SlashData’s biannual Omnibus Global Developer Surveys, specifically the latest Q1 2026 Developer Nation survey . In addition to the topics we’re covering today, the survey also explores cloud, mobile, web, games, and other areas, capturing a snapshot of the broader software development ecosystem. The survey has a global reach, with over 12,400 valid responses from software developers in 95 countries . I’d like to pass the mic to Bleona Bicaj , Principal Research Consultant and Product Strategist at SlashData. The state of AI in software development in Q1 2026 Bleona Bicaj:  Today I’ll be sharing data about the state of AI and development. Over the past two years, AI has transformed from a technology developers were curious about into something embedded in the everyday workflows of the majority of professional developers. But using AI and quantifying its benefits are two very different things. That’s one of the things we wanted to explore in the most recent wave of our Developer Nation survey. I’m going to walk you through two separate research findings that paint a picture of where the developer community stands right now with AI, both in terms of what they’re actually doing with these tools and whether they can prove that these tools are working. By the end of this webinar, you’ll have three key takeaways: a clear picture of AI adoption among professional developers, evidence about the measurement gap that most organizations are facing, and an introduction to a new benchmarking product that directly addresses the questions technology leaders are asking about AI developer tools. AI adoption among professional developers This first report comes from our latest Global Developer Survey, where we asked over 10,000 professional developers  a straightforward question: Do you use or work with ML, AI models, tools, APIs, or services? And if so, in which of the following ways? The data gives us a clear snapshot of where the market stands right now. The majority of professional developers ( 75% ) are using AI-assisted tools in some form, and almost half ( 45%)  are adding AI functionality or developing AI models. Within that 75% using AI-assisted tools, there are three distinct ways developers are engaging with AI, and they represent fundamentally different relationships with the technology. First, 53%  of professional developers use AI-assisted tools outside the coding environment, such as AI chatbots or agents like ChatGPT, Claude, or other LLMs integrated into their workflow to get answers to coding questions. This is lightweight, low-friction adoption. Developers are not building with AI; they are mainly consulting with it. Second, 42%  of these developers are using AI-assisted development tools or agents integrated into the coding environment itself. We’re talking about GitHub Copilot, JetBrains AI, Amazon Q Developer — tools that live in the IDE, understand the code base, and surface suggestions in real time. This is a deeper level of integration because the AI is no longer just a side tool, but part of the development loop. Third, a quarter of developers are using AI tools to generate creative assets for projects such as images, diagrams, documentation, or other non-code assets. This is more niche, but it signals that AI is being used not just for code generation, but for the full spectrum of what goes into shipping software. Now, 45%  of developers report either adding AI functionality to their applications or developing AI models and infrastructure. That’s a different category entirely because these developers aren’t just using AI as a productivity tool; they’re actually building with it. Within this group, we also see another split. Around a third of developers are adding AI functionality to their applications either through fully managed AI services or APIs, or self-managed local AI models. Here, they’re leveraging the service provider’s model. They’re not training or hosting their own. This is fast, managed, and abstracts away a lot of infrastructure complexity. The remaining developers represent increasingly specialist activities such as customizing pre-trained AI models and fine-tuning hyperparameters. These are the developers building the foundation that the first group of tool users depend on. For the purposes of today’s discussion, we’re going to focus on this first, largest group: developers using AI-assisted tools, because this is the group experiencing the most immediate pressure to justify investment, the group most likely to be affected by organization-wide decisions around AI tooling, and the group we’ll be diving into with our new benchmarking product. The 75%  using these tools represent the market we need to understand in detail. Before we dive into those results, I want to show how we got to this adoption level. This chart tracks developer involvement with AI over the past two years, from Q1 2024 to Q1 2026 . The story is one of consolidation at the top and migration toward more sophisticated use cases. When it comes to using AI-assisted tools, this has grown from 61% in Q1 2024  to 75% in Q1 2026 . That is steady, consistent growth over two years. The trajectory has remained consistently steep, and each quarter we see incremental gains. We’re not seeing a phenomenon of early adopters jumping in and then plateauing. This continuous integration tells us that these tools are sticky and solving real problems for developers. Adding AI functionality or developing AI models also shows an incline. It started at about 32%  two years ago and is now at 45% . The one thing that is declining is the share of developers saying that they don’t use or work with ML, AI models, tools, APIs, or services at all. Two years ago, that was about 28%  of the market, and today it’s down to 12% . The holdouts still exist, but they’re clearly a shrinking minority. Measuring AI ROI This brings us to the second report and the harder question of how technology leaders know that this investment is actually working and bringing productivity gains. AI has long been embedded in technology organizations, either through powering search engines or recommendation algorithms. But something has shifted in the past two years because it’s no longer a background technology. It’s visible, strategic, and expensive. Generative AI chatbots, coding assistants, and enterprise automation tools have moved to the center of business planning. As AI investment scales, pressure is emerging: the need to justify it to the board and to finance. Boards want evidence, finance teams want numbers, and developers caught in the middle are discovering that believing AI works and being able to prove it are two very different things. The second report examines how developers in leadership roles — or technology leaders — are experiencing and evaluating AI value: how they rate what it delivers, whether they measure it, and how rigorous or formal those measurements are in practice. The findings come from more than 2,000 professional developers working in leadership positions , drawn from SlashData’s 31st Global Developer Survey . Today we’re providing an overview of the headline findings. For a full deep dive, including breakdowns by role, sector, region, and agentic AI maturity level, we prepared a more comprehensive premium report called The State of AI ROI Measurement in Software Teams . Since we’re now focusing only on professional developers in leadership roles, I want to set the scene by saying that 80%  of them use AI-assisted tools, which is five percentage points higher than professional developers overall. From that group, 75%  rate AI tools as valuable or extremely valuable relative to the cost and effort required. This is a big number, so it deserves both celebration and scrutiny. On one hand, it reflects a genuine shift in the market. It confirms that AI tooling has become core infrastructure for most software engineering organizations, and the people close to that transition — the engineering leaders using these tools every day — are overwhelmingly positive. 27%  even describe the benefits as far exceeding the cost and effort. But confidence and evidence are not the same thing, and the broader market context makes that distinction urgent. For example, a study from S&P Global  found that the share of companies abandoning the majority of their AI initiatives before reaching production surged from 17% to 42% in a single year . Somewhere between pilot and production, the reality of the work (data quality challenges, integration complexity, and unclear ROI) caught up with the enthusiasm. Gartner  also predicted that at least 30% of generative AI projects  will be abandoned after proof of concept, citing three primary causes: poor data quality, unclear business value, inadequate risk controls. This unclear business value is the issue we’re examining today. When we asked technology leaders directly, “Do you measure the impact or ROI of the AI tools, models, or services that your teams use?” , 88% said yes . On the surface, that’s reassuring. An overwhelming majority is actively tracking AI value, and only 12%  seem to be making decisions about expensive tools based on trial and error. But when you look past this binary of measuring versus not measuring, a more complicated picture emerges. We can see that 39%  of technology leaders who are measuring AI ROI are doing so through formal or automated processes: things like regular KPI tracking, integrated dashboards, and automated reporting systems. This is the gold standard. Metrics are being collected continuously, tracked systematically, and when there’s a question about AI value, the data is already there. Another 41%  describe their approach as defined but manual. They have structure — quarterly reviews, internal surveys, even periodic conversations between developers and engineering leads. There’s a framework, but it depends on someone to trigger it. So when it’s time for the quarterly review, someone organizes the conversation, gathers the feedback, and documents the outcome. It’s rigorous in intent, but episodic in execution. Then we have 17%  operating informally or ad hoc, through occasional discussions and subjective impressions. There’s no consistent tracking. With this, I want to reframe that 88%  headline. Eighty-eight percent of organizations believe they are measuring AI value, but only 39%  are doing so through processes that don’t require someone to initiate measuring. If your organization sits in that manual middle — and many do — it’s worth understanding what this means operationally. Manual measurement, at 41% , often involves structured efforts like quarterly reviews or team surveys. But it also carries structural weaknesses that make it a poor foundation for high-stakes investment decisions like AI tooling. First, it is vulnerable to deprioritization. When delivery pressure rises, when teams are shipping a critical feature or fighting a production issue, quarterly AI review is often the first thing that slips. Measurement cadence breaks down precisely when it’s most needed (during periods of change or uncertainty) when the organization is deciding whether to double down on AI or pull back. Second, it is susceptible to recency bias. Informal and periodic processes tend to weigh the most recent and most visible interactions disproportionately. A high-profile failure shortly before a review, such as a hallucination in an AI suggestion, shapes the assessment more than months of quiet incremental productivity gains that were never explicitly tracked. Third, manual reviews rarely produce the evidence that finance teams find convincing. We’ve been running interviews with software engineering leaders about the future of developer teams and how ROI measurement is happening within teams. We find that formality, actual numbers, and longitudinal data are often lacking. Pressure from the board keeps increasing, so it’s paramount that teams are able to provide that data. Gartner noted that a major challenge for organizations is justifying substantial investment for productivity enhancement, which can be difficult to translate directly into financial benefits. Historically, CFOs have not been comfortable investing in indirect future value. Without longitudinal data connected to business outcomes, that investment is nearly impossible. Among teams with no measurement in place, 59%  rate AI as valuable and 13%  rate it as not valuable. Among teams that are measuring in some form, 78%  rate it as valuable, compared to 4%  finding it not valuable. So the difference between non-measurers and measurers is a 19 percentage point gap  in perceived value. When we isolate teams measuring formally, those with automated processes, the figure rises further to 85%  rating AI as valuable. The gap is huge. The intuitive explanation is straightforward: measurement captures value. Teams that track metrics are able to see what AI is actually delivering, so they rate it more highly. But there might be something deeper happening. We pose another hypothesis: measurement doesn’t just capture value, it helps create it. When teams are tracking metrics consistently, they also use AI tools more deliberately. They start routing tasks toward AI where it demonstrably helps and avoiding it where it doesn’t. They start to develop better practices. They correct for the asymmetry between the spectacular failure that sticks in memory and the hundreds of routine successes that don’t. Systematic tracking also creates feedback loops. You measure, you see what’s working, you adjust, and then you measure again. The process gets tighter and the value increases. Measurement doesn’t just answer the question, “Is AI working?” It also changes team behavior in ways that make the answer more likely to be yes. Organi s ation size and measurement maturity We also find that the clearest organization-size-related divide in our data set sits at the informal end of the measurement spectrum. Among freelancers and organizations with up to 100 employees , 25%  rely on occasional discussions and subjective impressions. That’s more than double the rate of enterprises with more than 1,000 employees  and notably higher than midsize firms. The flip is true at the formal end. 46%  of enterprises have KPI tracking, dashboards, or automated monitoring in place, compared to 41%  of midsize firms and only 30%  of smaller organizations. That’s a 16-point gap  between the smallest and largest organizations. We also see that every organization type has landed in the manual middle in roughly equal proportion, regardless of resources or scale. That consistency tells us that this manual tier doesn’t function as a stepping stone toward formal measurement. It is more like a default state that organizations settle into and tend to stay in. For smaller organizations, the practical priority is not building dashboard infrastructure from scratch, but escaping the informal tier entirely. Moving from ad hoc impressions to even one defined manual process closes the most consequential gap in the data. For midsize organizations already in the manual tier, the formal measurement gap relative to enterprises is the number worth closing, because it connects directly to the value perception gap between those groups. If that gap is closed, the organization is not just improving its measurement process, but likely also improving how senior leaders perceive the value of AI investments. What this means for technology leaders The question is no longer whether to adopt AI. The question is whether organizations have built the internal capabilities to know what that adoption is actually worth. The data suggests that most have not done it in a formal way. The gap between claiming to measure and measuring formally and rigorously is wide, and it carries real consequences for the quality of evidence available to senior leaders. When a board or CFO asks, “Is this AI investment paying off?” , the answer depends almost entirely on whether the organization has systematic data or quarterly impressions. When AI initiatives start being abandoned across the industry, boards will ask even harder questions. Organizations with measurement frameworks in place will have answers. Others will be scrambling. Without systematic tracking, it’s difficult to tell whether Copilot is saving more time than Q Developer, whether investment in an agentic AI platform is actually reducing toil, or whether the organization is paying for a tool that nobody is using effectively or to its full potential. The key point is that knowing how your measurement practices compare to the market is the starting point for building that capability. AI Developer Tool Benchmark We’ve been listening to questions from the market about which tools are actually delivering, what’s worth the investment, how they’re being used, and what’s driving adoption. We’ve developed something that is a direct response to that. We’ve recently introduced the AI Developer Tool Benchmark , a new research product specifically designed to give technology leaders the data they need to make informed decisions about AI developer tooling. Whether you’re a vendor building and selling AI products or a buyer looking to choose the right tool for the team or for your products, this data will be useful. We launched a pilot version in Q4 last year  to pressure-test the product in the market and gathered extensive feedback from clients. Within April, we’ll be launching the official first benchmark with more than 2,400 professional developers worldwide . The benchmark covers: an overview of 20 AI developer tools  scored on adoption, usage intensity, and satisfaction among 2,400 professional developers , how developers actually work — whether they use a single tool or stack multiple tools together, how they make tooling decisions, and what’s driving preference, task priorities and satisfaction, including code generation, debugging, and documentation, cost and pricing evaluation, including how developers perceive value relative to cost, decision drivers and trust perceptions, productivity and measurable impact, including whether developers perceive AI tools as making them more productive in the sense of saving time, and a deep-dive section that changes each wave based on client feedback and market interest. This time, we decided to focus on AI agents , mainly the agentic form of the AI coding tools that we’re asking about. This is fundamentally different from using them simply as coding assistants. We built this section to understand how teams are experimenting with agents, the level of autonomy they’re providing, what blockers they’re hitting, and where they see opportunity. Q&A Natasa Ljikar:  You mentioned that 42% of companies are abandoning AI initiatives , but 80% of tech leaders say that AI is valuable . That seems contradictory. Are the leaders saying it’s valuable the same ones whose companies are abandoning initiatives? Or is there a different group of people making those decisions? Bleona Bicaj:  The 42% abandoning  is coming from an external source, and the 80%  is coming from ours. The 80%  are engineering leaders and developers who are using AI tools and finding them valuable in their day-to-day work. The 42% abandonment rate  that S&P Global is tracking refers to projects that got greenlit at the board or executive level, often broader AI transformation initiatives, not just developer tools. So you can have engineering leaders genuinely finding Copilot valuable while the company’s enterprise AI data pipeline project — something much larger and more complex — gets abandoned because the data quality wasn’t there or the business case fell apart during implementation. Developer-level adoption and enterprise-level success are two different problems. That’s exactly why measurement matters. If you’re only measuring at the team level — “my engineers like this tool” — you’re missing the executive or strategic question of whether this is solving the business problem at scale. And that’s where the abandoned projects struggle. Natasa Ljikar:  You talked about how manual measurement is vulnerable to deprioritization and recency bias. But doesn’t the act of doing a quarterly review, even if it’s manual and imperfect, create accountability? Isn’t that better than nothing? Bleona Bicaj:  Manual measurement is genuinely better than nothing. That quarterly review does create accountability internally. The problem isn’t that it exists, but what you can’t see with it, and where the gap between the manual and formal process lies. When you’re doing quarterly reviews, you’re documenting past impressions. What you actually need is a more real-time signal about what’s working and what isn’t — more up-to-date data that you can adjust now and not in three months when the next review comes in. Teams in the manual tier often end up doing the measurement work twice. They do the quarterly review, report what they find, and then when the CFO asks follow-up questions three months later, they scramble to do a special investigation because the quarterly review data wasn’t structured to answer those new questions. Formal measurement systems are expensive upfront, but they answer both the questions you knew you’d have and the ones you didn’t. Natasa Ljikar:  How is value typically measured in organizations? Bleona Bicaj:  This is something we’re trying to answer through interviews. In our AI Developer Tool Benchmark study, we typically ask developers to tell us about time saved, for example, or PR merge — things that are easier to quantify and that people are measuring through KPIs. But value is very subjective. From the discussions we’ve been having with software engineering leaders, many are trying to include the subjective, human factor as well. They are trying to understand how developers themselves perceive the help they’re receiving from these AI developer tools — not just in terms of productivity, but also how they feel about them potentially replacing their roles. So this is something that may affect psychological safety, which we keep hearing about in interviews. It is being interpreted differently across organizations. There isn’t one exact answer yet, but it’s something we’re exploring through the Future of Developer Teams  interviews, with the aim of getting both the quantitative and qualitative sides. Natasa Ljikar:  Have you run any causal impact studies for measuring impact of AI on coding productivity? Bleona Bicaj:  That is what we’re trying to get with the AI Developer Tools Benchmark, and that is a quarterly product that we keep trying to improve. If someone is interested in something that the benchmark doesn’t carry in a given quarter, we can add questions in other quarters and make it a richer product. In terms of trust- and performance-related metrics, we’re able to have an answer about the AI developer tools — the 20 tools  that we’re measuring. Natasa Ljikar:  If any other questions arise, please feel free to reach out to us. You will also be receiving the recording of this session and the report when it’s ready in your inbox. Bleona Bicaj:  Thank you.

At KubeCon + CloudNativeCon EU 2026 in Amsterdam, theCUBE’s Rebecca Knight and Rob Strechay sat down with Liam Bollman-Dodd, Principal Market Research Consultant at SlashData, and Bob Killen, Senior Technical Program Manager at CNCF, to discuss the newly released State of Cloud Native report . The full interview is at the end of the article. The conversation was framed around one of the report’s headline findings: the cloud native ecosystem now includes nearly 20 million developers, a sharp increase that raises a bigger question than simple growth alone can answer — who counts as a cloud native developer now, and what does that say about where the industry is heading? That was where Liam Bollman-Dodd made some of the most important points in the discussion. Cloud native growth is more than an adoption story Rather than treating the growth figure as a straightforward adoption story, Liam explained that part of the jump comes from a broader and more accurate view of the developer population. In earlier waves of research, cloud native was largely associated with backend and infrastructure specialists. But as SlashData and CNCF expanded the lens to include developers working across cloud-based environments more broadly, the picture changed significantly. Many developers are now building on cloud native foundations without directly configuring the infrastructure themselves. That distinction matters. Liam’s argument was that cloud native has moved beyond its original identity as a specialist infrastructure domain. Developers may not be managing Kubernetes clusters by hand, but they are still using observability stacks, cloud services, APIs, telemetry tools, and platform abstractions that place them firmly inside the cloud native ecosystem. In that sense, the report is capturing a structural change in software development, not just a bigger version of the same community. How AI is connected to cloud native growth He also connected that shift directly to AI. One of Liam’s most notable observations was that cloud native tooling is increasingly becoming the operational backbone for AI inference and machine learning workflows. His point was not that these tools were built specifically for AI, but that they are well-suited to the scale, networking, data movement, and orchestration demands that AI creates. As a result, teams pursuing AI are often becoming cloud native by necessity, even if that was not their original strategic goal. Organisational structure Another key theme Liam raised was the growing divide in how organisations structure development work. Some companies still want deeply empowered developers who understand the full toolchain and can work close to infrastructure. Others are moving in the opposite direction, using platform engineering and internal abstraction layers so developers can focus more narrowly on product and business problems. Liam’s view was that both models are valid responses to different organisational needs, but they produce very different relationships with cloud native technology. That, in turn, affects how adoption should be interpreted. He also pointed to what may become one of the more consequential findings over time: the long tail of organisations that remain underrepresented in industry narratives. Liam noted that many capable developers operate in environments with low budgets, limited internal leadership, compliance constraints, or delayed access to newer tooling. In his telling, the cloud native market is not only being shaped by advanced platform teams and large-scale adopters, but also by organisations that are arriving later and more gradually. That makes the ecosystem broader, but also more uneven than headline numbers alone suggest. By the close of the interview, Liam’s broader message was clear: the meaning of “cloud native developer” is evolving, and the community may expand even faster than the raw numbers suggest as more people begin to recognise that the tools and workflows they already use fall under that label. In that respect, the interview was less about celebrating a large number in and of itself, but about redefining the boundaries of a maturing ecosystem. The full interview:

Cloud deployment has become an integral part of software development, with the vast majority of developers now relying on cloud infrastructure in some capacity. While cloud deployment has become nearly universal, not all cloud usage is equally sophisticated. Despite widespread adoption of cloud infrastructure, many developers and organisations have yet to fully leverage cloud native technologies and architectural patterns that unlock the cloud's full potential. This report , produced in partnership with the Cloud Native Computing Foundation, presents the latest insights into the state of cloud native developers in Q1 2026. It provides an analysis of key trends shaping the cloud native ecosystem, drawing on data from the 31st edition of SlashData’s Developer Nation survey, fielded between December 2025 and January 2026, which reached more than 12,500 respondents from 100 countries around the world. Cloud Native developer population in 2026 The cloud native developer community continues to expand in absolute terms, growing from 15.6M developers in Q3 2025 to approximately 19.9M in Q1 2026. This represents roughly 39% of the entire global developer population and reflects cloud native practices are spreading beyond their backend infrastructure origins into mainstream software development across domains. Among backend developers specifically — historically the core cloud native community — 52% are classified as cloud native in Q1 2026, down from 58% in Q3 2025 but still above the 49% recorded in Q1 2025. While the quarter-on-quarter decline is notable, it may reflect normal variation or indicate that Q3 2025's 58% was elevated. The Q3 2026 measurement will clarify whether the typical baseline is closer to 52%, 58%, or somewhere between. Year-over-year growth remains positive. It is also worth noting that these shifts in values are happening in a period where the developer job market is undergoing pressures — in particular, the restructuring that was seen during the 2024–2025 period. While it is not possible to establish direct causation between the market forces and cloud native adoption, developers educated under the normalization of cloud native technologies entering the market at restricted or impacted rates may be a driver of this six-month decline. In Q1 2026, we estimate that there are 4.5M cloud native developers in Western Europe and 1.2M in Eastern Europe. The expansion of the cloud native population was broad-based rather than concentrated in any single area. Professional games developers, for example, increased from 30% cloud native in Q3 2025 to 39% in Q1 2026, while industrial IoT developers rose from 38% to 42% over the same period. These increases reflect cloud native technologies becoming standard tools across diverse development contexts, not just those in specialized infrastructure work. Read the full report. About the author Liam Bollmann - Dodd, Principal Market Research Consultant at SlashData Liam is a former experimental antimatter physicist, and he obtained a PhD in Physics while working at CERN. He is interested in the changing landscape of cloud development, cybersecurity, and the relationship between technological developments and their impact on society.

The AI transformation currently taking over the software development industry has already shown that many aspects of this revolution are here to stay. Amidst rapidly changing landscapes, we have always found solace in the reality of data, sourced through best-in-class research.  The software/AI industry is drowning in noise: Hype cycles, vendor-spin, conflicting “evidence”, model benchmarks that don't reflect real-world use, and adoption statistics that are basically…marketing.  Executives in this space have been burned repeatedly by analysis that turned out to be extrapolation dressed up as data. CTOs, CPOs, and VPs of Engineering make daily build/buy/partner decisions, AI adoption strategies, and platform bets. These are high-stakes, high-regret decisions. The cost of acting on bad analysis is enormous.  We’re proud to be able to tell them what's actually happening: how software gets built, what developers need, what teams prioritise, and how AI is actually adopted. With that in mind, this article is a “highlight reel” of the top findings we discovered over the past few months.  A new, updated batch of insights is coming in within the next few weeks. Join the newsletter to get updated first. Here’s what you need to know, now (with sources because we’re into insights, not clickbait). If you want to know something very specific, we're here for you . Artificial Intelligence in software development highlights in Q1 2026 AI on Edge: An on-device focus What we found: Smartphones and tablets are rapidly evolving edge AI targets, driving demand for NPU-optimised on-device models. Source: Integration of AI into edge devices Edge devices are becoming an increasingly important way for artificial intelligence (AI) to reach end users, from smartphones and laptops to wearables, industrial machines, and connected vehicles. This report aims to understand how developers are currently integrating AI models into edge devices and where the main opportunities to reduce friction lie. Based on a global survey of professional software developers who reported building or implementing AI functionality in the 30th edition of our global Developer Nation survey, the analysis details the widespread usage of edgeAI among these developers, regional differences, the devices they target, the approaches they use, and the main challenges they face when deploying models on the edge. AI in Game Development  What we found: Over half of game developers fear AI will further reduce job opportunities amid an already fragile industry marked by widespread layoffs Source: The State of Game Development 2025 In this report, we take a look at today’s landscape of game development. We examine who game developers are, the technologies, engines, and programming languages they rely on, the platforms they target, and the types of games they create. The report also explores how game developers perceive the impact of AI in the industry, shedding light on both the opportunities and the challenges it introduces. AI tool usage across professional developers (full report free to access) What we found: As of Q3 2025, ChatGPT and GitHub Copilot lead in adoption and satisfaction as AI-assisted coding tools among professional developers, reinforcing their position as the safest bets for large-scale rollouts. Source: Choosing the right AI coding tools for your team The rapid rise of AI-assisted coding tools marks a pivotal moment in software development. What began as experimental add-ons has quickly evolved into a crowded market of products, each claiming to boost productivity and transform workflows. Yet with so many options and so much noise, it can be difficult to know which tools are truly delivering value. By examining adoption, satisfaction, and trust-related attributes such as accuracy, support, and security, this report provides a data-driven benchmark of which AI coding tools developers are embracing and which they rate most highly. The analysis reveals where usage aligns with satisfaction, where trust is earned through consistent delivery, and where gaps remain between expectations and reality. For engineering leaders making decisions about which tools to integrate and scale across their teams, the insights in this report help distinguish the coding tools that enable productivity from those that are still struggling to meet developer needs. AI Blockers: why developers don’t build GenAI apps What we found: Most developers remain open to using generative AI if key concerns are addressed. However, stronger privacy and security controls are at the top of confidence drivers, especially for those facing data and compliance barriers. Source: Understanding the reluctance towards building generative AI applications The aim of this report is to understand what prevents developers from integrating generative AI functionality into their applications and what could increase their confidence to do so. For vendors of generative AI platforms and APIs, these findings highlight the areas where developers most need reassurance and support, from robust data protection and clear documentation to seamless integration paths. Agentic AI in software projects (full report free to access) What we found: Agentic AI is moving beyond the experimental stage. Of those integrating AI into their applications, half have already deployed agentic AI architectures to production Source: The state of agentic AI adoption in software projects Agentic AI is emerging as one of the most transformative shifts in how companies design and deploy intelligent systems. This mini-report analyses insights from over 8,400 professional developers to help CTOs and engineering leaders navigate the rapidly evolving agentic AI landscape and make informed architecture and use case decisions. We’ll explore how the implementation of agentic AI varies by company size and project type as well as looking at the types of agentic architectures that are being deployed to production, along with the use cases developers are targeting. Programming language communities and software developer population size  There are 48.4 million developers around the world “How Many Developers Are There in the World?” is our most frequently asked question here at SlashData, both from Product and Marketing people who want to measure adoption, executives who care about their Target Addressable Market (TAM), and software industry journalists and enthusiasts.  To help them all with their goals, we happily share this number and update it as new data becomes available. Go ahead and confidently use this number in your pitch, BoD presentation, or article. We follow a strict methodology to ensure that this is the most accurate estimate you can get. Developer Population Trends Tracking Page JavaScript is the most popular language for software development (full report free to access) What we found: As of Q3 2025, JavaScript was the largest language community, with approximately 27M developers worldwide. Source: Sizing programming language communities Programming languages sit at the heart of the software development ecosystem, shaping not only the kinds of projects developers work on but also the communities they become part of. For product executives, understanding language adoption is more than an academic exercise as it directly informs decisions about which SDKs, APIs, and platform features to prioritise. Choosing the right languages to support can expand the reach of your platform, lower barriers for developers, and ultimately drive product adoption. Assessing how widely used a programming language is and estimating the size of each language community in absolute terms remains a challenge. The estimates presented here are based on two key data sources. First is our independent estimate of the global number of software developers, which we have been publishing for more than eight years. Second is our large-scale surveys, which reach tens of thousands of developers every six months.  A look into DevOps  DevOps: Lack of standardisation is connected to less security What we found: Organisations without DevOps standardisation show between two and three times lower rates of integrating security practices into their CI/CD pipelines Source: Impact of Platform Strategies on Security Practices in Software Development This report examines the security practices that developers integrate into their CI/CD pipelines, with a particular focus on how platform standardisation approaches influence which security tools see adoption and success. In this report, platform standardisation refers to organisation-wide standardisation strategies for DevOps practices, and we categorise platform configurations into five distinct groups: specialised internal developer platforms (IDPs), dedicated teams or individuals responsible for developer experience, unified systems for managing DevOps processes, curated lists of approved tools, and organisations engaging in none of these approaches. This report is based on data from SlashData’s 30th edition of the Developer Nation survey and represents the adoption patterns of more than 4,700 professional developers using CI/CD pipelines.  Company size and industry shape affect deployment strategies (full report free to access) What we found: As organisations grow in size, two overarching strategies to backend DevOps maturity emerge, with some empowering their developers to use a wide range of advanced technologies effectively, while others abstract away infrastructure behind internal development platforms leading developers to prioritise business needs Source: Benchmarking backend and cloud technology strategies This report examines cloud and server-side technology adoption patterns across organisation sizes and industry sectors, revealing insights that challenge conventional wisdom about technology maturity.We explore how multi-environment strategies evolve with organisational scale, why container adoption varies across company sizes, and how platform teams create infrastructure capabilities that are frequently invisible to their developers. Through analysis of deployment strategies, modern architecture adoption, and industry-specific technology leadership, we provide IT executives with frameworks for evaluating their technology strategies against relevant peer organisations rather than generic industry trends.The findings reveal that successful technology adoption depends lesson following best practices and more on aligning technology choices with organisational capabilities, industry requirements, and strategic priorities. Cloud updates you should know in Q1 2026 Cloud-native development (update coming in March 2026) What we found: There are 15.6M cloud native developers, of which 9.3M are backend developers Source: State of Cloud Native Development Q3 2025 (full report free to access) This report explores the current state and scale of cloud native development in Q3 2025. The report provides approximations of the cloud-native developer population in backend services, machine learning or AI, and throughout the entire developer population. The report also provides information on the popularity of different cloud native technologies or approaches among backend developers, to reveal the sophistication path organisations often go through.  In addition, the report explores the trends in cloud deployment approaches, as well as the technologies that developers are using in their backend or cloud development processes and services. We also provide estimates for the proportion of cloud nativeness throughout the range of types of development (e.g. mobile, desktop, DevOps, etc.).  Data residency: Compliance in practice  What we found: Collaboration between developers and legal teams is the leading challenge developers cite. Source: Data Residency Compliance Challenges and Organisational Responsibility This report provides an examination of how organisations are coping with data residency compliance in practice. It explores the primary challenges developers face when building compliant services, how these challenges vary by region and organisation size, and where responsibility for compliance tasks falls within organisations. The analysis reveals significant regional differences in both the nature of compliance challenges and how organisations structure accountability, offering insights for how cloud service providers (CSPs) should design their compliance offerings and which capabilities matter most to customers in different markets. FinOps beyond cost-cutting (full report free to access) What we found: Mid-sized organisations lead in FinOps adoption, likely due to scaling cloud complexity.  Budget monitoring and reporting are the most common FinOps activities, highlighting the importance of visibility into cloud spending. Source: The State of FinOps in 2025 Cloud spending can become one of the largest operational expenses for tech companies. It is often unpredictable due to elastic consumption models, hundreds of services and pricing models, and decentralised purchasing by developer teams (particularly in large companies). Cloud financial management (FinOps) sits at the intersection of finance, engineering, and product, ensuring that cloud resources are used efficiently, focusing on aligning cloud spending with business value, not just cost-cutting. In this report, we examine insights from over 6,300 professional developers working for companies with at least 2 employees who use cloud services. We’ll explore the adoption rate of FinOps practices among developer teams and how it varies by company size and region. Additionally, we’ll cover how teams implement FinOps by looking at the specific practices they have embraced. The report is designed to help technical leaders benchmark their organisations against industry peers and make informed decisions about where to focus their FinOps efforts. AR, VR and IIoT software developer trends AR and VR: ARVR practitioner numbers remain stable What we found: There are approximately five million AR/VR practitioners worldwide, a figure that has remained relatively stable over the past two years. 83% of AR/VR practitioners are leveraging AI across multiple use cases, from coding to content creation. Source: The State of AR/VR Development 2025 This report provides a detailed examination of today’s XR landscape. It explores how many practitioners there are, how they participate in the ecosystem, the types of projects they are building, and the platforms they target. It also investigates how XR practitioners are leveraging AI and which other technologies make up their stack. Finally, the report looks at the main challenges XR practitioners face today and looks ahead to the future of the AR and VR industries, capturing XR practitioners’ and other developers’ perspectives on its direction for the next decade. IIoT onboarding is frictionless  What we found: First IIoT development board onboarding is largely frictionless, as 65+% of professional developers involved in IIoT projects find “setting up the hardware” and “running a basic project” easy. Source: IIoT accessibility This report explores how developers begin their IIoT journey: which development boards they start with, how they experience onboarding across tasks and ecosystems, and how these patterns differ by professional status, experience level, and region. The findings highlight where the industry is lowering technical barriers and where better documentation, community support, or learning pathways are still needed. Insights come from the 30th edition of the Developer Nation survey, which ran from June to August 2025 and reached 830 developers worldwide involved in IIoT projects. After 20+ years of researching the software industry, we have a huge (HUGE) data library we can tap into to answer your questions. Our analysts are subject-matter experts on software development topics and can foresee trends and help you power your strategy with evidence. Let's dive into your priorities together. Get in touch . About the author Stathis Georgakopoulos, Marketing Manager at SlashData Stathis leads SlashData's marketing activities and product marketing and loves building helpful content that turns complex research into practical decisions. He focuses on setting the table for launches and campaigns, and has a soft spot for content marketing and terrible puns.

The games industry has faced significant turbulence in recent years, marked by widespread layoffs, reduced investment , and declining market confidence. Earlier this month, Google’s Project Genie announcement triggered a sharp drop in several major game stocks , including Unity, Roblox, and Take-Two, further highlighting the broader uncertainty surrounding the industry’s direction. Against this backdrop, AI has emerged as both a widely adopted tool and a highly contested topic. Player communities have pushed back visibly; review-bombing titles suspected of using AI-generated art, criticising Ubisoft’s AI-powered NPC system, and prompting Valve to update Steam’s policies to require developers to disclose AI-generated content following sustained community pressure. In some cases, studios have even cancelled projects and publicly committed to avoiding AI altogether. 76% of professional game developers are currently using AI to assist with coding or generate creative assets Despite this backlash, the data shows that AI adoption is already mainstream among game developers. According to our Q3 2025 survey with more than 2,000 game developers, 66% are currently using AI to assist with coding or generate creative assets. Among professional game developers, that figure rises to 76%. In this blog post, we’ll explore how game developers perceive AI’s impact across several key dimensions. The full findings, along with insights into the platforms developers target, the engines they use, or the types of games they build, are available in The State of Game Development 2025  report. AI accelerates game production and might help indies rival big studios, but raises alarms over shrinking career opportunities So how do game developers themselves evaluate AI’s impact? Beyond public backlash, our data reveals a more nuanced perspective from within the industry. The most widely shared perception is that AI accelerates the game development process. Over two-thirds (68%) of game developers agree with this statement, highlighting how AI is reducing friction from concept to execution. This highlights AI’s role in accelerating coding workflows (e.g. boilerplate code, debugging, and troubleshooting), as well as in enabling faster prototyping and iteration for assets. 68% of game developers agree that AI accelerates the game development procecss. A closely related finding is that 62% of game developers believe AI will make it easier for indie developers and smaller studios to compete with large publishers. However, indie developers themselves are the least convinced. Only 58% agree, compared to over 70% of those working for publishers or large studios. Indie developers might recognise that while AI can amplify their capabilities, it also scales the advantages of well-resourced studios, enabling them to produce more content, iterate faster, and optimise performance at greater scale. Moreover, many indie game developers might face their biggest challenges in areas like distribution, visibility, and marketing, which remain largely beyond AI’s scope. When it comes to career opportunities, just over half (55%) of game developers believe that AI will reduce the number of roles and opportunities available in the industry. This concern sits within a broader context of instability across the tech sector, one that has disproportionally affected games . The relationship between AI adoption and employment uncertainty remains a debate. On the one hand, AI can augment productivity and create demand for new hybrid skill sets. On the other hand, it risks displacing entry-level responsibilities, as automation absorbs many of the structured, repetitive tasks that once served as gateways for junior developers. As seen in the Stanford Digital Economy study , for jobs with high AI exposure, such as IT and software engineering, employment has been steadily declining for early-career professionals while increasing for the more seasoned ones. If this pattern extends to game development, the industry may face a structural challenge: fewer entry points for newcomers, combined with growing demand for senior talent to oversee, integrate, and validate AI systems. Game developers believe AI enhances player experience, while noting bugs and creativity risks Despite the backlash from some players towards games that use AI, 62% of game developers believe that integrating AI improves the overall player experience. From adaptive difficulty systems and more responsive AI-powered NPCs to personalised storylines and dynamic environments, AI is viewed as a tool that can potentially enable richer, more immersive, and more reactive gameplay. However, confidence is lower among developers in creative roles (art, asset production, audio), where 56% agree. Concerns about originality further illustrate this divide. Overall, 52% of game developers believe AI poses a threat to creative originality, rising to 59% among those involved in creative activities. Many of these creative practitioners might fear that AI-generated content, trained on similar datasets and optimised for popular aesthetics, leads to homogenised content that prioritises speed and scale over originality, making games feel increasingly alike. For many game developers, the drive for efficiency risks dulling the diversity and individuality that define great games if AI is adopted without strong creative direction. There are also technical reservations. Although most developers acknowledge AI’s productivity benefits, 53% agree it increases the risk of bugs or unpredictable behaviour in games. Unlike traditional rule-based systems, AI models can behave in ways that are difficult to fully anticipate, test, or reproduce. This unpredictability can lead to broken dialogue trees, erratic NPC behaviour, balance issues, or edge-case logic loops that only emerge under specific player interactions. As a result, while AI can enhance immersion, it can also introduce new layers of systemic complexity that demand stronger oversight, validation processes, and design safeguards. Taken together, the findings in this blog post suggest that AI adoption in the game development industry is widely perceived as beneficial, but not without meaningful trade-offs. While AI is transforming workflows and accelerating production, it also raises concerns about shrinking career opportunities, creative homogenisation, and technical unpredictability. Ultimately, AI’s role in game development will be shaped not only by what the technology makes possible, but by the strategic decisions developers make about how, and how far, to integrate it. Dive deeper into the game development world. Explore what is shaping the industry with the help of our analysts and 20+ years of software development data. Book a call with Natasa and Petro. About the author Alvaro Ruiz Cubero, Research Manager, SlashData ​Álvaro is a market research analyst with a background in strategy and operations consulting. He holds a Master’s in Business Management and believes in the power of data-driven decision-making. Álvaro is passionate about helping businesses tackle complex strategic business challenges and make strategic decisions that are backed by thorough research and analysis.

Edge devices are becoming an increasingly important way for artificial intelligence (AI) to reach end users, from smartphones and laptops to wearables, industrial machines, and connected vehicles. Running models directly on these devices can improve responsiveness, support offline or low-connectivity scenarios, and reduce the need to transmit sensitive data to the cloud. At the same time, doing more on the device introduces new constraints around compute, power, storage, and how data privacy and security are managed in practice. At the infrastructure level, recent industry analysis points to hundreds of billions of dollars being spent on edge computing over the next few years [ ref1 ] and several trillion dollars of cumulative investment in AI-driven compute capacity by 2030 [ ref2 ]. For anyone building hardware, frameworks, or platforms for AI at the edge, understanding how developers fit into this picture is essential. Here, we use SlashData’s latest Developer Nation data toestimate the size and growth of professional developers integrating AI into edge devices, and where this work is concentrated. Find a deeper analysis on the full report . 11 million professional edge AI developers worldwide and growing As of Q3 2025, we estimate that there are currently around 38.4 million professional developers worldwide. Of these developers, 29% (11 million) report building or integrating AI functionality on projects that target direct implementation into edge devices. We refer to this group as edge AI developers. Our data shows that edge AI is therefore already a substantial part of the AI developer ecosystem, rather than a niche reserved for early adopters. There are currently around 38.4 million professional developers worldwide. Of these developers, 29% (11 million) report building or integrating AI functionality on projects that target direct implementation into edge devices. We forecast that this population will receive substantial annual growth, even under conservative assumptions. In our conservative scenario, the number of edge AI developers is expected to rise by 30% to 14.3 million by late Q3 2026. Meanwhile, in the optimistic scenario, this figure reaches 18.1 million, representing a 64% increase. In both cases, the pool of developers integrating AI into edge devices is a moving target rather than a static market. As such, vendors should plan for a larger, more diverse edge AI audience in the near term. For technology leaders, there are three clear implications: Treat  edge AI as a strategic focus area with dedicated product planning and clear ownership, rather than as an add-on to cloud-only AI initiatives. Act  early to capture default status with developers by using the coming year of growth to position your products, APIs, and hardware platforms as the natural choice for teams starting or expanding edge AI work. Track  edge AI separately from broader AI efforts, so that usage, community engagement, and revenue for edge-specific offerings are visible in their own right and can inform investment decisions. Regional hotspots for edge AI development As of Q3 2025, edge AI activity is concentrated in three major hubs. North America and Western Europe account for 3.1 million and 2.9 million edge AI developers, respectively, while the Greater China area forms a third major centre at about 2.4 million. By Q3 2026, these regions are projected to grow by 30% to 60%, making them the highest-priority markets for advanced edge AI offerings where both scale and absolute growth are strongest.  The Middle East and Africa (MEA) and South Asia present notable but smaller markets, each with 800 thousand professional edge AI developers. However, we see major opportunities in our optimistic forecast, with both regions potentially reaching 1.4 million each by late Q3 2026. Vendors looking to grow in these two regions may benefit from lowering barriers to first deployments by offering accessible hardware options, opinionated tooling, and strong implementation support. South America presents a more extreme case, where the focus on edge AI development is significantly lower than in other regions. As such, penetrating this market may require a longer-term commitment, with particular emphasis on education, partnerships, and solutions that clearly demonstrate value under tighter resource constraints. At the same time, there is considerable interest and clear indications of increased activity over the next 12 months. This combination of low current penetration and rising intent points to significant headroom for growth for vendors prepared to invest early and build a presence over time. Edge AI is already a mainstream developer activity with clear room to grow Taken together, these findings show that edge AI is already a mainstream developer activity with clear room to grow, rather than an early-stage experiment. There are already 11 million professional developers working on AI functionality for edge devices worldwide, with an expected annual growth rate between 30% and 64% at the present time. North America, Western Europe, and the Greater China area are leading both in scale and growth, highlighting the three natural priority markets for edge AI offerings. Meanwhile, the Middle East & Africa, South Asia, and South America represent smaller markets with headroom for investment. Building tooling for edge AI? Access our full report , which breaks down device targets, integration patterns, and adoption barriers.  About the author Nikita Solodkov, Principal Research Consultant at SlashData Nikita Solodkov is a multidisciplinary researcher with a particular interest in using data-driven insights to solve real-world problems. He holds a PhD in Physics and has over five years of experience in data analytics and research design

Why a satisfaction score of 6 in Japan might be better than an 8 in China If you’ve ever looked at the same satisfaction question broken down by country and thought, “ Why are these numbers so wildly different? ” – you’re not alone. In global research, interpreting data responsibly is one of the hardest parts. At SlashData, we run developer studies across regions year after year (including our rolling Developer Program Benchmarking (DPB) , where we help vendors identify concrete improvement paths for their developer programs). One pattern shows up consistently: the way respondents use rating scales is deeply cultural. A satisfaction heatmap promises a unified view of performance. Executives can scan rows and columns for the green of success or the red of failure. Yet, once that data spans continents, it often conceals as much as it reveals. As we will see throughout this post, a growing body of research suggests that the standardised metric of customer satisfaction is often just a map of cultural biases. Without a cultural lens, your global heatmap isn't just a distorted mirror – it’s a dangerous map that can lead to strategic missteps, from the misallocation of resources to the unfair penalisation of high-performing regional teams. For simplicity, in this blog, we will assume a satisfaction scale from 0 to 10. Treat global satisfaction scores as directly comparable, and you can end up misallocating budget, fixing markets that aren’t broken, or missing early warning signals in markets that look healthy. The "Optimists" vs the "Sceptics" (and the Japan paradox) A quick glance at our DPB vendor satisfaction cuts often reveals a geographic divide. North American respondents are frequently at the high end. We also see a cluster of high-scoring Southeast and East Asian markets – especially the Philippines, Vietnam, Indonesia, and China. On the other hand, Japan consistently shows up as more conservative in its ratings, and we often see the same tougher grading in parts of Western Europe, including Germany and the Netherlands. This is not just a SlashData thing. Ipsos specifically flags that the Philippines, Indonesia, and Vietnam give high scores, while other Asian markets provide much lower scores, explicitly including Japan in the low-scoring set. And SurveyMonkey ’s cross-country NPS study shows just how dramatic this can be on a simple 0-10 “recommend” scale: Japan is the lowest of the markets they studied, while the United States and Canada are much higher, and the Netherlands sits well behind many other countries. If taken at face value, this data would suggest that developer programmes are thriving in North America but failing to impress in Western Europe. But does this align with actual retention rates? Often, the answer is no. This disconnect is likely driven by a few powerful cultural forces, like optimism bias and polite agreement on the one hand, and scepticism on the other.  High satisfaction scores can coexist with low developer retention, especially across regions. North America & Emerging Asia are “optimists” when it comes to surveys Research indicates that in cultures prioritising social harmony, such as some Asian markets (often correlated with high collectivism), respondents are predisposed to be agreeable. For high-scoring Asian markets (like the Philippines, Vietnam, China, Indonesia), one driver is often what researchers call agreement and harmony effects: in some cultures, direct negative feedback is less comfortable, and respondents can lean toward more socially acceptable, relationship-preserving answers. S ome markets systematically use the top end of the scale more than others, enough to reorder league tables without any real change in underlying experience. In high-agreement environments, a score of 8-9 can be closer to “fine” than “fanatically loyal”. The danger is overconfidence. In the US and Canada, high scores are often driven by Optimism Bias . Culturally, there is a tendency to view things in a positive light. “Good” is often rated as “Great”. As noted in global NPS studies by SurveyMonkey , American respondents consistently score higher than their European counterparts for the same service levels. Western Europe & Japan are the “sceptics” when it comes to surveys On the other side of the chart, we see Western Europe (e.g. Germany, the Netherlands) and Japan hovering at the bottom of the scale. Western Europe is home to the “ Dutch effect ” or sober grading. In these cultures, hyperbole is viewed with suspicion. A score of 10 is reserved for perfection – a standard almost no B2B service achieves. Japan is the ultimate outlier in our data. Despite being geographically close to the high-scoring Asian nations, it often produces the lowest satisfaction scores in the world. Multiple other studies reveal this pattern: in Japan, service expectations are famously high. A minor friction point that an American consumer might forgive is often punished harshly by Japanese consumers in surveys. Importantly, lower scores don’t automatically mean unhappiness. It often means that top ratings are reserved for rare perfection, and the cultural norm is to score more conservatively.  The cultural bias disconnect: confusing ratings with retention The biggest error a vendor can make is assuming a linear, universal relationship between these scores and churn. In harder-grading markets like Japan and some of Western Europe, a 6 or 7 can still behave like a loyal consumer. If you treat every sceptic as a problem, you risk wasting resources fixing relationships that aren’t broken – or worse, annoying stable customers with constant nudges to “rate us a 10.” In high-scoring markets, the risk flips. If the baseline is inflated, then a drop from 9 to 8 might not be just noise – it can be your early warning signal. And if the culture discourages direct complaints, you may not hear why until the customer leaves. If direct criticism is culturally discouraged, customers can look satisfied right up until they churn. Your first visible signal can be cancellation, not feedback. Adding a culturally intelligent framework to your research To navigate this landscape, vendors and clients must move beyond raw comparisons and adopt a relative, culturally intelligent framework. Benchmark intranationally, not internationally  Stop asking, " Why is our German market less satisfied than the Chinese market? " The correct question is, " How does our German score compare to the German benchmark? " If the regional average is a 6.5 and you score a 7.0, you are likely a market leader. Create country indices that normalise scores against the local average to reveal true performance. This is where tailored services like our Developer Program Benchmarking shine – we help you normalise scores against local averages to reveal true performance. Adjust your internal thresholds In “stoic” markets like parts of Western Europe and Japan, a 7 or 8 can be a genuine win. In high-scoring markets like some East Asian countries, treat anything below the local norm as a potential signal – especially if it’s trending down. Use ranking over rating  Where applicable, complement ratings with questions that force trade-offs. Ranking-style questions (“ Which programme is best? ”) are harder to game through polite scale use than “rate each one 0-10,” and they often reveal the competitive truth hiding beneath the friendliness. Conclusion A red Japan does not necessarily mean a failing program, nor does a green China guarantee a secure future.  By interpreting survey data through a cultural lens – acknowledging the sceptics, the polite promoters, and the scale's structural biases – you get closer to the true voice of the customer. The goal is not to standardise the customers, but to sophisticate the analysis so your data predicts what users will actually do next. Are you worried that your retention strategy is based on skewed heatmaps? We can audit your satisfaction data to separate real performance issues from cultural noise. Contact us today! About the author Bleona Bicaj - Principal Research Consultant Bleona is a research consultant, enthusiastic about product strategy and behavioural science. She holds a Master’s in Economic and Consumer Psychology. With more than 6 years of professional experience as an analyst, she has worked across quantitative and qualitative research studies, turning complex data into clear narratives that inform better products, smarter investments, and long-term growth.

Throughout the development world, we are seeing two competing approaches to DevOps maturity: developer empowerment or business focusing. Both models aim to ensure that their organisations are able to increase their developer velocity, ship securer code, and be able to respond to feedback and demands, but take diametrically opposed approaches to do so.  In this article, we explore both approaches: where each excels, what challenges they create, and how they manifest in real development teams. Drawing on data from SlashData's 30th Developer Nation Survey (which reached more than 10,000 developers globally in summer 2025), we'll show how these philosophical differences translate into concrete security practice adoption patterns, and why organisations should choose based on their specific context rather than industry trends.  Developer Empowerment, Autonomy and Visibility Those who follow the developer empowerment model focus on ensuring their developers are knowledgeable, informed, and have autonomy and visibility over their DevOps processes. Organisations adopting this approach typically value developer satisfaction and retention highly. This model hopes that recognition of experienced developers desire to control their toolchains and their resistance to imposed limitations will create happier developers who are willing to experiment freely. The organisations can provide guidance, approved vendor lists, or internal documentation, but ultimately they leave the decision to the ground-floor developers.  The challenge with this is consistency. Security practices may vary between teams, which can lead to blind spots. While individual developers, or teams, may have high levels of visibility into their processes and build up deep familiarity with security practices, the lack of consistency can lead to blind spots in the organisation-wide security posture. Adding to this challenge is that knowledge can become siloed within teams, with successful approaches not being shared with others. At its worst, developers who lack security experience can have their autonomy instead become a liability rather than an asset. However, while decentralised approaches to security risks gaps, it also allows developers to react very quickly to new vulnerabilities without having to wait on a central platform team.  In our current examination, this can include developers who are provided a curated list of tools for their  selection and configuration (34% of professional developers). This leads to a slightly higher adoption of IDE security checks (32%), pre-commit hooks (20%), and container-scanning(28% ) integrated into their CI/CD pipelines, as they are selecting the tools that they interact with during development.  Business Focus: Abstraction and Efficiency The other approach is business-focused, where the goal is to abstract away the concerns about security, infrastructure, deployment, and other DevOps processes behind an IDP or a controlled list of tooling configured for them (27% of professional developers). This aims to allow the developers to focus more on addressing business needs, and their core responsibilities, rather than having to consider wider aspects of the software development lifecycle. This approach emerges from different organisational priorities, including consistency at scale, meeting compliance requirements, or protecting specific business interests, even if it means constraining developers' choices. This can become especially true for companies with hundreds or thousands of developers, where complete heterogeneity of tooling can create maintenance headaches. In addition, organisations that want to prioritise their developer time on product differentiation, or need to onboard developers rapidly, a centralised process supports both of these. This aims to allow the developers to focus more on addressing business needs, and their core responsibilities, rather than having to consider wider aspects of the software development lifecycle. In practice, this can manifest as developers interacting with an IDP with abstracted interfaces. When a developer might deploy to staging, they may not be aware whether this instruction triggers Kubernetes, ECS, or Cloud Run behind the scenes. Within this approach, security checks happen automatically in the pipeline, where developers see the results but don’t necessarily configure these themselves. With these developers, we see higher rates of SCA (29%), DAST(26%), and IAST (27%) practices built into CI/CD pipelines because these happen behind-the-scenes for developers, which are benefitted by having highly centralised platforms.  However, despite the benefits to organisations, and developers, these systems risk creating ‘black box’ problems. If developers don’t understand what is happening behind the abstraction, they can become less effective at debugging, and have a shallower understanding of security practices. Additionally, platform teams can risk becoming bottlenecks, with every new tool or feature request platform team time. This can leave developers unable to work, or risk them engaging in shadow IT and compromising the goals of centralising security practices The False Choice Neither approach is inherently better or worse than the other. Every few years thought leaders emerge to declare that development teams should shift-left or shift-right  as the ‘correct’ way to do development, or to unlock previously unimaginable benefits. However, the reality is that simply shifting  doesn’t actually do anything, and it is instead the processes, practices, and culture within organisations and development teams that have the largest impact, and centralising or decentralising are just mechanisms to achieve this.  What matters instead is for organisations to consider other factors that will motivate them, and what capabilities it instead needs: faster feedback loops, comprehensive security coverage, developer satisfaction, or operational reliability. Some of these benefit from centralisation, and others from distribution, and organisations frequently blend aspects together to meet their specific needs.  What to consider when choosing a DevOps approach   Rather than asking 'which approach is better?', organisations should ask 'what does our context demand?'. Consider: Organisational size and growth trajectory: A 50-person startup might start with curated lists, knowing they'll need an IDP at 500 people Team security maturity: Less experienced teams may need more guardrails; senior teams may resent them Regulatory requirements: Financial services or healthcare often require centralised control and audit trails Cultural values: Does your organisation optimise for innovation speed or operational consistency? Platform team capacity: Building an IDP requires sustained investment—do you have the people and time? Your choice isn't permanent. Many organisations start with developer autonomy and gradually centralise as they scale. Others go the opposite direction, decentralising after realising their IDP became a bottleneck. The key is being intentional about the trade-offs you're making and regularly reassessing whether your approach still serves your needs. Our team of analysts can help you decide on the best option, using concrete data to help your decision-making. Let’s talk and find the solution that works for you.  About the author Liam Bollmann-Dodd Principal Market Research Consultant at SlashData Liam is a former experimental antimatter physicist, and he obtained a PhD in Physics while working at CERN. He is interested in the changing landscape of cloud development, cybersecurity, and the relationship between technological developments and their impact on society.