BONUS: Jamie's Appearance on Coder Radio 640 - GitHub's Spec-Kit

Hello, hello, hello, and welcome to Coder Radio. Today I’m speaking with Jamie Taylor, who is of course the host of the Modern .NET podcast, among other things. A pretty big .NET guy. Loves some C#. It’s a great conversation. We jump around. It’s less .NET focused than you think, a lot on Spec Kit, which is something I was very unaware of but has been released by GitHub as part of their frankly large and somewhat confusing array of developer tools powered by AI.

Yeah, it’s great chat. We also accidentally stumble upon—I think it’s called Moltbot now, but it was called Clawdbot when we recorded it—which subsequently in the forty-eight to seventy-two hours since the recording has just blown up all over Twitter and Reddit. It’s the host-it-yourself AI. It’s pretty cool. I’m actually going to be doing a tutorial on getting that set up on a home Linux server and possibly a Mac Mini. So fun stuff to look forward to.

All right. As always, check out Alice.dev if you need any data work or development work done. Here’s the show.

Alright, I’ve got Jamie Taylor of the Modern .NET Podcast, and I believe a Microsoft MVP. Am I correct?

That is correct. That is correct, Michael. Thank you ever so much for having me. I just want to say real quick before we do anything: First time, long time, right? I’ve been listening to the show since the beginning. Well, maybe not the beginning-beginning, but all the way back when it was Jupiter Broadcasting and stuff. So big fan of you, big fan of the show as well.

Awesome, I appreciate it. But I was listening to your show when it was called—I think—the .NET Core podcast. Thank you very much. Back in the ancient times, right?

Yeah, in the before times.

So I understand you’re here to take me to school today. We were chatting in the Discord—which folks, you should join the Discord—about something called Spec Kit, which went right over my head. So what the hell is that?

Yeah, so first thing we need to say is—obviously in computer science, naming things is one of the difficult things to do, right? So there’s loads of different things called Spec Kit. But I’m hoping that we can talk about something very specific today: a GitHub release. It’s on GitHub. If you go to github.com/github/spec-kit, the idea is it’s a specification-driven toolkit for whichever AI agent you want to involve.

Obviously it’s a GitHub project, so they probably want you to use Copilot, but I don’t use Copilot, so I can’t really say how good it is. But the idea is you open Spec Kit in a directory with your code and you say, "Hey agent, we’re gonna work on some stuff, but I’m gonna provide you with the specification and a plan and a bunch of tasks, and then you’re going to do it."

The idea is it’s back and forth, building up a very detailed plan of what you want to do, rather than going "Hey AI, build me the thing." It’s like "Here’s all of the information you need and maybe some research stuff. Now go build it." Which sounds like a really big lofty task, but actually Spec Kit helps you to do that. If there are gaps in what you’re telling the LLM, it says "Hey, go to Google or your search engine of choice, or look in the code and fill in the gaps of knowledge and tell the user what you’ve found, right?"

Found," right? Interesting. So is it almost like you’re developing a project plan up front and then feeding that in, or is it conversational?

So it’s a bit of both. The idea is that we live in a world where the code is king and the specification is this woolly thing that somebody else writes. Maybe a business person, maybe a BA, maybe a project manager—someone who probably doesn’t know much about the technology you’re going to implement. That’s a good thing and a bad thing, right?

We always want to try and delay the technology decisions until the last minute because then that gives us more options to play with. So in that respect, having someone who isn’t technical, who isn’t an engineer, having them write the spec makes that easier because they don’t know what an ORM is or what programming languages you’re going to use, right? So you get to make that decision.

We’ve done that for a very long time where we’ll write a spec and then we’ll build the feature. Well, this is actually flipping it on its head. What you want to do is you want to keep the specification in source code because then you can see where you’ve come from. So rather than having your JIRA tickets or your Trello tickets or whatever separate, you keep it all in-house in the codebase, and then you can see how we got to where we are.

Every time you build a feature, there’s a bunch of files that you create with Spec Kit that outline how that feature is meant to be built. Then you finish that feature, merge back to main and carry on with your life. Make another feature, merge back to main, and then there’s this record of who built what and when and what the decisions were. Almost like having an ADR—an architecture design record.

