The Software GardenThe Cambrian explosion ← Contents
The Software Garden · Case studies · 21

The Cambrian explosion

Until June 2025, one engineer maintained one SDK by hand. Then we went agentic. That engineer scaled up, and then the approach scaled out to the people around him. Here is what happened, measured from the git history of the 22 repositories it grew into, comparing the 12 months before with the last 12.

20×commits per month, same engineer
98×authored lines, generated code excluded
1 → 21active repositories
7language SDKs from one spec
scroll ↓
Case study 1 · Engineer A · Before

One repository, tended by hand.

From late 2023 to May 2025, the Camunda 8 JavaScript SDK (camunda-8-js-sdk) was maintained manually. It was a healthy, well-used project, and it moved at the speed of one person with a day job.

Every feature, test and release went through the same pair of hands.

15commits a month
1,300authored lines a month
5releases a month
1repository, 1 language
The explosion

Then the curve leaves the page.

Monthly activity across every repository in this story, coloured by what it was for. The dashed line is June 2025, when the work went agentic.

 
Stage 1 · Harden the foundation

The first thing we built wasn't an SDK. It was a better spec.

Agents generate from what you give them. So before generating clients, we made the OpenAPI specification say what the API means: domain types for keys, eventual consistency marked on every endpoint that has it, and lint rules to keep it that way.

That is derivation over duplication applied to a whole product line: one source of truth, everything else generated from it.

typed-api-workflowDomain-typed REST API proof of concept, with a consistency analyser that checks the spec against the gateway’s controllers. 124 commits in four weeks.
camunda-orchestration-cluster-apiThe hardened spec, extracted from the workflow repo and finished on its own, then merged upstream into camunda/camunda.
camunda-schema-bundlerBundles the multi-part spec, now living upstream, into the single file every SDK generator consumes. 26 releases.
return-of-api-added-in-analysisVersion analysis across spec releases: which endpoint arrived in which version.
Stage 2 · One SDK, then seven

Get one right. Then the next one is a copy of the pattern, not of the work.

The Orchestration Cluster API SDKs started with JavaScript. Once the spec, the generator pipeline and the test harness were proven there, each new language reused them. The gaps between languages shrank from months to weeks.

JSSep 2025
PythonNov 2025
C#Feb 2026
RustJun 2026
GoJul 2026
JavaSep 2026
PHPSep 2026

Month of first commit in each orchestration-cluster-api-* repository. The three oldest SDKs have shipped more than 100 releases each.

Stage 3 · Harden the tests

Speed needs a signal you can trust.

Seven SDKs at agentic speed only work if “green” means something. So the tests were derived from the spec too: response bodies asserted against the schema, then whole test suites generated from a semantic graph of the API.

The test generator became the most collaborative repository in the story: ten people have committed to it.

Then the SDKs were tested against each other. A conformance harness wraps all seven SDKs in thin adapters, sends the same operation to each, and compares the HTTP requests they would send. Seven SDKs must agree on every operation in the spec.

assert-json-bodyExtracts response bodies from the OpenAPI spec and asserts them in Playwright tests. 24 releases.
camunda-sdk-conformance-testCross-SDK conformance: about 250 spec operations, sent through all seven SDKs, requests compared. Runs as a gate before an SDK release.
api-test-generatorSemantic graph extraction and test generation from the spec. 838 commits from ten contributors.
Stage 3, continued · Profile every workload

“Profile your workload” was the only honest answer. Now we profile all of them.

Customers ask how to deploy their workers: how many processes, how many workers in each, REST or gRPC streaming, which SDK. Before, the honest answer was “profile your workload”. Nobody had the time to measure every combination for even one SDK.

At agentic speed, the measurement is the cheap part. A performance matrix runs every valid combination of worker topology, SDK language, SDK mode, handler type and cluster size, locally or on Google Cloud, and publishes the results to a dashboard.

The answers are now specific. Prefer streaming when you run many workers: its tail latency stays flat while REST long-polling climbs. Spread workers across processes, about one event loop per core, instead of adding workers to one process. Set the C# poll interval to 25 ms: in the Google Cloud runs, that alone took throughput from 117 to 146 jobs a second.

