How to Enhance Vibe Coding with AI Spec Driven Development and Cisco U

Hinzugefügt: 2026-05-09

[00:00:00]All right. Hello everyone and welcome to the month of AI series. Today I have a very special guest with me from Cisco University, Jason Belk.

[00:00:11]Jason, would you like to introduce yourself?

[00:00:14]>> Hi, I'm Jason Belulk with learn learn with Cisco and our our main platform is Cisco.isco.com both for Cisco employees and all our customers and partners who want to check what's out on there. for training and certifications from CCNA, CCNP, cloud security, automation. We cover it all.

[00:00:32]Providing both on demand labs, videos, full-blown um courses, as well as free content for those of you who don't yet have subscriptions. So, today I'll I'll be sharing some information about a cool new AI approach on a free tutorial that you can check out and play around with yourself.

[00:00:50]>> Very nice. Well, being from Cisco DevNet myself, we love hands-on learning and opportunities to really scale up. So, I'm really excited to collaborate with Cisco U today. Jason, do you want to give us a sneak peek of what the website looks like?

[00:01:07]>> Sure. So, this is our main Cisco U homepage. For those of you who are logged in, you have a for you page that basically gives you access and also if you're an existing certification holder, you can see we have different rev up campaigns that go on where you can actually get C credits to reertify your certifications as well. So keep an eye out for that for those of you who have your DevNet or CCNA CCNP automation certifications.

[00:01:30]>> And what we're covering here today is it on this website?

[00:01:34]>> Yeah. So if if you go to.isco.comtutorials, cisco.com/tutorials.

[00:01:39]You can see we have over 200 tutorials covering from automation to cloud security networking. And you can see a recent one here I created in February.

[00:01:47]It's called introduction to specd driven development build a project without writing code. And if I go into that particular tutorial, you can see we have whatever one to 10 steps. And the first step on all these tutorials include over overview of what you're going to learn, different learning objectives, as well as any dependencies that you'll need.

[00:02:08]So, this particular one has a sample project and a zip file that will help you get started and get going and lets you know that you're going to need a cloud code subscription to follow along as I'm doing it today.

[00:02:18]>> Hey, someone's joining us that has no idea what an AI specification criteria even is as an engineer. So, what is that?

[00:02:28]Let's pretend you're in a conference room and your manager says, "What are you working on this week?" And then you explain to them in layman terms or lay person terms of what you're trying to accomplish. You know, the 10,000 foot view defining your requirements of saying what type of languages you're working with and basically laying all those assumptions out there because the AI can't read your mind. And so it needs to know what your experience level is, what your comfort level is, what you're able to troubleshoot as an engineer because you you don't want to be creating something from a coding perspective that's insecure.

[00:03:02]>> Well, can you tell me a little bit about how this project came to be? Was there like a need that needed to be filled or what are the origin stories?

[00:03:09]>> Sure. So, so I didn't create Spectrum Development and I I actually had it shared with me through a friend named Jason Gekki. I have this website here sddd.gki.io IO that gives you this some basically starter material to go through that I based my tutorial on and for spec driven development started last summer as far as I can remember it was GitHub Microsoft they they called this create this thing called a spec kit that basically allows you to download these series of bash scripts to give some guard rails and guidance for your AI local coding environment that simulate what I'd call like a project management water flow waterfall workflow. in terms of defining your requirements, defining your tasks, you know, defining your success criteria and your assumptions and then actually executing on that and repeating that through all of your different features that you're going to do generally even for small projects all the way up to I'd say production grade deployments.

[00:04:04]>> Okay. Yeah, I see some of these words that I see here, these features in your workflow, they align with little things I've known about just regular AIdriven development. things like process and evaluation, safety, collaboration. Um, do you mind going a little bit more into what are the difference between like constitution clarify for example tasks those kind of things?

[00:04:28]>> Sure. So, so the first command before you get started is basically the spec kit constitution. So, assuming you're following my tutorial, you've loaded down this uh spec kit workflow into your claw code. You have the slash commands.

[00:04:39]These are skills loaded in. You will then issue your specit constitution command. And this will ask you a series of questions basically trying to get your assumptions. Is this a production thing that's for 10,000 people or is this just your hobby project for yourself? And that will change its design decisions as you're doing the project. So this constitution is something that this cloud code instance will refer to every time it's going through this implementation loop. So if you change your assumptions as you're going in a project, you want to go back in there and edit that constitution.

[00:05:07]Maybe it started as a hobby project and it grew to something much more.

