Como a Oxide usa LLMs

• Modelos de linguagem de grande escala (LLM) estão transformando fundamentalmente a forma de trabalhar, e a Oxide definiu com clareza como usá-los dentro da organização
  • A Oxide é uma startup de infraestrutura de computação sob demanda que cria hardware e software unificados para data centers on-premises
• A Oxide apresenta como princípio central do uso de LLMs o equilíbrio entre responsabilidade, rigor, empatia, trabalho em equipe e senso de urgência
• São úteis para resumo e compreensão de documentos, revisão de código e depuração, mas na escrita e criação de código o julgamento e a responsabilidade humanos são indispensáveis
• Os resultados gerados por LLMs devem sempre preservar uma estrutura em que um humano revisa e responde pela decisão
• A Oxide incentiva o uso de LLMs, desde que com a premissa de responsabilidade com produto, clientes e colegas

---

Critérios de valor para o uso de LLMs

• A Oxide avalia o uso de LLMs com base em seus valores fundamentais da organização
  • Responsabilidade (Responsibility): LLM é apenas uma ferramenta, e a responsabilidade pelo resultado é inteiramente humana
  • Rigor (Rigor): quando usado com cuidado, ajuda a refinar o raciocínio; quando usado sem cuidado, pode reduzir a qualidade do pensamento
  • Empatia (Empathy): é preciso lembrar que o emissor e o receptor da linguagem são humanos e manter uma comunicação centrada em pessoas
  • Trabalho em equipe (Teamwork): deve-se evitar que o uso de LLM prejudique a confiança entre colegas e garantir que a transparência no uso não pareça fuga de responsabilidade
  • Urgência (Urgency): é possível ganhar velocidade, mas sem sacrificar os demais valores

As diferentes formas de uso de LLMs

LLMs como leitores

• LLMs são excelentes em resumo de documentos e perguntas e respostas, facilitando a compreensão rápida de grandes volumes de material
• No entanto, é preciso garantir a privacidade dos dados e configurar para que documentos enviados não sejam usados no treinamento do modelo
• São úteis como ferramenta de apoio à compreensão de documentos, mas não devem substituir situações em que é necessário ler diretamente

LLMs como editores

• São eficazes para melhorar estrutura e tom de documentos concluídos e podem ser úteis em fases finais
• No entanto, LLMs tendem a oferecer respostas excessivamente positivas, o que pode faltar uma análise crítica
• Em fase de rascunho, seu uso pode representar risco de perder a voz única do autor

LLMs como escritores

• Textos gerados por LLMs frequentemente parecem clichês ou exibem sinais óbvios de geração automática
• Texto produzido automaticamente pode comprometer a autenticidade do pensamento e a confiança do leitor
• O leitor parte do pressuposto de que o autor entendeu o conteúdo, mas o texto gerado por LLM quebra essa premissa
• A Oxide parte do pressuposto de que todos os membros têm habilidade de escrita e, portanto, não usa LLM como autor principal
• Ainda assim, é possível usar de forma limitada como ferramenta auxiliar para organização de ideias

LLMs como revisores de código

• LLMs são úteis para detectar certos tipos de problemas de código, mas não substituem a revisão humana
• Como as sugestões podem ser ilógicas ou ignorar o contexto, devem ser usadas somente como ferramenta auxiliar

LLMs como depuradores

• LLMs podem servir no papel de rubber duck, para inspirar ideias de depuração
• A capacidade real de resolução de problemas é limitada, mas são úteis como estímulo para pensar em abordagens novas

LLMs como programadores

• LLMs têm forte capacidade de geração de código e são adequados para escrita experimental e de apoio
• Quanto mais próximo do código de produto, mais importantes se tornam validação e responsabilidade
• O código escrito por LLM deve passar por auto revisão (self-review) pelo autor e precisa ser verificado antes da revisão de pares
• Não é permitido responder à revisão de código com reescrita total/geração completa, pois isso impede revisão repetitiva
• Mesmo na geração de código, é preciso manter responsabilidade, rigor, empatia e trabalho em equipe

Operação e diretrizes

• Os detalhes técnicos e diretrizes internas de uso de LLMs estão registrados em documentação interna no GitHub
• A Oxide recomenda o uso de LLMs, mas parte do princípio de uso responsável
  • Responsabilidade por qualidade do produto, confiança do cliente e colaboração entre colegas é a prioridade máxima

[GN⁺]

Comentários no Hacker News

