From Idea to Production with AI

Added: 2026-05-09

[00:00:16]Hello everyone. Um, just before we get started, if you can hear me clearly and see everything and everything looks great. Um, would you just mind popping a comment in the chat? Um, just so I know and then we will get started.

[00:00:45]Great. Thank you. I can see a couple coming in.

[00:00:49]Great.

[00:00:51]Amazing. Thank you so much. Um, okay.

[00:00:53]So, I'm just going to go. Brilliant. I'm just going to go ahead and share my screen and um I'll talk a little bit about what we're doing today and then we will get started.

[00:01:04]And so if you just give me a second, just see what I can do here.

[00:01:12]And there we go. Great.

[00:01:16]Okay. So, welcome to today's workshop.

[00:01:19]We are going to be talking about specdriven development, which in this workshop, we talk about going from a vague idea. So something that you, you know, either have planned out previously or you just have an idea in your head all the way to a fully built product.

[00:01:36]Um, and we're specifically going to talk about opensp spec. There are lots of different options for this. We'll get to this, but the goal is to stop prompting your way to building things like prompting, fixing, prompting, fixing, and and so on. So we'll go through all of that as we go. Uh, so a really quick introduction. My name's Alex. Uh I'm a technical education lead at Bitterbrains. We are currently building um unlearn.dev which you've probably seen from the notes for today's workshop. And this our goal for unlearn is uh we you know we know that developer education is changing. We know that we don't go and write much code ourselves anymore. Um but we also realize that AI is can be pretty hard. Workflows can be pretty hard. Getting teams on board can be pretty hard. So, we built Unlearn to solve this problem. Um, and this isn't just a platform for a bunch of AI courses. There are tons of them already.

[00:02:32]We're building something different here.

[00:02:34]We're building a hub for developers because we know that while AI is, um, you know, at the forefront of everything right now, it might not be in the future. So, um, I'll leave you to go ahead and watch the video here. You can see I'm here as well. Um, and just have a look around. Um, and we would love to see you there. So, please feel free uh to go ahead and check it out, have a look at what we offer on here and uh sign up if you think it's going to be helpful for you, but we're really excited about it. So, um yeah, I my name is Alex. I'm technical education lead at Bitterrains. I've been teaching over on Unlearn. Um please go ahead and follow me on X if you want to. If you have any questions after the workshop, we're going to do a we're going to do a Q&A if we get time. Sort of do them as we go.

[00:03:18]I'm going to keep an eye on in the chat.

[00:03:20]Um, but if you have anything at all that you need, please go ahead and give me a shout. Okay, let's uh have a quick look through the agenda. So, first of all, we're going to talk about why spec driven development matters. Then we're going to go into a practical where I'm going to create and refine a spec live for a product. And then we're going to go ahead into the uh take the spec and basically turn it into code. That's the apply phase. And we'll talk a little bit about guard rails as well, how we monitor um our AI agent as it starts to build a product or a feature and how we tweak it as we go. Um and um then as we sort of go through that, you'll have a really good idea as to how to use OpenSpec if you haven't already used this. And then you can go into the hands-on activity which will be basically taking any of your existing products that you have on your machine using OpenSpec to add a feature or make a tweak or you know fix something and then build it and review it. And then we'll have another Q&A at the end um just after we wrap up. So if you have any questions about the process, what went wrong, what you don't understand, then I'm going to try my best to answer as much as I possibly can. So let's go and start at the very beginning.

[00:04:38]And the most important part about this is why this matters. So um what have I done there? Okay. So without a spec, which is you know the majority of the time, I'm not going to lie, I will just go in and prompt my agent to do something. What happens? Well, we have requirements that live either in our head or in a document somewhere that's separated from our code base and separate from our team or in scrollback.

[00:05:02]So, if you're working on uh a really large feature or if you're scaffolding a project, you probably scrolled back through your terminal before to sort of figure out what's going on and you know things just tend to get a little bit messy. And another thing is that every prompt kind of feels like a fresh start.

[00:05:18]Yes, we build up context as we go through our um you know as we sort of start a session whether it's clawed code, codeex, whatever and you build up that context. Yes. But then what happens the next day when you've exited out? We all know the feeling about agent then jumping in and trying to figure out what the code does and what we have and haven't done. Um and that's pretty frustrating. Um the other thing is that your agent doesn't really know what you want. Sometimes you don't even know what you want. So it fills the gaps with guesses. So some are great, some are really, really bad. And you only discover that this has happened um after the code is written. So without a spec, you trust your agent to build something.

[00:06:01]Yeah, you might be in plan mode, but that might not give you all of the details of what it's going to do. And then you review the code afterwards, and then you think, do you know what? I'm going to have to either go and scratch this and start again, or I'm going to have to do some serious refactoring. Um, and I think we've probably all been there. So, with a spec, what's the difference? Well, the intent of the feature that you want to build or the thing that you want to build is written down as a document, as a spec document before any a before any code runs or any code is written or anything happens with your AI agent. You have a document that you can review and look at what your agent is going to do and in a lot of detail as well. So the other great thing about a spec, and we'll touch more on this later because this is great for teams, is that you have one source of truth. You have a source of truth of what you've done previously. So like the features that you've implemented, decisions you've made, things that you've had to remove or refactor. And that goes for you, your agent, and your team. So everyone is on the same page.

[00:07:03]And the bad decisions get caught beforehand when they're cheap both in cost of tokens and time and really easy to fix as well. So, uh, if you, you know, generate out of spec doc and you see, oh, actually, no, that's a really bad decision or I don't want that package pulled in or this, you know, shouldn't shouldn't be happening in this scenario, you can just basically change a piece of text and then your agent will implement it only when you ask it to.

[00:07:28]The other thing is that the spec outlives the chat. So we'll talk specifically about opensp spec here where you once you finished a feature or once you've finished a tweak or you know refactor everything gets folded into a sort of main big spec where there's a lot of context about the decision that you've made. I've already touched on that but we'll see that in action. So the the shift that we see here when we you know change from prompting sitting down prompting over and over again until we get the result we want is we do everything up front. We agree on what we're building first then we just let our agent build it which is if done correctly and if you get used to this workflow is really really really powerful. So with that said hopefully that gives you a little bit uh of a better idea about why spectrum development is good. What we are what are we doing today? Well, we're going to build out uh a simple app. We don't have, you know, hours and hours or days.

[00:08:23]Uh which is just going to be a basic poll creator. So, we're going to um give uh or build the ability to put a question in, pop a couple of answers in, and then share a poll, and then everyone can vote on it. Um and we're going to be doing that with spec driven development specifically with OpenSpec. Although, you can take what we learn here today, and if you find a better package or a better solution for this, then you can use that as well. So specifically what's opensp spec? Well, it's a framework for specd driven development workflows with AI and it allows you to capture the change. So any change that you want, that could be a bug, a feature, a completely new project before you start to write the code. And this generally happens, I've simplified this down and we'll look at a longer version of this a little bit later. This usually happens in a three-step cycle. So first of all, we propose the change and we do that directly through our agent. We'll see this in action in a minute.

