Cursor has spent the last year moving from “AI coding assistant” into something much more ambitious: a vertically integrated agentic software engineering stack. Yesterday’s release of Composer 2.5 makes that direction impossible to ignore.

This is not just a faster autocomplete model. Cursor is explicitly optimizing for long-horizon coding agents that can plan, execute, recover from failures, and stay coherent across large multi-step engineering tasks.

The Problem It’s Solving

Most coding models still break the moment a task stops being local.

They can generate a React component, patch a bug, or refactor a function. But once the task becomes multi-file, infrastructure-heavy, or operationally ambiguous, the cracks show quickly. Context drifts. Tool calls fail. The model loops. Terminal sessions become chaotic. Long-running execution loses coherence.

That is the real bottleneck in agentic software engineering right now.

Cursor says Composer 2.5 was specifically trained to improve “long-horizon agentic tasks” and follow complex instructions more reliably. The company also claims substantial behavioral improvements around effort calibration, communication style, and execution consistency. (Cursor)

This matters because the next phase of AI coding is no longer about code generation quality alone. It is about whether agents can operate inside real engineering environments without constantly collapsing under state management and execution complexity.

How Composer 2.5 Actually Works

Under the hood, Composer 2.5 continues Cursor’s strategy from Composer 2: domain-specialized reinforcement learning for software engineering workflows.

Cursor’s technical report for Composer 2 describes a two-stage training pipeline:

1. Continued pretraining on a base model
2. Large-scale reinforcement learning inside real software engineering environments and agent harnesses (arXiv)

The important detail is not the benchmark number. It is the training environment.

Cursor is training models directly inside the same operational harness used by deployed coding agents — including terminals, tools, multi-step execution chains, and realistic repository interactions. That creates a feedback loop where the model is optimized for actual agent workflows instead of isolated benchmark prompts. (arXiv)

Composer 2.5 reportedly improves:

• Long-running task reliability
• Multi-step execution planning
• Instruction adherence
• Agent communication behavior
• Effort calibration during coding workflows (The Indian Express)

There is another important layer here: infrastructure economics.

Composer 2 originally gained attention because Cursor delivered strong coding performance at dramatically lower token costs than frontier proprietary models. Cursor positioned it as a cheaper alternative to systems from Anthropic and OpenAI. (Cursor)

That pricing advantage came with controversy.

After launch, developers discovered Composer 2 was built on top of Moonshot AI‘s open-weight Kimi K2.5 model. Cursor later acknowledged this publicly and admitted it should have disclosed the base model earlier. (Business Insider)

Composer 2.5 reportedly still builds on the same Kimi base checkpoint, but Cursor is increasingly differentiating through RL infrastructure, agent training environments, and deployment tooling rather than raw foundational pretraining. (The Indian Express)

That is a very different strategy from the “train everything from scratch” approach most frontier labs market publicly.

What Developers Are Actually Using It For

The interesting part about Cursor’s recent releases is that they increasingly resemble operational AI infrastructure rather than a standalone IDE.

Over the last few months, Cursor has launched:

• Cursor SDK for programmatic agents
• Cloud development environments for agents
• Bugbot autonomous debugging systems
• Multi-agent execution workflows
• Cursor 3, a broader agentic workspace layer (Cursor)

Composer 2.5 sits in the middle of that stack.

The target use case is no longer “help me write code faster.” It is:

• Autonomous repository maintenance
• Long-running refactors
• Infrastructure migration workflows
• Multi-step debugging
• Agent-managed terminal execution
• PR generation and validation
• Extended software tasks that may run for hours

That direction aligns closely with where the broader MCP and agentic ecosystem is heading.

The future competitive advantage is not just model intelligence. It is orchestration quality: tool reliability, memory handling, execution recovery, context persistence, and operational safety across long-running workflows.

This is exactly why infrastructure companies like Gentoro and MCP ecosystem players like Glama.ai matter increasingly in the stack. Models are becoming interchangeable faster than orchestration layers are.

Why This Is a Bigger Deal Than It Looks

Cursor is quietly proving something the broader AI market still underestimates:

Specialized agent training may matter more than raw frontier scale for real-world developer workflows.

Composer 2.5 is not trying to be a universal reasoning model. It is being optimized aggressively for software execution environments.

That shift has major implications.

The AI coding market is rapidly splitting into two layers:

