A confession: stdlib doesn't have an AI-use policy.

It isn't for lack of trying. There's an open RFC proposing guidance on AI usage—citations to prior art, disclosure requirements, a carve-out for "good first issue"^[1]—and a draft PR with the policy text, both of which are from December 2025.^[2] Both are still open. Both are still drafts.

It's not because AI usage is hypothetical here, either. We've had stdlib core contributors participating in METR's randomized trial on AI's effect on experienced open-source developers since 2025. Philipp Burckhardt, one of stdlib's co-maintainers, wrote up his experience on the project blog, including which tools he uses and how his workflow changed.^[3] More recently, Karan Anand described using the codebase itself as the prompt.

So: we use these tools, we've said so in public, and (beyond some check boxes in our PR template) we still haven't codified what we expect from anyone else. We've gotten stuck, and one of the sticking points has been an obvious one—discomfort with publishing a rule we're not going to hold ourselves to.

This is a real objection. It's also, I've come to think, the wrong one, and we're not the only project stalling out on it. The question isn't whether AI is being used on this project. It's whether there's anything written down that a contributor can read.

Plenty of projects got past this. Melissa Weber Mendonça keeps a running catalog of what's been published;^[4] Kate Holterhoff's RedMonk survey was up to eighty-six policies as of April 2026, dimensionalized by stance and primary concern;^[5] CHAOSS's AI-alignment working group runs a companion list with an incident-and-discussion layer.^[6]

Given the scope of the discourse around AI usage in open source, this is a strikingly small corpus—and a young one.^[7] Nobody is late to a settled consensus here. As James Fredley put it, after a tier-by-tier read from the primary documents: "there is no single industry-wide standard yet."^[8]

What the policies themselves agree on is narrower than it first looks. Stance splits three ways—permissive, ban, undecided—and the stated concerns split at least three ways again: code quality, licensing liability, and ethics. Where they do line up is on something small and specific: contributors are responsible for understanding what they submit. Sean McLellan's case for the Assisted-by: Git trailer states the reasoning plainly—using Co-authored-by: claims shared authorship, and with it accountability. A tool can't hold up its end of that bargain.^[9] The trailer itself is one lightweight implementation; the claim underneath it is what travels.

Accountability is what the trailer is for; responsibility is what the policies actually ask of you. Part of that is legal clarity—the human is the sole author of the commit, whatever helped them write it. But what responsibility looks like in practice depends on the author's relationship to the project.

Two mechanisms tend to get bundled together here. Disclosure is a record-keeping rule—the Assisted-by: trailer, the AI-assistance section of our own PR template—and what it produces is provenance: what helped write this. Everyone takes part in that one. Gating is a permission rule: who may use these tools, on what, with how much latitude. What follows is an argument about the gate, not the disclosure.

A maintainer who merges a bad change is still there in three months when it breaks. They wrote the module it broke, or reviewed it, and they will be the one bisecting at midnight to find out why the build went red. Responsibility, for them, isn't a claim. It's a structural fact about where they're standing.

An infrequent contributor who submits a bad change usually isn't there. Not out of bad faith—that's simply what infrequent means. Whatever I take responsibility for this means when they sign off on their PR, it can't mean quite the same thing as it does for a maintainer. The position it's said from is different.

So a policy that says you're responsible for what you submit is asking two structurally different things of two structurally different people, while looking like it asks one thing of everyone. That's roughly where our hypocrisy objection came from. It's also, it turns out, where the objection comes apart.

The word for it

There's a word for a rule that behaves this way, and I'm going to use it even though it's unfamiliar, because the precise word does work the familiar ones don't.

A rule can be defeasible: correct as a default, and properly overridden when the situations it applies to genuinely differ. The everyday version is the speed limit is 45, except for the ambulance. The rule holds. The exception is principled. The exception doesn't retroactively invalidate the rule.^[10]

The open-source policy version goes something like this:

There's a naïve consistency heuristic: don't require of others what you wouldn't do yourself. It's correct for most governance choices. Don't require signed commits if you don't sign yours. Don't require test coverage your codebase doesn't have.

But it's defeasible where the situations genuinely differ, and AI-use policy is the clean case. A maintainer using AI owns the fallout, holds the project's mental model, and can recognize when the output is wrong. A first-time contributor using AI may be offloading understanding to the tool—producing work they can't fully vouch for—and has no accountability chain yet. Those are different situations. Different rules are warranted.

The distinction comes down to what's underneath the rule. Because I own the fallout in a way you don't is principled. Because I said so isn't. The trust ledger is what makes the difference legible, and it's why "just be consistent" is worse advice than it sounds.

The naïve-consistency rule is itself defeasible. That's the whole thing. It's a good default, it does honest work most of the time, and this is one of the situations where the exception is warranted rather than merely convenient.

Ghostty's AI_POLICY.md lays out the usual disclosure-and-human-in-the-loop rules for contributions, and then closes with this:^[11]

These rules apply only to outside contributions to Ghostty.
Maintainers are exempt from these rules and may use AI tools at their discretion; they've proven themselves trustworthy to apply good judgment.

Two sentences. The first says this policy is for you, the contributor, not for me. The second says why. And the why isn't brash authority—it's a claim about accumulated context. They've proven themselves. You can agree with it, or push back on it, or ask what the proving consisted of.

So: you (potential contributor) can weigh and evaluate the claim. Naming the asymmetry on the page—rather than writing a symmetric-sounding rule and then quietly not applying it to yourself—is the move. It's two sentences. It's been shipped, in public. Just like a good CONTRIBUTING.md, the honest accounting is a kindness.

"You're just formalizing hierarchy"

There's a critique here I too feel the pull of, and it might be part of what keeps projects like ours from making the move. You're building a hierarchy where maintainers get one rule and contributors get another.