The matrix also feeds the SDKs: it produced the proposal for threaded workers in the JavaScript SDK. For the method behind it, and how the conformance harness works as an oracle, see Point them at a number.

1,280scenarios in the full matrix
8SDK builds in 7 languages, 4 transport modes
20worker topologies × 2 handlers × 2 cluster sizes
~84kauthored lines, 151 commits, two contributors, since March 2026
Up, and out

It wasn’t one person getting faster. Other people learned it too.

An approach that only works for the person who invented it is a trick. This one transferred: to a student who learned it from scratch, and to a team that took a whole repository over.

From work experience to SDK co-owner

She joined as a student intern on work experience and learned agentic engineering from scratch. She is now an engineer on staff.

  1. Mar 2026: first commits. README examples and fixes across the JS, Python and C# SDKs, with a lot of “address review feedback”.
  2. May 2026: first change to shared tooling (schema-bundler).
  3. Jul 2026: leads the Go SDK. 123 of its 137 human commits are hers.
  4. Sep 2026: leads the Java SDK. 64 of 72.

870 commits and 167k authored lines across 9 repositories in eight months. She is now a co-owner of the SDKs and the principal driver of several of them.

The QA team took over the test generator

api-test-generator was built in April and May. In June it changed hands. Since July, every commit has come from the QA team and its contributors.

Original engineerQA team & contributors
  1. The QA team runs its own automation on it, pinning the spec and opening PRs.
  2. Four student interns contribute too. Their open pull requests extend it to generate SDK test suites for JS, Python and C#.

From one owner to a pod of three

Before going agentic, one engineer owned the SDK. Now the SDKs have an SDK pod of three people. The former intern co-owns them and drives several. A third engineer brings the human bus factor down, and supports the SDKs in production with an agent that picks up production issues, so a report from the field becomes a fix without pulling the others off their work.

Stage 4 · The research garden

Then we pointed the same discipline at the process itself.

The nanobpm organisation started as research spikes. It became a Rust BPMN engine compatible with Camunda 8, compiled to WebAssembly to drive interactive examples in the docs and on the website, plus the orchestration we now use internally for the agentic SDLC.

The biggest spike on the chart, August 2026, is mostly this garden.

nano-bpmRust BPM engine, with a WebAssembly build. 1,319 commits.
nano-ideIDE extensions for Nano BPM.
nano-workforceOpinionated agentic SDLC orchestration, built on Nano BPM.
bojtosIn-browser BPMN demo framework on the WASM engine.
nano-coder, nano-supervisorA 6 MB coding agent, and the supervisor and job workers that run a fleet of them.
Reading the numbers honestly

Volume isn’t value. But these numbers survive the obvious objections.

“It’s generated code.”Excluded. Generator output, vendored specs and lockfiles are not counted: another 3.2 million generated lines sit on top of these numbers.
“Agents just make smaller commits.”The opposite. The median commit grew from 29 changed lines to 157. The commit ratio understates the change.
“The team got bigger.”It did, and that is part of the result. The same engineer alone went from 182 commits a year to 3,649, and everyone else together added another 1,300. Try the switches on the chart.
“Lines of code are a bad measure.”Agreed, so look at what shipped: releases of the published packages went from 59 a year to 438, across seven languages instead of one.

Source: the full git history of the 22 public repositories named in this chapter, merges excluded. Bot authors (Renovate, release automation) are excluded from commit and line counts. “Authored” means written by a person or by an agent working for them. Snapshot taken October 2026. The conformance harness and the performance matrix are internal repositories and are not counted in these numbers.

So

The explosion came from the structure, not from the agents alone.

Engineer A hardened the spec first, derived the SDKs and the tests from it, used the new capacity to measure what nobody could measure before, then taught the approach to an intern and a QA team. One owner became a pod of three.

The speed came from the agents. Where it went came from the structure. Two more engineers got there on their own, in different settings: see Three shapes. And in c8ctl, the method left the SDKs.