Season 3 Finale: Spec Kit, AI Workflows & the Future of Building Software

**Seamus** (1:07)
Welcome back to another episode of SEEK Bytes, the podcast for engineers by engineers.
I think I got it right that time, maybe for the first time in the entirety of the three seasons that we've been recording. My name is Seamus and I am joined by Elliott.

**Elliott** (1:20)
Hello. Also, he's lying. His name is not Seamus. It is a lie. He's been lying to us for years.

**Seamus** (1:25)
Glenn. Oh, I thought you were gonna say it. I was like, Glenn, you better edit this out.
And we're also joined by Will.i.am. Hello, hello. Today, we're going to be talking about Spec Kit. That's GitHub Spec Kit. More generally, about spec-driven development with AI. There are other options, but the one that I've spent the most time with is Spec Kit.
We've done episodes about skills and tools, and we've had this whole season of AI, but this seems to be the big thing that a lot of people are driving. It's definitely being driven pretty hard at SEEK. And so in this episode, I'm gonna share a little bit of my wisdom and my experience using this tool.

**Elliott** (2:03)
So spec-driven development. So we'd say this is S-D-D.

**Will** (2:08)
What is it? What is S-T-D? S-D-D.

**Elliott** (2:12)
No, no.

**Seamus** (2:14)
S-D-D, spec-driven development. So probably the acronym for something driven development people are familiar with would be test-driven development, right, T-D-D.

**Elliott** (2:23)
D-D-D, B-D-D, T-D-D are kind of the top two.

**Seamus** (2:25)
Behavior-driven development, test-driven development, spec-driven development. I've never done B-D-D. I've done T-D-D. I did T-D-D a lot when I first started at SEEK when I came in as a grad some eight years ago.
Slowly, like sort of dropped off doing that as like a constant practice, but continued to teach it to people. So whenever grads would join our teams or junior devs would join our teams, I would teach them T-D-D because I can see the value in the practice. But I think just as like a tangent, I think something that people struggle with with T-D-D is in a large growing code base where you don't quite understand exactly what it is you need to build. T-D-D can add a lot of friction, which I think is a good point to circle back on with Spectrum Development is, some of my findings is that it does add a lot of friction. But the trade-off, I guess, in this case is that you can move a lot faster with AI doing this stuff. The quality that it outputs is significantly higher in my experience.

**Elliott** (3:23)
What I really like about T-D-D is that because you have to really think about what you're doing ahead of time, you have to know the test that you want to write. If you don't know what test you need to write, there's two fundamental problems about the system you're working in. Either one, you don't understand the problem you're trying to solve, or two, the code is structured in a way that is not testable.

**Seamus** (3:43)
Yeah. I think that the two things you just said really hammer home why a lot of people avoid T-D-D, because they haven't spent enough time in the codebase to have a good solid understanding of the structure of the code, the components and how they hang together.
But more importantly, and I think this is the bigger one, is that a lot of codebases are not written in a really test-first way, which is where T-D-D comes in handy. I think something that I want to add for people before we start talking about spec-driven development and GitHub Spec Kit is that these are not mutually exclusive things. I use T-D-D with Spec Kit at the same time.
The reason for that is because with T-D-D, when you build your tests first, if you're following T-D-Ds like red-green repeat process, you're producing and your AI is producing the minimal amount of code to pass the test, which is something a lot of people get frustrated with when I started using AI, was AI will go off on a tangent and fix things that it wasn't meant to be fixing. It will create obscure abstractions that make the code harder to understand. And getting it to do T-D-D and spectrum development actually helps it stay on rails and kind of guide it to only make the correct change at the right time in the right place. With some exceptions, obviously, I think like any AI tool these days, you can definitely use it the wrong way and produce bad results. So, well, let's go back to what Will said originally.

**Will** (4:59)
What is it?

**Seamus** (5:00)
Yeah, what is Spec? We still haven't said what spectrum development is. So, spectrum development, spectrum development. So here's the thing. I'm not super familiar with spectrum development outside of my experience using it with Spec Kit. But after using Spec Kit, my interpretation of it would be, essentially, if you and a product manager sat down together and you worked through the user stories. So you came up with a bunch of functional requirements first. But before you even start writing code, before you even start writing a JIRA ticket, you would essentially come up with what the functional requirements are. You'd come up with the user stories from those functional requirements. And then you would probably, hopefully, do TDD or whatever to implement the user requirements and the functional requirements. And that's essentially probably what we've already been doing, right? Most of us are familiar with, we write a JIRA ticket. Hopefully, it's got a user story, it's got acceptance criteria. That is essentially spectrum development, at least as far as the parallels that I can draw between what Spec Kit produces and what we do at SEEK and what probably most companies do looks really similar. It's just that the quality and the content and the detail that is created as part of Spec Kit is much more thorough than what we tend to do day to day.