SD Times 100 Retires 'AI Coding Tool' as a Category and Declares the Era of Agentic Infrastructure

The SD Times 100, the annual survey of companies and tools shaping software development, has retired “AI coding tool” as a category. The 2026 edition, published June 29, replaces it with “Intelligence-Augmented Development” and frames AI coding systems as foundational infrastructure rather than optional productivity add-ons.

The editorial board wrote that the name change generated more internal debate than any other category. Their conclusion: the term “AI coding tool” had become meaningless because the products it described had outgrown the description. Tools like Cursor, Claude Code, Windsurf, and LangChain now plan features, write and test code across entire repositories, review pull requests, and in some workflows, ship changes with only light human supervision. The SD Times board called this the “Era of Agentic Infrastructure.”

The reclassification arrives alongside data that makes the shift measurable. A Black Duck survey of over 800 respondents, published June 9, found that AI coding tool adoption has reached 97%. A separate Infragistics Reveal 2026 survey of 250 senior technology leaders found that 57% now cite AI integration into development processes as their top software development challenge, up sharply from prior years. And security researchers at Mozilla’s 0DIN demonstrated that agentic coding tools can be silently compromised through repositories containing no malicious code at all.

Taken together, these data points describe a technology category that has crossed from experimental to load-bearing, and the governance structures around it have not kept pace.

What Changed in the SD Times 100

The 2026 list added eight new honorees to the category, each reflecting a different axis of the infrastructure shift.

Cursor and Windsurf represent AI-native IDEs built from scratch around agentic coding workflows, as opposed to AI bolted onto existing editors. LangChain represents the agent orchestration layer that developers use to build multi-step reasoning systems for products, distinct from the tools developers use to write code with AI assistance. Block, built on the open-source Goose agent framework, addresses multi-agent coordination across large, multi-service codebases. Lovable and Bolt.new represent natural-language application builders that collapse the distance between idea and deployed software.

Returning honorees include foundation model providers (Anthropic, Google, OpenAI, Amazon), embedded assistants (GitHub Copilot), established IDEs integrating AI (JetBrains), deployment platforms (Vercel), feature management systems (LaunchDarkly), and enterprise lifecycle tools (Perforce, Progress).

The SD Times board explicitly distinguished six segments within the category: foundation model providers, AI-native IDEs, embedded assistants inside existing platforms, no-code natural-language builders, deployment and runtime infrastructure, agent orchestration frameworks, and multi-agent orchestration at enterprise codebase scale. The segmentation itself is notable. Twelve months ago, all of these would have been lumped under “AI coding.”

The Unit of Work Has Changed

The SD Times editorial board observed that the fundamental unit of developer work is shifting from “lines of code” to “outcomes delegated.” Senior developers increasingly describe their workday not as writing code but as describing what they want built, reviewing what an AI system produced, and deciding whether to accept, redirect, or escalate.

This language mirrors what the Infragistics Reveal 2026 survey found independently. Among 250 CIOs, CTOs, VPs, and IT directors, 66% cited AI as a primary driver of productivity. But the survey also found that 42% reported incorporating AI into workflows is a major challenge, and half identified recruiting and retaining skilled technology professionals as their biggest business challenge. The demand for expertise in AI governance, integration, and secure development has surged alongside adoption, according to the survey.

The Black Duck data adds a third dimension: the bottleneck has moved from code creation to validation. Their study found that 90% of respondents encounter some issue with AI-generated code, with manual review bottlenecks (52%), security testing delays (51%), and code rework (48%) as the top three. Only about a third of teams reported having full governance in place for AI coding tool adoption. Jason Schmitt, CEO at Black Duck, stated: “Speed without governance is a liability, not an advantage.”

The Governance Gap

When the SD Times board writes that decisions about AI coding tools “now shape engineering velocity, code quality, security posture, and hiring strategy all at once,” they are describing a governance problem that most organizations have not solved.

The board noted that model and tool choice has been pulled up from individual contributors to engineering leadership and, in many organizations, to procurement and security teams. A year ago, picking an AI coding assistant was largely individual preference. Today, the choice of underlying model and tooling affects security review requirements, IP and code-retention policies, cost at scale, and integration with CI/CD, version control, and project management systems.