[00:05:11]So you're not actually writing these constitution files. Of course, you can go in there, mark down files. It is generated for you based on based on the conversation you're having with clock code. Um so the first one in this flow, the constitution you really just do once and then you kind of go through this flow starting with spec kit.specify specify, which is creating your specification files, defining what your new feature is, the tools we're using, the scope we're trying to accomplish, and then you type that all in several sentences on your cloud code terminal with with the spec and specified, and it will take you to the following um commands. And then after that, you have spec clarify in case there are any ambiguities. This is not a required one.

[00:05:50]It will suggest it if if you're not clear, it will suggest, hey, you should run specit clarify. and that brings up that skill and then you run it. So example of that would be maybe you were ambiguous like oh I want to use Python to do this app and it's like okay what Python libraries are you interested in are you what package managers are using UV all these types of things so specit clarify not require it'll suggest it when you need it specit plan it creates the plan for architectural decisions in any parallelization so if it if it wants to spin up sub agents for cloud code and do things in parallel it will figure that out at the planning phase Then on the task phase after it has its plan it defines success criteria for each of the tasks that it needs to implement. These are are all markdown files and then you issue spec kit implement. So my recommendation even though this is not part of spec kit is to do test driven development. So test driven development basically says tell us the AI when you're writing this code don't just go off and start building things that are that are going to break.

[00:06:51]build with a mindset in mind that you're going to build tests that fail and then build code that pass the tests which is kind of I think for people who haven't done it before a reverse way of thinking but it helps the AI give it an end goal in mind saying okay I want to have a test that says I'm able to generate these ginger 2 um templates into network configuration so I need to have I need I need to build for the user these different tests that are going to start failing in a fail state and eventually pass once the code executes properly.

[00:07:24]>> And when you say tests, do you mean like automated tests like or like a human manually? You know, >> I say these would be automated tests, but you would still want to verify as a human making sure all the output because you can have all your tests pass and still have code that isn't doing what you wanted.

[00:07:41]>> Okay.

[00:07:42]>> So, we're team human in the loop, right?

[00:07:44]>> Exactly. Exactly.

[00:07:45]>> Okay. Just clarifying. Okay.

[00:07:47]>> And or it might have things that it built you're like, "Oh, wait. you're taking this in a different direction that I wasn't expecting that that's where the previous steps help on that end, but it's not perfect by any means.

[00:07:56]So from a demo perspective, um I'm in cloud code right now. I have you can see all the different spec kit from specit constitution to spec kit implement out here. What what what's something you you want to build that is relatively simple, we'll say without any outside dependency scheme?

[00:08:10]>> Yeah, just like a payment app.

[00:08:12]>> Okay. Can you create a simple CLI app that uh simulates paying through a payment process? Does that does that sound good?

[00:08:28]>> Yeah.

[00:08:29]>> Okay.

[00:08:29]>> I think I I I like it because it adds there's a certain lens of ambiguity to it that I I'm interested in what it's going to output. So >> yeah. So So it's loading in the specit bash scripts. It's checking to see what we currently have in terms of existing files. It's gonna >> It's ha ballalooing.

[00:08:46]>> Yeah, it's halalooing. And and cloud code says, "Okay, I'm going to run some commands audio bash." It's it creates it it automatically one of the nice things about this is it creates feature branches for each of these specs. So, you're automatically getting a paper trail. So, each of your feature branches have all these specs. So, as you're creating your app, you're creating these subdirectories that are all on, you know, features that eventually get merged into domain. Um, and it auto creates your documentation. So often times when I'm done with my app, I have 30, 40, 50 specs that then I can just tell my other AI look at all my specs and build a presentation so I can report to management on what I've been working on because it's kind of a self-documenting feature that way because it's defining all its requirements, all its test outcomes, all the stuff. So the AI can then easily look at all these markdown files and coate, you know, exactly what you're doing. And then you also have automatically it creates the GitHub branches for you and merge it in later.