The idea is you’re working with the LLM to help you write those, and then you say to the LLM, "I’m happy with that. Now either you can go write the code or I’ll go write the code, or we’ll write the code together, or maybe I’ll spawn 12 of you to write a whole bunch of code and I’ll write some code." Then eventually we’ll come back together and we’ll have the feature written, right? Like I said, it gives you better results than just going "Hey AI, write me the thing," right?

Right, right. So you mentioned you can pick any—so it supports all the Claudes, the ChatGPTs of the world, most of the big boys, right?

Yep, that’s right.

I could totally see going greenfield with this and saying, "Okay, I want to build—I don’t know, I’m out of ideas today—let’s say a to-do list app," because that’s what you do when you’re building things. I guess the first thing everybody builds is a to-do list. I could totally see setting it up with Spec Kit, Spec Kit init, I’m on my way. What if you have an existing project, which I think most of us do, right? Brownfield, enterprise-y. Where does Spec Kit come in there?

Okay. So here’s my workflow, right? I realise we’re going elbow deep straight away, but yeah, why not?

Right. So I’ve got a pre-existing project. Maybe I’ve been brought onto a project, or maybe it’s something I’ve been working on for ages and I’ve just left to the wayside for a little while. First thing I’m gonna do—before I even involve Spec Kit—is say "Hey AI helper, it’s been forever since I looked at this, or I’m brand new to the team. Help me to get onboarded by going and reading through the code and give me an idea of where the different modules are." Maybe if I’m in object-oriented, maybe where all the classes are, where all the helper functions are, which libraries we’re using, what technologies we’re using. I don’t even know yet, right?

Hopefully that’s already been done because we’re in that world now. So hopefully someone on the team’s already done that and they’re keeping that up to date. But if not, "Hey AI"—I’m using Claude, so "Hey Claude, go deep dive into the code and give me some documentation to get me started."

From there I can say, "Okay, cool. Now we’ve got Spec Kit there." Spec Kit init, which just basically says “Go create a bunch of folders in my project that are specific to the LLM that I use.” So I’m using Claude Code; you may be using Copilot, or you might be using Qwen3 or Windsurf or any of the other supported AI systems. And what it will do is it’ll dump a bunch of script files in there.

This is where it gets a bit confusing because I said script files—some of them are PowerShell. You can have them in PowerShell or Bash, and then there are Markdown files that sit with it. So for instance, with Claude you can have slash commands. You can put forward slash and then the name of something, and if there is a Markdown file, it will read through the Markdown file and process that.

These work a little bit different. There’s a Markdown file that links to a shell script or a PowerShell script. Those PowerShell scripts have helper functions. Maybe every so often it needs to clear the context, or maybe it needs to read something from the user, so it sets up a whole bunch of stuff about how it should behave as well as telling the LLM, "Okay, so the user is about to give you a specification for a thing. Be ready. Be ready to create a git branch if there isn’t one, and get ready to make sure we’re on main and we’ve pulled recently so that when you create the branch, you’re not creating it from an old version of main," right? So there’s a whole bunch of setup for it.

If I’m brownfield, what I’m gonna do is I’m gonna install—in inverted commas—Spec Kit and init it. Then I’m gonna say "Hey Spec Kit, first thing I’m gonna do is go create a constitution," right? The constitution is this Markdown file that sets up all of the different coding standards for the particular project we’re looking at. So it might set up things like "Oh, we use a linter, use this particular .editorconfig, or test-driven development." So I’m from .NET C# land, so it might say "Make sure that you do dotnet format," which is like linting but not a hundred percent.

Right, like a RuboCop or a Flake8 thing.

Yeah, exactly, right? Setting up the rules of how the code should be written. Then setting up things like: if you are doing test-driven development, this much code coverage is a bare minimum. Or maybe first-party packages first, then widely supported third-party packages, and then maybe experimental ones if there isn’t something that supports what we want to do.

So the first thing it does is it sets that up, and then that way, regardless of what you ask your LLM to write, it will always look at that first and say, "Am I about to write something that’s insecure, that violates the constitution?" So you’ve got that operating environment already.

