Using LLMs at Oxide
TL;DR Highlight
Oxide, a systems software company, published their internal LLM usage principles — focused on accountability, rigor, empathy, and teamwork rather than 'use it fast and often.'
Who Should Read
Engineering managers and team leads thinking about how to set healthy norms around LLM use in their org, and individual devs wanting a framework for responsible AI use.
Core Mechanics
- Oxide's guidelines aren't about maximizing LLM usage — they center on values like accountability (own the output), rigor (verify before shipping), empathy (consider the reader), and teamwork (don't let AI erode collaboration).
- The core principle: LLM output is your responsibility once you use it. 'The AI wrote it' is not an acceptable excuse for incorrect, sloppy, or misleading content.
- They explicitly warn against using LLMs to pad or obscure — generated content should be as tight and precise as anything you'd write manually.
- On teamwork: LLMs can subtly reduce knowledge-sharing and mentorship if people stop asking colleagues questions and start asking models instead. The guidelines encourage preserving human interaction.
- Rigor includes not just fact-checking but also stylistic review — LLM output tends toward certain patterns (verbose intros, hedge words, passive voice) that need to be actively edited out.
- The document positions LLMs as tools that amplify your existing quality standards, not tools that establish new (lower) ones.
Evidence
- HN discussion was unusually positive — many commenters praised this as a rare example of an org thinking carefully about LLM use rather than just adopting it uncritically.
- Several engineers shared similar internal guidelines they'd written, suggesting this is a widespread but rarely published concern.
- A few commenters noted the irony that the guidelines were apparently drafted collaboratively by humans, not generated by LLMs — which itself demonstrates the values they're promoting.
- Some pushback: critics argued that overly restrictive guidelines risk making a company less competitive as AI-augmented peers become more productive.
How to Apply
- Use this as a template to draft your own team's LLM usage guidelines — adapt the values section to match your org's existing engineering culture.
- Add a step in your code review process where authors flag AI-generated sections, enabling reviewers to apply extra scrutiny.
- For technical writing: run a dedicated pass to strip LLM-isms (hedging phrases, unnecessary preamble, passive constructions) before publishing.
- Explicitly discuss LLM use in onboarding — set expectations early rather than letting norms drift organically.
Terminology
Related Papers
What happened after 2k people tried to hack my AI assistant
실제로 6,000개 이상의 이메일로 AI 에이전트에 prompt injection 공격을 시도한 공개 실험 결과로, Claude Opus 4.6이 비밀 파일 유출을 한 번도 허용하지 않았지만 실험 설계의 현실성에 대한 논란이 뜨거웠다.
When Does Combining Language Models Help? A Co-Failure Ceiling on Routing, Voting, and Mixture-of-Agents Across 67 Frontier Models
여러 LLM을 조합해도 '모든 모델이 동시에 틀리는 비율(β)'이 성능 상한선이며, 업계가 쓰는 pairwise 상관계수(ρ)는 이 상한선을 예측하지 못한다.
Beyond Function Calling: Benchmarking Tool-Using Agents under Tool-Environment Unreliability
실제 환경처럼 API가 망가지거나 결과가 이상할 때 LLM 에이전트가 얼마나 잘 버티는지 측정하는 벤치마크 ToolBench-X 공개.
Nearly Half of LG Smart TV Apps Contain Residential Proxy SDKs
6,038개의 LG·Samsung 스마트 TV 앱을 스캔했더니 2,058개에서 사용자의 IP를 몰래 팔아 트래픽을 중계하는 Residential Proxy SDK가 발견됐다. TV는 컴퓨터처럼 감시받지 않아서 프록시 호스트로 거의 이상적인 환경이다.
Prompt Injection as Role Confusion
LLM이 시스템 프롬프트, 사용자 입력, 툴 출력을 구분하지 못하는 구조적 결함이 prompt injection의 근본 원인이라는 ICML 2026 논문으로, 현재 LLM 보안 아키텍처의 한계를 명확히 분석한다.
GPT-5.5 hallucinates 3x more than MIT-licensed GLM-5.2
모델 크기가 커질수록 성능이 좋아진다는 통념에 반해, 오픈소스 753B 모델 GLM-5.2가 추정 1~2T 규모의 GPT-5.5보다 환각 비율이 3배 낮다는 벤치마크 결과가 나왔다. 단순히 파라미터 수와 벤치마크 점수만으로 모델을 선택하면 실제 업무에서 낭패를 볼 수 있다는 경고다.