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

7,530 words · about 30 min to read · YouTube’s automatic captions

Launching Tessl to fix unreliable coding agents

0:00 It's a big day for us. We are unveiling Tessle. We're launching Tessle's products. And it's it's exciting. We've been building this for quite a while. And if you're using agents to develop, then you've probably seen that agents are powerful, but they're also unreliable. So you would ask them for something, then go off and they rush to start coding. The first solution that comes to mind and often times that would be the wrong thing. For some people, they just can't get into agentic development because of this blocker. And so we think we can address many of these problems through specs and specdriven development. That's what both of our products are trying to solve. What are the two product that we're releasing?

0:34 The first one is the Tesla framework and that is really a specdriven development framework. The second product is the Tesla spec registry. 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. It's rules of some new game and the Tesla 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.

1:11 Before we jump into this episode, I wanted to let you know that this podcast is for developers building with AI at the core. So whether that's exploring the latest tools, the workflows, or the best practices, this podcast's for you. Now, we've had amazing guests like Olivier Pomel, the CEO of Data Dog, Matty Stanisowski, the co-founder of 11 Labs, Victor Ripelli, the CEO and co-founder at Synthesia, and of course, Tessle's very own Patrick Dubois. And they're all sharing lessons right from the frontier of our industry. A really quick ask, 90% of people who are listening to this haven't yet subscribed. So, if this content has helped you build smarter, hit that subscribe button and maybe a like. It really does help us keep bringing the folks who are actually pushing this space forward and helping build that AI native future. All right, back to the episode. Hello and welcome to another episode of the AI native dev.

2:10 And this is a pretty special episodedeed. Joining me as regular host is regular host GO. Guy,

2:16 thanks for coming on to the show. Sim,

2:18 it's my pleasure. So, uh, who's interviewing? I'll interview you. Uh, there probably

2:22 Let's just improvise and see where it goes. Um, so yeah, guy, it's a special it's a special occasion. What's this special occasion?

2:29 Yeah, it is. It's a it's a big day for us. We are unveiling Tessle. We're launching Tesla's products, which we'll talk a fair bit about. Uh, and it's it's exciting. We've been building this for quite a while. Uh, so we can't wait to tell you more about it.

2:42 Yeah. And so it's available right now on Tesl.io. So go ahead, have a play, see what we got. But guy, why don't you tell us what are we launching?

2:50 Sure. So we're launching uh two products actually. sort of can't uh you know named it twice. Yeah, it's like why one you know why choose. Um so actually uh in general they're both in the world of specdriven development. We'll talk more about that. Uh but the first one is the Tesla framework which is uh a solution that integrates into your agent and helps it uh start developing in the sort of specdriven approach as we'll explain. And the second is the Tesla spec registry uh which helps agents use open source better and expands into generally distributing information through specs to agents about everything that's not in their codebase. So both products together are to us a part of what is specdriven development. Uh and yeah, we'll sort of 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 des.io and start playing with the tools.

3:45 Yeah. Yeah. 2 minutes into this episode, you might as well stop now and just go and try it out.

3:49 Consider your life choices.

Software loses original intent in code-centric development

3:50 Yeah. Exactly. Exactly. So, so let let's talk about every every good solution guy has a has a pain. Well, some some I always used to laugh at when people said blockchain. Oh, yeah. That's a that's a solution looking for a problem, right? Tell me what the problem is that that that you know we're trying to solve here at Tesla, but also AI and D and things like that is trying to solve.

4:08 Sure. So we have the the meta problem that is semi-pro semi- opportunity uh that I think you've heard us talk about a fair bit which is that uh software today is code ccentric and that in that code we forget what we wanted the product built for in the first place and uh and that we think there's an

1 Highlight · Why coding agents suffer from reliability and overconfidence

4:27 opportunity to change to this spec driven development world in which your software is defined through its specs. Um but that's that's the vision that's the destination. But the more concrete problem we're talking about now and we're trying to tackle is around agentic development. Uh and if you're using agents to develop then you've probably seen that agents are powerful but they're also unreliable. Uh and they're definitely overconfident, right? So you would uh you would ask them for something that go off and they rush to start coding the first solution that comes to mind. Uh, and oftentimes that would be the wrong thing or they misunderstood you and you find yourself needing to fix it after the fact or they would make things up, right? They would say they're done when they're not really like they they say, "Hey, I fixed the problem." Or like, "Oh, 59 out of 75 tests pass. I think I'm good." It's like, "No, you're not." Um, and sort of similarly, they hallucinate information that is outside. They hallucinate APIs.

