Speaker labels not present. This transcript comes from a source without per-speaker labels. The vast majority of speech is Jack Wotherspoon. Other voices that appear:

• An MC referred to as "Macey" (intro and Q&A facilitation)
• Audience members during Q&A (unnamed in the transcript)

Names mentioned in the talk include "Theo" (tech influencer), "Mary" (Python coding agent maintainer — likely a transcription artifact), "mental hashimoto" (almost certainly Mitchell Hashimoto, Ghostty / Terraform / "Azure" creator — note "Azure" here is likely a transcription error for a different project name). Cross-reference before attributing.

Some apparent garbles preserved verbatim: "demons versus love" (likely "humans versus slop"), "Forgive us" (likely "Forgive me"), "the war of our generation", "in your queue" patterns, and various awkward Q&A phrasings have been left as-is to keep the source faithful.

Intro & framing

For a while. I was. On. An office. Or anything. They were. Like, oh, they're looking. For folks. A couple. More minutes. Just. A lot of people. Filter in. There's a bit of competition in this time slot that you guys. Might be correct choice coming out here. Congratulations.

Okay. We are going to go ahead and get started. I would like to introduce Jack Wotherspoon from Google. He is working on the Gemini CLI and he's going to be talking about. The war of our generation. Okay, actually, forget us at that. I'm going to be talking about demons versus love. Forgive us. That. Thank you very much, Jack. Round of the box.

Thank you. Thank you, Macey. So thank you all for coming. We've heard throughout this today, you know, AI is becoming so much more popular. You're changing tools. Every few weeks, there's always new models coming out. Things are changing and evolving so fast. Today we're going to talk about open source, how something that has kind of had, you know, social contract and worked the same way for a really long time has started to have a parallelized shift towards like AI and how we perceive open source.

So quickly what we'll cover, we'll cover kind of the old world. We'll set the stage for what open source was. Then we'll talk about how AI is changing that. I use the word slop, but I don't actually really like that word too much. AI generated code is changing open source, whether it's for the better, for the worst. We'll get into that. There we go. And then. We'll talk about the new rules. So how you can navigate open source properly now that AI is really, there's no longer a human connection. Essentially you used to always know when you were in open source, someone tried to pull requests or create an issue. There's a real user on the end. Now we're shifting towards, you're not sure if that's Claude, if that's someone's bot, if that's someone's agent.

The old world of open source

So we'll get back to what open source has been traditionally. It's kind of had a human to human experience. It's been a way where people can come together as a community, build software, learn from one another. So kind of what I mentioned is normally back a few years ago where an open source maintainer or working in open source, you would expect if you see an issue created, that's a real user who's running into an actual issue that you should probably take a look at. And every pull request or code that was put up to your repository was by someone who probably thought about it. Was actually handwriting code.

And there was a social contract. So if you were an external contributor to an open source project, you're kind of expected to read the docs, make sure that whatever is breaking isn't on your fault, it's actually the library or the framework that you are using. And you actually take a look at the code base, understand why something's going wrong before you would put up kind of a pull request. You do some design, maybe you respond to a code review with the user, go back to the maintainer, adjust feedback and kind of iterate. And for them the maintainer side, the other side of the coin, you're providing guidance, you're kind of teaching people, there's kind of a contract there to kind of do mentorship or help people merge quality work into the project.

How AI is changing it

So that's no longer really the case or we're seeing uprise in AI and things are changing. Like I said, you don't know whether or not that pull request is being put up by someone's agent, whether they've even actually looked at the code, any human eyes have been on that code generated. And that's because the rise of agents. And there are so many different agents, there's dozens more, and agents are now becoming really good at long running tasks. So they can actually, you see, Claude running 24/7. Recently, there's everyone's been really crazed with slash goal where you can essentially just run your agent for a really, really long time. People are running them for days on end.

And so code, the other kind of problem here is that code is essentially free. You know, it's just a prompt away. You can type something in and you've got code generated in seconds.

Subsidized inference & the Copilot/Theo example

And these plans that are offered by all the major companies are quite subsidized. So you're paying $20 or $200, but you're potentially getting thousands of dollars actual inference out of those subscriptions. So as the end user, you're not necessarily thinking about the dollar amount when you're prompting all these agents. You kind of feel like you have unlimited resources. So you can just throw something at it and see if it works.

