Revolutionising Spec-Driven Development with Tessl’s Framework & Registry

[00:01:36] Simon: Hello and welcome to another episode of the AI Native Dev and this is a pretty special episode.

Guy: Indeed.

Simon: Joining me as regular host is regular host Guy Pod. Welcome.

[00:01:47] Guy: Yeah, thanks for coming onto the show, Simon.

[00:01:48] Simon: It's my pleasure. So who's interviewing? Utter I'll interview you. That's probably…

Guy: Let's just improvise and see where it goes.

[00:01:54] Simon: So, yeah Guy, it's a special occasion. What's this special occasion?

[00:01:59] Guy: Yeah, it is. It's a big day for us. We are unveiling Tessl. We're launching Tessl's products, which we'll talk a fair bit about. And it's exciting. We've been building this for quite a while, so we can't wait to tell you more about it.

[00:02:12] Simon: Yeah. And so it's available right now on tessl.io. So go ahead, have a play, see what we got. But Guy, why don't you tell us what are we launching?

[00:02:20] Guy: ure. So we're launching two products actually. It's like why one, you know, why choose. In general, they're both in the world of spec driven development.

[00:02:33] Guy: We'll talk more about that. The first one is the Tessl framework, which is a solution that integrates into your agent and helps it start developing in the sort of spec driven approach as we'll explain. And the second is the Tessl spec registry, which helps agents use open source better and expands into generally distributing information through specs to agents for everything that's not in their code base.

[00:02:58] Guy: So both products [00:03:00] together are to us a part of what is spec driven development. And yeah, we'll explain about both, but as Simon pointed out, we're going to blabber here a little bit and explain more about it. But if you're keen to try them out, just check out tessl.io and start playing with the tools.

[00:03:15] Simon: Yeah. Two minutes into this episode, you might as well stop now and just go and try out, consider your life choices. Yeah, exactly. So every good solution Guy has a pain. Well, some. I always used to laugh at when people said blockchain.

[00:03:29] Simon: That's a solution looking for a problem. Right. Tell me what the problem is that we're trying to solve here at Tessl, but also AI and things like that we are trying to solve.

[00:03:39] Guy: Sure. So we have the meta problem that is semi problem, semi opportunity that I think you've heard us talk about a fair bit, which is that software today is code centric, and in that code we forget what we wanted the product built for in the first place. And we think [00:04:00] there's an opportunity to change to this spec driven development world in which your software is defined through its specs. But that's the vision, that's the destination. The more concrete problem we're talking about now, and we're trying to tackle, is around agent development. And if you're using agents to develop, then you've probably seen that agents are powerful, but they're also unreliable.

[00:04:22] Guy: And they're definitely overconfident. You would ask them for something, they'd go off and rush to start coding the first solution that comes to mind. Oftentimes that would be the wrong thing. Or they misunderstood you and you find yourself needing to fix it after the fact.

[00:04:36] Guy: Or they would make things up. They would say they're done when they're not really, like they say, hey, fixed the problem, or like, oh, 59 out of 75 tests pass, I think I'm good. It's like, no, you're not. They hallucinate information that is outside. They hallucinate APIs, they hallucinate [00:05:00] libraries sometimes, and all of those really culminate as you start to build bigger and bigger.

[00:04:55] Guy: So you use the agents, you wrangle them, you review them, and you get them to a safe spot, and then you add the feature and they break something else. All of those are reliability problems that mean that if you're using agents, you are in this perpetual review motion.

[00:05:18] Guy: You are just trying to understand what they have done, was it correct, review the products and the outputs, and when you encounter a problem or something that was incorrect, it's really hard to fix things in hindsight. Because you need to go back. How far back do I go? Do I revert the changes altogether?

[00:05:38] Guy: I think this is the biggest pain that people using agents today experience. For those who stick to it and build with agents, they have to build their techniques, and it's the challenge they face day to day, which is how do I minimize the amount of reviewing that I need to do and get these agents to do what I need them to do?

[00:05:59] Guy: And for many people, it's [00:06:00] actually a blocker. They can't get into agent development because the systems are just too reliable. These agents are just too unreliable, uh, to, uh, sorry, lemme sort of say this. For some people, uh, they just can't get into agent development today at all, uh, because of this blocker.