5:22 They hallucinate uh all libraries

5:25 sometimes. And all of those really culminates as you try to build bigger and bigger. And so you you use the agents, you wrangle them, you review them, and you get them to a to a safe spot, and then you add a feature, and they break something else.

5:37 And so all of those are are sort of this reliability problems that mean that if you're using agents, uh you are in this perpetual review motion. You are just trying to understand what have they done, was it correct, review the products and the outputs. And when you encounter a problem or something that was incorrect, uh it it's really hard to fix things uh in hindsight cuz you you kind of need to go back. How far back do I go? Do I revert the changes altogether? Uh and I think this is the biggest pain that uh people using agents today experience. For those who stick to it and build with agents, it's, you know, they have to build their techniques and and it's the challenge that they face dayto-day is how do I minimize the amount of reviewing that I need to do and get these agents just to do what I what I need them to do. And for many people, it's actually a blocker. They can't get into agentic development because the systems are just too reliable. All these agents are just too unreliable uh to uh sorry let me

6:38 sort of save for some people uh they just can't get into agentic development today at all uh because of this blocker the the systems and these agents are just too unreliable to use them in a professional setting and so 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. Super interesting. I I mean for me personally I I guess two of the pains which which really spring to mind for me is I I start coding with agents and you feel that magic. You feel that kind of like 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 almost like this certain size where it has an amount of functionality and capability, there's almost like you hit this ceiling whereby exactly what you kind of like referred to where I change one bit and a whole bunch of other things change even if I've actually 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

7:38 from the from the original conversation um and so forth. it it makes it almost like you can't continue with the agent because it's it's it becomes more work to kind of keep it on on track and that becomes that becomes a huge huge pain. the the other the other problem that I have is sometimes you get to this stage where you actually have to almost give up and you have to say almost like I have to start again it it's got itself in such a knot I can't continue down this path and it's the these are the limitations of the of the vibe coding way which actually uh almost like a blocker from going into that kind of more into that actual enterprise-like production style level of of reliable code. So, so yeah, I think these are like super important and common pain points that that both we and most of the world who have been using AI have suffered and and and feel day-to-day basis. What are the two products then that uh that that we're releasing?

8:31 Uh so two products both very exciting.

The Tessl Framework captures intent in specs before coding

8:34 Um the first one is the Tesla framework and that is really a specri development framework that connects to your agent via MCP. So we support all the agents that support it. Uh and guides it to uh capture its intent in specs before it builds, right? So you come along and you give it an instruction, whatever, build me a uh to-do app or whatever it is. Uh and before it jumps into code, it first creates a spec thanks to using Tesla's tools and thanks to Tesla's guidance to say what is it that it wants to build in a quick and easy to understand format and then it goes off to build it. And have you had a case where you ran along or you gave an instruction and the agent rushed and they ended up building the wrong thing?

9:16 It's it's not just daily, maybe hourly when I when I when I use agents. Um, and it's it's I guess a twofold thing. One where I either give it an instruction and it hasn't quite understood exactly what I meant. And it's because I love to short prompt because I get, you know, value and speed out of short prompting. Uh the other of course is where I you know I ask it for a small a small change in a larger app and it actually then goes ahead and starts changing other pieces expands it of the

9:41 oh gosh it's frustrating. So, so that's the sort of the first goal is separate intent from implementation and capture what it means to build in a spec and then once you are comfortable with you know the the intent and with what has been built and you're happy with it uh then Tesla offers you an easy way to now generate tests uh with sort of a single command uh and this is done because the spec is actually designed up front to be built with a lot of test cases in mind that serve as examples when you initially generate Right? But then those uh are are sort of 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. Needs to set up a test environment sometimes iterate uh but it does it quite autonomously and once it works those serve as regression tests and so now you know that it would not do as you mentioned before you know you you make a change then goes off and it breaks something else.

10:37 Yeah. Yeah. And and that kind of like leads into whether you prefer to do a test-driven tests up front 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. And 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 uh with that same uh centricity over the specification.

2 Highlight · Supporting both spec-first and vibe-coding workflows

11:04 Yeah. Exactly. And there's no we we we we went a lot of back and forth on like do we 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 uh what you mean to build that your intent is well captured that the test cases represent what you want etc. And you're willing to invest that time because you have enough opinions and it's important enough or maybe unique enough. it's rules of some new game or whatever it may be. And so then you want to invest that time and and the Tesla framework supports that and it's very easy and natural to do it. And then once you have defined those you sort of send the agent off to build and you have those guardrails so the agent can work more autonomously until it gets it right. But the other mode uh that we've started calling vibesing is also legit, right? As we've heard Ollie from uh Data Dog, the CEO and founder of Data Dog tell us in a previous episode, you know, the the biggest lie that customers tell you is that if it's important, they'll