Because these are Markdown files, you can jump in and edit them as you go, or you can gently nudge the LLM as it’s writing them and say, "Actually, yeah, that’s great, but maybe I care about—because maybe this is a web app—maybe I care about what OWASP have to say. So go find the rules that OWASP recommend for this type of application development." Then it’ll grab those, put that in the constitution, and then that way you’ll be protected against things like SQL injection and cross-site scripting and all of these wonderful things that you no longer have to worry about, because all the code that you’re gonna write with this LLM is already protected against.

So that’s the first thing it does. Yeah, you do spec first. That’s specification, and you say, "Here’s the spec." I’m thinking project manager/BA level: "This is what we want—a feature that allows the customer to check out." We’re not talking about technology, we’re not talking about the hows, we’re not talking about the whys, we’re talking about the whats. You can be as detailed as you can or just say "Build me a checkout system," whatever, right?

I like to put—and this is gonna scare some folks because some folks don’t like lots of typing of words, they like to jump in with the code—but I like to put in as much detail as I can. So I’ll probably do three or four paragraphs of "This is my specification for this one feature." I’ll go ahead and hit return. What happens then is Spec Kit goes, "Cool, that’s awesome. Hey LLM, the user has given you this specification. I want you to read through it, split it into actual specifications, or split it into user stories and functional requirements and things like what was the user not clear about."

So it automatically starts asking you questions about "Well, you said a checkout system and I can’t see that there is a store in this app. Are you sure that you want a checkout system for this web API? I think you’ve got this project the wrong way around." So it starts to ask you these questions about what you want, what technologies you want, all this stuff. Then all the way through that, you can gently nudge the LLM in different directions. I am talking lots, so please interrupt me.

I just want to clarify something. So is Spec Kit basically—I mean this is a wild simplification, but it’s almost like guardrails and a go-between between you and the LLM, right? So instead of opening Claude CLI or whatever and saying "Build me a"—like you said—"checkout page, I don’t know, a Paddle or Stripe or something like that," Spec Kit says "In my constitution, we always use Ruby, we always use Stripe." I’m just making this up, right? "This is our RuboCop file. You must follow these rules as defined in this file. We never, ever, ever want to write inline raw SQL," right? Because that’s an attack vector in Rails.

Someone’s gonna correct me and say there’s ways to do it safely. I know, but I’m trying to give a simple case, right? So a common thing—I use Warp a lot—and a common thing will be I’ll be like "I want to copy these files from this server to that server," blah blah blah, right? I use it for a lot of DevOps stuff. I’ve learned that the trick is to always—because I use Claude underneath—always ask it "Do you understand what I actually mean? Do you have any questions?" Right, just like you would with an intern, right, or a super junior developer.

Is Spec Kit doing that? Because it sounds like it is. It sounds like you write the constitution, and if let’s say Claude or whatever comes back with "Well, I’m gonna do it like this," Spec Kit would actually—before even talking to you, it seems like—say "No, that violates this rule. You must pass whatever this .NET validator is, or you must use libraries only." I’m assuming you could say all things, right? Like "I only want to use NuGet packages published by Microsoft," theoretically, if you had, right? Is it doing that proactively or is that still something you have to intervene?

So what it’s doing is it’s putting your LLM agent/assistant/whatever in that mode already. It’s telling it what the rules are so that when it goes away and generates that code, it already knows "I’m not allowed to use—for instance, I’m only allowed to use Microsoft NuGet packages," or "I’m only allowed to use these particular things that are available in my Ruby environment," and maybe "I’m not allowed to use this coding or that coding," right?

I’m trying to think of things that are abstract enough that probably apply to lots of different languages rather than just .NET things, because then only I understand.

How about "Where applicable, always use the ORM," right? Yeah, exactly. But okay, so just to really hammer down on this point: it’s not that it’s a middleman, it’s that it’s actually seeding the context. When necessary, when the context has to be cleared, it’s re-updating the context to the current state with the current rules based on your initial creation of the spec per feature. I know that sounded very persnickety, but—