[00:06:18] Guy: And for many people, it's [00:06:00] actually a blocker. They can't get into agent development because the systems are just too unreliable to use in a professional setting. We think we can address many of these problems through specs and spec driven development, and that's what both of our products are trying to solve.

[00:06:31] Simon: It's super interesting. For me personally, I guess two of the pains, and I've used many different agents a lot.

[00:06:38] Simon: Two of the pains which really spring to mind for me are: I start coding with agents and you feel that magic, you feel the true vibe coding nature of, I give it a little, I get a lot back. But then as soon as the app gets to a certain size where it has an amount of functionality and capability, [00:07:00] you hit this ceiling whereby exactly what you referred to.

[00:06:59] Simon: [00:07:00] I change one bit and a whole bunch of other things change, even if I've already specified this is how I want that to work. It almost neglects some of my previous comments, even though that is part of the context from the original conversation, and so forth.

[00:07:19] Simon: It makes it almost like you can't continue with the agent because it becomes more work to keep it on track. That becomes a huge pain. The other problem that I have is sometimes you get to this stage where you actually have to almost give up and say, I have to start again.

[00:07:37] Simon: Right? It's got itself in such a knot I can't continue down this path. These are the limitations of the vibe coding way, which actually give it a blocker from going into that enterprise, production style level of reliable code.

[00:23:10] Simon: So yeah, I think these are super important and common pain points that both we and most of the world who have been using AI have suffered and failed on a day-to-day basis. What are the two products then that we are releasing?

[00:23:25] Guy: Two products, both very exciting. The first one is the Tessl framework, and that is really a spec driven development framework that connects to your agent via MCP.

[00:23:35] Guy: So we support all the agents that support it and guide it to capture its intent in specs before it builds. You give it an instruction, whatever. Build me a to-do app or whatever it is, and before it jumps into code, it first creates a spec thanks to using Tessl's tools and Tessl's guidance to say what it wants to build in [00:24:00] a quick and easy to understand format, and then it goes off to build it.

[00:24:03] Guy: And have you had a case where you gave an instruction and the agent rushed and ended up building the wrong thing?

[00:24:10] Simon: It's not just daily, maybe hourly when I use agents. It's a twofold thing. One where I either give it an instruction and it hasn't quite understood exactly what I meant.

[00:24:21] Simon: And it's because I love to short prompt because I get value and speed out of short prompting. The other is where I ask it for a small change in a larger app and it then goes ahead and starts changing other pieces, which, so it..

[00:24:34] Guy: expands it over the app.

[00:24:35] Guy: Oh gosh.

[00:24:35] Simon: It's frustrating.

[00:24:36] Guy: So that's the first goal. Separate intent from implementation and capture what it means to build in a spec. And then once you are comfortable with the intent and with what has been built and you're happy with it, Tessl offers you an easy way to generate tests with a single command.

[00:24:57] Guy: This is done because the spec [00:25:00] is actually designed upfront to be built with a lot of test cases in mind that serve as examples when you initially generate. Those are the key definitions to go off and create tests, and the agent needs to work a little bit harder to be able to generate those tests.

[00:25:16] Guy: It needs to set up a test environment, sometimes iterate, but it does it quite autonomously, and once it works, those serve as regression tests. So now you know it would not do, as you mentioned before, you make a change and then it goes off and breaks something else.

[00:25:31] Simon: Yeah. And that leads into whether you prefer to do a test driven test upfront kind of phase or whether you want to do that innovation and creation first, and then once you're happy with what you have, do tests later. I think there's never a right or a wrong answer. It massively depends on either organization or individual preference of how they want to build. But you have both solutions with that same centricity over the specification.

[00:25:58] Guy: Yeah, exactly. We went a lot of back and forth on do we want to be opinionated about one versus the other. But in practice, even the same person, in the same company, for certain tasks, sometimes you want to create the spec, review the spec, ensure that what you mean to build, that your intent is well captured, that the test cases represent what you want, and you're willing to invest that time because you have enough opinions and it's important enough or maybe unique enough, like rules of some new game or whatever it may be. Then you want to invest that time. The Tessl framework supports that, and it's very easy and natural to do it. And then once you have defined those, you send the agent off to build and you have those guardrails so the agent can work more autonomously until it gets it right.

