Erik Hanchett (Senior Developer Advocate, AWS) explores spec-driven development as a way to handle complex codebases where AI coding assistants need upfront planning beyond small tasks. The talk shows how assistants like Kiro can break down complex work into three distinct phases, discusses real-world tradeoffs of the approach, and explains how to apply it in projects. # Video Identity Observations: "Using Spec-Driven Development for Production Workflows" ## Speaker Self-Description (Explicit Claims) - **Creator identity stated directly in transcript:** > "My name is Eric Hanchett. I'm a senior developer advocate at AWS. I have over 15-plus years of software development experience." - **Contact points promoted:** LinkedIn (primary), Blue Sky ("Eric C H"), and X, plus invitations to connect: > "Talk to me, follow me. I'd love to talk to you more about it." - **AWS affiliation drives product content:** He presents Kiro, AWS's AI IDE: > "We released Qiro [Kiro] uh early late last year in a general availability. It's our new AI IDE coding assistant." The repeated "we" ("we decided to create," "we're really proud of it") signals he speaks as part of the AWS team. ## Intended Audience - **Working software developers using AI coding assistants**, evidenced by framing like: > "I kind of like to think about our coding assistants, our large language models that we're using every day..." - **Practitioners responsible for code quality and review**, implied by the "human in the loop" advice: > "You need to be the code reviewer of all the code that's generated through this process." - **Developers of both new and legacy projects**, addressed explicitly: > "You're probably thinking is this spec only good for greenfield brand new projects? And I would say absolutely not." ## Claimed Scope of Content - **Tutorial/explainer on spec-driven development**, defined at the outset: > "Today I want to tell you guys all about spec-driven development and how you might use it in your workflows... how can it make you a better and faster coder?" - **Not purely promotional:** He explicitly disclaims a product-only pitch: > "I don't want this to be a half-hour pitch for Kiro. You can do this process spec-driven development without Kiro." - **Includes a live product demo** of Kiro's spec mode with a movie database example, plus mention of a manual workflow and GitHub's open-source "Spec It" as alternatives. ## Observable Presentation Patterns (Demonstrated, Not Claimed) - **Opinion-forward, interactive style:** He flags personal stance and invites debate: > "I have some opinions. These are my opinions. Uh let me know. Connect with me on LinkedIn if you agree or disagree." - **Anecdote-driven teaching**, e.g., the intern/VP story used to analogize LLM behavior. - **Community-building via multiple channels:** Closing directs viewers to kiro.dev, Discord (`discord.gg/kiro.dev`), LinkedIn, Blue Sky, and X. - **Tool-ecosystem awareness:** References Kiro, GitHub's Spec It, MCP, Jira/Asana, fast-check, mermaid diagrams — suggesting a channel presentation oriented toward the AI-assisted development toolchain. ## Claims vs. Demonstrated Evidence — Distinctions - **Claimed:** Kiro "went a little bit viral. We got tens of thousands of downloads" — creator assertion, not verifiable from this material. - **Demonstrated:** Practical depth in the demo (requirements in EARS format, property-based tests, MVP task restructuring) supports the tutorial framing regardless of product claims. - **No channel-wide scope inferred:** This single video shows a conference/presentation-style talk format with embedded product demo; broader channel identity cannot be concluded from this source alone. # Delivery Observations: "Using Spec-Driven Development for Production Workflows" — Erik Hanchett, AWS ## Overall Tone - **Conversational and casual**: Frequent filler and asides — "uh," "you know," "cuz you know, we're really proud of it. It's fun." - **Enthusiastic and encouraging**: Repeated invitations to engage — "Feel free to after this presentation to go check it out," "I'd love to talk to you more about it." - **Self-aware and disarming**: Flags his own opinions explicitly — "I have some opinions. These are my opinions." ## Recurring Phrases & Verbal Habits - **"Really" as an intensifier** appears constantly: - "structured specifications are created before any code is written. That's the definition of really the specs" - "it works really, really well with large language models" - "it does a pretty good job" / "which is really nice" / "I really think MCP is still maturing" - **"Kind of / sort of" hedges**: - "sort of like AI interns," "kind of like that Goldilocks zone," "kind of a manual way" - **Direct audience address** — "you guys," "if you're trying this at home," "I highly recommend" - **"So, ..." as a transition opener** — begins many segments: "So, let me give you a little bit of a history lesson," "So, let me show you a quick demo." ## Teaching Habits & Structure - **Question-driven framing**: Explicitly poses audience questions then answers them: - "A question I sometimes get is why?" - "Can't the latest frontier models just do everything for us already?" - "Isn't MCP 6 months old and it's dead now?" - **Extended analogy**: Compares LLMs to eager interns via a personal anecdote about a VP with "random ideas off the top of his head." - **Numbered/sequential walkthrough**: Requirements → design document → implementation tasks, repeated consistently ("First is the user requirements... Then you tell the assistant to create the design document... then you have it create the implementation details"). - **Practical quick tips embedded mid-explanation**: > "Quick tip here, once it creates this task list, I tell it, 'Please take the top four tasks, put them at the top, and create an MVP for me first.'" - **Anticipates audience skepticism**: "You're probably thinking is this spec only good for greenfield brand new projects? And I would say absolutely not." ## Vocabulary - Technical terms introduced with plain glosses: "Skills are like instruction files," "property-based tests in them, which are tests that are against the requirements document." - Informal industry slang: "vibe coding," "go off the rails," "Goldilocks zone," "give it a whirl," "human in the loop." ## Communication Patterns - **Reassurance of vendor neutrality**: "I don't want this to be a half-hour pitch for Kiro. You can do this process spec-driven development without Kiro." - **Calls to action clustered at the end and mid-talk**: kiro.dev, Discord, LinkedIn, Blue Sky, X. - **Emphasis on human accountability**: "You need to be the code reviewer of all the code... you are the person that are going to be blamed for it, not the agent." ## Stable Patterns vs. Isolated Moments - **Stable (well-supported by repetition)**: intensifier "really," question-then-answer structure, casual tone, safety/human-in-the-loop caveats. - **Isolated / lower confidence**: The intern anecdote and "Goldilocks zone" metaphor each appear once — memorable but not recurring habits. The "no pun intended with the prompting" aside is a single occurrence; no broader humor pattern can be confirmed from this transcript. # Observation Document: Spec-Driven Development for Production Workflows — Erik Hanchett (AWS) ## Speaker Identification - **Erik Hanchett**, self-identified: Senior Developer Advocate at AWS, 15+ years of software development experience. All claims below are his. ## Core Definition - **Spec-driven development**: structured specifications are created *before* any code is written — markdown files containing specifications and design documents. - He claims it pairs "really, really well" with large language models and coding assistants. ## Stated Rationale ("Why?") - He likens coding assistants/LLMs to **"AI interns"**: they need prompting and guidance, and "if you give them just a little bit of leeway, they will go off the rails." - **Analogy from his career**: as an intern, a VP's off-the-cuff ideas would cause him to drop everything; he learned to write requests down and check with his manager first. He frames LLMs as similarly "too eager." - **On "can't frontier models do everything?"**: He concedes models improve "sometimes incrementally, sometimes by leaps and bounds," but maintains they're "still not perfect" and benefit from more context, especially given changing software, requirements, and paradigms. Some harnesses add planning modes, but he argues "there's nothing better" than human-reviewed documents between planning and code generation. ## Cautions and Qualifications Hanchett explicitly frames these as **his opinions** and invites disagreement via LinkedIn. - **Context management**: agent/`agents.md`/`claude.md` files should be neither too sparse nor overloaded — a "**Goldilocks zone**." - **Skills**: instruction files for coding agents, triggered by keywords or slash commands; useful alongside spec-driven development for design docs and task implementation. - **Human in the loop**: the developer must review all generated code and the requirements/design documents, because "if something goes wrong, you are the person that are going to be blamed for it, not the agent." He clarifies this doesn't exclude tools or multiple reviewers — normal AI review tools on pull requests are fine. - **Review for inconsistencies, hallucinations, and errors** in generated markdown. - **Manual intervention point**: after design-doc generation, he "highly" recommends editing with your own "knowledge and expertise and taste" — output "is only as good as what you put in." ## Kiro (AWS Product) — History and Claims - AWS observed customers vibe coding without desired outputs; customers were using a "bespoke pattern" of having agents create requirements and design documents. AWS built **Kiro** around this, released GA "early late last year" (transcript retains the verbal stumble). - Kiro is an AI IDE coding assistant plus a CLI; he observes usage is shifting toward CLIs. - Features: **vibe mode and spec mode**, spec mode for bug fixes, clarifying Q&A before generating requirements, a "quick plan mode," and EARS-format requirements documents. - Adoption claims: launch "went a little bit viral," "tens of thousands of downloads," preview demand required a gate, which people circumvented; now publicly available. - **Qualification**: "I don't want this to be a half-hour pitch for Kiro" — the process works without it. ## Alternatives Mentioned - **Manual workflow** with any assistant: generate user requirements → review → generate design document → review → generate implementation task list. - **Spec It**: GitHub's open-source version of this process, installable across coding assistants. ## Scope Claims - Spec-driven development is **not** limited to greenfield: he has seen existing apps "years old" with dozens of spec files. - Best suited for **in-depth features, complex projects, structured building**; smaller items may be better vibe-coded (his stated preference). ## Workflow Tips (Stated by Hanchett) - **MVP-first trick**: after the task list is generated, ask the assistant to take the top four tasks and build an MVP first so you "can actually see it working." - **Property-based tests**: tests run against the requirements and design documents (fast-check in TypeScript/Node in his demo), running "dozens if not hundreds of times with different values." ## On MCP (Model Context Protocol) - Describes it briefly as a protocol connecting model providers to data sources. - **Acknowledged skepticism**: "Isn't MCP 6 months old and it's dead now?" — he notes some internet commentators argue command-line tools suffice. - **His position**: MCP is "still maturing" with "a long road ahead," especially on security; keep watching it. Main value for spec-driven development: pulling tickets and PM-authored requirements (e.g., from Jira or Asana) into spec generation. Steering files can instruct the agent to pull from specific MCP servers. ## Demo Summary - Movie-database example in Kiro IDE spec mode, greenfield project ("movie website"), started with design document (his choice), including mermaid and sequence diagrams; then EARS-format requirements; then revised task list with an MVP covering tasks 1–4 (browsable movie grid, search, genre filtering, sorting, "80s synthwave theme"). He implemented all tasks after that. ## Closing Calls to Action - kiro.dev, discord.gg/kiro.dev, LinkedIn (Eric Hanchett), Blue Sky (Eric C H), X. # Video Attribution & Provenance Record ## Video Metadata - **Title:** Using Spec-Driven Development for Production Workflows – Erik Hanchett, AWS - **Video ID:** `01a15ca8-e1ca-7d09-be5f-8229f09126e4` - **Curated metadata:** None supplied beyond title; no comment availability information provided. ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | Erik Hanchett (transcribed as "Eric Hanchett") | **Creator / sole presenter** | Self-introduced: *"My name is Eric Hanchett. I'm a senior developer advocate at AWS. I have over 15-plus years of software development experience."* | - **Guests:** None. - **Narrator:** None; Hanchett is the only voice throughout. - **Other roles referenced (not speaking):** a VP and a boss from Hanchett's past internship anecdote; unnamed product managers and AWS customers/customers' teams mentioned in aggregate. ## Promotional Segments (Flagged) - **Kiro promotion:** Extended segment describing AWS's Kiro AI IDE/CLI — *"we're really proud of it"* — release history, download counts, and kiro.dev availability. Presenter explicitly mitigates: *"I don't want this to be a half-hour pitch for Kiro."* - **Call-to-action closing:** kiro.dev, Discord (discord.gg/kiro.dev), LinkedIn, Blue Sky ("Eric C H"), and X. - **Kiro demo:** Walkthrough of Kiro spec mode on a movie database project (design doc, requirements, MVP task list, property-based tests). ## Referenced Sources & Third-Party Tools/Claims - **Spec It** — described as *"GitHub's open source way of doing this process"* (shout-out). - **MCP (Model Context Protocol)** — described by presenter; third-party internet claims cited and paraphrased: *"Isn't MCP 6 months old and it's dead now?"* and *"some people were saying that... you can do a lot of stuff with MCP just with command line tools."* Presenter attributes these to unnamed internet commenters. - **Project management services:** Jira, Asana mentioned as data sources for MCP integration. - **Tools/frameworks mentioned:** fast-check (property-based testing, TypeScript/Node), agents.md / claude.md / steering docs, EARS format, Mermaid diagrams, model providers OpenAI and Anthropic. - **Personal anecdote:** Hanchett's internship story — first-party experience, no external source. - **Opinions disclaimer:** Presenter explicitly states *"These are my opinions."* ## Availability & Uncertainty - **Comments:** No information on comment availability in supplied material. - **Transcript spellings uncertain:** "Eric Hanchett/Hanchett" vs. title "Erik Hanchett"; product names transcribed as "Qiro/Kara/Kira" (title/site confirm **Kiro**); "Spec It" name not independently verified. - **No timestamps, external documents, or cited publications present in the transcript.** Hey everyone, my name is Eric Hanchett, and today I want to tell you guys all about spec-driven development and how you might use it in your workflows today. So, there's a couple of things we want to talk about. First, what is spec-driven development? And then, how can it make you a better and faster coder? So, we just don't want you to code faster, but we want you to actually create higher-quality code from it. And I think really spec-driven development helps you with this, and I'm going to explain why and how. It's a structured specifications are created before any code is written. That's the definition of really the specs or the requirements of this spec-driven development, and it goes to the heart of what it is. So, what we're doing is we are writing these markdown files, we're writing the specifications and the design document before any of the code is written. And this actually works really, really well with large language models and our coding assistants that we use. And I'm going to show you exactly how that works. Now, a question I sometimes get is why? Like, why should we use this spec-driven development workflow and then how can we do it? So, to answer that why question, I kind of like to think about our coding assistants, our large language models that we're using every day as sort of like AI interns. You need to really prompt them, you really need to push them the right way, no pun intended with the prompting. So, you really need to guide them. Because if you give them just a little bit of of leeway, they will go off the rails. And really the spec-driven development helps guide them in the right direction. I remember when I was an intern in one of my first jobs, we had a VP that would walk around and he would just come up with random ideas off the top of his head. And when he told me it, I would drop everything and work on it. And then later my boss would be like, "Hey Eric, why did you drop everything?" Well, the the VP said something. And then I learned about, well, you got to take his information that he gives you, write it down, put it in your schedule, talk to me talk to my manager about it. So, I was a little too eager. And this is what AI interns or basically these large language models do nowadays. And we got to be careful about it. I didn't really give you too much of introduction, so I'll give it to you now. My name is Eric Hanchett. I'm a senior developer advocate at AWS. I have over 15-plus years of software development experience. And if you want to connect with me, you can check out LinkedIn. That's probably the best place to go. I just look for Eric Hanchett and yeah, talk to me, follow me. I'd love to talk to you more about it. Another question when I that people often ask me about spec-driven development is, "Can't the latest frontier models just do everything for us already? Why do we need this?" And while I do say that the models are getting better and better every year and and every release, sometimes incrementally, sometimes by leaps and bounds, it's still not perfect. And giving the large language model these models more context is actually really important because it does help guide it in the right direction. And with our software always changing and with the requirements always changing, and with new paradigms and shifts, you always need to kind of guide it where it needs to go. Some large language models, some harnesses are starting to think more about this and adding in a little bit more of a thinking or planning mode before it jumps into when it writes code. But there's nothing better than actually having those documents created and having you be in the middle before it jumps into the net that next part with it creating code. So, let's keep a few things in mind before we get too far. There is quite a lot of information out there. I have some opinions. These are my opinions. Uh let me know. Connect with me on LinkedIn if you agree or disagree, but I think you need to keep these in mind before using spec-driven development or vibe coding or anything in between. We have to You have to be careful with context. Now, I told you before that spec-driven development gives you a lot of context that gets fed into that large language model, but sometimes you have too much of a good thing. Uh what you need to do is when you are working with these large language models, usually you create like an agents.md or claw.md at the beginning with some information in it. I would be very careful not to put too much information or too little information in that. Kind of like that Goldilocks zone of information is what you need. So, you just need to give it enough rules and guidelines that it knows what to do. Uh we call it steering docs in Cara, which I'll mention about in a minute, but you just got to be very careful what you put in those documents. I also highly recommend when you're using spec-driven development to use skills. Skills are like instruction files that you can give to your coding agents that are ran on demand. So, usually they have keywords in them, and when the coding assistant sees those keywords, they'll activate the skill or you can do \{slash\} and the skill name and then run it. But, this actually really helps when you're doing the spec-driven development process. You can actually add skills um when it creates your design documents or whatever else. You can use those in parallel or with the spec-driven development or when you actually implement the tasks. And just be careful about giving too much trust. Uh remember everything in the spec-driven development flow is you, meaning that you are the human in the loop, so to speak. You need to be the code reviewer of all the code that's generated through this process. You need to be interactively looking at the design documents and the requirements documents that are created because at the end of the day, if something goes wrong, you are the person that are going to be blamed for it, not the agent. And uh that's not to say that we don't use tools to help do code reviews. Someone once told me like, are you saying you're the human in the loop, you do the code review, no one else? Of course, we might have multiple be doing people doing code reviews and definitely use your normal AI coding assistants and and review tools to help you review any pull request that you create. Or CRs. So, let me give you a little bit of a history lesson of where we have been, especially at AWS. We uh saw this need, especially from our teams and our customers, that they were vibe coding, they were using this coding assistance, but they weren't getting the outputs that they wanted. And what we saw is this these customers were using this bespoke pattern of having the agents, the coding assistants, create uh these full down requirements documents and these design documents and we decided to create a application to kind of do this all for them. So, we released Qiro uh early late last year in a general availability. It's our new AI IDE coding assistant. We also have a command line interface or CLI version, which is just as popular. I think right now it's switching. Most people are starting to use CLIs more often than IDEs. So, if you like to do that, you can use the CLI. But, what we really focused in on with Qiro is, you can see in these screenshots, is this vibe and spec mode. So, we're going to jump into spec mode in a little bit, but we really thought this really encompass what we were hearing from our customers, what people wanted more ways to work with larger features and more complex projects and they really needed the coding system to know exactly what their project was doing. We also released the website at kiro.dev. Feel free to after this presentation to go check it out. You can download our CLI, our IDE, and give it a whirl cuz you know, we're really proud of it. It's fun. When we released this, it actually went a little bit viral. We got tens of thousands of downloads. A lot of people were asking us asking us about Kiro so we were really happy to to release this and we actually when we set it up in preview, we had so many downloads we had to put a gate in front of it and then people found a around the gate, but now it is publicly available for everyone to try and and and give it a shot. But I don't want this to be a half-hour pitch for Kiro. You can do this process spec-driven development without Kiro and there's a few few ways. One is that you basically have to just you can do this manually with anything. You could tell the your assistant, your large language model to include the following. First is the user requirements. You would tell them please based on XYZ create a whole set of user requirements. Now, you can feed it your own user requirements beforehand and say, okay, use this as a basis or you can have the editor or the AI IDE go ahead and create it for you. Then you look back and forth and make sure it's okay. Then you tell the assistant to create the design document. Then you look back at that and then you have it create the implementation details. These are the the tasks list, the tasks one by one to actually implement it based on the requirements and the design document you created. So you could do this kind of a manual way if you like. I'll give a shout-out to Spec It. This is GitHub's open source way of doing this process. You can install it in a variety of different coding assistants. Now, in Kiro, you have this lab This is the IDE version. We have plan mode inside the CLI if you prefer the CLI, but in the IDE you would choose spec. And then you would go ahead and give it a prompt. So, in this case I could say like build a movie MCP server to keep track of movies I've watched or build an a movie website, whatever you want. Now, you're probably thinking is this spec only good for greenfield brand new projects? And I would say absolutely not. I've seen existing apps that are years old have dozens and dozens of these different spec files in them. And this example, it's kind of more of a greenfield, but you can definitely use it for existing legacy projects as well. It thinks it works very well. And I would just say that these are really good for when you're doing in-depth features, when you need your project needs a little more upfront planning, uh and you just want to build things in a structured way. For definitely works really well with complex projects. We actually added a spec mode for bug fixes, too. So, you can use it for smaller things, though you may want to just kind of vibe code those things instead. Here's what our requirements document looks like. So, in the first part it creates this uh requirements phase where it's in this ears format and it gives you the introduction, like the requirements, the user stories. Uh we also have a process where it asks you questions beforehand. And so, we added in some extra question and answer. So, as you put your prompt in, it'll ask you some clarifying questions before it creates this requirements phase. You can also do this quick plan mode we just added, which uh will go ahead and just generate all these documents quickly for you based on the questions and answers you give. So, there's a lot of different ways you can do this. Then you'll create a design document, which is a higher-level design document. You can also start with the design document first. Some people kind of take this design and requirements, combine them. But typically with with our spec-driven development flow, you can either start one or the other. And then you might have mermaid diagrams here, ASCII art with all the information. Now, this is at the point I would highly recommend, if you're trying this at home, to stop and go in and update it with your knowledge and expertise and taste to exactly what you're looking for. Because it's only as good as what you put in. But you'll find out that it even with a smaller prompt it and with the clarifying questions, it does a pretty good job. And course you always want to review it for markdown the markdown files for inconsistencies, hallucinations, and errors. And then finally you get to the implementation phase. This will be a list of tasks. Uh it also has something called property-based tests in them, which are tests that are against the requirements document and design document. You can additionally have those created and ran. I would highly recommend it, so that way it makes sure that the the tasks actually are implemented correctly. I usually also, uh quick tip here, once it creates this task list, I tell it, "Please take the top four tasks, put them at the top, and create an MVP for me first." So that way I can actually see it working. And then I'll implement them I'll implement the MVP version first. Now, I love model context protocol. I'm not going to go into exactly all the details of it, but it's a way essentially for your model providers to connect to different data sources. So, in this case, I'm using Kiro, and maybe I'm using like OpenAI or Anthropic, and we want to connect to different data sources. So, we have this MCP protocol in the middle, and it connects everything together for us, which is awesome. Now, I get this question, "Isn't MCP 6 months old and it's dead now?" Now, a lot of people on the internet have opinions that change every other day, and some people were saying that, well, you can do a lot of stuff with MCP just with command line tools. I really think MCP is still maturing. There's a lot uh a long road ahead for it, especially with some of the security stuff it's doing. I would keep an eye out for MCP, but one of the main reasons I like it, especially for the Spec Driven Development Flow, is you can have something like in Jira or Asana, all your tickets, all your uh large requirements docs, and then you can have it being pulled into your Spec Driven Development Flow when it creates your specs, which makes it much easier to work with. So, if you have a product manager that has actually written a requirements document, you can pull that in. And uh it just makes a little bit easier. And I'm I'm talking about any any kind of project management service. And grab technical details for it. You can also put additional rules in your steering or your agents.md files that tells it, so if you're using Spec Driven Development Flow, make sure you grab the information out of this MCP server. And that way it knows where to look. Or you can just specify it in the first step, like, "Hey, look at this MCP server when you create the requirements." So, let me show you a quick demo. This is the latest version of Kiro, the IDE version. And let me give you a a quick show of it. Now, just for the sake of time, I don't have time to actually go in and create a brand new project from scratch, but I used this one. It's a movie database. So, this is more of a green field, brand new project, but I think you'll still get the idea. I was in the spec mode here. I said, "Please create me a movie website." So, what it did is it started with this design document. And this case In this case, I actually told it to start with design instead of requirements. And then this shows the actual preview of the markdown file. So you can see it created a bunch of different mermaid diagrams that show the architecture of it. Gives you sequence diagrams. And so I went back and forth with this and updated and edited and it created this all for me. If I scroll down to the bottom of this document it created, you can see here it created a bunch of property test tests. And these are really special tests. It uses fast check in this TypeScript in the node world to do these tests which actually run dozens if not hundreds of times with different values to make sure that it's uh these requirements are satisfied correctly, which is really nice. And then it created this requirements document in once again this EARS format, so it's really uh very simple with these user stories, requirements. Uh let me see if I can open it up again. Here's it in preview. Uh so here's the requirements document. Requirements one, movie data loading. When the application initialize, the filter engine shall load. So it kind of gives you step-by-step exactly what's uh what it's doing here. And then when I went back and forth with this, I got to the task list and I asked it, "Hey, in the task list, can we create like an MVP?" So it went ahead and updated the task list and even says right here, "Task one through four deliver a working MVP, browsable movie grid with search, genre filtering, sorting, and the full 80s synthwave theme." So it actually redid all the requirements and to get this uh basically MVP up and running out of the door, which I really enjoyed. I went ahead and just implemented all of them after that, but you could see how it works. You can also see it created this property paste based tests, which are nice which I can go back in and take a look at the execution. You can also, let me see if I scroll to the bottom here. Here it is. So if I just kind of hover, it shows like a little bit of information about the property-based test. Like with property test test for genre filtering for any movie data set and if the extracted genre list must contain exactly a sorted set of unique genre. So, it tells me exactly what it did at this point. So, if you want to learn more, you can go to kiro.dev or you can join our Discord at discord.gg/kiro.dev. I highly recommend everyone watching check it out and make sure you connect with me on LinkedIn at Eric Hanchett. Love to just connect with as many people as I can and also on Blue Sky at Eric C H or X. Thanks.