[00:09:17]um and basically just say what we want to change. Then once we're happy with the written spec um we go ahead and apply it and our agent will follow the steps, usually a checklist and it will basically just build out what you've agreed to up front. Then once we're done with that feature, we go ahead and we fold it into or we archive it into the living spec. So the next time we open up our agent and we want to start building um it already knows what we've done. I already mentioned that but it's really important that this is one of the benefits. So let's go into the first um sort of section of this workshop here.

[00:09:56]And the best way to demo this is with a vibe coded version that I built earlier.

[00:10:01]So um earlier I gave Claude code this prompt and I just hit enter on it. Let's take a look at the prompt. And you know there's nothing wrong with this. Um, and this is a really good way to just prototype. Um, but it just goes to show that this doesn't capture everything.

[00:10:16]So, build me a simple poll app. Users should be able to create a poll with a question and some options, share it, and let people vote, show the results after voting. For a poll app, I can't think of anything else that I would want to specify uh to my agent to build. Um, I also gave some light technical direction here because I already have a had a sort of scaffolded project set up. And again, this doesn't matter if you are not using Laravel or Inertia or View or Tailwind.

[00:10:44]It doesn't, you know, this is this is not language specific. Um, so this took about 4 minutes roughly. We got a working app, but it did miss some things and it actually made some really bad choices. So, let's go ahead and take a look at what it built. So, first of all, aside from looking pretty generic and very Tailwindike, um, you know, it it looks okay. So I'm going to go ahead and add in a question.

[00:11:11]Add in some options and we'll just see what it built. So let's say what agent do you use for example and let's just put a couple of options in here. So let's say claude codeex and let's add an option here. Um and actually I think I spotted a bug earlier when I click create. Nothing happens. So already it just feels very vibe coded.

[00:11:32]So I'm actually going to get rid of that and click create poll. Okay. So so far it looks good. Uh I can go ahead and click on one. I can share the poll by copying a link. Uh I can vote myself which is fine. Um but one of the questions I had after I built this was how does it know that I voted? Like what is going on here? How is this being stored or how or more importantly how does it recognize that I specifically have voted? Now, I went back and I asked my asked my agent, and you may have guessed already that it's using cookies.

[00:12:07]Now, that is not ideal for a lot of reasons, but the fact that I could just come into my uh storage tab here, go over to my cookies, and there we go. We've got quick poll session, voted token. That's I could just get rid of all of these. I could give that a refresh, and I could vote for Claude again, and that gives me two votes. So it's very very easy to manipulate this and we want to do a little bit better than this. This is like a classic vibecoded thing where it looks great but actually behind the scenes it needs a little bit more thought. Now one of the things that I like to do is use a bad build or a prototype more appropriately to find gaps in an actual product I'm going to build. You can do this with big features as well. So v coding rough version I find is a really useful technique. It allows me to see what's wrong, what's missing, and you know, helps me discover the features that I actually need. So, from this bad build, I then went ahead and thought, well, let's be a little bit more clear on this. So, we want to create a poll. We're a little bit more specific, but we don't want all. We don't want users to have to sign up. Um, we want a sharable link. We want an admin link because at the moment with the one that we have here, let's find it. There's no way to close the poll. I can't really manage it. you know, it's it just doesn't feel uh completely finished. Um and uh that's really important. So, we also obviously want voting one per browser session. We want to be able to view the results. We want to be able to close a poll. And then really importantly based on that vibe coded bad build is email verification.

[00:13:45]So, I think that's okay. You know, you could implement anything here, but I just went for email verification. This is going to send our users an an email to say please can you verify your vote and then they can go ahead and uh you know verify that a little bit later. So now that we have looked at our bad build, we want to actually go ahead and create and refine the spec. So I'm going to show you how to do this now and then you can use this to go on and do this for yourself. So let's go over to our um editor here. Well, our terminal. I'm just going to pull this in as well so we can just switch between them. And I'm going to come over to this starter app just here. So, it's just a freshly installed Laravel app. Again, don't worry if you're not used to Laravel. This isn't going to be technical in terms of Laravel. It's absolutely um uh a framework and language agnostic. So, I'm going to go ahead and run Claude. I'm going to run this with dangerously skip permissions which I wouldn't recommend you do um just so we can get through the workshop without it asking me a bunch of questions. And um yeah, what's the first thing we need to do here? Well, actually before we dive into Claude, the first thing that we need to do is within this project um we need to initialize OpenSpec. So once you've installed OpenSpec, which is, you know, all of the details are over on the uh site just here, you're going to go ahead and initialize this in your project. So you can use this for existing projects as well which we'll talk a little bit more about later. So I'm going to say open spec in it directly within this project and uh we're going to press enter to select our tools. So I'm using claude code here but you can select as many here as you want. So if m if different people on your team within your project to use a different agents that's fine.

[00:15:26]You can just install all of them. Um and that's it. We're done. We've uh initialized opensp spec. So, I might just need to exit out of Claude and go back in. And now we have a bunch of opsx slash commands or uh skills basically um that we can run. So, what these will do is basically go through the openspec workflow. Now, that sounds more complicated, but cast your mind back to what I was speaking about a minute ago where I said we've got propose, we've got apply, and we've got archive. So what we have here is propose. We have apply which will apply the changes and we have archive. We also have explore as well which is um a really great and if you've used plan mode within cloud code or any other agent this is very similar to plan mode where you might want to propose a change. So for example I could say propose and then I could say add a you know x to y whatever feature that we want to build. um that will just create the proposal. Whereas sometimes we want to do a little bit more exploration. So I'm going to go down the explore route because I'm going to show you the workflow from this point and we're going to go ahead and enter into here. So with this, let me just go ahead and grab the prompt that we had within here. Um so I'm basically taking what we found out from the bad build and um and I'm putting it into here. So I'm going to go ahead and paste this in and I'm going to show you what this looks like. So let's build a simple poll app. It should have these features. These are the features that I just showed you in the slideshow.

[00:17:05]So basically everything that we figured out earlier and then we're building this with Laravel in ash view and Tailwind.

[00:17:10]So just giving it some light technical direction. So what's going to happen at this point is it's possibly going to ask me a bunch of questions. So it will look through what I've given it. Remember this is a totally blank app. There's nothing to currently build on. And it will start to ask me some questions. So yeah, you can see here already before formalizing there are a few tensions in the spec I want to surface. So of course, you know, my uh explanation of this probably wasn't good enough. So we've got uh tension one cookie vote versus email verified vote. Now what I kind of want is a cookie yes to show that that user has voted, but then I also want to send an email to actually verify that. So we want something to show that the user's voted without having or but we also want that um that verification. So, let's have a look here. We've got a couple of options. So, the instinct that it's come up with is D. Um, so require email verification.

