Viktor
00:00:00.000
Let's write it in five different languages, I'm just validating the idea and the design behind the idea and all the jazz, And, throw it away. Completely throwable. Something that would be unimaginable. Imagine kind of like five MVPs for a new product, not fully fleshed out with all the features, but kind of five MVPs. I never built it in less than a week, a month. Teams take weeks, months to build a MVP, singular. I can build five in a day
Darin
00:01:36.774
So if you're writing code using AI where you're just typing in prompts and then fixing hallucinations, you're doing it wrong. Not a bad place to start. That's called vibe coding. But that's not where you want to stay. Spec-driven development, however, might be the next step, but even that can be questionable. Viktor, how did you start up your process when you started with AI? Did you just go from specs from day one, or what were you doing?
Viktor
00:02:06.282
specs from day one. the reasons are very simple for that. I had specs before AI. I don't fully understand what changed
Darin
00:02:16.637
So even if you were just trying to come up with an idea, you would have specs? You would go that far versus just gue- see, you spend way too much time planning than I do
Viktor
00:02:26.581
Just to be clear, before AI, depending on whether I'm working a team or solo, I would always have specs, but sometimes specs could be in my head
Viktor
00:02:41.326
always more than idea. It's not kind of like, "Hey, I have an idea. I have no idea Should, should it be Go or should it be b- Python? are we running it in cloud or am I running it below my desk?" Kind of, I never tried to do anything so unprepared. There is always more than idea. There is more than, I'm going to create, I don't know, my, my, DevOps agent. What will it do? I don't know. Where it will run? I don't know. I mean, it might start like that, but it progresses further than that before I start writing code, right? So there is always spec. What we should talk about is how detailed it should be. And in some case, for some people, maybe there is no spec, kind of. Like I literally kind of, I, I, I literally don't know what I'm going to do. but then it reminds me, you know, in Go- I don't know whether there is still in Google, uh, at least before if not still, there was a I'm Feeling Lucky button. Maybe some people do it like that. I don't
Darin
00:03:50.296
Well, that's sort of the scenario I was laying out, to where you start writing something with a prompt, it comes back, "Oh, yeah, that's not right." So you update your prompt, and that's not right, and you keep going in this cycle until eventually you run out of context or you get compacted and you lose things. It's like playing Whac-A-Mole. That's what we don't want to do
Viktor
00:04:10.917
imagine that you replace that agent with a person. We're going to the era before AI. How would you do it? Would you say just kind of, "Hey," let's say you and me work on a project, and you have some rough idea of what that project is, and you tell me, "Viktor, let's work on a project." "What is it?" "I don't know. I'm not telling you." "How are we going to do it?" "I'm, I'm, I'm not telling you. No." "Uh, are we going to use Java or, or Go or Rust?" "I'm not telling you that either." "Will it run in cloud or we're buying service?" "Not that either." How long do you think that I would stay, stay in your team, Darin?
Darin
00:04:56.743
Probably very little. Actually, you probably left before you started, let's put it that way
Viktor
00:05:02.619
Right? So when you work with multiple people, probably better word for they would be entities You need to explain wh-wh-you're our glorious leader. You need to explain what you want us to do And I'm going back to my previous question, the-- or not the question, but statement that the thing we should be discussing is how deep we should go into, those specs
Darin
00:05:31.631
the old model or current model, depending on where you're at, is requirements, design, coding, testing. Would you agree with that? That's, that, that feels like a very normal flow.
Darin
00:05:43.421
Whereas with, if we're gonna be using AI to either do it or augment us to do it, still requirements, but instead of design, we've got to come up with detailed specs. Once we have detailed specs, we can hand it off to AI, and then we do the validation. I'm saying we. We could be entities, as you s- What was the word you used before? You didn't use entity.
Viktor
00:06:11.439
Entity. Yeah. I don't know how to call something. It could be a person or an agent
Darin
00:06:16.693
Right. So it, it looks and smells the same, but the key part is that second step. We moved from design to detailed specification.
Darin
00:06:34.450
It could be. but it's not a detailed specification at that point, right? Requirements are we want to do these things, right? That's the one-pager or the two-pager. that's what you're getting from your executive VP because they got budget to do this thing.
Darin
00:06:49.970
You're not getting the 80 pages of paper to figure out what to do next That's what we have to have if we're going to be successful in doing AI, whether it's spec-driven development or not. Because if we're expecting to hand it off to the agent to do the work for us, it knows nothing
Viktor
00:07:10.061
Yes, but, how detailed and what we should do will depend on the answer I'm going to ask, on answer to question I'm about to ask, and that's are we talking about one-shot unsupervised or we're talking about I'm with you, I'm your glorious leader that is breathing behind your neck all the time?
Darin
00:07:30.021
That just got really creepy really fast. But you're right. if people think one shot is going to cover it, I'm not saying it can't, but it's a infinitesimal percentage
Viktor
00:07:42.779
No, the-- let, let's say that it, today or in the future it's possible, right? Uh, I'm not saying it's not possible. Depends probably what you're doing. I have some one-shot things I do. let's imagine for a second that it can be one-shot, it can be, uh, supervised, it can be s- anything in between. but depending on what you choose, the level of details you need to specify in advance differs, right? So if you're planning to one-shot it, you better explain everything in detail. Or you can say, "Okay, this is what I know, and this is what I speculate, and there are many things I don't know, and we're going to discover it together." Emerging design.
Darin
00:08:26.503
So effectively what you're saying is if we're trying to one-shot it, that's going back to waterfall to where we spent five years writing a spec and then hand it off versus more agile-ish by, I don't know exactly, but I know where I want to start
Viktor
00:08:44.621
Exactly. Because I'm just being more honest by admitting that I don't know everything in advance And I think that this is not, not related even with AI because you even mentioned waterfall and, uh, agile and this and that, right? I think it's about the level of honesty we, we have with ourselves
Darin
00:09:04.900
the twist though now is it still feels like waterfall is the, I'm, I'm going to get shot down for this, is the best way to do things today.
Viktor
00:09:16.801
Uh, not at all. I, if I limit myself to things I try to do seriously, I never one-shotted anything, and I'm guessing that when you say water- waterfall in, in AI era, you mean one-shot, which
Darin
00:09:29.803
No. No, no, no, no, no, no. That's not what I mean. No, I'm still sa- I'm still saying that overly ver- ver- verbose specs are the best thing to have when working with AI today
Viktor
00:09:42.983
Okay, let me backtrack for a second. And this is, based on some conversations I'm having actually lately, with some people, and that's that we have two options. We can, we can create very detailed design, of what we want to do, I mean, first very detailed idea of what we want to do, and then very detailed design. And, uh, we all agree on that design, and then we do it with AI agents, all the shenanigans, right? Now, my argument is today different, and that's that we tried to be very detailed in the past, and we are still trying to be very detailed, because the cost of mistakes could be high. If we don't design something well, architecture, APIs, this or that We might need to redo a lot of work. We need to do some very heavy refactoring that can set us back for a period of time, right? my argument to that is that actually a design is validated through code, through implementation of that design We don't know whether you-- that design is truly good or not until we actually do it. That's when we discover whether that's actually that was a good design or bad design or something in between, right? Only after we implement it. Afterwards, we are just making educated guesses. So I'm going now in a direction, okay, so why not create, um, throwaway executable designs? Instead of me giving you a Markdown file that explains everything I want, I can just iterate maybe with five different MVPs. I can give you your design Together, actually, I can extrapolate the design, five different designs from the code I wrote And then we can decide what works best. And I can do that faster than normally you would create that single one design And we're all going throw it all to trash, all five of them. None of them exists afterwards And then we're going to have actually clearer, I'm not saying going to say clearer because it's never 100% cleared. Okay, so this actually works. I pick number three And we can even vibe code it. We can one-shot it, We can iterate very, very fast. Because if we are going to make a decision what we're going to do in detail, then let's just make it. Not production ready, a lot of shortcuts, all that jazz, kind of like. I'm not evaluating the, whether that code is, production ready, whether it's fine, whether… I'm just validating the idea. Look, I'm going to give you five des- f- not five designs. I'm going to give you five MVPs today and I'm going to let AI afterwards generate design diagrams and all that stuff from all those five MVPs and pick one. How about that?
Viktor
00:12:55.224
I think it's actually very realistic. I think that production, we can, we can discuss how good or bad AI is creating production-ready code and how much assistance we need to provide it and all that stuff, but MVPs, I think it's excellent. You know, we're not checking whether the design of the webpage is exactly as we want it. We are not checking whether code is repeated or no. We're not checking whether it's camel case or this case or that case. We don't… I mean, I, I don't even care about which code it's written in. Let's write it in five different languages, I'm just validating the idea and the design behind the idea and all the jazz, And, throw it away. Completely throwable. Something that would be unimaginable. Imagine kind of like five MVPs for a new product, not fully fleshed out with all the features, but kind of five MVPs. I never built it in less than a week, a month. Teams take weeks, months to build a MVP, singular. I can build five in a day
Darin
00:14:01.726
Well, that's the key point. You just said it is weeks or months down to a day. This is a tool that we can… I mean, okay, you could have used Figma, right? Or fill in the blank, any of the other tools like that to come up with the, the mock-ups. But you're not saying mock-ups now. You're taking it beyond, a step beyond potentially
Viktor
00:14:22.426
Yeah, this is all fully operational, kind of like there is a front end, there is a back end. it's running in my kind cluster. It's connected to a database. I can do all of that. Maybe it's not a day, maybe it's a week, but it's drastically shorter than it was before, right? and also I'm not valid-- And this is the important thing. I'm not going to validate Figma on one hand and then APIs in some OpenAPI schema on the other and then this, uh, then over there. No, no, no. I'm giving you fully connected operational end-to-end, uh, I cannot say the word that start with SH, uh, that will be not worth anything.
Viktor
00:15:10.987
Oh, yeah. I can even show it to customers and say, "Is this what you would like?" I'm not giving it to you to run it, just to be a hundred percent clear. Imagine a meeting where, you know, usually, uh, software vendors, they have customers that are helping them design new stuff, design partners or whatever it's called, and then you would go there, and then you would have a PowerPoint presentation where you explain what you're planning to do, and it's looking for their validation, That happens fairly often, Not necessarily always PowerPoint, sometimes, uh, Figma, sometimes, uh, I don't know, some architecture diagrams, right? But you're explaining what you're planning to do. It took you a month to assemble it. Then you go to a customer and say, "How does this feel? Would this be useful," right? Then you, you check with five of them or five hundred or depends on how big you are. And imagine if I, if I come up back and say, "Hey, uh, here's a laptop. Tell me whe-whether this is the, the product, the feature, whatever that you want." It's horrible. You, you cannot use it. Don't, don't even try to copy it, kind of like. I, I s- uh, I see you there. I, I see you inserting USB drive. Don't do that. That's completely useless. But that's a working solution that you can tell me, "Is this something that would be useful to you?"
Darin
00:16:34.709
Imagine how impressed those prospects would be to where-- I'm gonna go back to the design partner concept. They go in, you, you have some meetings, you go away, you come back weeks, months later. Now you have a meeting one day, you pull not an all-nighter, but a late-nighter, and you come in the next day, it's like, "Is this what we were talking about yesterday? and then you would use all your caveats of, "This is not production ready. I did this last night. This is…" Right. But is this in the correct direction versus having to wait weeks or months for that
Viktor
00:17:13.768
And, just to remember, weeks or months for you to tell me whether this is the right direction based on a PowerPoint.
Viktor
00:17:23.474
Right? It's, it's very powerful and you, you still have that kind of, hey, I'm, I'm-- I still need weeks to give it this to you. I just kind of, uh, this is not-- we didn't even start, but kind of it's operational. It works. Check it out
Darin
00:17:37.994
Yeah. And you're saying that's where a one-shot could come into play and it's reasonable.
Darin
00:17:49.148
But not fully spec-driven. That's what I'm trying to get to is it's not fully spec-driven at that point
Viktor
00:17:58.786
we spoke with five customers. We had five solutions. We showed them five different solutions. We internally, we discussed those five solutions, and we picked solution number three, and now we are throwing it to trash. But that's not true. We're not throwing everything to trash. Now we say, "Okay, dear Claude, I picked solution number three. Create a spec Create the diagrams, create motivations, create kind of, uh, you depict it. Give me everything I need to start working on this for real, and everything but that document you are about to write for me is going to trash That's extremely powerful
Darin
00:18:46.456
That's extremely powerful and I want to pause right there. If you were just sort of glossing over the last 45 seconds of what Viktor just said, you talk with Claude to write the spec for you. You aren't sitting down in front of a blank white page in Microsoft Word to start writing a spec. You are giving an agent the directive to go and take a look at the thing that was created, not production ready, but it's in the right direction, and saying, "Go write a spec for this."
Viktor
00:19:26.330
It might not be one shot, just to be clear. You know, write spec and then you start questioning, "Oh, should we use this database for reload, that database?" Kind of there is a conversation going around it, but you have a starting point
Darin
00:19:37.556
but that's what I'm saying is, is, is it w- writes that initial spec that gives you the ability to start having conversations with that spec to dial it in as close as you can to what you think the first pass is going to be.
Darin
00:19:51.596
I can tell you that's-- When I'm setting up a new project, that's effectively what I'm doing. I have an initial pro- or initial something, I can't-- initial project or something that I co- And s- it's an epic. I do everything with epics and specs. Just that's my strategy. But is everything correct in that very first one? Not even close. That's sort of like my bootstrap, for lack of a better term. It's like, "Oh, we're gonna do this, we're gonna do this." Great. And then I think about every feature that's going to be coming behind that. That's gonna be a new epic with its own specs, because sometimes the specs are just the general part, some of the specs are edge cases. Could be any number of things. And that's how I plan out my work. Now, is it classical spec-driven development? No, it's not, because I'm trying to ship something. You know, ship things. That's what we're supposed to do in this world, right? We're supposed to ship things, not keep creating new things. I'm talking to myself right now. Stop creating new things and start shipping things. I'm telling myself that. But if we don't get our specs right, what's gonna happen? Like, let's assume that, okay, hey, we had Claude go and write the spec for us, and then we're ticked off that the outcome from that wasn't what we expected
Viktor
00:21:16.619
Let me just correct you. I assume that that's what you meant. Writes, uh, Claude writes spec With us. not for us. Yes. okay. So you discover, no matter how much effort you put in advance, that once you start working on it, one hour later, one day later, one month later, that, uh, it's not fully right. Is, is that a concern? Kind of like it's, it's not really… We should have organized it differently. We should do this, we should do that. You, you discover that and, uh, no biggie, no problem. Kind of rewrite it.
Viktor
00:21:59.271
we change our spec, we change our code, right? And let's face it, we did. That has not, again, nothing to do with AI. The number of teams that are suffering because they are unwilling to change their mind, and then they suffer through the things, using things or maintaining things that are obviously wrong, that's very close to 100% of the teams And I'm saying just change. Yeah, cha- because, you I'm having real difficulties with AI agents, whatever you want, in figuring out what and how and when and stuff like… That's my, that's my real complication, and, it's not that clever. But saying something like, "Rewrite this API to that API," that's so, so trivial. "Change from this database to that database," so trivial, Cause those are the very kind of… There is not really thinking involved in that, or not much. There is no brainstorming. Kind of okay. Eh, we chose this database. It's completely wrong, and it's not wrong that we chose wrong SQL database, but we shouldn't be using SQL database in the first place. Rewriting that is trivial now ' Cause you don't need to figure out. You know what your application needs. It's already there. I'm not figuring out anything new. I'm just kind of like change color to, from red to blue It's easy. Today
Darin
00:23:38.172
It reminds me of one of the things I would tell myself and I would see is people would think, a- as a tech person, have a manager come to me or a business analyst come to me and it's like, "Boy, I, I really think this is gonna be hard." And my response to them is like, "Oh no, that's pretty straightforward." But then the flip side of that is also true. It's like, "Oh, this should just be easy. Change it from red to blue." And then my response is, "Okay, that's gonna be a three-week project. We're gonna need five people, and then testing's gonna need about three weeks to test it But you're just changing a color
Viktor
00:24:14.700
when you're working alone, right? Uh, so no AI, none of those things. There is a big difference between this is easy, I know everything I need to know, and this takes small or a huge amount of time I was involved in many projects or tasks, but actually this is fairly easy. I need a full week. It's easy in terms like there are no unknowns here. There is nothing to figure out. We're changing from s- I don't know, from React to, uh, no, uh, from r- what was before React? Whatever. Uh, from framework X to framero- framework Y, I would say that that is fairly easy. Tedious is Not the same as easy, right? I mean, it's a very different thing. I can have easy task to do that takes me months, and I have a, I can have a very complicated things to do, uh, or task to do that takes me a day Now, the first group is very easy for AI as well, and it doesn't have the time constraints we have. The second case is actually hard
Darin
00:25:38.142
Let me ask you this question. Do you think writing specs and going through that process as a human, writing specs with AI is harder than actually writing the code?
Viktor
00:25:52.204
Oh, definitely. With or without, doesn't matter whether you involve AI. That's so much harder than writing code Harder as in more complex?
Darin
00:26:02.446
More complex because you're trying to figure out, okay, what are the edge cases? What are the normal cases that the business analyst probably didn't think about that you know because you're around, or maybe you're new and you got assigned to this, like you don't know anything. It's like, oh, this is gonna be simple until you talk to somebody reviewing that spec, and it's like, "Mm, nope, not even close."
Viktor
00:26:23.380
Correct And on top of that, being depressed because most likely you're not doing the right thing anyways
Darin
00:26:31.934
Right, because you're used to, as developers, we've been used to asking, "How do I build this?" instead of, "What is this thing supposed to do?" Because what is this thing supposed to do was already solved for us upstream.
Viktor
00:26:45.305
Yeah, the, the bigger challenge is Like probably the biggest challenge in what we do is that until you put that something into the hands of your users, you don't truly know whether you're doing the right thing or not And that's where I'm pushing back on massive, whatever massive means today compared to before. Ma-massive investment in specs, massive investment in design, massive investment in architecture, because the biggest issue is always, are we building the right thing? Conceptually And customers, prospects, users, whatever you wanna call them, they tend to be terribly bad at telling you whether you're doing the right thing based on you explaining them what you're doing I'm pretty sure that the number of people that would be excited, let's say, with iPhone, you explaining them iPhone, is very different from number of people that were excited when they got it in their hands Even if that would be a prototype So you really need to give me something tangible for me to see and use and touch and feel for me to give you, uh, real feedback how useful this might or might not be for me. And if I'm right on that one, that means that our primary goal, and this is going to the beginning of this conversation, primary goal should be producing something that people, our users can touch and feel and give us feedback. Everything else is easier than that. Everything else ' Darin: Cause until you have feedback, you don't even know if you need to build it or not I mean, if I'm wrong, then I would be wrong in saying that vast majority of startups fail
Viktor
00:28:56.591
Yeah, I mean, you need to make some decision without… You c- cannot, you know, you talk to people? but that's not kind of, "Oh, would you like to have this type of service?" "Yes." Then you give me to that, that service and ask me for money and say, "You know what? No." startups fail when they reach the validation phase, tangible validation phase. when people get their hands on that something. that's when they fail or succeed,
Viktor
00:29:25.675
Definitely. That, that's the five MVPs I was talking about, Now, it's not a full validation. You're still not giving me money for it because m- paying for it is the real validation. when you start weighing whether you, you will open your wallet for that or not, that, that's when you're really validating. But we can get better validation of sort or early validation if the, the sooner we give people that something in not fully baked form, that's fine
Darin
00:29:58.238
We use the word early. When we're writing specs today, that's different than writing specs six months ago. Here's my reasoning behind this. GitHub has its Spec Kit. We've talked about agentOS on live streams, and there's other frameworks out there to help write specs. However, these frameworks came into play before Slash Plan existed inside of Claude Code, and Slash Plan exists, I believe, now in Gemini
Darin
00:30:32.236
Why would we need to use a heavier framework? Because even some of the, the guy behind Agent OS, Brian, said once Plan came into play with Claude Code, he was able to strip away almost 80 to 90% of what Agent OS was doing because Plan had gotten that good
Viktor
00:30:55.720
Yes, but only on the s- on a lower level, on a level of a task doable within the context So you need, so you need higher level plan where things build on top of each other. Like, uh, let's say I wa-- I'm going to build this feature, and this feature has five milestones, and I'm going to build each of those milestones in a different context, kind of like I cannot fit more than one milestone in whatever the context size is, right? At least that's my strategy. So now I don't need to be very detailed because planning with Claude Code is exactly that. Kind of, okay, milestone number one, read what's the general gist of it, kind of we are building feature like this and that. We want to accomplish this and that. Cool. Some general guidance, general rules, blah, blah, blah, and then milestones. Milestone one, authentication. Cool. And that's when plan kicks in, Claude Plan, because we're gonna plan it together and we're, and then we're gonna do it together or you're gonna do it alone, depending on what we're doing. that's already debatable how much I should or shouldn't be involved there. But that planning phase, definitely that's Claude Code now or whichever planning f- tool your cl- uh, your agent provides. But for that to work, you need to have some kind of milestones, tasks, and the gist of what you're trying to do. But once you have that, then yeah. And assuming that you're writing back, because if you reach milestone two without having clear what we did in milestone one, that will not work either, just to be completely transparent, right? So you can plan and, but you should write the outcome before you close the session.
Darin
00:32:47.496
I think like all its predecessors, software-d- driven development is also going to break down, just like all the other DDs, TDD, BDD, all the… Everything has its problem.
Darin
00:33:05.362
Isn't that the spec-driven development though? Or is you t- planning is prior to spec-driven development
Viktor
00:33:09.904
but plan- planning and spec, spec-driven development, isn't that the same? Kind of like it is the same thing. Now, what we're really debating here probably is whether for those fi… That feature that has five milestones, do I have a detailed spec in advance before I start working on the first one or I don't? And if I don't, then I'm still doing spec-driven development. It's just that kind of like I have high-level specs, and we're going to define lower-level specs for each milestone when we start working on it, which would be Claude planning, plan mode, right? You… In bo- in all case, you end up with a spec
Darin
00:33:48.840
But the downside to that is, and this is the same problem that we had before AI. I know everybody gets hear-- tired of hear- us saying that. But we have static specs versus dynamic changes that are happening out from underneath us. Again, not an AI problem. But again, if I can build something out, if I can hit, I'll use your words, if I can hit a milestone today, like by end of day, it's, it's 10:00 AM now and I can, by 4:00 PM I can have that milestone done.
Viktor
00:34:26.626
I'll give you two options. Let's say that you spend tremendous amount of time planning let's say a week planning, and then you do that milestone in half a day or would you rather do that milestone with one hour planning in a day? With the option to redo that milestone five more times before you hit the, timeframe of the first option. I'm gonna do it five times
Darin
00:34:55.443
Absolutely. And what you just said there also reinforces this point of over-specifying gives you a false sense of security
Viktor
00:35:06.862
you are. I mean, uh, you're a liar in the sense that you lie to yourself. thinking that,
Viktor
00:35:12.612
thinking that you know in advance everything, and you don't. Let's face it, you don't
Darin
00:35:17.954
because what may have been true at milestone two is no longer fully true by the time you hit milestone five because of what happened in three and four
Viktor
00:35:29.370
Yeah. But also Milestone 5 will, will change because of the work you did in Milestones 1 to 4
Viktor
00:35:38.541
It should. We did agile development, kind of. It's not even new, right? Kind of like, I thought that we, we, we went through it already
Darin
00:35:49.335
So here I do think is one of the real problems is somebody in the company is going to believe that w- hey, we can get rid of all the business analysts now since we just want the people actually, quote unquote, "writing the code," driving the AI agents to write the specs themselves. not a bad request. I think it's reasonable. Uh, except not all developers are able to put specs together. A lot of developers are, "Give me my next Jira ticket. That's what I work from."
Viktor
00:36:20.943
I will repeat this over and over again unless I-- until I change my mind, which I do often, is that we are not getting rid of anybody. We are not getting rid of testers, we are not getting rid of designers, we are not getting rid of developers, and we are not getting rid of business analysts. What is happening is that everybody's going to do their work very differently or might be doing multiple roles Okay, how about this, Darin? That business analyst, can that business analyst do those five MVPs? Let's assume that that business analyst is a technical person. Not technical enough to bring it to production, but technical enough to build MVPs. There you go. That's your business analyst. From now on, I'm not doing those MVPs anymore
Darin
00:37:08.481
Correct. It-- And by technical, I would say they understand how to use Google Sheets or Excel, 'cause that's usually what business analysts are really good at, are numbers
Viktor
00:37:17.369
I, I mean that business analyst in software industry needs to be an engineer. That's what I mean.
Viktor
00:37:26.287
and that has nothing to do with AI. Not necessarily the best coder in the world, not necessarily coding even anymore, but experience-wise, yes, you're a software engineer. If you're not, I don't know what you're doing here. Go away
Darin
00:37:39.968
Now, there are places where spec-driven design, and let's debate these because I'm not sure I've got a list here. Spec-driven design that works really well for and not so great for. So here's the list. Works well with greenfield. Agree or disagree?
Darin
00:38:05.272
Yeah. Yeah. API development with clear contracts. Yes. Talk, talk about true specs. I mean, those are real specs. CRUD operations, standard patterns. All day long. Right? No big deal. Here's what it might struggle with, and this is where I'm not sure that I agree with this list, because there's-- I was going back and forth trying to figure out, okay, how, what should we include there? How about experimental development? Well, you've already sort of shot that down because experimental development, your five MV- MVPs, proved that spec-driven development actually works great there
Viktor
00:38:50.912
In my head when I say spec that means we're not necessarily discussing how detailed that spec is, but I'm not saying do five random things. That's not my prompt There is always spec. The question is really how detailed it is
Darin
00:39:05.500
Another thing where it may not work out as great is performance optimization. Now, before you say, "No, wait a minute, I thought it knew everything," going back to the standard procedures and standard practices. Which true, but if you're really trying to do performance optimization, you need to do profiling. And profiling, the output from profiling could help drive what goes into a spec, but a naked spec isn't gonna figure out how to do performance optimizations in general
Darin
00:39:36.060
I mean, it may see that it could take a look at your code and say, "Oh, you, ins- instead of writing to disk every time, maybe you should just use a cache." Okay, that's, that's an easy one. But once it's actually running, then that's where profiling has to come into play
Viktor
00:39:52.426
I have a very different opinion probably from many people on that area. I think that performance measurements are done in-- should be done in production The question and the reason why you might not want to do it in production is that, "Oh, if I deliver it production wrongly and it takes me five months to correct it, then let's not put it in production." Which is wrong because then you say, "Okay, let's, let's, let's valid-- let's performance test it for five months, and then we're gonna somehow be sure whether it's performant and put it in production," which is ridiculous. just put it in production and see what happens,
Darin
00:40:30.665
The number of flashbacks I just had, I lost count of, of put it in, see what happens. Oh yeah, we can't touch it again for another six months
Viktor
00:40:39.573
Yeah, then don't. Exactly. But, uh, when I say put it in production, see what happens, is I'm going to be extremely fast. I'm going to be flash lightning, uh, with it in terms of how fast I'm going to react to discovery that it doesn't do what it needs to do
Darin
00:40:59.242
The last one that I'm not sure that I'm in agreement with it where it could be hard is legacy systems, where we take an agent, a handful of agents, point it at a legacy code base and say, "Figure it out. Go change this from X to Y." I'm not saying it can't be done in the future, but the context is way, way, way, way, too big
Viktor
00:41:22.864
Okay, so if the context is way too big, let, let's assume for a second that you can refactor with AI legacy system. Let's make that assumption for a second, right? the holy valid spec of a legacy system is the legacy system
Viktor
00:41:42.213
Yeah. I can, and, you know, even if they're valid, they're not complete. And if the… You know what would be a complete spec of a legacy system be? Well, legacy system itself. The complete spec is the code. That's the most complete spec you can imagine, yeah, legacy system spec is the code. The code and, uh, you know, other stuff like observability, networking, the, the system itself, just to be clear.
Darin
00:42:10.391
and t- to me, legacy is… How can I say this? A program becomes legacy as soon as it ships Let me explain why I say that.
Darin
00:42:24.835
I was working with a CLI yesterday. I'm not going to name it. Not one that I wrote. And instead of looking at dash dash help, I just looked at the README online. It's like, okay, I would expect the README because knowing who wrote this, I would expect them to keep the README up to date. The README wasn't completely up to date. So then when I had Claude write a skill for me to help drive that CLI, I was like, "Oh, there's six other options for this one command. There's eight other options for this other command that weren't documented in the README." So when you have that mismatch, it's like, "Oh, now we can't use this because I just looked at the README," versus, "Oh, heck yes, I can actually use this and I don't have to worry about anything else,"
Viktor
00:43:19.407
It's something that you could do as well. It just, it would take you too much time for that to be viable
Darin
00:43:26.547
Yeah, it was just like, "Eh, I don't want to do this." I mean, I wanted to do it, but I had too many other things to do. And I already knew there was a solution there.
Viktor
00:43:34.857
one thing that I feel changes from the examples you mentioned before is potentially the order. Like, one, one of the examples you, you made was, if I remember correctly, APIs, right? Spec-driven development for APIs. in the past, the way I would do APIs is that I would start with OpenAPI schema And then I would go through it, think about it, think again, and so on and so forth until I get the schema right And then both the clients using that future API and the development of API would be based on that schema. I'm not sure that that's the correct order anymore. I'm more inclined towards, okay, let's just make that API, and I will generate the schema Cheers to it! Maybe five of those, again, according to my MVPs, right?
Darin
00:44:20.713
that's an interesting thought. I guess really what I meant by that was that that's a solved problem, right? The OpenAPI spec is easy to deal with. So Yeah,
Darin
00:44:34.625
Correct. I, I, I, don't know that-- Well, you could argue that the first milestone would be that the OpenAPI spec was produced, going back to your
Darin
00:44:48.795
mean, you, you could argue that, and then everything would happen from that point
Viktor
00:44:53.395
So you need, and I'm limiting myself to, uh, APIs now, but I think it applies to others. You need to s- write schema first because it will take time for you to create implementation of that API, and in parallel with you working on that API, some client, let's say front-end calling it, will be worked on as Well, right? They cannot wait for you to do it first and then they do it, and then somebody else do it, and then kind of three years pass until we actually see that something in production, writing spec first, like schema, allows everybody to start working on their parts Because it takes time but now when time is not the question anymore, at least not that much. No, yeah, I'm gonna give you a schema when I implement it
Darin
00:45:43.459
Well, and again, sticking with API, OpenAPI is a spec. So it's that use case is like, "Oh yeah, we really should do this one first." If somebody hasn't started even trying to do spec-driven development, where should they start? I'm thinking they should just start on a single feature. Don't try to do the whole project unless your project's small, right?
Viktor
00:46:07.985
Yeah, it's always a feature. I mean, I I, don't believe in whole pro- I mean, even when I start a new project, it's always kind of, "Okay, so it's the project in general," blah, blah, blah, whatever. And then after a bit of tinkering, you use… You move to the first feature. It's always a feature
Darin
00:46:25.582
The other thing that we need to do, and something we should've been doing all along, is treating specs like living docs. Just nobody wanted to do it because you'd spend more time writing the documentation than you would actually writing the code, and we didn't have time for that. But now it's really important
Viktor
00:46:43.255
I actually, constantly, uh, uh, reinstruct Claude to do docs differently with, and I'm paraphrasing now, the skill that says, "This is user-facing documentation. I don't want to see anything technical related to implementation in that documentation." Zero implementation details Simply because you can figure out implementation details from the code. You as in Darin, you as agent, blah, blah, blah. Now, you as Darin is complicated because it's not really nice for you to read all nobody knows how many lines of code to figure it out, right? But now it's relatively easy to do that. You can just ask Claude, "Hey, Vic- uh, explain what this project does. What's the architecture?" And stuff like that, right? I don't need anymore to document. I don't want to document that because sooner or later I will forget. Claude will forget, and I will-- We will both forget to update it. I'm really focusing now documentation only on user-facing
Darin
00:47:52.434
There's one place where I probably break that concept, but I guess you could argue that this is user-facing as well,
Darin
00:48:00.084
is we want to put our stack decisions into the specs That way it's not having to always go and look and guess and figure out, "Okay, what is this? What do I need to learn?" It's like it's just defined right there, meaning this is a Go CLI project, this is a Spring Boot web project,
Viktor
00:48:20.216
But yeah. yeah. I have a relatively short agents MD, that is not giving any real information, but more like kind of helping it file. Okay, I have a like root directory level, for example, diagram with short description kind of like source code here, test here, this here, that here, right? Kind of just to help it not nudge it in a right direction when it starts discovering things, but you're gonna discover things
Darin
00:48:50.562
Do you put tests in your specs at all? Like, or the, you know, what it has to conform to once it actually does the implementation?
Viktor
00:48:58.297
not in spec as in, um, because, you know, spec and tests are the same thing conceptually in terms like kind of, oh, when you click this button, this should happen, So I have when you click this button, this should happen type, type of instruction. and that instruction is eventually translated to a test, sometimes before the code, sometimes after, right? I will actually admit here that I spend more time reviewing, tests it writes than code now these days 'Cause through tests, I actually, uh, I almost never let it, you know, code, depending on what it's writing, I put more or less or no attention, but tests I always review it in detail. And when I say tests, and I mean unit tests, I mean functional tests. Because, okay, so you're going to validate this, this, and that That's exactly the behavior I expect it to do. Cool. Now we have tests. Now we can check actually whether your code is correct. by me reviewing tests, I'm in a way reviewing code
Viktor
00:50:15.391
Correct. Not, not 100%, you know, uh, it will never capture everything we test, but based on, on certain level, that is correct, yes
Darin
00:50:24.570
If somebody's never really spent any time trying to build out their skills for creating specs, where do you think they should start?
Viktor
00:50:33.801
To turn on the plan mode, and then when it's finished with plan mode, say write it to this file. cloud code is good, but I insist that, everything needs to be in a file. I just don't write very, very detailed specs in advance now. if you go to any of my projects, you, you will always find a PRD directory over there, And I dare you to actually do a diff. Uh, I have a sub-directory done when I'm finished. and, uh, I dare you to do a diff between PRD initially and PRD when it's finished, and you see that they are very, very different. But everything is written down there, yes.
Darin
00:51:08.697
That's one thing you'll run into with any of these tools is they'll create the plans for you, but you can't really see them once you've seen them. So it's critical to write them out somewhere else because that's my pattern is I have it write out the plan for me, and then I've got a couple of skills that I run afterwards, like go and find gaps or blind spots that I didn't think of in the first pass, and then start building from there
Viktor
00:51:33.746
I have three skills that I use all the time, and that's PRD create. That's when we brainstorm what we're going to build. but more importantly, I have, update progress, which means, okay, we finished with this milestone, update the PRD with critical information. and, uh, the third one is, update decisions that one is the one probably I use the most because it starts doing something, it goes fine, fine, fine. W- why did you do thi- wh- oh, you s- whatever. We have a conversation, and then it updates that plan, right? When I say update, it's not always kind of replace this paragraph with that paragraph. It can be, or I'm going to add five new milestones
Darin
00:52:15.109
Right, because you didn't see them before or it might be going down a path you don't want it to go down at all.
Darin
00:52:24.657
So writing things out to a file so you can review the file, build things out from that point. What other things do people need to understand? let's assume the person has always been, uh, forgive me, a code monkey. They pull the issue, do the work, push the issue. That's all they've done
Viktor
00:52:42.494
Well, that's problematic, right? you need to change the way how you think. You need to change the way how you operate. You're not going to be code monkey anymore. You will become, tech lead, architect, product manager, many different things. Any of those things or maybe all of those things. That's your new role. Face it. I hope you have capacity to do it
Viktor
00:53:15.727
you know, it's the same thing with, you know, with any other profession pro- uh, what is expected from a profession changes, I could be-- I could have been in the past witch doctor, voodoo something, something, and then, uh, we discover medicine, and we have doctors and kind of, uh, I don't know, maybe I can become a doctor. Maybe I can't. If I can't, well, I don't know. Need to figure out some other job
Darin
00:53:40.031
Well, I think we can say that spec-driven development, to me, really is nothing new. The twist on it is, okay, we're mixing agents in now. But we've got to spend the time working on the specs like we probably should have been doing all along in the past
Viktor
00:53:58.330
I don't think that anybody working with AI doesn't have any specs. That, that would be ridiculous. That would be literally saying, "Do random thing, and I'll see whether I like it." Uh, everybody has spec. The real conversation here is whether we are applying waterfall or agile principles to specs. I think that that's the conversation that I don't know whether anybody framed it like that, but that's how I, I like to think of it. when I say whether to do it like waterfall or agile, it's not kind of, "Oh, if you do waterfall, it's bad." No, no, no. I, I don't think that we are certain how, what is the best way to do it with agents. Maybe it's none of those. I don't know. But right now it feels like it's waterfall versus agile, and for all I know, either of them could be a better fit. I mean, I don't think that waterfall is a better fit, but I'm, you know, trying to be positive here.
Darin
00:54:48.508
If you were to look back three months through all the practice you've done, do you think you've really improved on your skill just through that practice? Like looking at your PRD directory, if you were to think back what you were doing three months ago or maybe before that, and I'm just trying to-- From the beginning time of when you started doing the PRDs to where you are now, is it easier?
Viktor
00:55:09.808
uh, it is definitely easier. First of all, the skills I'm using to create, to update, to this, are changing over time. The pace of change is smaller now than it was before, but, all those skills I'm using in MCPs and stuff like that, they're all living things that are improving as I figure out how to do it better. So yeah, the answer is yes. And also, I think that in general, my-- on any level, the, the, the results I'm getting with working with agentic AI is, is changing all the time. It's getting much better. I'm pretty sure that I'm much better today than I was, like, half a year ago. I'm sure of that.
Darin
00:55:52.530
So you, dear listener, where are you at in this? Maybe one thing you could consider is sitting down and writing a spec for a feature that you recently implemented. Just do it retroactively, and then put in the constraints, you know, put in the specifications or whatever all the other pieces are. And then once you get to the point to where, "Ooh, I'm having problems doing this one thing," that's the one thing you need to probably work on. So what do you think? Head over to the Slack workspace, go to the podcast channel, and leave your comments there