Comfy-Org / Comfy-Org/comfy-cli

docs: Disclosure of AI agents with respect to development process

Open
#584 1 comment 2 reactions 0 assignees View on GitHub
documentation
Dominant language
Python
Stars
968
Forks
151
Avg merge
1d 9h
Merged PRs (30d)
77

Description

**TL;DR:** Recent activity on this project by maintainers has left some ambiguity to their development process, and what users or contributors should expect when engaging with the `comfy-cli` repo. This should be documented with clear disclosure of how AI has been adopted into the process.

If the observations are correct, that maintainers are no longer directly engaging with issues and PRs via the Github browser interface, but instead abstracted via an API and delegating agents to act on their behalf through developer GH accounts, including acts such as posting comments and PR feedback/approval... transparency of this delegation should be clearly disclosed, as presently the ability to discern any form human interaction in the review process is looking questionable?

---

I appreciate the labels like `agent-coded` to provide context, but when AI tooling has been used to manage issues (_closing them in bulk with commentary tailored to each message_), and also in PR descriptions, discussion and feedback/approval... It is less obvious the prose in these cases is not authored by a human unless certain mannerisms/content is present to distinguish this.

Could the project please disclose this is part of the process used now? There's been an uptick in PR activity for example, but [examples like this PR](https://github.com/Comfy-Org/comfy-cli/pull/532) give a strong impression that even the reviewer involved is agentic or through some AI tool generating that comment content?

For users of the project, this concern may be a niche concern. For OSS the added transparency however would be appreciated as the accounts are assumed to belong to real humans while these interactions are either automated or managed via some higher-level interface/service, rather than from Github itself which is what is available to the public eye.

Traditionally engagement with issues/PRs from those with commit access on this project has stalled, and with the recent closing of issues (all actioned in the same minute), it's unclear if there's a real human that can be engaged with as notifications may not reach the account owner if a third-party service is managing issues and PRs via an API alone while AI agents submit and review PRs with whatever degree of oversight by said account owners.

An example of where this is problematic is that any user engaging with the `comfy-cli` repo is highly likely to do so via the GH web interface (_especially for issues_), and they're most likely to be doing so directly as a human rather than delegated via an automated task. When a maintainer responds (_such as closing an issue for any given reason_), attempting to engage with that maintainer may be unsuccessful, and in turn any actions suggested by the comment may result in similar automated actions taking place unintentionally. This is not ideal for the maintainers (_whom may be unaware of the attempt to reach out_), nor for the public image of the repo (_and thus the organization itself_).

I don't have an issue with the use of AI, but as a user I'd very much appreciate upfront disclosure when engagement will not only be ignored (_for reasons I understand_), but attempts to contribute not only becoming stale from lack of upstream engagement but by automation quietly dismissing efforts via accounts that will not respond when a follow-up query to their action is commented (_an issue I've experienced personally several times over the past year by the `Comfy-Org` organization_).

Without providing such transparency, these additional practices with AI tooling do accumulate across the various users engaging with the project that it can erode trust and leave a negative impression, which while ComfyUI has reached levels of success a good driver of that was via community and OSS... I would hope this request is fair and won't be dismissed.

Contributor guide

Open the contributing guide

Research direction

The issue names no documentation file or test; start by reviewing the requested disclosure alongside PR #532 and the repository's existing contributor-facing guidance. Done means the project has a clear, visible statement explaining when AI agents or automation participate in issue and pull-request engagement.

Written by the indexing model from the issue text.

Assessment

Tech stack
github
Domain
documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.