[00:18:01]Yes. Now, I'm just going to explain to, you know, I'm not going to read through all this because we don't have huge amount of time. Uh, let's look at tension two. So, we've got when does the vote actually get cast in the email flow. I want this to be after they've verified this in the email. Um, although that's up to you. Um, results fillable after after posting. What about closed polls? So, um, we we'd want them to be shown admin link is a capability URL.

[00:18:27]So, yeah, and, uh, Tension 5 hashed email per poll. That's fine. Okay, let's just go through and start to answer these questions. And this is what I really like about this. It's really thinking about the data I've given. It's filling in the gaps for us. Not always because we still need to review the spec afterwards, but most of the time. So for one I'm going to say cookie to show user has voted but email off to verify. Let's just take a look at point two here. Uh when does it get cast? So after email is verified.

[00:19:05]Three. Let's just take a look at this.

[00:19:07]Results visible after. Yes. So yes visible after poll closed.

[00:19:14]And let's just take a look here. here.

[00:19:16]Admin link is a capability URL.

[00:19:19]Um, yeah, this is fine. It just means if we lose the link, then we don't get access to the admin panel. But of course, you could work through that in your own spec. Hash email per poll uh prevents duplicate. And let's have a look here.

[00:19:36]So, let's just say you decide whatever is uh easier for now. Okay. So, I'm going to go ahead and answer them questions.

[00:19:46]Remember, we're still in explore mode here, so nothing concrete has been generated yet. We'll take a look at that in a minute, and then we'll talk about sort of what's been created where and what we should do with this information.

[00:19:57]Um, but yeah, this is this is um just working away. Now, just while that's working, uh one of the things that we want to make sure that we've got set up in any project anyway, and we cover this a huge amount on on learn, is any kind of guard rails. So the guardrails that I've set up in this project are just a really basic set of preferences inside my agents.mmd file. These are the kinds of things that steer your agent generally and these will be baked into opensp spec as well. And also just while our opensp spec uh spec is working through you'll also notice when you initialize a new opensp spec project you'll get an opensp spec directory which is um which will contain all of your changes. is. Now, we don't have anything in there at the moment, but let's hop back over to uh Ghosty and have a look. Okay, great. So, this has, you know, this isn't going to be perfect because I'm I'm not going to spend like an hour on camera reading through and and doing everything. But now, we want to go ahead and actually propose this.

[00:20:56]We want a concrete proposal that we can review, tweak, and then build. So, very very simple. We just go ahead and we use opsx propose. If you wanted to change anything about this spec at this point, just write it in here. There's no specific command that you need to use.

[00:21:12]You could just say, can we change X, you know, Y, whatever you needed to do. But in our case, we are going to, let's just get rid of that. We're going to use opsx uh bring that in propose. And that's going to create that proposal for us. And we'll see that in our editor as well.

[00:21:30]So, uh, yeah, let's just wait for this to go through. Um, if you've got any questions at these points while we're waiting, please feel free to just pop them in the chat. Uh, and I'll do my best to answer them while we're going through cuz might be a little bit of waiting around for this. It's always the the case with agents. Um, uh, let's actually take a look as well at the OpenSpec config. So, the OpenSpec config lives within this OpenSpec directory. By the way, and we'll talk about this more later, you do want to commit this openspec directory to your source control. Why? Because of course, every member of your team will have all of the prior changes that have been made. Um, this is your living spec that lives alongside of your codebase and matches up with what you know the state of your codebase, the decisions you've made, and this is what makes it, in my opinion, incredibly powerful. So, you've got a config file here for um, OpenSpec, which you can go ahead and fill in. So you can fill in stuff like your text stack, uh the domain that you're working under, per artifact rules. So for proposals, you might want to keep these really short. You might want to always include specifics. You can tweak this as you get used to it. Personally, I would just start out by using it without the config and then go ahead and, you know, if you love openspec or if you have another framework that you prefer, go ahead and make use of this. And this I found on larger projects where or projects that are more mature, you can actually get rid of your agents.mmd file because you're working with your spec only and you're using your spec. Every time you create a feature or change something, it will be read from this uh config file.

[00:23:04]Okay. So, um our agent is working away here. So, it is creating a proposal which we can have a look at because that's done. It's creating a design document. is creating a spec uh a a a poll spec and a task list which is my favorite. So let's go and just open up the proposal and you can see here it's basically just everything that we have discussed uh when we proposed this but written now as developers yeah me personally I don't like reading specs I never have I'm more like let's just get into the code but we know that with AI that's sort of changed you know our roles have changed from writing code to figuring out how to steer an agent and that does involve reading through specs X. Uh, one of the things that I do do, and this is available in most editors, is I use the Let's just find it here. It might be gone again. This happened the last time I did the workshop. Let me just pull up um my plugins here, cuz this is super helpful. Uh, spec. So, I'm just going to go ahead and update this and apply here.

[00:24:13]And let's see if that's come back into here. And yeah, open spec. So this is a plugin that you can use for it's available for VS Code, PHP Storm, and this will basically just turn your spec into like a website that you can just click through and view. So you can see here we've got changes. We've got this add pole core the core functionality.

[00:24:35]We've got the proposal in here. We've got the design document which has just come through. Uh we've got the specs in here. We've got the list of tasks which haven't uh been created yet. But you can uh you know it's a little bit nicer to read through in this kind of format. Um and of course that there are probably external tools that would render this out for you as well. So it makes reading specs a little bit more enjoyable. Okay.

[00:24:59]So, we're still waiting for this to finish. Um, I'll just go ahead and jump in and check if there are any questions.

[00:25:06]Um, while we wait for that, so I'll just pull that up real quick. Um, really good question here. What's the difference between using openspec and just entering plan mode? Really good point. And I still use plan mode for smaller tasks.

[00:25:20]The difference between openspec, we'll learn more about this as we go on, but this will create, like I said, a living document. Plan mode doesn't. Plan mode's great because it allows us to read through a plan before we agree to it, which is what we're doing here. But with OpenSpec, this allows us to keep a history of what we did. With plan mode, we don't have that unless we manually take the um the the output of plan mode and we put it into a document and then we structure it in a certain way. Think of OpenSpec as a framework around that that just basically makes it easier for you to do that. what I would uh or what I used to do is I used to take plan mode, build something out, ask it for a list of tasks, and then I would convert that into a checklist. Um, and I still do that sometimes depending on what task I'm working on. If I'm working through a list of bugs, I'll still do that. Um, and we built a skill for that on Unlearn. It's available on the uh Unlearn uh workflows um inside. And um that skill basically turns any output into a checklist. So then I can go through, but we're basically doing what opensp spec does. So you can still use plan mode, but that's the main difference. And there are there are other benefits of OpenSpec as well, which uh is a very very powerful tool.