And here's a really good example of this where actually I think starting today, GitHub Copilot has changed from a subscription base to actually paying for the tokens that you use. And Theo, one of the tech influencers actually showed kind of not an exploit, but actually using the subsidized system kind of against it where actually GitHub Copilot measure things in requests. They didn't actually count tokens. So it was just prompts. So if you actually train or had your agent running for a super, super, super long time, you could get thousands of dollars worth out of like $20, $30 plan. So in the case here, a single prompt did over 60 million in tokens, which would regularly be $200 if you were paying for the actual API cost. So from a $30 plan, theoretically, you would have been able to get over $30,000 worth of inference. So I believe started today they've changed this, so don't go home and try this. It should no longer work. You tried it? Yes. Up to me. Okay. Okay. That's good timing. It's good timing.

So AI generated code is now abundant. You've probably heard this before. It doesn't even matter if you're really technical in background. My mom who just got a smartphone only a few years ago, she could probably figure out how to actually get something up and get code generated. So that's kind of where we're at.

Examples of slop PRs (Gemini CLI)

So how do we start to put guardrails in effect on projects? And here's an example. You know, you can just say to your agent, fix all the issues on this repo and then it would just start throwing up pull requests. Generating thousands and thousands of lines of code. And really, you don't have to think about it. There's zero costs, zero accountability. Which opens up another can of worms.

So here's an example. I work for Google to develop advocate. I've been in open source for the past five years at Google working on Google ADK. So agent development kit. And most recently, Gemini CLI. Here's kind of just an example of some of the pull requests that we see. Where you have absolutely gibberish in the actual title. We have pull request templates that we expect to try to help guide how you should be putting out code changes to repository. They didn't fill any of them in. And if you look in the top right corner, it's over 30,000 lines of code change. So that is not going to pass the test.

Live demo: 10 sub-agents → 10 nonsense PRs

And so here's a quick example of how quickly you can actually go ahead and just spin up an agent. We're going to say create, this is Anti-Gravity CLI one of our products. And we'll say create 10 sub agents in parallel to go ahead and just create nonsensical pull requests to this repository. And we'll quickly see how in a matter of about 30, 45 seconds, we're going to have 10 pull requests up against this repository. We didn't say what features to build. It's just going to make up random stuff. So you can see it's making a culinary slop chef. We've got a bribe laundering engineer. I have no idea what that is. And then it's going to go ahead and actually start putting out these pull requests. So this is kind of the open source world that we've now come to. People can throw things, they can just absolutely create pull requests at a whim. So how do as maintainers, as stewards of the open source community, how do we fight this?

So we'll let that run for a few seconds and then we'll prove that there are 10 pull requests. At.

Maintaining code isn't free

So really this comes down to maintaining code isn't free. Generating code is free like we talked about, but maintaining it is not. And that's really kind of where this battle is now being fought.

So GitHub released that over 45 million pull requests were merged per month in 2025. Like we said, how fast AI is evolving. This number is probably super, super out of date. I think last I heard GitHub's been in the news a lot recently for like trying to keep up with the pace of the AI and all the code generated. I think last month they said it was over 200 million pull requests. So we're already seeing a 5x right there.

And so this leads to a lot of issues. We've seen multiple different companies already starting to face this. So curl actually had basically a swarm of AI agents and bots creating fake security reports. To the point where they were actually getting flagged by all of the systems and caused them a ton of headache. We see in other companies put in their contributions in their open source repositories that they just will not take anything that is pure AI generated. So 100% generated. And then there's Tldraw also is closed external pull requests. So essentially it's gotten so bad that they just said we're doing it ourselves. We're not going to take anything. And then Ghostty is an interesting one which has this belt based system which we'll talk about a bit more. In a few minutes.

Main issue 1 — the drive-by PR

So what are the main issues? Breaking down the barriers with AI should be a win. Right? Makes it easier for people to contribute to these projects. But what's the flip side?