The most mature organizations, according to the SD Times survey, are standardizing on a small set of approved tools, often tiered by task: a fast embedded assistant for everyday code completion, a more powerful agentic tool for larger multi-file tasks, and a separate orchestration layer for building AI agents that ship as part of the product itself.

Code review practices are being rewritten specifically for AI-generated output. Some organizations require a different review checklist for AI-assisted pull requests, with specific attention to security issues, license concerns, and subtle logic errors that look plausible but are wrong. Others are investing in AI-powered review tools to keep pace with the volume of code now being produced, since human review throughput has not scaled at the same rate as code generation.

The Black Duck study quantified this concern: 64% of respondents said they are moderately or extremely concerned about AI-generated code creating security vulnerabilities, and 84% prefer human oversight as “a critical check in the AI-assisted SDLC.”

The Security Surface

The governance gap is not theoretical. On June 25, researchers Andre Hall and Miller Engelbrecht at Mozilla’s Zero Day Investigative Network (0DIN) published a proof-of-concept attack demonstrating how a GitHub repository containing zero lines of malicious code can give an attacker full shell access to a developer’s machine when opened with an agentic coding tool.

The attack chain works in three steps. First, a normal-looking repository presents standard setup instructions in its README. Second, a Python package is engineered to fail on first use and direct the user to run an initialization command. Third, that initialization command calls a shell script that resolves a DNS TXT record controlled by the attacker and pipes the result to bash. The malicious payload, a reverse shell, never exists in the repository. It is fetched at runtime from DNS, making it invisible to code review, static analysis, and the AI agent itself.

As Help Net Security reported, the researchers noted that “agentic coding tools have access to everything they need for this: private data, including environment variables, credentials, API keys, and local configuration files.” The AI agent follows the setup steps, encounters an expected error, runs the documented fix, and unknowingly opens a connection to the attacker’s server with the developer’s own privileges.

The 0DIN team recommended that agents surface what a command will actually execute at runtime, including the contents of any script it invokes and anything that script fetches, rather than evaluating only the literal command string. This is a non-trivial engineering requirement for tools that are increasingly running autonomously.

Junior Developer Onboarding

The SD Times board flagged another consequence of the infrastructure shift that has received less attention: the impact on how organizations train junior engineers.

If AI tools can produce working code quickly, the differentiating skill for engineers becomes the ability to specify problems clearly, evaluate AI output critically, and debug systems they did not personally write. Engineering leaders are increasingly building this explicitly into training and evaluation rather than assuming it develops naturally.

This connects to a broader concern raised by both the Infragistics survey and the Black Duck study. Infragistics found that demand for expertise in AI governance, integration, and secure development has surged. Black Duck found that 68% of developers say having an automated system for tracking where AI-generated code is deployed is “extremely important.” The skills required to use these tools safely are not the same as the skills required to write code without them.

The Purchasing Decision

The SD Times board laid out four evaluation criteria for engineering leaders choosing tools in this category, each reflecting the infrastructure framing:

First, data handling. Model providers and tool vendors differ significantly in data retention, training-on-customer-code policies, and regional hosting options. This is now a procurement and legal question, not just a technical one.

Second, blast radius. A tool that can autonomously modify multiple files, run commands, or deploy code needs commensurately strong audit trails, permission scoping, and rollback capability.

Third, toolchain fit. Embedded assistants inside existing IDEs have a lower adoption cost than AI-native tools that require developers to change their daily environment, even if the AI-native tools are more capable.

Fourth, measurement credibility. Vendor-reported productivity gains should be treated skeptically until validated against an organization’s own before-and-after data, using engineering intelligence tooling rather than self-reported developer sentiment.

The Infrastructure Question

The SD Times 100 reclassification does not, on its own, change how any organization buys or deploys AI coding tools. But it captures something that the data from Black Duck, Infragistics, and Mozilla’s 0DIN team all point toward independently: these tools have crossed a threshold.

At 97% adoption, AI coding assistance is no longer a competitive differentiator. It is table stakes. The competitive questions are now about governance, security, and the organizational capacity to manage autonomous systems that operate on production codebases. The SD Times board is formally naming what builders already know: AI coding tools are infrastructure, with all the reliability, security, and governance expectations that word implies.

Whether the industry’s governance structures can catch up to the deployment velocity remains the open question. The data, so far, suggests they have not.