[00:26:29]We won't have time to go into today. Um Oh, sorry. Yeah, I've just seen the uh the um away from my video. Why does this do this? Let's just I'm going to see if I can move it. That might make it too small. Okay, I'll try and uh I'll try and keep it out the way of my face.

[00:26:46]Okay, so um this is finished now, which is great. So, um, we can see all of the documents in here. So, we've got the specs just inside of here for this. Uh, we'll ignore this for now because we've got proposal. We've got the design document, which is a more sort of technical, you know, it's called design, but it doesn't just apply to UI. Uh, it's like the technical stuff as well.

[00:27:07]So, we've got all of this stuff in here and we've got a list of tasks as well.

[00:27:11]Now, at this stage, you might be thinking, you know, once we've read through this, what if we need to make a change? what if, you know, I don't agree with, you know, a piece of information in here. I would honestly not go in and and uh manually change this. I would always use the agent to change this. So, um just as an example, I've got another sort of snippet of a prompt over here.

[00:27:34]What I really want to do, and you know, at this stage, depending on, you know, who you're working with, you might have a design all ready to go. You might have some wire frames. In which case, what you could do is just drag them into your terminal. If you're using clawed code, you'll know that accepts images just being dragged in or pasted in. And you could just use that to build out what what your spec gives. For me, I'm just going to do like a really quick could we adjust the UI design. We want modern, clean, monotone, minimalist design. Um, just so it doesn't create like a basic Tailwind thing. And again, there's no special command for this. I'm just, you know, talking to my agent as I normally would, but it knows that we're in the context of working with OpenSpec.

[00:28:20]OpenSpec will pick this up and it will update the documents. Um, so this will update probably the design document, maybe a little bit of the proposal, but I would always back to what happens if we want to modify any of this. I would always use my agent. The reason being is that on tasks, which we're going to look at in a second, proposal and design, these things interlink. So, what you don't want to do is update it in one place and it just will be out of sync in another place. That's going to cause confusion within your agent and it's not going to work. Over to my favorite part, tasks. Now, look at this. We have a very specific technical broken up into sections marked down checklist of tasks that the agent should do. Basically, this is uh you know like the guide for the agent to implement. So, we've got uh API resources, controllers, mail, front end, and all that kind of stuff. The great thing about checklists general generally with AI agents is we can pause and we can resume for multiple reasons.

[00:29:21]We might need to step away, you know, it might be time to finish work. It might be uh we might just need to leave it and then pick it up the next day. uh or really importantly we might spot it going in a slightly incorrect direction or we might see a technical decision we don't quite agree with in which case we can pause the build we can go ahead and update our agents MD we can tweak our linting rules static analysis whatever you need to do and then you can go ahead and resume the build so we're going to start the um you know I haven't looked through this proposal because we won't have time and it would be really boring for me to sit and do this on camera um but uh once this is finished updating all of the documents. You can see it's updating tasks here now. It's updated the design document uh and part of the proposal as well. Um so once this is finished, we're going to go ahead and apply the change. I'll jump in if there are any more questions. Um and then we might go for a sort of little break while it builds depending on how long it is going to take. Um so yeah, let's just wait for this to finish. See there's quite a lot updated just from that small change. And again, we would review this every single time. Wait for that to go through. Okay, great. Looks like it is done. Perfect. So, the artifacts, the proposal, the design, and the check uh the tasks have been updated, which is great. So, now is the time to go ahead and apply it when we are ready. Okay, let's just hop back over to my slideshow just to make sure that we are good here. Um, and we're going to talk about from spec to code. Um, so this is the phase where we're happy with the spec and we're ready to go ahead and start to actually turn this into code.

[00:31:07]Now bear in mind what we're building today is from zero to one. We're going from absolutely nothing or a very basic scaffolded project all the way up to a working prototype, which is not something that you would do every day.

[00:31:19]Um, so this could apply to either what we're doing today or it could apply to small features. it really doesn't matter.

[00:31:27]So the apply phase which we've already touched on looks like this. We run opsx apply that will read the change and it will implement it task by task. We've already seen that tasks nd file um the proposal the design it will work through each task. It will write the code and it will check it off as we go. So we can actually see physically see the progress that it's been making. So, one tip which I I basically add to the slideshow because I always forget before you're ready to go ahead and implement clear out your context. The reason being is that as you are talking about the changes that you want to make within this context well within the context of this session, you basically are polluting it with lots of information.

[00:32:12]Whereas what you really want and you know you want the power of the spec. You want to clear this out completely or as I tend to do I don't really trust it. I just exit out and rerun it. Um we want to do that so we start fresh and it will only then read from the spec and it won't um assume anything or make any mistakes based on what we've been chatting about uh to Claude or really with open uh open spec. Okay. So pausing and resuming. So to pause if you notice something is going wrong or you need to take a break or you know you um or anything happens, you just stop the agent. That's all you need to do. You just close your agent off. Um and your progress is already saved in tasks. Now don't worry too much if you're sort of mid task and it's written a single line of code for one task. Your agent will figure it out most of the time. So to resume you just rerun opsx apply.

[00:33:05]Simple, you know, it's not um it's not uh complicated. Did you just pause, stop, and then rerun apply? And it will pick up from the last task that you worked on. And that applies to the session you're in and of course overnight or the next week or if you're handing it over to a team member because of course remember we're committing that OpenSpec directory. So that means that your team member could technically pick up a feature mid build if if you you couldn't finish it off. And really importantly is guardrails midbu because when I'm building things I tend to sit and watch what it's doing and I like to monitor it as I go. Um and that sounds really weird to say because you know we've gone from writing code to going oh well I really want to just let my agent do it and you know I want to go and get a coffee or I want to go on a walk but I like to sit and watch it just to make sure it's heading in the right direction so I don't waste time later. So, pause it, update agents.mnd, update any of the other guard rails or, you know, whatever you need to do. So, for examples, linting rules, testing requirements, you might specifically uh want to include some tests or you might want to update it so it runs the test suite for every task. Uh, naming conventions you might spot are wrong, so you might want to go in and tweak them. Uh, you might spot forbidden patterns, dependency rules, pretty much anything um, you know, that you that you notice is wrong. And remember, this stuff compounds. Every decision that you make within your specs or, you know, even your agents.m MD file will compound over time and and these will just get easier to do. Okay, so let's go and actually apply this. Now, this is where it takes a little bit of time, so we might take a little bit of a break. I've also got a pre-built version that I did earlier just in case things go really wrong. So, we already know we're just going to run opsx apply. and we've cleared out our context, but we've already got all of this stuff in here, so it should know exactly what to do.