[00:26:45] Guy: But the other mode that we've started calling vibe specing is also legit. As we've heard Ollie from Datadog, CEO and founder of Datadog, tell us in a previous episode, the biggest slide that customers tell you is that if it's important, they'll invest the time. In practice what we see in ourselves and our users is that oftentimes people just want to get to working code [00:27:00] as quickly as possible.

[00:27:08] Guy: So this vibe specing mode is one in which you don't create the test upfront. You don't really know what it is that you want, so you just flow with it. You allow the agents to make the decisions as you did before. You're just now capturing those decisions in these different documents.

[00:27:26] Guy: So it's easy for you to proceed. And even if you've done that, those regression tests still serve as a guardrail for future evolutions of it. So even if you went the casual mode, you still get some extra protection.

[00:27:39] Simon: Yeah, and ultimately you get the same thing at the end of the day. You have your code, you have those tests that make sure the code that's generated satisfies the specification, and the specification really importantly still holds all the intents. Whether you go test first or whether you go test after, it's not opinionated in such a way.

[00:27:58] Guy: Exactly. You can now continue and you have something you actually didn't have before in software development as a whole, which is this long-term memory as the specs get committed to your code base of what your product should do. [00:28:11] Guy: We actually don't really have this in software development today. We have docs, but because they are not the source, they're not the file through which changes get applied, they oftentimes fall out of date, as we all know.

[00:28:25] Simon: Not that dusty PRD down in the basement you're talking about.

[00:28:28] Guy: Exactly. It's not these fragmented requirements nor even user docs. You have these specs and the specs capture your intent over time, and you can keep coming back to them. It's an easy way to manage tests and relate them to the product. The true biggest value of the Tessl framework actually comes as you continue building and continue evolving because you have these specs as part of your code base.

[00:28:53] Guy: Defining what your product should do and what the framework also does is it helps you ensure, again, with [00:29:00] minimal effort that they are always up to speed. Whenever we can, we end up modifying files through the spec. When you call an edit, you call the Tessl edit tool, and that modifies the spec.

[00:29:13] Guy: First and then modifies the code. And when the agent misbehaves or when you had some good reason to change a code file or a test file, we have means of detecting that and going back and updating the spec. And so we really try to make it as seamless as possible to always keep the specs up to date and to ensure that changes get applied through the specs.

[00:29:34] Guy: Really allowing you to sort of scale and grow. And we think that the more information gets captured in the specs over time, the more you can tap into the creative power, if you will, of the LLM or the ability to try many, many different things and try to make code that is faster, that is adaptable to change something from a Python environment to a TypeScript, to a Java, and not need to [00:30:00] worry that your functionality breaks in the process.

[00:30:02] Guy: So, a lot of value upfront as you create, but really, probably the biggest treasure trove is as you grow.

[00:30:10] Simon: Yeah. And these specs really build up to the lifecycle of the application, right? They just stay with the tests, with the code, all the way through. And continually, you as a user are focusing more on the specification than, yeah.

[00:30:22] Simon: Than anything else. Yeah.

[00:30:23] Guy: And that's a very important clarification because I think in the industry today, we use specs for various purposes. I think in the sort of nascent agent dev world, and for many people, specs are about a transition from point A to point B, from state A to state B. That is not how we think of specs.

[00:30:42] Guy: We do create plans as a natural part of the Tessl usage, and those plans are indeed temporary. Their life cycle or lifespan is the lifespan of the change. Mm-hmm. But the specs are really the definitive document that describes functionality, and their [00:31:00] lifespan is the lifespan of your code base.

[00:31:01] Guy: Yeah. Amazing.

[00:31:02] Simon: So, product one, the Tessl framework, the ability to create using a spec-driven approach, a spec-driven development approach. You mentioned agents being a little bit dodgy, a little bit wary sometimes. Tell us a little bit about product two, and how that kind of helps keep these agents on the rails.

[00:31:25] Guy: Sure. So the second product, which I'm very excited about, is the Tessl Spec Registry. And maybe going back a little bit to the pain point, I think what you see with agents is sometimes they do not know something, and they do not know they do not know, or...

[00:31:42] Simon: Story of my life. I'm basically an agent.

[00:31:43] Guy: They are kind of overconfident. You know, I am not, I am going to let that slide. I feel seen now. So they oftentimes, for instance, the most evident version of that is when they use an API, a third-party API or an open-source library API. If you are [00:32:00] using something that is straight up in the mainstream and they know it,

