Viktor
00:00:00.375
People who maintain project and are not good enough with agents to fight agents And this is the key, right? If you think that your manual review process is going to work in today, you're terribly wrong. And I feel that's where most of the contention comes from, Without AI, six thousand lines of code is very different than with AI. When I say with AI, I mean AI as a maintainer, as a reviewer I feel that many maintainers are actually, falling behind, and that could be their issue
Darin
00:01:43.107
Imagine you're an open source maintainer. You get this PR in from somebody you've never heard. It's about 6,000 lines. All the tests pass, all your tests pass, all the tests they added pass, and you look at it and you can see that it was all generated. Not assisted, generated. What are you gonna do with that PR?
Darin
00:02:06.299
Because I've been seeing all these generated PRs come in that look like a bunch of crap. That's how I
Viktor
00:02:11.106
yeah, but, I've seen assisted code that looks like crap AI-assisted code, just to be clear. I've seen non-AI-assisted, the code that looks like crap. It's just that not people rarely are capable of creating so many lines of crap for a PR. That's the big difference. But when it comes to 6,000 lines, I would actually be very grateful if somebody would tell me how do I distinguish AI-assisted from AI not assisted or autonomous AI code. I cannot distinguish those
Darin
00:02:45.394
Today's conversation is sort of based around what somebody wrote up as an open source maintainer, and it's basically saying, " I just don't want your PRs anymore. I just don't."
Viktor
00:02:55.484
I think it's crap, to be honest. So I feel that the responsibility of maintainers in open source projects is to guide and help and bring people in to contribute. That's their first responsibility over anything else. Whomever thinks that you're a maintainer and your job is to primarily write code, I think you're in the wrong business. It's not business, but you're in the wrong place. And I think it's beautiful, really beautiful that people now with help of agents or agentic AI are more willing to contribute because it's easier, because it's less daunting, and because it demands less of your time, and so on and so forth. It's beautiful, and I'm fully behind it, and I think that we should support people creating those PRs Even if that means that we need to spend more time on it. pick any of the projects I worked in or working on. A, if 100% of my time would be sifting through massive number of PRs created by others I think that's beautiful, and I would consider it mission accomplished, with or without AI. Does not matter really. Now, if you put AI into, and say exclusively AI AI helps me review code like I was never able to review. I can easily find inconsistency in code itself, and I can focus on architecture, and I can focus on the feature itself, and that's beautiful as well. I love it because before I could not spend enough time on those things. I could not spend enough time on architecture. I could not spend enough time on features themselves, because by the time I review the code itself to find nitpicks and silliness of the code itself, I'm so exhausted and so much time passed that I cannot actually spend time on things that really matter. So both things are great. CodeRabbit, Greptile, whichever one you're using, Coder, they can eliminate the obvious issues. I c- I don't have to look at those, or code the issues. I don't have to look at those, and I have more time thinking about the things that matter for real on that project. I love it, and I'm pretty sure that I'm in a minority of people on both accounts
Darin
00:05:24.459
Well, you are, especially against what DPC wrote. I don't know what DPC's name is. I'll include a link to this article down in the episode description. But basically it's like, "Look, don't send me more PRs. Send me anything else, just don't send me a PR." We've talked about this before. It's like even you said, "I'd almost rather have issues than PRs," or at least you said that at one point. Have you flipped on that?
Viktor
00:05:51.421
I think that you as a user, you can just send me an issue and I will be able to do it now faster than before. I'm still behind on so many, but let's imagine that's not the case. Was-- I was more referring that you as a user of a project I'm maintaining, it would be enough if you open an issue. Now, if you open a PR, that's still better because I can now not only see what you wrote about it, I can see how that featured or fixed or whatever works. I can run it. I will get much better idea what you want and worst case scenario, which is still great, okay, so this is really what you need. This is what you want. I run it, I see it, I can feel it, I love it, and then worst case scenario, okay, let's throw away this PR now that we understand and I have a better understand-- Wha-- Now that I understand what you want and given that I have better understanding of the project, I might even create a new PR. But that PR was still helpful. The… And that's the worst case scenario My question is, how do people review today? I can tell you how I review, and that's CodeRabbit did its pass, are there things that are flagged by CodeRabbit, Greptile, whatever I use both. If there are, should we fix it or no? If we should, f-fix it, and then we'll continue the conversation. Cool. Code problem's mostly gone and then I review it, and I review it again with Claude, okay, CI passes, reviews are fine, we passed through the phase one, cool. Phase two what is this about? Can you find additional issues? Because there is a difference between Greptile and CodeRabbit just running and having only the context of the PR, maybe the project, and there is a very different thing when AI reviews it but with my guidance. Look for this. Why is that? How about this? I can do 6,000 lines of PR with Claude probably the same time as somebody would manually review, I don't know, 600, one-tenth
Darin
00:08:03.413
in this article, DPC basically breaks down four items. I'm gonna give you the reasons. Unknown contributors are a security risk. Supply chain attacks are real and ongoing. We've talked about this. Style and approach disagreements require synchronous resolution. That can cost a maintainer time across time zones. LLMs eliminated code writing as the bottleneck. It's true. The actual bottlenecks are understanding, designing, and reviewing, none of which the stranger's PR helps with. And you've already touched on the reviewing part of this, if we're not going to accept PRs, then we're taking everything onto ourselves. We've talked about this before. Are you a bene- benevolent dictator for life for this project? So when you die, it just goes off into oblivion? Or is it really a project that's got a community around it? If it's got a community around it, you shouldn't be the only one knowing what's going on Now, this guy is a Rust maintainer, but it doesn't feel like it's just a Rust thing if, or it's just an LLM thing or agentic AI thing. This is a, just a thing, right? This is what we're running into now
Viktor
00:09:11.156
Exactly. first of all, we were running into that before. Can I dare you to submit a PR to Kubernetes and see what time, what type of backlash you're going to receive? You're going to feel stupid, and th- that's fine, they want quality and stuff like that, but sometimes those comments are not really nice. Sometimes you're rejected and so on and so forth. But I would like to go back to the first point you mentioned. It was something about, unknown contributors. So let's start with this. Unless you started the project yourself, everybody on that project for eternity is going to be unknown committer once So basically if you say un- unknown committer is bad, and I understand that there are risks, of course there are risks, but that's the nature of open source. But first commit is by definition unknown contributor unless we kind of look globally, are you known to GitHub in general, and if you're known to GitHub in general, then you're not unknown, which I guess is not the case. So everybody's is at one time unknown contributor. I don't even understand that. That so sounds elitistic, I'm a maintainer, I'm God," stuff like that. Cool. Then just Close PRs for anybody but you. That's your option or pick a cousin or a friend or something like that, and then for two of you and that's fine. And I have nothing against, that's your choice, it's your project. But if you allow PRs, then you allow PRs, and you judge PRs, and you instruct people how to improve them. That's fine. But don't say unknown contributors, please
Darin
00:10:48.646
It's funny you said that with GitHub because GitHub, one of the key premises way back when was it was social coding. So you should know people that are around there
Viktor
00:10:57.951
W- what I can tell you is that on my pet projects, they are not big, they are not popular and stuff like that there are contributors that never wrote code before they started contributing to my projects. now tell me, isn't that beautiful?
Viktor
00:11:15.514
Kind of somebody's just starting to write code because they feel enabled, empowered with agents. Amazing
Darin
00:11:25.675
It is good because that means they are figuring out how to maybe move through their career. Maybe they were just trying to get caught up on a project or something they just really love working on. I have a couple projects that I love using that when I can make a contribution, I will. That's just the way I do it
Viktor
00:11:44.937
I was in situations where people were very negative to juniors joining a company. Same story. "Oh, you don't know. You don't have 75 years of experience. You don't know this system." Stuff like that. Come on, you also were in that position at some moment.
Darin
00:12:01.221
Well, That's actually the first bottleneck that DPC brought up, was understanding how the thing works. sure an LLM can help the actual maintainer because the maintainer already knows everything, but how much can it actually help a new contributor? Now, I could argue if your project is old enough, the LLM already knows everything about it Good, bad, or indifferent?
Viktor
00:12:27.816
Yeah, but even if it's new, so okay, so isn't that how we start the process of that potentially being a long-lasting contributor on your project that will need your guidance and help until that person becomes productive in your project? It's an investment in people
Darin
00:12:47.907
Okay, let's pause there for just a second. How many people get into open source projects to manage people?
Darin
00:12:56.943
Isn't that the problem right now that we're facing? Is sure, I get a contributor, that means I have to have a relationship, quote-unquote, with that person in some way, shape, or form that's going to be a top-down relationship management l- relationship.
Viktor
00:13:17.458
Look, in cases you allow PRs, if you signed up to be maintainer of a project, you signed up to be that person, that manager. That's the job That's the job. So it will be the same with me complaining, "Oh I became a product manager. It's not for me." Well, why, the heck did I become a product manager? I mean, I have answer to the question to find out that it's not for me, right? But that's the job. You cannot complain about the job you picked. Close it. Like, uh, Wasn't it Hashimoto that closed the-- ghosted two contributions? Respect. Cool. Okay, so you set it clear. No contributions. Cool. I understand now fully what it's all about. No, I think it makes perfect sense. That's your choice
Darin
00:14:04.244
And that's what I expect to see happen more and more for projects that are like that level. There's not 1,000 Mitch Hashimotos existing in the world. uh, SQLite, SQL- SQLite actually guys. There's three guys that maintain that. That's it, three. Their code's running on the outside world of-- or outside of the universe, literally. Three guys That's all they
Darin
00:14:40.814
But now if you're going to flip it and you're going to allow PRs, you have now moved from being an individual contributor to being a manager
Viktor
00:14:51.608
And you have responsibility to people who are less experienced in that project, which is literally everybody else
Viktor
00:15:04.587
Hopefully, if you play your cards right somebody will be more experienced and that somebody will be promoted to maintainer of that project but still the story stays, right? Kind of maintainers are more experienced than contributors. Easy. And your job what is your job with less experienced people? To teach them
Darin
00:15:26.947
conundrum here. One of the other bottlenecks that DPC called out was designing the right solution. This is where you've got to go through issues, conversations, comments, everything else. I can argue an LLM can make it a lot faster through that than a human can.
Darin
00:15:43.365
As a human, I can gather those pieces together and then say, "Hey, Claude, go take care of this. Gi- give me some options."
Viktor
00:15:52.525
Yeah. And that includes start over Go- going back to my previous story. Okay, so functionally, this is the feature. Architecturally, it is not. You can redo it or update it, or you can just start over. I start over very often with Claude. Nothing to do with the contributions, okay, so we got to the point mmm, where we're blocked or this is not the architecture I want or what so not, but there are-- those are the good things. What did we learn, right? Oh, we learned this and that. Cool. Let's start over with those learnings because writing code is cheap, right? It takes close to no time to write code now, and so we can go to infinite number of it-iterations until we land to the one we want, and there is nothing wrong with that either. That's why I was slightly correcting you when you were saying that I said that kind of only issues. I think all issues are enough, but hey, if you give me a PR, that's better than an issue
Darin
00:17:00.725
I like how you said we can generate code faster than ever before. You said a variation of that. You didn't say we can generate good code faster than ever before. You just said we could generate code and then iterate. That's what we did as a human anyway, right? We'd write our first pass. How many times did your first and only pass of code make it to production?
Viktor
00:17:27.711
Okay, yeah, if you-- Okay uh, substantial PR made to production from the first item, never
Viktor
00:17:36.417
Yeah, c-code, exactly. I mean, By the time it reaches… it becomes a PR, it might be fifth iteration of it, so maybe PRs do go to production but code, no
Darin
00:17:48.167
I think the key point to this is the PR is the last thing in the process, though. We've done our research, we've done all the other stuff, we've written the code that then gen- gets us to the point to where we can do a PR
Viktor
00:17:58.917
Not anymore. I find PR easier to deal with when in terms of communication. even when I work alone sometimes I watch and redirect, like I'm in it. Sometimes I let it rip. Anyway, when I want to try out myself the feature, let's say run it I tell Claude, "Okay," "You rip it until a PR." Because for me, PR is the easiest one to review and it's easier, easiest one to run. GH PR checkout and the number, right? And I have it there, and I run it, and I see whether it works, it doesn't work, and so on and so forth. And from there on goes decision. Okay, should we improve the P… Is it good as is, option A. Should we improve it, option B. Write down what we learned, what works and what doesn't, and let's start over. All three options are fine. You close the PR, that's fine as well
Darin
00:18:58.014
This is what we're talking about in PRs was the last point is reviewing the result because It's his statement, or not necessarily statement, but it's, there's a fixed cost to reviewing PRs to him. Like every PR to him is roughly equal. That's not true in most cases for me, but let's say that's true. One of the worst cases you can get into is that looks good." Like what you were just saying you do a GHPR checkout, you bring it in, you test it, and it looks good But there's a subtle bug that you don't see, right? It's a latent bug that will bite you later on. So the-- what came in was plausible, mostly correct, but it was actually wrong in the end. We see this all the time too, because we'll put in a fix that's… This is what we call a partial fix, right? Or it's a partial new feature. Not on purpose. We thought it was fully formed, but in reality, we just missed things because fill in the blank. Doesn't really matter. So there's bottlenecks in getting these PRs processed correctly to where we feel like we can take them in. Again, a 6,600. If I got a one-liner PR, like changing the color for something because I wasn't consistent throughout, okay, great. I should have done better in my CSS. I'll take that one. But if it's something I've worked on for a really long time and I've been the only person working on it, I go back to cURL. That's another one to think about. would I want to put a PR in against cURL? I I… Even if I thought I found something, I think I would probably write it up as an issue, because the guys working on cURL, Daniel primarily has forgotten more about cURL than I'll ever know. The same thing with Mitchell with Ghosti, right? He's already forgotten more about Ghosti than I will ever understand about it. So there, there's this tension that we have to try to figure out how are we gonna deal with it. Again, if you don't want to deal with people, don't allow PRs
Viktor
00:20:51.299
Exactly. Then Don't deal with people. It's fine. It's fine. Everything is a learning opportunity. Let's say 6,000 lines and you say, "Oh, okay, even with Grep tile and this and that, I cannot review that, that much. We don't do m- we don't make such big PRs in this project." Cool. That's a comment in that PR. Start over, make five PRs That's a comment, and that person learned. Okay, so I should organize it differently next time. And that person hopefully is not going to be mad at you because you gave honest feedback, and that person learned something, and that person goes to Claude Code and says, "Hey, Viktor said break it into five." Cool. Let me go and fetch coffee
Darin
00:21:39.263
Well, That's a flip of actually what we want as maintainers, but it's, you're feeding it back. What as, as a maintainer, what I want is a user coming to me is "I see X, but I expected Y." You flipped it just like, okay, maintainer told the contributor, "Hey, look, that's great, but instead of one, we need five."
Viktor
00:22:01.846
That, that feels much better than rejected It doesn't cost you much Even if it does cost you, I still argue that it's investment in people you want your project to have contributions
Darin
00:22:15.086
I want to go back to security for just a minute because if we're getting contributors or if we're getting contributions in from contributors we don't know, but even if we're getting contributions from contributors that we do know, boy, that was hard to say. I go back to XZ, right? The guy played a long game to get in and put a payload in. There's still risk in that. So to me, the argument is understandable, but it's also flawed because a new contributor doesn't mean that… Being an old contributor doesn't mean you're not gonna do silly things from a secure or a supply chain perspective
Darin
00:22:56.280
xZ was way before AI. Well, Not necessarily way before AI, but it was happening. It was social engineering
Viktor
00:23:00.738
Exactly. The difference is only in quantity, but not necessarily percentages. So i- if you say, "Hey, there are more PRs now that are made by people trying to exploit something," is it percentage-wise more or more in number? Because we have everything more now
Darin
00:23:21.828
Another idea that we want as maintainers, we want people with different domain usage. I'm saying that sort of in a weird way. I've seen Jenkins used in a bunch of different ways besides just doing CI/CD I've seen normal Java apps building JAR files, WAR files, container images. I've seen hooked into embedded systems. I've seen across the board of how that tool has been used used in ways I would have never thought that it could be used Used in ways that I look at going, "Really? You needed that much? Isn't that what Cron is for?" Seen that too. But that's the kind, that's the kind of i- information that I do want as a maintainer is, okay, how are people actually using what I'm producing?
Viktor
00:24:11.911
forget that you ever worked in a company around Jenkins and all the time that you've worked with companies that are prospects or customers, right? Ignore that type of feedback. How do you get feedback that leads you to learn how Jenkins is used if not through PRs or issues? It's rare that people call you, kind of like a random open source user pings you and says, "Darin, let me tell you, how I use Jenkins."
Darin
00:24:44.215
But that's, not the norm. That's, that happens every once in a while. I typically see it in issues. That's where I see it. " Hey, we're trying to do this." And that's where you start saying, "Oh, okay, maybe you want to think about doing it this way," or, "Oh, that's actually a great idea. We should make that easier." Those are the kinds of things that we want to think about What we want as maintainers, we want detailed bug reports with reproducible steps. Please? Pretty please? getting an issue that says it doesn't work and that's all there doesn't help
Viktor
00:25:16.063
Now, let me flip it to the beginning of conversation. If you would get a PR that fixes that issue, even if it's not written in a way you like it, isn't that even more helpful than exact steps?
Darin
00:25:30.023
It can be. It's not so much that it's not written the way I want it, 'cause I can, I can put up with a lot, but it needs to give me enough context to understand what's going on. Not context for the AI, context for me. It's like, what, what's missing here? And that's where I would start up a thread within that PR saying, "Okay, what is this? I don't really understand what you're trying… I mean, I can see what you're doing, but what really sent you down this path that caused this problem?" Because let's say I just don't see that problem in my setup, which is a possibility
Viktor
00:26:01.478
The direction where we are probably both of us going is that to do the right call, you need information and that information is issue description, steps to reproduce it, including code changes that fixes it, That's all the information that you're looking for essentially And then if you include the agent, then you can sift through that information faster. Power to you. But you get, hey, six lines, six thousand lines of code of information. Brilliant. I'm not gonna merge it, but brilliant. I, I got the information. Step number… Step one, checked
Darin
00:26:40.122
This is where another one of the ideas would be you want to show me how it works, this 6,000-line change? Fork the repo and show me something running, right? Because it'll be harder for me to argue with that. Just fork it. I mean, It's open source, or at least m- not open source from a licensing perspective, but the code's there, so obviously you can fork it, or hopefully you can fork it. So if I can fork it and I can put in my change and then show that as a demo, going back to a couple episodes ago is, okay, how am I going to demo this to the maintainer to say, "Pretty please, I don't want to maintain a fork of this. I would like for this to be in core product. What can I do to help get that there?" And by showing it, it's gonna be better than s- the maintainer having to dig through the 6,000 lines. I don't know why we're sticking with the 6,000 lines, but it's just a big number and it sounds good. I mean, That would be useful to me. And it's like, oh, okay, that sort of makes sense. I'm-- I'll go with that But i- isn't all of this just gatekeeping in the end? Isn't that what open source really is, is about gatekeeping?
Viktor
00:27:42.792
that's where I'm going and why I'm disappointed at such negative reactions because it's, gatekeeping that existed long before AI, especially in open source. I mean, Not especially, but in open source. Now that quantity of everything inquiry increased, gatekeeping increased as well. Hey man, I can reject thousand PRs now this week instead of hundred. Power to you
Darin
00:28:08.188
Well, That's sort of the standard way too that we would get in. We'd do a small PR, a little bit bigger PR, a little bit bigger PR, right? You build up the trust with the maintainer. Again, this goes back to XZ as well. But man, it's like now according to his model, it's okay, even that small PR at the beginning to change the color on something is a no-go. Why do we want to do that? If you don't want to allow contributions, don't allow contributions. Just say it
Viktor
00:28:36.788
Look, I think it's inevitable in terms that… forget about contribution for a second, right? Would you agree that you are now in a batch, in a feature, in a PR, that you're working for yourself, your pet project. Would you agree that you're noticing that actually you're working on bigger chunks now than before?
Viktor
00:28:59.618
And my best guess is that you're s- working in very small chunks among other reasons because, hey you don't wanna spend three months until you see this happen, right? how can I just change the color right now and I'll, I'll do the rest later, my PRs that I make and merge myself, nobody else involved, are getting bigger I'm, I'm going, I'm going to cut the release of one of the projects probably tomorrow. It's going to have probably tens of thousands of lines of changes 5 PRs approximately, I think.
Viktor
00:29:34.622
No, not really because I tested it to death. I spent most of the time testing it really rather than writing. I spoke with my underlings to death about it. I'm confident. Now, is there a chance that something will not work? Of course, there is a chance. I be most likely able to fix it almost instantly? Yes. Instantly after I detect it. So it might exist there for months, but the moment I detect it, it's gonna be fixed. There will be almost no, no time between the two, two actions, detection and then fix
Darin
00:30:11.875
What's going to happen to open source if DPC's mentality and Mitchell's and, 'cause I, I even also believe that cURL is the same way, not allowing PRs. What's going to happen to open source if that keeps on spreading?
Viktor
00:30:24.285
I think that existed long time before now. The, just that people were-- you heard about it less, but if you worked in project, you expe-experienced it just the same. But you hear in media less simply because it is socially acceptable to say it now. ' Cause imagine without AI. C-ima- let's say there is a single person. Of course, there is more than one, but let's say there is a single person that was having the same opinion before AI, and I guarantee that there are those people. They could not say it in public ' cause "Oh, I'm not going to accept anybody who is not super genius and has 75 years of experience in this project." You cannot say that. Now, oh, AI uh, because of AI, the thing that I was doing before, now I'm not going to do because of AI people existed. Those people were there
Darin
00:31:17.782
This could be a foot gun too for projects that live and die by the contributing back to upstream, looking for projects like that, and all of a sudden you're not able to contribute back to upstream, then why should people keep using the project? mean, let's imagine this for a second. The, what would happen to Kubernetes if all of a sudden CNCF said, "Okay, n- no more contributions except from these two people for Kubernetes"?
Viktor
00:31:50.804
Do something else immediately. But Kubernetes is very big. Let's go something smaller, right? whatever the smaller is. If I have a problem and f- I'm hitting a wall using that something, and I create a PR, and that PR is rejected, which is very different from I'm guiding, guided through my mistakes, and then we make it right at the end. Just reject it, AI. You know what I'm going to do? I have two options in front of me. Fork it and do the cha-- Uh, uh, actually, not fork it. I already forked it to make PR, right? Maintain my own fork. That's option number one. Option number two is start from scratch. I'm talking about smaller projects now. Ah, really? I'm gonna make the app myself. I'm gonna be the only user. That's fine
Darin
00:32:38.690
That's fine until you get into an enterprise organization to where that's not possible because you may get fired, and now the company is depending on that little app that you wrote. Of course, they could call you back and make a lot of money
Viktor
00:32:52.370
It's perfectly fine for enterprise because it will typical old-fashioned enterprise, it takes them five year to reach the version that is happening right now. So they have five years to figure out before they upgrade to it what to do
Viktor
00:33:07.797
Does the typical enterprise care what's happening in the latest version of Java?
Darin
00:33:11.369
No. Latest version, they don't even care what's happening in Java 11 at this point. Some of them are, Yeah.
Darin
00:33:19.319
What piece of advice would you give somebody working in open source today or wanting to work with open source and wanting to contribute? Is the answer still just open a PR, or is it first find out what this project does and what it wants?
Viktor
00:33:35.559
I assume that-- if somebody opens a PR and that somebody, I don't know how to detect it, but is not the user of that project, that should be rejected immediately, just to be 100% clear, right? Outside of that, I assume that whoever opens a PR is a user of that project, so they are familiar with the project, at least on a functional level, right? How many people are non-Jenkins users are going to open a Jenkins PR?
Viktor
00:34:04.412
Yeah, I mean, excluding I won a T-shirt for some hackathon excluding special cases, but in under normal circumstances nobody opens a PR for Jenkins who is not a Jenkins user. So they know the project to some level, not, maybe not to the level you know it but if you do but they know the project already. They're just not familiar with the code base. They will get there
Viktor
00:34:29.313
Let's say that there are three types of people, and two of the-- first two of the three types existed before AI, and that's the maintainers who really want to grow the community, the contrib-contributors. They're helping them rather than scolding them. Good, positive. People who are just kind of, "Oh you're, you're not uh, you're not every-everybody that-- You're not everything that I ever wished for," type of people who reject PRs because they're not perfect. I don't want, I don't want to know them. I don't want to use their project. And the third, and this is now the new group People who maintain project and are not good enough with agents to fight agents And this is the key, right? If you think that your manual review process is going to work in today, you're terribly wrong. And I feel that's where most of the contention comes from, Without AI, six thousand lines of code is very different than with AI. When I say with AI, I mean AI as a maintainer, as a reviewer I feel that many maintainers are actually, falling behind, and that could be their issue
Darin
00:35:46.503
Well, Most of the, at least… I'm trying to think. I know Anthropic has a deal with open source maintainers to where you can get access, but it's not, or at least at the time it was only for a few months, but then you had to start paying. I mean, If you're now going to have to pay for all your tooling, the chances of a maintainer, especially if they're not in the US, I mean, that's probably a lot biased there, but I think probably US has more, most US people probably have more cash flow than other places in the world. Does that feel right? Am I going way too far out on a limb for that?
Darin
00:36:25.202
Like, a developer in the US probably has more cash flow than a developer in other parts of the world. Okay.
Viktor
00:36:37.869
No, I, I uh, y- n- no place on this planet has such high income for software development as people in US
Darin
00:36:46.730
So assuming that's true and I'm managing-- Let's say I'm working on a project and I'm not in the US, I can't afford to keep paying for a subscription to Anthropic. Then I'm back to my normal days. Or great, I could use open source models, but I don't have the hardware to run the open source models. In order to get the hardware, it's gonna cost… It all comes down to money again. So how do I fund my project? And at the time, I start losing users because they're figuring out, okay well, I'm not reacting quick enough, so they're going down your path. I'm forking it, quote unquote, forking it for myself, maintaining a fork, and then I'll just deal with it myself then why do I need to keep doing the project?
Viktor
00:37:28.442
Yeah. I mean, you know, If that's the situation, that's very sad and I understand, but that's not the reality anymore, you cannot be without tokens. You need to have tokens or close the PRs. Close the possibility to create PRs
Darin
00:37:43.582
I'm thinking ahead for 12 months. This whole no more PRs movement, is that gonna become more mainstream or is it still gonna remain pretty fringe?
Viktor
00:37:54.032
I think that we will have to learn to live with it. Let's put it that way. At this point, it's inevitable. I'm not creating PRs anywhere. My project, other people projects without Claude. Let's be clear about that. I'm not doing that Do, do, are you? W- would you?
Viktor
00:38:12.716
And I'm, I guarantee that we are not 100% of the people with that opinion And that number is just going to go, go up and up and up because somebody who spends, let's say, at least few months with agents that somebody is not creating PRs uh, without them. I c- I can tell you that. And if that means that as as the number of people using agents in general is increasing, means that the nu- percentage of PRs done with AI is increasing as Well,
Darin
00:38:45.599
Well, In theory, we could fix it, quote-unquote, "fix it with tooling," but again, that's going to cost more money. Now, I know CodeRabbit has open source for included for free or some variation of that
Viktor
00:38:58.209
Reptile is also free right? You just need to submit the repo and you get it for free. there's a lot of it for free, really. Maybe not everything you want exactly as you want and things like that. You might not get Anthropic, but even tokens, you can get tokens for free if you just write a nice letter to I don't know, Moonshot
Darin
00:39:19.693
So what do you think? What-- You gonna keep listing out things for me here? if we can get them, great. But it's gonna be like, oof. Sorry to all the people that are getting requests for tokens now
Viktor
00:39:30.563
Yeah, but l-let me go to extreme and say, okay, uh, what if that person cannot have internet?
Viktor
00:39:37.538
Or let's say that this project the rule is that we need to build it and run tests locally before uh, creating a PR. What if that person has a tiny machine that cannot do it? there are always those cases. But I assume that you as a maintainer, you have a machine where you can build stuff and run tests, and you have connection to internet, and now it's tokens. It's new, so we are all freaking out, but the tokens are gonna be equivalent to internet, we just assume you have internet
Darin
00:40:06.261
Once you start using tooling, this could be AI, it could be anything. Once you get start, get used to using a tool, it's hard to do the work, similar work without that tool in the future
Viktor
00:40:20.340
Exactly eventually you might replace the tool for some other tool that is doing even better job, but you're not going back. Hey, no AI imagine never existed, and now what if I cannot run VS Code? I'm growing po- tomatoes. That's the alternative to not using VS Code to write code. I mean, VS Code or similar IDE, just to be clear
Darin
00:40:40.076
Didn't already say that's a, that's a big jump So what do you think? I'll make sure to have the link to DPC's article down in the episode description. You can take a look at it and read over it. Head over to the Slack workspace, go to the podcast channel, and leave your comments there