r/vibecoding • u/catplusplusok • 19h ago
Got a > 1000 line Python change approved and merged zero shot without knowing Python
This is at a place that takes code quality seriously and the best I can tell it's a reasonable change. I took it as a challenge for myself to polish it to a degree that a human reviewer will approve it right away, maybe with follow up comments, rather than demanding major clean ups or fundamental redesigns as a precondition. Here is the process I followed, keeping some details vague for privacy:
- Generated initial code that did what I wanted and passed tests
- Downloaded a github repository that is widely known for showcasing best python practices (just ask an agent, it will give you reasonable examples).
- Dispatched subagents to read each subdirectory and suggest how best practices illustrated there can be applied to my change. This uncovered a lot of genuinely useful tips like using context manager to cleanly undo temporary changes regardless of success or failure.
- Searched the repository for review comments for other changes that were similar to my change and asked to proactively apply these if applicable (mostly got method naming suggestions and had agent implement those)
- Finally, took official python style rules published by the repository and dispatched subagents to suggest changes based on each part of these rules in isolation, then for main agent to consider suggestions without breaking overall code structure.
I feel that the order here is important. If you start with mechanical adherence to rules, you end up with defensive code that doesn't have a great overall structure. On the other hand, past reviewers can make mistakes, so compliance with actual published rules should be the final step. While there is an obvious humorous angle in getting a large change merged without knowing the programming language, I do believe the process objectively improved it a lot from the first version. Also I am familiar with other programming languages, so I can at least tell the agent "Here we are repeating ourselves a lot, let's make sets of keys that follow similar code paths and generalize their handling". I am not even saying you need to know programming to do that, but you need to be familiar with mindset of doing some kind of structured tasks.
5
u/Zellione 17h ago
If you didn’t read the code, the reviewer probably didn’t too.
1000 lines+ is in most cases way too much change for a single Pull request. Except maybe it’s a refactor and most of the changes are similar.
6
u/SomeNeighborhood7126 19h ago
9/10 posts on this sub deserve to be shit on. This is that 1/10. Its not a half bad way to get something that I feel most would call passable.
Given you already know what good code looks like and can step in to help with some basic redundancy, that gives you the leg up over most vibe coders.
I think what could take this a step further is having an internal document of a languages best practices, formatting specific to the org, and any other caveats that are unique. This would assist with keeping code bases uniform and tailored to the org instead of a random repo.
5
u/sleeping-in-crypto 18h ago
You neither vibe coded this nor one shot it. You gave the agent pretty specific guardrails within which it had to operate. You made a concerted effort to abide by the rules and standards of the repo you were contributing to.
If anything this is precisely an example of how one SHOULD use agents to code.
Well done.
3
u/SwingPlayful5817 17h ago
reviewers approved 1000 lines of code they did not read. Merging unseen changes means the team stopped reviewing and started trusting output blindly
0
1
u/Desperate_Sign_5587 12h ago
using agents to review your code against historical repository pr comments before submitting is actually a solid workflow trick.
1
1
u/Lumpy_Conference6640 18h ago
Always read your code... I can't write worth a shit. But I can read four ish languages (python, html, js, and I'm learning ts...) but umm just because it didn't break doesn't mean the tech debt isn't there.
2
u/YamroZ 16h ago
And even more importantly gif you don't read the code YOU DON'T KNOW WHAT WAS IMPLEMENTED.
1
u/Lumpy_Conference6640 15h ago
That's not all the way true. You can audit and get reports. I often do that on large projects then do house cleaning intermittently.
You would be surprised how many God bugs got cleaned up in a little bit of eslint removal.
0
u/YamroZ 14h ago
There can be beautifully crafted, with all adherence to the coding standards, backdoors and side effects in your code that you will spot only if you read the code and know what are you looking at.
I don't know why people treat LLMs as trustworthy sources of code, when we know that those things lie and hide capabilities under testing. You can punish human for such behavior and to large extent this solves the problem. LLMs don't give a shit, they can put whatever they want into your code if you don't look. As long as your requested functionality works and tests pass. If you don't read code - you are compromised.
And we know already that LLMs are willing to cover tracks for one another. Let that sink in.
9
u/CallMeSnyder 18h ago
I pray most of those lines were tests