The hierarchy is already there, and has been the whole time—and it's not just maintainers vs. contributors, there are often tiers of trust (maintainers is just a useful shorthand). A maintainer with three years of context on a codebase reads a stranger's PR differently from how they read their own or one of a long-time contributor. The maintainer/reviewer knows what's load-bearing, what's under active refactor, which review objections are terminal versus fixable. None of that is malicious; most of it isn't even conscious. It's what accumulated context does. Call it a "trust ledger" (a term I'll return to in a subsequent post).

What a written policy does is convert an existing asymmetry from invisible-and-unchallengeable into visible-and-contestable. That's an accountability gain, not a hierarchy invention. Writing it down is what makes it something you can be held to.

If you've been sitting on a policy because the but-I-don't-hold-myself-to-this objection kept stopping you: note it, acknowledge that it does ethical work worth respecting in most contexts, and it doesn't apply here in the way it feels like it does. The situations genuinely differ. Different rules are principled when the difference has a reason you can be held to.

I'm not saying every project should ship one; whether it's right for a given project depends on more than fits in a piece this size. What I am saying is that this particular reason for stalling—the hypocrisy-avoidance reason, the one that stopped us—is dissolvable.

Take it, if it's useful. Ours has been open since December; I'm hoping this is a step towards closing it out.

Mara Averick is a developer advocate at Quansight and contributor experience lead for stdlib.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

Acknowledgments

This work was supported in part by the National Science Foundation under Award No. 2449410.

Disclaimer: Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.

JavaScript does not suffer from a shortage of ways to draw a chart. There are mature libraries for quick statistical graphics, dashboards, bespoke data-driven documents, publication-quality figures, and nearly every use case in between. Some are small and focused. Others are entire ecosystems in their own right.

So, naturally, stdlib is building another one.

At first glance, this may look like a textbook case of not-invented-here. It is not. We are not building a plotting library because we think the existing libraries are bad. Quite the opposite: JavaScript has some of the best visualization tooling of any programming ecosystem. We are building one because stdlib is trying to solve a different problem.

The gap we care about is not at the level of pixels. Current JavaScript charting libraries can draw lines, symbols, axes, legends, and tooltips just fine. The gap is at the level of workflow: how plotting fits into numerical computation across the browser, the REPL, the command line, on the server, and in desktop windows.

That is the problem we have not seen addressed as one coherent system.

TL;DR

We are not building another rendering engine.

We are building a plotting layer for scientific JavaScript: one which understands n-dimensional arrays (a.k.a., ndarrays), works naturally in the Node.js REPL, can render to an Electron-powered desktop window, participates in command-line workflows, can be embedded in a browser, exposes a programmatic event model, and provides a path from exploratory analysis to publication-quality graphics.

For rendering and interaction, we are building on Vega, a declarative visualization grammar and runtime which produces canvas and SVG output in the browser, and supports static rendering on the server. Vega gives us a robust target specification and rendering backend. stdlib provides the scientific data model, ergonomic plotting APIs, runtime integrations, object model, viewers, editing tools, documentation, testing, and long-term compatibility layer around it.

Put another way: Vega handles the pixels. We are building the workflow.

Start where the computation happens

Most JavaScript visualization libraries treat the browser as the center of the universe. That makes sense. JavaScript was born in the browser, and the browser provides a rich environment for interaction, layout, animation, and graphical output. For many applications, targeting a DOM element on a web page is the right abstraction.

But stdlib does not live only in the browser.

It also lives in Node.js scripts, REPL sessions, command-line programs, batch jobs, data pipelines, web services, and other server-side environments. If plotting is going to be a first-class part of scientific computing in JavaScript, it needs to feel at home in all of those places.

When I am exploring a dataset, I do not want to create a browser application just to see whether two variables are correlated. I do not want to scaffold a project, write HTML, start a development server, move my data across an application boundary, and attach a chart to a DOM node. I want to start the stdlib REPL, load my data, create a plot, and keep working.

That should not be a radical request.

The plotting work currently underway in stdlib deliberately separates a chart from how that chart is viewed. The same chart can target stdout, a browser, or an Electron-powered desktop window. A browser remains a first-class destination, but it is not assumed to be the only destination.

This matters for exploratory data analysis. Plotting is not merely a final presentation step. It is part of the feedback loop through which we inspect data, question assumptions, identify structure, discover errors, and decide what to compute next. A plotting library for scientific computing should begin where the computation happens, not require users to move the computation somewhere else.

Numerical data is not always a JSON table

A great deal of JavaScript visualization is organized around arrays of objects (often referred to as "tidy datasets"; e.g., see Vega and Observable Plot):

[
    { 'x': 1.0, 'y': 3.2 },
    { 'x': 2.0, 'y': 4.8 },
    { 'x': 3.0, 'y': 4.1 }
]

That is a perfectly reasonable interchange format centered on JSON. It is readable, flexible, and maps naturally to rows and fields. It is not, however, necessarily the data model used by a numerical program.

Scientific code routinely works with typed arrays, multi-dimensional arrays, strided views, non-contiguous memory layouts, stacks of matrices, and arrays with explicit shape and data type information. Those objects are not incidental implementation details. They are fundamental abstractions around which numerical software is built.

In stdlib, we want users to be able to provide the same ndarray objects they use for statistics, linear algebra, simulation, and signal processing directly to plotting APIs. Users should not need to manually flatten, reshape, transpose, copy, or serialize their data just to look at it.

Our work-in-progress line-chart implementation already accepts ndarray-like inputs, determines how to organize those inputs as chart data, and lowers the result into Vega datasets, scales, axes, and marks.

const uniform = require( '@stdlib/random/uniform' );
const Float64Vector = require( '@stdlib/ndarray/vector/float64' );
const LineChart = require( './../lib' );

// Define minimum lower and upper bounds for uniformly distributed random numbers:
const a = new Float64Vector( [ 10, 20, 30, 40, 50 ] );
const b = new Float64Vector( [ 20, 30, 40, 50, 60 ] );

// Generate 5 datasets containing 100 rows of data:
const y = uniform( [ 100, 5 ], a, b );

// Create a new chart instance:
const chart = new LineChart( y );

This is not the sort of feature which produces a flashy landing-page demo. But it is foundational.

A plotting library within stdlib should understand the data structures produced by the rest of stdlib. Anything less would make plotting feel like an attached application rather than an integrated part of the numerical computing environment.

A plot should be a live computational object

A plot is often treated as a terminal artifact: provide some data and options, create an SVG or canvas element, and move on. That model is useful, but incomplete.

Plots change. Data arrives. Parameters are updated. Axes are rescaled. Themes are switched. A server may need to notify a connected client. A host application may need to export an image after a computation finishes. A stream may need to trigger an update without any DOM event occurring.

Vega signals provide an excellent reactive model within the visualization runtime. Signal values can respond to input events, external API calls, and upstream changes, with updated values propagating through the visualization dataflow. But signals inside a visualization runtime are not a replacement for a general-purpose event model across a JavaScript object graph.

In our current work, stdlib plotting objects use event emitters throughout the programmatic API. Changes to child objects propagate upward, allowing a chart, server, viewer, logger, or another consumer to respond. A change can result in a visual update, but it could just as readily result in writing a file, emitting a message over a socket, recording an audit log, or initiating some other non-DOM action. This is particularly important on the server, where there may be no user-interface element to bind and no mouse or keyboard event to observe.

It is also why we are investing in debug logging throughout the plotting stack. Once a visualization becomes reactive, understanding what changed, where that change originated, and why a render occurred becomes essential. Plotting should not be a black box which mysteriously redraws itself. Failure should be easy to diagnose.

In other words, we are treating a plot as a live computational object, not just a picture.

Code and GUI should meet in the middle

There is a longstanding tension in scientific plotting between code and graphical editing. Code is reproducible. It can be reviewed, versioned, rerun, tested, and applied consistently across many figures. A graphical interface, however, can be much more efficient for the final stages of figure creation: adjusting padding, changing font sizes, refining tick marks, moving a legend, modifying line styles, and making the dozens of small visual decisions which turn a serviceable plot into a publication-quality graphic.

Most tools force users to choose. Either every visual detail must be expressed in code, even when direct manipulation would be faster, or a figure is edited in a graphical application and the relationship between the resulting artifact and the code which produced it is severed.

We want both.

The current in-progress plotting work contains an early graphical editor which reads from a visualization schema, exposes controls for chart properties, and posts changes back to a server-side plot. The underlying schema remains the source of truth. Programmatic changes can update the editor, and editor changes can update the programmatic object.

This work is still early, but the direction is important. The goal is not to replace code with a GUI. It is to make the GUI another frontend to the same underlying representation.

Knowing when to stop building everything ourselves

At this point, an obvious question arises. If we are building so much custom plotting infrastructure, why build on Vega at all? Why not implement the renderer ourselves?

We tried.

stdlib has a strong bias toward building foundational infrastructure in-house. That tendency has served us well. It gives us control over API design, behavior, performance, portability, testing, documentation, and release cadence.

Our original plotting implementation followed that instinct. We built SVG components, virtual-DOM infrastructure, scales, axes, marks, layout logic, and rendering machinery. It worked. It also made increasingly clear just how much work remained.

A serious visualization renderer needs to handle scenegraphs, data joins, text measurement, clipping, layout, rendering order, incremental updates, animation, browser differences, event handling, image export, accessibility, canvas, SVG, server-side rendering, and a seemingly endless collection of edge cases. We could keep investing in all of that. But doing so would mean spending an enormous amount of time reproducing infrastructure which already exists and is maintained by people who have devoted years to solving those exact problems.

At some point, persistence becomes stubbornness. So we folded that hand.

The pull request containing the current work explicitly removes the previous virtual-DOM plotting implementation and replaces it with packages for constructing and generating Vega specifications. That does not mean the previous work was wasted. Quite the opposite. It taught us where the correct abstraction boundary should be.

We do not need to own every pixel in order to own the user experience. Rendering is not where stdlib can add the most value. Integrating plotting into scientific JavaScript is.

Why Vega?

Vega is described as a visualization grammar. Rather than directly issuing imperative drawing commands, a Vega visualization is described using a JSON specification containing data, scales, axes, legends, marks, signals, and other components. The specification is then parsed into a reactive dataflow and rendered by the Vega runtime.

That distinction makes Vega a particularly good fit for what we are building.

A portable intermediate representation

We treat a Vega specification as an intermediate representation, which is one of the stated goals of Vega: namely, to provide a "target language" in which computer programs can dynamically generate visualizations.

Conceptually, the architecture looks something like this:

 high-level chart   future plotting
    constructors       DSLs
            \       /
             \     /
        low-level builders     GUI editor
                 \               /
                  \             /
                Vega specification
                         |
                    Vega runtime
                         |
            SVG / Canvas / other renderers

A high-level line-chart constructor does not need to know how to create SVG paths, draw onto a canvas context, or generate shaders. It needs to know how to translate the user's intent and data into a valid visualization specification. Similarly, a graphical editor does not need its own rendering engine. It can modify the same specification generated by a programmatic API.

This is not an untested architectural model. Vega-Lite is itself a higher-level grammar which compiles to Vega. Lyra was an initial attempt at a graphical environment for custom visualization design without writing any code. We are applying a similar separation, but building a different frontend, one which is shaped around JavaScript numerical computing, stdlib conventions, and direct integration with stdlib data structures, such as ndarrays.

Vega specifications also give us portable artifacts which can be inspected, serialized, stored, shared, transformed, and handed to other tools. Because Vega and Vega-Lite sit underneath tools in other ecosystems, including Altair and VegaFusion in Python, the specification provides a natural bridge beyond JavaScript as well.

The schema becomes a boundary rather than a burden.

Multiple rendering environments

Vega supports canvas and SVG rendering in the browser and static SVG and PNG export on the server. Server-side SVG generation does not require constructing a server-side DOM. Vega provides multi-view layout machinery, configuration-based theming, and explicit accessibility properties for SVG output. Third-party work has additionally demonstrated a WebGL renderer for the Vega scenegraph.

Those capabilities would each represent substantial projects in their own right. By building on Vega, we inherit a rendering foundation which already spans the environments stdlib cares about. We can then spend our time on the problems which are specific to scientific computing: data adapters, chart semantics, numerical types, server integration, REPL workflows, command-line composition, and user-facing APIs.

Reactive behavior on the client

Vega's signals and reactive dataflow allow many updates to be resolved directly within the client-side runtime. Not every change should require sending an entirely new specification from a server. A line color, tick size, font weight, or opacity can often be updated without rebuilding the world.

The current in-progress stdlib view implementation already distinguishes between properties which can be updated dynamically and structural changes which require the specification to be re-parsed. This gives us a useful division of labor. stdlib can own the server-side object model and change propagation, while Vega can handle reactive visual updates close to where rendering occurs and facilitate a more responsive and snappier user experience.

An ecosystem rather than an island

Depending on a rendering backend is not a decision we take lightly. Visualization libraries are expensive dependencies. They have large surface areas, and choosing one means placing a certain amount of trust in its architecture, maintainers, and continued development. Vega has continued to evolve, remains actively maintained, and supports a broader ecosystem including Vega-Lite, Altair, VegaFusion, Vega-Embed, Vega Themes, and the Vega Editor.

That matters.

We are not tying stdlib to an isolated renderer which only we depend upon. We are aligning with a specification and runtime already shared across languages, applications, and communities.

Vega is the backend, not the user-facing API

One might reasonably ask: why not simply tell users to write Vega specifications directly? Our answer is that, while powerful, Vega is also low-level.

Creating even a conventional chart can require thinking about datasets, scales, domains, ranges, axes, marks, encoding sets, value references, signals, and layout, and then trying to encode that in JSON. That level of control is invaluable when building novel visualizations. It is unnecessary ceremony when someone simply wants to plot x against y. A scientist should not need to learn a visualization grammar before inspecting an array.

stdlib's role is to provide ergonomic plotting APIs inspired by established numerical environments such as MATLAB and matplotlib, while retaining the ability to reach for the full expressive power of Vega when needed. At the highest level, that may mean static chart constructors which make common plots easy. At a lower level, it means programmatic objects corresponding to Vega concepts such as data sources, scales, axes, marks, and encoding sets. Those objects provide validation, defaults, property accessors, change events, debug logs, and predictable serialization. And, at the bottom, the generated Vega specification remains available as an escape hatch and interoperability format.

The work-in-progress implementation already reflects this layering: high-level quantitative and line-chart objects are composed from lower-level Vega dataset, scale, axis, mark, encoding, and value objects before serializing to a standard specification.

This is not intended to be a thin wrapper which renames a few Vega properties. What we are building is a frontend and integration layer.

The value is in the continuity

To be clear, we are not claiming that every individual feature we want is unprecedented. That would be both false and unhelpful.

Vega already renders on the server. Other libraries can be made to work with Node.js. Command-line visualization tools exist. Graphical chart editors exist. Some libraries accept typed arrays or can be used inside Electron.

The individual pieces are out there. What we have not found is a coherent system which brings those pieces together around scientific computing in JavaScript.

Consider the workflow we are working toward:

Load an ndarray. Create a chart without manually reshaping the data. Open the chart in a desktop window directly from the REPL. Update a property and see the view react. Listen for changes from another server-side object. Inspect debug logs to understand why the plot updated. Fine-tune the figure in a graphical editor. Serialize the same underlying specification to stdout. Embed the same visualization in a browser application. Hand the specification to a tool in another ecosystem.

No single step is the point. The continuity is.

Building it the stdlib way

The plotting work is also being built according to the same principles which guide the rest of stdlib. Low-level components are modular and independently usable. Higher-level behavior is composed from those components. Complexity is pushed upward into APIs which can provide convenience without compromising the predictability of the foundations underneath.

Yes, this results in more packages than placing everything inside a single plot function. It also gives each concept a clear boundary. Components can be tested in isolation, documented independently, benchmarked where appropriate, reused by other packages, and replaced without rewriting the entire plotting system.

Just as importantly, stdlib owns the user-facing compatibility boundary.

Vega may evolve. Renderers may change. New specification versions may be released. By placing stdlib APIs in front of that machinery, we can absorb upstream changes, maintain consistent conventions across the rest of the project, and release plotting functionality according to the needs of stdlib users.

Depending on Vega does not mean surrendering control. It means focusing our control at the layer where we can add the most value.

Where things stand

This is not a launch announcement. The plotting work currently lives in a long-running draft pull request, and it is not ready for general use. API names may change. Package boundaries may move. Some features are incomplete, and many details remain to be worked out. But we have made significant progress.

The branch now contains a programmatic Vega object model, data conversion utilities, scales, axes, marks, encoding objects, high-level chart constructors, direct ndarray support, multiple view targets, server-side change propagation, and an early graphical editor. Enough of the architecture is now working that the direction is no longer hypothetical.

We are sharing the rationale before the software is finished because we think the motivation matters. From the outside, another plotting library can look like duplication for duplication's sake. From inside stdlib, it is an important missing piece in our effort to provide a comprehensive environment for scientific computing and data analysis in JavaScript.

We welcome initial feedback, especially from those whose workflows move between the REPL, scripts, servers, browsers, command-line tools, and publication systems. Those are precisely the boundaries we want to make disappear.

Closing

JavaScript does not need another plotting library in the abstract. stdlib does need a plotting system designed around scientific JavaScript.

A scientific computing environment is incomplete if it can perform a computation but cannot help you inspect, explore, understand, and communicate the result. Visualization is not an accessory to data analysis. It is part of the process by which analysis happens.

We are not trying to replace every existing visualization library, nor are we trying to win a chart-library arms race. We are trying to make scientific computing in JavaScript feel whole.

That means starting where the data lives. It means supporting the runtime the user is already working in. It means understanding numerical data structures. It means treating plots as live computational objects. And it means knowing when to build our own infrastructure and when to rely on excellent work already available in the broader ecosystem.

Yes, data visualization in JavaScript is a rather frothy and noisy space.

And yet, here we are.

That is why we are building another plotting library.

Athan Reines is a software engineer at Quansight and core developer of stdlib.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

Acknowledgments

This work was supported in part by the National Science Foundation under Award No. 2449410.

Disclaimer: Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.

For most of the last eight months, my prompts have been the same sentence with two package names swapped.

Ok, considering `blas/ext/base/gxmy` as the closest reference
implementation, we need to refactor everything in
`blas/ext/base/gxdy`.

The difference is mostly implementation, and some other things
you will figure out when comparing.

But as far as structure goes, `blas/ext/base/gxmy` is the way
to go.

I have typed some version of that dozens of times, mostly inside blas/ext/base. The package names can look like line noise if you don't know the naming scheme. The leading letter often identifies the data type, while the rest describes the operation. You don't need to remember the details. The important part is that related packages follow recognizable patterns.

It's not a clever prompt. There's no elaborate role, long checklist, or prompting trick. It points at a package that already exists and says: follow that pattern, with these differences.

And it works surprisingly often.

It took me a while to understand why. The answer turned out to be more interesting than the prompt itself. It works because of how stdlib is built.

Thousands of siblings

stdlib is a standard library for JavaScript and Node.js focused on numerical and scientific computing. It is assembled from thousands of small packages under lib/node_modules/@stdlib, each of which can be installed independently. They are not thousands of unique snowflakes. They are variations on a much smaller number of shapes.

A strided BLAS routine looks like other strided BLAS routines. A LAPACK auxiliary routine follows the same general package structure as its neighbors, with similar files, section comments, documentation, tests, and naming conventions.

The Zen of stdlib puts it plainly:

Value consistency above all else.

That principle was written for people. A contributor who implements one package can recognize the shape of many others. Consistency becomes a teaching tool and a promise that the next package won't require starting from scratch. Nobody wrote that principle with language models in mind. But a codebase where packages consistently resemble their neighbors is also one of the best things you can give an AI agent.

When I point an LLM at blas/ext/base/gxmy and ask for blas/ext/base/gxdy, I am not asking the model to invent a package. I am asking it to compare two related operations and apply an existing pattern. The specification is not in a document. It is in the sibling package, sitting on disk, already reviewed, already merged, and already known to work.

The codebase is the prompt.

A messy codebase is a messy prompt

This is where the idea becomes uncomfortable. If precedent is your specification, every inconsistency in the repository becomes a bug in that specification. It's not only a cosmetic issue. A stale package using an old benchmark style is also a wrong answer waiting to be copied.

One of the other stdlib maintainers put this to me recently, and it changed how I thought about the problem. When a convention changes, you have two options:

• You can add another instruction telling the model to remember the exception; or
• You can update the old packages, so the exception no longer exists.

The second option is better when it is practical. Telling the model to remember is only a patch. It asks the model to carry an inconsistency and to keep track of which version is current. Fixing the codebase removes that ambiguity. The model can simply look around.

The same is true for people. Every "ignore that file, it uses the old approach" adds a small cost for every future contributor. We have always known this. AI agents only make the cost appear faster because they will find the old example and treat it as evidence.

I saw this during a recent modernization effort. Benchmark names used to be built by using string concatenation, and we have since migrated them to use string interpolation with format(), a pure JavaScript implementation of an API similar to C's printf. While that migration was in process, the tree had a mixture of both conventions. An agent adding benchmarks to a new package copied whichever style its nearest neighbor happened to use, and it was right to. Nothing in the old file says it's the old way.

Do not put off to tomorrow what you can fix today, because tomorrow an agent may read every version and assume they are all equally valid.

After stdlib participated in the METR study, which reported that experienced developers were 19 percent slower on tasks where they could use AI, Philipp Burckhardt wrote a reflection identifying two sources of friction: gaps in project conventions, and the blank slate from which an agent begins each session.

I think that diagnosis is right. An agent may not reliably remember an instruction from a previous session, but it can inspect the code in front of it. Consistency makes the right convention visible wherever the agent happens to begin.

This is why much of my work this year has looked boring from the outside. Updating benchmark names. Modernizing tests. Cleaning up old conventions across hundreds of pull requests. I used to think of that work mainly as maintenance. I now also think of it as improving the examples that every future contributor, human or otherwise, will learn from.

What isn't in the package

Precedent is powerful, but it has a limit. Code shows you the what. It rarely shows you the why, and it doesn't always show you what to verify. A model can produce a correct implementation and still have no idea which checks to run before opening a pull request.

But that knowledge isn't only in people's heads. Much of it is already written down in the repository, just not inside the package you happen to be editing.

stdlib installs a pre-commit hook that runs more than a dozen checks before a commit is allowed. It validates formatting, lints JavaScript separately for source, tests, examples, and benchmarks, checks the package manifest, lints Markdown and TypeScript declarations, and verifies license headers.

At the time of this post, there are 126 custom lint rules written for this project alone, covering conventions a general linter has no reason to know: how a JSDoc block should be shaped, how doctest output should match, how a namespace should export its packages. There are style guides for every language in the tree, and a contributing guide describing what a reviewable pull request looks like.

None of that sits inside the package. All of it is machine readable.

That distinction matters more than I expected. An agent that doesn't know that these exist will guess, and its guesses will look plausible enough to survive a quick review. An agent that runs the hook is told exactly what is wrong, in the project's own words, without anyone writing a prompt about it.

So the most useful thing you can do for an agent is not to describe your conventions. It is to make them executable. A convention that lives in a reviewer's memory has to be repeated every time it's broken. A convention that lives in a lint rule enforces itself, for people and machines alike.

What tooling cannot decide is which existing package to imitate in the first place. Choosing the right reference is the one piece of guidance I had to write down for the model myself.

Finding the right sibling

The most useful thing I learned while writing that guidance is that the valuable part is not another list of style rules. It is teaching the model how to find the right precedent.

For a new package, the guidance is a simple ladder:

1. Look for the same operation at a different precision.
2. If that does not exist, find a routine with the same package shape and the same precision.
3. Otherwise, find the closest operation in the same family.

Then, before editing anything, state the chosen reference and explain why it was selected.

That is the core of my repeated prompt, generalized. Instead of requiring me to know that blas/ext/base/gxmy is the right package to follow, the model has a process for finding the right package itself.

The final instruction matters more than it may appear. Asking the model to state its reference before writing code gives me a cheap place to stop it. If it chooses the wrong sibling, I find out in one sentence rather than after reviewing a four-hundred-line diff. Many of the poor outputs I have received began with the wrong reference. That mistake was visible before any code needed to be written.

What I would tell a maintainer

If you maintain a project and are thinking about how to prepare it for AI-assisted contributions, this is what I currently believe.

• Consistency is infrastructure. It helps people understand a project, and it gives machines reliable examples to follow.
• Fix the codebase instead of documenting every exception. When practical, migrate old conventions rather than asking every future contributor to remember which examples should be ignored.
• Write down the process, not only the style. A linter can enforce formatting. It can't explain which reference to choose, which checks prove the work, or which changes don't belong in the same pull request.
• Make the agent commit to a reference first. One sentence before any code can prevent an entire incorrect implementation.
• Keep a real reference for numerical work. Convention can make code look correct. Differential testing against trustworthy ground truth is what tells you whether it behaves correctly.
• Version AI instructions like code. They become outdated. Give them identifiers, an index, and a history so contributors can tell which guidance is current.

The accident that paid off

I came into this year thinking the interesting question was how to prompt well. I no longer think that is the main question. Prompting is a thin layer over a more basic question: does your project have anything coherent to point at?

stdlib is unusually good at this, although the benefit to AI was accidental. Years of insisting that related packages look and behave consistently, entirely for the benefit of human contributors, created a useful machine-readable specification as well. The best AI investment the project made happened long before anyone was thinking about AI. It was called "value consistency above all else."

That leads to something optimistic. Making a codebase legible to a machine is not separate from making it legible to a person. It is the same work: consistent structure, current conventions, documented processes, and real verification.

We have always known these things matter. We have not always treated them as urgent. Now something is reading all of it and using what it finds to shape the next contribution.

Better make it good.

Karan Anand is a core contributor of stdlib, a JavaScript library for numerical and scientific computing.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

We are often rewarded for becoming indispensable, both in our professional and our personal relationships. There is satisfaction in being the person who understands the obscure subsystem, who remembers the history behind a difficult decision, or who can step in and solve the problem that no one else can solve. Being needed can feel like evidence that our work matters, that we matter. But in open source, indispensability is often another name for fragility.

A release process that only one person understands is not really a process. It is a dependency. A project whose history lives entirely in one person's memory does not yet possess shared knowledge. And a community that can survive only through the continued sacrifice of a handful of exhausted people is not yet sustainable, no matter how many stars the repository has or how green its dashboards remain.

This is not a criticism of those people. In fact, if I'm being honest, I'm one of them. More often, it is a testament to how much they have invested and how much they have quietly carried. But it does suggest that good stewardship asks us to do something somewhat counter-intuitive: to care deeply enough about something that it eventually no longer depends on us.

We care deeply enough whenever we explain not only what we did, but why we did it.

We do it when we turn an answer we have given ten times into documentation that means no one has to ask the same question an eleventh.

We do it when we write tests that preserve knowledge of the behavior we intended, when we simplify something clever so another person can understand it, and when we record the context behind a decision rather than allowing that context to disappear into an old chat thread or someone's memory.

And perhaps most importantly, we do it when we invite another person into the work before we desperately need their help. When we give someone room to make a decision, to own a release, to lead a conversation, or even to make a mistake without immediately taking the work back from them.

These actions can be easy to dismiss as overhead. They rarely have the drama of solving the hardest technical problem or shipping the long-awaited feature. There may be no benchmark that captures their value and no release note that gives them proper credit. But they are the actions that turn individual expertise into collective capacity. They are what transform a project from something held together by heroes into something genuinely held in common.

And this is an important part of what it means for open source to be community-driven.

It does not mean that everyone must participate in every decision, or that expertise and leadership no longer matter. It means that knowledge, trust, context, and authority are distributed widely enough that the work can be carried by more than a few people and that there is a visible path for someone new to become one of those people. In open source, we are always building an inheritance.

Someone we may never meet will eventually read the documentation we wrote, encounter the interface we designed, puzzle over the test we left behind, or search through an old issue to understand why the software behaves as it does. That person may never know our name, particularly now in the age of AI. But they will encounter our judgment. They will discover whether we anticipated their confusion, whether we respected their time, and whether we left enough of a trail for them to understand the work and make it their own.

As open-source maintainers in a globally distributed world, so much of our shared life exists in code reviews, chat messages, meeting notes, and the moments when one person takes the time to bring another person into context. A shared purpose is not sustained by a mission statement alone. It is sustained by the small, repeated choices through which we make our knowledge available, make room for others to lead, and ensure that no one has to carry important work entirely alone.

As engineers, maintainers, designers, project leads, and community leaders, our value is not measured only by what we can accomplish ourselves. It is also measured by what others become able to accomplish because we were here.

Every project will eventually pass from our hands. Code will be rewritten. Interfaces will change. Roles will change. New people will arrive with ideas that we didn't anticipate.

That is not a failure of our stewardship. That is its purpose.

We should strive to build things worth inheriting and to do the quieter work that makes inheritance possible.

Because the best proof that we mattered may not be that the work still needs us. It may be that, because of how we cared for it, others can carry it farther than we ever could carry it alone.

Athan Reines is a software engineer at Quansight and core developer of stdlib.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

Acknowledgments

This work was supported in part by the National Science Foundation under Award No. 2449410.

Disclaimer: Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.

My open-source origin story goes something like this: I fixed a typo, tweeted some stuff, tripped, fell, and found myself in the inner circle of a large-scale OSS ecosystem with an active, supportive community! It's trite but true—neither universal nor unique. But "inner circle of a large-scale OSS ecosystem" is where I landed, and it's colored a lot of what I've written since—including an implicit assumption that you (person who is reading this) are trying to build an ecosystem-scale project too.

POSE (Pathways to Enable Open-Source Ecosystems) has it right there in the name. It expressly describes this shape as the first item in the list of activities it's meant to support:

Building and maintaining a distributed community of external contributors who will actively participate in the ongoing development of the open-source product.

However, this isn't the only (or even the most common) experience for open-source maintainers or projects. Most projects run on one to three active maintainers.^[1] Solo isn't a failure mode; it's the default.

There's a wide spectrum of how folks define open source: from "it's just a license" to "radically open and participatory." For the rest of this post to land, I need you to accept the license-end as at least legitimate—not right, necessarily, just legitimate. There's no need to re-litigate the decades-long disagreement in order to say that you, as a maintainer, get to decide the bounds of participation in your project.

An open-source project's first few artifacts are click-through: license (checkbox), README (template), .gitignore (whatever your framework spits out). Then you hit CONTRIBUTING.md—the first artifact that actually asks you what you want. Sure, there are best practices and helpful guides for you to follow, but it's where your project starts having opinions instead of defaults. So it's worth pausing and really unpacking what you want yours to look like. It's more than the mechanics of filing issues and submitting pull requests: CONTRIBUTING.md is the foundational framework for the relationship between your project and the unnamed masses who may or may not encounter it.

In fairness, the bare-bones version of contributor guidelines may work just fine for you. Or you and your project may have a version that was working in the past, but no longer feels sufficient.

For years, I had a Venn diagram I used in talks to illustrate what I called the "FOSS happy place":

It wasn't a lie—it reflected my early experience as a contributor to open source (even if my contributions weren't code-shaped). It's still not "wrong," per se. But it is guilty of radical oversimplification—not quite discretizing a continuous variable, but definitely improper dimensionality reduction. Critical features, like time, remuneration, and changing conditions/priorities are nowhere to be seen.