12:05 invest the time. And in practice, what we see on ourselves and on our users is that often times people just want to get to working code as quickly as possible. And so uh this vibespecking mode is one in which you indeed you you don't create the test up front. You don't really know what it is that you want. So you just flow with it. You allow the agent to make the decisions as you did before. You're just now capturing those decisions in these different documents.

12:30 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.

12:43 Yeah. And ultimately you get the same thing at the end of the day. You have your code, you have those tests that that make sure that the code that's generated satisfies the specification and the specification really importantly still holds all the intents. Uh whether

12:58 you go tests first, whether you go tests after, it's it's not opinionated in in in such a way.

13:02 Exactly. you actually you you can now continue and you have something you actually didn't have before in software development as a whole which is you now have this long-term memory as the specs get committed to your codebase of what your product should do uh which we actually don't really have in software development today. We have you know docs or or such but because they are not the source they're not the the the file through which changes get applied then they often times fall out of date as we all know.

13:29 Not that not that dusty PRD down in the basement you're talking about. Exactly. It's not these sort of fragmented requirements nor even sort of user docs. And so you have you have these specs and the specs capture your intent over time. Uh and you can keep coming back to them. And it's an easy way to manage tests and relate them to the product. And so the the true maybe biggest value of the Tesla framework actually comes as you continue building and continue evolving because you have these specs as part of your codebase and defining what your product should do. What the framework also does is it helps you ensure again with 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 Tessle edit tool and that modifies the spec first and then modifies the code. And when the agent uh 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

14:31 always keep the specs up to date and to ensure that changes get applied through the specs really allowing you to sort of scale and grow. And we think that the 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, you know, adaptable to change something from, you know, a Python environment to a TypeScript to a Java uh and uh and not need to worry that your functionality breaks in the process. So, a lot of value upfront as you create. Uh but really probably the biggest treasure trove is uh as you as you grow.

15:13 Yeah. And these specs really build up to the life cycle of the of the application, right? They just stay with the with the test with the code all the way through and continually you as a user are focusing more on the specification than than anything else.

15:26 And that's a very important clarification because I think in the industry today we use specs for various purposes. I think uh in the sort of naent agentic dev world and for many people specs are uh about a transition from point A to point B from state A to state B uh we that's not how we think of specs we do create plans as a natural part of the uh of the Tesla usage and those plans are indeed their life cycle or lifespan is the the the lifespan of the change but the specs are really about the definitive document that describes functionality and their lifespan is the lif of your codebase.

16:02 Yeah. Amazing. So, product one, the Tesla framework, the ability to to to

The Tessl Spec Registry prevents library hallucinations

16:08 create uh using a a a specd driven approach, spec driven development approach. Um you mentioned about agents being being a little bit uh a little bit dodgy, a little bit a little bit wary. Tell us a little bit about product two and how that kind of like helps keeps keep these agents in the rails.

16:26 Uh sure. So the second product which I'm very excited about is the Tesla spec registry. Going back a little bit to the pain point, I think what you see with agents is uh sometimes they don't know something and they don't know they don't know uh or the story of my life. I'm basically an agent.

16:42 They're kind of uh they're kind of overconfident. You know, I'm not I'm going to let that slide.

16:46 I feel seen now.

16:48 So the most evident version of that is when they use an API, a third party API or or an open source library API. uh if you're using something that is like straight up in the mainstream then they know they're amazing at it. If you're using something that's a little bit off or using a slightly older version of a popular library or even more if you're using a new version that didn't exist yet when those models were trained uh typically what the agents would do is they would just make it up as they go and they would use you know false APIs or flawed one and sometimes they would just really get stuck in that mode and they would just sort of waste time and money trying to get there and never get out of it and sometimes they would eventually figure it out but it was you know timeconuming costly And they often times are left with a slightly messy implementation. And have you experienced things like that?

17:34 So much. So much. And it's particularly because you know AI is great at when it looks at its when it you know trains on on a huge amount of of open source libraries with tons of different versions on there. when things and I'm talking about the Java world here, but when things progress over years and years and years and years, there are so many API changes from different libraries whereby the most popular is really the one it's going to be trained on. And I'm not always using the most popular because I sometimes run on an old stack or I'm sometimes bleeding edge with some of the things I'm using. And it's not just as much a hallucination as it is a I'm assuming this is the version you're running on without actually using the correct context to build against uh when and generating my app. huge problem.