And this is one that I've seen a lot and it's the drive by PR. Right. So you have, you run, you're using a library or a framework or whatever it may be and something doesn't go wrong. You say, oh, I've got the error message. Let me just go and fix this. You know, I know it's an open source project. Let me go and contribute to this. So you just throw in your stack trace, you clone the repository, you know, ask your agent to fix it. So that takes like 30 seconds on your end. But the trick side, and we'll, we'll assume that this is actually good code generated. We'll assume that. For this scenario. Then you've got the maintainer who actually has to go and review that. So they're going to take their time, at least at Google, we still kind of hand review each PR that goes in. We have like code reviews that are automated and we'll review the code agent first, but then it still gets to a point where a maintainer looks at the code and ships it with all the security, vulnerabilities and everything right now that has been at scale. We make sure that humans see everything. So then they go and they post some feedback. You know, hey, maybe change these few things. And drive by PR really is someone confident. They had no expectation that they were actually going to have to follow up or do anything right. So it might have been a good first judgment being like, hey, I could try to fix this. But they're not going to come back. So you just have a prompt and forget it. Where now it's either the maintainer needs to come and kind of take over that pull request. Or it just kind of floats away to the U. S.

Main issue 2 — parallelized agents

The second one is agents like we showed in that quick example is 10 sub agents. It's super easy to paralyze work. Unfortunately, we have not figured out how to do that as humans for our own ranks. So we might be able to create code super, super fast. For the burden on the maintainer. If we spin up 10 pull requests in a minute. It's not going to take 10 seconds to review all that code generated. So there's a disconnect there.

Main issue 3 — trust breakdown

And trust is somewhat breaking down. Like I mentioned, you don't necessarily know whether or not a human is on the other side of that code. Whether it was even looked at. So when someone puts up a pull request, normally you would have gone back and forth. Hey, why did you make this design decision? Nowadays, I don't know. Gemini told me to or Claude told me to. So now that the thing is you've not actually trust there. You can't actually assume that whoever put up that code even knows what's going on.

New rule 1 — Require an issue first

So what can we do now? What are the new rules of open source and how can we kind of fight these issues? And again, this will be kind of our experience on how we actually implement things for Gemini CLI, one of our open source repositories. 100,000 GitHub stars and over like 700 external contributors. So quite a big scale. We see a lot of this stuff.

The first one is actually pretty trivial. It's that we require you to put up an issue first before you can put up a pull request. So this kind of eliminates 90% of those drive by PRs where, hey, I'm just going to try to fix this, put up a pull request. And then we actually close that and say, hey, you prep an issue first. So right there, if this is an agent or someone's bought, they're not going to come back. And most of the time will not go ahead and create that issue. Whereas if you're a human on the other side, you know, you are actually going to take the time to maybe go and file that and then start working on it. And then we'll take a look at your PR. So open the issue. And we normally try to have a maintainer approve that like if it's something that's going to be pretty hefty, we'll go back and forth. Hey, what are you thinking of the design? Okay, that looks good. Go ahead and start working on that. And that solves about probably 90% of the issues right there. That drive-by PR is now kind of eliminated. There's kind of a buy in for that pull request if they're going to put that up. They've kind of done their work, done their due diligence.

New rule 2 — Rate-limit contributions

The second one is kind of rate limit contributions. So for external contributors, we actually kind of put limits on how many pull requests they can have active at any given time. So for that example we showed where we just started generating 10 different nonsensical ones. This would actually get stopped by that. And it's pretty easy to do in GitHub Actions. But luckily just recently GitHub actually is now going up with this feature by default. So you can actually go into your GitHub repository settings. And actually set a limit for external contributors. To how many active pull requests they can have at any given time. And regular maintainers or people who are allowed to contribute to the project are not affected by this. So it's kind of a nice way where you don't go to sleep at night, wake up the next morning and be like, oh, I've got 40, you know, people trying to rewrite their entire library overnight.

New rule 3 — Automation (incl. stale PR closure)

And the next one is automation. You know, if there's going to be automation for generating the code, you should probably implement automation to help fight that. And this can be done in a way where you're not necessarily even using AI, right? Just be through GitHub Actions. So we have some on our repository where it actually will check to see, hey, we followed up with somebody. Have they responded? If not, after 60 days, which is probably a little generous. It'll go ahead and actually close out that issue. So a way of flagging things as stale or not really active. There's not the buy-in on the other side. Because it is a two-way street.

New rule 4 — Context files (agents.md)

