Michael Carducci Adopts OpenSpec

00:00 Michael Carducci is an old friend and a

00:02 multi-talented software engineer,

00:04 architect, speaker, communicator, writer,

00:07 with magical powers.

00:09 I'm not kidding. He is an outstanding

00:11 magician. I've seen him perform many

00:12 times and he never

00:14 ceases to blow my mind.

00:15 Today he and I didn't talk about the dark

00:17 arts, but rather OpenSpec and some

00:19 experiences he had resulting from a talk

00:22 I gave on OpenSpec at

00:23 a conference last July.

00:26 If you're new to the tool or to

00:27 spec-driven development, we don't

00:28 actually describe what it is and how it

00:30 works until around the 30-minute mark.

00:31 It takes us a little bit, but you know

00:33 what? It's a fun conversation like it

00:34 always is with Michael. Let's listen in.

00:38 Mr. Carducci, it is good to see you.

00:42 Tim, it has been too long. How the heck are you?

00:45 I am doing okay. I really am having a good time.

00:50 It is, I don't mind saying September the 24th as we record this, 2026.

00:55 Last time we saw each other was like two months

00:57 ago plus a little bit. That is, I agree, too long.

01:01 And it's good to see you. I haven't seen

01:03 this, this setup. This background looks great.

01:05 Little spooky red light back there. I feel, I

01:08 feel like I should, I should just pay heed to you.

01:13 Well, we are in the Dev Random TV studio.

01:17 There you go. Link in the show notes to Dev Random.

01:22 Indeed.

01:23 I gave a talk at UberConf in July. That's if, dear listener, if you don't know,

01:29 that has nothing to do with Uber, the ride service.

01:34 That is a talk in the No Fluff Just Stuff family of conferences.

01:38 It takes place in Westminster every summer,

01:39 Westminster, Colorado, not Westminster, London.

01:43 And I gave a talk on OpenSpec, a tool that supports

01:48 spec-driven development in the context of agentic engineering.

01:52 And you were not there, which is okay.

01:55 I was not.

01:56 No, we don't usually go to each other's talks.

01:59 We don't normally have that opportunity because

02:03 at UberConf I was speaking the entire conference.

02:07 So every slot.

02:09 Every slot. Modulo, give or take one, I think.

02:13 Sure, sure. Just for the bleeding in your

02:16 throat to stop. I am not that cool anymore.

02:18 I had opposite end of the spectrum, just that one talk.

02:23 And there was a year, I think it was 2011, where I did, I didn't do every slot.

02:28 I did all six on Wednesday. There's, again, folks, if you don't know the

02:32 conference, there are 90 minute sessions.

02:34 And on the first day of the conference, after the workshops, the first proper day,

02:38 there are six sessions that go from like 830 to 1030 at night.

02:41 It's insane. I did all six of those once. And you're just like, we used to call

02:44 this pulling a Venkat, but it's now pulling a Carducci filling every slot.

02:50 Oh my. I'm about to become whatever part of speech that is.

02:58 My brain is too tired today to figure that out because a verb?

03:03 No, it's still a noun, but I'm already a noun. You know what I mean? Yeah.

03:06 But that's okay. I've always said that I'm... Yeah.

03:09 Like Xerox.

03:11 Yeah, there you go. Xerox is a verb and a noun. But

03:14 I've always said that I'm more of a verb than a noun.

03:16 People ask me, what do you do for a living? And I don't know. I do fun and

03:22 interesting things and occasionally people pay me.

03:26 The only... which is a great way to live your life except

03:28 for the occasionally part. But, you know, we learn to adapt.

03:33 There's, you know, some ups and downs and things like that. But you do get to do

03:39 fun and interesting things and do things like give

03:41 15 talks at a conference, 15 90-minute talks, which...

03:46 Yeah, that's more like type two fun than it is. It is. Type one fun. It is. And

03:52 folks, if you don't know what type two fun

03:53 is, that's fun. That's fun after the fact.

03:56 Like... But not certainly not in the middle. Not during. And I'll usually describe

04:00 difficult outdoor experiences like getting caught in bad weather as type two fun.

04:04 Because it's miserable at the time. And afterward, like 30 minutes

04:08 after you get warm, you have become the most

04:11 awesome human being ever to exist.

04:15 And just listen to my story. I'm going to tell you how awesome I am. It becomes the