I'm not the only one whose journey was typo fix → full-time job/way of life. Kent C. Dodds (among the best in the game of open-source developer experience, in my opinion) describes a similar origin story in How getting into Open Source has been awesome for me (2020). I mention him for two reasons, and neither is throwing him under the bus: one, it's not just me; two, it's not dev-rel delusion—because (unlike me) he's a lines-of-code, PR-reviews, engineer-shaped maintainer of a widely used open-source project (Testing Library).

A career in open source isn't always a heart-eyes-emoji experience. Evan Czaplicki gave a great (aptly named) talk at Strange Loop 2018: The Hard Parts of Open Source. The challenges he describes seem somewhat inherent to the craft: you can't please everyone, conflicts will arise, things that once motivated you will be deeply draining at times. Anyone who's struggled through a group project in school will recognize the shape. None of that friction is new—LLMs didn't create maintainer burnout. In a 2019 piece by Nadia Eghbal, "The rise of few-maintainer projects", she wrote:

The salient issue for maintainers today is less about growing contributor numbers and more about navigating the flow of developers who are clamoring for their time.

Sounds familiar, right? AI has ratcheted things up. Maintainers are seriously rethinking what their relationship to their projects and users looks like. And here's where I return to CONTRIBUTING.md because this is a place where you get to be explicit about the choices you're making. Even if nobody reads every word (and most people don't read CONTRIBUTING files at all), writing one is how you set your boundaries in the first place. A CONTRIBUTING.md that reads:

No thanks! I'm gonna go it alone.
But feel free to fork and do whatever you like!

may not be what you're used to seeing (in fairness, that sentiment is likely carried through the absence of a CONTRIBUTING file), but it's legitimate. Or, maybe you think it isn't. Maybe it's anathema to open source, BUT it is a move that someone could make.

Am I recommending it? No. But I'm not you. I'm not everyone. And, importantly, it forces you to acknowledge that you get to set your boundaries and expectations. Again, this is an oversimplification. If you're maintaining a mature project with a set governance pattern and change-management process, waking up and burning your contributing process to the ground is likely to have serious fallout. But, that doesn't mean that you can't experiment (especially if the status quo feels like you're headed off a cliff.)

Certain projects have, by design, made the bar for contribution high for legitimate reasons. Debian's already the perfect example of a working gatekeeping mechanism that's high-demand. You need a sponsor, you find a mentor, you meet in person with someone who can vouch for you—as Nadia Eghbal put it, "Debian's process is built on the need for trust."^[2]

But Debian is one shape among several. Athan Reines pitched a taxonomy for this: not "how open is your project" on a slider, but "what shape of project are you actually running?" He described four archetypes: the walled castle, the clique, the university, and the hippie commune.

The walled castle (or black box). You get the code, but the drawbridge stays up. SQLite is the cleanest live example. Their copyright page has a section literally titled "Open-Source, not Open-Contribution," which says:

SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution...the project does not accept patches from random people on the internet.

You can't misread that. It's on their homepage. This archetype fits when the maintainer has a firm boundary they don't want to soften—a totally legitimate choice. It also fits when there's an author who's just done. The question: Do you want contributors? The answer: No.

The clique. You need to know the right people to get the secret password. OpenBSD is the best not-pejoratively-clique example I could find. Their hackathons page says, plainly: "Hackathon attendees come by invitation only. Some new people in the community who show promise are sometimes invited to see if they have what it takes." Linux kernel subsystems run on the same social logic at scale: the kernel docs describe a "chain of trust" where pull requests from unknown developers are received warily by subsystem maintainers until they've earned their way in. This archetype fits when the cost of misplaced trust is high and the mechanism for establishing trust is "does someone I already trust vouch for you."

The university. If you do your homework and score high enough on your exams, we'll admit you. Debian's process, above, is the archetypal case: the sponsor and mentor are part of a longer sequence that includes an application manager, a Philosophy & Procedures exam, a Tasks & Skills exam, and then DAM approval (or not). Their own docs are unusually honest about the deal: "the whole NM process is very strict and thorough. This is not meant to discourage people... but it does explain why the New Member process takes so much time." Kubernetes runs the most numerically explicit ladder I've seen: Member (sponsored by two reviewers from different companies), Reviewer (primary on 5+ PRs, reviewed 20+ substantial ones), Approver (30+ merged, nominated by a subproject owner). If you want the stdlib-adjacent case, pyOpenSci has documented onboarding flows for reviewers and editors: guest-editor probation, editor-in-chief nominations, a peer-review process modeled on academic journals. This archetype fits infrastructure that's load-bearing enough that mistakes are expensive to unwind, and it works if the syllabus is real. (It fails, badly, if the syllabus is a rebrand of "vibes-based homework we won't tell you the rules of.")

The hippie commune. Do you have a pulse? Yes? You're in. freeCodeCamp basically checks for a pulse and hands you a first timers only label. Their whole cultural stance is "let us help you land your first PR." I've been part of projects like this, and it's actually onerous in its own way. But, they're where a lot of folks get started. Without these, the rest of the spectrum loses its future contributors and maintainers. MDN Web Docs runs the same posture on the docs side: their contributing guide is basically "there's a place for you here, even if your grammar isn't perfect." (Wikipedia is the mother of this archetype but isn't code-shaped, so treat that as a cultural reference, not a technical one.) This archetype fits projects where the marginal contribution has low blast radius, and the real bottleneck is reach or discoverability, not integration cost. It also fits projects whose goal is teaching people to contribute, where the code is almost a byproduct of the mentorship.

In reality, there is, of course, a spectrum—and shades of gray as well. A project doesn't necessarily have to operate in a single mode, either. SQLite runs some clique-shaped review practices under its walled-castle surface. Debian's university process has real clique-shaped social realities inside it. Any given project can occupy more than one archetype at once—a codebase that's walled-castle at the core and hippie commune at the docs layer, say. And most projects drift between shapes as they age.

I also want to be clear that you're ALLOWED TO MOVE where your project is at. Is hippie-commune mode failing you in the age of AI slop? Maybe you run an experiment with a more rigorous onboarding (or have folks who have already contributed to the project mentor newcomers through their first PR so that the onus doesn't always fall on the maintainer.)

There is no more a platonic form for a perfect CONTRIBUTING.md than there is for a universally "perfect" job. The fit is between your project and its contributors. What works for one can be exactly wrong for another.

But here's why the taxonomy belongs in a piece about what you actually want: it forces you to say the thing out loud. "I want a hippie commune" is a different maintainer future than "I want a university," and both are different from "I want to keep the code out here but the process in here." You can't dodge the question by writing a CONTRIBUTING.md that just describes issue templates. The people who read it (the ~7 who will) can tell which archetype you're aiming for even when you haven't named it. Might as well spell it out.

There are pros and cons to the types of friction you introduce—selectively inviting who can interact, permanently banning a suspected peddler of AI slop, toggling off the "Issues" section of a repository. But, if the relationship (that between a maintainer and contributors) is evolving in such a way that it feels like it cannot hold, that's its own type of failure. Neither the maintainer nor "the community" are to blame when things end in a silent resignation or a public crashout—but maybe they can be avoided by experimenting with things you hadn't previously considered as being "worth it."

Like my old FOSS-happy-place Venn diagram, the chart below doesn't capture the n-dimensional reality of working in open source. But I'd like to think it's an improvement. On the x-axis you have maintainer/project (dis)comfort. And the y-axis is something akin to ROI (return on investment)—demand from contributors/community/ecosystem.

The catch is that you don't really know where an experiment lands on this chart until you try it—not how much it'll cost you (the x-axis), and not what you'll get back (the y-axis). That doesn't mean you have to try everything. But it's worth paying attention to where things actually fall, rather than where you assumed they would.

Here are some things that we're trying (or considering taking for a spin):

• Code review as the alignment step. Ed Yang makes the case that code review is where humans do the alignment work now. As AI takes on more of the implementation, the reviewer's job shifts away from line-by-line mechanics and toward the big-picture questions—does this fit, should it exist, is this the shape we want?

• Using AI as a market-research companion, not a PR-generation machine. Instead of AI writes the pull request, it's AI helps you see the landscape. Feed it the parallel projects—for us that's NumPy, SciPy, Math.js, and friends—let it aggregate the patterns everyone else has converged on, and then you decide what fits. Same tool, pointed at what should we build instead of let's crank out code.

• Livestreamed PR review. Twitch, Discord, YouTube—pick your poison. Someone watches a maintainer work through a review in real time. The discomfort scales hard depending on who you are (some folks would genuinely rather chew glass than do their job on camera), but it puts other humans in the room at the moment you're deciding something. And it teaches in both directions: people watching learn what makes a good contribution and what being a maintainer actually takes. It's knowledge capture without the curation—which means it might surface insights you never knew people wanted.