[00:32:02] Guy: They are amazing at it. If you are using something that is a little bit off, or using a slightly older version of a popular library, or even more if you are using a new version that did not exist yet when those models were trained, typically what the agents would do is just make it up as they go. They would use false APIs or flawed ones, and sometimes they would really get stuck in that mode and just waste time and money trying to get there, never getting out of it.

[00:32:29] Guy: And sometimes they would eventually figure it out, but it was time-consuming, costly, and oftentimes they were left with a slightly messy implementation. And have you experienced things like that?

[00:32:39] Simon: So much. And it is particularly because AI is great when it trains on a huge amount of open-source libraries with tons of different versions on there.

[00:32:52] Simon: When things, and I am talking about the Java world here, but when things progress over years and years and years, there are so many API [00:33:00] changes from different libraries, whereby the most popular is really the one it is going to be trained on. And I am not always using the most popular because I sometimes run on an old stack, or I am sometimes bleeding edge with some of the things I am using.

[00:33:11] Simon: And it is not just as much a hallucination as it is assuming this is the version you are running on, without actually using the correct context to build against when generating my app. Huge problem.

[00:33:22] Guy: Precisely. And so this is really a context problem, right? They do not have the right information at the right time. Sometimes because they literally do not have the info, like a brand-new library version. Sometimes because of a less statistically significant bit of information.

[00:33:37] Guy: And sometimes it is information there is no way for them to have, like your team's specific best practices or context. And so what we believe, and enable with the spec registry, is to make that knowledge a part of your project. So we introduce a new dependency system that the spec registry enables.

[00:33:56] Guy: That is a dependency system for knowledge, for specs. [00:34:00] You would have a new manifest file in your project that references certain spec packs, packages of specs with the right information to be able to work on this code base. More specifically, for open source, we have pre-populated the registry with over 10,000 usage specs, which are

[00:34:20] Guy: pre, like generated by analyzing the code of specific versions of libraries and additional information about those libraries from usage online. That is all version-aware. And we package them up in these easy-to-consume nuggets of knowledge for the agents. So these are Markdown files,

[00:34:38] Guy: with the right sections. They are split up into multiple files so the agent can load the right thing at the right time. And so, let us say you are using some library at an old version. Then the agent will, you will add that. You would use Tessl registry search to find the usage spec, it will be added to your manifest file, and those usage specs will be downloaded to your [00:35:00] project, just like node modules or other dependencies.

[00:35:03] Guy: And then, using Tessl tools and even natively, the agent can then find them and use the information correctly. And you know that this information is there, it is correct for your specific project, and it is always available to all the agents. You are not dependent on them realizing they need to go seek it out or misunderstanding it.

[00:35:24] Guy: And as your software stack changes or as your practices change, so does the information that you make available to the agents.

[00:35:32] Simon: And it is important here to raise that distinction between the spec that you referred to earlier, where we are creating a specification using the Tessl framework, and that specification allows agents to create code.

[00:35:44] Simon: It is effectively a blueprint of this is how I want you to build my application. The usage spec that you are referring to is quite different. It is telling the agent how I should use these various libraries or components so I can code against them. It reminds me, I do not know how well [00:36:00] this will travel to our listeners, but the Haynes manual for cars, it is the book that tells you every little bit about how a component works in a car.

[00:36:08] Simon: It is great to understand how every single component could work and can work, but it does not necessarily tell you how to drive the car. I would not look at that in order to be able to use a car correctly. That is the usage that I need. And so if you go in just understanding how a library can do things, what APIs are available and so forth, that only gives me half a story.

[00:36:31] Simon: It does not actually tell me how I should use it. Examples and best practices are the key distinction which usage specs here give us.

[00:36:38] Guy: Correct. And I think we talk a lot about what should be in the spec. Specs can hold many things, and we find ourselves now defining a type of functional spec versus a usage spec.

[00:36:48] Guy: Eventually, when we think about spec driven development and spec driven spec centric software, then oftentimes all of these will be part of the software package itself [00:37:00] because when you are creating a library, the information that you need to be able to regenerate that library again.

[00:37:09] Guy: Again, for instance, that might be more of a functional spec. It might be a bit more technical, but understanding that library both for the consumer and for future developers actually starts looking a lot more like a usage spec. So at the moment we are not. There isn't much software out there that is defined by specs.

