Draft / barebone of AI Guidelines - #127
Conversation
|
|
||
| --- | ||
|
|
||
| ## Approved Tools |
There was a problem hiding this comment.
To discuss: should we mention we started a NYPL Hugging Face org?
https://huggingface.co/NYPL
| ### 1. Security | ||
|
|
||
| - **Hard rule:** Secrets must never appear in agent context. If your codebase stores API keys in files an agent can read, refactor before using AI agents on that project. | ||
| - Prefer technical controls (`.gitignore`, secret scanning, environment injection) over relying on `AGENTS.md` instructions alone to exclude sensitive files. |
There was a problem hiding this comment.
Re: meeting on Jun 22, we could be more explicit about this cc: @bantucaravan
|
|
||
| Welcome to the NYPL Engineering AI Guidelines! | ||
|
|
||
| Here at NYPL Digital, we are excited about the potential of AI to enhance our engineering work, but we also recognize the need for clear guidelines to ensure responsible and secure use as a quasi-public institution. This document outlines our principles, approved tools, and policies for using AI in our engineering projects. |
There was a problem hiding this comment.
| Here at NYPL Digital, we are excited about the potential of AI to enhance our engineering work, but we also recognize the need for clear guidelines to ensure responsible and secure use as a quasi-public institution. This document outlines our principles, approved tools, and policies for using AI in our engineering projects. | |
| Here at NYPL Digital, we are excited about the potential of AI to enhance our engineering work, but we also recognize the need for clear guidelines to ensure responsible and secure use as a 501(c)(3) nonprofit organization. This document outlines our principles, approved tools, and policies for using AI in our engineering projects. |
|
|
||
| - All AI-generated code must be reviewed before merging, as you would review any human-authored PR. | ||
| - Engineers must be able to explain every line of code they commit, regardless of how it was produced. If you cannot explain it, do not commit it. | ||
| - Clearly indicate AI assistance in pull requests using the [PR template](./templates/PR_TEMPLATE.md). |
There was a problem hiding this comment.
| - Clearly indicate AI assistance in pull requests using the [PR template](./templates/PR_TEMPLATE.md). | |
| - Clearly indicate AI assistance in pull requests using the [PR template](./templates/PULL_REQUEST_TEMPLATE.MD) in your project repo. |
My repos at least have PR spelled out, but not sure if this is consistent across every repo...
| ### 3. Cost & Usage | ||
|
|
||
| - Some models are significantly more expensive than others — use the most capable model appropriate for the task, not the most powerful one available. | ||
| - Monitor your own usage. The working group will establish team-level cost baselines as part of the Claude rollout. |
There was a problem hiding this comment.
What do we want folks to do after monitoring their usage? There's currently some ambiguity about what is "too much," I wonder if there is any more guidance we can give ahead of the Claude rollout of team baselines.
| ### 4. Configuration & Agent Files | ||
|
|
||
| - Place `AGENTS.md` (or equivalent, e.g., `.github/copilot-instructions.md`) in your project root to establish project-specific AI behavior. | ||
| - Use the [AGENTS.md template](./templates/AGENTS.md) as a starting point. Customize per project; a one-size-fits-all ruleset is explicitly discouraged. |
There was a problem hiding this comment.
Do we know if Copilot-generated changes to agent.md templates still require admin approval? If so, could be good to highlight what to expect, who to reach out to for review... or optionally advise against this if that's our POV
|
|
||
| | Tool | Scope | Access | | ||
| | -------------------- | ----------------------------------------------- | ---------------------------------------------------------------------- | | ||
| | GitHub Copilot | Code generation, inline completion, code review | All engineers | |
There was a problem hiding this comment.
Do you feel we need to specify anything about the models or do you think it is clear that people can use any of the ones available?
|
|
||
| - All AI-generated code must be reviewed before merging, as you would review any human-authored PR. | ||
| - Engineers must be able to explain every line of code they commit, regardless of how it was produced. If you cannot explain it, do not commit it. | ||
| - Clearly indicate AI assistance in pull requests using the [PR template](./templates/PR_TEMPLATE.md). |
There was a problem hiding this comment.
I think this could be clarified. What if you just used AI to ask a question or make a plan? What if you just used Copilot code complete? What does "AI assistance" mean and how specific should you be about what AI assistance you used?
|
|
||
| ### 3. Cost & Usage | ||
|
|
||
| - Some models are significantly more expensive than others — use the most capable model appropriate for the task, not the most powerful one available. |
There was a problem hiding this comment.
Will teams get guidance about what models are best for what tasks?
|
|
||
| ### 5. Labeling AI-Generated Work | ||
|
|
||
| - Work outputs that are largely AI-generated must be clearly labeled per NYPL policy. |
There was a problem hiding this comment.
Is "largely" up to the engineer's discretion?
samanthaandrews
left a comment
samanthaandrews
left a comment
There was a problem hiding this comment.
I have been reviewing the guidelines as they are currently drafted with my direct reports before they receive Claude premium access and it has been a useful tool to make sure we're on the same page. For this purpose, they have been useful already.
4 participants
Basically consolidated the notes from our first three AI Policy Working Group meetings. Hoping we could start from here!