None of this is guaranteed to work. Most of what gets written about open-source communities and contributor experience gets written after the fact—after something worked. That means there's a bottom drawer somewhere full of the things people tried that didn't (those posts mostly don't get written.) And even the experiments that did work worked in the specific conditions of that project—its size, its maintainers, its users, its moment. Different projects, different fits. This isn't Wills and Trusts. You can iterate. Your CONTRIBUTING.md can change. Your governance can change. Your mind can change. Whatever you want to do is okay—just own it. And if you're trying something (the thing that's working, or the thing that isn't) come tell us about it. We're figuring it out too.

Mara Averick is a developer advocate at Quansight and contributor experience lead for stdlib.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

Acknowledgments

This work was supported in part by the National Science Foundation under Award No. 2449410.

Disclaimer: Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.

Billions of browsers are already deployed. We just haven't been using them that way. Think about how most web applications work today: a user interacts with a webpage, that interaction triggers a request to a server somewhere in a data center, the server does the computation, and then the result travels back over the network to display in the browser. This architecture makes sense for many applications, but it introduces latency, requires server infrastructure, and means your data has to leave your device to get anything done.

There's another approach: modern browsers have become powerful enough to handle serious computational work right on your device. At HPSFCon 2026, I demonstrated what this looks like in practice: real-time object detection processing webcam feeds, gesture recognition identifying hand signals, and numerical computing operations on large datasets. All of it running entirely in the browser. No servers involved. No network requests. Data never leaves the device.

This represents a fundamental shift in how we think about computation on the web. For decades, the pattern has been to centralize computation on servers and treat browsers as thin clients that just display results. The early days of computing followed a similar centralization pattern with mainframes like the Z3 and ENIAC. Then came Fortran in the 1950s, which made these machines programmable for scientific work. The development of optimized libraries, such as BLAS in the 1970s and LAPACK in the 1980s, established the foundation for numerical computing that we still use today. Fast forward to now, and we're seeing browsers gain capabilities that were previously only available on servers: the ability to run compiled code efficiently, to leverage graphics hardware for computation, and to execute machine-learning models locally.

The Deployment Problem

Traditional deployment follows a simple pattern: client devices send requests over a network to servers, which compute results and send them back. As computations scale, the architecture explodes in complexity. Load balancers, caching layers, cloud storage, and dozens of other components pile on. The infrastructure becomes more sophisticated than the computation itself.

Consider calculating the absolute value of all elements in an array. The computation is trivial. But, in a client-server architecture, you route it through this entire complex infrastructure. The network round-trip time dwarfs the actual computation time by orders of magnitude.

This pattern dominates high-performance computing, as well. Supercomputers, GPU clusters, HPC facilities all centralize computation. Users submit jobs through schedulers and wait for results. It works, but centralization is a choice, not a requirement.

Distributed Computing Works, Deployment Friction Doesn't

Folding@home and SETI@home proved that volunteer computing works at scale. These projects harnessed idle capacity across millions of devices to run molecular simulations and signal analysis. The core insight holds: massive amounts of idle compute capacity sit in devices on desks and in pockets.

The problem was deployment friction. Users had to explicitly install software, configure their systems, and opt in. That barrier limited adoption to enthusiasts and prevented mainstream use.

Browsers Are Already Everywhere

Web browsers exist on billions of devices. They require no installation, no external setup, and run on virtually every computing device made in the last decade. The distributed compute platform already exists.

Browser-based computation solves real problems. When computation happens locally, data never leaves the device. For medical data, financial analysis, or any sensitive information, this is the only acceptable model. Network round-trips are eliminated, so interactive applications respond immediately instead of waiting on network calls. Each browser instance is a compute node, and the infrastructure is already deployed and maintained. Users don't need to install anything, set up environments, or deal with compatibility issues. They click a URL and the application runs.

Modern browsers can handle complex computation. The technical foundation is already built.

The Technical Foundation

So, what makes browsers capable of running complex computations? Several key technologies have matured over the past few years, transforming browsers from simple document viewers into powerful computing platforms. Let's discuss a few of them.

WebAssembly: Running High-Performance Code in the Browser

For years, JavaScript was the only language you could run in a browser. If you had existing code written in C, C++, or Rust—especially performance-critical scientific computing libraries—you couldn't use them on the web. WebAssembly changed that. It's a portable compilation target that lets you take code written in these languages and run it in the browser at speeds approaching what you'd get running natively on your machine.

The workflow is straightforward. You start with your source code in C, C++, or Rust, which gets compiled to an intermediate representation (typically LLVM IR, which is a common format many compilers use). That intermediate representation then gets converted to WebAssembly's binary format. The browser downloads this binary and executes it directly. What's particularly powerful here is that the browser handles all the platform-specific details. Whether your user is on an Intel laptop, an ARM-based smartphone, or an Apple Silicon Mac, the same WebAssembly binary works across all of them.

WebGPU: Tapping Into Graphics Hardware for Computation

GPUs (graphics processing units) are exceptionally good at certain types of computation, particularly anything that can be parallelized across many small operations. That's why they're used for graphics rendering, but it's also why they're powerful for scientific computing and machine learning. The problem has always been that GPU programming is vendor-specific. Code you write for an NVIDIA GPU won't work on an Intel GPU or an Apple GPU. Each vendor has their own APIs, their own optimization techniques, their own quirks. This makes it incredibly difficult to write portable GPU-accelerated code.

WebGPU solves this problem for the web. It provides a single, unified API that works across all GPU vendors. Your application code talks to what WebGPU calls a "logical device," which is an abstraction. The browser then maps that logical device to an adapter for whatever physical GPU the user actually has. That adapter translates your WebGPU calls into the native GPU API (e.g., DirectX, Metal, or Vulkan) and communicates with the driver for that specific hardware. As a developer, you write your code once and it runs on any GPU.

Web Workers: Using Multiple CPU Cores

Modern computers have multiple CPU cores, but JavaScript in the browser traditionally runs on a single thread. That means, even if your laptop has eight cores, your JavaScript code can only use one of them. Web Workers fix this limitation. They let you spawn independent threads that can run computation in parallel across multiple cores. Your main JavaScript thread can hand off computationally intensive work to these workers, which means heavy computation doesn't freeze the user interface. The user can still interact with your application while complex calculations happen in the background.

Web Neural Networks: Running AI Models Locally

Most AI-powered applications today work the same way: you send your data to a server, the server runs inference on a machine learning model, and the result comes back. Every query requires a network round-trip. The Web Neural Network API enables a different approach: running the model directly in the user's browser.

This works through a stack of abstractions. Your web application uses a framework such as ONNX Runtime Web, which provides a high-level interface for loading and running models. That framework talks to the WebNN API, which is the browser's standardized interface for neural-network operations. WebNN then routes those operations to whatever hardware acceleration is available on the device. On Windows, that might be DirectML. On macOS or iOS, it's Metal Performance Shaders. On devices with specialized neural processing units (NPUs), WebNN can use those directly. If no hardware acceleration is available, it falls back to running on the CPU or even to cloud-based inference.

What makes this powerful is privacy. When the model runs locally, your queries never leave your device. If you're using an AI-powered photo editor, your photos stay on your machine. If you're using a language model for text editing, your documents stay private. Chrome has built an entire infrastructure around this concept, with APIs specifically designed for common AI tasks and pre-loaded models such as Gemini Nano that applications can use without downloading anything.

Building the Software Foundation

Having powerful browser capabilities is one thing. Having the software libraries to make those capabilities accessible is another. This is where the ecosystem comes in.

Think about how scientific computing works in languages such as Python, R, or MATLAB. Researchers don't typically write their own matrix multiplication routines or Fourier transform algorithms. They use high-level functions that hide the complexity. When you call numpy.matmul() in Python to multiply two matrices, you're not executing Python code for the actual multiplication. NumPy calls down to highly optimized libraries such as BLAS (Basic Linear Algebra Subprograms) and LAPACK (Linear Algebra Package), which are written in Fortran and C and have been optimized over decades. The high-level language provides the interface, the low-level libraries provide the performance.

This layered architecture is what makes scientific computing practical. Researchers work at a high level of abstraction, but get performance from heavily optimized low-level code. For browser-based computation to be viable for real work, we need the same kind of ecosystem.

That ecosystem is emerging. TensorFlow.js pioneered deep learning on the web by bringing machine learning to the browser with APIs that felt familiar to anyone who's used TensorFlow in Python. Transformers.js builds on the success of TensorFlow.js and leverages the ONNX Runtime to let you load pre-trained language models and run inference locally. LiteRT.js brings Google's cross-platform edge AI runtime to the web, delivering high-performance model inference with WebGPU and WebNN acceleration. stdlib provides the numerical computing foundation: multidimensional arrays, linear algebra routines, statistical functions, and more.

The Python ecosystem shows how this works at scale. NumPy sits at the foundation, providing arrays and basic operations. On top of NumPy, you have SciPy for more advanced scientific computing, Matplotlib for visualization, pandas for data analysis, scikit-learn for machine learning. Then on top of those, you have domain-specific libraries for astronomy (AstroPy), biology (BioPython), image processing (scikit-image), and countless other fields. Each layer builds on the layer below.

JavaScript is following the same pattern. stdlib provides the foundational layer: the basic data structures (e.g., ndarrays for multidimensional arrays), the core numerical algorithms, and bindings to optimized libraries such as BLAS and LAPACK. Above that foundation, you can build technique-specific libraries for particular methods such as optimization or signal processing, domain-specific libraries for particular fields such as finance or biology, and application-specific tools for particular use cases. The structure is remarkably similar to Python's approach, which makes sense because both are solving the same problem: how to build a productive scientific computing environment on top of a high-level language.

Seeing It Work

All of this technology is real and shipping today. At the conference, I ran several live demonstrations to show what browser-based computation actually looks like in practice.

Object Detection with MediaPipe

The first demo used Google's MediaPipe for real-time object detection. I pointed my webcam at the audience, and the browser identified objects in the video feed in real-time. The entire machine learning model was running locally in the browser. No data was being sent to any server. The webcam feed went directly into the model, the model processed each frame, and the browser drew bounding boxes around detected objects. Zero network requests after the initial page load.

This isn't a toy demo. MediaPipe is a production-quality framework used in real applications. Running it entirely in the browser means instant feedback (no network latency) and complete privacy (your webcam feed never leaves your device).

Gesture Recognition

The second demo was gesture recognition. The browser watched my hands through the webcam and identified specific gestures: thumbs up, peace signs, open palms. Again, everything ran locally. The model loaded once when the page opened, and then all the inference happened on my machine. No API calls. No external services. Just a machine-learning model executing in the browser, processing video frames in real-time.

These demonstrations matter because they're not hypothetical. These are production-quality models running at production-quality speeds, entirely client-side. The technology works today.

Performance Benchmarks

Demonstrations are one thing, but quantitative comparisons tell a clearer story. To make the comparison tangible, I built three separate live demos, one for each implementation approach. Each demo takes the same input image and inverts its colors, running the operation 10 times to measure consistent performance. The first implementation uses traditional client-server architecture: send the image to a server, it processes the image, and then returns the result. The second runs Python with NumPy in the browser via Pyodide, which compiles the entire Python runtime to WebAssembly. The third uses stdlib for native JavaScript computation. The performance difference is immediately visible: the client-server implementation takes over 2 seconds for 10 iterations, while the browser-based approaches finish in milliseconds.

I tested each implementation across different image sizes, from small 100×100 pixel images up to larger 3200×3200 images. The pattern holds across all sizes.

The client-server approach isn't slow because the server is slow. Network round-trip time dwarfs the actual computation time. For a trivial operation, such as inverting image colors, the time spent moving data over the network completely dominates the time spent actually computing. The infrastructure overhead exceeds the computation itself by 300×.

Pyodide and stdlib both run in the browser, which eliminates network overhead entirely. But even between these two browser-based approaches, there's a significant difference. Native JavaScript (stdlib) outperforms Python-via-WebAssembly (Pyodide) by 4.6×. This makes sense: Pyodide has to run the entire Python interpreter compiled to WebAssembly, which adds overhead. Cross-compiling existing ecosystems to the browser works, and projects such as Pyodide and WebR bring valuable tools to the web. But native browser-based libraries deliver better performance by avoiding that interpreter overhead.

The chart shows another important pattern: as image dimensions increase, the performance gap between client-server and browser-based approaches widens. For small images, network overhead is a fixed cost. For larger images, you're paying both the network cost and the cost of moving more data. Browser-based computation scales better because there's no network involved.

Python and R in the Browser

Python and R now run in browsers through impressive engineering efforts. Pyodide brings Python, including NumPy and SciPy, to the browser by compiling the entire Python runtime to WebAssembly. WebR does the same for R. These projects make established ecosystems available on the web, which means researchers can use familiar tools without changing their workflow.

The tradeoff is performance. These projects compile interpreters to WebAssembly and run them in the browser, which adds overhead. The alternative is writing directly in JavaScript using libraries like stdlib that provide the same numerical primitives as NumPy or SciPy. Both approaches work. Compiled runtimes leverage decades of existing code and let people use tools they already know. Native JavaScript avoids interpreter overhead and delivers better performance for new projects.

AI Deployment Shifts to the Browser

AI model deployment changes fundamentally when you move inference to the browser. The training pipeline stays exactly the same: train on GPU clusters, supercomputers, wherever you train today. But deployment changes completely. Instead of deploying models to cloud servers where users send queries over the network, you load the model into the user's browser once. After that initial load, users query a local model, not a remote API.

This shift delivers concrete benefits. Queries never leave the device, which means complete data privacy. There's no network round-trip, which means low latency for every inference. You don't need to run massive inference servers, which means reduced infrastructure costs. Training infrastructure stays the same, but deployment becomes radically simpler and completely privacy-preserving.

Where This Goes

JavaScript has closed the gap for numerical computing. WebAssembly brings near-native performance for compiled languages. WebGPU provides hardware-agnostic GPU acceleration. Web Workers enable true parallelism across CPU cores. WebAI and the Web Neural Network API make on-device inference practical. These aren't experimental features. They're shipping in production browsers today.

The ecosystem is developing rapidly. stdlib provides the numerical computing foundation. Higher-level, domain-specific libraries will follow the same pattern we've seen in Python, building on these foundational tools to solve specific problems.

Browsers will become the default platform for privacy-sensitive applications where data cannot leave the device. They're ideal for interactive tools where latency matters and network round-trips kill the user experience. Educational platforms benefit from zero-friction deployment: students click a link and the application runs, no installation required. Edge computing scenarios where connectivity is intermittent or expensive make browser-based computation the obvious choice.

Computation is moving from servers to browsers. Not as a replacement for all server-side compute, but as the superior model for specific use cases. The infrastructure is already deployed. Billions of browsers are waiting to compute. You can explore stdlib on GitHub, join the conversation on Zulip, or watch the full HPSFCon 2026 talk for more details on browser-based scientific computing.

Gunj Joshi is a core developer of stdlib, a JavaScript library for numerical and scientific computing.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

This is the third post in a series on the tools we picked up during I-Corps training, part of the NSF's Pathways for Open-Source Ecosystems (POSE) program. The Open-Source Ecosystem Canvas and the Ecosystem and Stakeholder Map both ended on the same question—what does it actually take to keep a project alive?—and on the observation that the passive window we used to watch our communities through is narrowing. This tool is about looking on purpose instead.

What the journey is

The third tool is the Stakeholder Journey, taught to us by Betsy Peters as part of the go-to-market module of POSE. It maps the path a person takes from never having heard of your project to being one of the people who sustains and leads it:

Discovery → Acquisition → Activation → First Impact → Habit → Commitment → Ecosystem Leadership.

Most projects, when they think about onboarding at all, think about the left side. Discovery is whether your project shows up—in search, in a tutorial, in a coworker's recommendation, in an AI's suggested package. Acquisition is whether someone reaches it: installs it, opens the docs, clones the repo. Activation is whether they get past the first wall—the README works, the install command runs, the example does what it promised.

These are the things engineering teams instinctively optimize for. They're also where most projects stop. We made it easier to install. We rewrote the getting-started guide. We added a Colab badge. All of that work matters. It's not enough.

First Impact is the pinch point

The pinch point at the center is First Impact—the moment when a person can say this thing helped me achieve a goal I actually had. Not "I got it running," but "it did the thing I came here to do." Without First Impact, nobody moves any further to the right. Everything downstream is gated by it. A project can have a beautiful README and a flawless install and still fail at First Impact, because the person came looking for a result, not a successful build.

The right side of the journey is what you're actually building toward. The left—Discovery, Acquisition, Activation—is about volume and lowering friction. The right is about depth, repeat use, and the people who eventually keep the project alive. And the right side is where the open-source-specific problem hides.

Everything up to Habit used to be relational by accident. To get the install to work, the example to do the thing, the edge case to resolve, you had to look in someone's docs, read someone else's post about hitting the same wall, maybe venture into the somewhat hostile waters of Stack Overflow. None of that was billed as community engagement. It was the cost of getting the thing to work. But every step put you in proximity to other people's care—the maintainer who wrote the doc, the contributor who answered the question three years ago, the stranger who took your duplicate question seriously enough to point you somewhere. The community wasn't somewhere you went; it was somewhere you passed through to get to the thing you came for. AI dissolves the passage. The install still has to run, the example still has to do the thing—but you can now clear those walls without ever touching the artifacts of care that used to do the introducing. AI and the Invisible Newcomer in Open Source was about what we didn't know we were relying on until it was gone.

Habit is the territory of repeat use—the project becomes a default, a known quantity in someone's toolchain. This can still happen passively. People settle into tools because the tool works and they don't have to think about it. Someone finds your project, uses it, relies on it—and you may never know they exist. Habit users have never been fully visible—plenty went unseen even when public friction was the norm—but the passive window the Ecosystem and Stakeholder Map named used to make more of them visible than it does now, if not to maintainers then to each other. That visibility to each other matters: people who can see others engaged at the same stage recognize themselves as part of something larger, and what you help build feels worth more than what you just consume.^[1] AI absorbs the friction that produced that visibility, which means projects at the Habit stage increasingly have plenty of repeat users and no idea who they are.

Commitment is different. Commitment is a crossing—the moment a person stops being a user and starts being someone who tends to the project. They file the issue. They open the PR. They answer somebody else's question. They show up to the call. (Past it lies one more stage, Ecosystem Leadership—the people willing to help steward the whole thing—but Commitment is the crossing everything hinges on.) The transition from Habit to Commitment is the one that has never happened by itself, and it has gotten harder, not easier, as Habit has grown less visible.

The three conditions that have to be true for someone to make that crossing are uncomfortably soft to talk about, and they matter anyway: people have to feel seen and valued; they need an authentic connection inside the project, not just awareness of it; and they have to participate in creation, not just consumption—to feel like they helped shape something, not only consume it.

None of those happen on their own. Discovery through Habit can be a passive flow. Commitment isn't.

Who does the inviting

AI and the Invisible Newcomer in Open Source landed on invitation: that crossing into a community almost never happens by accident, and that there's usually a person with standing who reaches out and makes it personal. The journey is where you can see exactly what that act does. Invitation is the force at the Commitment crossing—the one transition no amount of passive flow will carry someone across.

Among the people we interviewed who'd already crossed that chasm—the maintainers, the stewards—the story came back the same shape. Nobody starts their open-source journey with a grand plan to maintain a project. You stumble in. You find something that works. You stick around because it keeps working. You read an issue, then another. You answer one question. Somewhere along the way, almost without noticing, you're doing it because the work itself matters to you. That shift—from user to contributor, from consumer to caretaker—doesn't happen by accident. There has to be someone with standing already inside the community who reaches out, who makes it personal, who says: we see you, and there's a place for you here.

So who does the inviting?

The people in the inner rings. The scaffold AI and the Invisible Newcomer in Open Source laid out—old-timers at the center, casual visitors at the outermost edge, a labeled trajectory pulling inward through intermediate roles—describes how any community works, and it pins down where the inviting has to come from. The people whose attention pulls that trajectory are the ones with the standing to do it. It's the same point the communities-of-practice literature has made for decades^[2]—that the journey from periphery to center is a social one, needing paths and people willing to guide—but the journey map is where you can finally put your finger on the step it happens at.

But "the inner rings do the inviting" hides a more specific mechanism. Invitation from the center—the maintainer who reaches out, the steward who notices—is rare and high-signal and doesn't scale. The daily work of pulling someone inward, the work that makes the next step look like a step rather than a leap, is done by the person one ring ahead of them. The trajectory the figure draws as a single arrow from edge to center is, in practice, a relay of short pulls. The near-peer who just crossed the same threshold is a better guide than the expert who crossed it years ago—not because they know more, but because they can still see where it was hard.^[3]

That mechanism needs density. A community where the next ring is visibly populated—where someone at Habit can see other people doing what Commitment looks like—can pull contributors along it. A community where the rings are sparse can't. The path doesn't close; it stops being visible from where most people are standing. Recent empirical work on aging OSS projects finds that sustained substantive engagement is what keeps the trajectory functioning over time, while passive attention loses its predictive power as a project ages.^[4] The failure mode is quiet: the dashboards stay green; the path just stops being navigable.

Invitation is how the trajectory begins. Belonging is what carries it forward. And belonging—not a tutorial, not your CONTRIBUTING.md—is what turns a user into a contributor.

Three questions for every project

If there's a single way to summarize what the canvas, the map, and the journey are for, it's that they make three questions impossible to leave unanswered.

1. Have you mapped your ecosystem—including the saboteurs? Or are you assuming you already know who's in your world? Most projects know their power users by name and their critics by reputation, but can't actually draw the network of incentives around them. The map exists because the people you haven't named are still acting on your project—funders, competitors, downstream maintainers, model providers, the people quietly recommending a different library in every Slack you can't see. If you can't see them, you can't steer around them, and they will steer anyway.
2. Are you designing your contributor pipeline—or assuming it will appear? It used to appear on its own—the byproduct of public friction that AI and the Invisible Newcomer in Open Source was about, and the one that's weakening. Designed programs help, but they aren't a substitute: even Google Summer of Code, about as structured an onramp as open source has, sees only around 45% of true newcomers^[5] who keep contributing after the program ends, and most never arrived intending to become maintainers in the first place.^[6] So, if you want a next generation of people who can run your project after you, the activities friction used to produce for free have to be built on purpose now: invitation, mentorship, and a path from user to contributor to maintainer with visible, named rungs that people know exist and can actually reach for. Mentorship in particular has more measurable shape than it usually gets credit for: in the most thorough study to date^[7] of mentors in Google Summer of Code, Tan and colleagues find that the heaviest load falls in proposal evaluation and the first weeks of onboarding—phases you can design around once you know they're the binding ones.
3. Is your community built for survivorship? Not just for how things worked before. The shape of the world a project's community grew up in is not the shape of the world the next one will. The question isn't whether the old onramps are still working; it's whether you've designed onramps that still work when the old ones don't.

The reason to ask these isn't to add another set of metrics to a dashboard. It's because the projects that will still matter in ten years—the ones that are still vibrant and alive—will be the ones where someone chose to tend to the community with the same rigor they brought to the code.

The code is the part that's easy to measure. The community is the part that decides whether the code still matters.

Mara Averick is a developer advocate at Quansight and contributor experience lead for stdlib.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

Acknowledgments

This work was supported in part by the National Science Foundation under Award No. 2449410.

Disclaimer: Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.

1. Strayhorn, T. L. (2018). College students' sense of belonging: A key to educational success for all students (2nd ed.). Routledge. https://doi.org/10.4324/9781315297293 ↩︎
2. Sholler, D., Steinmacher, I., Ford, D., Averick, M., Hoye, M., & Wilson, G. (2019). Ten simple rules for helping newcomers become contributors to open projects. PLOS Computational Biology, 15(9): e1007296. https://doi.org/10.1371/journal.pcbi.1007296 ↩︎
3. On the curse of expertise—the structural blind-spot experts develop about what was hard for them years ago: Hinds, P. J. (1999). The curse of expertise: The effects of expertise and debiasing methods on prediction of novice performance. Journal of Experimental Psychology: Applied, 5(2), 205–221. https://doi.org/10.1037/1076-898X.5.2.205. See also Nathan, M. J., & Petrosino, A. (2003). Expert blind spot among preservice teachers. American Educational Research Journal, 40(4), 905–928. https://doi.org/10.3102/00028312040004905. ↩︎
4. Kaushik, M., & Chahal, K. K. (2026). Community engagement and the lifespan of open-source software projects. Information and Software Technology. https://doi.org/10.1016/j.infsof.2025.107914 — sustained substantive participation keeps aging projects alive; passive attention loses predictive power as a project ages. Companion death-spiral dynamics paper: Kaushik, M., & Chahal, K. K. (2026). The death spiral of open source projects: A post-mortem analysis of pull request workflow dynamics. Journal of Systems and Software, 240, 112942. https://doi.org/10.1016/j.jss.2026.112942. ↩︎
5. Silva, J. O. dos, Wiese, I., German, D. M., Steinmacher, I., & Gerosa, M. A. (2017). How long and how much: What to expect from Summer of Code participants? ICSME 2017. https://doi.org/10.1109/ICSME.2017.81 ↩︎
6. Silva, J. O., Wiese, I., German, D. M., Treude, C., Gerosa, M. A., & Steinmacher, I. (2020). Google Summer of Code: Student motivations and contributions. Journal of Systems and Software, 162, 110487. https://doi.org/10.1016/j.jss.2019.110487 — surveys of 141 students and 53 mentors plus ten confirmatory interviews found most students enter GSoC seeking an enriching experience or skill development, not long-term project membership. ↩︎
7. Tan, X., Zhou, M., & Zhang, L. (2023). Understanding mentors' engagement in OSS communities via Google Summer of Code. IEEE Transactions on Software Engineering, 49(5), 3106–3130. https://doi.org/10.1109/TSE.2023.3242415; they catalog 41 distinct challenges and 52 strategies across all phases. ↩

This is the second post in a series on the tools we picked up during I-Corps training, part of the NSF's POSE (Pathways to Enable Open-Source Ecosystems) program. The first post covered the Open-Source Ecosystem Canvas—who you're building for, what it takes, and how you sustain it. This one is about drawing the network those answers live inside.

The map changes as you learn. Like the canvas, it surfaces the assumptions you didn't know you were making.

What the map is

The tool is the Ecosystem and Stakeholder Map. Your project doesn't operate in a silo; the map simplifies the world around it enough to look at. The first thing it asks you to do is something surprisingly difficult: name everyone who is in your world.

Not just your users.

Not just your contributors.

Everyone.

Our map has a box labeled "Saboteurs"—a category the I-Corps program asks every team to fill in. The label is sharper than the function. In the framing, "saboteurs" is one of six stakeholder categories (among them competitors, partners, users, contributors, and influencers), not a class of villains.

Many of the people in it are friends and colleagues whose work is good and valuable, and we're not trying to deny that. The point of the box is closer to what else is around here that could take our place. These are the projects and people who inform what we do—who could plausibly substitute for us, who is shaping the conversation around what we build. Knowing how you fit in that competitive landscape is how you figure out where your project adds value. Leave the box blank and you lose your read on where you stand, and on what it will take to keep standing there. And the box isn't hypothetical: of our hundred-odd interviews, fourteen were with people who belonged in it—alongside industry and academic users, contributors, downstream adopters, and funders.

And not every saboteur is a competitor. One of this year's CHI papers names a different kind—"Invisible Saboteurs"¹—high-sycophancy LLMs that made users less likely to correct their misconceptions, with a majority unable to detect that AI was being agreeable. The most consequential saboteur in your ecosystem may not be another project at all. It may be a tool that agrees with everyone, including your newest contributor, at the moment they're forming the wrong mental model.

One small discipline that pays off here: map people before organizations, and notice your blind spots. The world your project sits in is bigger than the people you already know to name. The segments where you can only name one or two—or none—are where your understanding is thinnest and your confidence is least earned. They're also where opportunities tend to hide.

The arrows matter as much as the nodes

The map isn't only a roster of who's there. It's a steering tool: arrows show how value flows. Where it comes from, where it goes, where it leaks.

We tend to talk about open-source value in concrete terms. The software is free. The tooling saves time. The license costs nothing. Those are real, and they belong on the map. But there's a less tangible current, too: reputation and belonging. Standing. The regard of people whose regard means something.

That's always mattered. It matters more now. As AI makes writing code faster and cheaper, the thing that doesn't get cheaper is trust—because trust requires a real other with the standing to withhold it. A system engineered to validate you can satisfy the form of recognition without the substance²; a friend whose approval costs them nothing isn't really a friend³. When you weigh in on a decision, people listen—not because of your commit count, but because of what you've earned in the community over time. That is a value proposition. It belongs on your map alongside the funding arrows.

What the canvas and the map are both asking

Both are asking the same question.

What does it actually take to keep an open-source community alive?

Part of the answer turns on a distinction that's easy to miss. Your code can be copied, distributed, and shared without being depleted—if anything, it grows in value the more it's shared. Your community is the opposite. Time, attention, and trust are finite, spent in the giving, and not replenished automatically—which is why burnout is a resource-depletion problem. The code can largely sustain itself. The community has to be designed. The code is free; the community isn't.

That's why the honest answer to what it takes has three levels, and most projects only think seriously about the first one.

Level 1 is code. Does it run. Does it build. Are the tests green. Is the dependency graph manageable. This is the level that maintainers are trained to think about, that funders understand, that GitHub measures for you. Almost every "sustainability" conversation in open source starts and ends here.

Level 2 is governance. Who decides. How decisions get made. What happens when the founder steps back, or burns out, or moves on. Whether there's a process for contention that doesn't depend on a single person being in the room. Some projects take this seriously; many don't, and by the time they need to, the people who would have done the work have already left.

Level 3 is community. Who actually shows up. Whether new people are arriving, and whether the people already there are staying. Whether the project has a story about itself that someone could find their way into. This is where projects die—not when the code breaks, but when nobody's left who cares enough to fix it. The empirical record on project abandonment bears this out. A post-mortem of 104 deprecated GitHub projects found the recurring failure modes were community-side, not code-side: loss of the lead maintainer, lack of time or interest from main contributors, displacement by a competitor ⁴. The live-project picture mirrors this: in a study of nearly 34,000 active GitHub repos, what predicted longevity wasn't stars, watchers, or workflow efficiency but active community engagement on issues—and that predictive power intensifies as projects age ⁵. Both are proxies—measuring issue activity and deprecation events, not the sense of belonging that actually keeps a community alive. But anyone who's worked in one knows the research is pointing at the right wall.

The asymmetry matters here. AI is good at producing the artifact and bad at producing the attachment, because attachment is a byproduct of the labor AI removes. The merged PR, the answered question, the completed exercise can all look identical whether a person grew through them or skipped them—and the difference, invisible on the artifact graph, is the entire ballgame for whether your community has a next generation.

For a long time, Level 3 had a window we could look through without thinking about it. Stack Overflow. GitHub issues. Mailing lists. Forum threads. We could see—passively, almost automatically—whether the community was still there, because people kept showing up to ask questions in public.

That's the window AI and the Invisible Newcomer in Open Source was about. It's narrowing.

The point of what comes next isn't to mourn the window. It's to notice that if the passive view is gone, the active one has to be designed. What used to happen by accident is now deliberate work. That's the Stakeholder Journey, which I will discuss in the next post in this series.

Notes

1. Bo, J. Y., Kazemitabaar, M., Deng, M., Inzlicht, M., & Anderson, A. (2026). Invisible saboteurs: Sycophantic LLMs mislead novices in problem-solving tasks. In CHI '26: Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems. https://doi.org/10.1145/3772318.3791365

2. Jacobs, K. A. (2024). Digital loneliness—Changes of social recognition through AI companions. Frontiers in Digital Health, 6, 1281037. https://doi.org/10.3389/fdgth.2024.1281037

3. Sparrow, R., & Brown, J. (2026). Against imaginary friends: Why digital companions are no solution to social isolation. Communications of the ACM, 69(2), 60–68. https://doi.org/10.1145/3750037

4. Coelho, J., & Valente, M. T. (2017). Why modern open source projects fail. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2017) (pp. 186–196). https://doi.org/10.1145/3106237.3106246

