AI Boundary Compatibility

When building AI/LLM-related tooling (tool-calls, background execution, inference/image generation), enforce compatibility at the boundaries: 1) Use team-standard LLM-friendly IDs

copy reviewer prompt

Prompt

Reviewer Prompt
Deploy Agent

When building AI/LLM-related tooling (tool-calls, background execution, inference/image generation), enforce compatibility at the boundaries:

1) Use team-standard LLM-friendly IDs

  • Generate identifiers used in LLM-facing payloads with the shared guids.py helper and its default length (e.g., 8). Don’t invent new ID formats for tool-call correlation.

2) Make AI hardware initialization conservative + always fall back

  • Hardware probing/installation for GPU/CUDA should be environment-aware and non-disruptive in minimal containers/users.
  • If CUDA isn’t available, the system must reliably proceed on CPU.
  • Add a smoke test using a regular minimal OS/user image (e.g., Debian slim) to ensure CUDA setup isn’t too aggressive.

Example (ID generation pattern):

# pseudo-example: use the team helper rather than custom UUID strings
from python.helpers.guids import llm_guid  # assumed name from your guids.py

call_id = llm_guid(length=8)  # keep the default length consistent

Checklist to apply during review

  • Are all LLM-facing identifiers produced via the team’s LLM-friendly GUID utility (no custom formats)?
  • Does the AI runtime path (GPU/CUDA detection + setup) degrade safely to CPU when CUDA isn’t present?
  • Is there at least one test/smoke run in a minimal Debian-slim style environment to validate behavior and prevent overly aggressive CUDA install/setup attempts?

Source discussions