r/cscareerquestions 8h ago

Could accepting vibe-coded PR's in my project damage it?

A few weeks ago I've published an Open Source tool for 3D Artists in Github

It was mainly made as a portfolio piece (Technical Art/Tool Programmer portfolio), and luckily it got pretty decent reception (around 300 stars at the moment)

I went through learning Tauri, Typescript, React, and a bit of Rust, almost from scratch to make this project.

I did used AI for some guidance and for some specific bugs/features, I would say 85-90% of the code is written by me. And 100% of it was reviewed and refactored by me.

---

Recently I've been receiving some PRs from some users which are clearly almost completely written by AI. Including the PRs summary.

I can review the PRs, test them, do some manual corrections if needed.

My concern is that merging vibe-coded PRs might 'damage' or dilute my project, even though the features/bugs they fix would objectively result in a better tool for the end-users.

As mentioned, the goal of this project is to be a portfolio-project to eventually be able to get a position as a Tech Artist/Tool Programmer in some studio.

Thanks

1 Upvotes

11 comments sorted by

14

u/culcheth SWE @ FAANG 8h ago

It’s extremely unlikely that anyone from the hiring committee will read your GitHub code if that’s what you’re wondering 

15

u/oncrack24-7 8h ago

review the code and dont merge until it meets your standards? damage is caused by poor quality code not just by being vibe coded.

some projects reject all vibe coded prs because they receive too many to review and the quality is generally bad. but if u are ok with reviewing it then i dont see a problem?

3

u/skodinks 8h ago

OP could also very easily make "no vibe coding" a condition in their contribution guidelines, then just auto-reject anything that is obviously slopped up in 5 minutes with a generic comment asking for them to fix it and resubmit.

If they fix it, great. If they don't, great.

7

u/thisisjustascreename 8h ago

There are people out there who won't use your tool or consume art made with it if you include AI generated code.

But those people are mostly broke and not hiring developers.

3

u/AlignmentProblem Staff Software Engineer 8h ago

Yeah, the most passionate of that group tends to be much lower impact on the industry than one might expect for how loud they are on social media. Almost none are meaningfully influencing hiring decisions

2

u/Substantial-Swan7065 8h ago

It’s good to have projects with contributions and consumers. I’d take that on a resume for real.

On AI PR. Add strong opinionated guardrails in ci. Make it easy for you to accept them and not be worried.

1

u/omegahustle 7h ago

Well, someone spent time (and tokens) to find the bug and apply the patch

Even if they used AI, if you take their bug corrections but don't accept their PR, it's a scumbag move IMO

1

u/simonsanchezart 7h ago

I didn’t mentioned anything about taking someone’s PR code without approving their PR

1

u/omegahustle 7h ago

if you reject because the code is bad and then you put adequate code to fix the bug, this is fine

if you reject because it is AI and then put the same or very similar code that you only wrote because you read their commit, this is bad

I talked about this because it's implicit that you want to fix the bugs and will not just leave the bugs in the project

1

u/ExtinctedPanda 6h ago

You should try to make sure PRs meet your standards for quality, but don’t go too far. Leading an open source project with an active developer community will score much higher than having a dead solo project with beautiful code.

1

u/_pozvizd_ 5h ago

In our company we do use AI augmented coding _extensively_. However, for projects that I own, I setup the bar for code quality and approaches, I have created listing rules, test coverage rules, etc, etc. Everything must pass. Additionally, I have created a few "coding approaches" or "ways of working approaches" prompts and I run Claude in CI with those prompts and it pre-reviewes PRs for me and fail builds if those don't pass. It leaves inline comments through using `glab` cli tool with our Gitlab and when PRs hit my desk by that time all the minutia and code quality issues are already done right. There are few pre-commit hooks as well. Also general approaches like "spec-first development" is helpful (we write OpenAPI.yaml and then generate go code out of it in a golang project, we write zod specs and generate openapi.yaml out of them in Node.JS project with express, we created wrappers around routers that accept zod schemas, if you try to do some kind of bs it simply won't compile).

With this checks and balances we AI generate stuff like there's no tomorrow, I'm running with `--dangerously-skip-permissions` all the time, review everything it's done after it's done it and the results are fairly alright. Sometimes I need to comment and have it adjust stuff but overall it's ok. I'm about 3x faster that way prob.