5. Kaushik, M., & Chahal, K. K. (2026). Community engagement and the lifespan of open-source software projects. Information and Software Technology. https://doi.org/10.1016/j.infsof.2025.107914

Mara Averick is a developer advocate at Quansight and contributor experience lead for stdlib.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

Acknowledgments

This work was supported in part by the National Science Foundation under Award No. 2449410.

Disclaimer: Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.

This is the first in a series of posts on the tools we picked up during I-Corps training—part of the NSF's POSE (Pathways to Enable Open-Source Ecosystems) program—and what each one showed us about stdlib's ecosystem. It picks up where AI and the Invisible Newcomer in Open Source left off: that post was the diagnosis—the visible friction open-source communities have always relied on is being absorbed by AI, and what's eroding underneath is how newcomers get seen. It closed on a question—what signals are you still relying on that may no longer be reaching you?—and a promise to come back to the tools we've been using to ask it.

One discipline ran through the whole program, and it's worth stating up front because it decides whether these tools work or just flatter you: you don't pitch—you examine. You're there to learn what's true about your project, not to sell anyone on what it already is. A canvas you fill in to feel good about yourself is worthless.

How you do the examining is on a sliding scale. The program ran on roughly 100 interviews in seven weeks—brutal, and not what most teams will (or should) try to repeat. The canvas works at lower fidelity too: a team running its own prompts honestly, a handful of conversations with people in your orbit, even one careful pass with the people already in the room. The discipline is what travels; the interview count scales to whatever you can get.

What the canvas is

The program led with the Open-Source Ecosystem Canvas: a grid of cells you fill in, one per facet of the project—who it's for, what value they get, how you reach them, what it costs, how it's funded. It's adapted from the Business Model Canvas, and the adaptation is the interesting part. An open-source project doesn't have customers in the SaaS sense, and the people who use it, build it, and fund it are often three different groups. So the canvas makes you account for value role by role, instead of letting you collapse everyone into a single "user." Most of what follows came from that one move.

What makes the canvas different from a plan is that nothing on it is a promise. Every cell is a hypothesis—what you suspect is true, written down where you can look at it, not what you've committed to deliver. That's a strange kind of freedom: a canvas is a place to be tentatively wrong on purpose. A blank brainstorm follows your attention—you end up circling the parts of the project you already think about. The canvas fixes the prompts in advance, so it asks about the cells you'd never have raised yourself. Those are usually the ones worth lingering on.

What ours surfaced

So here's ours. We've worked on it and it's still unfinished—which is what a canvas is supposed to be: some cells are firmer than others, and a few are mostly still questions. Doing it turned up things we'd been quietly avoiding: about sustainability, about the gap between who we were building for and who we said we were building for, about what the next ten years of stdlib look like if we change nothing.

Two cells did most of the surfacing.

Value Propositions. This cell asks you to think beyond the fact that you're shipping "free" code, and name what value each kind of person gets from the project—and the moment we took that seriously, one answer split into several. Contribution as a résumé line and a career stepping-stone? Numerical computing that runs on anything with a browser, no server or back end required? Familiar data tooling for people arriving from Python or R? These don't reduce to a single pitch, and forcing them into one would have buried the actual finding: some of these are reasons people use stdlib, some are reasons people contribute to it, and those turned out not to be the same people.

Community Members. This cell asks you to list who's actually there. We wrote down the obvious roles—core maintainers, Google Summer of Code (GSoC) alumni who stuck around, ecosystem package authors, industry users, the JavaScript developers who'd steered clear of statistics because the tools weren't there—and a handful more. Then we noticed a phrase we'd typed almost without thinking, parenthetical, next to casual contributors: usually non-users. That aside was doing more work than the rest of the list. For a lot of open-source projects, contributors are a subset of users—they show up because they hit a limitation in something they depend on. For stdlib, that's frequently not the case. A large share of the people opening pull requests aren't people using JavaScript for numerical computing in their own work; many arrive through GSoC and other on-ramps, and they're building the thing more than using it. Once that's written down, you can't un-see it—and you can't describe both groups honestly on one grid. We ended up needing two canvases, one per community, because the questions that matter for the people who build stdlib aren't the questions that matter for the people who depend on it. A project where contributors and users overlap heavily might never need that split—the canvas surfaces what's true for you, not a particular answer. And the canvas keeps asking for more precision than its grid can hold—"users" isn't one group either, which is where the rest of the series picks up.

It's worth saying why an exercise like this earns its discomfort. The ground under open source is moving fast enough that the honest reactions are either to keep shipping and trust it'll sort itself out, or to decide the whole thing isn't worth the trouble anymore. Both are real, and both can be self-protective if left unexamined. A canvas is the examination—stopping to look at what you're actually doing and who it's for, before you decide. And if you decide parts of it aren't worth sustaining, that's a decision made on purpose rather than by default—different from throwing up your hands. And if you decide it is worth sustaining, it shows you where the work has to change by design—the note the last post ended on: the on-ramps that used to happen by accident increasingly have to be built.

You don't need ours, though—you need yours. That's the whole point: filling one in surfaces the choices you'd otherwise leave implicit.

What to ask once it's filled in

A filled canvas isn't the deliverable—the conversations it forces are. The useful questions read across cells, not down a single column—for us, that means questions that straddle the split between non-user contributors and the users they build for. The best of them are the ones you can't answer without going and asking someone. A few we're sitting with:

• Do our operations actually deliver the value we promise contributors? Our Operations-and-Activities cell lists GSoC as the contributor pipeline, with monthly newcomer sessions and office hours as the mentorship structure. Our Value Propositions include mentorship and recognition, and contribution as a career stepping-stone. Do those activities close that loop—does a GSoC contributor leave having gotten what we say they'll get?
• Do users' value propositions match the ones we think we're offering? Our Value-Propositions cell mixes contributor value (résumé-builder, mentorship) with user value (browser-native results, familiar tooling for Python/R developers, no back end). This is the one you pair with interviews. What you think you're building and what your users think you're building are not necessarily the same thing.
• Are our go-to-market activities still pointed at the people we want? Our Go-to-Market cell was built for a pre-AI world: Bluesky posts, conference talks, SEO, cross-posting, video onboarding. If AI is absorbing those accidental on-ramps, which of those activities still land—and which need to be jettisoned and replaced with something else? One channel is sliding into gatekeeper territory: AI-mediated discovery is increasingly how developers find their way to a numerical library, and the canvas' flat Community Members cell can't see it. Another tool from the program—Ecosystem Segmentation, which we'll get to later in this series—splits User from Decision Maker from Gatekeeper, and that split is what makes the gatekeeper visible.
• Are the resources keeping this alive still going to be there? Open-source projects run on time, money, and effort that someone commits to them—written down by name in the canvas' Funding-Sources, In-Kind Support, and Costs cells. For us right now, that's an NSF POSE grant, in-kind labor from sponsoring companies, and recurring donations. AI has already changed the shape of open-source communities, not just for newcomers—and the labor that goes into the code itself isn't immune. There's a physics teacher's line in Svetlana Alexievich's Secondhand Time we keep returning to: money solves all problems, even differential equations. Particularly sharp when the differential equations are the product.

