1 00:00:00,110 --> 00:00:01,980 Welcome to the architecture Corner. 2 00:00:02,110 --> 00:00:04,980 You know, if you feel like we've been stuck in a bit of an AI 3 00:00:04,990 --> 00:00:07,720 Groundhog Day lately, well, you're probably right. 4 00:00:07,770 --> 00:00:09,440 It does feel that way sometimes, doesn't. 5 00:00:09,450 --> 00:00:12,640 It yeah, it's late 2025, investments are still pouring 6 00:00:12,650 --> 00:00:14,580 into AI development huge amounts. 7 00:00:14,590 --> 00:00:19,080 But thankfully the conversation, at least professionally, seems 8 00:00:19,090 --> 00:00:22,600 to be moving past that whole developers are obsolete phase. 9 00:00:22,610 --> 00:00:24,840 Oh thank goodness, that was getting tiresome. 10 00:00:25,030 --> 00:00:28,590 It feels like we're finally shifting out of that Wild West 11 00:00:28,600 --> 00:00:32,210 phase of just pure generative AI, right? 12 00:00:32,299 --> 00:00:35,150 And into something a bit more structured because let's face 13 00:00:35,160 --> 00:00:38,310 it, vibe coding, you know, type of prompt. 14 00:00:38,500 --> 00:00:40,150 Hope for a miracle. App, huh? 15 00:00:40,160 --> 00:00:42,410 Yeah, the miracle. App, It all just creates a mess, 16 00:00:42,420 --> 00:00:44,430 right? Yeah, unmaintainable technical 17 00:00:44,440 --> 00:00:46,060 debt. The industry is starting to get 18 00:00:46,070 --> 00:00:48,810 that speed is kind of useless if you don't have governance. 19 00:00:49,240 --> 00:00:52,420 So structure is the keyword and the technical term we're hearing 20 00:00:52,430 --> 00:00:55,550 more about is specification driven development or SD 21 00:00:55,840 --> 00:00:57,720 requirements driven development. Same idea. 22 00:00:57,780 --> 00:00:59,630 Exactly. When you look at the landscape 23 00:00:59,640 --> 00:01:02,750 now, you've basically got those like prompt to full app systems. 24 00:01:02,760 --> 00:01:04,569 You mentioned the Vibe coding camp. 25 00:01:05,379 --> 00:01:08,230 And then you have the more traditional AI assisted tools, 26 00:01:08,240 --> 00:01:12,890 think copilot cursor things living in your IDE helping out 27 00:01:12,950 --> 00:01:16,570 right the assistance. And the big problem historically 28 00:01:16,780 --> 00:01:19,830 was how do you govern those assistance if you wanted them to 29 00:01:19,840 --> 00:01:22,350 follow your specific rules, maybe use PostgreSQL, Stick to 30 00:01:22,360 --> 00:01:25,250 certain security standards. You ended up building these 31 00:01:25,260 --> 00:01:27,180 enormous custom instruction. Files. 32 00:01:27,190 --> 00:01:29,480 Oh yeah, the massive prompt engineering headache. 33 00:01:29,490 --> 00:01:32,340 Exactly, and they were a nightmare to maintain. 34 00:01:32,690 --> 00:01:35,540 SD flips that script. It aims to make the 35 00:01:35,550 --> 00:01:38,760 specification, the requirements, the rules of first class 36 00:01:38,770 --> 00:01:41,640 citizen, something you actually maintain as part of the whole 37 00:01:41,650 --> 00:01:43,740 development process. OK, that sets the stage 38 00:01:43,750 --> 00:01:45,100 perfectly for what we want to do. 39 00:01:45,110 --> 00:01:46,960 Today we're going to do a deep dive into. 40 00:01:46,970 --> 00:01:50,880 Spicket, spicket. Yeah, it's a newer open source 41 00:01:50,890 --> 00:01:53,980 player specifically designed for this SDK approach. 42 00:01:54,050 --> 00:01:57,340 We really need to unpack how it works, what it actually delivers 43 00:01:57,410 --> 00:02:00,130 and, importantly, what the early reviews are saying about its 44 00:02:00,140 --> 00:02:02,200 strengths and maybe its weaknesses. 45 00:02:02,420 --> 00:02:04,770 And what's really interesting about Secret, I think is how it 46 00:02:04,780 --> 00:02:06,860 does this. You might remember some early 47 00:02:06,870 --> 00:02:10,500 proprietary tools like Hero. They often followed a similar 48 00:02:10,789 --> 00:02:12,880 requirements design implementation flow. 49 00:02:12,950 --> 00:02:15,180 Right, but they often locked you into their ecosystem. 50 00:02:15,190 --> 00:02:17,480 Precisely. KIRO for example often meant 51 00:02:17,530 --> 00:02:21,550 using their specific environment or IDE fork spec. 52 00:02:21,560 --> 00:02:24,220 It takes a different path. It's basically delivered as a 53 00:02:24,230 --> 00:02:27,710 collection of open source custom prompt miles and shell scripts. 54 00:02:27,780 --> 00:02:29,210 So the lighter weight. Much. 55 00:02:29,280 --> 00:02:32,830 It essentially acts as an orchestration layer on top of 56 00:02:32,900 --> 00:02:34,680 the AI assistant you might already be using. 57 00:02:35,360 --> 00:02:37,690 It's there to enforce discipline, to provide that 58 00:02:37,700 --> 00:02:39,840 governance layer. I like that framing the 59 00:02:39,850 --> 00:02:42,610 governance layer, not the AI engine itself. 60 00:02:42,720 --> 00:02:44,090 OK, so walk us through the workflow. 61 00:02:44,100 --> 00:02:46,350 It sounds like it's a pretty specific, maybe cyclical 62 00:02:46,360 --> 00:02:48,310 process. It absolutely is cyclical. 63 00:02:48,380 --> 00:02:50,510 That's key. You expect to iterate The basic 64 00:02:50,520 --> 00:02:53,090 loop goes something like this. Create principles, they call 65 00:02:53,100 --> 00:02:56,020 this the constitution. Then define requirements, the 66 00:02:56,030 --> 00:02:58,210 specification. Then you might clarify 67 00:02:58,220 --> 00:03:01,170 ambiguities. After that, create the plan, 68 00:03:01,300 --> 00:03:05,160 generate tasks, optionally analyze consistency, and only 69 00:03:05,170 --> 00:03:09,850 then do you implement tasks. And if that analysis step finds 70 00:03:09,860 --> 00:03:13,460 something off, you just loop back, maybe to clarify, maybe 71 00:03:13,470 --> 00:03:15,280 even back to the specification stage, OK. 72 00:03:15,290 --> 00:03:18,290 That sounds thorough, maybe a bit heavy up front. 73 00:03:18,430 --> 00:03:21,420 How complex is the actual setup getting started? 74 00:03:21,430 --> 00:03:23,720 You know, surprisingly straightforward based on the 75 00:03:23,730 --> 00:03:27,040 source material. They recommend using the UV tool 76 00:03:27,050 --> 00:03:29,300 for installation, which is pretty standard now. 77 00:03:29,310 --> 00:03:32,760 OK, and here's what I think is the crucial architectural bit. 78 00:03:33,380 --> 00:03:36,340 When you initialize Spec it in your project, it sets up 79 00:03:36,350 --> 00:03:38,760 dedicated folders that are meant to be source controlled. 80 00:03:38,890 --> 00:03:42,180 You get a GitHub folder holding all the custom prompts files, 81 00:03:42,250 --> 00:03:46,800 actual markdown files like secret plan prompts, and ah OK. 82 00:03:46,810 --> 00:03:49,360 You also get a specify folder for templates, scripts and 83 00:03:49,370 --> 00:03:52,000 importantly, the artifacts that generates along the way. 84 00:03:52,190 --> 00:03:55,340 Right, so because these are just regular files marked down shell 85 00:03:55,350 --> 00:03:58,220 scripts living inside your project repo, they instantly 86 00:03:58,230 --> 00:03:59,740 become part of your source control. 87 00:03:59,790 --> 00:04:01,820 Exactly. That's a huge win for 88 00:04:01,830 --> 00:04:04,600 governance, isn't it? The whole team shares and can 89 00:04:04,610 --> 00:04:08,670 customize how the AI behaves. The team owns the AI behavior, 90 00:04:08,680 --> 00:04:10,980 not just one person fiddling with prompts. 91 00:04:11,040 --> 00:04:13,920 That's the core idea. You establish that shared 92 00:04:13,930 --> 00:04:16,490 ownership right from the start, beginning with that very first 93 00:04:16,500 --> 00:04:19,410 artifact, the Constitution. OK, let's unpack the 94 00:04:19,420 --> 00:04:21,050 Constitution. How should we think about this? 95 00:04:21,060 --> 00:04:25,390 Is it like the projects 10 commandments, the non-negotiable 96 00:04:25,460 --> 00:04:26,790 architectural? Laws. 97 00:04:26,800 --> 00:04:28,110 That's a great way to put it, yeah. 98 00:04:28,180 --> 00:04:31,830 It dictates the mandatory project wide conditions, things 99 00:04:31,840 --> 00:04:35,340 like coding standards, required frameworks or libraries, and 100 00:04:35,350 --> 00:04:37,150 crucially, architectural patterns. 101 00:04:37,160 --> 00:04:38,740 What kind of patterns are we talking? 102 00:04:38,810 --> 00:04:41,730 Yeah, well, the review we looked at mentioned a constitution that 103 00:04:41,740 --> 00:04:45,130 mandated, for example, layered architecture, specifically using 104 00:04:45,180 --> 00:04:48,190 Domain Driven Design or DDD principles. 105 00:04:48,200 --> 00:04:50,250 OK. D that's significant. 106 00:04:50,260 --> 00:04:53,190 And it also mandated Command Query separation CQRS. 107 00:04:53,200 --> 00:04:54,190 Wow. OK. 108 00:04:54,200 --> 00:04:58,090 Mandating CQRS from the start, that's a serious architectural 109 00:04:58,100 --> 00:05:00,430 commitment. That force is a really clear 110 00:05:00,440 --> 00:05:02,830 split between how you change data versus how you read. 111 00:05:02,840 --> 00:05:06,430 It it does, and it means even a junior developer guided by the 112 00:05:06,440 --> 00:05:09,530 AI assistant using these prompts has to adhere to that 113 00:05:09,660 --> 00:05:13,490 potentially complex enterprise level pattern right from the 114 00:05:13,500 --> 00:05:15,390 gecko. It guarantees a certain level 115 00:05:15,400 --> 00:05:17,270 consistency. Consistency, right? 116 00:05:17,340 --> 00:05:19,750 And what's really neat is that spec, it doesn't treat the 117 00:05:19,760 --> 00:05:22,730 Constitution as this static document you write once and 118 00:05:22,740 --> 00:05:25,490 forget it actually tracks changes to it. 119 00:05:25,560 --> 00:05:27,510 Oh yeah. It generates what they call Sync 120 00:05:27,520 --> 00:05:31,070 Impact Report. So if you decide later to add a 121 00:05:31,080 --> 00:05:34,690 new principal, say, enforce specific Jess testing standards 122 00:05:34,700 --> 00:05:38,910 for TypeScript, the report tells you how that change might impact 123 00:05:38,960 --> 00:05:40,580 other parts of the system downstream. 124 00:05:40,630 --> 00:05:44,390 So it makes architectural evolution a managed, traceable 125 00:05:44,400 --> 00:05:45,960 thing. Exactly, it's not just someone 126 00:05:45,970 --> 00:05:48,180 changing a wiki. Page OK, So once we've defined 127 00:05:48,190 --> 00:05:51,400 how we build with the Constitution, we move on to what 128 00:05:51,410 --> 00:05:53,220 we're building. That's the specification. 129 00:05:53,230 --> 00:05:56,240 Right, the specification focuses purely on the functional 130 00:05:56,250 --> 00:05:58,600 requirements. It's all about the what and the 131 00:05:58,610 --> 00:06:01,540 why of the feature, and it deliberately avoids getting into 132 00:06:01,550 --> 00:06:03,100 the how. Give me an example. 133 00:06:03,470 --> 00:06:05,810 Let's say we're building that multi user movie tracking app we 134 00:06:05,820 --> 00:06:07,860 mentioned earlier. The specification would define 135 00:06:07,870 --> 00:06:11,470 things like users must be able to add movies, or the system 136 00:06:11,480 --> 00:06:15,070 must prevent duplicate movie titles per user, or it must 137 00:06:15,080 --> 00:06:18,840 display the average user rating for each movie functional stuff. 138 00:06:18,980 --> 00:06:20,370 Got it. What it does? 139 00:06:20,380 --> 00:06:23,410 Why it does it not the implementation details yet. 140 00:06:24,040 --> 00:06:26,690 Now, before we go further, I think it's important we credit 141 00:06:26,700 --> 00:06:30,360 the author whose detailed review really guided this exploration. 142 00:06:30,370 --> 00:06:32,110 That's Mario Bittencourt. Absolutely. 143 00:06:32,120 --> 00:06:35,050 His walkthrough was incredibly helpful in understanding the 144 00:06:35,060 --> 00:06:38,010 structured flow. He really emphasized the value 145 00:06:38,020 --> 00:06:40,650 of taking the time in these early planning stages, didn't 146 00:06:40,660 --> 00:06:43,030 he? He did, and the specification 147 00:06:43,040 --> 00:06:44,470 phase is also where spec it starts. 148 00:06:44,480 --> 00:06:47,470 Doing some practical setup, it automatically creates a new git 149 00:06:47,480 --> 00:06:50,970 branch for the feature and sets UA dedicated SEC solder to hold 150 00:06:50,980 --> 00:06:53,730 all the artifacts generated for that specific feature. 151 00:06:53,780 --> 00:06:57,430 OK, the output from this stage is a pretty granular list of 152 00:06:57,440 --> 00:07:03,740 numbered requirements like FR003 system amest enforce unique 153 00:07:03,750 --> 00:07:06,790 titles, very explicit. And right after we define what 154 00:07:06,800 --> 00:07:08,530 we want, we hit the clarification step. 155 00:07:08,540 --> 00:07:10,830 This feels really important. This is where we stop the AI 156 00:07:10,840 --> 00:07:12,620 from just making wild assumptions, right? 157 00:07:12,700 --> 00:07:16,850 That's exactly its purpose. Think of it as an early quality 158 00:07:16,860 --> 00:07:20,570 gate to prevent what you might call integration debt later on. 159 00:07:21,000 --> 00:07:24,330 The clarification step scans both the Constitution and the 160 00:07:24,340 --> 00:07:27,700 specification you just created, looking for ambiguities or 161 00:07:27,710 --> 00:07:29,650 missing pieces. How does it present those? 162 00:07:29,660 --> 00:07:32,090 The author noted it usually gives you a limited list of 163 00:07:32,100 --> 00:07:36,610 questions, maybe 5 or so, often suggesting recommended options. 164 00:07:36,780 --> 00:07:39,830 It forces the human developer to make a decision and commit to a 165 00:07:39,840 --> 00:07:43,270 specific direction. Like it might ask for 166 00:07:43,280 --> 00:07:46,390 authentication. Do you prefer GitHub Oath, 167 00:07:46,440 --> 00:07:50,270 Google Oath or maybe Azure? AD exactly that kind of thing. 168 00:07:50,280 --> 00:07:52,910 If you don't answer that explicitly, the AI might just 169 00:07:52,920 --> 00:07:56,050 pick one, potentially locking you into a dependency or 170 00:07:56,060 --> 00:07:58,610 architecture that's completely wrong for your project. 171 00:07:58,680 --> 00:08:02,160 So we nail down this big decisions early, avoids costly 172 00:08:02,230 --> 00:08:03,810 rework. Correct. 173 00:08:03,920 --> 00:08:06,570 You prevent potentially catastrophic assumptions before 174 00:08:06,580 --> 00:08:09,470 they get baked in. Only once those core artifacts, 175 00:08:09,480 --> 00:08:12,750 constitution and specification are clarified and stable do you 176 00:08:12,760 --> 00:08:15,310 move to the plan phase. This is where we finally get to 177 00:08:15,320 --> 00:08:16,490 the how. The how? 178 00:08:16,500 --> 00:08:19,420 What happens here? Here, the AI takes everything 179 00:08:19,430 --> 00:08:22,270 defined so far, the rules from the constitution, the 180 00:08:22,280 --> 00:08:25,590 requirements from the specification, and synthesizes 181 00:08:25,600 --> 00:08:28,400 it all to propose a concrete implementation plan. 182 00:08:28,980 --> 00:08:31,540 Often it starts by outlining necessary research. 183 00:08:31,550 --> 00:08:32,710 And what does that plan look like? 184 00:08:32,780 --> 00:08:35,039 Is just a big text file saying do this then do. 185 00:08:35,049 --> 00:08:38,140 That oh, much more than that. This is where the structural 186 00:08:38,150 --> 00:08:41,679 detail really starts to emerge. The plan phase generates several 187 00:08:41,690 --> 00:08:44,420 key artifacts, all designed for human review. 188 00:08:44,590 --> 00:08:47,800 You typically get a data model dot MD outlining entity 189 00:08:47,810 --> 00:08:51,770 relationships like user, movie entry, rating, entities useful. 190 00:08:51,780 --> 00:08:55,840 You'll get an Openapi YAML file if it involves an API, plus 191 00:08:55,850 --> 00:08:59,530 explanatory markdown files like plan dot MD itself, maybe your 192 00:08:59,540 --> 00:09:02,740 research dot MD summarizing findings, and even a quickstart 193 00:09:02,750 --> 00:09:04,330 dot MD how to get things running. 194 00:09:04,340 --> 00:09:07,050 Wow, OK, that's quite comprehensive documentation 195 00:09:07,060 --> 00:09:09,600 generated before code. Right, all ready for inspection 196 00:09:09,610 --> 00:09:11,320 before the AI even thinks about generating. 197 00:09:11,330 --> 00:09:14,200 Code seems thorough, but then there's another optional step, 198 00:09:14,300 --> 00:09:16,510 the checklist. What's this about? 199 00:09:16,580 --> 00:09:18,480 How is it different from clarification? 200 00:09:18,520 --> 00:09:21,460 Good question. The checklist step is focused 201 00:09:21,470 --> 00:09:24,250 more on non functional requirements and quality 202 00:09:24,260 --> 00:09:27,270 attributes. Think security, user experience, 203 00:09:27,280 --> 00:09:30,590 API design best practices. But it's not just a generic 204 00:09:30,600 --> 00:09:34,470 checklist, it's customized to generate it spec. 205 00:09:34,480 --> 00:09:37,410 It first asks the user clarifying questions about the 206 00:09:37,420 --> 00:09:40,950 checklist itself, like what things like what is the security 207 00:09:40,960 --> 00:09:44,230 focus scope for this feature? Or what's the risk priority? 208 00:09:44,240 --> 00:09:47,370 Critical, high, medium? And maybe are there specific 209 00:09:47,380 --> 00:09:50,950 compliance standards we need to meet like OWASP Top 10? 210 00:09:51,390 --> 00:09:53,610 I see. So instead of just giving me a 211 00:09:53,620 --> 00:09:56,380 generic 100 point security checklist, it generates 1 212 00:09:56,390 --> 00:09:58,890 tailored to the fact that we decided this feature is critical 213 00:09:58,980 --> 00:10:01,930 and we need to ensure it covers, say, the Oauth top 10 214 00:10:01,940 --> 00:10:03,380 vulnerabilities. Exactly. 215 00:10:03,480 --> 00:10:06,940 That specificity is a major step up from just asking an LLM. 216 00:10:06,950 --> 00:10:08,980 Make this secure in a basic prompt. 217 00:10:08,990 --> 00:10:12,420 Definitely more targeted OK plan is set quality checks defined 218 00:10:12,430 --> 00:10:13,020 now? What now? 219 00:10:13,030 --> 00:10:15,280 We break it down the tasks phase. 220 00:10:15,370 --> 00:10:18,220 This takes the high level plan and decomposes it into smaller 221 00:10:18,230 --> 00:10:20,080 actionable instructions for the LLM. 222 00:10:20,390 --> 00:10:22,620 These also serve as review points for the developer. 223 00:10:22,660 --> 00:10:24,860 OK, this is where I start to get a little skeptical. 224 00:10:24,930 --> 00:10:28,920 Based on the review it mentioned the example feature generated 225 00:10:28,930 --> 00:10:33,150 205 tasks 205. Isn't that just trading the work 226 00:10:33,160 --> 00:10:36,950 of coding for the work of auditing a massive AI generated 227 00:10:37,000 --> 00:10:39,410 waterfall plan? That is the core tension, 228 00:10:39,420 --> 00:10:42,650 absolutely, and spec it seems to anticipate this, trying to 229 00:10:42,660 --> 00:10:45,990 mitigate it with the very next optional step, which is analyze. 230 00:10:46,300 --> 00:10:50,210 Yes, 205 tasks sounds like a lot, but the goal seems to be 231 00:10:50,220 --> 00:10:53,120 granularity. The tasks dot MD file it 232 00:10:53,130 --> 00:10:56,860 generates lists them out, often organized by phase or user 233 00:10:56,870 --> 00:10:59,960 story, and even tries to mark tasks that could potentially be 234 00:10:59,970 --> 00:11:02,300 run in parallel with AP. All right, let's talk about 235 00:11:02,310 --> 00:11:04,190 analyze. Why is this stuff so important, 236 00:11:04,200 --> 00:11:06,640 especially if you have that huge task list? 237 00:11:06,690 --> 00:11:09,440 This, I think is where the real power of this structured, 238 00:11:09,490 --> 00:11:11,630 specification driven approach comes through. 239 00:11:11,690 --> 00:11:14,560 The analyze step cross references everything generated 240 00:11:14,570 --> 00:11:17,580 so far, the constitution, the specification of the plan, the 241 00:11:17,590 --> 00:11:20,520 individual tasks looking for inconsistencies or divergences 242 00:11:20,530 --> 00:11:22,050 between. Them so it's checking its own 243 00:11:22,120 --> 00:11:24,260 work essentially. In a way, yes. 244 00:11:24,490 --> 00:11:27,420 It quantifies the cost of any overlooked details or 245 00:11:27,430 --> 00:11:30,840 contradictions before you commit to writing actual production 246 00:11:30,850 --> 00:11:32,560 code based on that. Plan. 247 00:11:32,570 --> 00:11:34,280 Can you give an example of what it might catch? 248 00:11:34,590 --> 00:11:36,940 Something concrete. Yeah, the source material 249 00:11:36,950 --> 00:11:38,580 highlighted some really critical issues. 250 00:11:38,590 --> 00:11:42,860 It found things that human might easily miss until much later, 251 00:11:42,930 --> 00:11:45,460 like during integration testing. For instance. 252 00:11:45,470 --> 00:11:48,520 It flagged a missing Docker Compose setup task that was 253 00:11:48,530 --> 00:11:51,900 needed early on, even though the overall plan clearly required 254 00:11:51,910 --> 00:11:53,630 containerization. Huh. 255 00:11:53,680 --> 00:11:56,230 Subtle but important. Or another one. 256 00:11:56,620 --> 00:11:59,650 It noticed that the task list failed to include logic to 257 00:11:59,660 --> 00:12:02,990 prevent deletion of platforms or tags if they were still in use, 258 00:12:03,060 --> 00:12:05,970 which directly violated A requirement probably stated way 259 00:12:05,980 --> 00:12:08,470 back in the specification or even the Constitution. 260 00:12:08,760 --> 00:12:12,100 That is impressive, catching a potential data integrity or 261 00:12:12,110 --> 00:12:14,720 business logic flaw just by analyzing the generated 262 00:12:14,730 --> 00:12:17,030 documents. That could save days, maybe 263 00:12:17,040 --> 00:12:19,150 weeks of debugging and rework later. 264 00:12:19,380 --> 00:12:20,770 That's the value proposition, right? 265 00:12:20,780 --> 00:12:24,340 Yeah, it aims to catch those high severity architectural were 266 00:12:24,350 --> 00:12:27,140 requirements violations before you even start the 267 00:12:27,150 --> 00:12:30,260 implementation phase. That alone could justify the 268 00:12:30,270 --> 00:12:32,200 structured overhead for many teams. 269 00:12:32,250 --> 00:12:35,520 It really ensures the code you do eventually generate actually 270 00:12:35,530 --> 00:12:37,090 matches the requirements you set out. 271 00:12:37,770 --> 00:12:41,780 OK, so assuming we run analyze, fix any high severity issues it 272 00:12:41,790 --> 00:12:44,740 finds, then we finally get to implementation. 273 00:12:44,790 --> 00:12:48,320 Then we get to implementation and even here spec it throws in 274 00:12:48,330 --> 00:12:51,000 one last little safety check. The final warning shirt. 275 00:12:51,050 --> 00:12:53,140 Kinda, yeah. Before it starts executing the 276 00:12:53,150 --> 00:12:56,560 tasks, it checks those quality checklists we defined earlier, 277 00:12:56,570 --> 00:12:58,440 like that customized security one. 278 00:12:58,570 --> 00:13:02,040 If any are still marked as fail, it alerts the user. 279 00:13:02,090 --> 00:13:04,590 But it lets you proceed. Yes, the human is still in 280 00:13:04,600 --> 00:13:07,150 control. You get the warning, but you can 281 00:13:07,160 --> 00:13:10,540 decide to proceed anyway. We'll pause, go back and resolve 282 00:13:10,550 --> 00:13:12,050 whatever failed the checklist. Right. 283 00:13:12,130 --> 00:13:13,780 And how does the implementation itself work? 284 00:13:13,790 --> 00:13:16,240 Does it just dump a huge amount of code on you at once? 285 00:13:16,290 --> 00:13:19,800 No, it seems more controlled. It follows the phases or user 286 00:13:19,810 --> 00:13:22,800 stories laid out in that tasks dot MD file. 287 00:13:23,840 --> 00:13:28,050 As it executes each instruction prompting the underlying LLM, it 288 00:13:28,060 --> 00:13:29,910 marks the task complete, usually with an. 289 00:13:29,920 --> 00:13:31,870 X and the developers role during this. 290 00:13:31,960 --> 00:13:33,790 You get to decide the review cadence. 291 00:13:33,860 --> 00:13:36,950 You could, in theory, let it run and accept all files 292 00:13:36,960 --> 00:13:40,140 automatically, or you could review each file 1 by 1 as it's 293 00:13:40,150 --> 00:13:42,170 generated. Or maybe you review a batch of 294 00:13:42,180 --> 00:13:44,110 files at the end of each phase or user story. 295 00:13:44,360 --> 00:13:45,750 You choose the level of scrutiny. 296 00:13:45,820 --> 00:13:49,910 OK, so we've gone through this entire pretty detailed journey, 297 00:13:49,920 --> 00:13:52,900 5 to 8 steps depending on the optionals from the high level 298 00:13:52,910 --> 00:13:56,110 constitution, all the way to implement hopefully consistent 299 00:13:56,120 --> 00:13:58,250 code. What was the bottom line for 300 00:13:58,260 --> 00:14:01,590 Mario Bittencourt's review? How viable is this in the real 301 00:14:01,600 --> 00:14:03,370 world? Well, the overall assessment was 302 00:14:03,380 --> 00:14:05,590 definitely positive. The main take away was that 303 00:14:05,600 --> 00:14:08,750 Specht successfully brings that much needed governance and 304 00:14:08,760 --> 00:14:11,190 predictability to AI assisted coding. 305 00:14:11,280 --> 00:14:14,310 The structure really pays off in 2 main ways. 306 00:14:14,840 --> 00:14:18,150 First, it delivers a working solution faster than purely 307 00:14:18,160 --> 00:14:20,290 manual coding would likely achieve. 308 00:14:20,480 --> 00:14:23,020 Second, and maybe more importantly, because of things 309 00:14:23,030 --> 00:14:25,210 like the Constitution, the resulting code was 310 00:14:25,220 --> 00:14:28,720 architecturally bound and stylistically close to what was 311 00:14:28,730 --> 00:14:32,280 desired, adhering to those DDD and CQRS patterns they mandated 312 00:14:32,290 --> 00:14:34,740 up front. So you get speed, but it's speed 313 00:14:34,750 --> 00:14:38,420 coupled with mandated quality and consistency that sounds like 314 00:14:38,430 --> 00:14:41,160 the Holy Grail. Where did this structure become 315 00:14:41,170 --> 00:14:44,860 a potential drawback or burden? The biggest caution flags was 316 00:14:44,870 --> 00:14:47,760 around scope management. If you try to use spec kit for a 317 00:14:47,770 --> 00:14:51,560 very large monolithic feature, the sheer volume of generated 318 00:14:51,570 --> 00:14:53,860 artifacts you need to review can become overwhelming. 319 00:14:53,920 --> 00:14:56,640 Ah, the review burden. Exactly. 320 00:14:56,760 --> 00:15:00,010 The author mentioned one feature generating 30 or more created or 321 00:15:00,020 --> 00:15:02,250 updated files. The planned files, the tasks 322 00:15:02,260 --> 00:15:04,530 file, the data models, and the code itself. 323 00:15:04,700 --> 00:15:06,650 Reviewing all of that effectively can be really 324 00:15:06,660 --> 00:15:08,510 challenging and frankly tiresome. 325 00:15:08,660 --> 00:15:11,870 It's almost like trying to learn a new complex domain just by 326 00:15:11,940 --> 00:15:14,970 reading a huge pile of new documentation and code dropped 327 00:15:14,980 --> 00:15:16,930 in your lap. That's the critical tradeoff 328 00:15:16,940 --> 00:15:19,870 then, isn't it? You potentially solve the AI 329 00:15:19,880 --> 00:15:23,170 generating inconsistent or architecturally unsound code 330 00:15:23,180 --> 00:15:27,240 problem, but you might introduce a new cognitive load problem for 331 00:15:27,250 --> 00:15:29,500 the human reviewer if the scope is too big. 332 00:15:30,140 --> 00:15:33,290 That nails it. If I have 30 new files to check, 333 00:15:33,440 --> 00:15:37,210 am I really in the loop or am I just becoming a post hoc auditor 334 00:15:37,220 --> 00:15:39,170 for the AI? Yeah, you're just checking the 335 00:15:39,180 --> 00:15:41,410 homework after it's all done. Right, so the clear 336 00:15:41,420 --> 00:15:45,810 recommendation for you listening seems to be use spec it or tools 337 00:15:45,820 --> 00:15:49,330 like it, but stick to smaller, more focused features or user 338 00:15:49,340 --> 00:15:52,030 stories. Use it to enforce consistency on 339 00:15:52,040 --> 00:15:55,550 manageable chunks of work. That way the human in the loop 340 00:15:55,600 --> 00:15:59,030 is genuinely reviewing and guiding as things are generated, 341 00:15:59,080 --> 00:16:01,730 not grounding in documentation. Afterwards, and if you're 342 00:16:01,740 --> 00:16:05,690 someone who really loves that freewheeling vibe coating 343 00:16:05,760 --> 00:16:07,750 approach. Then this highly structured 344 00:16:07,760 --> 00:16:11,570 multi step process might feel, well, tedious or like overkill. 345 00:16:11,640 --> 00:16:13,430 It's definitely a shift in mindset. 346 00:16:13,480 --> 00:16:16,350 So spec It represents a kind of maturing middle ground. 347 00:16:16,440 --> 00:16:19,250 It acknowledges that just prompting for speed leads to 348 00:16:19,260 --> 00:16:23,210 fragile chaos in the long run. But it demands that upfront 349 00:16:23,220 --> 00:16:26,680 investment in planning and specification in defining the 350 00:16:26,690 --> 00:16:29,790 rules. It's trading that immediate may 351 00:16:29,800 --> 00:16:34,830 be deceptive speed of generation for longer term consistency, 352 00:16:34,900 --> 00:16:37,730 maintainability and architectural integrity. 353 00:16:37,780 --> 00:16:39,920 Well put. It really feels like the 354 00:16:39,930 --> 00:16:43,710 structured future for leveraging AI assistance effectively in 355 00:16:43,720 --> 00:16:46,930 serious development, offering those quality checks and 356 00:16:46,940 --> 00:16:50,090 governance layers that pure prompt engineering just doesn't 357 00:16:50,100 --> 00:16:52,150 have. Which brings us nicely to our 358 00:16:52,160 --> 00:16:55,710 final provocative thought for you to consider for development 359 00:16:55,720 --> 00:16:58,610 teams, especially those working in complex or regulated 360 00:16:58,620 --> 00:17:01,710 industries where architectural governance and consistency 361 00:17:01,800 --> 00:17:04,400 weren't just nice to haves, but are absolutely critical. 362 00:17:04,490 --> 00:17:06,140 And we know there are many teams like that. 363 00:17:06,210 --> 00:17:09,170 For those teams looking to scale how they use AI assistance, 364 00:17:09,180 --> 00:17:10,869 doesn't this kind of specification driven 365 00:17:10,880 --> 00:17:13,650 development, maybe using open source orchestrators like Spec 366 00:17:13,660 --> 00:17:16,140 Hit start to look less like an option and more like a 367 00:17:16,150 --> 00:17:18,880 necessity? Is the discipline it imposes 368 00:17:18,890 --> 00:17:22,180 ultimately worth the quality and predictability of the output? 369 00:17:22,490 --> 00:17:25,359 Based on what we've discussed today, the early signs seem to 370 00:17:25,369 --> 00:17:29,080 point overwhelmingly towards yes, the discipline seems to pay 371 00:17:29,090 --> 00:17:30,870 off. Definitely something to think 372 00:17:30,880 --> 00:17:33,040 about now. Don't forget to check the 373 00:17:33,050 --> 00:17:35,560 description for links and more information on the sources we 374 00:17:35,570 --> 00:17:39,280 discussed today, including Mario Bettencourt's full review of 375 00:17:39,290 --> 00:17:40,460 Spec It. It's worth a read. 376 00:17:40,530 --> 00:17:43,440 And please make sure you subscribe absolutely free onto 377 00:17:43,450 --> 00:17:45,260 the Architecture Corner newsletter over at 378 00:17:45,270 --> 00:17:48,920 architecturecorner.substack.com. Thanks for joining us.