04:19 best thing ever. So yeah, yeah, that kind of that kind

04:21 of load at a conference can be that kind of thing. So...

04:26 But you gave this talk. I want to preface this though, because before we get to

04:31 this talk, I want to get to you calling me

04:33 out whether you knew it or not. Because I...

04:38 I've done that thing that a lot of people tend to do. We hear ideas, we hear words,

04:43 and we start to connect those words, these new buzzwords, these new ideas in the

04:47 industry. We connect them to the concepts we're familiar with.

04:51 Yeah, and it's very, very easy to connect all those concepts together. And then

04:55 basically quickly parse it in your mind, build a little mental model, hey, it

04:58 parses, and then it just becomes fact in our head.

05:02 I... I deride that behavior, but I am human and I also do it and I'm trying to get

05:08 better. I had heard this talk of spec driven development. And I...

05:14 let my own assumptions define it independently event everything else. I'd even

05:20 cracked a joke or two at the the expense of spec-driven development

05:24 in the context of

05:25 a larger point that I was trying to make in

05:27 a panel or in a talk or something like that.

05:30 And then you posted on LinkedIn, you said to the people who are making these kinds

05:36 of jokes, first of all, seen. Second of all, you followed it with...

05:41 Get wrecked, whoever you are. No, I don't think I said that, but...

05:44 No, I think you said, do you even lift, bro, was your exact word.

05:49 Okay, that sounds like me. Yeah.

05:52 And... and so I paused and I just sort of accepted that maybe I don't know what I

05:58 think this thing is. Yeah. And that was where it was resting. Now I sent a

06:04 colleague of mine to UberConf and he went to your session.

06:10 And then he taught me what he learned from you and

06:14 that's when everything changed. Okay. So what did you think...

06:17 But I will hand the narrative right now.

06:18 Did you think Tim is back to the 90s and functional specifications and I was

06:24 working for IBM at the time just a few months ago

06:26 you're thinking, wow, IBM has

06:27 really had its impact on him. He used to

06:30 be something and now look, I mean, was it...

06:32 I'm overselling it, but you were thinking of that kind of spec.

06:36 I...

06:38 Yeah, well, yes. And I think really what...

06:43 What I imagined when I heard the term "spec-driven development"

06:47 and I'm not afraid to

06:49 say there are a lot of things in the world that I don't understand or that I'm

06:52 wrong about because what I don't know could fill a warehouse.

06:54 But I had done some AI-assisted coding and I'd been doing some back and forth, but

07:01 I'd never really had a good repeatable, consistently useful approach.

07:08 And I could see the value of sitting down and doing the kinds of things that we

07:13 did. I'm of a certain age that I remember writing functional specifications and

07:19 technical specifications and planning out the

07:21 entire implementation before I even wrote a line of code.

07:24 And that mindset sort of fit both my experience

07:31 of working with AI to produce code,

07:34 but also this label of spec because I had this label of spec in my mind and I

07:43 associated this thing that I started doing back in the 1990s or we'll just say the

07:48 1900s because it might as well be that far away.

07:51 It is the last century and that was just sort of where I landed. So I was certainly

07:58 associating this idea of spec-driven development

08:02 as these kinds of specifications.

08:05 I wasn't really hung up on granularity, but it made intuitive sense to me because I

08:13 figured writing more and more about the implementation

08:17 in a specification that is essentially a giant prompt

08:21 was what people were talking about. Now there is a semantic diffusion

08:26 problem with spec-driven development

08:27 I'm finding out because people call a lot of things spectrum

08:31 spec-driven development and some people are even doing what I was imagining

08:36 and they're calling that spec-driven development all the way to very

08:39 opinionated, very tool driven approaches like OpenSpec.

08:44 Yeah, like the one I was advocating in that talk. And I was kind of set off by some

08:53 YouTube discourse. And that in July is the first time I'd given that talk and I

08:59 thought, you know, what are people saying about this? Maybe I should go check. I

09:04 think it's great. I've been using it. But what's going on in the world? And I saw

09:08 uninformed arguments against it that

09:11 and by the way, Michael, you...

09:14 uh, you called yourself out because you heard a thing, and you

09:18 interpreted it in terms of the mental scaffolding that you had

09:23 You don't have a choice. There are too many individual