• Foundation model providers
• Agent orchestration and execution platforms

Cursor appears to be betting the second layer becomes more defensible over time.

That also explains why the company is investing heavily in infrastructure. Reports indicate Cursor plans to train Composer 2.5 using xAI compute infrastructure with tens of thousands of GPUs. (Business Insider)

The strategic signal here is important:
AI coding is moving from “chatbot in an editor” toward persistent software agents operating inside full execution environments.

And once that happens, infrastructure quality becomes the actual moat.

Availability and Access

Composer 2.5 is now available through Cursor.

The release follows Cursor’s broader push into autonomous coding systems and arrives during intensifying competition from Claude Code, OpenAI, and other agentic developer tooling platforms. (WIRED)

The bigger story is not whether Composer 2.5 wins a benchmark cycle. It is that Cursor is steadily building an operational stack for autonomous software engineering.

The IDE war is turning into an agent infrastructure war.

Follow for more coverage on MCP, agentic AI, and AI infrastructure.

Most people ask:

“What’s the best AI coding tool?”

After building 4 AI-assisted projects, I realized the better question is:

“Which tool fits each stage of the workflow?”

My current workflow:

• ChatGPT → ideas and prompts
• Windsurf → rough project structure
• Codex → fix and refactor logic
• Cursor → production polish

Using this workflow, I built:

1. Parent-child emotional connection app
2. English learning platform
3. AI video project
4. Affiliate marketing system

Biggest lesson:

AI doesn’t magically replace developers.

It reduces friction between:
idea → prototype → working product.

That’s where the real leverage is.

For years, Microsoft’s open source strategy was mostly about cloud adoption and developer ecosystems. At Open Source Summit North America 2026, the company made something much bigger clear: it now sees open protocols and agent infrastructure as the next foundational layer of computing.

And buried inside that announcement was the real signal for the MCP ecosystem.

The Problem It’s Solving

Right now, most AI agents are still trapped inside fragmented execution environments.

Every framework has its own tooling model. Every cloud vendor has its own orchestration stack. Tool access, memory handling, governance, and runtime execution are all implemented differently depending on the platform. That fragmentation becomes a serious problem once agents move from demos into production infrastructure.

Microsoft’s latest messaging is essentially acknowledging that agentic systems need the equivalent of what Kubernetes became for containers: portable infrastructure primitives and open interoperability standards. ([Microsoft Open Source][1])

That is where MCP starts becoming strategically important.

Model Context Protocol was initially framed as a standardized interface for connecting models to tools and external systems. But the ecosystem around it has evolved rapidly. MCP is increasingly becoming a shared interoperability layer for agent execution environments, tool routing, UI delivery, and cross-platform orchestration. ([Wikipedia][2])

Microsoft’s Open Source Summit announcement strongly suggests the company understands that shift.

How Microsoft’s Open Agentic Stack Actually Works

In its official summit post, Microsoft explicitly described its vision around “frameworks, protocols, and governance for AI agents” and repeatedly emphasized the need for agents to operate “across frameworks, clouds, languages, and runtimes.” ([Microsoft Open Source][1])

That wording matters.

The company is no longer talking about isolated copilots. It is talking about infrastructure portability.

Microsoft’s announcement centered around several major layers:

• Azure Linux 4.0
• Azure Container Linux
• Open governance tooling
• Secure software supply chain infrastructure
• Open agentic system interoperability ([SDxCentral][3])

The Linux layer is especially important here.

Microsoft says Azure Linux 4.0 is being positioned as a hardened operating system foundation for cloud-native and AI-native workloads. The company also confirmed that Linux infrastructure now underpins large parts of Azure’s AI stack, including services tied to GitHub, Microsoft 365, and ChatGPT-scale deployments. ([Cloud Native Now][4])

That changes the MCP conversation significantly.

MCP servers do not exist in isolation. Real-world deployment requires:

• Sandboxed execution
• Tool governance
• Authentication layers
• Runtime isolation
• Observability
• Secure software supply chains
• Container orchestration
• Cross-agent communication

In other words, MCP adoption eventually becomes an infrastructure problem, not just a protocol problem.

Microsoft’s summit positioning suggests the company increasingly sees agent interoperability and runtime portability as core platform primitives — similar to how Kubernetes standardized container orchestration a decade ago.

What Developers Are Actually Building With MCP

