Viktor
00:00:00.000
I think that good coders are not people who spend majority of their time writing code. I think that good developers are people who spend the majority of time designing. Figuring out and doing all sorts of activities and then writing code is just chore,
Darin
00:01:24.720
So in our last episode, we were reviewing my first 24 hours of trying out Cursor and Claude code, and overall phenomenal enough to make me spend $200 on a pro subscription for the year, not month, year. It's like I'm not willing to 200 a month yet, not, I'm not there yet, yet. But then I started talking and thinking about all the silly things with Claude Code. Think that just made me go, this is silly, like it's a terminal. And I was like, okay, let me, let me look, look at the, the file listing real quick. So I typed in LS and then all of a sudden it said, thinking and it started burning tokens. I was like to do a, a freaking listing of a files.
Darin
00:02:18.677
Well, it's like I didn't have the editor open at that time, so it's like, oh, you know what files am I, you know, what path am I in? And I, I could have done PWD, it'd been the same problem.
Viktor
00:02:28.847
Where I was going and I could not get there is that usually you do those things for a reason, right? I'm going to invent the reason you would do LS because you want to find the file where there is a function x. Usually it's there is a reason. It's not just listing files.
Viktor
00:02:49.969
Now, if you think in agent terms, you would not say, Hey, list the files. No, no, no. Where is my function X?
Viktor
00:02:58.422
Or What is function X doing? You need to change the way how you think about those things. There is a reason. Explain the reason. Explain what you want to do.
Darin
00:03:08.552
Explain what you want to do. that is a mind shift that I had not thought about, but again, you know, I just screwed up and typed in LS in the terminal window that was open in front of me. And I was burning tokens and I was like, what does that matter? I was like, why? Why are you, why are you charging me for something? Like to me, this is an argument of sort of like on-prem versus cloud where, or you know, on demand compute versus paid compute. It's like, yeah, I messed up. But I guess the argument falls apart there because yeah, I guess if I split it up I'm gonna have to pay for it.
Viktor
00:03:45.105
Yeah, the key is there that why do you care what's in the directory? I'm not saying that you don't care, you care, but then think about what they're trying to accomplish
Viktor
00:03:59.190
And then it becomes helpful and then you say, okay, actually those tokens are well spent.
Darin
00:04:03.890
So why would do I want to do everything inside that, that cloud code terminal? I guess we're gonna be talking about cloud code
Darin
00:04:11.510
Um, let's say that I'm doing a, let's say I'm just gonna run a test suite. Let's say I'm using Maven, so I do a Maven Clean test or Maven
Viktor
00:04:23.210
And you're running because there is a chance that something, some tests will fail, right? Not because you're a hundred percent convinced and you want those, tests fixed.
Viktor
00:04:34.783
Okay, so let's, let's say it is going to fail. Let's skip for a second, the option that is going to be all successful, right? So what's option number one? Run the test somewhere, and then copy and paste the output to cloud code so that it fixes it, right? Did you save any tokens? Probably not. You just pasted the whole output. You just spent time on it for no good reason. Now, would you have spent tokens for no good reason if all tests were successful? Yes. But the goal is not really to run them because you're convinced that it's successful. Right.
Viktor
00:05:16.710
And cloud code will in general. So let, let's go a step further, right. You're running tests most likely because you change the code. You're not, let me assume that you're not running tests without changing any, any, any code, right?
Viktor
00:05:34.147
So you're changing code with cloud code, And cloud code is running your tests and it's running your test because it's wrote the test. Quote code, wrote your code, quote code, uh, wrote your tests, and it wants to see whether what it wrote works or it doesn't. And if it doesn't, it wants to fix the test that incorrectly wrote. You're not running the test just for the sake. Hey, let me see whether the code that, uh, that was successfully running tests yesterday, successfully running it today as well.
Darin
00:06:07.027
If as a human you're doing that, you're really doing your job wrong because. That's, that's what Jenkins, GitHub actions, you name it, that's what those tools are for, to always make sure things are always in a good state.
Viktor
00:06:20.798
even if somebody is doubting whether an agent should be writing your code. Oh, writing tests. Nobody likes writing tests. There is no person on earth that likes writing tests more than anything else. that's a perfect example of agent. Oh yeah, I just implemented this. Write the test. Or if you're funky, write the test, sit and fail, implement that something.
Darin
00:06:45.128
Okay, you bring up an interesting point of a case that I just saw happen. So I had put in a PR for some changes I made driven by Claude Code and I was reviewing the diff inside of GitHub
Darin
00:06:59.948
Right on on the pull request. And there was. Based on how it's configured, it tells me if there's any code coverage or not for a block of code, or it warns me if there's no code. There's no code coverage.
Darin
00:07:12.598
Now that's giving me ideas. It's like, oh wait. Go back to the notebook, write it down. We need to create code coverage tests to make sure that this part of the code is covered. I mean, I'm not going for a hundred percent code coverage by any means, but it's calling things out. It's like if I see one thing, it's like it's complaining about a getter. Okay, well go pound sand. That's doesn't matter. But if it's real code, it's like, oh, now I can have it write a test to make sure that's covered, or at least start it up for me so I can start writing the rest of the test,
Darin
00:07:46.878
Which is something I would not have. I mean, I would've completely ignored it before. In fact, lemme rephrase that. I have completely ignored it in the past. Now I don't think I can.
Viktor
00:07:54.927
I go a step further and I have instruction in memory of the projects. You know, the one that is loaded when the session starts, before writing first line of code. execute this and record the coverage in this file. when I say we are done. You're going to execute 57 different tasks. We can discuss later if you want what those tasks are, but in this context, one of those tasks is now record the end coverage in this different file and tell me how the coverage changed and if it changed, that is less covered. We have a problem.
Darin
00:08:31.888
That's interesting. Now I want to rewind for just a second, because you'd be using Cloud code primarily now, correct? I.
Viktor
00:08:45.853
Sometimes when I, when I'm too lazy to set up MCP. Yes. but I, I tend to use memory MCP heavily. Just because I'm paranoid, it feels like that I will continue using cloud code for the time being and then I might not be so eager to use m uh, memory MCP, and use CLO MD instead.
Darin
00:09:05.908
So if, if people listening aren't familiar with Claude md because I'm not, I haven't even looked at it yet 'cause I haven't used it. I've just been asking my typical questions.
Viktor
00:09:14.203
But when you started cloud code for the first time, it tasks you, do you want to initialize project right?
Darin
00:09:24.898
Dude, I'm trying to have as little impact on an existing repository as possible because I don't own it. Like for something I own. Sure, I'll do that, but these aren't things I own yet. if I can prove that this is good enough, then I can probably peel off one of the projects I'm working on and let's, let's try this. Let's see
Viktor
00:09:42.431
There is. One very interesting file in, in your report that you might want to take, look, take a look at, and that's get ignore
Darin
00:09:55.525
Fair enough. Okay, so that's something we didn't talk about that last time. Yeah, I saw the knit, I just blew it off. So I guess I need to do that just to see what it looks like.
Viktor
00:10:04.860
what then it'll do is that it'll go through your whole project and it'll write. Everything that matters for that project there. And then you can edit it with things that they didn't discover. Oh, we always do TDD. Cool, right? But project structure, how it's being tested and stuff like that. And then it'll be spending less time trying to figure those things out.
Darin
00:10:26.778
Well, that makes too much sense. So I guess what I'll be doing after we're finished recording this is I'll go, go back and do that for the two or three that I'm working on right now. Just to see what it looks like. I had no idea the docs for Claude Code are, well, I haven't looked at 'em. Let's be honest. Other than how to install it, I haven't looked at 'em, but that's also good. I think because I haven't had to look at any docs. It just sort of makes sense.
Viktor
00:10:57.048
It makes perfect sense. There is no good reason to go through a doc, to be honest, because it, it tells you everything. Like if you ever say, Hey, can you remember this? It'll remember it by, um, storing it in Code Code md, but it'll tell you at the bottom if you pay attention, hey, you can use Hash Sign in the future. Right? It, it basically, it guides you, uh, in a very subtle way. Another thing that you will discover is unless you already have slash commands, so you could create empty files, markdown files, one of my slash commands, I'm ignoring now, the fact that I use memory, is, hey, when I say, we are done. That's how I call it. That has instructions. Okay? When I say we are done, you push to the git, uh, sorry. You commit everything. You create a new branch, you create a pull request, you push there, you calculate test coverage. You wait and, and analyze the result of GitHub actions, et cetera, et cetera, et cetera, and then you convert it into command. So slash done.
Darin
00:12:06.565
So I saw the slash commands, I've looked at them. Uh, the only slash command I've used so far is slash exit. Don't control C out, do slash exit or slash quit. Uh, be careful with slash logout because then you'll get logged out. Now, in order to switch from tokens to my subscription, I had to log out and then log back in.
Viktor
00:12:31.605
Yeah. ' Darin: cause I had to pick because you, you're given the path when you're first setting up cloud code to pick a subscription or pick tokens. So I had to at least do that, but I shouldn't have to log out anymore. I. Unless I lose the handshake. So it sounds like I have a lot more homework to do. That stinks. But it sounds like it's something that I do need to do and it'll make my life even better. Hmm. So what else should I be doing with cloud code that I'm not? 'cause it still feels like, forget about scratching the surface. I mean, I've barely even cracked open what it can do. I. Do a lot of conversations, which I mentioned in one of the previous episodes, conversations with cloud code. Okay. Can, let's say that performance that you mentioned before in the previous episode, right. I would typically say, okay, can you explain to me the option number one, explain to me, and then it would gimme normally bullet points. or even better, instead of explain, can we work onary design of this? And then it would come up with questions, and then I would say, okay, let's go through them one by one. Right? Oh, okay. How should we do this? And then we talk about it and make a decision. How should we do this? We talk about, so I rarely just go and kind of, Hey, uh, I want you to do this right? I insist on. Going through the design right, and questions and so on and so forth. the more of such a conversation I do, uh, the results tend to be better, right? And I, I ultimately end up much faster. I.
Darin
00:14:12.283
So with my use cases, which is basically refactoring use cases, do you see any reason why I would need to set up any MCPS at all?
Darin
00:14:27.350
That's what I'm thinking because I don't need memory if I, again, do the knit stuff correctly. I don't need what's ta, I don't think I need taskmaster either.
Viktor
00:14:37.220
So think of it this way, CPS are, could be useful to make something slightly better, but there is, there are very few cases where it'll do something that cloud code is not already doing. Like I use memory MCP. Cloud code already has memory, right? I use taskmaster mainly to record what should be done and go through it. Like, I don't know, there will be 50 tasks for this, right? You can extract, instruct cloud, cloud code and say, okay, create a to-do list, as a file. It already does that internally, but kind of, okay, let's create file with everything we are going to do and talk about it and then modify it and uh, make it a checklist, right? And, oh, done. What's next? This. so there is nothing special with CPS that you would say, oh, this is life changing kind. Oh, you know, I cannot do it with cloud code, especially if you are in, you probably are, you have C eyes for the things that you need. So
Darin
00:15:40.938
that's the black magic behind this right now is how does it know? What tools it needs to use. I mean, it's just, I mean, I know it. I know it knows. It's just the, the amazing things of, let me put it this way. If I gave a C-level person, this goes back to, what was it, Shopify or Etsy? It was Etsy, you know, where every C-level had to do a deploy.
Darin
00:16:16.143
And that they had to, they had to go and click the button. How much more now could you get a C level to actually make a legitimate change? A change that then does the deploy. I mean, think about it.
Viktor
00:16:33.744
Imagine now to go a step further and you have that Cloud MD that really nails down the project and everything related to the project. It specifies exactly how it should be work, worked on that project. Then anybody, not C-level, kind of like, uh, I don't know anybody Junior.
Viktor
00:16:55.109
Oh, there is an art on actually constructing all those things like Claude md and few others, right? But if you spend time setting it up, it'll know what to do. It'll occasionally re forget because sessions are some kind of dark magic. but if you don't work, let's say that you have relatively short sessions. Yeah. It'll know what to do as long as you explain it what to do right now, don't try to explain it. Everything, just kind of as the time goes, as you see that it's not doing something that it should be doing. Tell to memorize, right? Start constructing that knowledge base. And then you give it to your C level and say, okay, so, um, give it to your executive in your company, and then, then you say it was nice knowing you. I assume that I'm not needed anymore. Right. I'm exaggerating. I, I, I don't believed that at all, but yeah.
Darin
00:17:56.411
Well, if anything, what you were saying there I think is key is we've always talked about having great business requirements documents. I remember being at clients, there would be teams of people cranking out reams of paper week after week after week, and now we actually ha have a living breathing document in a markdown file. Or should have a living breathing document in a markdown file that as we make changes to that, the agents wake up and do their thing.
Darin
00:18:33.748
Well, humans aren't unsupervised today. Think about how many managers are in companies that do nothing but supervised people.
Darin
00:18:40.933
So we still have to, somebody has to manage that. So I guess that's what those of us that are at the bottom of the food chain that are actually hands on keyboard now are hands on keyboard directing the agents. And we're in a more managery role than actually doing the work. 'cause I, again, in the couple of use cases I've done with this, it's like as much as I wanted to go in. And write the changes that I knew that I wanted. I chose not to, and instead told Claude code to make the change.
Darin
00:19:19.241
Now, if I would've had the init, right, and this goes back to the, the Claude md, knowing that, oh, okay. Hey, look, if, if a variable isn't being used, market final, or excuse me, if a variable isn't being mutated, market final. And there's other things that I'm learning. It's like if there are any unused imports, get rid of them. Right. These kinds of things. If they're in that, I don't even have to set it up that way. It's just, that's the full context.
Viktor
00:19:51.175
can easily for forget, but that's where slush commands and all other ages have something similar come in play. You can create one is that has, I dunno, 17 rules among one. One of them, check finals. I. And if it forgets, you can just say, okay, when I'm finished, I execute this command. That will go through the checklist, which is probably what you would do as a human as well. You have some kind of checklist in your head or in paper or whatever. You have a checklist. So create a checklist. Okay, we are done. Go through all the stuff over there.
Darin
00:20:24.242
Yeah, and the key part to that is it's doing what the human should be doing. And in theory, the machine is gonna do it more consistently than the human I.
Darin
00:20:37.794
Isn't that what we all want? We want the machine to do our work for us. We shouldn't be scared of the machine. But we should also have, Ooh, I don't wanna use this word. I'm gonna use it for the moment. Respect for the machine. Because if we tell it, if we don't give it enough context, just like we didn't give a newbie on the team context, we can't expect good output.
Viktor
00:21:02.619
Even if, if you think of context as and prompts. Being code. Imagine that the prompts are code and context is a prompt, essentially, right? Uh, so imagine that that's code, right? Then actually it's the same story, right? Oh, if your code is not detailed enough, it's not doing what it's supposed to be doing, right? You did. If you didn't contemplate all the different conditions that might happen, your code will not do what you wanted it to do, correct?
Viktor
00:21:37.269
thing goes with, uh, with prompts, with vibe coding, right? Yeah. The, if you're not detailed enough, if you say just, oh, uh, make it work. It'll make it somehow something who knows work, right? The deeper you go, the better it'll do.
Darin
00:21:57.429
And if it's all written down and archived, for lack of a better term in a file or whatever system you're using, whatever, however that memory is, it'll just do it over and over and over again. And when you get a new feature request in, uh, will the agent be able to do it? Don't know. But I can guarantee you that the Stack of close it out for lack of a better name, where it does all the things and making sure that all those things always happen no matter what. Man, that's amazing.
Viktor
00:22:31.815
What makes me very excited is actually the upcoming startup scene. So how, how did it work before? Right. You, let's say two of us, right? Usually very small number of people. We want to, we have this idea, we want to create a startup, right? Soon after, maybe you, you, you start, you reach the point that you have 10 K in yearly revenue. If you're very lucky, most likely you have minus 50 K in your revenue, right? That's how it works. And then what do you do? You ask for VC to to get another five people because you cannot do, two of, you cannot do anything. You need five more and you're still losing money, and then you get 10 more. Maybe when you reach like 50 people, you start churning some positive revenue, and that's, if you're extremely good, extremely lucky, which, which is startup scene still does not happen. I believe that we are going to see startups that start getting real revenue with two people. They, will need to expand. I'm not saying, oh, two people will reach $1 billion revenue with two. I'm not saying that just to be clear, but hey, we can get very, very far and especially in the future, you know, things will improve. We can get very, very far. Two of us only,
Darin
00:23:53.941
I mean, there are the predictions that, you know, at some point there will be a one person billion dollar company.
Darin
00:24:01.209
think it's possible. but that's not 1 billion in profit. That's 1 billion in revenue It may cost 5 billion in
Viktor
00:24:13.057
No. But, the problem with startups is that, yeah, you, at some point you start earning money, but what do you have? 10 people, 50 people. How much is that a year?
Viktor
00:24:24.961
That's a lot, right? Say 50 people and let, let me be as pessimistic as as you can get. Kind of. We are neither in states nor nor somewhere else. Let's say Europe. That's what, a hundred K per person and I'm being very, very, kind of
Viktor
00:24:41.581
makes it easy. That's five 50 times 100 K. That's, uh, that's 5 million. 5 million in costs, not counting everything else. Let's say we reached seven. Now I can be on two
Viktor
00:24:58.348
plus the two of us. So let's say that I'm on 2.5 million costs, which is a huge difference compared to seven.
Darin
00:25:07.673
Well, in the other thing too, with the humans, we're recording this July 2nd, 2025, in the Northern Hemisphere. Sorry, European people. basically you just got back from your June vacation and you're getting ready to go on your August vacation. Excuse me, you went on your June vacation, now you're getting ready to go on your August holiday. I think that's the, the proper way to say it. that's impacting, whereas with agents, in theory, they work 24 7. Which is what our executives want us to do Anyway,
Darin
00:25:48.152
It's close. It's close, but again, it goes back. I think it rewinds back to what are the managerial instructions, what are the business instructions if those can be captured in words and thrown in a markdown file. The sooner we, I say we, I'm gonna say continue to say we, the sooner we can do that, the faster we're gonna get to that point to where things are just working all the time. And the request for, Hey, I need that new Max studio that's got, you know, 128 gig in it, that cost $8,000 I need that. Okay. Great. 'cause $8,000 is gonna be cheap.
Viktor
00:26:29.542
Going back to, and I mentioned a couple of times in other episodes to your gi uh, janky issues. Imagine a hundred issues, just kind of like fix all of them in separate prs in containers. It is not going to work, but it's going to get you 60% there and I'm being very pessimistic now.
Viktor
00:26:52.572
no. While we are talking, you could have had 40% of a hundred issues solved while we are doing this conversation. Not a hundred percent of those issues. You said it 40%.
Viktor
00:27:07.005
And then what we would do, would you be solving 60%? No. What you would do is go back to those issues, check one. That can take time. write the additional instructions in a comment, and then let it work. Go to the next one, check it. Additional instructions, go to the third one.
Darin
00:27:27.593
Lemme ask this question. This is an ex existential threat, I think, but it's not At the same time, did we ever really want to write code? I. Did as a human, did we ever really want to write code?
Viktor
00:27:42.594
Now you're touching on a subject. Uh, when I start speaking about it, I think that I make quite a few people mad. I think that good coders are not people who spend majority of their time writing code. I think that good developers are people who spend the majority of time designing. Figuring out and doing all sorts of activities and then writing code is just chore, I definitely feel like writing code is chore, What I really want to do is, okay, how, how can I do this? What should be the flow, what should be the design, and so on and so forth, right? And I'm talking about new features now, not necessarily, fixing issues, which is a separate discussion, but that's where I want to spend my time. That's where I, that's the part I truly enjoy. I don't enjoy writing infinite number of lines of code. I mean, I'm not miserable doing it, just to be clear. But I'm more happy trying to figure out what should be done, how it should be done, why it should be done, what is the architecture, I feel that that's the real job of a developer. Like, okay, let, let's change the subject. Let's, let's say that you're, you're a writer, you're a book, book author. What do you think is the primarily job of a book author? To write the words of the book or to figure out the story. To figure out the details, to figure out the flow of the book, and so on and so forth.
Darin
00:29:19.650
It's the world creation you're having. It's, you have to understand it's like the, the sitting down in front of a typewriter. Yeah. Some said typewriter, not a computer to write out your words or you're using a yellow legal pad to actually write out your words. Literally, that's just, that's chore. I'll use your word. That's a chore.
Darin
00:29:43.095
But I can't start doing that. And this is where people, I'm glad you use book author. This is where you have the, uh, the white sheet syndrome. You're looking at a blank page. It's like, what do I do? And if you hadn't done the world creation first, you'll be stuck on that white page. But if you've done the, but if you've done the world creation, you may still look at it, but at least you're gonna be able to get some stuff in and then guess what? You edit and. If that doesn't go away, you're not gonna get it out right the first time. Just like I have been massaging both Cursor and Claude to give me what I want. That's never going to change until it does. I think it will change at some point. I,
Viktor
00:30:26.276
Yeah, but that's precisely with the change that I know. Book cultures that stare at the blank page of the second chapter as well, just to be clear.
Viktor
00:30:41.756
Yeah. You have general idea. This is the general story and then you narrow it down or chapter or whatever and you still need to figure out within the broader context was the second one and then you stop. And repeat the process.
Darin
00:30:57.766
so listening to this. I'm gonna send this down and we're gonna wrap here in just a minute. What I'm hearing, and probably incorrectly, is that Agile is dead and Waterfall is the new way. In this age, agentic world,
Darin
00:31:21.071
all the heavy documentation and getting all of that right first before you have the agents do the work.
Viktor
00:31:26.786
No. So I mentioned previous episodes, maybe three episodes before that. Uh, if you remember that I am on a third or fourth or fifth duration of a project that I'm working on right now. If you remember when I was saying, Hey. Imagine that you've worked on a first iteration for a month and realize that it's wrong, I cannot figure, it doesn't matter whether we are using AI or not. I cannot figure out everything from scratch. I'm not going to build that world from the first go. I'm going to build a world, and then I'm going to modify the world, and I'm going to modify the world again. And eventually by the end of writing that book, the world will be fully complete. There is work that you do in advance, but there is a lot of iterations, that's in a way closer to Agile than Waterfall. Right? With the major differences that everything is so much faster, I could do the first week's worth of iteration in a, in two days, say, okay, so. General idea mostly. Okay. Implementation, 70%. I don't like it. It's wrong. Wrong direction. Let's start over.
Darin
00:32:43.286
So, let me rephrase again. Design is even more important than it's ever been before.
Viktor
00:32:52.509
It can be iterative. You don't have to come with a final design. I mean, nobody can come up with a final design. Design of every single detail. It doesn't matter whether we use ai. We don't use ai. Whomever says that I can do the final design before writing a single line of code no matter how I do it. That person is lying to you or is willing to accept failure at the end, one of the two. Design emerges It's iterative.
Darin
00:33:20.779
Well, we've been all over the place yet again. Will we revisit this? Probably. When, not sure, but for now, what do you think? Head over to the slack workspace. Look over in the podcast channel for episode three 15 and leave your comments there.