AI Can Write the Patch — Can You Get It Merged?

Transcript

[music] [music] >> So, first of all, thank you all for being here and have a good afternoon as well. My name is Rachit. I'm a continue a contributor with Force Asia in India project as a G-Shock 2026 contributor. So, before I start, I would like to ask you guys a question about like most of the people that's here like you use some AI for such as Claude or cursor or something as an AI assisted code generator, right? So, if you look like the numbers of PR are creating the numbers of PR and creating

a patch is like a relatively easier than the time that we had before when there was not AI dominated field and so on. So, this is this is also affected the open source as well. So, that is where my topic comes in. AI can write the patch like the fix and so on, but it is on to you that you get it merged and how you understand the code changes and so on. Yes. So, the first thing we'll discussing is AI can write the code, but developers own the change. So, when you give AI a prompt like this is the issue and so on, they solve they give you the fixes in a just a seconds minutes and so on. But, the ownership of the code who like who wrote the code and so it

belongs to the developer who has prompted the AI agent to fix this. So, the goal is not just AI written code like creating a PR with just AI written code. It's also about understanding the changes that the AI did and whether like those changes are correct or not because if you have seen like AI generates a test case for even just a read me changes as well. So, this shows like the like this is just a purely AI generated and the contributor or the person who generated the changes has not even taken a look at after what uh AI has uh changed in the code and so on.

So, uh for me, if you are a beginner contributor, I have a contributor workflow for you. So, how can you create a well-scoped and powerful PR that gets it merged and like uh maintenance can also understand like no, this person has actually invested time in the PR and understanding the thing as well. So, the first step will be choosing the scope. So, scope here means you need to understand So, on open source, you see that the issues are pretty well-scoped. It shows the steps of how it is reproduced. They include screenshot references and so on.

But, that is just a hypothesis by the user who is using it and so on. It is not the correct thing. Like, you cannot assume like this is the issue. You need to also understand like where is this coming from and so on. So, the first would be choosing a scoped issue that is reproducible. You also You should also try to reproduce the issue and so on. Uh the second step step for this is the baseline step. So, in the baseline step, what you can do is actually cover the thing like where the code this part of code is used and how it is used. For instance, like you are working with an API and the API get it give a unexpected response in the output and so on. So, you need So, when you make a change, before making a change, you should have

a baseline like this API is used in multiple cases and various places as well. So, you need to get a baseline about that. The third step is tracing. So, it's the trace here means you need to trace where the uh issue or the bug is coming from and which part of code is generating. Of course, you can use AI for the guidance and for the help like AI is pretty good in finding the architectures like sorry, explaining the architectures, the code lines and so on. So, once you have gotten the baseline, the scope of the issue, and of course, you have traced like where this thing is coming from, the issue, and so on. So, you have a pretty much a knowledge of what the bug is and how is it caused and what it is affecting. So after that you

can draft the draft the patch for the for the bug. So also but after writing the patch and like just creating a PR it's not the right way but after writing the patch you should also read the difference like what was there before and what is changed how it is affecting and so on like I mentioned before the AI hallucinates a lot and so the changes they did is it they like the AI did not do not check like what recreation is it causing or what other thing was it used in and what other things it is breaking as well. So yeah this is the step five we need to verify the difference we need to test the fix as well check for any

regressions and respond to review means like after the PR is created sometime it happens that the maintainer or the reviewer will leave some review that please explain this what what change you have done or how will this thing work after the change is done and so on. So you should be able to under like explain your change and the behavior as well. Okay. So this is about the issue so I've seen many people doing this thing that is the first thing like copy pasting the issue directly in the AI. They say they for example they just open the GitHub for like event and they open the issue they do control A and then C and V like they directly paste the whole issue in the AI prompt and they

say like solve this issue and so on. But like I said this is not a good work type and workflow you should do because of course you should also understand how things are working in the project as well. So rather than directly pasting the issue directly into the AI you should also try to verify the system behavior. As earlier mentioned your AI is a great guide and a helper in terms of explaining the architecture the code structures way how the things are working. They also give make a pretty good hello read me guide as well.

