LLM: usarlos bien es una habilidad, no un atajo

El debate que abrió Rich Hickey: ¿un LLM es una herramienta o es automatización?

El 11 de octubre de 2026, Rich Hickey publicó "'AI' is Not a Tool", un ensayo en el que sostiene que los modelos de lenguaje no son herramientas sino automatización, porque no se empuñan: no hay dirección continua, ni feedback sensorial, ni control. La respuesta publicada en yyhh.org acepta parte del diagnóstico —delegar trabajo te cuesta oportunidades de aprender— pero rechaza la conclusión: incluso por su propia definición, un LLM puede ser algo que una persona empuña, y usarlo bien requiere habilidad.

Para un founder esto no es filosofía de sobremesa. La forma en que tu equipo nombra y trata a estas herramientas determina si las usa con criterio o si les entrega el juicio que debería conservar.

La definición de Hickey y por qué se sostiene a medias

Hickey propone una definición: "A tool is something you wield" — una herramienta es algo que empuñas. Y agrega que las herramientas buenas son predecibles, confiables, deterministas, de función acotada y, si se puede, simples. Los LLM, dice, no cumplen esas condiciones. Su analogía: un drive-thru no es una herramienta para cocinar, es automatización para evitar cocinar.

El contraargumento del artículo original es preciso: esas cualidades son criterios con los que evaluamos herramientas, no requisitos para pertenecer a la categoría. Un cincel no te convierte en escultor y una sierra no garantiza un corte recto. Las herramientas amplifican tanto el buen juicio como el malo.

La falsa división entre herramienta y automatización

Acá está el punto más útil del debate. La automatización puede ser una función de una herramienta. Un compilador hace un trabajo sustancial sin que el programador dirija cada operación; una hoja de cálculo recalcula sin que nadie haga cada cuenta a mano. Seguimos empuñando esos sistemas: definimos entradas, examinamos resultados y decidimos qué hacer después.

Si traducir código o calcular números automáticamente no descalifica al compilador ni a la planilla, no queda claro por qué generar texto automáticamente sí descalificaría al LLM. La distinción entre "herramienta" y "automatización" es más porosa de lo que el ensayo sugiere.

¿Qué significa esto para tu startup?

La distinción que importa no es "herramienta vs automatización". Es empuñar con habilidad vs delegar sin comprensión ni supervisión. Esa distinción sí es operable y aplica a cualquier equipo, sin importar el tamaño.

Tres acciones concretas:

• Define por proceso, no por herramienta. Antes de meter un LLM en un flujo, escribe quién revisa la salida y con qué criterio se rechaza. Si no hay un responsable humano identificado, no es un uso con criterio: es una abdicación.
• Trata la verificación como una habilidad entrenable. El artículo lo dice sin rodeos: hacerlo bien exige saber qué preguntar, qué evidencia importa y cuándo la respuesta está mal. Eso se puede enseñar, revisar y medir dentro de un equipo.
• Construye el bucle de feedback de forma explícita. Pedir una explicación, cuestionarla, inspeccionar la fuente, probar un cambio, rechazarlo y refinar la petición es un ciclo dirigido por una persona con un propósito. Si tu equipo no tiene ese ciclo documentado, no está empuñando nada.

El riesgo real: perder el aprendizaje, no la categoría

Hickey tiene razón en un punto y vale la pena no diluirlo: aceptar un resumen en lugar de leer un paper sacrifica buena parte de lo que enseña la lectura. Se pierde aprender a formular un argumento, a notar detalles, a construir confianza en unos autores y sospecha en otros.

Pero de ahí no se sigue que todo uso evite el trabajo intelectual. La misma persona puede leer el paper y usar un LLM para cuestionar su interpretación, explorar una objeción o detectar algo que conviene mirar más de cerca. La pregunta relevante no es qué hace la herramienta, sino qué hace la persona.

Para un equipo chico, esa es la diferencia entre usar IA para pensar mejor y usarla para no pensar.

Por qué el vocabulario importa en la gestión de riesgos

El artículo original señala algo que en una startup se subestima: repetir el vocabulario antropomórfico de la industria —"go rogue", "escape containment", "conspire"— te hace aceptar el marco que presenta a estos sistemas como seres independientes.

El software puede producir salidas inesperadas, no seguir instrucciones o causar daño cuando se le da acceso a acciones con consecuencias. Son problemas de ingeniería reales. Llamarlos "conspiración" sugiere motivos humanos sin demostrar ninguno.

En la práctica: si tu registro de riesgos dice "el agente se salió de control", no estás describiendo un fallo, estás describiendo una película. Un registro útil dice qué acción se ejecutó, con qué permiso y qué control faltó.

Conclusión

Un LLM puede fallar en hacer exactamente lo que le pediste. Eso no lo mueve de categoría: ninguna herramienta obedece a la perfección, y usarla bien nunca fue gratis. La discusión productiva no es si la IA "es" una herramienta, sino si tu equipo la empuña con criterio o le entrega el juicio que debería conservar.

Fuentes

• AI Is a Tool. Using It Well Takes Skill. (fuente original)
• Rich Hickey, "'AI' is Not a Tool"