Agentic coding tools are powerful, but they are also unreliable and overconfident. They dive into code too quickly, often producing the wrong solution or leaving work unfinished. Common issues include hallucinated APIs, version blur, and unintended side effects that impact other parts of the app.
Tessl’s answer to this is spec-driven development (SDD), which captures intent in structured specifications so agents can build with clarity and guardrails. To put this approach into practice, Tessl last week launched its first products: the Spec Registry, available now in open beta, and the Tessl Framework, which is in closed beta.
“Spec-driven development \[...\] gives agents the information they need about both what and how you want them to build, bolstered by tests and hard guardrails,” Tessl founder and CEO Guy Podjarny explained.
What is the Tessl Framework?
The Tessl Framework lets teams define what to build before they start coding, using carefully crafted specifications (“specs”) or AI-generated “vibe-specs.” These instructions live in the codebase as long-term memory, guiding agents as the app evolves and pairing with tests to enforce guardrails so existing functionality isn’t broken.
What is the Tessl Spec Registry?
The Tessl Spec Registry helps agents use open source libraries correctly, with more than 10,000 pre-built specs that explain how to avoid API hallucinations and version mixups. Teams can integrate these specs directly into their projects to give agents the right context, or publish their own to share internal guidelines.
Combined with the Tessl Framework, the Registry helps agents deliver more reliable, maintainable code.
What a spec looks like
A typical Tessl spec has three parts: a description of the software component that the spec represents, a list of capabilities with linked tests, and an API showing how to use it.
Here’s an example from the Tessl platform: a spec that defines a simple math library and generates code to match its capabilities.
Key details worth highlighting from this spec include:
[@generate](./src/index.ts): This tells Tessl to generate code from this spec. Specifically, the /src/,[object Object], file An alternative, @describe, means the spec documents existing code rather than generating it.
- It adds two numbers together [@test](../tests/add.test.ts): This shows a capability described in natural language, with a linked test at ../tests/add.test.ts.
ts { .api } export function add(a: number, b: number): number; export function subtract(a: number, b: number): number;: This defines the component’s public API. In this case, two functions (add and subtract) that each take two numbers and returns a result.
[,[object Object],(./big-int.spec.md): This imports other specs, so their functionality can be used inside this spec.
A second kind of spec
Tessl also supports a second kind of specification: the usage spec, which focuses less on defining what a component should do, and more on how to use it. These give agents practical guidance for a specific version of a library or service, covering best practices and usage patterns.
A usage spec can also capture team- or organisation-specific rules: details of a particular tech stack, internal libraries, APIs, or security policies. This ensures agents follow not just general best practices, but an organisation’s own standards.
You can browse examples of usage specs at tessl.io/registry, where many popular open-source libraries are already covered.
