# Spec-Driven Development: Workflow Strategy Over Tooling

**Podcast:** Thoughtworks Technology Podcast
**Published:** 2026-05-28

## Transcript

Hello, everybody, and welcome to the ThoughtWorks Technology Podcast.
My name is Birgitta Böckler.
I'm a distinguished engineer at ThoughtWorks and a regular, sometimes host, sometimes guest on this podcast.
And today, it's just me and one other person that I'll have a conversation with.
And I'm very happy to have Laura Tacho here today to talk to me about spec-driven development.
Laura is the former CTO of DX and recently joined AWS as a senior principal technologist.
Hi, Laura.
Thanks for taking time to talk to me.
Hello.
Very nice that we've been talking about doing a podcast for a couple of years now and it's finally worked out.
I'm glad to be here.
Yeah.
And we'll have a conversation today about spec-driven development.
I have a bit of history with that topic.
because when it first kind of started taking, getting traction was around October, September, October last year.
And I wrote up my observations of what I was seeing and that memo on Martin Farrer's website actually still to this day, eight months later, gets a lot of traffic.
But I actually personally have been like staying a little bit on the sidelines since then for several reasons that we can maybe talk about.
But let's start with definitely.
maybe, and then get into a conversation of where we think this is eight months after it started gaining traction.
What is spectrum development in your perspective, Laura?
I'm so glad that you asked this question, because what I observe from the companies that I work with is that there are lots of different practices that people all call spectrum development.
And so it's really kind of like a wide array and there's not a lot of standardization.
When I think about spectrum development, a couple of things have to be true.
So I define spectrum development as a framework or a workflow for creating well-defined specs as part of the planning process before coding begins.
And then that spec is an artifact that then is handed off to typically an agent to complete.
I think we can get into a question of.
If the agent is a requirement as well, if Spectrum and Development only applies to AI, augmented engineering or not, maybe a conversation for a different time.
But Spectrum and Development is a workflow that allows teams to get very clear about user requirements, plan it, create an artifact, and then use an agent for the actual implementation.
And usually also you use the agent to do...
the planning right to all of them yeah yeah i think that's where we get into some very um you know some very sophisticated workflows this isn't this isn't just writing a really really good prompt this is actually using your agentic ai tools to facilitate the authoring of a very very well documented spec that has a lot of edge cases test cases very comprehensive and so that agent understands it has everything that it needs to go build something How does that differ or align with your definition of what a spec is?
Yeah, the word spec is still super fuzzy.
I mean, sometimes it's just a more elaborate prompt.
Sometimes it's 50 markdown files, sometimes just 10 markdown files.
Sometimes it's also a difference between what it is in reality in the, let's say, frameworks that call themselves SDD frameworks, spectrum development frameworks, and like...
what people are talking about when they talk to each other, right?
Or what the ideas are in people's heads that maybe haven't tried it yet.
So for example, there's this blurring of the lines between functional specification and the specification of the technical solution, right?
So there's some people, I think, especially people more removed from the actual like...
hands-on development work, who sometimes have this idea in their head, it's just about describing the functionality, like that's something that I can do as a non-technical person.
And then AI just creates it, right?
Whereas a lot of these frameworks also facilitate this whole solutioning process, right?
So it can, because if you just leave it to AI, if you're being too unspecific, it can be as variable as AI decides to introduce a persistence layer with a database versus AI does not.
decide to do that I mean it's an extreme example but it has actually happened to me yeah so that's like still very fuzzy then of course there's you know some people who say oh the only like properly detailed spec is a test, right?
Don't we already have executable specs, right?
So, but that's of course like a different, let's say bounded context maybe almost than spectrum development.
So we as a mass of people have now decided to use that term for it in this bounded context, right?
Like of these frameworks that you described.
I think a lot of times when I discuss spectrum and development with developers and also with engineering leaders, they're often also describing greenfield projects.
And that's a very different flavor of spectrum and development when you don't have an existing code base to contribute to versus spectrum and development for a brownfield project.
I don't love that.
I don't love that word brownfield, but of existing services and systems where to your point, right, the functional, like the technical specification.
is really critical because there's existing architecture that needs to be considered in your spec and in the development of whatever feature is being kind of attached to or changed within that system.
And so there's a lot of different styles which would all really fall under spectrum development because it's, I think SDD spectrum development is more describing like the behavior of having a workflow and then an artifact with specifications and less you know, something that we could throw a linter at and say, yes, that's spec-driven development or no, that's not, that doesn't pass the linter.
I don't know if we'll ever get to that point.
But, you know, we're kind of also, we're describing similar, if we think about what we have now, test-driven development, behavior-driven development, all of those things are describing kind of like patterns that developers and teams use in order to develop in a very...
certain and specific way, but it's still a little bit fuzzy around the edges.
And I think that's like, we're letting people self-identify into spectrum and development right now.
And that just leads to a lot of drift and a lot of fuzziness in the, in the name.
Yeah.
Because I think the, the key here really is for me, not.
a fuzzy spec it's the workflow part right it's that these tools that call themselves std tools they kind of walk you through a workflow and um as you already just said and i totally agree with that there is not one workflow for everything that we do right like brownfield greenfield is one example is it a bug or is it a new feature is it a small feature is it a big feature right so As developers as well, we don't work the same way all the time, right?
And what I see in some organizations now is they see these frameworks and...
they ask us as consultants, like, how do we scale this?
Right.
And like, one of the things in their head is we just have to figure out one of these tools or come up with our own workflow and then every developer will use it and then we're good.
And then everybody has to use this.
Right.
But again, it like, it depends a little bit on the situation and in terms of the workflows, also, when you look across the space at all the different, um, tools, they always have like a very similar flow and then just the.
details of the implementation are different, right?
And how well they support different types of feature sizes, feature types, and so on is different.
But it's always some form of discover and plan, design the solution, implement, right?
I mean, this is like very simplified.
Some of them have six or seven steps.
Some of them just have three steps.
Usually it's optional for you as a developer, which one you choose, right?
So, but yeah, ultimately I think it's about the workflows.
That's much more at the core of it than, this spec thing.
Yeah.
And I think this is a nice time just to sort of pause and hold that thought for everyone about not getting too hung up on the specific tool or on implementation details, but more focusing on the workflow and the process of spectrum and development and having that be the goal of going through the process of right discover and plan.
uh implement evaluate those those kinds of workflows versus just thinking oh if i just start to use this tool that i know does spectrum development then all of a sudden i'm going to be doing it it's not as simple as that it is more it's a it's a behavior change um and it's a process change so we can't ignore the the human aspect or the team aspect of this as well um where uh you know a tool isn't going to solve necessarily all of the problems even if a tool can really help support teams get better at their planning process, again, going back to what we talked about before, use AI to plan and to write the specs.
These aren't something that developers are just authoring by hand or even like business stakeholders are authoring by hand.
It's all happening kind of in the same development ecosystem.
Yeah.
And that's also one of the questions I had in my write up from October and a question.
that I still have, and I think we still, as a profession, haven't figured out, which is who is the target audience for this or who is the target user?
They seem to be targeted as developers mostly right now because they're like usually built into the coding agents as.
in form of skills and stuff like that.
And even though I do know lots of stories at this point of also product managers using cloud code and kind of like losing their, you know, fear of using a terminal for that and all of that, right?
It's still like very much catered to developers.
And so I hear a lot of stories of, you know, developers then figuring, doing this discovery phase of the workflow, right?
Or like figuring out the details of the story or the feature and then going right into implementation.
where I'm still wondering, I mean, it's not quite explicit with the authors of these workflows as well.
They don't, I mean, they could be saying, this is the future, developers will also be the product managers or developers will also figure out the functional details of the story, right?
Or they...
could explicitly say the goal here is for like a requirements analyst to use like a more old-fashioned word and a developer to pair on these first phases and then the developers continues right but it's somehow not quite clear and i mostly see people using these by themselves as developers right like um which i i just think is going to be a problem at some point right in terms of the alignment could not agree more Could not agree with you more.
I think one thing that I've been talking about, it now feels like forever, right?
But it's only been like 18 months.
I mean, it's hard.
I sometimes think, you know, Claude code wasn't even GA at this time last year.
But I think about, you know, it feels like this has always just been the world.
And I think you and I work in this world a lot.
You know, one of the things that I've been sharing with engineering leaders for the last three years is that if we want organizational lift, so increased productivity from your product development teams.
Essentially, we're looking to actually influence revenue, right?
We're trying to build better stuff for our customers and end users.
We're not going to get that just from engineering alone.
And to your point about we've got spectrum and development workflows oftentimes really built in to the IDE where developers are spending their time.
Well, it's not a job that only developers can do.
Like developers can flex into what a lot of companies are now calling like, you know, product engineers, or even I've heard the term like AI native engineers, multidisciplinary engineers, renaissance engineers, renaissance developers is another one.
They can flex into that, but there are all these people on the business that have incredible expertise in figuring out exactly, you know, people that are field facing product managers.
They have the knowledge and expertise about what needs to be built and scoping that down.
It's very important to get those people.
into the venue where STD is happening, which means that they also need to be using the same tools that developers are using.
And we see this start to happen.
One of the last things that I did before I left DX was a impact report.
looking at AI trends.
And Justin Riach, who's the deputy CTO, has kind of picked that work stream up and published kind of the second version of it to give updated data now a quarter later.
But one of the things that we started to see was the proportion of product managers and designers using tools like Cloud Code or Kiro or Codex was just increasing.
And it has, I think, steadily increased also the number of engineering managers who use AI tools, agentic IDEs and then also looking at their PR count is an interesting indication of people are just getting a little bit closer to the code.
But in order for spectrum and development, I think to have the organizational impact that it can have, we really need multidisciplinary teams sitting at the table and in the same workspace working together.
I don't think that really...
any of the organizational problems that we're trying to solve with agentic AI can be solved by engineers alone.
We can build a lot of tools, but it's not, you know, it's not a single threaded solution.
Yeah.
Yeah.
Part of it is a tooling question, of course.
Right.
So we, there's still like so much potential of how we can evolve these tools.
Right.
Like I know there's like a project at GitHub next right now.
I forgot the name, unfortunately, where they're also trying to like create kind of like a collaboration thing where all the.
artifacts and all the conversations are in one place about a feature to improve that collaboration, right?
Maybe making the interface more intuitive for somebody who usually doesn't deal with the code, right?
But of course, it is super powerful if a person who kind of like lives and breathes the product and the requirements and knows all the stakeholders and knows all of that space, right?
If they can use a tool that also knows the code base, right?
Without them having to...
you know, understand what the code does, right?
Like I was using one of these workflow tools the other day and I was going through like a discovery phase with it, right?
And it was actually making really good suggestions or like pointing out gaps in my, you know, kind of like rough input that I had given it.
They were based on it reading the code base, right?
So that's actually super powerful that, you know, these people now don't.
have to go to a developer all the time and ask them like how do we do this again like what is it really like in the code right so part of this is a tooling question and there's still like so much potential i think the other one is like you said organizationally or you know i still think software delivery is still a team sport and will still stay a team sport right and um you know just like having one silo where we create more and more code throughput and then you know, have another silo where we create more and more requirements by different people, right?
That won't work, right?
Just in terms of like flow and theory of constraints, all of that type of stuff.
But then also like deciding that developers will just do it all.
That's also not a solution, right?
Like there's this thing where everybody seems to think that they will be able to do it all and the other people will be out of a job, right?
And not the other way around, right?
Maybe product managers who can now like actually, you know, access the code, you know, maybe they will come out on top.
I mean, it's not a zero-sum game, right?
That's, I guess, what I'm trying to say, right?
Yeah, I think that's a great way to think about it is that this is like software development is still a team sport.
And now we really have tried to solve this alignment problem.
for a long time.
And I remember posting something on LinkedIn probably over a year ago where I said, you know what, the thing I find most interesting about, we were still calling it like AI assisted development, I think at that point, now we can call it agentic development, is that it's actually forcing teams to really look at the requirements and the user, you know, the intended outcome for the user before starting to build something.
And like, We've really tried to do that in software engineering for a really long time.
We've got tons of tools out there to try to document, you know, user requirements, user stories.
We've got all these different methodologies and workflows and practices to take a big requirement and break it down into small things and make it, you know, digestible.
You know, I've seen all sorts of stuff, as I'm sure you have.
And everyone who's listening out there, I'm sure you've seen like a wide variety of good practices and bad practices when it comes to requirements, completeness and, you know, how things are broken down in your ticketing system.
But I look at Spectrum and Development and I think, oh, this is like this is us trying to solve the alignment problem still again.
But maybe but maybe it's going to stick this time.
Maybe these workflows and practices, because we are actually.
keeping the thread the same, like we're keeping a thread between the required, like the spec and the implementation.
Whereas, well, I should say that.
I hope that's still true because as you said, right now, we've got teams using AI to come up with the spec and then going into implementation.
And there's not a put down or a handoff of that work.
To your point, what you just said about What will happen if Spectre-driven development morphs into something where it's just a team over here writing a bunch of specs and then a team over here who's implementing a bunch of specs.
I think that doesn't actually solve the alignment process.
And then we lose what Spectre-driven development has enabled us.
Why it's enabled us to move faster is because it is start to finish and we have one loop and we're not just like creating a backlog of specs and then a backlog of implementation.
I am worried.
that that practice is just it's too it's it's too tempting to do that because it's really close to how a lot of the things work right now.
But I would say, you know, going back to that very definition of spectrum and development, I would say that if you're doing that, that is not spectrum and development.
And maybe that's like through this conversation, I've identified one more of my qualifiers for what I would how I would define spectrum and development versus not is that it has to stay in the same loop and there's no.
hand, uh, handover or handoff or like backlog of specs.
Like a spec should never end up in a backlog.
Maybe we just need different words at some point, right?
Like we have a lot of, I mean, we just published an episode on harness engineering, right?
Where that I actually also wrote up, tried to come up with definitions and I feel like, oh, we need like three more words at least.
Right.
And I hope that we'll, we'll develop some of those.
But in terms of the handoffs, I think, um, There seem to be two things happening at the same time right now.
One is like all that's old is new again in like a positive sense, right?
And like the, you know, as somebody who's worked with extreme programming practices for a long time and worked in environments where it was really like agile by principle and not agile as a methodology.
So I see some of these things and I go like, huh, interesting.
Like, for example, everybody says now, oh, it's the product engineer is now like a...
trendy term right and it means the the developer has to has to care about the product and it's like huh we used to just call that an agile developer that was the whole point right so so that in the sense of like what's old is new again like it's interesting to see some people like finally embrace some of these things because there's additional incentives right and like the systems that they were in before it wasn't worth doing some of these things because of how things around them were set up but then at the same time there's the negative side of What's old might be new again, right?
And so I assume you're also of a similar generation as me.
So you have worked in like some waterfall environments before.
And I think it's not even worth like arguing with waterfall these days because like the vast majority of developers these days haven't even worked in what, they don't even know what that means.
So they haven't experienced the pain that led to some of the things, right?
So, and because a lot of stuff in waterfall is kind of...
feels very intuitive, right?
It's a lot about control.
And if only we just think really hard about the requirements first, and then, you know, everything will be good at the end.
So a lot of the stuff that came with Agile is kind of counterintuitive.
It goes counter our like need for certainty, our need for like control, right?
And so I think it's very easy now with these things to fall back into that and actually sit there for two days, you know, for one feature and just like work with the agent to get the spec.
just right so that then in one perfect beautiful go it can create the perfect code right so um yeah so it's also then on like people who have experienced that to kind of like suss out what are the things here that we shouldn't fall back into but what are also new opportunities where circumstances have actually changed and we can look at how we can leverage ai to do things even differently than um uh yeah we were doing six, seven years ago.
Yeah, like, what's old is new again.
And I said, like, you know, the physics of great software haven't changed, which is that it has to be, you know, software that's reliable, completed quickly, that with high quality that solves a customer problem.
That hasn't changed.
And also things like having short feedback loops being very beneficial to both developers and the business, that hasn't changed either.
And I think that it is really tempting with spec-driven development to get back into that, like, okay, well, now I'm in planning and I have to plan every little thing.
And looking at the process and thinking like, oh, well, how do I iterate on the spec?
Like, is that allowed?
You know, that's a real question that I've gotten.
how much planning is enough planning, how much planning is too much planning for a spec.
And I think this is where it's like we can't we have to learn from the past and understand that like we don't want to go back to full waterfall where we were just like because it's so easy now we can just generate arbitrary arbitrarily large change sets at the drop of a hat, you know, assuming you've got enough enough tokens.
It's still not a good practice to do that.
even if we can do it and we can do it much easier, it's still not a good practice to do that.
It's still a good practice to start small, to iterate.
A lot of those agile principles are still true.
And then it's also true that bigger changes carry more risk, even with the additional quality checks and monitoring and observability that we can do with agents and predictions and all these things.
Smaller change sets carry less risk.
The fewer bits that you move back and forth, the better.
So we have to be really careful.
And I think that's one thing that I've seen a lot of developers and engineering leaders struggle with spectrum development is just trying to get the balance right between how much planning is the right amount without going over, but also not going under where we're just putting something into prod where no one...
really understands how it's working or it's not well tested and those kinds of things.
Yeah.
Yeah.
Somebody reminded me last week when I was talking about this as well, like how can we still have short feedback loops and how they were saying, yeah, it's, it's all about learning, right?
How can we learn new information?
How can we gather more data as soon as possible?
So, and ultimately that's also about reducing waste, right?
So if you build like a spec in the sense of like my, I don't know.
25 markdown files that, you know, do the planning that I have all of that.
And then finally we do the implementation and we just need like two second look at the website or something.
And we see, Oh, I hadn't thought about that.
That's why we had these like smaller iterations previously.
And I agree with you.
It's, um, it's something that we still struggle with, with these frameworks.
I think some of them do it better than others, but, um, yeah.
Um, we just talked a bit about the, the past, like.
looking at some of the more extreme futures that people are painting in the context of spectrum development.
In my write-up, I kind of, I called it spec as source, right?
So this idea that in the future, will we have specs, whatever a spec is in the future, right?
Exactly.
Some kind of specs where we edit the spec when we want to change something and we never even touch the code anymore.
but the spec becomes the source, right?
What is your view on this vision?
I remember, so Brigitte, we were both at the Future of Software Development Summit back in February.
You know, some people might have a party to celebrate the 25 years since the Agile Manifesto.
We all thought it would probably be a better idea to just go in a couple of rooms and like think really hard about hard problems and actually come out with...
close to no answers, but a lot more questions.
It was a really great event.
And we had one session about spectrum and development and other kind of, you know, what's the artifact.
And I raised my hand and said something to the extent of, you know, when we're thinking about the future and thinking about what we're committing, it might not be source code.
It might be the spec.
It might be...
context, you know, what is going to be that permanent artifact where we can rewind time and go back to that point in time.
And someone in that session had a kind of comical, funny reaction where that person raised their hands and said, oh, my goodness, but source code is the it is the source of truth.
But that led into a conversation of like, but what if it doesn't have to be anymore?
Because what if the spec is actually what if we can?
always, what if we can always get to working software from a spec and actually it doesn't matter how it works to a certain point.
And I think that that framing is something I think about a lot when I think about what should be, you know, what should be committed, how should specs evolve alongside their alongside the code that they're responsible for, that they've informed.
Because there's quite a few different techniques to do it, right?
And Brigitte, you wrote about this in your memo.
We've got the spec that evolves next to the source code.
We've kind of got the spec that is frozen moment in time.
And then we have different artifacts that inform the changes.
Maybe it would actually be helpful if you wanted to give a quick breakdown of the different ways that you've seen teams.
operate with spectrum development because I'd love to talk to you about then what the future might look like in terms of like are we committing source code or not?
Yeah so the three levels and again this goes back to like me thinking oh we need more terminology right and so I just came up with three new terms at the time right so the first one spec first and that's what I see most people do at the moment I think so you kind of like or it's kind of like a mix right so you create like the description of the feature that you're currently working on and then you throw most of it out again right or like you know some people keep it in the repository as like history for the agent right but it's kind of like like you said frozen in time and you know it's archived kind of or deleted right and then the second level is spec anchored where maybe you have a an area of the feature in your code base that you describe and then every time you work on a change of that feature you go again through the spec and have then the agent kind of like derive the changes from the spec.
So you try to keep the spec and the code consistent with each other, which is a challenge in itself.
It might be a little bit easier with AI, but it's still like, you know, when you have lots of artifacts lying around, right, that there might be a lot of overhead.
And then that last one is the spec as source that I described before, right, like where you actually, yeah, this.
vision of like just editing something other than code right because the the thing is again we don't know what that means spec so the question would be if we think about what would that spec look like that it's like this idea of an erased abstraction level I guess right a new race abstraction level and so when you think about what would we want that spec to look like then you have to think about what do we want to achieve with this right do we want more people to be able to maintain software do we want fewer people to be able to make software, right?
So more people in the citizen developer sense, like different skill profiles, and then fewer people, it's just much more effective.
You just change this thing and it magically happens because people see code as creating the code and all of that as a tedious thing that you want to outsource, right?
So that's one of the...
things because then when you think that through and you're like what would that form of spec have to look like um i actually at the beginning of my career a long time ago i uh worked for a while on two projects even for quite a while or three uh doing like model driven development right so this idea that you create some kind of model of your functionality of your software, either we started out with like a UML stereotype, like a UML based language, and then later went to a textual, a DSL language actually to describe our screens, for example, right?
Like here are the different fields that we have.
Here's a button.
When you click that button, the following thing happens, right?
So I went through the experience of like working on that DSL and the code generators for it.
And just constantly we had to expand this language, right?
So it was like a formal language.
So it really had to, and parsable, so it really had to describe everything, right?
With language models, of course, we have a lot more flexibility about how we describe things.
But I just went through that experience realizing how many things there are to consider, right?
Like which fields are editable based on who's locked in, which fields are not.
So there was constantly these things we had to add to it, right?
And I think everybody who's used these tools has...
had the experience that you write something like this is the functionality I want and you forget a detail like a default value a like what is the format of this customer number right and every time you generate it AI makes a different assumption about the format of the customer number and the reg X you need to validate it right so there's I mean we have not just like my anecdotal experience just now from model driven development we know historically that we are not good at writing down in a lot of detail what we want, right?
The way that we write down in detail what we want is the code right now.
And the question is, will we ultimately, you know, chasing this spec that we can edit alongside code, will we get to the point where we're like, oh, now it's just code or now it's just tests, right?
Executable specifications, right?
So that's like my hangup that I have with this maybe.
influenced by this history as well, right?
Like ultimately what spec can we get to that actually gives us meaningful added value on top of writing the code?
I do agree with a lot of what you said.
I also think about like, you know, when I was at DX and you can find this in some of their public research, documentation is consistently even now the top pain point for developers, lack of great documentation.
You know, spectrum and development, we ask the question, does this does this solve the alignment problem between the business and engineering?
Like, well, maybe it can help solve some of it.
One of the other questions I think about is, like, does this solve documentation?
Like does spectrum and development, you know, what we're proposing is this documentation that evolves at the same time as the code evolves and they're always in sync because they have to be in sync.
And I think about, you know, everything old is new again, but everything old is new again.
We've struggled with documentation for decades.
That's been, I mean, it's a huge problem.
But what I think that spectrum and development does is it changes the incentive structure.
Because in the past, developers writing really good documentation didn't benefit them immediately.
It benefited maybe them in the future when they had to come back to it, or it benefits some kind of ambiguous other developer that's onboarding onto their team.
But, you know, and it's not that we're not nice people and we don't want to help those people.
those people, but there's no immediate gratification.
But what spectrum development does is it changes the gratification to almost immediate, where if your spec gets out of sync with your code, then anything you try to build on top of it is going to be wrong and requires more rework.
And so the developers and systems that developers build, right?
Because I also don't imagine a future where if I say, hey, this bug exists, go fix it.
And an agent fixes it, that I would say as part of fixing it, go update the spec as well.
It's not that I'm going in there and updating it, but we've created now a much more enticing incentive for teams to keep their code self-documented through the spec and to keep the spec up to date.
And I think it's that behavior change that I think it's a good thing.
And I think that helps these spectrum development workflows take root.
you know one question i have a lot about what we commit as the artifact is like you know source code changing does commit you know we can see change but it doesn't really capture intent and i think that the intent is captured really well in the spec um and and maybe now we just have a centralized place for that intent to be captured which is in the spec whereas before it was like in an email in a slack message in a jira ticket in linear in in whatever and now we just have like you know, one central place for it that's easy to search.
And, you know, I think that's overall a good thing.
But, you know, time will tell because if it's not benefiting developers and they're feeling stress or pressure to deliver more quickly and don't have time to build systems around keeping those things in sync, then they also lose incentive to keep doing it.
So I think these next six to 12 months are going to be really interesting with how...
you know, how teams are evolving alongside spectrum and development evolving as well.
Yeah, the documentation connection is interesting to me because like what you just said about like, what if the spec is just a place where we have the intent in one place, right?
And that sounds like what we have been...
telling ourselves about documentation since the age of time, right?
If only you put it in the right place in Confluence and then it's only in one place, right?
And we know that that never happens.
There's always duplication.
And so I'm always about like with wikis and all of that.
There's no, like, of course you want to try and keep some, a little bit of structure, right?
But then you have to also have to embrace the chaos and you need a good search function and all of that, right?
And what...
AI gives us now is also that the persistent documentation is not as important anymore because we can get on the fly documentation, right?
I can ask it, like, look this up in the code base, like what's happening there, right?
Like, or create like a sequence diagram for me, which I would never persist anywhere because they get outdated too quickly, right?
So it's not worth the effort.
But now I can actually get a sequence diagram in the moment when I want that type of visualization, right?
Or there's these tools out there that create like a knowledge graph of not only your code bases, but like your wiki, some of your Slack conversations, like all of your tickets and so on, right?
And the promise of some of them is that that actually does help you discover the intent based on like all the connections in the knowledge graph between this piece of the code and everything else, right?
So there's some of this like on the fly thing.
And then the other thing with documentation is yes, um we now it's now actually a lot easier to keep like track of a lot of you know decision records for example another one of those things that finally more people are doing yeah yeah there's more decision records but the question is also yeah can we now do we just do like a check check check we now have decision record files in the repo we now have like these things documented those things documented um and yes that probably like It's a good thing because it helps the agents.
That's why we're doing it.
That's a new incentive, right?
To make it easier for us to use the agents and get better results.
But does it really help us is the question.
Is that because I usually get overwhelmed by all of these files that these workflow tools generate, right?
And then you actually, through the process, you go and you review these markdown files, you know, which, you know, usually I would be reviewing the code maybe, but now I'm reviewing these markdown files and they're very long.
And you hear everybody say, oh, yeah, yeah, you have to read what it says, because if early in the workflow process you miss like a wrong assumption or something like that, it will go all the way through, right?
And I'm like, are you really, really reading all of these markdown files that get generated?
I just can't believe it, you know?
So there's this like, yeah, this experience thing as well, like this finding the balance between having a lot of stuff that the agent can actually use and that we also have documentation about what it decided in the past and like almost this memory for the future agent, right?
But yeah, how do you actually make it human consumable as well?
Is that the new review experience?
I don't know.
It doesn't really excite me that much or like it doesn't make me that confident either.
Yeah.
Yeah.
One of the things that we talked about heavily at the Future of Software retreat was Is this stuff for humans at all?
And should we be fine with the fact that we're creating a lot of artifacts that a human is actually never going to interact with?
And are they still valuable?
How do we know that they're bringing value and not just like creating more garbage and more stuff to maintain?
I think that's the concern that I have is that...
Maybe we solve the documentation problem and we solve this problem of centralizing requirements, intent, and user outcomes in one place, but the maintenance problem of keeping it all up to date and all pointed in the right places is still a really hard thing.
And that's a place that I have seen some examples of teams that are doing it well, but not.
Not so many, and it's not been kind of like, you know, productized or commoditized quite yet.
But I think that will be an area of rapid kind of innovation and research and new thinking as teams adopt spectrum and development and then have to build out all of the peripheral workflows and systems and products that are going to support that.
that workflow.
You know, we'll see.
I think it's going to be, like I said before, a really interesting six to 12 months with these teams that are really going hard with Spectrum Development and finding a way for it to work for them.
Yeah, that's kind of like a good wrap-up question for both of us, right?
So the term Spectrum Development is about eight months old now.
Where do you think this will be in eight months, Laura?
Oh, man.
Yeah, it's so hard to predict because I see such a wide range of organizations in their adoption journey.
I see some organizations that have, you know, small teams that are multidisciplinary, that are using spectrum and development with, let's say, like a product manager, a designer and a couple engineers, and then shipping that stuff to production environments, user facing environments and doing it safely, reliably, you know, easy to maintain all those things.
I also see organizations who are still struggling to get users to use code complete in an IDE.
And, you know, we've got, we've just got like such a wide spectrum.
I think for spectrum development, first and foremost, I think that this is a technique for professional.
software teams and for teams of, you know, teams who are trying to produce software.
And I think that's a really important distinction.
This isn't a technique that I'm going to use for my like, well, maybe, maybe actually it is like, you know, for a, it's not a personal prototype.
I'm probably not going to use Spectrum and Development.
I'll probably like vibe code that.
I'm just going to give a prompt with natural language and like see what happens.
You know, that's not what Spectrum and Development is.
But I think as teams.
more teams mature and start using this professionally, we're going to see the gaps of, you know, what is the answer?
Should specs evolve next to the code?
Should they be throwaway?
I've seen a lot of interesting things like modernization projects where we can actually generate a spec just based on observed behavior of the...
software and then generate a spec and then generate new technology.
So I think there's going to be a lot of different use cases aside from just teams using spectrum and development to ship software to their end users.
I'm definitely excited.
It's a workflow that I've seen have have incredible positive impact.
I think that the on ramp is challenging and I hope that in the next, you know, eight months we'll see easier ways for organizations to give their engineer, their software development teams, their product managers, their designers, their developers, the skills that they need and the time and the space to start practicing it if they want to.
That's what I hope will happen.
What about you?
Yeah, for me, it's like one, let's get maybe like a...
negative predictions yeah way for us like a backlash against markdown files i mean maybe it's already happening right like maybe fewer markdown files like i mean or maybe it's more in this way of like oh we're just just like acknowledging like looking ourselves into the eyes as we say in german yeah and like say um look we are not reading these markdown files let's just be honest about it but they are useful for the agent how are we going to deal with that but like i'm also interested to see how all of these markdown files and also these like new things that are happening with like keeping agent traces with commits and stuff like that if it will lead to like an overload of agents and lots of inconsistencies and lots of weird behavior because they're picking up like the wrong context from somewhere because there's just too much right like so that you know it's maybe like a concern i have in terms of like the more positive thing it would be uh what we talked about before about like how are we going to bridge the gap between people on a team to have like all of these things that are in these workflows right now but actually make it a lot easier for everybody to work on that and have different projections on what's happening and like I said make it much easier for product managers requirements analysts to actually have tools that have access to the code so that they have additional information right and like How can we actually use this to get people to talk to each other still or keep them talking to each other and not just each of them like in their little cubicle talk to their agent?
So that would be an evolution that I would like to see in the space.
Yeah, I think over the next eight months, this idea of like the shared organizational intelligence layer, the shared context layer org-wide is going to be...
a huge area with a lot of development and innovation and a lot of different solutions coming out because software development is a team sport, but if we have a team, team A that's doing something really well on part of their service and team B over here also using spectrum development doing things like how can we better facilitate sharing of workflow skills, things that are going to help them both benefit.
And I think that's one.
one area where I'm seeing a lot of cool progress.
So I'm interested to see what that will bring as well.
Yeah.
And maybe then in eight months we have to talk again, Laura.
Yeah.
Yeah.
We should schedule it now because, you know, we have a history of wanting to talk on a podcast and then we just, you know, life gets in the way.
So yeah, eight months we'll come back and see if any of our predictions were accurate or where, you know, where we were wrong and where we were right.
Yeah.
Yeah.
Thank you so much, Laura, for joining me for this.
This was...
really good to kind of like reflect back on where we are and where this is going.
And thank you all for listening and see you on another episode of the ThoughtWorks Technology Podcast.