[00:34:58]So, let's just sit with this for a minute. Um, and we'll see it start to pick up. So, you can see one active change. Now, that's really important because you can have multiple active changes as well if you want. Um, so it's using that. It's going ahead and reading the context files, which are the context files that we have within OpenSpec to understand scope of what we're actually doing here, which is quite big. And let's just wait to the point where it just starts to pick this up and starts to work through the tasks. And you'll see it will categorize it by section as well.

[00:35:32]So a little bit of a sort of wait here.

[00:35:35]Um I've just seen a question as this comes in. Can I use openspec with VS GitHub copilot? Yes, you can. It works with we just um let's just go into another project somewhere. Uh oh, actually no, we can do it. We can do it within that starter.

[00:35:54]Uh quick pole. No, where am I going?

[00:35:57]Let's go to quickpoll starter again. So when you run open spec in it, uh at first you'll see you've got all of this stuff in here and you do in fact have let's just have a look here. Where is it?

[00:36:13]Open GitHub co-pilot. So you just select that as well. And again, if your um agent supports slash commands, which all of these will because um this doesn't use MCP servers or anything like that, then it's supported. So, you've got this, you know, this huge list of stuff as well. So, there's there's plenty of options here as well. It's just completely agnostic.

[00:36:34]Um so, just let's just answer one more question really quickly. Um, what if I spend more time planning um on the GPT UI to create the prompt before coding?

[00:36:49]Um, let me come back to that cuz could you just clarify exactly what you mean and then I'll come back to it and I'll answer that cuz that sounds really interesting. What we've got here though, as I said, is now this is working section by section. So, if we actually head over to the tasks list, um, we should start to see these checked off as it works through the first section. Um, so we're basically just going to leave this to go through. Let's head into a really quick 5m minute break. Um, feel free to uh fill the chat with any questions that you've got as we go and then when we come back we are going to look at archiving and then we'll go on to if you want to try this with your own projects and then we'll go to another Q&A at the end. So super exciting. I can't wait to see how this one turns out. Um let's go to a really really quick break and we will um be back in a bit to see how our agent has Okay, so short break and I haven't looked, but hopefully this is working its way through. Um, yeah, we're about halfway through here. So, I think what we're going to do is we'll carry on with the presentation, uh, just to let this build in the background. Um and then we will look at archiving once we are done with this.

[00:43:19]Okay. So what do we do once our change has been applied? Well, we want to lock in the completed change into the project history so our context doesn't disappear. We touched on this earlier and there was a great um question about plan mode. Um like I said, I do use plan mode, but the benefit you get of this is that you can archive any small change you make. Now, I was thinking about this earlier because I thought, well, what you know what what problem does this actually solve? I I kind of know what problem it solves, but I couldn't think of a specific example. Now, a specific example I did come up with is let's say that you have um a fresh project or not.

[00:44:01]It doesn't matter if you're working with an existing project and your AI agent builds something or you build something or you know someone on your team makes a decision and they you know commit it with your code and it goes up to production and then later on you decide to remove that feature or that thing or that the way something was architected or you know could be absolutely anything. Now, the benefit of archiving away any of these decisions that you make is that your agent has context of the um I want to say history, but journey, I think, is a more appropriate way to phrase it. The journey of your project. It can look into the past and it can say, well, I can see a proposal that's been archived in to the the the living spec that we decided not to use action classes, for example, or we decided to do something, you know, completely different or we decided to remove that. Yes, that can live in agents.mmd, but this gives a much richer context of the decisions that you and your team have made over time. That also helps new members of the team coming in to see what had been what has been done in the past as well. So everyone is on board and like I said we commit that open inspec directory to source control.

[00:45:18]So we've got that living history that lives alongside our code. We know that that those were the decisions decisions that have been made. Yes, it's great to have external documentation but that does not directly map up to your code.

[00:45:33]you don't know if that you know change within notion or where whatever you use has actually made its way into your codebase or was and then removed later.

[00:45:44]So archiving is super helpful. So as I said this uh the next change builds on what came before not a blank slate. So you've got a living document that grows um with your uh project.

[00:45:56]Okay. So, um yeah, let's go back to our um terminal. And it's still not uh done.

[00:46:05]So, what can we do? Let's let's go through with some questions. See if we've got any questions here. Um and we'll wait for this to do. If this takes too long, I've got a pre-built version of this I did with this exact well, not exact spec, but the exact prompt to build a spec earlier. So, let's just see how it goes. Okay. So um we did have a question about token usage and I've had this question a couple of times before as well. So from what I have observed it doesn't necessarily use more or less tokens. I haven't noticed a huge difference. I use clawed so obviously um I can monitor the usage really carefully. Um, we're not going to go into the clawed um, usage drama, but um, I didn't really notice any massive difference while I was using OpenSpec, which I personally use. Um, so yeah, I I would say just monitor your usage. Another tip that I could say is what you probably want to do is specifically exclude your archive in a clawed or cursor ignore file or whatever your agent supports to ignore this from your agent context because you might not necessarily want this archive to be read. You want the living specs to be read, which we'll get to later when we actually archive this after this is done. Um but you yeah you can you can tweak it as you need. Um so just couple more questions here. For a massive application, do you recommend one giant master spec or a distributed network of specs? If the latter, how do you prevent them uh from contradicting each other?

[00:47:50]Um, so yeah, when you fold in your um your specs, when you archive your specs within OpenSpec, what will happen is it will actually separate these out into uh sections of your application if you like. It's hard to demo with a small project like this, but um I like to think of it like um let's say you had an application that deals with, you know, you've got one huge module which deals with pay payments, you've got one huge module that deals with orth, you've got one that deals with invoicing. When you make changes to any section, they don't have to specifically be modules that are separated out into directories, but when you do create features within them, they will be separated out into different uh sections if you like. Um, so with openspec, it does its own thing. You you can control this to an extent, but it does its own thing. And for conflicts, you don't necessarily get huge amount of conflicts any more than you would get conflicts in the code itself. So, you know, if you imagine um we're basically asking the question, do we get conflicts when multiple developers on a team are building features? Yes, of course we do.

[00:48:59]But we uh you know, we merge in changes, we discuss changes, we discuss any overlap. It's exactly the same thing. I like to think of the specs as like an extension of like the features that you're building along with a PR. So I just treat them in exactly the same way.

[00:49:14]So yes, um, OpenSpec does deal with that for you and um, from what I've seen in teams that do use OpenSpec and it's been great for teams, like lots of teams, big big teams do use it. Um, once you're used to the workflow, it tends to work out really really well. Better I would say than just people prompting away um, in PRs. So because you get the context beside each PR of what what was actually done as well. Um okay so another question about archiving. Uh once a spec is archived is it purely for history or can the agent query the archive for context? Yes exactly it can do and that's the whole point about it. Um so once we do get to the point where it's actually done we're nearly there. Come on. Then um it will be folded into the spec and uh you can ask your agent about it directly. But if you're using opensp spec to build on this, you can say when we added the poll feature that allowed us to add time limits to polls, this has created a bug and then it will go back and it can fetch the context as you need. So yes, that's why um I find this really really helpful because you've got the the context there. Of course, it's not perfect. You know, there might be some missing things. there might be some uh things that we missed out of our spec that we should have done in which case we can just go ahead and propose again and add on top of it. Um and you know all of that adds to that rich history.