So, yes, we can also use AI as a code code base code sorry code base guide. >> [snorts] >> So, this is what I was meant by AI is a good mentor like guide in helping the architecture understanding the architecture and so on. So, the first thing that we see Okay. The first thing that we see here is map architecture. So, you can actually ask the AI and request like do AI do explain the whole architecture of the project and sometime it also helps you understand what this project targets, what this project is used for and how this works as well. The second is uh find project patterns. It identifies like how the features like the feature can be similarly used in other places or how

this feature is used inside the same project as well. Uh the sorry, the third one is verify assumption. So, you can also like for instance there is a bug for a UI on the start page and so on. So, this is caused by one of the start like pages for the HTML file something like that. So, you can ask like this issue is particular for this so which file is causing the issue and so on. So, it will also like redirect you to the exact file and sometime the uh code line as well. Okay. So, this is how also so you also need to when you are trying to test things and so on you will also come across uh various bugs that you found yourself and so on. So, you

should also try to report those bugs because it also shows that you are actually taking interest in the project uh and trying out the project doing some things and so on. So, the first thing is would be to uh uh issue to like to report the issue. Uh so, confirm confirming the behavior comes first like if uh you some people just ask AI like this is the whole project you go ahead and find some bugs and create the the bugs and so on. Like tell me this is bugs and they just create the PR directly without sorry the issue directly without even like trying to verify like is this a real bug or not.

So, second is the baseline production. So, before like adding the fix for the issue and so on, uh, you should also observe the current behavior and where is it breaking and why is it breaking as well. So, the code trace and verify is the same thing like I said, you can trace the code where is it coming for and you can verify the root cause as well, which file is it coming from. Okay. So, uh, this I think Okay, yes. So, how how do like you can make a PR that is mergeable? What should be the pattern for creating the PR? What should you include in the PR and so on.

So, the PR that you create should have a exact like a clear problem. You can state the problem like this is this was the problem, this was the bug that was being occurred and so on. Also, you should try to add uh, root cause and evidence like where it was breaking. You can add some screenshots or screencasts as as well. Also, you when you create a PR, it's on the contributor and the developer to check for the not breaking any other parts and so on. So, you should also include that in the PR that we have tested this in various parts, various cases as well. Uh, of course, after creating a PR, the PR does not end there. You need to also address

reviews and be like up on time and respond well to the maintainers or the reviewers because like you can't just create a PR then that's just mergeable. So, there are always some changes and so on, but nowadays we are using AI reviewers such as Copilot or Code Rabbit, Sourcery. So, we have various tools that like automatically reviews the PR when you create a PR as well. So, those reviews are also some reviews that needs to be addressed. Like you should address those reviews as well.

Okay. So, yes, Uh this is all about uh, me. This is how you can use AI for creating a PR that uh can be merged and so on. Uh yes. Uh any questions regarding the uh AI using in PR and so on. Okay. So, if you want to have a question, you can uh come to the mic stand and ask the question if there's any.

Okay. Then uh should I go? >> Yes, ma'am. >> All right. Um I think we do have a question actually in the app. So, by the way, everyone, you can also use this QR code on both screens on the side of the stages to ask questions uh through Meercat. It's uh an anonymous um question tool. So, you can ask questions anonymously. Um Let me do the bot check. So, it says when AI writes both the code and the test cases, how do we ensure tests genuinely catch bugs and edge cases instead of merely validating the AI's own implementation?

>> Uh >> Um >> Yeah. >> Okay. So, this is one of the things that AI really does. So, when you ask the AI to uh uh patch or fix it, so what it writes the uh test cases and so on, but those test cases are not uh 100% right. Yes. So, you also need to check the change like the once uh the change is done, you also need to check the behaviors and so on because AI write the test in its own favor. So, the test will always pass, but uh you can also validate the test case yourself by writing different tests and so on. Or you can also uh like guide the AI as well like this uh all the situations that can happen.

We can write a test case for those as well. Yes. That's all from me. >> Any other questions from the audience? You can also raise your hand and we can give you a mic. All right, in that case, please give a big round of applause for Archit. >> Okay, so I think the next person is Norbert.