And then some more examples or what you can do to kind of help fight this. Is check in context files into your repository. And, you know, agents are supposed to read instructions whether they actually read the instructions. That's a different ball game. But we can do our best.

And so the thing I'll also say is don't just put into the repository. Don't just commit the context files for Claude. If you're using Claude, that's perfect. But you should actually add an agents.md as well. Because even if your team is using Claude for development, there might be people who are, you know, there's so many different tools out there that they might be using a different tool for development. So by putting the other context files in there as well, or through a symlink, you can actually kind of make sure that the contributions of everyone are kind of uplifted and get better.

And really it's pretty simple. You just throw in there, like run the tests. Follow the PR template. That's a big one. And it's actually makes quite a big difference.

New rule 5 — Agent skills

And you've heard a lot, I think about this over the next few days about agent skills. Everyone is big on the skills right now. They're kind of blowing up everywhere. And they can also really help not just uplift the quality from AI, but also from human people as well. So in our repository, we have a bunch of different skills that actually help kind of take this drive by or one-off contributors and really raise the bar so they can actually help get their work merged.

I think the biggest one that I personally like a lot is the PR creator. You basically just say, hey create a PR for this. It's going to go look at the template, make sure it's looking at the code that's changed. Run the tests and do all that formatting. So if someone who is also contributing to projects says hey, throw the pull request, it'll go through those exact same steps that normally someone human or maintain or do kind of. Codifying those skills that you as a human would do into the code base.

The other one is for docs. Nobody likes riding docs, but they are so important, especially to train the models and to actually have the models kind of look at the docs is a really big uplift in skill. So of course we have a docs writer skill to enforce the style guide and make sure that any features or code that's getting changed has docs going with it. Code review, I'll skip over, but there's a lot of others. And really checking these into the repositories that not only your team members get the benefits, but also external folks is a really good skill.

And we'll take an example of just kind of what this looks like. So here's prime actually that's gone through the PR creator skill. I also have my own personal skill that will like use Playwright to take videos and screenshots of code changes as well so that we can actually have visual proof. I find as a maintainer, if I see a screenshot or a video and pull request, it's in my brain already higher level of easier to see the code that's changed as well as kind of somewhat knowing that there's been thought into it.

Community experiments — OSS Vacation

So that's a little bit of what we've been doing at Google in our repositories, but what are others doing in the open source community? Let's take a look.

Raise your hands. Has anyone heard of open source vacation as a concept? No? Okay, okay. So it is essentially, think about it when you go out of office, you probably put in like automated email that says, hey, I'll be back at this day, two weeks. Or if you really need something urgent, follow up with my boss. It's kind of the same concept for an open source project. If the team has a conference like this and we're all going to it, we can put it into our code base and essentially any pull request or issues during that time. Will get automatically closed and say, hey, you can put the message saying, hey, we're on vacation. We're on open source vacation. It's also another way that open source maintainers, I feel like there's solo maintainer and you're actually going out of office, you can do the same thing so that when you get back from your trip, you're not automatically swarmed with hundreds of pull requests or issues. So it's a really cool way to basically say, hey, we're not accepting contributions right now. We're coming back in like two days. And you can configure it to have the exact message. As well as when it ends.

And the Pie Coding agent, Mary over there, has been a big user of this. He actually will go on really extended periods of OSS vacation even when he's not at a office, but just doesn't want to accept any new contributions. And essentially be able to get through the backlog, bring it down to zero, and then he'll open it up and get spotted with more things.

Community experiments — Vouch

And in fact, anyone heard of Vouch. Okay, few. Few heard about, so Vouch is a system problem source that's kind of a referral system. So if someone's trying to get a job, they say, hey, I know Jack, he can vouch for me. It's the same concept, but for open source. So trusted maintainers or contributors can vouch for other people and essentially say, you know, hey, I know Macey is a good worker. She's on good code. I'm in a vouch for her. Now she can put up pull requests and contribute to the project. And you can set the system defaults for like unknown people who are new. So what maybe they have some permissions. But once you get a vouch, you have, you know, more access. And then the flip side, you can actually get denounced. So bots or people who have put up sloppy code can get denounced and then they get blocked.

And that's kind of similar to the OSS vacation. It uses vacation.markdown. this uses a.td file. So you just check it into your repo GitHub Actions. We'll scan it. And essentially it's just a list of the GitHub handles where there's a list for the bad people, a list of the good people. So stay off the naughty list.