The MCP ecosystem has quietly moved far beyond simple tool calling.

Developers are now using MCP to build:

• Multi-agent orchestration systems
• Secure enterprise tool gateways
• Agent memory layers
• Remote execution environments
• Interactive AI application interfaces
• Cross-model tool portability
• Agent observability pipelines

That evolution is happening fast across the open ecosystem.

The Agentic AI Foundation recently positioned MCP as a key interoperability layer for “secure, scalable agentic AI systems” operating across tools, models, and platforms. ([Linux Foundation][5])

At the same time, infrastructure companies are racing to operationalize the stack around it.

Platforms like Glama.ai are increasingly focused on MCP gateway quality, discoverability, and secure tool integration. Companies like Gentoro are working on orchestration and infrastructure layers for enterprise-grade agent systems.

This is the important shift:
the protocol itself is becoming less valuable than the operational ecosystem forming around it.

And Microsoft appears to be positioning Azure directly underneath that future stack.

Why This Is a Bigger Deal Than It Looks

The most important part of Microsoft’s announcement was not Linux.

It was the company openly framing agentic AI as an open systems problem rather than a proprietary model problem.

That is a major strategic distinction.

The AI industry spent the last two years competing almost entirely on model intelligence. But production agent systems introduce a completely different bottleneck:

• interoperability
• execution reliability
• governance
• runtime security
• infrastructure portability
• software supply chain trust

Those are open infrastructure problems.

That is also why Open Source Summit North America 2026 heavily centered discussions around AI infrastructure, supply chain security, embedded systems, and agentic AI on the same stage. ([Cloud Native Now][6])

The ecosystem is converging around a new reality:
agents are becoming distributed systems.

And distributed systems historically standardize around open protocols faster than proprietary interfaces.

That creates a very favorable environment for MCP.

Availability and Access

Microsoft’s announcements around Azure Linux 4.0 and Azure Container Linux were unveiled during Open Source Summit North America 2026, with broader rollout activity expected around Microsoft Build. ([SDxCentral][3])

The more important takeaway is strategic:
Microsoft is increasingly treating agent infrastructure as a first-class cloud layer.

And once cloud vendors start organizing around open agent interoperability, MCP stops looking like a niche protocol and starts looking like foundational infrastructure.

Follow for more coverage on MCP, agentic AI, and AI infrastructure.

This is Part 2 of an ongoing investigation. Part 1 documented the initial discovery of a coordinated GitHub follow botnet — 8 accounts with Jaccard following-list similarity of 0.99+ across ~29,800 entries each, evading cross-follow detection entirely.

In Part 1, I identified 8 accounts operating as a coordinated follow botnet and showed the statistical fingerprint that exposed them. After publishing, I kept pulling.

Subsequent analysis expanded the cluster to 9 accounts, recovered infrastructure linkage to a specific GitHub identity, and mapped the generation pipeline responsible for all 552 repositories across the cluster. The pipeline left recoverable artifacts in every repository it produced.

Here is what the data shows.

The Cluster Expanded

Running Jaccard similarity analysis against the original 8 accounts and their extended follower graphs surfaced a ninth account: lynewinter.

Jaccard similarity against mariwatts: 0.9898.

The same methodology that identified the original 8 applies here. A similarity coefficient of 0.9898 across ~29,800 following entries does not occur between unrelated accounts. At this scale, unrelated GitHub users do not organically converge on near-identical follow graphs.

The confirmed cluster is now 9 accounts:

canestein, hazexone, domcomit, kylehyne, jaderytm,
vierystein, hanyvert, mariwatts, lynewinter

552 Repositories, One Pipeline, 34 Minutes

Each of the 9 accounts has between 57 and 63 public repositories. Total across the cluster: 552 repositories.

Every repository was created on May 12, 2026. Fetching the first repository per account and extracting an HTML comment embedded in every generated README reveals the exact creation timestamp and a job identifier for each:

2026-05-12 11:10:39  |  hanyvert    |  SwapLink    |  job=48099
2026-05-12 11:18:46  |  jaderytm   |  GasSync     |  job=39412
2026-05-12 11:27:52  |  hazexone   |  BitForge    |  job=63871
2026-05-12 11:30:00  |  canestein  |  BlockLink   |  job=51606
2026-05-12 11:33:07  |  mariwatts  |  MintChain   |  job=82564
2026-05-12 11:35:37  |  vierystein |  HashSync    |  job=20845
2026-05-12 11:38:58  |  kylehyne   |  SmartLink   |  job=38575
2026-05-12 11:42:07  |  lynewinter |  YieldChain  |  job=78012
2026-05-12 11:44:30  |  domcomit   |  ProjectCloud|  job=26977