[00:37:27] Guy: And so we are creating these kinds of docs for agents, for software that has been built in a code centric fashion. And we make it accessible in a very kind of agent friendly way with a good ax so that they can consume it and make it a part of that project, a dependency system for knowledge.

[00:37:45] Guy: And again, we've kind of spent some inference dollars so you don't have to, to make this information available to you so you can install it now and make your agents use open source better. But we think conceptually [00:38:00] there's more information that needs to be made available to agents than just usage specs.

[00:38:06] Guy: They could be around how do I add analytics to a project in my specific organization, right? How do we run a security scan over here and fix the vulnerabilities? Which logger should I use? All of those might be things that the agent can intuit or make up, but what it would make up is going to be inconsistent and oftentimes incorrect.

[00:38:26] Guy: So you need to get the right information to it. And you're right, you want that information to always be available for this project, and you want it to be cross agent as your team changes and moves agents over time. Yeah. So right now, use it to make your agent use open source better.

[00:38:47] Guy: And over time, start thinking about what would you publish into this registry and what else would you like to find there to consume?

[00:38:55] Simon: So the Tessl framework, the Tessl spec registry guy, [00:39:00] shut up and take my money. I can use all of this today, right now, right? If I go to tessl io.

[00:39:05] Guy: So almost, almost. So the Tessl Spec Registry is now available in open beta, so you can go to tessl.io and with a couple of clicks, you can get it installed and integrated on your.

[00:39:17] Guy: On your agent environment and start using it right away. And we'd love for you to try that and to send us feedback to build it up. The Tessl framework is still released in a controlled beta. So you can find..

Simon: Why, why? Guy, why?

Guy: So the development framework has a lot of moving parts and there are many, many, many ways that you can use it.

[00:39:39] Guy: nd today there's just a lot of freedom and we feel like there are too many opportunities for users to shoot themselves in the foot. And so we are making it available in a controlled beta. It's still like a large scale controlled beta and we want to evolve the onboarding experience, the right guardrails, the right learnings so that not everybody shaves on the [00:40:00] same practice.

[00:40:00] Guy: We think in general, creating the right spec driven development methodology is not something we've just solved. We are launching a version of that and we want to iterate on it with the world, with the community. And so we'd love for you to register and request access. And we intend to give many people access as we learn.

[00:40:19] Guy: But we're just going to throttle that or stagger that a little bit so that not everybody encounters the same problems. And as we improve, we hope fairly quickly to get to something that is an open beta and then eventually we'll take your money.

[00:40:32] Simon: Awesome. So right now if you go to tessl.io, you can have access to the spec registry.

[00:40:41] Simon: Tessl Spec Registry. Correct. That's open beta. The Tessl framework is being opened up to many more people on a throttled beta, and you can sign up to the waiting list, correct. For that. Yep. One of the interesting things which kind of like me and the team are doing here at Tessl as [00:41:00] well is we are opening up, we're not, we know we’re not

[00:41:02] Simon: Trying to keep everything hidden. We are opening up much, much more of our docs so you can see how you can use the Tessl framework, even if you don't have access today. There's a bunch of videos on Tessl io to be able to see Tessl, the Tessl framework in action. Exactly. And so you can see exactly what we're talking about here.

[00:41:19] Simon: And in fact, going forward, why don't I bring Macy on again? Remember Macy Baker, for those who watched, oh, she's amazing. A few episodes.

[00:41:27] Guy: Definitely invite her on the show much more than me.

[00:41:30] Simon: Let's get some demos going and we'll show you the framework in action as well.

[00:41:32] Guy: This is a part of what makes today special for us, this big unveiling. There are many thoughts, a long process to get to this situation. So we're happy to build in public even as we slightly, slightly control access to just help it all go smoothly.

[00:41:54] Simon: Yeah, and the best way to build in public of course is to get user and community feedback. The best way to do that, join [00:42:00] us on Discord. Links will be in the show notes, our Discord server. There are the Tessl channels, a couple of Tessl channels now in the AI Native dev community.

[00:42:10] Simon: So join that. Tell us what you're using there and you'll be joined to the correct roles and the correct channels where you can discuss both about the spec registry as well as the Tessl framework.

[00:42:20] Guy: Yep, yep. And indeed, we're seeking a lot of feedback. And there's a chance that if you're a valuable feedback provider, even if it's critical feedback on it, maybe you also get bumped up the wait list for the.

