Tessl takes the most radical position on the Spec-driven development spectrum: spec-as-source, where the specification is the only artifact developers edit directly, and code is entirely generated from it and regenerated whenever the specification changes. The report that places it there says Tessl represents what that report calls the emerging vision of specs as “the new source code” — developers work in terms of requirements and behavior, and any change in functionality means changing the specification and regenerating rather than hand-editing the generated code.
Capabilities
A chapter of Jimmy Song’s online handbook 智能体构建指南 describes it as an experimental framework and
records three concrete mechanisms. It documents a tessl document --code command that works in the
reverse direction from the one above, deriving a specification from code that already exists. It
states that generated code carries a // GENERATED FROM SPEC – DO NOT EDIT marker, which is how the
spec-as-source boundary is made visible in the tree itself rather than only in the workflow. And it
names @generate and @test tags used to control what generation does. That account places Tessl as
an early form of the move toward spec-as-source rather than a finished one.
Adoption & Ecosystem
A 2026 practitioner’s survey of spec-driven development tools (From Code to Contract: Spec-Driven Development in the Age of AI Coding Assistants) places Tessl at the spec-as-source end of a three-part toolkit taxonomy that also includes GitHub Spec Kit and Kiro, noting that this approach requires mature, trusted code-generation tooling to be practical. The handbook chapter above lists it among eight representative implementations of the practice, the same three among them.