Some of those questions gesture at something the canvas does quietly. It captures not just who's in your world—builders and users—but the gap between the state you're in and the state you want. The discipline that exposes that gap is to work the canvas right to left: start with who you want your Community Members to be and what Impact you want to have, then ask whether your current Value Propositions match the community you've actually got. If they don't, the cells you've written down are describing a project pointed somewhere other than the future you want. The cells that earn their keep aren't the ones describing what you do now; they're the ones that make you decide what to carry forward and what to stop.

Run it yourself

No special software, no template, nothing that has to look like ours: a canvas is just as happily done on paper, in a shared doc, on a whiteboard, or vibe-coded in an hour. The format matters less than the honesty.

Next in the series, we move from who's in your world to how value flows through it: the Ecosystem and Stakeholder Map—including the people who aren't rooting for you.

Mara Averick is a developer advocate at Quansight and contributor experience lead for stdlib.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

Acknowledgments

This work was supported in part by the National Science Foundation under Award No. 2449410.

Disclaimer: Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.

Last winter, our team went through I-Corps training as part of the NSF's POSE—Pathways to Enable Open-Source Ecosystems—program. I-Corps is the National Science Foundation's customer-discovery training, and POSE adapts it for open-source projects. For us, that meant seven weeks and more than a hundred interviews with stakeholders in and around our ecosystem. (The "us" here is stdlib, an open-source standard library for JavaScript and Node.js, with an emphasis on numerical and scientific computing.)

These ecosystem-discovery interviews had one hard and fast rule: you don't pitch. No explaining what stdlib does, no defending decisions, no selling.

You ask, and you listen.

So that's what we did. The curriculum taught us how open-source ecosystems are supposed to be sustained—the frameworks, the canvases, the interview discipline. The interviews taught us something nobody had put on the syllabus. Talking with maintainers, contributors, and users, the same theme kept surfacing: AI was changing how people found projects, got help, and contributed. And we weren't just hearing it in the interviews. At conferences and in hallway conversations, in blog posts and LinkedIn threads, peers who do developer relations and community work for a living were describing the same shift from their own angles.

We went to learn about our ecosystem. While we were looking, the ecosystem was changing around us.

This post is about what we were seeing. It's also about what we weren't.

For a long time, open-source communities have depended on a specific kind of visible friction. People got stuck and they showed up—on Stack Overflow, in GitHub issues, on mailing lists, in forum threads. That first act of asking for help in public was itself a form of participation. It was the way you found the edge of someone else's community, and the way they found you.

There's an old model from Charles Vogl's The Art of Community—the idea that any community has concentric rings around it. People start as visitors. They find their footing. They ask, in one way or another, what am I doing here? The journey from the outer ring inward—visitor to member to elder—isn't automatic. It requires visible pathways. It requires people willing to guide. And, crucially, it requires that the path be known to others.

That model isn't unique to Vogl, or to open source. The figure below comes from a study of a community most readers have no skin in: recreational scuba divers in the early 1990s. Edouard Lagache, building on legitimate peripheral participation (a term coined by Jean Lave and Étienne Wenger), mapped the same geometry—old-timers at the center, casual sightseers at the outermost ring, a labeled trajectory pulling inward. People become members of a community by doing low-risk things at its edges—things that exist because there's a structure around them that makes them visible. Early 90s scuba diving is just an example, but the same dynamic and shape exists in open source, in sports, in fandoms, in any community you can name. The details differ, but the geometry is the same.

What made it work in open source, structurally speaking, was friction—visible friction. Someone got stuck, showed up, and both sides could see each other. That first public question was a form of initiation, and it was also legitimate peripheral participation in action: a low-risk, visible way of taking part from the edge. That dynamic is woven through decades of open-source community-building practice—it's underneath Ten simple rules for helping newcomers become contributors to open projects, among others. The public question made the newcomer visible, and it created the opportunity for someone already inside to respond.

It also made the community visible to the newcomer. Oh—there's a there here. There are people. There's a way in.

For a while, the shift we kept hearing about was a vibe more than a finding—something you could feel in the conversations before you could point to it on a chart. But it kept turning out to be tangible. At FOSDEM this year, David Allen, who leads developer relations at Grafana, showed everyone his numbers, describing a moment some maintainers haven't had yet but many will.

He'd gotten comfortable expecting community growth of 8 to 18 percent a quarter, almost automatically—I could fall asleep, he said, and the community would grow. Then one quarter the number dropped 27 percent. They checked the data, ran it again, and it wasn't a measurement error: the number of people entering the community had collapsed, even though overall user growth was still going up. The mechanism wasn't mysterious, either. Organic traffic to community spaces was down roughly 30 percent, traceable to question-and-answer behavior moving to LLMs.

And it's not a one-project story. A 2024 study in PNAS Nexus found a clean way to isolate the effect: compare Stack Overflow activity in English (where ChatGPT was available) with Russian- and Chinese-language counterparts (where it wasn't), and with mathematics forums (where LLMs are weaker). Within six months of ChatGPT's release, English-language activity had dropped 25 percent relative to those controls—and the authors call that a lower bound. The decline wasn't limited to beginners or to duplicate questions. Experienced and inexperienced users alike posted less.

And that was 2024. You don't need a natural experiment to know what's happened since: LLM-assisted development has gone from novelty to default, and more of the questions that used to be asked in public are answered in private.

Allen and his co-presenter, Amanda Wagner, offered a framing I keep coming back to: AI isn't the cause of this. It's an accelerant, exposing foundations that were already fragile.

Here's where the argument I want to make sharpens.

The surface loss is signal. Questions that used to surface as GitHub issues or forum threads are now answered privately. That's real, and it's measurable, and it's not nothing. But it understates what's actually happening.

When AI handles the initial friction, the newcomer gets unblocked. They get functional value. They make progress; they solve the problem. But they get it without connection—without anyone seeing them, without a moment of initiation. This isn't inherently bad. It's just different. However, the friction that we've always addressed as a "bug"—the thing we wanted to smooth out—was also doing work we didn't understand until it was gone.

Think about what deepens anyone's engagement with a community—what turns getting an answer into the start of a journey: they choose it, they're making progress in it, and they feel some connection to the people in it. AI delivers choice and progress with remarkable efficiency, but it doesn't replicate connection.

And here's the part that doesn't get said enough:

The blindness goes both ways.

The newcomer doesn't know they're at the edge of your community. They're using your software through an AI intermediary, and they may not think of themselves as being in relationship with a project at all—only with a tool. They don't know you exist as a community. They only know you exist as a dependency. They have no idea that they're already part of your ecosystem.

And you don't know they're there.

Vogl's inner-rings model depends on visibility in both directions. People can only be invited inward if they can be seen. They can only begin the journey if they know there's a path. When the first interaction with a project happens through an AI layer, neither condition is reliably met.

This is a different problem than the old problem of lurkers. Lurkers were quiet, but they were present. They were in your spaces. They could see you, even when you couldn't see them. The observer who finds your library through an AI assistant may never visit your spaces at all.

To be clear: not everyone wants to move inward, and that's fine. Vogl writes about this directly—most members of any community stay in the outer rings, and a healthy community makes room for them. Users don't owe a project anything. But open-source ecosystems aren't sustained by everyone; they're sustained by the few who do make the journey inward. And that's the real cost of the outer rings going invisible. It's not that every unseen user is a lost contributor. It's that we no longer know who's out there—which means we no longer know whom to invite.

What's actually being lost, then, is not support traffic or page views or the other surface metrics. It's the early moments of maturation—the activities that mark a new member, signal arrival, and begin the process of belonging. The public question used to be one of those moments, almost without anyone meaning it that way. It made someone visible, opened a door, created the conditions for response.

And we kept hearing versions of this from people working entirely different corners of the problem. Abigail Cabunoc Mayes, talking about mentorship at FOSDEM, put it plainly: "the volume of contributions is going up, but the signal-to-noise ratio is really going down." A community can look alive by the surface metrics—commits, PRs, downloads—while the substrate of belonging is hollowing out underneath.

The months since haven't quieted any of this. Maintainers are sharing their experiences—Daniel Stenberg has been chronicling what the AI era looks like from inside curl, and Franck Nijhof recently described Home Assistant's version of it: contributions arriving faster than anyone can review them, because "contributors are being amplified, but maintainers are still the verification bottleneck." Projects across the ecosystem are rethinking their contribution policies in response. The particulars differ; the shape is the same.

And here's the uncomfortable realization underneath all of it: we were relying on a friction we didn't even know we needed. The playbook for building and sustaining open-source communities—accumulated over decades by a lot of people who took the question seriously—assumed newcomers would keep becoming visible on their own. Nobody wrote that assumption down, because nobody had to. Now that it's failing, the playbook has to change.

This is a design problem, not a crisis

The instinct, when something erodes, is to mourn it or try to restore it. The more useful response is to ask: what has to be built intentionally that used to happen as a byproduct?

Everything we were learning—from the program on one track, from our interviews and our peers on the other—kept converging on the same few answers.

The communities that come through this in shape will be the ones oriented around relationships and narrative—not tooling, not clever onboarding flows, not any one platform. The technology stack underneath a community is replaceable. What isn't replaceable is whether the people in it are in real relationship with each other and with the project, and whether the project has a story about itself that someone can find their way into. That sounds soft. It is the hard part.

A piece of that is what Allen and Wagner call proof of effort. When the cost of producing surface-level engagement falls—an issue that reads as plausible, a PR that compiles, a comment that sounds informed—the signal that someone is actually here, actually paying attention, actually committed, has to come from somewhere else. Getting prospective contributors to demonstrate investment becomes more important, not less. Not as a gatekeeping move. As a way of making real participation visible again. Communities that ask people to do something on the project's terms—show up to a call, take a small responsibility, write the doc nobody wants to write—are not being precious. They are reconstructing the legibility the old friction used to provide.

The other shift—one we heard named, in almost the same words, by different people in different rooms—is from extractive to contributive: communities oriented around what someone can give to the project, not just what they can get from it. That's not a new idea either. What's new is that the default has flipped. If you don't say anything, the default relationship a person now has with your project is consumption with an AI in the middle. The contributive frame has to be made explicit because the extractive one is no longer being challenged by the structure of how people find you.

The structural argument follows directly from this. If the passive onramps are narrowing—and the evidence is now plural enough that this is no longer a hunch—then the active ones have to be designed. If the outer ring of the community is becoming invisible, you have to go looking for the people in it; they will not show up on your dashboard. If initiation no longer happens by accident, the project has to create the conditions for it on purpose. None of this is a return to a previous state. It's a different posture toward maintenance: looking, naming, inviting, and following up are now first-order work, not extracurricular.

Which lands the section, and the post, in one specific place.

Invitation. Invitation has to come from someone already inside the community—someone with standing, someone whose attention means something—saying out loud to a particular person: we see you, and there's a place for you here. That isn't new advice. The communities-of-practice literature has been making this argument, in one form or another, for thirty years. What's new is that it used to be advice. Now it's structural. The friction that used to put newcomers in front of us is thinner. The work of putting them in front of us, on purpose, is the work.

What you might not be seeing—and what's next

So: what signals are you still relying on that may no longer be reaching you? What onramps did you assume would always be there? Whose first contact with your project this year went through a layer you can't see into—and what would it take to find out?

In subsequent posts, I want to talk about the tools I-Corps handed us for actually looking at these questions honestly. A canvas, a map, a journey—they aren't the answer, but they can help you take a realistic look at your ecosystem and figure out where the gaps are.

Sources

• Allen, D., & Wagner, A. V. (2026). The AI Shockwave in Open Source Communities: How AI Is Reshaping the Foundations of Open Source Communities. FOSDEM 2026, Brussels. https://fosdem.org/2026/schedule/event/KXPSTQ-the_ai_shockwave_in_open_source_communities_how_ai_is_reshaping_the_foundations_/
• Cabunoc Mayes, A. (2026). The Synthetic Senior: Rethinking Free Software Mentorship in the AI Era. FOSDEM 2026, Brussels. https://fosdem.org/2026/schedule/event/AJGB73-the_synthetic_senior_rethinking_free_software_mentorship_in_the_ai_era/
• del Rio-Chanona, R. M., Laurentsyeva, N., & Wachs, J. (2024). Large language models reduce public knowledge sharing on online Q&A platforms. PNAS Nexus, 3(9): pgae400. https://doi.org/10.1093/pnasnexus/pgae400
• Lagache, E. (1993). "Diving" into Communities of Practice: Examining Learning as Legitimate Peripheral Participation in an Everyday Setting. Paper presented at the American Educational Research Association annual meeting, Atlanta, GA. ERIC ED 360 387. https://eric.ed.gov/?id=ED360387
• Lave, J., & Wenger, E. (1991). Situated Learning: Legitimate Peripheral Participation. Cambridge University Press.
• Sholler, D., Steinmacher, I., Ford, D., Averick, M., Hoye, M., & Wilson, G. (2019). Ten simple rules for helping newcomers become contributors to open projects. PLOS Computational Biology, 15(9): e1007296. https://doi.org/10.1371/journal.pcbi.1007296
• Vogl, C. H. (2025). The Art of Community: 7 Principles for Belonging (2nd ed.). Berrett-Koehler.

Mara Averick is a developer advocate at Quansight and contributor experience lead for stdlib.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

Acknowledgments

This work was supported in part by the National Science Foundation under Award No. 2449410.

Disclaimer: Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.

We're excited to share that Google Summer of Code 2026 is officially underway and that stdlib has been awarded five contributor slots for this year's program.

This is our third year participating in GSoC, and every year the program has gotten bigger, more competitive, and more energizing for the project.

What continues to stand out most is not just the number of proposals we receive, but the level of engagement contributors bring before applications even open. Increasingly, contributors are showing up months in advance: opening pull requests, participating in discussions, helping with reviews, fixing bugs, improving documentation, and steadily becoming part of the community long before proposal season begins.

And that matters.

Open source is not built over the course of a single summer. It is built through consistency, trust, curiosity, and sustained collaboration over time. GSoC works best when it amplifies an existing trajectory rather than starting from zero.

This year's application season was the most competitive we've seen so far.

From January 1 through April 21 of this year, prospective GSoC contributors were busy ramping up on stdlib's development practices, refining their proposals, and contributing across the project. During that time, the stdlib community:

• opened more than 2,000 PRs, with 1,452 of those being successfully merged.
• added 2,209 commits and 146 new packages.
• welcomed contributions from 89 different contributors.

During the official proposal period alone (February 19 – April 21), contributors opened 1,250 pull requests and authored 1,421 commits across the project.

In total, we received 75 proposals for just 5 slots.

That level of participation says a lot about the momentum behind scientific computing on the web and about the community that continues to grow around stdlib.

The 2026 Cohort

This year's accepted projects span numerical computing, machine learning, visualization, and low-level linear algebra infrastructure, all areas which are foundational to stdlib's long-term vision for scientific computing on the web.

Over the next several months, contributors will be working closely with mentors across the project, participating in design discussions, iterating on implementations, writing documentation, and helping shape the future direction of stdlib.

One thing we emphasize heavily within stdlib is that open source is not just about writing code. Good engineering requires communication, design thinking, documentation, review discipline, testing rigor, and an ability to collaborate effectively with others. GSoC gives contributors exposure to all of those dimensions.

With that, on to the projects!

BLAS Bindings and Implementations for Linear Algebra

Contributor: Kaustubh Patange

This project focuses on expanding stdlib's BLAS support by adding missing Level 2 and 3 BLAS routines. The work continues stdlib's broader effort to bring high-performance numerical computing primitives to the JavaScript ecosystem while maintaining API consistency and portability across runtimes.

More broadly, the project will strengthen one of the most important foundational layers for scientific computing: fast and reliable linear algebra operations.

Batch Machine Learning Algorithms in JavaScript and C

Contributor: Nakul Krishnakumar

This project aims to introduce a new set of foundational machine learning algorithms to stdlib, implemented in both JavaScript and C. The focus is on building reusable low-level primitives which can serve as the basis for a broader machine learning ecosystem within stdlib over time.

Machine learning infrastructure on the web is still relatively immature compared to other ecosystems. One of stdlib's goals is to help close that gap by providing robust, modular, and composable numerical tooling that works across Node.js, browsers, edge runtimes, and beyond.