• O texto do Bryan mostra uma visão equilibrada e realista
  Acho que esse tema ficou de fora do RFD porque a Oxide não contrata engenheiros juniores
  Bryan é um engenheiro com mais de 30 anos lidando com software e hardware difíceis, e já teve a experiência de concluir um “programa realmente difícil (um SO)”
  A forma como ele lida com LLMs é muito diferente da de um engenheiro júnior em 2025
  Os juniores de hoje provavelmente quase nunca codificaram sem ajuda de LLM

  • Antigamente, havia épocas em que eu passava meses na empresa construindo apenas modelos para ingestão de dados
    Era tão entediante que até ir trabalhar era difícil, e hoje parece o tipo de coisa que um LLM terminaria em poucos minutos
    Pensando agora, o tempo que gastei naquilo parece quase uma loucura
  • Lembro da primeira aula de web design, em que o professor ensinou por um semestre inteiro os “princípios básicos” de HTML, CSS e JS no Notepad
    Só depois ele apresentou o Dreamweaver, e a produtividade aumentou umas dez vezes
  • A tensão entre “artesanato vs praticidade” nos LLMs é interessante
    Em áreas com resultados claros, como pesquisa de segurança, LLMs são excelentes, mas são fracos em problemas que exigem julgamento sutil
    Por isso, o ideal é deixar as partes repetitivas e sistemáticas com o LLM, e as partes que exigem julgamento com humanos
  • Programo há mais de 20 anos e tinha uma resistência invisível ao uso de LLMs
    Mas agora aceitei que isso é “uma nova forma de programar”, e, ao perceber isso, acabei me sentindo até mais jovem
  • Achei engraçado que, logo após a expressão “pessoas que reconhecem sinais de LLM”, apareceu um em-dash (—) na frase
    Hoje em dia, usar em-dash às vezes faz parecer que o texto foi escrito por IA, o que é meio irritante

• Concordei com quase tudo ao ler o RFD da Oxide, mas não com a parte de que “LLMs escrevem bem código do zero”
  LLMs são bons para resolver a “síndrome da página em branco”, mas acho que código realmente pronto para produção ainda está longe do resultado que eles entregam
  Isso também pode ser uma “ilusão de progresso”

  • Escrita é expressão pessoal, mas código é uma ferramenta para resolver problemas
    LLMs aprendem “boas soluções” que aparecem muito nos datasets e, por isso, são fortes na resolução de problemas
    Já a expressão humana tem a diversidade como essência, então expressões medianas tendem a perder o interesse
    No fim, LLMs podem limitar a capacidade de resolver problemas ainda não solucionados
    Acho que a baixa qualidade do código se deve às limitações da context window
  • Texto banal é ruim, mas código banal pode até ser uma coisa boa
  • A resposta “tente outro modelo” já está parecendo o “No True Scotsman” do mundo dos LLMs
    Gerar no nível de função até funciona, mas, quando se entrega uma funcionalidade inteira, a estrutura e as interfaces costumam sair uma bagunça
    Numa analogia com escrita, seria algo como dar só a primeira e a última frase de um parágrafo e pedir que ele preencha o resto
  • É parecido com o fenômeno de percebermos facilmente erros em notícias sobre áreas que conhecemos bem, mas acreditarmos sem questionar em temas que não dominamos
    Programadores conseguem julgar a qualidade do código, mas com escrita isso não acontece da mesma forma
  • A qualidade dos LLMs varia conforme o modelo
    Muita gente fica com má impressão porque usou modelos antigos ou baratos

• Tenho dúvidas sobre a afirmação de que “LLMs são bons em detectar textos escritos por LLMs”
  Fiquei curioso se isso já foi comprovado com dados

  • O próprio Bryan, da Oxide, explicou isso
    Como o processo seletivo deles é centrado na escrita, houve uma explosão recente de candidaturas escritas com LLM
    Eles avisaram sobre isso no RFD 0003 e na página de carreiras, mas continua acontecendo
    O episódio do podcast também trata de casos relacionados
    LLMs não conseguem pegar todo texto gerado por IA, mas, em casos suspeitos, são úteis como ferramenta auxiliar de detecção
  • Como método para detectar texto gerado por LLM, alguém sugeriu a ideia de colocar metade do texto em um LLM e pedir que ele preveja o restante, comparando a probabilidade de n tokens
    Não testei, mas parece uma abordagem interessante
  • Como a dificuldade de detecção muda conforme o grau de intervenção do LLM (texto inteiro, resumo, revisão etc.),
    acho impossível fazer uma identificação perfeita com a tecnologia atual

• Ao usar código gerado por LLM, a responsabilidade continua sendo do engenheiro
  Código que você mesmo não revisou não pode ser objeto de review
  Meu processo é o seguinte:

  1. inserir o código relevante → 2) explicar o objetivo → 3) revisar o design → 4) gerar o código → 5) testar e corrigir → 6) ler todo o código com atenção e fazer ajustes manuais
     A última etapa é a mais difícil, e emocionalmente dá vontade de pulá-la
     Esse método ajuda a manter o pensamento em nível de arquitetura enquanto reduz o trabalho repetitivo
     Mas LLMs são não determinísticos, então são diferentes de ferramentas previsíveis como um compilador
  • Na prática, a etapa 6 consome a maior parte do tempo
    Se o código não funciona direito, ainda são necessárias mais correções
    Por isso, não tenho certeza se LLMs realmente economizam tempo
  • Antes da etapa 4, seria bom acrescentar um passo para gerar código de teste primeiro, fazê-lo falhar e depois passar
  • Em vez de fazer ajustes manuais, se você deixar o próprio LLM conduzir todas as mudanças, ele consegue manter a consistência de conhecimento dentro da sessão
  • Ainda assim, isso parece ferir o orgulho e o senso de autoria do engenheiro
    É difícil se envolver emocionalmente refinando código feito por uma máquina