18:16 Precisely. And so we This is really a kind of a context problem, right? They don't 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 sort of a a less statistically significant bit of information. Uh and sometimes it's indeed information there's no way for them to have like your team's specific best practices or context. Um and so what we believe and

3 Highlight · The spec registry functions as a knowledge dependency system

18:40 enable with the spec registry is to make that knowledge a part of your project. Um so we introduce a new dependency system that the spec registry enables that is a dependency system for knowledge for specs. Uh you would have a 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 codebase. More specifically for open source, we have pre-populated uh the registry with over 10,000 usage specs which are uh pre like we generated them by analyzing the code of specific versions of libraries uh and additional information about those libraries of you know usage online that is all version aware and we package them up in these easy to consume kind of nuggets of knowledge for the agent. So these are markdown files 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's say you're using some library at you know version old then the agent will

19:43 uh you you will add that you would use Tesla registry search to find uh the usage spec you will it will be added to your manifest file and those usage specs will be downloaded to your uh your project just like node modules or other dependencies uh and then using tesla 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 uh uh correct for your specific project. It is uh um kind of always available to all the agents. You're not dependent on them

20:15 realizing they need to go seek it out or misunderstanding it. Uh and as your software stack changes or as your practices change, so does the information that you make available to the agents. And and it's important to hear to raise that distinction between the spec that you kind of like referred to earlier where we're creating a specification using the Tesla framework and that specification allows agents to create code. It's effectively a blueprint of this is how I want you to build my application. The usage spec that you're referring to is quite different. It's telling the agent how I should use these various libraries or components so I can code against them.

20:52 It kind of reminds me, I don't know how well this will travel to our listeners, but uh the Hannes manual for cars. It's like the the book that that kind of like tells you every little bit about how a component works in a car. It's great to understand how every single component could work and can work, but it doesn't necessarily tell you how to drive the car. I wouldn't look at that in order for me to, you know, be able to to use a car correctly. That's 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.

21:25 It doesn't actually tell me how I should use it, examples, best practices. That's a key distinction which usage specs here give us.

21:32 Uh correct. And I think we talk a lot about what is uh what what should be in the spec. And specs can hold many things. and we find ourselves now defining a type a functional spec versus a usage spec eventually when we think about spec driven development and spec driven specentric software. Um then we oftenimes all of these will be part of the software package itself because um you know when you are creating a library you the information that you need to be able to uh uh regenerate that library again again for instance that might be more of a functional spec might be a bit more technical but uh understanding that library both for the consumer and for future developers actually starts looking a lot more like a user spec. Uh so at the moment we are you know not there isn't much software out there that is uh that is defined by specs and so we are creating these kind of docs for agents you know for software that has been built in a code-centric fashion and we make it accessible in a very kind of agent uh friendly way right with a good

22:33 ax um so that they can consume it and make it a part of that project you know a dependency system for knowledge uh and again we we've kind of spent some inference dollars so you don't have to uh to make this information available to you so you can install it now and just make it you know make your agents use open source better. Uh but we think conceptually uh there's there's more information that needs to be made available to agents than just usage specs. 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?

23:10 Which logger should I use? Like all of those might be things that the agent can intuitit or make up, but what it would make up is going to be inconsistent and often times incorrect. So you need to get the right information to it and you're right and you want this information to always be available for this project and you want it to be cross agent as your team changes and moves uh agents over time. So right now use it to make your agents use open source better

Registry in open beta while framework uses throttled rollout

23:38 and over time start thinking about what would you publish into this registry and what else would you like to find there to consume. So the Tesla framework, the Tesla's spec registry guy, shut up and take my money. I can use all of this today right now, right? If I go to Tesla.io.

23:56 Uh so almost almost. So the Tesla spec registry is now available in open beta. So you can go to tesl.io and with a couple of clicks, you can get it installed and integrated on your uh on your agent environment and start using it right away. uh and would love for you to try that and to send us feedback uh to build it up. The Tesla framework uh is still released in a controlled beta. So you can find Yeah.

24:21 Why why so the development framework has a lot of moving parts and there are many many many ways that you can use it. Uh and uh 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 just evolve the on boarding experience, the right guard rails, the right learnings so that not everybody sort of shaves on the same practice. 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. Uh, and we we intend to give many people access as we learn, but we're just going to throttle that or sort of 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