[00:50:40]Okay. So I think we're just going to wait for this to um to finish now um and uh see this in action. Then we can we can archive this away. So, for the um for the hands-on exercise, if you do want to follow this along, we'll we'll take about 15 minutes to do that. Um I don't have anything pre-prepared. Um but what I would recommend you do is go ahead and install OpenSpec. If you want to try this out on a feature within your codebase, create up a branch, experiment with it. It doesn't really matter, you know, you can delete it afterwards. Um, so if we go over to the openspec uh GitHub repository, there's some really good documentation here. And when I say opensp spec, there's a lot more to it than what I'm going through today. I really mean that.

[00:51:29]It can get incredibly complex. We're just looking at the very high level, which I find is all I really need most of the time. Um, so if you go over to the let's go to the installation section on here. So go ahead and install whatever package manager you're using.

[00:51:44]install OpenSpec and um then just do what we've been doing in this workshop. So we'll we'll get to that in a bit and I'll give you an opportunity to do that and and add a feature to your to your project.

[00:51:56]Practice stopping it, practice reviewing the code and all that kind of stuff. And then we'll do a little Q&A at the end if there are any more questions or if something didn't quite work. Um okay, this is already coming together, so I can already see it sort of coming together. Uh which is great. Um, yeah, if you do have any more questions, please just chuck them in the chat and I will do my best to answer them as well.

[00:52:21]Um, and let me just check here as well.

[00:52:24]Yeah, we're very nearly done. We're basically at the test and then the polish of verification. Let's open this back up again because you can see here that we've got this um, you know, all of this stuff checked off as well. So you can see that we're just getting to the point of the tests being written. And by the way, um I didn't cover this today, but generally what I would do in in this um situation is I'm a massive fan of TDD within the context of AI. So what I would usually do is I would ask um my spec to generate tests up front beforehand purely because then I like to review tests and I like to make sure that the agent builds the features against the tests and it doesn't just write tests as an afterthought. So I do this generally with all AI development where I won't just create tests from the feature because the feature might be wrong.

[00:53:18]There's no point writing tests to test something that's wrong. So I like to have the tests up front written first after the, you know, little bit of scaffolding and then have the AI agent write the test to satisfy or write the code, sorry, to satisfy the test. Pure preference. I'm not saying that's the best way to do things. Uh that's just how I like to do this. Okay, so we are getting to the polish and verification.

[00:53:41]Now what opensp spec will often do is it will ask you to manually verify now which is absolutely fine. Um our agents tend to do this anyway once it's built something. It will say do this to check do this to check. It's doing a couple of checks on its own which is great. Let's just head over actually because yeah it's just finishing up. Um, but it'll ask us to manually visually audit stuff like check the right color palette is used, do a smoke test in the browser, which is exactly of course what we are going to do. Um, so I don't know what I've done there. Let's go and jump into um Safari. We can find it. Don't know what's happened here. There. There we go. Okay, great. So, already this looks better. We gave it some visual direction, which is what we wanted. Um, and yeah, let's go ahead and try this out. And I've got a pre-made version if anything goes wrong because I didn't properly review the spec. So, um, let's do the exactly the same thing. So, yeah, say which agent do you use and we'll go for clawed code and we'll go for codeex.

[00:54:48]Now this isn't necessarily um always guaranteed but one of the side effects I find of using openspec or any specd driven development framework is that it tends to be a little bit more careful about things. We saw earlier on this version where when I added an option and then I click create poll it didn't have any validation. Now with openspec and the framework in general it will think a little bit harder about this. And as you can see here we've got a validation message. The validation message isn't perfect. It's saying the options to field is required. So that zero index sort of, you know, validation thing is coming through without any customization, but at least it's validating. We can go in and manually tweak that or ask our agent to do that without necessarily writing any more spec. So let's go ahead and create the poll. And I just need to uh start mpm rundev in here.

[00:55:43]And oh no, mpm rundev.

[00:55:47]And there we go. Perfect. So already a lot better. It's listened to what we wanted from that initial build. We knew that we wanted a sort of admin panel. So we've got copy uh links here, which is great for the admin URL. We've got a public URL which we can share. There we go. And more importantly, we've got your email. So let's test this out. We're going to do a quick smoke test on this.

[00:56:10]Um it don't worry if you've not used Laravel but basically I am using let's just check for our mail a log file. So this will instead of actually sending something over it will just log the email for us which is fine. So I'm going to go ahead and enter in my email address here and I'm going to click send magic link and yeah nothing happened. I think we've got an issue without um dev server here but the email has been sent here. Let's just refresh that. Yeah.

[00:56:37]Okay. So, I think um uh maybe the client isn't uh refreshing properly, but that's fine. Um so, yeah, here's the email.

[00:56:45]You're voting on this poll. Your choice.

[00:56:47]Click the link below within 24 hours to record your vote. We've got a confirm vote. One thing I probably would have done is look more at the spec and decided, well, actually, I want a signed URL. Laravel has that functionality. Um but these are all just small decisions you'll pick up as you're going through your spec. So, I've clicked on that in my mail. I haven't obviously, but that has registered that um uh poll vote, which is great. Um now over on here, let's check out the admin panel. Um oh, it's here. Okay, so yeah, the admin panel is here. Now, one thing I would have probably added to this is that I could see results in here, but that's fine. If I'd have read the spec, we would have got that. Um, and this looks good to me. So, it's a lot better. And we know that we've got that email verification now. We already figured this out. Um, that's the one I I built earlier as well. Okay, great. So, this is clearly better. So, um, what do we want to do now? Well, we want to archive this. We've already spoken about this, but let's just say I'm happy with this feature or this uh, you know, uh, scaffold of this this MVP if you like.