Simon: Oh, it's a popularity contest. I see. I see.

[00:42:33] Guy: It’s a usefulness

[00:42:35] Simon: It's a usefulness contest. Excellent. So yeah, you talked about the story a little bit about what we've been through. Tessl's obviously not a fresh company. It's been around for over a year now. I remember the episode that we did with 125 mil of funding and things like that. It's an established company. Tell us a little bit about the journey that Tessl has been through [00:43:00] to get to this point, to where we are today.

[00:43:02] Guy: So first of all, I think the company is over almost a year and a half old.

[00:43:09] Guy: And consistently we have believed that spec centric software is the future. And many of the core concepts of how we imagined spec centric software, sort of spec driven development, to look like are actually the same, surprisingly the same. But we also knew that we're anchored in the future and that the LLMs can't quite do it today.

[00:43:36] Guy: And so we went through I'd say maybe a couple of chapters over almost a year. At first it's kind of the naivety phase. And so we could imagine it. And so we said, fine, let's build a spec driven development platform that allows you to create in this sort of A ish environment software through specs, and we really were very, very [00:44:00] bullish in what can we do in a period of time.

[00:44:03] Guy: And that took maybe six months to get a better appreciation of the level of capability of LLMs at the time and understand that there's still a bit of a journey to be able to deliver. So we to deliver that. And so we were left with a lot of ideas about what's the correct destination, but was just a bit too much.

[00:44:27] Guy: And then we switched to a more controlled environment in which you could create software components through a very controlled web based development path. And we indeed managed to build something that matches the capabilities of the LLM. So you could create software libraries with Tessl in a spec driven fashion, in a next next experience.

[00:44:50] Guy: And users were quite interested in that, but it was too narrow and too big a change.

[00:44:58] Simon: Quite opinionated as well. I remember [00:45:00] when we were building that, it took us through a number of stages as well, where right, you need to be in this stage first, then you go to the code gen, then you go to the test, then you export and publish and blah blah blah.

[00:45:10] Simon: And we went through a number of changes even there, just working out if it's linear. Do users want jump through exactly various stages. It's a complex thing as well.

[00:45:18] Guy: It was hard. And the part of the reason that we went through that is because the LLMs were just not good enough.

[00:45:24] Guy: And so we needed to hold our hand and be very specific, but eventually the product we ended up with was not worth the leap. It was too narrow and too different. And so you couldn't really develop software in this fashion. And so in the last chapter, which is the one that I feel like we've [00:45:44] hit the mark. First of all, we said, hey, we need to abandon this closed web based controlled environment and embrace the roots of local file based, very open and tinker able development [00:46:00] environment and the CLI and then. Agents came along and I think agents were key for in two ways.

[00:46:06] Guy: You know, in part is because of the capability. They unlock an ability for AI to generate a lot more. And we have been building basically a version of an agent in the previous iterations of it, but there was clearly a lot more, and especially with cloud code and the terminal based approach, there was a lot more that they can do.

[00:46:22] Guy: But more importantly, it surfaced an immediate version of the pain that we're addressing. And so we from the beginning said the pain we're addressing is this big pain of software development. You develop software and over time you forget why, what the software is meant to do, and you're just left with a code.

[00:46:43] Guy: And then over years that problem manifests and software becomes fragile because you forget who it was. Agents is like a microcosmos of that. They've got amnesia, right? You tell them to do something today and the next day [00:47:00] they forget it. They don't remember it anymore.

[00:47:02] Guy: Nobody has knowledge of the code because they've written it. And so nobody understands the code or any meaning that is within it. And you really face first with the problem that the code just doesn't have enough information. And then they have all these other symptoms that are like in software development.

[00:47:23] Guy: Sometimes they misunderstand you, just like developers might, but it's a faster iteration and therefore they build the wrong thing. And fixing problems after the fact is harder. And a great developer today, you tell them, hey, I need this change in the system. They will stop and say, okay, what's the product impact? What are the use cases that you're trying to satisfy so I can prioritize my work accordingly?

[00:47:38] Guy: And so to an extent that's what we're doing to the agents. We're trying to make them do that. And so I think it is very invigorating and it just feels a lot better to say, okay, we remain true to this vision of spectrum and [00:48:00] development.