09:25 things in the world. You have

09:27 plausibility structures and sort of a skeleton for knowledge and you get a new

09:32 thing in there and you got to put it in the skeleton somewhere until something

09:37 comes along to disrupt that you think, oh, I need to rebuild some frames. There's

09:40 nothing wrong with that. But these were guys who were

09:43 going to the trouble of making a whole YouTube video

09:45 saying, did Agile teach us nothing?

09:47 Why are we writing specs again? I thought, Okay,

09:49 that just sounds nothing like the actual practice here. So

09:54 Oh, wow. Okay, so you weren't calling me out because I made one or two...

10:00 No, I live in jokes that you were talking trash about me. If you said it on a

10:04 panel, usually I go to my happy place

10:05 during the panel, I can't hear any words. And so

10:08 So you put this your team put this practice at work. What...what was the

10:14 thing that it turned out to be that you

10:16 saw what to talk, talk to me about? Oh, okay.

10:21 essentially, like I said, I had I had somebody who was working with me on one of my

10:25 projects. And I said, I said, I'm gonna send you to UberConf, he goes, he comes

10:29 back, he says, I learned about spec-driven development. And I said, Okay, explain

10:34 this to me. So we sat down afterwards and just spent the day.

10:39 Pair, pair programming is not the right word here. But we were pair spec-driven

10:45 developing whatever that is, and just kind of walking

10:49 down and playing with it. And what I discovered is, this is

10:56 an extremely valuable workflow that may not be the optimum workflow, but it is the

11:03 that has two advantages over anything else that I personally done. Number one is I

11:09 started it gave me a very consistent repeatable process that I could follow. And

11:19 two, it gave me consistent, repeatable results. And the side effect is my

11:29 experience with the agent kept getting better. So whereas every time I would sit

11:36 down with Claude, it was like we were having the same conversations, and I was

11:40 giving it the same reminders and oh, no, no, we do these things this way. And yeah,

11:45 I've been going in there and editing things in my CLAUDE.md file.

11:49 And doing other bits and pieces, but it just...

11:53 ...always felt like we were from square one. And, and it was always felt

11:57 like this new person who was a very capable coder had just joined the team and

12:04 you're trying to catch it up on all of the things. Right, right.

12:09 But spec-driven development

12:11 has its own memory of the meta that it maintains.

12:19 Which is enormously valuable. And it does that better than what I was able to do

12:23 with like a CLAUDE.md file or a bunch of markdown files or anything else.

12:28 Because it's part of this more tool-driven, consistent approach.

12:34 And since then, I

12:36 haven't gone anywhere without it. It's like my American Express.

12:41 Nice. Before we go on, I want to say

12:46 to anyone listening who hates spec-driven development

12:48 or OpenSpec or whatever, thinks, you know, if you don't have agent

12:52 loops running, then you're missing the game. There's a lot of ideas. We don't the

12:58 practice of writing software has just radically

13:00 changed. For most of us as of about nine or 10 months ago.

13:04 And it's still radically changing.

13:06 And we don't really know what we're doing. Now, I think I'm getting great results.

13:11 A lot of people are getting fantastic results. But it's kind of a three to five,

13:17 maybe five- to ten-year kind of problem to figure out

13:21 what it is we're doing again.

13:25 It would be like the kinds...the parts of Agile that sort of filtered through

13:29 all the consultancies and processes and all that

13:33 stuff to just become accepted practice in the world.

13:37 That took 10, 15 years. For people to figure out, okay,

13:40 what's test driven development really for?

13:42 An architectural paradigm like microservices, we just sucked at those

13:45 for three to five years. I'm amazed the paradigm even survived the initial

13:50 implementations before people really figured out how to do that. So

13:54 I have a theory two things. If I if I can just drop a little bit in there, we're

13:59 here to riff. I don't I don't think most people have ever figured out

14:02 microservices. I don't think teams have ever really figured out agile. I think the

14:07 interesting thing is, is that we've always had humans in the loop doing what the

14:11 humans always do.

14:13 And, and where I think the entire calculus really changes is now

14:19 we're taking humans out of the loop. And I don't think we can really afford

14:24 to not understand these broader ideas. Yeah, but yeah, no, I've been an

14:32 architecture consultant for 15 years. And, at least, and I've never seen anybody

14:41 like personally, not yeah, we can case study this company on Netflix or somebody