[00:57:56]What do I do now? Well, once I'm happy with this, I archive it. So, we use opsx and we use the archive command. Um, just while we're running that through, I want to talk cuz I got a question about this previously. When do we archive? Do we archive as soon as we've locally built the the the feature um and we're happy with it? Not necessarily. There's a few different points within the life cycle of the the software development life cycle within your workflow you can um you can do. Just while just before I answer that, um which change do you want to archive? Add pole core. Now, notice that it's telling us that some of the tasks aren't complete. They're the manual tasks. So, you could just go ahead and check them off. Ask your agent to check them off, or you could check them off yourself in the in the markdown. Um, so let's go ahead and do that. So, when do you archive? Do you archive now? Do you archive um after it's been code reviewed? It's really up to you. From what I can gather, a lot of teams will actually push these up to source control. They'll then push them to staging. they'll push them into production. Once they're happy with the change, then they will go in and they will archive a specific change. Um, I'm going to say archive anyway here because the tasks are unchecked. Um, and we're going to say sync. So, what you could do is, you know, you'll have multiple changes. Remember, these are put into directories here. You might have add pole core, then you might have add feature one, add feature two, add feature three. You don't need to archive these once they're finished. They can stay living in your spec. um you know as long as you want but then once you're happy with each one you can archive any of the commands that we've looked at so far uh so far so opsx um propose archive they take loose arguments like all skill files so we could say archive and then we could say add pole course you have control over this you don't need to make one change archive it then create another feature and all that kind of stuff. So, you know, you can do pretty much anything. You, you know, you can create a list of five features or you can create two features that you're experimenting with and then go ahead and apply the one that you prefer and then archive the one that's, you know, that worked out. You've got a lot of options here. And of course, all of that is in the documentation as well. Um, so let's just have a look here. Now, I did interrupt this by accident, so I'm going to go ahead and archive this again. And let's just wait for this to run through.

[01:00:29]and we'll see this start to come into here. So, you can see that our specs, like I said earlier, is sort of breaking up the the polls and the voting functionality separately. Um, so you'll see that these folded into specific sections of the app. Of course, this is really simple at the moment, but like I said, if you had like a billing section, if you had an invoicing section of your app, an or section, these would be categorized under the right place. Um, so yeah, let's just wait for that to run through.

[01:01:02]Um, and once it's running, I'll just have a look at the questions really quickly.

[01:01:06]Um, so we've got heavy UI features. How do you describe these in the spec or guide the agent to handle this in the spec? Um, now there's a bunch of ways that I I've done this in the past. Um, if I'm working on a project and I have a design inspiration, just drag it into my agent. So, I just grab an image, drag it in, and say, "This is the kind of visual style I'm looking for." Um, it's really difficult with AI agents, with any kind of UI design, because you can't design them as such because you don't know how it's going to look before you actually do it. You sort of can because there are lots of tools, there are lots of services that allow you to do that as well. Um but I would typically uh work using a service like um I would use something like um the the name of it completely slipped from my mind. Give me a second and I'll think but I would use a service to build up a design using AI or you know manually building something as well. or if you have a designer on your team who can give you that um then you can then you can import that into uh Claude either through just pasting over a load of Figma. So with Figma what I would tend to do is build up a design in there and then I would export like the HTML, the style, the the color palette, all of that kind of stuff. I'm not a designer and you know I um I don't have a huge amount of experience with design and stuff but you'll find a way. Either way, try and get that into your to your um your projects or start with a pre-built design and then add features on top. Um, okay. So, I've seen another question, but I'll we'll we'll we'll take it from here and then I'll answer that in just a second. You can see that this has now been archived. So, let's take a look at the structure again. Um, so we've got under changes, we've got the archive directory is now full of this exact change. So, we don't lose the very specific context here, which I love because it means I can come back and look at the exact decisions that were made for any of these things in here.

[01:03:14]So, we've got two sort of overall specs for both of these in here. So, these are just sort of like um when then scenario specs for each of these, but we've also got the design document, the proposal, the tasks. And if you were going to go ahead and use that open spec package, you can see that um we've got two specs here. We've got a a task completion rate. We know that that's not 100% because we had some manual smoke testing that we didn't check off, which is fine.

[01:03:41]We've got archived uh things. We've got a graph here as well, which will show you the um the the the sort of features that are branching out from your uh project as well, the changes. So, this is really helpful because we can come in and we can browse things. We can look at past decisions as we've already spoken about. Um, and then we get the sort of overall specs here. So, this is the poll spec. So, anything that we change in polls will be folded into this. Anything that we specifically change within the voting section of this will be folded into this. We've got these decisions that were made along the way as well, which is great. And we've got all of the rich history inside of our archive. Um, which is brilliant. Okay. So, let's go back over to uh let's go back over to Safari and yeah, so we've done this. So, let's go for a 15inut break slash hands-on activity. Um feel free to go ahead install OpenSpec. Pull up one of your projects that you haven't worked on for a while or the one that you're currently working on. Create out a new branch. Run OpenSpec in it once you've installed OpenSpec. So, OpenSpec is just openspec.dev. I'm just going to pop that in the chat just so you can grab uh that easily. Um, and just go ahead and add a feature to one of your apps. Try and keep it really, really small and simple.

[01:05:04]Even as small as changing a bit of text.

[01:05:07]You just want to get used to the new workflow of proposing. So, remember what we can do here is we can say opsx either explore. or if you've got like a tricky problem that you want to work through and answer ask some questions or you can just go straight into proposing.

[01:05:24]And in here, the string that you give after propose can be anything. It could be uh let's say you've already got a spec living somewhere else. You could just grab that and paste it in like it's entirely up to you. Or you could just say change homepage text to something and then you could do it like that. So, it doesn't really matter what you put into propose. Uh, it could be a bunch of images as well.

[01:05:49]Really, you know, you could drag some files over, whatever you need to do. And then practice doing that with the propose, apply, and archive cycle. Let me know how you get on after the 15 minutes. Also, if you have any questions while we are doing the exercise or if you don't want to do the exercise, that's fine. Uh, please feel free to pop them in the chat. I'll have a think about them while we're in the break and then I'll go ahead and answer as many as I can. But this is a really good way just to get into this like overall that three-stage workflow that we looked at earlier. Okay, so uh just to recap, open an existing app, install opensp spec, add a feature. So, uh there's the command. I'll leave this open. Um pick a feature, just something small. Write the spec. So, really simple proposal for the change. You don't really need to give it too much information. Build it. practice stopping it, reviewing the code if you need to adjust anything and restart and then check that it works of course and then archive it and uh yeah feel free to share any details. Um so yeah I'll leave this open actually rather than the timer. We'll be back in 15 minutes and uh yeah pop any questions in the chat um as we are working through but I'll see you back here in about 15 minutes.

[01:21:40]Okay, so we we've got about 30 seconds left, but I thought I'd jump in.

[01:21:45]Hopefully, you got on really well with this. If you uh gave it a try, it can feel a little bit weird at first, but um if you didn't try this or if something went wrong, um then you've got plenty of time to experiment with. And of course, please feel free to add anything in the chat if something didn't make sense or if you have any other questions. I can see some great questions rolling through um from before and I'm going to go into them in a minute. But we are now going to go on to uh just a wrap-up just to talk about what we've gone through just to summarize everything and uh this should be really helpful. So let's take a look at the loop or the workflow here end to end. So we know that we start by proposing then we go and read the spec and we refine the spec by jumping back into our agent and asking it to update stuff. We typically don't do that manually just because of the uh difference between the different files.

