An open-source SAS® interpreter, written by agents

Coding agents are transforming software engineering. They no longer just autocomplete code: they plan, write, execute, and collaborate over increasingly long horizons. On July 20, Cursor showed what this looks like at scale, with a swarm of agents rebuilding SQLite in Rust from its 835-page manual[1].

Yet one major programming language has been left behind by this new paradigm: SAS. The proprietary technology has dominated regulated industries for decades and still accounts for 68% of clinical statistical programming[2].

An agent can write SAS, but without programmatic access to a runtime, it cannot execute, test, or correct the programs it produces. That breaks the feedback loop that makes coding agents effective.

Until now.

Introducing OpenSAS: an open-source, SAS 9.4-compatible interpreter written in Zig. For supported programs, It produces byte-for-byte compatible output with SAS across complete production pipelines. At the time of writing, OpenSAS is 87,795 lines of Zig across 3,548 commits, all generated by coding agents. It is backed by 829 unit tests, 1,835 conformance tests against a corpus of expected SAS 9.4 outputs, and two end-to-end real-world clinical programs, including complete SDTM and ADaM pipelines.

It runs on Linux, Windows, macOS, and in your browser.

data trial;
  input subject $ arm $ height weight;
  bmi = round(weight / ((height/100)**2), 0.1);
  datalines;
S001 DRUG 170 70
S002 PLBO 182 82
S003 DRUG 165 65
S004 PLBO 178 90
;
run;

title "Demo trial subjects";
proc print data=trial noobs;
run;

Press Run. The interpreter is 1.8 MB and loads on first use.

#OpenSAS agentic development

For all their long history in computer science, parsers remain notoriously tedious to implement for non-trivial languages, and SAS is far from trivial. Its grammar has evolved since the first commercial release in 1976, accumulating hundreds of statements, procedure-specific syntax, and a full preprocessing macro language. A few months ago, rebuilding it from scratch would have been unrealistic for a small team. Today, all it takes is some good engineering practices and a thousand dollars in tokens. Recent improvements in models and agent harnesses shift the challenge from writing code to coordinating agents and verifying what they produce.

Auditability then becomes a by-product of the same constraints that buy us confidence in the implementation: zero dependencies, with every feature covered by unit and end-to-end tests.

Coordination, in turn, becomes more demanding as the horizon grows. The longer the project, the more important planning becomes. Just like humans, agents are bad at context switching, and clear work separation helps preserve context isolation; see the CodeDelegator framework[3].

Below is the dependency graph we defined before starting the implementation.

Engineering in 2026 is about being a good Scrum master for agents. Unlike humans, agents actually like to be managed. Perhaps Scrum was waiting for agents all along. With the plan in place, we assembled a team of seven agents. They coordinated through a shared task board called jira.md in remembrance of the demeaning enterprise software. Only the manager could edit it; the rest of the team had read-only access. To keep the active context small, completed tasks were moved to an append-only jira-archive.md. Everything else happened through Git. No worktrees or anything fancy.

[DONE] M0.2 AST — stmt + expr node types, arena, data-only
[owns: src/ast.zig]  [deps: none]  @dev2

[DONE] A1 Expression parser — precedence climbing, ** right-assoc
[owns: src/parser_expr.zig]  [deps: M0.2, M0.4]  @dev2

#What does it mean for clinical programming?

Statistical programming for clinical trial regulatory submissions, from CDISC SDTM and ADaM datasets to tables, listings, and figures, remains largely manual, vendor-locked, and on the critical path to drug approval. Coding agents could relieve much of this work, but two obstacles have limited their deployment: patient-level trial data has to remain within tightly controlled computing environments, and SAS®, the industry-standard language, has lacked an open runtime where agents can execute, test, and correct the code they generate. With the rise of local coding models and OpenSAS, agents can run inside controlled environments while getting execution feedback on the SAS they produce.

We started our implementation of OpenSAS with the subset of SAS needed for clinical data programming rather than trying to reproduce the entire SAS ecosystem at once. OpenSAS supports the procedures, file formats, and QC workflows needed to run real SDTM and ADaM pipelines end to end.

We will continue maintaining the runtime and broadening its language coverage in response to the open-source community's needs.

Through agent and human contributions.

#References

1. Cursor, “Agent swarms and the new model economics”, 20 July 2026. https://cursor.com/blog/agent-swarm-model-economics
2. Analytical Market Research, “Clinical trial statistical programming services market”, July 2026. https://analyticalmr.com/reports-details/clinical-trial-statistical-programming-services-market
3. CodeDelegator: Mitigating Context Pollution via Role Separation inCode-as-Action Agents Jan 2026. https://arxiv.org/pdf/2601.14914