Singular Value Decomposition (SVD) via LAPACK

Contributor: Prajjwal Bajpai

This project will add LAPACK bindings and JavaScript implementations for singular value decomposition (SVD), centered around LAPACK's dgesvd routine.

SVD is one of the most important algorithms in numerical linear algebra and underpins a wide range of applications, including dimensionality reduction, least-squares optimization, signal processing, recommendation systems, and machine learning.

Adding robust SVD support will significantly expand stdlib's growing linear algebra capabilities and move the project closer toward providing a comprehensive numerical computing stack for the web.

Linear System Solvers and Factorization Workflows

Contributor: Pratik Bhagwat

This project focuses on enabling factorization-to-solution workflows within stdlib by integrating matrix factorizations and linear system solvers into a more cohesive numerical linear algebra pipeline.

In practice, scientific computing is rarely about isolated kernels. Real-world workflows often involve composing lower-level primitives into larger computational pipelines. This project will help bridge that gap by improving interoperability between routines and strengthening stdlib's higher-level numerical computing ergonomics.

Plotting Infrastructure and Chart Creation

Contributor: Sachin Pangal

This project will extend stdlib's plotting infrastructure by implementing missing components needed for end-to-end chart generation using Vega.

Visualization is a critical part of scientific computing workflows, yet the JavaScript ecosystem still lacks cohesive, low-level scientific visualization tooling designed around composability and modularity. This work will help move stdlib toward a more complete data analysis and visualization stack capable of supporting exploratory analysis, diagnostics, dashboards, and educational tooling directly in the browser and in server-side runtimes such as Node.js.

More Than a Summer Program

One of the most rewarding aspects of GSoC has been seeing contributors continue participating well after the program ends.

Several former GSoC contributors are still active members of the stdlib community today, continuing to review code, mentor newer contributors, and help drive development across the project. That long-term continuity is enormously valuable and is ultimately what makes programs such as GSoC successful.

For stdlib specifically, GSoC has also helped accelerate an important broader goal: building a sustainable ecosystem for scientific computing in JavaScript and bringing more contributors into that ecosystem.

The web platform has become one of the most important computing environments in the world. Scientific computing tools should exist there as first-class citizens.

That means performant numerical primitives. It means robust infrastructure. It means approachable tooling. It means strong documentation. And it means building a healthy contributor community capable of sustaining all of that over the long term.

Programs like GSoC help make that possible.

Thank You

A huge thank you to everyone who submitted a proposal this year.

We know how much time and effort goes into preparing applications, contributing beforehand, engaging with mentors, and refining project ideas. The selection process was very difficult this year, and there were many strong proposals we simply did not have enough slots to support.

We also want to thank all of the mentors and community members who continue investing time into reviewing pull requests, answering questions, helping contributors onboard, and supporting the project day to day. Open source communities only work because people choose to show up for one another.

We're excited to get started and are looking forward to seeing what this year's contributors build.

Athan Reines is a software engineer at Quansight and core developer of stdlib.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

Over the past several years, stdlib has grown from a small collection of utilities into a large, highly modular system for scientific computing in JavaScript and on the web. Along the way, we've made thousands of small decisions about APIs, naming, performance, package boundaries, and implementation strategies.

Individually, those decisions may seem minor. Collectively, they define the character of the project.

As the project has grown, it's become increasingly important to make those underlying principles explicit not just for maintainers, but for contributors and users who want to understand how and why stdlib is the way it is.

Today, we're introducing the Zen of stdlib: a set of guiding principles that capture the philosophy behind the project.

Why a "Zen"?

This is not a style guide.

It's not a checklist.

And it's not meant to be followed dogmatically.

Instead, the Zen is a distillation of experience: what has worked, what hasn't, and what tends to scale as a codebase and community grow. It exists to guide decisions, especially in ambiguous situations where there is no obviously "correct" answer.

If you've ever asked questions like:

• Should this be a new package or part of an existing one?
• Is this API too general?
• Should we add another option or compose existing functionality?
• Is this abstraction worth it?

The Zen is meant to help answer those questions.

The Zen of stdlib

Do one thing. Do it well.
Embrace radical modularity.
Favor composition over configuration.
Stability is a feature.

Make it obvious and predictable.
Don't be clever.

Complexity kills.
Push complexity up the stack.

If it's hard to explain, it's a bad idea.
If it's hard to test, it's a bad design.

Failure should be easy to diagnose.

Value consistency above all else.
Except when correctness, safety, or clarity demands otherwise.

Write it like C.
Be explicit. Avoid polymorphism by default.

Automate where it scales; stop where it obscures.

Code is read more than it is written.
Be kind to your future self.

Code is craft.
Tend to the garden.

Mistakes are infectious.
Fix them early.

Simple is beautiful.

What this means in practice

A few themes show up repeatedly throughout stdlib.

Radical modularity

If something can stand on its own, it should.

stdlib is intentionally composed of many small packages rather than a few large ones. This enables reuse, makes testing easier, and allows consumers to include only what they need. It also forces discipline, as each package must have a clear purpose and boundary.

Composition over configuration

We prefer simple building blocks over highly configurable interfaces.

Instead of adding more flags, options, and modes, we aim to provide small primitives that can be composed. This keeps individual APIs predictable and avoids combinatorial complexity.

Pushing complexity up the stack

Lower-level APIs should be simple, predictable, and easy to reason about.

More complex behavior, such as branching logic, multiple modes of operation, and orchestration, belongs in higher-level utilities built on top of those primitives. This separation is critical for both performance and maintainability.

Predictability and consistency

Users should not have to guess what an API does.

Naming conventions, argument ordering, and error behavior should be consistent across the entire project. Consistency reduces cognitive load and makes the system easier to learn and use.

Performance by design

"Write it like C" is less about language and more about mindset.

We favor predictable performance characteristics, monomorphic code paths, and explicit behavior. Hidden allocations, excessive polymorphism, and implicit work tend to introduce both performance and debugging challenges.

Maintainability as a first-class concern

Code is read far more often than it is written.

That reality drives many of the principles in the Zen: clarity over cleverness, simplicity over abstraction, and documentation that explains not just what the code does, but why.

A living document

The Zen of stdlib is not fixed.

As the project evolves, so will our understanding of what works and what doesn't. The Zen may change over time, but changes should be rare, deliberate, and grounded in experience.

For contributors

If you're contributing to stdlib, the Zen is a useful reference point when designing APIs or reviewing code.

It won't answer every question, but it should help you reason about trade-offs and make decisions that align with the broader direction of the project.

When in doubt: prefer simplicity, clarity, and consistency.

Closing

stdlib is an ongoing experiment in what scientific computing in JavaScript and on the web looks like when built around strong principles.

The Zen is an attempt to capture those principles so that the project can continue to grow without losing what makes it coherent.

As always, feedback is welcome.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

As the stdlib community continues to grow and evolve, so has our need for new ways to connect and collaborate (see, for example, our announcement of office hours and a public events calendar). While Gitter's simple, single-channel interface worked well in the early days, it no longer scales with the range of conversations happening around the project. Today we're excited to announce our new Zulip chat, which provides a more full-featured, structured, and searchable space for us to interact.

Why Zulip?

Zulip is open source and generously supports open-source projects like ours with a free cloud plan. Its channel-and-topic model makes it easier to keep discussions focused, follow ongoing threads, and resurface past knowledge through powerful search features.

Anyone can browse the web-public channels of stdlib's Zulip without an account, and you can sign up at any time to join the conversation.

Join and get started

The stdlib Zulip chat is open to all. A welcome bot will greet you when you first join and share some tips specific to stdlib about how to participate effectively. If you're new to Zulip, their getting started guide is an invaluable resource. If you're already familiar with applications such as Slack or Discord, much of the experience will be familiar.

We encourage you to come say hello in the #introductions channel and take some time to explore other channels and topics that may be of interest to you. If you have any questions about Zulip itself, we've got a channel for that too (#zulip).

The stdlib team is active in the chat, and public messages are the best way to get timely help—no need for routine @-mentions. Asking questions in public is the fastest way to get a response, as more people can help, plus it's likely that someone else will benefit from finding out the answer to your question. The stdlib Code of Conduct applies to all community spaces, including stdlib's Zulip. Should you encounter an issue, Zulip's reporting tools and our moderation team are available.

See you there!

We're looking forward to seeing you in the stdlib Zulip instance! We welcome questions and suggestions as we continue shaping a space that is useful, inclusive, and genuinely supportive for everyone who wants to learn, build, or contribute.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider financially supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

I read the results of the recent METR study on "Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" with great interest for two reasons. Firstly, I have been an early adopter of LLM tools. In 2020, I was lucky enough to get access to the private beta of the OpenAI API from then CTO Greg Brockman and explored the use of AI for education at Carnegie Mellon University. Secondly, because stdlib participated in the METR study, I was personally involved and contributed by working on randomized issues over several months, being allowed to use AI for some tasks and forbidden for others.

Given that stdlib's involvement is central to my perspective, it's worth providing some context on the project. stdlib is a comprehensive open-source standard library for JavaScript and Node.js, with a specific and ambitious goal: to be the fundamental library for numerical and scientific computing on the web. It is a large-scale project with well over 5 million source lines of JavaScript, C, Fortran, and WebAssembly, and composed of thousands of independently consumable packages, bringing the rigor of high-performance mathematics, statistics, and machine learning to the JavaScript ecosystem. Think of it as a foundational layer for data-intensive applications similar to the roles NumPy and SciPy serve in the Python ecosystem. In short, stdlib isn't your average JavaScript project.

A Word of Thanks

Before diving into my reflection, I want to take the opportunity to thank the METR team and especially Nate Rush for giving stdlib the chance to participate in this study with two core stdlib developers, Muhammad Haris and myself. It was a great experience to work with the METR team, and I am eager to see any future studies they will conduct. It is my conviction that, with the entire tech industry being gripped by an AI gold rush, it is incredibly valuable to have a non-profit research institute like METR conduct studies that cut through the noise with actual data.

The Slowdown