All 9 accounts provisioned across a 34-minute window. Job IDs are non-sequential, consistent with a job queue system dispatching parallel workers rather than a simple sequential script.

The comment format embedded in every README:

<!-- fallback_BlockLink_20260512113000_51606 -->

fallback_ is a named prefix — consistent across all accounts and repos. The timestamp and job ID vary per generation run. This is a recoverable generator fingerprint present in all 552 repositories.

The central finding of Part 2 follows directly from this: a single automated pipeline provisioned all 9 accounts and generated all 552 repositories in a 34-minute window. Every subsequent finding — the template leak, the commit metadata, the email domain — is evidence of that same pipeline’s operation.

Repo Contents Are Hollow

Fetching file trees and raw content from sampled repositories confirms the repositories contain no functional code.

A representative Python file (blocklink.py, 1,656 bytes):

class BlockLink:
    def run(self) -> bool:
        try:
            self.logger.info("Starting BlockLink processing")
            # Add your main logic here
            self.logger.info("Processing completed successfully")
            return True

The comment # Add your main logic here is the entirety of the implementation. Every repository follows this pattern: a class stub, a logging setup, an argparse entry point, and a test file that imports and instantiates the stub. No logic. No purpose. The repositories exist as props.

Repo names follow a consistent [Word][Suffix] pattern where suffixes are drawn from a fixed set: Core, Chain, Sync, Vault, Forge, Link. Names and descriptions are AI-generated. Stars: zero. Forks: zero, across all 552.

A Template Leak Confirms Shared Generation

The LICENSE section of every generated README contains a hardcoded URL pointing to mariwatts regardless of which account’s repository it appears in:

From canestein/BlockLink:

See the LICENSE file at https://github.com/mariwatts/BlockLink/blob/main/LICENSE

From lynewinter/YieldChain:

See the LICENSE file at https://github.com/mariwatts/YieldChain/blob/main/LICENSE

The account name substitution in the generator did not apply to the LICENSE URL field. mariwatts appears as the base account in the generator template. The substitution pattern replaced account names in repo metadata and README body text but missed this field.

Pipeline Linked to a Single GitHub Account via Authenticated Commit Metadata

Every repository across all 9 accounts contains commits with the following co-author line:

Co-authored-by: Hajigur <66867581+hajigur69@users.noreply.github.com>

The format [email protected] is GitHub’s authenticated noreply scheme. GitHub generates this address from the account’s internal numeric ID. The ID is immutable and assigned at account creation.

Fetching commits from hajigur69‘s own repository (Cloud9, created February 2, 2026) confirms the same identifier:

Author: Hajigur | 66867581+hajigur69@users.noreply.github.com

The same authenticated GitHub ID (66867581) appears both in the cluster commits and in commits authored directly by hajigur69.

hajigur69 is pipeline-linked. GitHub account created June 13, 2020. 903 followers. 679 following. Public bio: lamer.

Pipeline-Associated Infrastructure: carox.tech

Two accounts in the cluster — canestein and lynewinter — use a custom domain in their git commit author fields rather than GitHub’s noreply format:

canestein  →  [email protected]
lynewinter →  [email protected]

These addresses appear in the git author field of every commit on those accounts, recorded at commit time by the pipeline’s local git configuration.

WHOIS on carox.tech:

Creation Date:  2025-07-19
Updated Date:   2025-08-01
Registrar:      Namify Domains Inc
Name Server:    raphaela.ns.cloudflare.com
Name Server:    uriah.ns.cloudflare.com

DNS enumeration:

A record:   none
MX records: route1.mx.cloudflare.net (priority 44)
            route2.mx.cloudflare.net (priority 84)
            route3.mx.cloudflare.net (priority 28)
TXT record: v=spf1 include:_spf.mx.cloudflare.net ~all

No web presence. MX records point to Cloudflare Email Routing — a free service that forwards custom domain email to an external inbox. The domain functions exclusively as an email forwarding layer. The destination inbox is not publicly recoverable.