25:21 we'll take your money.

25:22 Awesome. So, uh, right now if you go to Tesla, you can have access to the to the, uh, to the spec registry. Tesla spec registry open. um the the Tesla framework uh is being opened up to many more people on a throttled uh beta and you can sign up uh to the waiting list correct for that. One of the interesting things which kind of like me and the team are doing here at Tesla as well is we're opening up we're not we know we're not trying to keep everything hidden.

25:50 We're opening up much much more of of our docs so you can see how you can use the Tesla framework even if you don't have access today. There's a bunch of videos on Teslio to be able to see uh Tesla, the Tesla framework in action and so you can see exactly what what we're talking about here. And in fact going forward uh why don't I bring Macy on again? Do you remember Macy Baker for those who who watching a few episodes

26:13 definitely want her on the show much more than me.

26:15 Let's get let's get some demos going and we'll show we'll show you the framework in action as well. This is a part of what makes today special for us is this big unveiling. There's been there are many thoughts you know like a long process to get to to the situation. So we're happy to build in public uh even as we slightly slightly control access to uh to to just sort of help it all go smoothly.

26:37 Yeah. And the best way to build in public of course is to is to get user and community feedback. Uh the best way to do that join us on Discord. Links will be links will be in the in the show notes. Uh our Discord server. Um there's there's Tesla channels couple of Tesla channels now in the in the AI native uh dev community. So join that tell us what you're using there and you'll be uh joined uh to the correct roles and the correct channels where you can discuss both about the spec registry as well as uh the Tesla framework.

27:03 Yeah. And indeed we're we're seeking a lot of feedback and there's a chance that if you're uh a valuable feedback provider even if it's critical feedback on it maybe you you also get bumped up the weight list for the uh

27:14 popularity contest. I see. I see.

27:16 It's a usefulness.

27:17 It's a a usefulness contest. Excellent. Um, so yeah, you talked about, you know, the the story a little bit about what we've what we've been through. Tesla's

Pivoting from closed web platforms to open CLI tools

27:26 obviously, you know, not not a a fresh uh company. It's it's been around for over a year now. I remember the the the episode that we did with 125 mil of funding and things like that. It's an it's a it's an established company. Tell us a little bit about the journey uh that that Tesla has been through to to get to this point to where we are today. So first of all I think the company is over almost a year and a half old uh and uh consistently we have believed that specentric software is the future uh and and many of the core concepts of how we imagined spec centric software or sort of specdriven development uh to to look like are actually the same surprisingly the same uh but we also knew that we're anchored in the future and that the LLMs can't quite do it uh today. And so we went through sort of I'd say maybe a couple of chapters over almost a year.

28:20 Uh at first it's kind of the navy uh phase. And so we you know we could imagine it and so we said fine let's build a specri development uh platform that allows you to create in the sort of uh uh webish environment software through specs. H and we really were very uh very bullish in what can we do in a period of time. uh and that took maybe 6 months to get a better appreciation of the uh level of capability of LLMs at the time and uh and understand that there's still a bit of a journey to be able to deliver. we were to deliver that and so we were left with with a lot of ideas about what's the correct destination uh but it was just a bit too much and then we switched to a more kind of controlled environment in which you could create software components uh through a very controlled web-based development path uh and we indeed managed to build something that matches

29:21 the capabilities of the LLM so you could create software libraries with Tessle in a spec driven fashion in a next next experience and users were were quite interested in that but it was it was too narrow and too big a change

29:35 opinionated as well. I remember when we were building that it took us through a number of stages as well where 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 blah blah blah and and you know we went through a number of changes even there just working out if it's linear do users want to jump through stages it it's a complex thing

29:56 part of the reason that we went through that is because the elements were just not good enough and so uh we we needed to kind of hold their hand and be very specific but eventually the product we ended ended up with was was not worth the the leap. You know, it was too

4 Highlight · Pivoting from closed web tools to open CLI workflows

30:10 narrow to and too different. And so, you couldn't really develop software in this fashion. And so in the last chapter, which is, you know, the one that I feel like we've we've uh hit the mark, first of all, we said, hey, we can't we need to abandon the sort of closed web- based controlled environment and embrace the the roots of local uh file-based, you know, very open and tinkerable uh development environment and the CLI. And then uh agents came along and I think agents were key for in two ways. Uh you know, in part is because of the capability. So they they unlock an ability for AI to generate a lot more and we have been building basically a a version of an agent in the previous iterations of it. Uh 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. But more importantly it it uh surfaced uh an immediate version of the pain that we're addressing. Uh and so we from the beginning said the pain we're addressing is is this sort of big pain of software development. You develop