14:46 like that. But personally, I've never seen

14:47 anybody doing microservices well. Actually succeeding with microservices

14:54 they are surviving with whatever they built. Fair enough, fair

14:58 enough. And, and I, I threw a bunch of things in there that are absolute catnip for

15:05 various debates. And I don't I don't mean to, if you're listening, you think I just

15:09 said something deeply foolish. Just, just give me a minute here.

15:13 Let him cook.

15:15 Let me cook. So much has been upended in the way we do

15:20 what we do, the way we create systems out of software that

15:24 we are currently casting about feeling around in the dark trying to figure out

15:28 smart ways to do things. And just like pre-AI there wasn't one methodology

15:33 There wasn't one architecture, there was this robust debate all

15:36 these it's gonna it's gonna stay that way. Okay, so

15:40 we're talking about spec-driven development, particularly OpenSpec here,

15:42 because I think it's interesting, because I like it,

15:44 you have found some some luck with it.

15:47 There are going to be other AI-assisted engineering

15:50 workflows, practices, methodologies, that will just never have anything to do with

15:56 a tool like this. And big tent, lots of room for

16:00 lots of approaches. And you know, I wouldn't mind

16:05 finding somebody who hates OpenSpec in a principled way to,

16:09 but you and I love it. So and it's less about the tool than the process. But

16:14 what I've found, let me let me just talk a little bit about what my experience has

16:19 been. And I have to be clear that this is with pretty hobby-ish projects. My work

16:27 as a developer relations leader. I do a lot of zoom calls and Slack messages and

16:34 occasionally travel places and give talks. But

16:37 I'm managing people. I'm not writing code at work.

16:41 I'm, you know, leading teams that that that write code, but I'm not. And so this is

16:45 hobby stuff. And so you know, take take with a grain of salt. I find you mentioned

16:53 it keeps the agent on track. And I'd like to dig into a little bit about how but I

16:57 thought it keeps me on track is the thing. I am working right now in this month of

17:03 September on something to replace Adobe Lightroom for myself.

17:09 I don't know how broadly useful it'll be. There's a lot of really hard problems in

17:13 there, but just sort of tired of their BS. And I think I could I could do better.

17:20 Now that we've got AI. And I kind of need to be kept on track about what I'm

17:26 working on when it's when it's as easy as prompting a new feature. I don't know

17:33 that that a random walk through the feature space of what a

17:37 Lightroom replacement might be is all that good of an idea.

17:40 And so I started with a conversation with Claude saying what I wanted to do. And,

17:46 you know, I want storage to work like this, I want import to work like this, I want

17:50 to support these formats. I want, you know, face recognition and and semantic

17:57 search of images and, you know, stuff that why do I not have these in Apple photos

18:02 or any of these things? It's it's it's crazy. I would just like these things. And

18:08 we had this this long conversation. And it gave me a markdown file of some

18:16 proposals and explorations. I'm using particular verbs related

18:20 maybe we can get into them.

18:22 And now I'm just sort of walking through that. And implementing there.

18:26 Not just saying, "Oh, hey, that's cool. But let's do this."

18:31 You know, there would be a little bit more of a meandering in my own

18:36 focused-deprived mind through the process, because I can just prompt stuff.

18:42 So I feel he keeps me on track as much as as anything.

18:45 Now, that's really interesting, because my one of one of my observations was it

18:52 allows me to go off track. Oh, tell me, can I can I can I yang your yin for a

18:58 moment? I may know what you mean, but I want to I want to hear.

19:01 So I use OpenSpec in a slightly less hobby ish context, built and maintain a sass,

19:11 which is which is good that there's a responsible professional in the

19:15 conversation here, at least one.

19:16 I have I have customers, I have SLAs, you know, paying customers

19:22 So I have to be somewhat careful.

19:25 Now, where I have been is

19:33 I'm a classically trained software engineer, right?

19:36 Well, I'm not classically trained. But whatever you want that to

19:41 mean, let's let's—I'm old school. How about that? I've been

19:44 around for a long time. I didn't start coding in the 21st century.

19:49 And so I just have a way of working and it's it's sort of a chorus of things,

19:57 right? So there's there's the ideas, the goal, the code, the architecture, the

20:02 design, the value proposition, like I'm trying to weave all these things together