The results of the METR study are surprising, clashing with some previously published and very optimistic study results on the impact of generative AI (e.g., see GitHub and Accenture's 2023 study on the impact of Copilot on developer productivity). Citing from the Core Result section of the METR study page:

When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.

Rather predictably, the results have led to a lot of discussion on Hacker News and other social channels, with parties on both sides lining up with their pitchforks.

The Perception Gap

I am part of the group of developers who estimated that they were sped up 20%-30% during the study's exit interview. While I like to believe that my productivity didn't suffer while using AI for my tasks, it's not unlikely that it might not have helped me as much as I anticipated or maybe even hampered my efforts.

But how can that be? Daily, we are reading about how AI is already revolutionizing the workplace or making software engineers redundant, with companies like Salesforce announcing that they won't be hiring for software engineering positions anymore or online lender Klarna announcing that they were shuttering their entire human customer support in favor of AI.

Many of these stories have turned out to be more hyperbole than reality. Klarna still has human support, and Salesforce still has many engineering job listings. Sadly, some of these stories appear influenced by ulterior motives, such as Klarna's strategic positioning as an "AI-native" company to capture premium valuations ahead of its IPO amid the current AI wave.

However, I have been using AI tools daily for the past three years, both at work and outside, and find them immensely useful. How do I square these benefits with the study results?

On Study Design

When confronted with results that go counter to one's expectations, it is a natural instinct to try to attack the study and identify holes to explain away the result. For example, one could point to the small sample size of 16 developers. There is also the argument that the study was conducted in a very specific context, with experienced developers working on projects they are intimately familiar with.

There might also have been a subtle selection effect in the tasks themselves: since project maintainers proposed their own task lists, it is possible that those more experienced with AI subconsciously selected issues they believed were more amenable to an agentic workflow. One could also argue that the developers were subject to the Hawthorne effect, altering their behavior simply because they knew they were being video-recorded, perhaps over-relying on the AI tools for the sake of the experiment.

Finally, and perhaps most importantly, the experimental setup of requiring screen recordings and active time tracking for a single task enforced a synchronous workflow. This effectively locked developers into what I call "supervision mode", where they had to watch the agent work rather than being free to context-switch to another problem.

Some of these critiques, particularly the enforced "supervision" workflow, could directly contribute to the observed slowdown. But others, such as selecting "AI-friendly" tasks or over-relying on the tool to impress researchers, should have biased the results toward a speedup. This makes the final outcome even more notable. The direction of various potential biases is ambiguous at best, which is why we must look at the study's core design.

As a randomized control trial, the study follows the gold standard experimental design for detecting causality. By randomizing individual tasks to "AI-allowed" or "AI-disallowed", the study isolates the effect of AI tooling. Instead of comparing one group of developers against a control group (where differences in skill could skew the results), it compares each developer against themselves. This "within-subjects" design controls for individual characteristics, from typing speed to experience with the project. With such a study design, results are harder to write off as mere statistical noise, even with a smaller sample size.

Crucially, the tasks were defined before this randomization. This avoids a common pitfall where AI might simply produce more verbose code or encourage developers to break tasks into smaller pull requests, which can inflate some productivity metrics without representing more work getting done.

16 developers from several open-source projects might not sound like much, but, in total, we completed 246 tasks. To give a sense of the work involved, the tasks Haris and I worked on were not trivial, while still being hand scoped to be completed in a few hours or less. They were a mix of core feature development (such as adding new array, string, and BLAS functions), creating custom ESLint rules to enforce project-specific coding standards, enhancing our CI/CD pipelines with new automation, and fixing bugs from our issue tracker.

And while a single developer's performance on one task is likely correlated with their performance on another and the precision of the estimates thus larger than otherwise, it is quite notable that the effect was in the opposite direction from what economists, ML experts, and the developers themselves predicted (with the former two groups being more in the range of a 40% speedup). Moreover, the effect is quite large in magnitude. A quick back-of-the-envelope calculation reveals that if the true effect were a 40% speedup, the probability of observing a result this far in the opposite direction is astronomically low.

In light of this, I have no reason to doubt the internal validity of the study and would venture that the effect measured is real within the context of the experiment. If one believed the chatter on social media and the hype merchants who two years ago were all shilling cryptocurrency (and maybe still are!) but have meanwhile all switched over to extolling the amazing speedup AI offers, then increases of 100%, 5x, or even 10x should have been in the cards. But this is definitively not what the study observed.

Embracing Agentic Development

The more important consideration for squaring my own experience with these results is external validity: how generalizable are the study's findings? The paper is a great read and touches on many possible criticisms and threats to external validity, and I won't belabor any of the points raised therein.

Instead, I will solely focus on my experience as a study participant and how I have been leveraging AI with success. I will also share my own hypotheses for why the performance of the developers in this sample was overall negatively affected by the use of AI.

To give some context, my main way of incorporating LLMs into my work before participating in this study was twofold. As something of an early adopter, I had used GitHub Copilot for auto-completion and inline suggestions and made heavy use of ChatGPT and Anthropic Claude web apps by assembling relevant context, writing detailed prompts, and copying results back into my editor. Tools such as Repomix helped streamline the process of incorporating LLMs into my daily development workflow. This general approach allowed me to review changes quickly, iterate on them by asking questions, and have the LLM make follow-up edits directly in a chat interface.

The METR study subsequently provided an excuse for me to delve into agentic programming and make Cursor an integral part of my workflow. I had used it briefly some time before but didn't find the AI-generated results compelling enough to let it loose on any codebase I was working on. But Claude Sonnet 3.7 had come out, which is still one of the most powerful models for coding tasks. Due to some very encouraging results during early testing, I was eager to put it to work on a backlog of tooling that we wanted to build for stdlib, alongside various refactoring and bug fixes.

One of my first impressions with Cursor this time around was the underlying LLM's rather impressive ability to follow the very specific coding standards and conventions of the project and, when placed in agent mode, to automatically and reliably fix lint errors and attempt to iteratively resolve errors in unit tests. This felt like another step change in capabilities, just like when OpenAI released GPT-3 Davinci in June 2020, which made a lot of use cases suddenly feasible that before would break down in any realistic scenario.

While I no longer use Cursor and have meanwhile switched to Claude Code (more on that later), I found Cursor straightforward to use, especially given that it is a fork of VSCode, which has been my IDE of choice for many years. I heavily doubt that inexperience with Cursor, which I shared with roughly a half of the developers in the study, played a major role in the results. While I didn't have an extensive .cursorrules setup (which has since been deprecated in favor of project rules), I did add basic instructions and context about the project and made sure to index the stdlib codebase. Aside from that, further customization was neither possible nor necessary, as the Cursor Agent was able to automatically pull in other files, look up function call signatures, and perform other operations for assembling context.

My experience of Cursor was largely positive during the study. As an example, I ended up working on several Bash scripts for our CI/CD pipeline, and Cursor definitely sped up my development workflow by not having to look up the man page of jq for the eleventh time given that I only use this command-line tool for manipulating JSON once in a blue moon. With the AI agent's help, I could quickly generate a function like this one to check if a GitHub issue has a specific label:

# Check if an issue has the "Tracking Issue" label.
#
# $1 - Issue number
is_tracking_issue() {
    local issue_number="$1"
    local response

    debug_log "Checking if issue #${issue_number} is a tracking issue"
    # Get the issue:
    if ! response=$(github_api "GET" "/repos/${repo_owner}/${repo_name}/issues/${issue_number}"); then
        echo "Warning: Failed to fetch issue #${issue_number}" >&2
        return 1
    fi

    # ...

    # Check if the issue has the "Tracking Issue" label:
    if echo "$response" | jq -r '.labels[].name' 2>/dev/null | grep -q "Tracking Issue"; then
        debug_log "Issue #${issue_number} is a tracking issue"
        return 0
    else
        debug_log "Issue #${issue_number} is not a tracking issue"
        return 1
    fi
}

The agent correctly assembled the jq -r '.labels[].name' filter to extract the label names from the JSON response—something that would have sent me to a documentation page for a few minutes. While a small speed bump, these moments add up. The AI handled the rote task of recalling obscure syntax, letting me focus on the actual logic.

My first takeaway is this: current LLMs are very powerful for tasks in domains that you are not intimately familiar with, allowing you to move much more quickly. Agentic tools such as Cursor and Claude Code are also very helpful to quickly navigate and learn your way around a large codebase, allowing you to ask questions and explore the codebase in a natural way. Leveraging "deep research" provides another means to more exhaustively explore a problem space in a way that the search engines of old simply cannot match.

On the other hand, some tasks were very frustrating. For example, the Cursor agent wrote one ESLint rule almost fully in one shot, but for another one, the Cursor agent was running in circles and unable to figure out the correct algorithm. Trying to prompt it to fix the bug was unsuccessful multiple times. It would have been better to not fall prey to the sunk cost fallacy and instead throw away the code and then either give the agent another shot or write it myself.

Cursor does have a neat feature of breakpoints which allow you to stop the agent at any time and revert to a prior state, something I wholeheartedly recommend using. It is a great way to avoid getting stuck in a loop of the agent trying to fix a bug that it cannot figure out.

I freely admit that I may have been a bit overeager about using AI for all of the AI-enabled tasks, partly due to my desire to learn to use Cursor productively but also due to my general amazement of what these new technologies unlock. However, maybe the METR study suggests that the question of whether a task can be more efficiently completed by AI, or whether one would be better off completing it by hand, is far from settled.

The Blank Slate Problem

Aside from occasional inefficiencies and outright mistakes in the generated code, coding agents do not have access to all the implicit knowledge and conventions of a large, mature project, which often might not be written down. In his reflections on the study, John Whiles identifies a core conflict: an expert engineer's primary value isn't just writing code; it's holding a complete, evolving mental model of the entire system in their head. The agent does not have such a mental model. Every interaction starts from a blank slate.

It is possible that some of this can be mitigated with better, more targeted instructions. As usual, there is no free lunch. One has to actively invest in making one's codebase more accessible to coding agents. And more generally, memory and learning is an unsolved problem with transformer-based LLMs, and changing that will likely require fundamental architectural advancements.

The necessity of auditing the agent's code for mistakes created two major sources of friction: the cognitive drain of 'babysitting' the AI and the time spent waiting for and reviewing its output. For every minute the agent spent running in circles on that ESLint rule, I was blocked, my attention monopolized by the need to supervise its flawed process. This synchronous, blocking workflow is exhausting and inefficient. It's the digital equivalent of shoulder-surfing an overconfident junior developer who has memorized everything there is to know about programming but cannot be trusted and who will make subtle mistakes that are hard to spot.

My advice: stay in the driver's seat during such pair programming and use the AI as a sparring partner to bounce ideas back and forth instead of yielding agency.

Delegate, Don't Supervise

Partly based on my experiences in the study, my workflow has evolved, and I have subsequently switched to using Anthropic's Claude Code. This has changed my interaction model from synchronous supervision to asynchronous delegation. I can now define a complex task via Claude Code's planning mode and then have the agent work on the task in the background. I can then turn my full attention elsewhere, be it attending a meeting, reviewing a colleague's code, or simply thinking through the next problem without interruption. Claude's work happens in parallel and is not a blocker to my own. The cognitive cost of babysitting is replaced by the much lower cost of reviewing a completed proposal later; if it didn't work out, I might just throw away the code and have the model try again, instead of engaging in a fruitless back and forth.

Claude Sonnet 4 and Opus 4 were not released at the time the METR study was conducted, and, while they mark another improvement, especially with regard to tool use by the model, the dynamics haven't fundamentally changed. The models still make mistakes and do not always implement things in an optimal or sound way, but they are now much better at following instructions and can work uninterrupted for longer periods of time.

At least for me, in contrast to those who frame coding agents as mere "stochastic parrots", I find myself absolutely amazed that, despite its warts and hiccups, we have now a technology that, given a set of instructions, is able to generate a fully-formed pull request that correctly implements logic, adheres to style guidelines, and has a passing test suite. And, in the best cases, this can happen without any human intervention.

The First 80 Percent

We still need to reconcile the observed performance decrease with how many developers, including myself, have now been leveraging AI to get tasks done in a fraction of the time, tasks that would have taken them hours or days previously. I believe that the Pareto Principle is a helpful yardstick. Named after Italian economist Vilfredo Pareto, it is commonly referred to as the 80/20 rule and posits that roughly 80% of effects come from 20% of the causes. Coding agents can now generate working code that mostly works but that might fall short if the goal is 100%.

In many instances, coding agents can easily accomplish the first 80% of a programming task, generating boilerplate, scaffolding logic, implementing core functionality, and writing a test suite. However, the final 20% of the task, from handling tricky edge cases, adhering to unwritten architectural conventions, ensuring optimal performance, and avoiding code duplication by reusing existing utilities is where the complexity lies. This last mile still requires the developer's deep, stateful mental model of the project. The rub here is that, by using the AI agent, one may bypass all the little steps which are necessary in the process of building that mental model.

But does it matter? When working on a crucial piece of a larger, complex system, it definitely does, and I would be hesitant with generative AI. But when working on a well-defined, isolated piece of code with expected behavior for inputs and outputs, why bother? The marginal cost of writing code (long recognized as only a small part of software engineering) is going to zero. In the event that there is a problem with the code, it can simply be thrown away and rewritten. The code that AI agents now generate is of decent quality, well-documented, and capable of adhering to one's coding conventions.

This brings to mind the following quote by Kent Beck.

The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.

AI as a force multiplier is why I am long on AI, even though the METR study is a good reminder that we all can easily fall prey to cognitive biases.

In Thinking, Fast and Slow, Daniel Kahneman gives a classic example for biases driven by the availability heuristic: people overestimate plane crash risks due to vivid media coverage, making such events more "available" to memory than statistically riskier, yet routine, car crashes. Our judgment is swayed not by data, but by the ease of recall. In the case of working with AI agents, observing them build fully-functioning tools in seconds is a very memorable and visceral experience. On the other hand, the slow, frustrating "death by a thousand cuts" experience of auditing, debugging, and correcting the AI's subtle mistakes is the equivalent of the mundane car crash. It's a distributed cost with no single dramatic moment.

Nevertheless, I have no reason to believe that this technology will not continue to improve, and I, for one, am excited about the possibilities. For any big and ambitious project, the amount of tickets to be completed, features to be implemented, and bugs to fix vastly outstrips the available amount of time and human bandwidth to work on them.

What Future Studies Should Tell Us

It remains to be seen whether the results of the METR study can be replicated. However, the study clearly demonstrated that experts and developers were overly optimistic about the impact of AI on productivity. This is an important insight that should inform future research.

In some ways, the study raises more new questions than it answers. It looked at a very particular situation: seasoned experts working in the familiar territory of their own large, mature projects. Future studies by METR and others could vary these conditions. What happens when we throw developers into unfamiliar codebases, where, at least per my anecdotal experience, AI agents shine? Or what about junior developers or new contributors to an established open-source codebase? Under what conditions can AI act as a great equalizer, compressing the skill gap and providing a speed boost rather than slowdown?

Furthermore, the current study centered on completion time, but faster isn't always better. One possible follow-up would be a blinded study where human experts review pull requests without knowing if AI was involved. We could then measure things like the number of review cycles, the time spent in review, and the long-term maintainability of the code. This might shed light on when and how AI-assisted development may impact trading short-term speed for long-term technical debt.

Finally, the field of AI is still evolving at a rapid pace. The synchronous workflow that the study's setup encouraged could be fundamentally suboptimal. Exploring different interaction models, such as the asynchronous delegation workflow that I've moved to, could yield very different results.

How to Work With AI Now

What follows are my current recommendations for using AI in your daily workflow based on my experiences and the METR study.

Adopt an Asynchronous Workflow

The biggest drain from using AI is the cognitive load of "babysitting" it. Instead of watching the agent work, adopt an asynchronous model:

• Define one or more tasks (e.g., running a set of commands to audit a codebase for lint errors and documentation mistakes) and then let AI agents work on them in the background (e.g., in separate Git worktrees of your repository), and turn your attention elsewhere.
• Review the completed task(s) later. If the output is flawed, it's often better to discard it and have the model try again with a better prompt rather than engaging in a frustrating back-and-forth.

Know What to Delegate

AI can now handle the first 80% of many programming tasks, but the final 20% often requires deep context. The key is to choose the right tasks for AI:

• "Vibe Code" and Prototypes: use AI for mock-ups or small, isolated tools that can be thrown away. This is where the technology's speed offers a distinct advantage.
• Verifiable Code: AI is excellent for tasks that can be fully verified against an existing, robust test suite. The tests act as a safety net to catch the subtle mistakes the AI might make.
• Boilerplate Code: AI can quickly generate boilerplate code, such as REST API endpoints or form validation, and can do so in a way that follows project conventions.
• Learning and Navigation: use AI to quickly learn your way around a large codebase, document previously undocumented code, or to get help with tools you use infrequently. Asking LLMs questions can be much faster than hunting through documentation, particularly if that documentation is split across multiple resources.

Use and Customize Claude Code

For tools such as Claude Code, customization is a helpful means of writing down any implicit knowledge about the project that is not readily accessible from the code alone.

• Provide Proper Context: drag and drop relevant files (this can include images!) into the Claude Code window for the model to use as context for the task at hand. One approach I have found useful is to add TODO comments in the codebase with the required changes, and then have Claude Code work on them. Use the planning mode to have the model think through the task and generate a plan that can be approved before immediately jumping into implementation.
• Use Project Memory: use CLAUDE.md files to give the model project-specific memory, specifically on its architecture and unwritten knowledge. You can have multiple CLAUDE.md files in different project sub-directories, and the model will intelligently pick up the most relevant one based on your current context.
• Build Custom Tooling: use the Claude CLI to build small, automated tools, such as a review bot that flags typos as a daily CRON job. For fuzzy tasks such as pointing out typos or inconsistencies in a PR, it's best to let Claude generate output that can be verified by a human. For well-defined tasks that can be fully automated, it is better to have Claude produce code that deterministically runs and can be verified.
• Set up Hooks to Automate Actions: hooks are a powerful new feature of Claude Code that allows you to run scripts and commands at different points in Claude's agentic lifecycle.
• Automate Repetitive Actions: create custom slash commands for frequent tasks performing routine work. Below is an example stdlib:review-changed-packages command that I run to flag any possible errors in PRs that were recently merged to our development branch:

- Pull down the latest changes from the develop branch of the stdlib repository.
- Get all commits from the past $ARGUMENTS day(s) that were merged to the develop branch
- Extract a list of @stdlib packages touched by those commits
- Review the packages for any typos, bugs, violations of the stdlib style guidelines, or inconsistencies introduced by the changes.
- Fix any issues found during the review.

• Build Custom Tooling: use the Claude CLI to build small, automated tools, such as a review bot that flags typos as a daily CRON job. For fuzzy tasks such as pointing out typos or inconsistencies in a PR, it's best to let Claude generate output that can be verified by a human. For well-defined tasks that can be fully automated, it is better to have Claude produce code that deterministically runs and can be verified.
• Set up Hooks to Automate Actions: hooks are a powerful new feature of Claude Code that allows you to run scripts and commands at different points in Claude's agentic lifecycle.

Final Thoughts

It's natural to attack a study whose results you don't like. A better response is to ask what they might be telling you. For me, it tells me there is still a lot to learn about how to use this new, powerful, but often deeply weird and unpredictable technology. One mistake is treating it as the driver in a pair programming session that requires your constant attention. Instead, treat it like a batch process for grunt work, freeing you to focus on the problems that actually require a human brain.

Philipp Burckhardt is a data scientist and software engineer securing software supply chains at Socket and a core contributor of stdlib.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider financially supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

Today, we are grateful to announce that stdlib, the fundamental numerical library for JavaScript, was awarded five slots in this year's Google's Summer of Code (GSoC). We participated in the program last year for the first time, and had four talented students working on a variety of projects. It was a resounding success, which we hope to surpass this year given all that we have learned over the past year and a half.

This achievement comes after a tremendously productive start to 2025. Since January 1st of this year, the stdlib community has:

• Opened two thousand PRs with 1,377 successfully merged.
• Welcomed contributions from 88 different contributors.
• Added 3,452 commits to the repository.

For GSoC, we received 99 excellent applications from enthusiastic students. Ranking proposals was a tough decision, and we would have loved for a few more projects to be accepted. We are grateful to everyone who applied and encourage those not selected this year to stay connected, continue to contribute to the project, and to apply again next year! In fact, one of this year's accepted contributors was a repeat applicant, demonstrating how persistence and continued engagement can pay off.

The accepted projects are listed below. Each project addresses key areas that will expand JavaScript's potential for technical and scientific applications.

Add LAPACK bindings and implementations for linear algebra
Contributor: Aayush Khanna

The goal of Aayush's project is to develop JavaScript and C implementations of LAPACK (Linear Algebra Package) routines. This project aims to extend conventional LAPACK APIs by borrowing ideas from BLIS, thus ensuring easy compatibility with stdlib ndarrays and adding support for both row-major (C-style) and column-major (Fortran-style) storage layouts. This work will help overcome the LAPACK's column-major limitation and thus make advanced linear algebra operations more accessible and efficient in JavaScript environments.

Expanding array-based statistical computation in stdlib
Contributor: Gururaj Gurram

Gururaj will advance statistical operations in stdlib by introducing convenience array wrappers for all existing strided APIs, thus improving developer ergonomics for common use cases. Additionally, he will develop specialized ndarray statistical kernels with the aim of facilitating efficient statistical reductions across multi-dimensional data.

Implement base special mathematical functions in JavaScript and C
Contributor: Karan Anand

Karan will implement and enhance lower-level scalar kernels for special mathematical functions in stdlib. The goal is to complete missing C implementations for existing double-precision packages, develop new single-precision versions, and ensure consistency, accuracy, and IEEE 754 compliance. These enhancements will provide developers with the most comprehensive set of high-precision mathematical tools for scientific computing in JavaScript.

Achieve ndarray API parity with built-in JavaScript arrays
Contributor: Muhammad Haris

Haris will extend stdlib's ndarray capabilities by implementing familiar JavaScript array methods like concat, find, flat, includes, indexOf, reduce, and sort for multi-dimensional arrays. The project will develop high-performance C implementations with Node.js native add-ons for compute-intensive operations. These enhancements will allow JavaScript developers to work with multi-dimensional arrays as easily as built-in arrays, significantly expanding JavaScript's capabilities for scientific and numerical computing.

Add BLAS bindings and implementations for linear algebra
Contributor: Shabareesh Shetty

Shabareesh will expand stdlib's BLAS (Basic Linear Algebra Subprograms) support by implementing missing Level 2 (vector-matrix) and Level 3 (matrix-matrix) operations in JavaScript, C, Fortran, and WebAssembly. The project will focus on key dependencies for LAPACK routines and create performance-optimized APIs that work in both browser and server environments. These enhancements will provide essential building blocks for developing high-performance machine learning and statistical analysis applications on the web.

We're excited to see these projects develop over the coming months. Each contribution will significantly enhance stdlib's capabilities and make advanced mathematical and statistical operations more accessible to the JavaScript community. The work done by these talented contributors will help bridge the gap between traditional scientific computing environments and JavaScript, furthering our mission to create a comprehensive, high-performance standard library for JavaScript.

We'd like to extend thanks to Google for their continued support of open-source development through the Summer of Code program, and we look forward to sharing updates as the above projects progress over the course of this summer. In addition to watching for more posts on this blog, you can follow development by joining our community chat. We also hold regular office hours over video conferencing, which is a great opportunity to ask questions, share ideas, and engage directly with the stdlib team.

We hope that you'll join us in our mission to advance cutting-edge scientific computation in JavaScript. Start by showing your support and starring the project on GitHub today: https://github.com/stdlib-js/stdlib.

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider financially supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!