[01:22:46]And then we have this like inner loop.

[01:22:49]Um, so we have we apply the change, we pause it if we need to for any reason, usually to like fix guard rails. If it's going off off the rails, we want to sort of tighten that a little bit. And then we resume it. And then once we go through this inner loop multiple times potentially, uh, then we end up archiving it. And we've already seen how that folds it into the project history.

[01:23:11]And then we get that rich context for the past of our project. Um, okay. So, um, yeah, this is the workflow for a single change. Like I said, it can be something as simple as just fixing a bug. It could be just changing, uh, a small, you know, piece of information somewhere. Maybe not necessarily. I'd probably just dive in with a simple prompt to do that. Um, but it's, you know, for every meaningful change that you make, I'd say you would come in and propose, check it, and go ahead and execute it. Um, and this is pretty m much what we teach on unlearn. We teach this at a really high level and then we deeper dive into uh things like openspec. Um, you know, and you can deeper dive if you want to. And it's a massive shift from traditional development. And that's kind of the point, but we can relearn to do things like this. So why does this stuff pay off? Um, well before there's any code, you and the agent already agree on what you're building. I saw a question. And I'm actually going to sort of weave this into the end here. Um, before I hit apply, is there any way to dry run the spec? There isn't actually any way to dry run the spec before you go ahead and let your AI agent build it because your AI agent is non-deterministic. You don't know what it's going to do. The closest to that is the task list. Um, and I would then say the then say one stage up from that is the design document where you get the technical design decisions and then the proposal is that that highlevel document that you should be able to share with anyone on your team even if they're non-technical. So really just by looking through that task list that is really the dry run. Your agent is less likely to hallucinate if you use um a framework like OpenSpec or you write a spec yourself. Um, but you you will look at that task list and you will see that is the kind of dry run. There's no really way to dry run it because to dry run it, you would sort of have to have an agent interpret what you wanted to do and actually come out with some kind of output. Like I said, because that's non-deterministic. The best thing to do is just run it through. Now saying that try it with small features um before you try it with huge things and then you know you will be able to sort of work out um where you need to tweak things from there and and build up that skill. So um our specs are the source of truth. Um the next change, the next session you start up or when you hand this work over to someone else or someone else picks this up, everyone starts from the same place which is one of the problems with AI. um test the spec, test the build. So you poke at the spec, which is basically just text before you go ahead and uh and build it.

[01:26:01]And it's slower now this process. Um and that's going to sort of answer another question from Eric. Um so I'll weave that in as well, which is which is the hardest habit, which was the hardest habit for you to unlearn. I wouldn't necessarily say a habit, but it's it can feel painfully slow at first to to work like this rather than just jump in with a prompt. You think you know what you want. I think I know what I want. I don't. And it feels really slow to have your agent build a document, have to review a document. But trust me, if you use this process, particularly within a team, you'll get faster much later because you will start to think more in requirements rather than how to prompt.

[01:26:47]Prompt engineering is kind of dead. We we're past the point now where we have to construct really elegant, specific prompts to get our agents to do uh what we want. Our agents are really good at interpreting what we want, but they're even better at interpreting what a really well-ritten spec wants as well.

[01:27:07]So, this will actually save you time in the future with that little bit of upfront. And it's like anything. This follows that 80/20 rule where if you spend 80% of your time planning and then 20% of your time letting it implement or tweaking things, you um you'll find that really uh that sweet spot.

[01:27:26]Oh, that's the end of the um slideshow.

[01:27:29]So, I missed my Q&A slide for some reason. Um but yeah, hopefully that um hopefully that makes sense. So, um let's go to a couple of questions. I don't I think I might have actually answered them all.

[01:27:43]So, if there are any, please go ahead and let me uh let me know. Um and yeah, we'll we'll answer any more questions that you have. So, um, yeah, I've already answered what was the hardest habit moving from, uh, you know, writing code to actually reading specs beforehand.

[01:28:04]Um, have a look here.

[01:28:08]Uh, is it sponsored by OpenSpec? Nope, it is not sponsored by OpenSpec at all.

[01:28:12]This is um, this is my preference. There are other tools that you can use as well um which are just purely personal preference. The key thing about this process is less about the technical implementation of a spec and how it works and more about the purpose of specking. So over on unlearn in our first workflow we teach you how to build a spec without any specific tools. So the importance of building a spec, how we test our spec, how we uh ask our spec, if you built this now, what would you do? What assumptions would you make or what assumptions do you make about this project product or this feature before you build it? That's the most important part. Um with openspec, that tends to happen automatically, but of course you still need to to to read it uh read the actual spec. And um it's the same for any of any of the other tools that exist as well. Um, so no, it's not it's not sponsored, but it's just my personal preference, but I'm going to encourage you to explore every other tool there is.

[01:29:18]Um, let's have a look here.

[01:29:22]Yes, so someone else has mentioned um, GitHub spec kit um, and the question is why did I end up choosing this versus others? I re you know what I cannot give you um, a a specific reason. I just like the workflow. So again, if we come over to the docs here, if you really dive into this. So if we go into the workflows document, this is where things start to get a lot more powerful. Um, and the philosophy here is actions, not phases. Um, so if you go through here, have a really good read of the docs here, but um, you you basically get all of the patterns. There are different commands that you can use as well and different commands you can enable. And this gives you a lot more information about the workflows. I'll be honest, a lot of this is overkill, but I just really like the openspec philosophy um how how the the process through actually you know working through uh the proposals uh applying and archiving work. Um but you know there are benefits to every to every different framework.

[01:30:30]I'm just having a look here seeing if there are any more questions and Can't see anymore.

[01:30:49]Perfect. I can't see any more questions.

[01:30:51]I'm uh sorry if I have missed any, but um yeah, like I said, if you do have any other questions, feel free to reach out to me personally. you can reach out to me on X if you want to. Um and yeah, please check out Unlearn. So, um aside from specific tools, we teach workflows that are tool framework and language agnostic. Like I said at the start, these aren't just a collection of courses. These are things that are going to stick with you and your team for as long as different tools come and go.

[01:31:29]That's the the goal for Unlearn. That's why we built it. Uh we want this to be a hub for developers regardless of what happens in the future. So like I said, come over here, watch this video, you'll have a little bit of a preview into the system, and we're releasing workflows regularly and uh yeah, we're really excited um about how to solve this problem for developers now. Okay, so um thank you so much for joining this workshop. I really hope it was helpful and um yeah, I hope that you find a great workflow for yourself whether it's using openspec or not. Um but spec driven development is a really good thing to experiment with if you are struggling to get um accurate and non-h hallucination results out of your agent.

[01:32:20]Um so yeah, thank you so much for joining us. Um, I'm going to go ahead and end the stream now, but reach out if you have anything and enjoy the rest of your day.