[00:09:34]And those branches also give you a paper trail on the poll request. So it'll create a pull request comments to say okay here's what we worked on for this particular feature and then you know if the test pass so it's creating a specd so you can see it's doing something with a CVB of Visa Mastercard or MX uh okay so so we just finished our specify step and and you can see it created us a branch for payment CLI simulated it has a spec file under specs payment CLI simulator so if I went on to GitHub I I could go to this markdown file and review it That's kind of what I'd say is the UI is just like okay if you do want to read it review it you can either open up cursor or VS code or something like that and review the files or you know push it to a private public GitHub repository and view them that way has uh our requirements checklist says I create a specification for a simulator with process of payment transaction history simulate payment features and 12 functional requirements including card validation failure assimilation triggers and eight success criteria and you can proceed with either clarify if you want to refining requirements or plan. So let's go ahead and clarify so we can see if this one was kind of ambiguous. It already kind of suggested using the clarify. So and you see it suggests what the next step in the flow is. You don't have to memorize that flow. You just have to know the specit specify and then it suggests what the next step in the flow is. I just copy and paste it in. So now it's going it's going through the requirements it just built from this specify step. And now it has a multiple choice question. So if I scroll up it says question one of five CLI interaction mode. It uses provide payment details but doesn't specify the interaction model. This impacts UX design, input validation, testability, and it recommends option A. It's interactive mode. It's more user friendly. For the sake of time, I'm just going to go through all these questions and use its recommended mode. But that's basically what happens. And it's not always five questions. That's it's a maximum of five questions. And then it will ask these clarifying questions that update the specification before it moves forward.

[00:11:28]>> Is there like a lens of agentic reasoning in this workflow? Yeah. So I basically the cloud code side is doing the agentic reasoning because from a coding side the spec kit workflow is not adding you can look at the files on your own time but basically they're just bash scripts. So I don't have like some complicated you know AI framework that it's literally just helping claude code in this case which already has its own local agent >> say this these this is the way you should behave and then cloud code uses its intelligence and its sub agents to adhere to those guidelines.

[00:12:04]Um and we can see here we did our clarify and it already went through the clarifications that I typed in and said okay we had two questions was asked two questions answered it updated to the plan. So I can scroll down copy and paste spec kit plan and then we can build out that that plan.

[00:12:20]So if I go back to our um our high level flow here, we we started with our spec kit specify. Right now it's on the spec.

[00:12:27]We did the spec kit clarify. We already did the constitution and then we right now it's finishing the plan. Then it'll generate the tasks and then it'll start implementing that code. So I'll say in terms of like speed, it's not the fastest. Like if I just had cloud code, hey build me this CLI app, it'll be done already. It' be but it might not work.

[00:12:46]And also, um, I purposely picked a simple example just for the sake of example to show you kind of knowing something's going to work well. Um, but I'd say for more complicated things, this is very effective at saving you time in the long run because it's something that in the long run, you're going to have less issues in terms of assumptions not being clarified or dependencies not being accounted for, especially when it comes to assessing the parallelization. That's something where I've had often times it'll spin up sub agents and and and do things in parallel. So right now if I scroll up on the terminal we can see okay the planning is complete. It generates artifacts of our plan research data model. So it created all these markdown files and then it said everything passed our constitution. So it made sure all the stuff it created double checked against that constitution file of our governing principles and now suggests hey you should run spec kit test to generate the order task breakdown. So now I'll copy paste and do spec kit tasks. So now it's going to generate it implementation task. That should be relatively quick and then go into the actual implementation.

[00:13:51]>> I want to revisit what you said about the sub aents. Um so for those that may not know what sub aents are, what are they and what lends themselves to I guess exposure to vulnerabilities?

[00:14:05]>> Yeah. So, so sub sub aents are basically like processes spun up by the primary AI and they're going to go off and do whatever you tell them to. Um, and especially when you're giving them access to your underlying computer and access to install things to access the internet to um execute commands on your system. Those are all um entry points where an attacker could insert themselves and like say it's it searched on a website and that website had information that had basically you know ways of getting that data back into your sub agent that could then execute malicious code on on your your work PC or personal PC and things like that. So uh because recently there was even an attack uh for JavaScript where where I think it's Axios where where they basically um in injected malicious code into a published JavaScript repository and people using cloud code we're just going along and then downloading this malicious code not even knowing because it was from the official agency. So I'd say that's a best practice of security in general, not the way it's AI engineering, but just especially in AI when you're going fast, you're not reviewing everything >> is to be aware of your what they call supply chain of knowing where your code comes from, where your dependencies come from, and those subd dependencies like you might install a package that has sub packages that are corrupt.

[00:15:24]>> Okay. So then in this AI um spec uh project, is there like an opportunity to collaborate? So, for example, this financial app that we just built, um, if there was a need for like the network engineers to also be communicating with like the finance team or like the legal team or on something, uh, which feature would you use? Would they be also spawning the sub agents for that? Yeah.