The 12-day gap between creation and update date is consistent with the time to configure email routing after registration. Beyond that, the domain predates the repo generation by several months — it was in place before the pipeline ran, not stood up alongside it.

Additional Artifact: Malformed Co-Author Address

In addition to the hajigur69 co-author signature, a second co-author line appears on the GOOD commit across 8 of the 9 accounts:

Co-authored-by: v <v@users.noreply.github.com>

GitHub’s authenticated noreply format is [email protected]. The numeric ID prefix is machine-generated by GitHub’s credential system at authentication time — it cannot be produced by typing a username, only by pushing through a properly authenticated git session. The address [email protected] contains no such prefix and does not match the format GitHub generates for any account.

There is a GitHub account with the login v (ID: 627846, created 2011). Its correctly formatted noreply address would be [email protected]. The string present in these commits is not that address.

The most likely explanation is a misconfigured git identity on whichever machine ran the pipeline — a user.email set to [email protected] rather than the proper authenticated format. Whether placeholder or misconfiguration, the effect is the same: it was baked into the pipeline’s commit template and executed across the majority of accounts unchanged. It’s a pipeline artifact, not a deliberate attribution.

What the Repos Are Actually For

The following is inference from the confirmed findings above, not an independently verified claim.

The repositories are not the product. Hollow stubs with no stars and no forks have no value on their own.

The follow botnet from Part 1 is the product. The accounts need to look like real developers for the botnet to work — real developers have repositories. The 552 repos are set dressing: enough surface area to pass a casual profile inspection without requiring the operator to produce anything functional.

The pipeline’s role is to manufacture that surface area at scale and speed. Nine accounts, 552 repositories, 34 minutes. A human doing this by hand would take weeks and produce inconsistent output. Automation produces it uniformly and leaves the fingerprints documented above.

What the inflated follower counts are ultimately used for — social proof laundering for phishing accounts, legitimacy for malicious package distribution, resale of aged accounts — is not established by this data. The confirmed finding is the coordination and the shared infrastructure. The downstream use is an open question.

The follower graph itself appears to be the primary maintained asset. ~29,682 developers curated into a target population, followed across 9 aged accounts. The repos are disposable scaffolding.

Summary of Confirmed Findings

What This Demonstrates

The finding is the pipeline. A single automation system provisioned 9 apparently independent GitHub accounts, generated 552 repositories across all of them in 34 minutes, embedded the same co-author identity in commits across the cluster, and left recoverable fingerprints in every generated file — all while the accounts maintained behavioral patterns designed to evade the most common detection heuristic (cross-following).

Attribution was possible here because of operational mistakes: a hardcoded template account, an unformatted co-author string, and email domain leakage in git config. A pipeline with better hygiene — consistent noreply formatting, template substitution coverage, and throwaway email addresses — would produce the same coordinated behavioral output with substantially less recoverable linkage.

This analysis identifies operational linkage and shared infrastructure; it does not independently establish the real-world identity of the individual operating the pipeline.

The hajigur69 co-author fingerprint that surfaced in this investigation didn’t start here. The same identifier — same numeric ID, same fallback_ generator artifact — appears in an earlier operation running nine months before this botnet was provisioned: a crypto spam network with fabricated commit histories, purchased star services, and 163 active pip install vectors targeting developers through search poisoning.

Part 3 covers that earlier operation and what it tells us about the infrastructure behind both.

Read Part 3 →

When a group of academics started making open-source robotics hardware, a generation of roboticists got years of their lives back. Now, the bigger challenge is getting robots to think—and that’s starting to be open-sourced too.

The shift is still early, but companies including Hugging Face, Nvidia, and Alibaba have all made significant bets on open-source robotics in the last two years, releasing tools and models aimed at the higher-level work of getting robots to reason, decide, and act.

The open source movement that accelerated other AI applications is now being applied to the problem of making robots smarter. If these attempts to bring AI to robotics with open-source platforms succeed, the barrier to building a capable robot could fall as fast as the barrier to building an AI application did.

The world ROS built

Open-source robotics software has been around since the mid-1990s, with early projects like Carnegie Mellon’s Inter-Process Communication package and the Player project in the early 2000s laying the groundwork. But these were often tied to specific research groups, and the field remained fragmented.

The Robot Operating System, ROS, changed that when it made its debut in 2007. By bundling tools and attracting more users, it became the de facto standard. The story of open-source robotics, in many ways, starts there.

