- Los modelos de lenguaje de gran escala (LLM) están transformando de forma fundamental la forma de trabajar, y Oxide ha definido con claridad cómo se deben usar dentro de la organización
- Oxide es una startup de infraestructura de cómputo bajo demanda que construye hardware y software integrados para centros de datos on-premise
- Como principio central para aprovechar los LLM propone un equilibrio entre responsabilidad, rigor, empatía, trabajo en equipo y urgencia
- Son útiles para tareas como resumen y comprensión de documentos, revisión de código y depuración, pero en la escritura o la programación el juicio y la responsabilidad humanos son esenciales
- Los resultados generados por LLM deben mantener siempre una estructura donde una persona los revise y asuma la responsabilidad
- Oxide promueve el uso de LLM, condicionado al sentido de responsabilidad hacia el producto, los clientes y los compañeros
Criterios de valor para usar LLM
- Oxide evalúa el uso de LLM según los valores clave de la organización
- Responsabilidad (Responsibility) : Los LLM son solo una herramienta; la responsabilidad del resultado recae completamente en una persona
- Rigor (Rigor) : Usados con cuidado pueden pulir el pensamiento, pero si se usan sin cuidado disminuyen la calidad del mismo
- Empatía (Empathy) : Debe reconocerse que tanto el destinatario como el autor del mensaje son humanos, y mantener una comunicación centrada en las personas
- Trabajo en equipo (Teamwork) : Hay que cuidar que el uso de LLM no dañe la confianza entre colegas y que la transparencia en su uso no se perciba como evasión de responsabilidad
- Urgencia (Urgency) : Aunque se pueda mejorar la velocidad, no se deben sacrificar otros valores
Formas diversas de uso de LLM
LLMs como lectores
- Los LLM son excelentes para resumir documentos y responder preguntas, y pueden ayudar a entender rápidamente grandes volúmenes de información
- No obstante, se debe garantizar la privacidad de los datos y ajustar la configuración para que los documentos cargados no se usen en el entrenamiento del modelo
- Son útiles como herramienta de apoyo para comprender documentos, pero no deben reemplazar las situaciones en las que se debe leer directamente
LLMs como editores
- Son eficaces para mejorar la estructura y el estilo de documentos ya terminados, y son útiles cuando se usan en etapas finales
- Sin embargo, los LLM tienden a dar una respuesta excesivamente positiva, lo que puede traducirse en falta de análisis crítico
- Si se usan en la fase de borrador existe el riesgo de perder la voz propia del autor
LLMs como escritores
- Los textos creados por LLM suelen ser con frecuencia demasiado genéricos o con huellas evidentes de generación automática
- Los textos generados automáticamente pueden socavar la autenticidad del razonamiento y la confianza del lector
- El lector presupone que el autor comprende el contenido, pero los textos de LLM rompen esa premisa
- Oxide parte de que todos los miembros saben escribir y no usa LLM como protagonista en la redacción
- Sin embargo, puede usarse de forma limitada como herramienta auxiliar para ordenar ideas
LLMs como revisores de código
- Los LLM son útiles para detectar ciertos tipos de problemas de código, pero no pueden reemplazar la revisión humana
- Dado que las sugerencias pueden carecer de lógica o perder el contexto, deben usarse solo como herramienta complementaria
LLMs como depuradores
- Los LLM pueden usarse como un "rubber duck" que provoque ideas de depuración
- Su capacidad para resolver problemas reales es limitada, pero son útiles como estímulo para generar nuevos enfoques
LLMs como programadores
- Los LLM tienen una capacidad de creación de código muy alta y son adecuados para la escritura experimental y de apoyo
- Cuanto más se acerque al código de producto, más importantes son la verificación y la responsabilidad
- El código creado por un LLM debe ser revisado directamente por quien lo escribió (auto-revisión) y siempre verificado antes de la revisión por pares
- Durante la revisión de código está prohibido responder re-generando todo por completo, ya que eso impide la revisión repetida
- También al generar código se deben mantener la responsabilidad, el rigor, la empatía y el trabajo en equipo
Operación y directrices
- Los detalles técnicos e internas guías del uso de LLM están documentados en documentos internos de GitHub
- Oxide recomienda el uso de LLM, pero exige un uso responsable
- Da prioridad a la conciencia de responsabilidad en relación con la calidad del producto, la confianza del cliente y la colaboración entre colegas
1 comentarios
Comentarios en Hacker News
El texto de Bryan muestra una visión equilibrada y realista
Creo que el RFD no incluyó nada sobre eso porque Oxide no contrata ingenieros junior
Bryan es un ingeniero con más de 30 años trabajando con software y hardware difíciles, y tiene experiencia terminando un “programa realmente difícil (un SO)”
La forma en que él usa los LLM es muy distinta a la de un ingeniero junior de 2025
Da la impresión de que los juniors de hoy casi nunca han programado sin ayuda de un LLM
Era tan aburrido que hasta costaba ir a trabajar, pero ahora siento que eso podría terminarse en minutos con un LLM
Viéndolo hoy, todo el tiempo que invertimos entonces parece casi una locura
Recién después presentó Dreamweaver, y la productividad aumentó como diez veces
En áreas con resultados claros, como la investigación en seguridad, los LLM destacan, pero son débiles en problemas que requieren juicios sutiles
Por eso lo ideal es dejarle al LLM las partes repetitivas y sistemáticas, y que el humano se encargue de las partes que requieren criterio
Pero ahora acepté que esta es una “nueva forma de programar”, y al reconocerlo hasta me sentí más joven
Últimamente me molesta un poco que usar em-dash haga que crean que un texto fue escrito por IA
Al leer el RFD de Oxide asentí con casi todo, pero no estoy de acuerdo con la parte de que “el LLM escribe bien código desde cero”
Los LLM sirven para resolver el “síndrome de la página en blanco”, pero creo que el código que realmente se despliega está muy lejos de ese resultado
Tal vez esto sea una “ilusión de progreso”
Los LLM aprenden “buenas soluciones” que aparecen mucho en el dataset, así que son fuertes para resolver problemas
En cambio, en la expresión humana la diversidad es esencial, así que la expresión promedio pierde interés
Al final, los LLM podrían limitar la capacidad de resolver problemas no resueltos
Creo que la razón de la baja calidad del código es la limitación de la context window
La generación a nivel de función está bien, pero si le encargas una funcionalidad completa, la estructura y las interfaces salen hechas un desastre
Si lo comparas con escribir, sería como darle la primera y la última oración de un párrafo y pedirle que complete lo demás
Los programadores pueden juzgar la calidad del código, pero con la escritura no pasa igual
Muchas veces la mala impresión viene de haber usado modelos viejos o baratos
Me genera dudas la afirmación de que “un LLM detecta bien textos hechos por LLM”
Me pregunto si eso está demostrado con datos
Dijo que, como su proceso de contratación está centrado en la escritura, últimamente se disparó la cantidad de postulaciones redactadas con LLM
Lo advierten en RFD 0003 y en la página de empleo, pero sigue pasando
También tratan casos relacionados en un episodio del pódcast
Dice que el LLM no detecta todo el texto generado por IA, pero sí es útil como herramienta de apoyo para detectar casos sospechosos
No lo he probado, pero parece un enfoque interesante
creo que con la tecnología actual es imposible una detección perfecta
Al usar código hecho por LLM, la responsabilidad recae en el ingeniero
El código que uno no revisó por cuenta propia no puede pasar a revisión
Mi proceso es el siguiente:
El último paso es el más difícil, y emocionalmente dan ganas de saltárselo
Este método permite mantener el pensamiento a nivel de arquitectura mientras reduce trabajo repetitivo
Pero los LLM no son deterministas, así que son distintos de herramientas predecibles como un compilador
Si el código no funciona bien, hace falta todavía más corrección
Por eso no estoy seguro de que el LLM realmente ahorre tiempo
Cuesta involucrarse emocionalmente en pulir código hecho por una máquina
Me parece raro que no se mencione la posibilidad de infracción de copyright en el código generado por LLM
Podría copiar código de GitHub tal cual, y eso es un tema importante para una empresa de open source
Tiene que haber suficiente aporte humano para que exista copyright, pero no está claro dónde está ese umbral
El documento está bien armado, pero la parte de que “no hay problema en usar un LLM como ayuda de lectura” se siente contradictoria
Si fuera perfecto, no se diferenciaría del original, y si no lo es, existe el riesgo de mala interpretación
De hecho, muchas veces veo que los LLM no leen bien un documento y deducen cosas solo mirando el índice
Existe el riesgo de que aparezca una capa de traducción entre el contenido y el lector
Hay que meter el texto completo directamente en la context window
Aunque es posible que el contenido completo de tres libros ya supere los límites de un LLM
Me identifico con la idea de que “el texto escrito por LLM daña incluso la autenticidad del pensamiento”
Lo escrito directamente por un humano tiene valor, pero lo escrito por un LLM parece una copia diluida de valor
Me impactó la frase de que sería mejor leer el prompt
Las ideas interesantes y originales están en los puntos que se alejan del promedio
Entiendo que alguien use un LLM para expresar mejor sus ideas, por ejemplo en traducción o si no es hablante nativo,
pero quien recibe ese texto termina dudando si esa expresión realmente refleja el pensamiento de esa persona
Los comentarios son un intento de expresar el contexto teórico que no queda contenido en el código
Como un LLM no puede tener esa “teoría”, no puede producir comentarios verdaderamente valiosos
Por ejemplo, la mayoría de las publicaciones en /r/SaaS parecían escritas por LLM,
pero aun así provocaban bien la reacción de los lectores mediante storytelling emocional
Yo también uso LLM para redactar documentación o benchmarks
También ayudan a quienes no son hablantes nativos al escribir documentos técnicos, aunque la calidad varía mucho
Al final, en la escritura para transmitir información, los LLM se están volviendo cada vez más útiles
No me interesa solo qué se escribió, sino por qué se escribió
Así que me consuela pensar que, aunque mis ideas no sean originales, al menos estadísticamente son raras
Creo que no vale la pena leer texto escrito con LLM
Me gusta que Oxide haya establecido un principio firme de no usar LLM para entregables que no sean código
En las revisiones de código debería aplicar lo mismo: quien lo generó tiene que revisarlo primero
Habrá que ver si esta cultura realmente se mantiene, pero la dirección parece sensata
Existe una percepción fuerte de que los LLM fueron entrenados con datos apropiados indebidamente,
y creo que deberían haber tenido en cuenta esa percepción pública
Sea por una cuestión ética o por riesgo de marca, hoy es claramente un factor importante
Su propósito parece ser dar lineamientos técnicos, más que fijar una postura ética
El texto generado por LLM pierde autenticidad, y el lector termina sintiendo que hasta el pensamiento fue automatizado
Al final, eso puede dañar la confianza mutua
Me pareció interesante la idea de que “escribir implica un trabajo intelectual mayor que leer”
Pero con el código siento que es al revés
Por eso hay mucho más código malo
En cambio, el código bien escrito tiene gran valor como aprendizaje y requiere intuición, igual que la escritura
“Debuggear es dos veces más difícil que escribir código.
Así que, si escribes el código lo más inteligentemente posible, depurarlo será imposible”
Enlace de laws-of-software.com