[00:48:00] Guy: And again, a lot of the concepts are the same ones that we've been iterating on for a year and a half now, but we now have a real user with a real pain that is incremental that we can build with, that we can make that user successful at using agents better. And so I think this is the chapter that we're in and I've been saying like, we knew the destination, but now we found the trailhead.

[00:48:23] Guy: Yeah. You know, we were wondering this path and saying, okay, fine, but where does the path start? And now we find the trailhead and now we run.

[00:48:30] Simon: And I think it's amazing how. And this is the first time I personally have joined you or anyone on a journey so early in a startup stage.

[00:48:37] Simon: And I think one thing that I think is quite amazing is how startups can so quickly pivot. Say, look, this isn't the way, this is the way, this isn't the way, this is the way. And recognize that based on the changes that have happened in the industry, and of course AI, nothing's changed the industry so much as AI in as many months.

[00:48:58] Simon: But, but [00:49:00] yeah, it's that bravery and courage to be able to say, actually, look, this is the change here. We're not gonna continue on this path. We pivot completely to say. Same problem, same issues at its core, but the way in which we tackle them, the way in which our users are using technology today changes our approach.

[00:49:17] Simon: Right. And the change, the path changes quite significantly.

[00:49:21] Guy: It does. And that's actually also probably the bit that I think is most critical and that I'm most proud of the team for doing is really this adaptability. Right, like we have, we have a great team here. It's not a small team. Now we're sort of 37 people I think now.

[00:49:37] Guy: And you know, it's a lot of people, they've written a lot of code, which they've subsequently deleted. Sometimes because we've shifted and we're in this chapter, sometimes because new evolutions with LLMs have kind of rendered it unnecessary. And those are, that's not easy. You know, it's easy to get attached to the thing that you're building.

[00:49:56] Guy: It's easy to sort of stick to a path. What do [00:50:00] you mean, you know, like, I've built this and I'm kind of passionate about this creation that I have. And I think our team is very focused on, you know, we understand this vision. We want to bring it to life, and we're trying to provide value to users.

[00:50:12] Guy: In fact, probably the biggest complaint amidst the teams is like, we want more users because everybody's so attuned to say, okay, like, I want to, I want to show this to more and more users. Now, of course, we've had users all along, but not in vast quantities as we're sort of exploring the way.

[00:50:29] Guy: So everybody's very keen to doing it, but super proud of the team for being willing to sort of throw away past work if it is not the right path forward, for being kind of no ego, and aligning with the group. Because we're, again, we're sort of a larger group now. And coming along as we make changes in the sort of nebulous potential paths.

[00:50:52] Guy: And I guess most immediately in rallying towards this launch was like a lot of work to get done over the last few weeks. And I think now [00:51:00] we get the best opportunity of letting the team shine, which is engaging with users, responding to problems, and continuing to build with the speed that we have here.

[00:51:10] Simon: Yeah, it's amazing. And of course that whole team is ready to now engage and chat much more publicly indeed than ever before on the Discord. So this pretty much wraps it up. Extremely exciting news and amazing to be able to share this with the broader audience. Yep. And Guy, you'll be on Discord just as everyone will.

[00:51:31] Guy: I'll be on Discord and probably not the sort of the smartest person for you to engage with to solve problems there.

[00:51:36] Guy: But if you want some sort of philosophical ramble, I'll be there. I'll be there. And we do look forward to having all of you join us on the Discord and engage in this journey. Again, we're not claiming to have solved spec driven development. We understand these things take iteration, and we're here to iterate and fix problems that you encounter, needs that you have that we've not yet solved.

[00:51:58] Guy: And so very, very keen for you to [00:52:00] try it out, you know, both the spec registry and the framework, and to tell us what you think and just stay engaged in the community as we make more and more concepts of this journey available.

[00:52:13] Simon: Absolutely. So tessl.io, you can use the spec registry right now.

[00:52:17] Simon: Tell us what you think on Discord, and of course, sign up for the Tessl framework throttle beta program as well. We'd love to get your feedback on that. Once again, Guy, really appreciate this chat. It's great to, it's great to be here in person again.

[00:52:32] Guy: Indeed, indeed. Exciting time. Thank you, Simon.

[00:52:34] Guy: Thank you. And, yeah, now the fun part begins.

[00:52:38] Simon: Thanks for listening and tune into the next episode.