20:07 in the way that I am operating the machine.

20:10 So what comes out is something valuable. And I'm usually thinking about all of

20:15 these things as I go. And usually, when I prompt an agent, it will think about the

20:25 code, none of the other things, it won't

20:27 think about anything else, unless you talk to it.

20:30 So I, I'd been very hands on with the way that I had been prompting agents. It's,

20:35 nope, nope, nope, do this, I go and watch check, etc. So I certainly wasn't, I'm

20:42 not the kind of person that gets comfortable

20:46 with like completely unattended agent loops.

20:49 And I'm not trying to build dark software factories, because I've been outside of

20:54 coding in the rest of the business long enough to realize that

20:58 thar be dragons

21:00 I'm not prepared to slay them. So I've been very

21:04 interactive. And I have continued to be very interactive.

21:08 But when I started using OpenSpec, instead of just

21:11 hey, Fable, let's ideate and

21:13 then build a markdown file that I can hand over to Opus to go and build things. And

21:18 I started following the OpenSpec approach, the open spec, spec explore, we have

21:22 this great conversation, I really feel like I'm stepping into the role of the

21:26 architect again, I can be the architect, I can talk about the architectural

21:30 constraints, what must be true, the constraints that

21:32 we work within, the why behind a lot of these decisions.

21:37 And of course, being a language model, it can just change the context of everything

21:42 else. So it understands, "Oh, okay, yep, I understand we talked about semantic data

21:47 or modular monolith or the rest of it and why and what the constraints are, all of

21:51 those things have been emerging beautifully. And what, what comes out the other end

21:57 is, is the change. And so that's the, that's the this

22:04 didn't feel that different to what I'd already been doing.

22:06 I didn't realize how rigorous that approach had been, because it had baked in as

22:12 many surprises as possible into that specification.

22:17 So now most of what's happening

22:20 moves confidently forward. Well, the agent is always confident.

22:24 I'm confident.

22:25 And that's the harder one. But every now and again, it's

22:30 going and it says, Oh, I just noticed, there's a there's a

22:36 there's a gotcha here. And, you know, and in fact, what had happened was, I was

22:45 just trying to do some some basic stuff at first, I was just bumping some

22:49 dependencies. And that turned into a three day yak shaving extravaganza.

23:00 As it always does.

23:02 Because of, I'm gonna hold my tongue because I have so many unkind things to say

23:08 that Oracle right now. Oh, boy. But it mostly Oracle's fault.

23:13 Hey, we're not we're not sponsored by Oracle here on this

23:15 occasional podcast. So, you know, you say anything you want.

23:20 But it or they just shipped a bunch of buggy drivers and then and then did nothing

23:25 for six months and just turned into a big ordeal. But what my experience was

23:31 because I had this direction. And we had where we're trying to go. And we ran into

23:37 roadblocks. Now, the way I think about it is

23:43 it's like Google Maps or Apple Maps or Tom Tom or whatever turn by turn directions

23:48 that you use. Tom Tom. Okay, bloomer. Yeah.

23:54 I just want to be inclusive. Don't shame me for that. Please go on.

23:59 There are dozens of them

24:01 dozens, dozens, so many. Yeah. But whatever you're using for your turn by turn

24:06 directions GPS navigation. Sometimes you

24:09 will hit a roadblock that isn't in the map that

24:11 wasn't in the plan. Or sometimes you just make a mistake and miss an exit. And what

24:18 does your GPS do? It just recalculates and it gets you back on track. You go around

24:24 the obstacle gets you back on track. So, for me, the value that I observed early on

24:31 was the ability to absorb meandering. So like my

24:37 strategic brain can plan and propose and explore.

24:41 And again, throwing out more OpenSpec terms.

24:44 But once we're applying the change,

24:47 if something comes up, it doesn't end up getting us lost like,

24:53 okay, I, I want to, I want to reflect that and relate to that. It also occurs to

25:01 me, I just want to take a few minutes now that we're in a half hour into this

25:04 conversation. Let me explain what this silly technology is that we're talking

25:08 about. And this is in no way sponsored. I'm

25:11 not even a contributor. I don't know the folks who write it. I'm just a guy who

25:15 discovered this thing and said this thing looks useful. So if it sounds like I'm

25:20 shilling for it. I'm, we're just talking about a technology we like. That's all we're doing.