This is from mental hashimoto. So he created Ghostty. He's also one of the founders of Terraform and Azure. So he's been using it in Go CLI, which is a pretty big open source library for a few months. And what's actually surprising to me is he said PR quality has gone way up. Like the vouch system. But he actually is still seeing the PR. So it's really just filtering out the bad ones. So that he can get more of the good ones merged in. So I find that pretty interesting.

Prompts as the new pull request

This is, I haven't swung all the way to this side of the aisle yet, but some people are saying, you know, just don't accept issues at all and now prompts are the new pull requests. So don't give me the code. Just give me the prompt that you use to generate the code and I'll go do it myself. So give me all the details I need to basically go and fix this. I haven't swung all the way there yet. I think that's a little bit harsh. But it is being used by several big companies out there. So don't give me the output. Give me the intent behind it. And we heard that in the keynote this morning. You know, it's moving on to intent and context. So give me the context. Give me the intent. And if it's right, I will go and generate that code using your prompt.

The new playbook (summary)

So where do we go from here? I think there's kind of like a new playbook that we're seeing involved. Nobody really knows. We haven't really settled on, you know, people trying different things. There's vouch, there's open source vacation, different automations. Some people are even just leaving open source because AI and, you know, too many bots. But I think there's kind of a new playbook being written.

And for us at least for maintainers, you know, create issues first. Try to set up external contribution limits so that you can kind of filter out the noise. You know, add the context and skills to kind of uplift all the agents out there. And then try these other systems like automation and trust through vouch.

And on the flip side for the computers, try to discuss your code, actually understand kind of what is being written before you just put a pull request. There's still a little bit of a standard there. And be open to respond to feedback. If you're going to try to add code to a code base. Expect there to be a little bit of pushback. Try to learn something and try to be able to actually explain the decision behind that code.

So the future is really moving towards collaboration. It's not just humans. It's not just agents. It's really a blend of the two. And that's where things are going. So there still needs to be trust. We still kind of need. And that's what vouch tries to do. You're not trying to have some trust. I still use AI to generate code, but there's always got to be the intent there and understanding still on the system while you're making those decisions. And then structure. So try to add these agent skills, context files so that things can scale through humans and bots. And then respect. I think open source has always been on respect. And that's becoming even more crucial now that it's so easy to generate code. Kind of be patient with maintainers. Explain yourself. And that's the biggest thing.

Takeaways

So what would I take away from this is update your contributing.md files. Normally you would put how for humans to actually go ahead and interact with your code. I would actually add a section to kind of what is your contribution guidelines for agents or for AI. This is actually also weed out some agents will actually see this. Okay, I can't do this. Not really. They don't follow instructions that well yet. But it is kind of good to have that written down.

And like we said, check in the files and content. Check in the context files and skills and share repository. And checking context files that aren't just for the tools you're using, but also that the global ones like agents.md. So that people who are using other tools, there's so many controls out there can also benefit from it.

And then add automation to protect your own time. So it's going to be automation through these bots and through all these agents. Automate some of the easy stuff away like that. Stale PR stuff we put looked at as well as PR reviews and things like that. And that's it.

Q&A

Thank you very much, Jack. Yeah, we do. We have a few minutes. Very well timed. We have a few minutes for questions. Would anyone like to ask a general question? Excellent. Thank you.

Q1 (audience) — on whether filtering blocks legitimate contributors / response times:

I know this like all the tools to try to prevent people to commit slow. But what if possibility on the team like response time or how long it takes for the key to react when someone send appropriate? If you have all these blockers, I want to understand how people feel that you are blocking all the potential. Just to understand the reality of how we handle all the contributions.

Jack: Yeah, for sure. I think it's a little bit of like a judgment call. Like most of these automations are to filter out the bad ones so that your time as maintainer can be spent on the ones that are actually high quality. It's really just a filtering system to take out the bad ones. So you're still as a maintainer, hopefully still having response times that are good to high quality and ones that are still humans on the other end. So I think, yeah, it's a bit of a judgment call, but I think also having those like stated what kind of helps a lot too. So just having a clear guidelines or in the pot started being okay, expect two day turnaround time or I think we have that written down in our code base. Kind of what we strive for and just having it. So there's kind of somewhat preemptive pull request. Knows kind of the timeline as well.