31:12 software and over time you forget why what the software is meant to do and you're just left with the code uh and then over years that problem uh manifests and software becomes fragile because you forget what it was. agents is like a microcosmos of that, right? You they're they've got amnesia, right? You sort of you tell them uh you tell them to do something today and the next day they forget it. They don't remember it anymore. Uh you nobody has knowledge of the code, you know, because they've written it and so nobody understands the code or any meaning to uh that is within it. And you're you're really face first uh with the problem that the code just doesn't have enough information. Um and then they they have all these other symptoms that are like in software development. Sometimes they misunderstand you just like developers might uh but they just it's a faster

32:00 iteration and therefore they build the wrong thing you know and that fixing problems after the fact is harder. And a great developer today you come and you tell them hey I need this change in the system they will stop and say okay what's what's the product impact what are the use cases that you're trying to satisfy so I can prioritize my work accordingly. Uh and so to an extent that's what we're doing to the agents. we're trying to make them do that. So I I think it is very kind of invigorating and it's like it just feels a lot better to say okay we we are we remain true to this vision of spectriven development 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. Uh and so I think this is the chapter that we're in and I I've sort of been saying like we knew the destination but uh now we found the trail head you know we we were sort of wondering this path and saying okay fine but where does the path start and now we

Embracing team adaptability and community feedback

32:58 find the trail head uh and now we run

33:00 I think it's amazing how this is the first time I personally have joined you or anyone on a journey so early in in in a startup stage and I think one thing that I I think is is is quite quite amazing is how startups can so quickly pivot and say, "Look, this isn't the way. This is the way. This isn't the way. This is the way." And and recognize that based on the on the changes that have happened in the industry, and of course, AI, nothing's been nothing's changed the industry so much as as AI in in in as many months. But um but yeah, it it's it's that bravery and courage to be able to say actually look, this is the change here. We're not going to continue on this path. The way in which we tackle them. the way in which our users are using technology today changes our approach and the change the the the the path changes quite significantly. It does. And that's actually also probably the the 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 uh uh 37 people I think now.

34:02 And you know it's a lot of people they've they've written a lot of code which they've subsequently deleted. Uh sometimes because we've shifted and we're in this chapter. sometimes because uh new evolutions with LLMs have kind of rendered it unnecessary. Um and and those are that that's not easy. You know, it's easy to get attached to the thing that you're building. It's easy to uh to sort of stick to to a path. What do you mean? You know, like I I've built this and I'm I'm kind of passionate about this creation that I have. Uh 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. In fact, probably the biggest complaint, you know, 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, uh, but not in vast quantities as we're sort of exploring the way. Uh and so everybody is very keen to doing it but super proud of the team for for for being willing to sort of you know throw away you know past work if it is not the right path forward

35:03 for being kind of uh no ego uh and aligning with the group because we're again we're sort of a larger group now uh and coming along as we as we make changes in the sort of nebulous potential paths uh and I guess most immediately and rallying towards uh this launch like a lot of work got done uh over the last few weeks and I I think now we we get the best opportunity of letting the team shine which is engaging with users, responding to uh to problems and continuing to build with sort of the speed that we have here.

35:35 Yeah, it's amazing and of course that whole team is ready to now engage and chat much more publicly than ever before on on on the Discord. So

35:46 this pretty much wraps it up. extremely exciting news and amazing uh to be able to share this with with the broader audience. And Guy, you'll be on Discord just as everyone will.

35:56 I'll I'll be on Discord. I'm probably not the sort of the smartest person for you to sort of engage with to sort of solve problems there, but if you want some sort of philosophical ramble, I'll be there. I'll be there. Uh yeah, and we do look forward to having all of you join us on the Discord and engage in this in this journey. Again, we're not claiming to have solved spec driven development. Uh we understand these things take iteration. Uh, and we're here to iterate and fix problems that you encounter, hear needs that you have that we've not yet solved. And so very very keen for you to to try it out, you know, both the uh 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 kind of concepts of this journey available.

36:38 Absolutely. So tesla.io uh you can use the spec registry right now. Tell us what you think on Discord and of course sign up for the Tesla framework. um uh throttle beater uh 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.

36:56 Indeed. Indeed. Exciting time. Thank you, Simon. And uh yeah, now the fun part begins.

37:02 Thanks for listening and tune in to the next episode.