[00:15:52]>> Yeah. I mean, I think generally the implementation for this happens so quickly that it's it's not necessary to bring in other people, but I I I would say if if you're doing a more official project, this you can slow down that that workflow significantly in a good way where where you might have stakeholders that want to provide their input and you can tell cloud code, okay, refer to these other files of user inputs from the security team, from the marketing team, from the product design team. So when we're going back to like the the specifying the requirements, I just did that in like a sentence or two, but there's no reason you couldn't tell cloud code, you know, look at these particular files, look at these PDF from the these emails I downloaded, look or and if it's on GitHub or GitLab, your internal instance, you could have a pull request where people are commenting and because Cloud Code could have access to your GitHub CLI, you could have GitHub CLI access your poll request comments.

[00:16:50]So, I'd say there's definitely a collaborative opportunity there depending on how your team works. But I I'd say one of the main benefits of doing something like this is that you're able to prototype things very quickly.

[00:17:00]So, you you could come to the meeting rather than like, oh, let's let's define the requirements and think about what we could do, you could spin up just a very simple demo app in an afternoon and come to the meeting with a demo.

[00:17:11]>> I know earlier you said that uh you willingly chose Claus Code. You didn't have to, but there were other options.

[00:17:19]Um, is there some type of metric that you measured for like with latency, reliability, something that pushes you towards cloud code versus another interface?

[00:17:30]>> Um, it wasn't like a scientific thing. I I started using cursor and installed it and and I just found the onboarding experience less intuitive.

[00:17:40]>> Um, and this is a couple months ago, so it might have changed since then. and and uh the spec kit has instep instructions for how to install it with multiple different harnesses. In this case, I just found Cloud Code's harness to be very intuitive and kind of predicting what I'm going to be doing >> and and and in a way that I just have to kind of talk and plain human language and then it more or less figures out what I want.

[00:18:05]>> But what are we doing here now?

[00:18:07]>> So, it looks like it's finishing writing up the command line interface. So if I scroll up, it's on task 19 for uh the different tasks that it planned out. So it say you know task 18 implement iterative prompt. So I created this prompts.py for um this command line app and we have it's create display implement output display features. Um so basically it looks like it's you can see payment fail transaction ID reason response code display history. So it looks like it's finishing up um in terms of building the CLI app. So we can see okay it passed all its tests. Remember we're talking about the test driven development. So we can see it had phase one setup all the way down to polish and it successfully passed all of its tests all 40 tests completed with all these tests passing.

[00:18:57]Not going to take the time to review the tests. So the payment CLI simulator Python CLI app that simulates payment processing. So it has a pay process payments with it being interactive props history help quit validation uses loan algorithm for card numbers expir date CV validation three to four digits failure triggers if it if it the card has these weird numbers it'll fail and let's open a new tab okay so we have pay let's see what examples it gave us sample inputs pay $50 I think it said do pay okay then you enter So, I didn't follow the instructions.

[00:19:35]>> The instructions were pay then $50 and then put in your credit card number.

[00:19:40]>> It's interesting. It didn't prompt you like this is what you did wrong. It was just like unknown. Yep.

[00:19:45]>> Fig out.

[00:19:46]>> And and that's where it it comes down to like what requirements you gave and this is just the first feature where if you okay maybe for feature we want some error handling. We want in case someone puts pay $50, it is able to handle that.

[00:19:59]Um, okay. So, hit pay $50 for this credit card with this in the CDV processing payment. Okay. Transaction ID creates an amount with the card kind of blocked out. And we can go to view history and we have the transaction there. I see some type of JSON file.

[00:20:16]>> Um, remind me is this project like open source? Like can someone actually build on top of this? To what degree?

[00:20:24]>> Repo that I I made called claw specit template.

[00:20:27]>> Yeah. which basically gives people I'd say because you can go on Microsoft and get there's the official spec kit um which is what the instructions on my tutorial go through but I I've just noticed there are other things I want I kept want to add in there after using the original one. So this is my particular fork of that so to speak where I've added in some other bells and whistles to make it easier for myself to use. So if you want to use mine, that's fine. Or you can go to um GitHub spec kit and get cloned from their side and um cloud code can help walk you through how to set that up.

[00:20:58]>> All right. Well, thank you Jason for the demo and thank you again for joining us for the month of AI series. Do you have any final thoughts before we sign off?

[00:21:08]>> I'd say get out there and experiment.

[00:21:10]Like for me, the biggest thing with AI is less about reading it and more about just having fun ideas and seeing where you can take it. see how far both on your personal projects and professional projects you can do in a safe, secure, and scalable way.

[00:21:25]>> Well, I'm going to plus one that. So, you heard it here from Jason and myself.

[00:21:30]Get out there, check out this project, build, learn, and leave in the comments any questions or findings along the way.

[00:21:38]Bye, everyone. Thanks again.