Q2 (audience) — on commercial models for paid OSS support:

So since you involve a lot of open source projects and I'm developing the work too, are you seeing an evolution of, I would say evolve commercial models where there is more money, there's more business models around civil support, right? Because at the end of the day, it's question is asking. Right, you know, in the way they develop in that sense, right? They're showing go. There should be a lot more oil to higher duplicates. Are you seeing the evolution of those commercial model where the users of open source have easier ways to pay? That is not just contributions or dimensions. That's what we say.

Jack: Yeah, I think one of the biggest ones for us too in open source is like trying to realize when you see, because it is hard, you know, open source used to be the place where, you know, I would always recommend people to go try to learn coding, right? Like, hey, find something you're passionate about, go try to put up a pull request, kind of get some experience, first kind of with resume builder. I think the important thing is to still try to find that. In the weeds there where like there is still a bit from our side where we try to grow when we see there is someone actively kind of. Participating and not just saying, oh, that's bad code. Like it kind of is a judgment call, right? You want to keep have that community aspect to it.

Q2 follow-up: I was kind of more of, are you seeing companies paying for that level of support?

Jack: Oh, oh, I haven't seen that. Like we, everything we do is through GitHub and like there's not like a fast pass or like. Obviously if there's like some kind of, they don't get pinged being like, hey you got to check out this issue. We traded all the same. Is that kind of what you're asking? Like it's not a problem because you have people that you paid to do. If there are a small open source project or they come to when you're building small ones around open source.

Yeah, I think it's similar to the last question. It's like putting guidelines on what your response times are going to be and then trying to stick to those. And like you can, maybe it is setting up automation to try to help you like, hey, pay me over this one about to hit the SLO or SLA. Topic for sure.

Q3 (audience) — on educating junior developers rather than pushing back:

So thank you for that. I understand what way you're pushing back all these pull requests now is very easy for everyone to create a pull request and so on. So rather than filtering and pushing back the next day be better to kind of educate back rather than pushing back is one of the fears that we have as an industry. Who's going to. Teach all this junior developers, meet developers and so on. It's kind of the industry is kind of leaning towards. What the good looks like and they are using the agents very well. But we also need to use the agents to educate over new engineers.

Jack: Yeah, I think it's like, I think that's probably not just an open source related question. Like that's for like everyone like what does junior software engineering look like? There's like. People are moving more towards agents and I think there's still like mentoring aspect that is huge in that and I study everyone here like find the time. To be purposeful with like mentoring others. I know we have we have we have like we have summer of code programs where we will take on like students throughout the summer in open source. That's an open source program. It's not just a little thing. So like take on take on juniors and actually be thoughtful with like it's evolving right so it's like teaching them how to prompt better, how to do the like I think it's also teaching them how to use the tools as well. But we also do like code reviews and stuff like that. I think all of us we need to do some part on it.

Q3 follow-up: But I think from your perspective maybe just not just pushing back but also kind of advising that bakers can create those better because all of us need to

Jack: Exactly I think agent skills do play a part in that too. Like that's why we have those bureaucrator skills [PR creator skills] so that like hopefully it does raise the bar for somebody trying to. Contribute to projects on the agent skills.

Q4 (audience) — on managing skill conflicts:

Very shortcake. Yes, it's good to insert them into their box really but at some point because especially skills, how they manage which one to put in the bus or which one not to put into the bustle because the conflict becomes super

Jack: yeah, we check we try to say for us it's like what would you use over 50% of the time? And that's kind of the number that we use to gate what. S disabled or enabled by default. So like things like form class. Like you need that skill put it up. Code review as well is like the major ones otherwise we use these proposals like slash parents or rules or sales.

Closing (MC): One second work actually happens and have a direct conversation with the people working on some of the new features to help maintain us in this new AI world. So if you want to have a conversation, any of you may say members, you've got good ideas. I'm in direct conversations on slacking the others involved in the technical features. Like deleting one request and things like that asking for. So catch me out back when I'll see you.

Tonight guys you miss Jack's talk. What were you doing? I'm so confused. Thank you so much Jack that was excellent. Get comfy.