25:23 So it is fundamentally a command line tool. And a set of skills, very

25:28 particular set of skills. And when you, say, on a Mac, you'll

25:34 brew install openspec

25:36 and you have a new project, you'll, you'll install,

25:41 the skills into the .claude or .agent, or, you know, wherever they go in your

25:45 particular coding harness. And it's got support for

25:48 a couple dozen of those.

25:51 Then there's this workflow, okay?

25:53 So you got those skills, you got that command line tool

25:54 And there's this workflow

25:56 So if you know what you want to do,

25:59 You propose a change.

26:00 And that's the that's the /ospx:propose command. And that can be a sentence

26:06 that can be, you know, paragraphs and bullet points, whatever.

26:11 Your definition is of the thing that you want to get done. And that's called a

26:15 change. So and I'd like I know you know all this just in case the audience doesn't

26:19 So you propose a change.

26:21 And there might be a little back and forth on that proposal

26:24 There might be some things that are unclear. And the agent might say,

26:27 Well, you know, what do you mean about this?

26:28 Or it's not clear what library to use

26:30 for this? Do you want to spike this? There can be productive discussion there,

26:34 right? If you don't quite understand your

26:38 change well enough to jump in there, you can explore.

26:41 Which again, this is like, you know, a feature that's been in most coding harnesses

26:46 all along. But the explore command is intentionally like,

26:50 Hey, man, I don't quite know what I'm doing

26:52 I want to think about this. You know, how is raw image decode

26:57 gonna work in my Lightroom replacement

27:00 There's a lot to talk through. And usually,

27:04 that process, you're interacting with the model and the skill, and whatever

27:09 existing specs and existing code bases are in there.

27:11 Usually, that's iterative. It's asking you questions. And it's freaking

27:14 challenging. It often when I'm exploring, I'm like, Oh, yeah, I didn't think of

27:19 that. That's a really good question. I it's, it's hard work to go through to do

27:24 that architecture work. So if you explore, you explore for a little while, and then

27:30 that becomes a proposal, if you kind of understand things well enough,

27:32 you /ospx:propose

27:33 Now you've got a thing called a change in flight. And a change is

27:38 a proposal, which is like a description of kind of what you're doing, a design

27:44 document, which is just a more detailed implementation, a task list,

27:48 and, not to be forgotten,

27:50 a set of actual specs, WHEN blah, blah, blah, then this SHALL, blah,

27:55 blah, you know, that sort of formal spec language,

27:57 that's all in markdown. And on a per change basis.

28:03 And but it does have shades of BDD that become not like an

28:10 executable spec, per se, but like, you can see it from there.

28:16 You can, you can and I'll get I'll get there. There's the specs don't just go into

28:23 a folder to die and never be heard from again. When,

28:28 you know, development of something complex, new changes,

28:32 are going to interact with old specs and we'll get there. So

28:36 once you got a proposal, and you like it, you read the design document, it makes

28:40 sense, then you apply it and apply goes and writes all the code.

28:46 And typically, some of the tests are whatever automatic verification, the agent can

28:50 do some of them might be manual verification.

28:53 There's a new version of open spec that has a verify step

28:57 a verify command that you can get a different model to go in and check things out.

29:03 Actually, I'll confess I haven't done that yet. But

29:06 when you're done, everything works, then you archive the change, and it is no

29:09 longer an active change. But the design document,

29:13 the proposal, the task list and the specs

29:15 stay in the OpenSpec directory as

29:20 an official part of the repository of this project.

29:24 And this this is coming back around to something you said

29:26 how it keeps the agent on track

29:28 At least you've found that it keeps the agent on track.

29:32 All the modern harnesses and the models contemporary as of

29:37 this recording, do a really good job saying, Okay, what's out there in the code

29:41 base? What am I doing? What do I need to look at? And, you know, maybe if there's a

29:44 little markdown file of whether it's the AGENDS.md or CLAUDE.md or some

29:48 other sort of advice, you know, they'll find those things. But now explicitly,

29:53 there's this long list of specs and

29:56 The specs are merged into the master spec list for the application.

30:02 And this isn't part of the problem with

30:07 writing functional specs in the bad old days was it

30:10 was a focus on the software, the thing you

30:12 were building and not the people who used

30:15 it and what they were doing.

30:17 And it was very easy to just get absorbed