Despite its name, ROS is not actually an operating system. Rather, it is a software framework that sits on top of Linux and handles robotic fundamentals like moving data between components, talking to hardware, building maps, planning paths, and supporting developer tools, such as data logging and visualization. Before ROS, every robotics team wrote that infrastructure themselves. It often took a year or two before a lab could get to the research it actually cared about.

Brian Gerkey, who helped build ROS in the mid-2000s, says he was drawn to the project because of how much open source had already changed the world, pointing out that nearly the entire internet is built on it.

“I’m a tool builder, and I like to share everything as openly as I possibly can, because I think that’s where we get the most impact out of what we build,” says Gerkey, Board Chair at Open Robotics and now CTO at Intrinsic, a robotics and AI unit of Google.

As it was developing, the AI community largely took the same approach, sharing research, models, and data openly, and the field accelerated faster than almost anyone predicted. Now some of those same advancements are arriving in robotics.

Open-source AI for robotics

Computer vision, once a hard problem, has advanced dramatically in just a few years, says Spencer Huang, Nvidia’s director of product for robotics. What once required significant expertise can now be done in a few lines of code. Simulation tools have become accurate enough to be useful for training, and access to the tooling that once required a specialized lab is now widely available, much of it open source.

“To get into robotics, you no longer need a Ph.D.,” he says. The result is a much larger pool of people who can contribute, and the field is starting to look less like a specialized discipline and more like a platform that anyone can build on.

Nvidia has built out an open-source robotics stack that covers the full development pipeline. Its Cosmos world models generate synthetic training data and simulate physical environments. Its GR00T models give robots the ability to reason about and execute complex tasks. And its Isaac frameworks handle the orchestration that ties training, simulation, and deployment together. Not everyone needs to train the robots from scratch, Huang says, and most people probably shouldn’t.

“If you gate pre-training, the field just never grows,” he says. “We should be able to provide a high-quality, state-of-the-art pre-trained model that anyone can go and take and fine tune for their own purposes.”

All of Nvidia’s open-source models live on Hugging Face, the open-source AI platform that has become the default place to share models and datasets. Hugging Face launched LeRobot, a community platform for robotics AI, in May 2024. Since its launch, the number of robotics datasets on the platform grew from 1,145 at the end of 2024 to more than 58,000 today, making it the single largest dataset category on the hub.

Hugging Face has also moved into hardware, acquiring robotics company Pollen Robotics. The acquisition came from a realization that software alone was not enough, according to Clement Delangue, Hugging Face’s CEO. The goal, as with the software, was to bring more people in.

The contributors to LeRobot include the biggest names in the industry, academic labs, and hobbyists building robots in their spare time. For instance, Alibaba released RynnBrain earlier this year, an open-source foundation model for physical AI that the company claims outperforms comparable offerings from Google and Nvidia on benchmarks. That diversity of projects, Delangue says, is important.

“It is not just one model or one dataset or one hardware,” he says. “It is a lot of small contributions that everyone can be part of.”

Commercial incentives muddle the field

The stakes, Delangue says, go beyond convenience. A world where only a few proprietary systems control the robots in people’s homes is a concerning one. “Having robots at home that you don’t really understand, that you don’t really control, that a few people in Silicon Valley control is a scary thought,” he says. “Open source gives an alternative path.”

But getting there is not straightforward. The open sourcing happening now looks different from what produced ROS, which emerged largely from academics pooling their work with no commercial stake in the outcome. The biggest contributors today are companies with clear business reasons to want more people building on their platforms. That’s not necessarily a bad thing, says Bill Smart, a professor at Oregon State University who was part of the early open-source robotics community. But the incentives are worth being aware of.

He also worries that the lowered barrier to entry has a downside. Researchers coming from AI without a robotics background are sometimes solving problems the field already solved. A newcomer might spend a week training a neural network to move a robot’s hand from one point to another, unaware that the same task can be accomplished with a few lines of code using decades-old techniques. The incentives are not always pointing in the same direction as the progress.

Smart is not without hope though. Whatever the motives behind the open sourcing, he says, the effect is real. More people are in the field than ever before, the tools are genuinely easier to use, and the community is bigger and more diverse than anything that existed when ROS was getting started.

“Anyone can make a robot move now,” he says. “As an old tech guy, that makes me happy and sad, because I’m no longer special.”