Dark Factories: Retooling for LLM Velocity
A senior developer at Camunda has published a detailed account of how he rebuilt an entire SDK portfolio around LLM-generated code, making whole categories of runtime bugs literally impossible to write. The approach, called a "dark factory," removes human developers from the mome...
Josh Wulf, writing for Medium under his handle @sitapati, published a 48-minute read this week laying out exactly how his team at Camunda restructured their SDK development process to run at what he calls "LLM velocity." The piece is unusually concrete for this genre. Wulf is a Senior Developer at Camunda, the process orchestration company, and the primary output of the shift he describes is the Camunda Enhanced SDK Portfolio, released with Camunda 8.9, covering TypeScript, Python, and C#.
Why This Matters
Most writing about AI and software development stays abstract. Wulf's piece does not. He names a real product, a real version number, and a real failure mode that motivated the entire project. This is the kind of detail that separates a genuine engineering inflection from marketing copy. The SDK portfolio he describes was built from the ground up so that code generated by an LLM either satisfies the TypeScript compiler or it does not compile at all, which means the entire class of "looks right, fails at runtime" defects is gone. For engineering teams shipping SDKs that third-party developers depend on, that is not a minor quality improvement.
Daily briefing from 50+ sources. Free, 5-minute read.
The Full Story
Wulf opens with a blunt admission: after thirty years as a software developer, LLMs took his job, and he let them. He still ships software. He just does not write it anymore. That framing matters because it sets up everything else. He is not describing a workflow where a developer uses an AI assistant to autocomplete lines. He is describing a system where the developer's role has shifted from writing code to designing the constraints under which a code-writing system operates.
The original problem was specific and instructive. Camunda's older SDK would let an LLM produce code that passed TypeScript's type checker and compiled cleanly but then failed at runtime. An experienced Camunda engineer looking at that code could tell immediately it would break. The TypeScript compiler could not. Wulf and his team asked a pointed question: if a human can detect the defect by reading the code, why can't the type system detect it? The answer to that question became the architectural foundation for the new SDK portfolio.
The solution was to generate the SDKs directly from the OpenAPI specification of the Camunda 8 Public API rather than handwriting them. When the source of truth for the SDK is the API spec itself, and the type system is built to express the full constraints of that spec, then the compiler inherits the knowledge that a human engineer previously had to carry in their head. The result is that certain runtime failures become compile-time failures. The LLM cannot produce that class of broken code anymore, not because the LLM got smarter, but because the type system got stricter.
Wulf calls the overall approach a "dark factory," borrowing from the manufacturing concept of a lights-out facility, a production floor so fully automated that you can turn the lights off because no humans need to be present. In software terms, that means designing the system so that the automated process, the LLM writing code, produces verifiable output without a human in the review loop at every step. The human's job moves upstream, into designing the constraints, not downstream, into checking every output.
A secondary artifact of the project is c8ctl, an open-source CLI for operating Camunda 8, available on GitHub at camunda/c8ctl. Wulf uses examples from c8ctl throughout the piece to show what the new SDK patterns look like in practice.
Key Details
- Josh Wulf is a Senior Developer at Camunda, with over 30 years of software development experience as of 2025.
- The Camunda Enhanced SDK Portfolio was released with Camunda 8.9, covering TypeScript, Python, and C#.
- The SDKs are generated from the OpenAPI specification of the Camunda 8 Public API.
- The motivating defect was LLM-generated code that passed TypeScript's type checker but failed at runtime.
- The secondary project, c8ctl, is a CLI for Camunda 8 and is available publicly at github.com/camunda/c8ctl.
- Wulf's Medium post is a 48-minute read, published approximately 11 hours before this article.
What's Next
Teams using Camunda 8.9 can now evaluate whether the new SDK patterns actually deliver on the compile-time safety claims Wulf describes, and that real-world testing will determine how widely this approach gets adopted. The broader question is whether other SDK maintainers and platform teams will adopt the generate-from-spec-plus-strict-types pattern as a standard response to LLM-generated code defects. Watch for similar announcements from other API platform teams in the next two to three quarters as this architectural idea propagates.
How This Compares
The closest parallel in the industry is how Stripe has approached its SDK generation for years, building from a single source-of-truth spec and generating client libraries across multiple languages. What Wulf is describing at Camunda is the same principle, but with an explicit second-order goal: make the generated SDK resistant to a specific new class of defect that only became common once LLMs started writing the application code that calls the SDK. Stripe optimized for consistency across languages. Camunda's new portfolio optimizes for LLM-safety, which is a different constraint and a newer one.
Compare this to the approach Simon Willison, one of the more credible voices covering AI tooling, described in a November 2025 appearance on Lenny's Podcast. Willison called that period a genuine inflection point for agentic engineering, where developers stop treating LLMs as assistants and start treating them as systems to be constrained and directed. Wulf's piece is a concrete implementation of exactly that idea, and it predates most of the tooling-focused writing that followed Willison's framing. Wulf did not write about the theory first. He shipped a product first and then wrote about what he learned.
The piece also lands at a moment when Business Insider and others have reported that enterprise AI adoption has not yet approached the capability ceiling of current LLMs. If that is true, then Wulf's dark factory model represents an early example of what it looks like when an engineering team actually tries to close that gap, not by prompting harder, but by rebuilding the constraints around the model. That is a meaningfully different strategy than most of what gets published in the AI tools and platforms space, where the default advice still centers on better prompts and better retrieval.
FAQ
Q: What is a dark factory in software development? A: A dark factory in software development is a system designed to run with minimal human intervention, similar to a lights-out manufacturing facility. In Wulf's usage, it means structuring your codebase and type system so that LLM-generated code either satisfies strict compiler constraints automatically or fails to compile, removing the need for a human to review every output.
Q: How does generating SDKs from an OpenAPI spec prevent bugs? A: When an SDK is generated directly from an API specification rather than handwritten, the type definitions in the SDK can encode every constraint the API actually enforces. That means the TypeScript compiler, or the Python or C# equivalent, knows about rules that a human engineer previously had to memorize, and it will reject code that violates those rules before the code ever runs.
Q: What is the Camunda Enhanced SDK Portfolio? A: The Camunda Enhanced SDK Portfolio is a set of next-generation client libraries for Camunda 8, released with version 8.9. It covers TypeScript, Python, and C#, and was built from the ground up to support human-LLM collaboration by making incorrect code fail at compile time rather than at runtime.
The dark factory concept is going to keep gaining traction as more engineering teams hit the same runtime-bug-from-LLM-code problem that Wulf documented at Camunda. His approach, building stricter type systems around generated code, is reproducible and does not require any new AI capabilities. Subscribe to the AI Agents Daily weekly newsletter for daily updates on AI agents, tools, and automation.
Get stories like this daily
Free briefing. Curated from 50+ sources. 5-minute read every morning.