30:20 and off the road off into weird territory and,

30:23 and not thinking about the people who use your thing.

30:26 There's another dimension that's worth mentioning.

30:29 Yes, those specs were about building software.

30:33 And we don't build software, and we have not built software for a very long time.

30:38 Developers change software, software engineering is change cycles

30:42 that are nested

30:43 And that's a very important detail.

30:46 Because when you change software, there's

30:49 important context that doesn't exist in the code.

30:53 It exists in a list of previous decisions and commitments.

30:57 And now, and I'm just seeing this in my, my

31:01 current project, my Lightroom replacement, I have

31:04 this list of, I don't know, 50, 60

31:07 proposals that are the whole vision for the thing,

31:10 explorations and changes, 50 or 60 changes that

31:13 are going to be an initial version of this thing.

31:15 And occasionally it'll say, well, okay, but this

31:18 contradicts a spec that you've got from back here.

31:21 And that'll have to change.

31:22 What do you think about that?

31:24 For me, what I'm most excited about when it comes to OpenSpec, like, and again, I,

31:32 I, I fully admit that there are, like you said,

31:34 there are other approaches.

31:36 Um, none of them are really right.

31:38 None of them are really wrong.

31:39 It's just a different set of trade-offs.

31:41 But for me, I always go back to, I think

31:43 it was Peter Norr, Peter Nauer, Peter Nair.

31:47 I don't know how to pronounce his last name.

31:48 I've only ever read it.

31:49 Do you know who I'm talking about?

31:50 Yes.

31:52 Uh, he wrote a paper back, I think in the eighties

31:55 called, uh, uh, it was like programming as theory building.

31:59 So he has this concept of, uh, what he calls a theory, but, um, essentially there

32:06 is, there is the program and the program is more than the code.

32:13 The code is like a reification of the part

32:17 of the program that happens in the machine.

32:19 But there is, there was something bigger that, that exists outside of the machine

32:24 because the reality is the software that we build exists to deliver value and where

32:30 it delivers value ultimately is outside of the computer.

32:33 The problem is outside.

32:34 The solution is inside.

32:36 And so by definition, just looking at the code, you're only looking at part of the

32:43 program, part of the, part of the solution or part of the problem.

32:48 He says that code is, uh, is lossy.

32:51 And what I found is, is continuing to use OpenSpec, um, as a, as a consistent

33:00 process and even ritual, uh, allows me to expand

33:06 not only the code, but the, the program as theory.

33:10 It's the, it's the theory building part because what it's maintaining in those

33:15 markdown files and the opinionated structure that it adopts is

33:20 basically the kind of learning that happens in a team.

33:25 Like I remember one of my jobs as a coder, I show

33:27 up and they say, Hey, Michael, go do this thing.

33:30 And I'm like, Oh, okay.

33:31 Yeah, we need to do this.

33:32 I know how to do that.

33:33 That, that, that, that, that, that, that,

33:34 that, and all of a sudden, why is production down?

33:37 Oh, you didn't know that there was a load bearing bug in that particular class.

33:43 And nobody ever touches that.

33:45 Like that's no.

33:47 You just like this is stuff that doesn't fit in comments.

33:51 This is the tribal knowledge.

33:53 Yeah.

33:54 And what I really appreciate is it gives you a mechanism for capturing the context

34:03 behind decisions, not just the code that resulted.

34:08 And that is enormously valuable.

34:11 That makes the agent part of the team.

34:15 Instead of the bot that you say, okay, now make code do this.

34:20 Right.

34:22 Excellent point.

34:22 There's a learning loop there.

34:24 There, there is.

34:25 And, and, uh, the reality, again, I, in my

34:29 experience, I see it interacting with previous changes.

34:34 You know, like you got this from this change and you

34:36 decided in, you know, two point, what you call 2.2.

34:39 I'm using that numbering system, which doesn't

34:41 help my anti-functional spec, uh, spiel, but anyway,

34:45 you know, whatever it's got a name it's called Fred back in spec Fred.

34:49 Uh, you, you deferred that and it sounds like you want to get back into it now, you

34:53 know, so it, it's, it's got that history.

34:55 It's a very good point.

34:56 I think of it as guardrails for me, but it's also really a lot of state, a lot of

35:00 knowledge, uh, about the project that the