• Achei estranho não mencionarem a possibilidade de violação de direitos autorais em código gerado por LLM
  Código do GitHub pode ser copiado quase literalmente, e isso é uma questão importante para empresas de open source

  • Se o conteúdo gerado por LLM não estiver sujeito a direitos autorais, a situação jurídica de código sob licença Copyleft fica nebulosa
    É preciso haver contribuição humana suficiente para existir direito autoral, mas esse critério é pouco claro
  • Fico curioso se esse tipo de tema já foi discutido em tribunal
  • Também me pergunto se os LLMs mais recentes ainda causam esse problema, ou se fazem isso com mais frequência do que humanos

• O documento é bem estruturado, mas a parte que diz que “não há problema em usar LLMs como auxílio de leitura” parece contraditória
  Se fosse perfeito, não seria diferente do texto original; se não for perfeito, existe risco de má interpretação
  Vejo com frequência casos em que o LLM não lê o documento de fato e infere coisas apenas pelo índice
  Existe o risco de surgir uma camada de tradução entre o conteúdo e o leitor

  • Acho que o RFD não era sobre “leitura”, mas sobre as expectativas sociais em torno da “escrita”
  • Se você pediu para comparar três livros técnicos e ele deu um resultado errado, isso foi uma falha no uso da ferramenta
    É preciso colocar o texto completo diretamente na context window
    Ainda assim, três livros inteiros podem exceder os limites de um LLM

• Concordo com a ideia de que “texto feito por LLM corrói até a autenticidade do pensamento”
  Um texto escrito diretamente por um humano tem valor, mas o escrito por LLM parece uma cópia diluída em valor
  A frase de que talvez fosse melhor ler o prompt do que o resultado me marcou

  • A arte humana expressa o interior de uma pessoa, enquanto LLMs são o produto da média coletiva
    Ideias interessantes e originais ficam justamente nos pontos que se afastam da média
    Consigo entender o uso de LLM, por exemplo em tradução, quando alguém que não é nativo quer expressar melhor suas ideias,
    mas quem recebe o texto acaba se perguntando se aquela formulação reflete mesmo o pensamento real da pessoa
  • Isso me lembrou “Programming as Theory Building”, do Naur
    Comentários são uma tentativa de expressar o contexto teórico que não está contido no código
    Como LLMs não podem ter essa “teoria”, não conseguem produzir comentários realmente valiosos
  • Não gosto do “jeito de texto de IA” típico de LLMs, mas muita gente nem percebe isso
    Por exemplo, a maioria dos posts em /r/SaaS parecia escrita por LLM,
    mas ainda assim conduzia bem a reação dos leitores com storytelling emocional
    Eu mesmo uso LLMs para escrever documentação e benchmarks
    Também ajudam quando não nativos precisam redigir documentos técnicos, embora a variação de qualidade seja grande
    No fim, em textos voltados à transmissão de informação, os LLMs estão se tornando cada vez mais úteis
  • Essa ideia de “quero ler o prompt” também aparece quando vejo manchetes de notícias
    Mais do que o que foi escrito, quero saber por que foi escrito
  • LLMs preveem bem frases medianas, mas quase nunca acertam frases criativas
    Então é reconfortante pensar que, mesmo que minhas ideias não sejam geniais, ao menos ainda são estatisticamente raras

• Acho que texto escrito com LLM não vale a pena ser lido
  Gosto que a Oxide tenha estabelecido um princípio firme de não usar LLMs para entregas não relacionadas a código
  Em review de código deveria valer o mesmo: código gerado precisa ser revisado primeiro pelo próprio autor
  Ainda resta ver se essa cultura vai se sustentar na prática, mas a direção parece sensata

• Há uma percepção forte de que LLMs foram treinados com dados apropriados indevidamente,
  e acho que eles deveriam ter considerado essa percepção pública
  Seja como questão ética ou risco de marca, isso claramente importa hoje

  • Vejo esse documento não como algo para o público em geral, mas como documentação técnica interna
    O objetivo é apresentar diretrizes técnicas, não uma posição ética
  • Acho que o “colapso da confiança” mencionado no texto trata exatamente desse problema com outras palavras
    Texto gerado por LLM perde a autenticidade, e o leitor passa a sentir que até aquele pensamento foi automatizado
    Isso pode acabar prejudicando a confiança mútua

• Achei interessante a frase de que “escrever é um trabalho intelectual maior do que ler”
  Mas, no caso de código, sinto que é o contrário

  • Texto ruim é inútil, mas código ruim, se ao menos roda, já pode fechar um ticket no Jira
    Por isso existe muito mais código ruim
    Já código bem escrito tem grande valor de aprendizado e, como a escrita, exige insight
  • Cita-se a lei de Kernighan
    “Debugar é duas vezes mais difícil do que escrever código.
    Portanto, se você escrever o código da forma mais inteligente possível, então, por definição, você não será inteligente o suficiente para depurá-lo”
    link laws-of-software.com