35:03 agent has access to the harness has access to.

35:06 And, and we have conversations and, and some of these things basically become

35:12 integrated architectural decision records.

35:16 Given this context and, and this, this problem and this decision criteria, we

35:22 evaluated these options and landed on that one.

35:25 These are here, all the tradeoffs of all the different options.

35:28 And here's why this set of tradeoff matters most for this project.

35:32 Like that is now context that the next turn with the next bot that's going in there

35:38 isn't going to just blindly undo it because it's inconvenient.

35:42 Right.

35:43 Or it's just an inconsequential thing not to be considered.

35:47 Uh, and you know, we're focused on our current prompt and our current task.

35:51 Excellent.

35:51 Or it becomes a decision that no longer holds that is now being surfaced and a

35:57 human is making that distinction rather than a stochastic, um, chatbot.

36:05 But for me, that operational learning

36:06 is one of the most valuable pieces.

36:10 Um, and it, I noticed it at first in a very small

36:14 way because I'm on Windows for better, for worse.

36:20 Um, and I know that puts me in the minority because your first instinct was to send

36:27 the link to this podcast, um, studio online to my phone.

36:33 I, I in fact texted it to you.

36:35 Yeah.

36:36 Not, not helpful.

36:37 Yeah.

36:37 Uh, I mean, that works for you and you know, Sletten does the same thing and a

36:41 bunch of, you know, but all of my Mac

36:43 friends are like, wait, you're not an Apple device.

36:45 I just did a podcast.

36:45 I didn't put it in the calendar invite.

36:47 Like I said, I was gonna, but you know, still.

36:49 That's alright.

36:50 But then I got it moments later before I had to send you a snotty response, but,

36:54 um, the, uh, you know, I'm on a, I'm on a Windows

36:58 machine, but, uh, to help me, help me deal with that.

37:04 I spent a lot of time in zsh in, in the windows subsystem for Linux.

37:09 And so that's, that's where I try to spend most of my time.

37:12 And, uh, that's where I installed OpenSpec.

37:16 And of course I've got Claude running wherever Claude's

37:19 running and, and it says, I can't find OpenSpec the first time.

37:25 And then I said, Oh, it's in WSL.

37:27 Oh, okay.

37:29 And then it just shells over to WSL and assumes

37:32 Bash and it's not in Bash because I don't use Bash.

37:35 I haven't got anything configured in Bash.

37:37 And it says, I still can't find it.

37:38 I said, it's in, I'm using zsh.

37:40 Oh, okay.

37:41 Yep.

37:41 There it is.

37:42 And then that was it.

37:43 That was the end of it.

37:44 Every subsequent session knew that.

37:47 Uh, another one was it started spinning up all these different work trees and

37:50 things like that and, uh, putting everything in branches.

37:55 And, you know, that's fine.

37:57 Uh, I'm not, I'm not here to yuck anybody's branch yum.

38:00 But I am, uh, I'm a old school continuous

38:08 delivery, trunk based development kind of human being.

38:11 And I believe if you, if you're doing continuous

38:14 delivery, right, then the branches slow you down.

38:18 But, and also I think, you know, continuous integration is valuable, but,

38:26 in the beginning, it just always started to, uh, do things in branches.

38:30 I said, well, this isn't very helpful.

38:33 I do trunk based development here and it says, Oh, okay.

38:36 Got it.

38:36 And then that goes into your config.yml, which is basically

38:43 another fire we haven't even talked about.

38:45 Right.

38:45 But it's, yeah, things it needs to know, but that

38:51 is the, that is the value of persistent context.

38:53 It knows standard operating procedures.

38:55 It knows, uh, enormous context about past decisions and where we've run into

39:03 similar crossroads and how we evaluated those.

39:07 And not only that I feel like my agent got smarter, but my team got smarter as

39:13 well, because it was flagging inconsistencies that

39:18 we had in our approaches that we didn't know about.

39:23 Um, so that was just another side effect.

39:29 That you, you saw that, uh, help move you forward.

39:34 Yeah.

39:35 My guest today has been Michael Carducci, developer,

39:38 speaker, teacher, software architect, raconteur, magician.

39:45 And friend. And knowledge graph grease monkey.

39:48 Michael, thanks for being a part of the show.

39:52 Tim, it's always a pleasure.

39:53 Good to see you.