Posts on Un blog

Cosas que aprendí en mayo

Fri, 05 Jun 2026 19:55:15 -0300

A veces me pasa que me entero de curiosidades varias. Y después me olvido de compartirlas con otros. Así que acá recopilo las que me enteré durante el mes pasado.

Gallinas

Los seres humanos domesticamos a las gallinas inicialmente no por la carne o los huevos, sino para ver peleas de gallos como entretenimiento.

Dónde lo escuché: En el podcast We’re not so different. Wikipedia confirma: “In the process of domestication, chickens were apparently kept initially for cockfighting, and only later used for food.”

Cura para la resaca

Siguiendo con el tema gallinas, aparentemente una cura antigua céltica para la resaca era agarrar una gallina, cortarle la cabeza, y presionar el ano contra tu frente. No digo que funcione, pero no lo probé, así que tampoco puedo afirmar que no funcione.

Dónde lo escuché: Otra vez, We’re not so different.

El caballo del ajedrez

El caballo del ajedrez tiene nombres diferentes dependiendo del idioma. Ya sabía que en inglés (y también en otros idiomas) es “caballero”. Lo que no sabía es que en varios idiomas (nórdicos y alemán, y algún eslávico relativamente cercano a Alemania) es “saltarín”. Y en siciliano es “burro”.

Dónde lo escuché: Mirando en Wikipedia a partir de una conversación desatada por un meme boludo.

El meme boludo en cuestión

Panteras

Las panteras no son una especie de animales. Pantera es un nombre genérico para cualquier felino grande (leopardo, jaguar, puma) de color negro. Existe también el género Panthera, al cual pertenecen el leopardo (P. pardus), jaguar (P. onca), y puma (P. concolor), pero también otros animales como león (P. leo) y tigre (P. tigris).

Dónde lo escuché: En el canal de YouTube de zerowoolfe, y Wikipedia confirma.

Años largos

Hace cientos de millones de años, los años duraban más de 400 días. No es que los años fuesen más largos, sino que los días eran más cortos. La Luna estaba más cerca y la Tierra giraba más rápido.

Dónde lo escuché: En el podcast Lateral. La forma en que lo presentaron no parece coincidir con lo que dice Wikipedia. En el podcast dijeron 420 días (Wikipedia dice 400±7), y en el podcast dijeron que la evidencia era depósitos de coral (Wikipedia dice fósiles de moluscos).

Yunguseng Dojang, temporada 44, ciclo 2

Fri, 22 May 2026 20:10:17 -0300

Terminó el segundo ciclo de la temporada 44 de Yunguseng Dojang.

Como la vez pasada quedé entre los dos primeros de la liga en la que estaba, subí a la liga siguiente, la A2. Esto representó una increíble oportunidad para poder mostrar toda mi capacidad de hacer papelones.

De las cinco rondas de este ciclo, perdí cuatro, y al menos tres hice errores de un nivel principiante, y perdí el partido por eso. El único que gané arranqué mal pero logré recuperar gracias a que mi oponente jugó varias jugadas que esencialmente eran pasar, o casi. Gané por un punto y medio.

Me gustaría decir que la única partida que gané fue porque tenía la estufa a leña, pero en la quinta ronda también la tenía

La buena noticia es que siento que aprendí algo, a pesar de los papelones. También creo que aproveché más que el mes pasado las cosas que da el curso.

Una de ellas es el buscador de patrones. La sección de Lectures del sitio web tiene un buscador de patrones. Podés poner algunas piedras en el tablero, y te busca lectures en las que salga ese patrón. Un par de veces me pasó de decir “hm, claramente tuve un resultado subóptimo en esa esquina, a ver si hay algún video que mirar que me ayude por ese lado”, y fui y efectivamente, había videos. En general más de uno. Lo más difícil es elegir cuál es el más adecuado. Hay 43 temporadas (y media, ahora) de videos para elegir. Es un poco como aquel capítulo de South Park de “Simpsons did it”. Hace tanto que existe Yunguseng Dojang que alguna vez tiene que haber mirado una situación similar.

Lo otro, y que asumo totalmente que soy un boludo, es que todas las semanas manda un email titulado “this week’s highlights”, con links a videos de la semana. Yo asumí que eran los videos de las reviews de los partidos, y al principio ni miraba el mail. Resulta que no, que hay siempre un video que es “this week’s highlights”, que agarra un patrón o situación o algo que se haya repetido en los partidos de la semana y hace una mini-clase sobre eso, y es re útil.

Así que bueno, entre esas dos cosas, la mitad de mis almuerzos los paso mirando videos de go. El único problema es que me está trancando la lectura.

Partidos

Esta vez no voy a poner ningún comentario. Que el papelón hable por su propios medios.

Primera ronda

Segunda ronda

Tercera ronda

Cuarta ronda

Quinta ronda

Mirando para adelante

Como mencioné la última vez, tengo paga toda la temporada, y eso es hasta principios de julio. Dos ciclos más. Después de eso, la verdad, no sé si voy a seguir.

O sea, me está sirviendo, estoy aprendiendo, y la verdad me gusta esto de jugar un partido “serio” por semana. Pero por otro lado, consume un montón de tiempo. No sólo el partido, sino también la clase, y la review. Y también es bastante presión. No sólo porque no me guste perder (aunque no voy a negar que un poco me afecta), sino porque hay un tema de responsabilidad también. Si yo juego sin ganas, y sin esforzarme, el resultado es un partido del cual no hay mucha cosa para mirar a la hora de la revisión, y eso no me jode sólo a mí, también jode a mi oponente.

Y bueno, al final, si bien está bueno lo de jugar, y eso, capaz que prefieron no tener esa fuente extra de ansiedad.

Igual no sé, falta un cacho para julio. Tengo tiempo para decidir. Y también está la opción de anotarme como “observador”, que es más barato, y me da acceso a las clases (y al buscador de patrones), sin tener el compromiso y la presión de un partido por semana. Vamos a ver.

Claude, de nuevo

Fri, 15 May 2026 20:59:41 -0300

Hace un tiempo comenté sobre Claude, y cómo, por cuestiones del trabajo, me veo obligado a usarlo. También comenté sobre mi experiencia al usarlo. Pero eso fue básicamente una primera impresión, después de pocos días de uso. Quería dar una pequeña acrualización, para ver qué tanto de mis impresiones iniciales se mantienen. También, ya que estoy, tengo algunas cosas más para agregar después de varias semanas de usarlo.

Revisando mis Opiniones

Claude no va a reemplazar a un programador

Esto es tal vez la opinión más fuerte que tenía en ese momento. Y la mantengo. Claude comete errores, muchas veces muy graves, que requieren que estés al tanto de lo que está haciendo. Sí, hay un montón de cosas que podés delegarle y olvidarte, y confiar en que no te va a romper todo, pero también hay montones de otras cosas que no, no es una buena idea.

Esto no significa que Claude (y herramientas similares) no vayan a causar una disrupción enorme en la industria. Cory Doctorow ha dicho varias veces que un modelo de lenguajes no puede hacer tu trabajo, pero un vendedor de modelos de lenguajes puede fácilmente convencer a tu jefe de que sí puede. Además de eso, incluso sin reemplazarte, si Claude te hace más rápido, significa menos horas de programador necesarias para completar las mismas tareas. Y eso me lleva al primer punto donde cambié un poco mi opinión.

Sí, Claude es más rápido que hacerlo a mano

¿Por qué cambié mi postura? Bueno, en parte porque empecé a aplicarlo a tareas más complejas, donde la diferencia de velocidad es más notoria (por una simple cuestión de escala), y en parte porque un poco de toquetear la configuración y adaptarme al flujo de trabajo hace bastante diferencia.

Admito que cometí un error que debería haber sabido que era un error. Asumí que, como tiene la interfaz más fácil de entender de la historia de las computadoras, entonces el aprender a usarlo iba a ser inmediato. Que la curva de aprendizaje era esencialmente una constante. Eso obviamente es falso. La curva de aprendizaje es bastante plana, sí, pero no quiere decir que no haya algunas cosas que aprender. Y esas pocas cosas hacen pila la diferencia.

Igual no siempre va a ser más rápido usar Claude que hacerlo a mano. Claude no tiene contexto. No tiene memoria. Emula esas cosas mediante ciertas instrucciones escondidas, pero las tiene que evaluar cada vez. Por poner un ejemplo bien básico, si yo te digo que hay que cambiar un mensaje de error por otro, y conocés el código, vas a saber derecho a qué archivo ir. O si no sabés exactamente, tenés una idea de por dónde puede estar, y con un grep rápido lo encontrás al toque. Claude no puede tener esa capacidad, por la misma forma en la que está construído un modelo de lenguajes. Para poder aprender realmente, y tener memoria, tendrías que poder ir adaptando los pesos del modelo con el uso. Eso no es posible por un montón de razones, entonces lo que pasa es que Claude simula memorias.

La forma en la que Claude simula memorias y conocimiento del contexto particular del proyecto es metiendo instrucciones y referencias en archivos Markdown. Por ejemplo, si Claude encuentra un archivo CLAUDE.md en la raíz del proyecto, lo lee y lo interpreta como un mensaje enviado al principio de cada sesión. Por el mismo formato con el que funcionan los LLMs, eso significa que esas mismas instrucciones se releen con cada mensaje que mandes. Esto simula conocimiento, pero obviamente no lo es. Las sesiones de Claude son igual de stateless que los requests HTTP. Que vos estés mandando cookies con cada request no hace que HTTP sea stateful, y de la misma manera que vos estés mandando un montón de instrucciones al principio de cada sesión no hace que Claude tenga conocimiento sobre el proyecto. Lo que estás haciendo es esconder todo ese trámite abajo de la alfombra.

Claude también te permite guardar cosas en “memoria”, que es el mismo concepto del CLAUDE.md pero en otro archivo y en general localizado a tu instancia local del proyecto. Claude incluso puede escribir esas memorias, lo cual profundiza un poco la simulación de memoria. Tenés que ser explícito en pedirlo. Vos le podés decir que, volviendo al ejemplo de arriba, tus mensajes están todos en el directorio ./assets/i18n, y Claude va a usar esa información durante esta sesión, pero cerrás y volvés a abrir y esa información desapareció. Para que se acuerde tenés que decirle algo bien explícito, tipo “acordate siempre en el futuro que los mensajes están todos en ese directorio”, y ahí va a escribir eso en un archivo (creo que es MEMORY.md) que va a ejecutar, de nuevo, al principio de cada sesión. Por razones bastante obvias, el conocimiento que se puede almacenar es mucho más limitado que el que podés tener con una memoria humana real.

Entonces, de nuevo, suponete que querés cambiar el mensaje de error. Si lo hacés a mano, en un proyecto que conocés, vas directo al archivo, o, como mucho, un grep rápido. Pero si le decís a Claude que lo haga, le mandás un mensaje diciendo “hay que cambiar este mensaje de error”, y lo que le estás mandando en realidad es un mensaje que dice todas sus memorias y contexto del proyecto (las que le dijiste explícitamente que guarde), y luego “hay que cambiar este mensaje de error”. Claude no va a “saber” qué archivo es. En el contexto, en todo ese mensaje enorme e invisible que le mandaste, capaz que dice algo tipo “los mensajes de la aplicación se guardan en este directorio”, pero ahí tiene que encontrar el mensaje específico. El modelo de lenguaje de fondo responde algo tipo “con esta información el siguiente paso es hacer esto”. Capaz que es un grep, y hace el grep, y entonces repite todo ese contexto pero agregándole ahora el resultado del grep, y entonces el modelo responde “ok, ese es el archivo, hay que leerlo, y ver exactamente qué cambiar”, y entonces manda a ejecutar otro grep pero diciéndole que imprima más contexto, y entonces pasa todo el chat anterior (contexto, memorias, mensaje original, resultado del grep) agregando el nuevo grep, y así hasta que eventualmente dice “lo que hay que hacer es generar este diff”, y te lo presenta y vos lo aprobás.

Todo ese ciclo es esencialmente invisible para vos. Lo que vos viste es que dijiste “hay que cambiar este mensaje de error”, y después de un rato de procesar, y tal vez pedirte permiso para usar grep, y varios mensajes diciendo que cargó “memorias” o “skills” varias, eventualmente te muestra un diff y te dice “¿cambio esto?”. Pero es fácil ver cómo para muchos casos bien sencillos puede ser más rápido hacerlo a mano.

El tema es que una vez que estás en la rosca de hacer todo con Claude (porque te acostumbraste, o porque te obligan, o por lo que sea) es re fácil caer en la pereza. Por ejemplo, el otro día hice un ls y me encontré con dos archivos en la raíz del proyecto que no tenían que estar ahí. Verifiqué rápido, y sí, los había agregado yo (sí, mal yo) en un par de merge requests en días anteriores. Obviamente había que borrarlos, así que mi primer reflejo fue ir a la terminal de Claude y decir “hay que borrar estos dos archivos”. Ridículo, sí, y no, no lo hice al final, me frené a tiempo y lo hice a mano (era literalmente un git rm y un git commit), pero el punto es que mi instinto fue ir a lo fácil.

Claude sigue siendo aburrido

Mi gran queja en el post anterior era justamente esa, que Claude no es divertido. Y no hay vuelta, sigue siendo aburrido. Sí, es más rápido, pero realmente sentís que no estás haciendo nada, sos como Homero Simpson en aquel capítulo en el que dejaba el patito apretando la Y. Y tampoco podés dejarlo andando solo al patito, porque tenés que revisar y ver que Claude no haya decidido que, no sé, capaz que en lugar de actualizar el proyecto original de la dependencia, era más fácil modificar los archivos dentro de node_modules, y al carajo todo. Sí, eso es una anécdota.

Mi queja nueva: Claude tiene la comunicación más ineficiente posible

En la ciencia ficción, cuando tenés inteligencias artificiales, siempre se pueden comunicar de maneras super eficientes, pasando datos crudos, bien compactos, sin redundancia, sin ambigüedades. Claude no funciona así.

En este momento, en el proyecto en el que estoy trabajando, hay un LLM en cada paso. Alguien a un nivel medio alto tiene una idea, la tira a un LLM para que genere una descripción. La pasa a un product owner, que la tira a un LLM para que genere una epic más detallada. Esa epic la agarra un tech lead, que se la tira a un LLM para que, mirando el proyecto, genere una serie de historias para implementar esa epic. Luego cada una de esas historias la agarra un desarrollador, que se la pasa a un LLM que escribe el código, y genera el merge request, y luego le avisa a otro desarrollador para que se lo pase a su LLM y para que revise el código y diga si aprueba o no. Hay cinco LLMs diferentes ahí, comunicándose a cada paso mediante las formas más ineficientes de lenguaje natural corporativo.

Pero ok, está bien, digamos que en realidad acá el problema es que los LLMs tienen que mantener a los humanos enterados de lo que están haciendo, y en cada paso lo que genera el LLM es un artefacto para consumo humano, no sólo de otro LLM, y ta, te la llevo. Pero volvamos al sistema de contexto y memoria que mencionaba arriba. ¿Todas esas memorias que escribe Claude? Sí, todo en lenguaje natural. Y con las posibles ambigüedades que siempre vas a tener cuando tenés lenguaje natural.

Y sí, esas ambigüedades sí aparecen. Por un ejemplo, tengo un proceso que corre y me manda un email cada día con un resumen de merge requests y mensajes de Slack y otras cosas en el proyecto. Ese email se genera con Claude (sí, quería jugar). Resulta que de un día al otro me cambió el formato de una sección del resumen. No sé por qué, pero sí es cierto que el nuevo formato cumple igual de bien la especificación que el formato anterior. Y otro día decidió no agregar los archivos adjuntos que tenía que agregar. Tampoco sé por qué, sólo pasó. Y no, no es sólo porque mi especificación es ambigua, porque la versión actual de la especificación para ese email es 100% escrita por Claude. Y de esa misma manera escribe las memorias. Y entonces le decís “acordate de siempre escribir tests primero, luego ejecutarlos, luego escribir la implementación”, y te dice “sí, ya está, me lo acuerdo”, y sale un mensaje de que escribió una nueva memoria, y después en una sesión dada es totalmente aleatorio si le da bola a ese cacho de instrucciones o no, y no hay mucho que puedas hacer al respecto, excepto toquetear esas instrucciones un poco y ver si por alguna casualidad le pegás al encantamiento correcto.

Y no sólo en esas cosas, sino también en la comunicación interna entre distintas “partes” de Claude. Si Claude ejecuta un subagent, las instrucciones para este van en forma de lenguaje natural, y sí, de nuevo, el tema de ambigüedades está presente.

El lenguaje natural tampoco es ideal para la comunicación humano-máquina

Las computadoras, en general, son cosas simples. Ejecutan una secuencia de comandos, uno atrás de otro, y dado el mismo estado inicial y la misma secuencia de comandos en el mismo orden, el resultado va a ser el mismo cada vez. Sí, ta, sobre eso construímos una torre enorme de cosas re complejas que simulan muchas tareas corriendo a la vez, y eso agrega un poco de impredecibilidad, y un montón de otras cosas, pero al final, si vas a lo más básico, una computadora es una máquina determinista. Y los lenguajes de programación que usamos son, también, deterministas. Un programa en cualquier lenguaje de programación de uso corriente es algo totalmente determinista y no ambiguo, asumiendo entradas constantes. Hasta para los números al azar usamos algoritmos deterministas para simularlos (o leemos entradas desde afuera del sistema). Sí, podés errarle y hacer un programa que no haga lo que querías, pero sí va a hacer lo que le dijiste que haga.

Los humanos no pensamos así. Los humanos pensamos en lenguajes ambiguos y desordenados. Crecemos con eso desde chicos, y aprendemos, algunos más y otros menos, a manejarnos con la ambigüedad constante. Cuando decimos algo, ese algo viene con un montón de contexto cultural y social y también específico de la relación con la otra persona, y todo eso lo tenemos en cuenta automáticamente cuando interpretamos el mensaje. Sí, a veces le erramos, y tenemos todo un género de películas esencialmente basado en la idea de que, a veces, uno dice algo y otro entiende otra cosa.

El trabajo de los programadores es, justamente, traducir desde esa sopa extraña de ambigüedades y conocimiento y contexto que es el lenguaje natural a algo concreto y específico como es el código de un programa.

El tema es que esa falta de ambigüedad de las computadoras es un feature, no un bug. Si yo escribo ls o ls -a, está muy clara la diferencia en la intención. Si yo te digo “mostrame todos los archivos de este directorio”, no está claro si estoy incluyendo o no los archivos ocultos. Ok, es un ejemplo boludo, y el “costo” de errarle es esencialmente cero, pero cuando tu interfaz deja de ser comandos concretos y no ambiguos y pasa a ser lenguaje natural, estás eliminando la posibilidad de tener procesos repetibles.

Y no estoy simplemente hablando en teoría. Aparte de lo que mencionaba arriba del email de resumen, que cambia de día a día, esto es algo que pasa constantemente con Claude. Si le decís a Claude algo tan simple como “monitoreá el continuous integration y avisame si falla algo”, el cómo implementa ese monitoreo es totalmente impredecible. A veces pone algo en un comando llamado /loop, que le dice “dentro de tanto tiempo ejecutá este mensaje”, y a veces hace un loop en bash con un for y un sleep y lee la salida de ese comando en el fondo. Por qué elige uno u otro, y en qué casos, es un poco misterioso. Capaz que hay algunas palabras mágicas específicas que le podés decir para que use uno u otro, estoy seguro que la hay, sí, pero el punto es que por defecto no sabés qué va a hacer.

Y mirá, capaz que es porque soy viejo y no me adapto a las formas modernas, pero cuando era joven si un programa funcionaba de maneras impredecibles con la misma entrada, lo considerábamos bugs.

The Mercy of Gods - James S.A. Corey

Fri, 08 May 2026 20:49:21 -0300

The Mercy of Gods es el primer libro de la nueva serie de James S.A. Corey. James S.A. Corey es, por supuesto, el pseudónimo bajo el que Daniel Abraham y Ty Franck escribieron la serie de The Expanse. Decir que arranqué el libro con expectativas altas se quedaría corto.

La historia sigue a un grupo de humanos del planeta Anjiin, que tienen la mala suerte de vivir durante el primer contacto con los Carryx. El imperio de los Carryx es brutalmente genocida. Todo lo que encuentran a su paso mientras se expanden por el universo lo catalogan en dos categorías: lo que les es útil, y lo que no. Lo que es útil lo esclavizan y domestican, y lo que no, bueno, lo desechan.

“I think some important scientific questions have finally been answered. Alien life exists, and they are assholes.”

Dafyd Alkhor y su grupo de trabajo, uno de los mejores equipos científicos de Anjiin, tienen que demostrar su utilidad para los Carryx, bajo pena de muerte. No muerte de ellos, solamente, sino de toda la humanidad: si los humanos no son útiles para los Carryx, entonces les espera el genocidio.

Ok, no, no toda la humanidad. Los humanos de Anjiin. No sabemos qué pasa con los humanos de la Tierra, o si siguen existiendo. Los humanos llegaron a Anjiin hace mucho tiempo, trayendo consigo plantas y animales, que ahora viven junto con la vida totalmente diferente que evolucionó en Anjiin. El cómo llegaron a Anjiin es algo que se perdió en el tiempo. Los Anjiinianos saben que no son nativos de su planeta, saben que sus antepasados llegaron en naves espaciales, y saben que posiblemente haya otros humanos dando vueltas por ahí.

El world building me hizo acordar mucho a Adrian Tchaikovsky (autor de la serie de Children of Time y también de Shroud). Eso es, si ves mi opinión de Shroud, una excelente noticia. Tiene ese estilo “tchaikovskesco” de darte perspectivas de extraterrestres no humanos, y que son claramente no humanos, tanto en su biología como en su forma de ver el mundo.

Justamente entender esa psicología totalmente diferente de los Carryx es lo que preocupa a Dafyd, que es el personaje que más sigue la narrativa. Dafyd empieza siendo el más bajo en la jerarquía del grupo de trabajo de Tonner Freis. No sólo es el más joven e inexperiente, sino que parte de la razón por la que tiene el puesto es porque su tía tiene un puesto alto. Dafyd no es un excelente científico. Tampoco es totalmente inútil, pero al lado del resto del equipo, no está a la misma altura. Lo que sí tiene Dafyd es un instinto mucho mejor para intentar empezar a entender (muy de a poco) cómo piensan los Carryx, y cuando la vida de todo un planeta depende de demostrar utilidad para los Carryx, eso de repente se convierte en algo bastante importante.

En cuanto al tono, el libro es, obviamente, un libro bastante violento. Los personajes son prisioneros de extraterrestres genocidas que los tienen en un campo de exterminio, trabajando bajo la amenaza de la extinción. Por supuesto que va a ser jodido. Por otro lado, una parte del libro está dedicada a cómo los prisioneros logran de a poco hacerse un pequeño lugar y tener la ilusión de un pedazo de vida normal. Es una forma de darle un poco de optimismo. También hay unos fragmentos entre capítulos que dan a entender que, eventualmente, tal vez la humanidad logre ganarle a los Carryx. No lo dice explícitamente, pero lo sugiere, y capaz que sin esa pequeña sugerencia de que, capaz, al final de la serie hay un “vivieron felices”, el libro sería mucho más triste. Además, sabemos que los Carryx están peleando una guerra eterna, que lleva generaciones, contra un enemigo misterioso.

“It’ll be all right,” he said.
“It won’t”
“No. But we’ll find a way to be all right with that.”

La verdad es que el libro me gustó pila. Lo terminé bastante rápido. Siempre viene bien un libro que me encanta justo después de leer un libro que no me gustó mucho.

Tiene, eso sí, un par de cosas que no me convencieron. La principal es que hay twists que son bastante predecibles. Sí, ok, entiendo que Dafyd no lo sabe cuando lo vemos a través de sus ojos, pero la narrativa lo trata como una revelación al “esconderlo” por unos capítulos más, cuando es más que obvio lo que pasó. Igual tampoco me parece tan grave, sólo que me rechinó un poco las veces que pasó.

Igual, es un problema re menor. El libro es totalmente recomendable. Y, por suerte, ya salió (el mes pasado) el segundo libro de la serie. Y también una novela corta, en el medio, como para ir tirando.

★ ★ ★ ★ ★

On Vicious Worlds - Bethany Jacobs

Fri, 01 May 2026 19:45:53 -0300

On Vicious Worlds es el segundo libro de la trilogía Kindom, de Bethany Jacobs. These Burning Stars es el primer libro de la serie.

La trilogía es un space opera bien clásico. Naves espaciales, tecnología que bien podría ser magia, y bastante acción.

En cuanto al setting, la historia está ambientada en tres sistemas estelares unidos mediante portales que permiten viajar más rápido que la luz. Los tres sistemas forman el Kindom, y están gobernados por el Treble, que es un sistema donde el gobierno se reparte entre tres Hands, con distintos focos: están los clérigos, los secretarios, y los cloaks, una cruza entre asesinos, soldados, y policías. Básicamente, religión, burocracia, y fuerza bruta. Además de esto hay un grupo de familias que controlan el poder económico, y que son quienes proveen las cúpulas de cada una de las tres organizaciones del estado. Ya de entrada esto te promete un mundo bastante de mierda, y sí, no hay sorpresas por ese lado. Además, la trama de la trilogía está bastante atada a un genocidio cometido un par de generaciones antes de que empiece la historia.

También tiene magia, que no es magia, pero es magia. Están los casters, que son una especie de hackers/programadores y que crean programas en entornos multisensoriales que les permiten manejar la tecnología de manera que si agarrás y cambiás todo el setting por fantasía y los casters por magos, no tenés que cambiar mucho. El space opera tiende a este tipo de “fantasía en el espacio”, y esta trilogía es un excelente ejemplo.

El primer libro sigue a Chono, una clérigo que está al servicio de Esek Nightfoot, miembro de una de las familias más importantes, mientras va descubriendo qué pasó con su viejo compañero de clase que persigue a Esek para matarla, y también qué pasó con ese genocidio que mencionaba antes. El primer libro no me pareció brillante, pero sí me gustó lo suficiente como para decidirme a leer el segundo. En su momento le puse 4 estrellas, a pesar de que me costó un poco entrarle a la historia. Al final se puso mejor.

La verdad es que These Burning Stars tiene un final. Casi que decir “el primero de una trilogía” es mucho. Aparentemente esto es algo que se da mucho con autores primerizos. Van con un libro escrito, y se lo muestran a un agente, que se lo vende a una editorial como el primer libro de una trilogía, porque eso vende más. Si el libro vende bien, el autor tiene un contrato para dos más, golazo. Si el libro no vende bien, y bueno, tampoco hubiese vendido bien si fuese un libro solo. Entonces tenés estas trilogías en las que hay un primer libro que tiene un final que cierra relativamente bien, seguido de un segundo libro que termina en terrible cliffhanger, y un tercer libro que puede (o no) darle un cierre satisfactorio a la historia.

On Vicious Worlds cae en este patrón. La historia de These Burning Stars está bastante cerrada. Sí, por supuesto, quedan un montón de puntas de las que agarrarse para las (entonces potenciales) secuelas, pero la narrativa tiene un final. Pero On Vicious Worlds no, todo el libro parece una preparación para el tercero.

Y la verdad es que no me resultaría tan malo si el libro me hubiese gustado, pero no, no me gustó. Me costó mucho leerlo. Tiene para mi gusto demasiadas escenas de acción, que parecen sacadas de una película de Hollywood super taquillera. Incluso tiene algunos diálogos salidos de película de acción.

“You sent five guardsaan to apprehend me, Ilius. I’m offended.”
– Sí, a este nivel es la cosa

Ok, ponele que me banco un poco la acción y los diálogos cliché si la historia está buena. Pero no, ni siquiera eso. No pasa mucha cosa, y hay dos historias en dos mundos diferentes que te van contando a la vez, y que no se conectan hasta el final, y que la verdad es que ninguna de las dos está demasiado bien. El que evidentemente es el villano de la serie no aparece hasta las últimas páginas, y viene y esencialmente borra todo lo que pasó en el libro. No puedo decir demasiado sin caer en spoilers, pero el punto es ese: no me gustó.

Me anoté el tercer libro (This Brutal Moon) en la lista de libros para leer, pero más por mi necesidad de completar series que porque realmente esté esperando para leerlo.

★ ★ ☆ ☆ ☆

Claude me persigue

Thu, 30 Apr 2026 08:21:44 -0300

Ya ni puedo jugar al go tranquilo

Windows te come el disco y no sé ni por qué

Sat, 25 Apr 2026 17:30:27 -0300

Tengo un software que sólo está para Windows (y Mac) y no lo logré hacer andar bien con Wine. Como es el software del plotter de corte Silhouette, tampoco es que sea fácil encontrar una alternativa. Entonces lo que hice fue instalarlo en una máquina virtual.

A la máquina virtual le dí 30GB de espacio en disco, asumiendo que iba a ser más que suficiente. Todo lo que necesito, después de todo, es el sistema operativo, y el Silhouette Studio. Nada más. ¿Cuánto puede ocupar todo eso?

Bueno, resulta que ayer Silhouette Studio se empezó a quejar de que no quedaba mucho espacio en el disco. Miro, y queda alrededor de 1GB libre. No es mucho, pero bueno, funcionaba bien, así que ok. Un poco más tarde, me cambia el mensaje de error: ahora no tenés suficiente espacio como para arrancar el programa, esto ya no es una advertencia, es un error. Miro, y tenía 130MB libres. ¿Qué cambió? Nada, absolutamente. Sí, usé un poco el Silhouette Studio, pero los datos los guardé en un directorio compartido que está en la máquina host.

Hoy estuve mirando un poco, viendo a ver si había cosas que borrar, y ta, borré algunas, pero igual, no subía de medio giga de espacio. Y lo peor: fluctuaba. De repente tenía 500 MB libres, de repende 200, de repente 600.

Al final le aumenté el tamaño del disco virtual, tampoco me voy a preocupar demasiado. Pero ta, no puede ser que no puedas ni saber cuánto espacio libre te queda, porque cambia cada dos minutos sin que hagas nada.

Playlist ACAB (en español)

Fri, 24 Apr 2026 20:08:10 -0300

El otro día publiqué un pedido de recomendaciones musicales en Mastodon.

https://mastodon.uy/@nachof/116348465939960678

Acá dejo la lista de respuestas, compilada, con links a videos en YouTube:

Spotify

Casi todas las canciones están en Spotify. Hice una playlist con las que encontré.

Por supuesto, sigo abierto a más sugerencias.

Arcs

Fri, 17 Apr 2026 15:57:32 -0300

Arcs es un juego diseñado por Cole Wehrle e ilustrado por Kyle Ferrin. Como si eso no fuera suficiente, además está ambientado en EL ESPACIO. No sé si podés describir un juego en un párrafo tan corto y que me llame más la atención que esto.

Imagen de BGG

Cole Wehrle y Kyle Ferrin son el equipo atrás de juegos como Root y Oath. No se puede tener mejores credenciales que ellos.

Hace tiempo que lo venía mirando al juego, pero durante un tiempo no había versión en español. Últimamente trato de comprar sólo juegos en español, por varios motivos. Principalmente, porque quiero poder jugar con gente que no maneja otros idiomas sin sentir que los estoy dejando un poco por fuera. Así que por un tiempo, lo miraba con ganas, pero no lo iba a comprar. Hasta que 2Tomatoes sacó la traducción el año pasado. No puedo decir que sea fan de la traducción, pero bueno, funciona.

De qué se trata

En Arcs manejás a un imperio espacial, compitiendo con otros imperios para ganar puntos mediante conquistar planetas, construir naves, y destruir al oponente. Más o menos la misma idea que otros juegos como Twilight Imperium o Eclipse.

Mecánicamente, tiene un poco de control de áreas y un poco de juego de bazas, y con eso bastante de manejo de mano.

Cómo se juega

El juego se divide en cinco “capítulos”. Al final de cada capítulo se puntúan las “ambiciones” que los jugadores hayan elegido, y gana el primero en llegar a cierta cantidad de puntos (dependiente del número de jugadores). Si nadie gana antes del final del capítulo 5, gana el que tenga más puntos.

Capítulo

En cada capítulo, se reparten seis cartas a cada jugador, y luego se juegan varias rondas. En cada ronda, el jugador inicial (el que tiene la “iniciativa”, representada por una escultura) juega una carta, que tiene un palo, un número, y una cantidad de acciones. Dependiendo del palo (agresión, construcción, administración, movilización) es qué acciones puede hacer, y la cantidad de acciones marcadas es cuántas de esas acciones puede hacer.

Luego del turno del jugador con la iniciativa, el resto de los jugadores, en orden de turno, juegan una carta para “sobrepasar”, “copiar”, o “pivotar”. Sobrepasar es jugar una carta del mismo palo que la inicial, pero con un número más alto. Copiar es jugar una carta cualquiera, boca abajo. Pivotar es jugar una carta de un palo diferente, de cualquier número. Si copiás o pivotás, podés jugar sólo una única acción. Si copiás, hacés una acción de la carta inicial, mientras que si pivotás hacés una acción de la carta que jugaste. Si sobrepasás, hacés tantas acciones como indica tu carta, del palo de la carta que jugaste (que es el mismo que la carta inicial).

Cuando jugás una carta y no tenés la iniciativa, podés “arrebatarla”, ya sea sobrepasando con un 7, o jugando cualquier otra cosa y descartando una carta extra. Si arrebatás la iniciativa, vas a tenerla para la siguiente ronda. Si nadie la arrebata, al final de la ronda se la lleva quien haya sobrepasado con la carta más alta, o se la queda el jugador que la tenía si nadie sobrepasó ni arrebató.

Cuando nadie tiene más cartas, puntuás las ambiciones, y si nadie ganó, repartís cartas y arranca el siguiente capítulo.

Las ambiciones

La única forma de hacer puntos en Arcs es con las ambiciones. En cada capítulo puede haber hasta tres ambiciones diferentes que puntúen. Para que una ambición puntúe, alguien tiene que “declararla”. El jugador con la iniciativa tiene la posibilidad de, al jugar una carta, declarar una ambición (cuál, depende de la carta). Al declarar una ambición, esa ambición va a puntuar al final del capítulo, y todos los jugadores compiten por ella (no sólo el jugador que la declaró). Además, el valor de la carta inicial es cero si se declara ambición, lo cual da un poco de tensión porque declarar una ambición hace que sea mucho más fácil sobrepasar con otra carta.

Hay cinco ambiciones diferentes. Tres de ellas consisten en acumular recursos de diferentes tipos, y las otras dos en acumular “trofeos” y “cautivos”, que son piezas de los oponentes que podés obtener mediante combate (trofeos) o acciones más diplomáticas o administrativas (cautivos).

Además de toda esta estructura básica, hay algunas otras reglas menores. Notablemente, hay unas cartas que modifican las reglas y que se pueden obtener durante el juego.

Me gustó pila este juego

Al momento de escribir esto, llevo dos partidos jugados, y la verdad que me gustó pila. No es perfecto, porque ningún juego lo es, pero tiene un montón de cosas que me gustaron pila.

Primero, lo malo. Lo malo es, esencialmente, la duración. El manual dice media hora por jugador si son jugadores experimentados, 45 minutos para jugadores nuevos. Jugando de a cuatro (las dos veces jugamos de a cuatro), eso significaría unas tres horas, que ya es un juego largo. Pero se fue a más de cuatro horas. Ok, ya estoy acostumbrado a que los juegos me mientan con la duración, pero si me vas a dar una duración específica para novatos, espero un poco más de acierto.

Después de eso, no tengo muchas quejas. Sí, hay un montón de reglas, pero no es tan complejo de explicar, y las reglas tienen sentido una vez que entendés el concepto general del juego. Lo más complicado de todo es la acción de atacar, que tiene un montón de pequeñas vueltas, porque hay bastantes resultados posibles. En particular, hay toda una sección de consecuencias feas si destruís una ciudad (intencionalmente o accidentalmente, que puede pasar también), que puede ser un poco mucho al principio.

Pero justamente esa regla de destrucción de ciudades toca lo que me parece uno de los mejores aspectos del juego: la conexión temática de las reglas. Destruir una ciudad tiene consecuencias, porque estás destruyendo una ciudad. Estás cometiendo un genocidio. A la gente no le gusta eso, y si rompés una ciudad, perdés todos los recursos del tipo asociado a la ciudad, y todas las cartas con ese ícono de recurso, y no podés usar más la habilidad del recurso (cada recurso tiene una habilidad que casi siempre significa “una acción gratis”). Y esa última es permanente. No volvés a poder usar ese recurso por el resto del juego. Destruir ciudades se siente como un suceso importante. Cuando alguien destruye una ciudad, se nota. No es lo mismo que destruir una nave, o incluso que destruir el otro tipo de estructuras (los espaciopuertos).

La otra cosa que le da mucho peso narrativo a las reglas es todo el tema de las ambiciones. Todas las cosas que podés tener que juntar son limitadas. Si lo tenés vos, no lo tiene otro. Si estás compitiendo por, por ejemplo, la ambición Guardián (juntar la mayor cantidad de íconos de reliquia entre cartas y recursos), estás compitiendo por un pedazo de una torta bastante limitada. Hay cinco recursos de cada tipo, o sea que, dejando de lado las cartas, hay sólo cinco otros íconos que conseguir. Por otro lado, las cartas son mucho más difíciles de conseguir: para conseguir un recurso, sólo tenés que hacer la acción tributar en un planeta del recurso correcto, pero para conseguir una carta tenés que hacer la acción influenciar, y luego en otro turno (normalmente en otro turno) hacer la acción asegurar, esperando que no te hayan sacado la mayoría de influencia sobre la carta. Entonces lo que pasa es que cuando hay una ambición declarada (o cuando la mesa se ve venir que alguien va a declarar una ambición específica), hay una carrera por conseguir los elementos necesarios para ganarla. Ah, sí, también es importante que sólo dos (como mucho) puntúan, así que si quedás en tercer lugar te cagaron y todo el esfuerzo fue al pedo.

Pero eso es como cualquier otro juego, me dirás, y es cierto, sí, es como cualquier otro juego. Pero por alguna razón en Arcs se siente muy fuerte ese peso. Con la ambición Señor de la Guerra (juntar trofeos, que es piezas matadas en combate), por ejemplo, hay un incentivo en atacar y destruir naves, sí, pero el tema es que las naves (y otras piezas) destruídas quedan en trofeos, o sea, no las podés volver a construir. Entonces de repente tenés un capítulo en el que arrancás con un tablero lleno de naves y termina con todo casi vacío, y pequeñas bandas de naves cazando supervivientes para rascar esos últimos trofeos y ver si ganás algo, sin poder poner refuerzos porque no tenés naves en la reserva, están todas en trofeos de los oponentes.

Todas esas víctimas y no llegué a puntuar

Y de nuevo, en teoría, ese tipo de cosas está en muchos juegos, pero siento que en Arcs está más presente que en muchos otros juegos. No sé por qué, pero lo siento así.

Y ta, sí, mucho de eso es gustos personales. El hecho de que sea EN EL ESPACIO me llega. Pero la verdad es que me gustó mucho el juego, y ya quiero jugar de nuevo.

Claude Code: tengo Opiniones

Fri, 10 Apr 2026 21:13:42 -0300

Por cuestiones que no termino de entender, el uso de Claude en el proyecto en el que estoy es esencialmente obligatorio. Eso significa que lo usé un poco en los últimos dos días¹. Tengo Opiniones.

Pero resumiendo, si alguien piensa que esta cosa puede reemplazar a un programador, incluso a un programador junior, está muy equivocado.

Mi punto de partida

Quiero ser honesto: de pique, no me gustan los LLMs. Hay bastante de rechazo al hype, que siempre me sale automáticamente. Pero también hay cosas que no me gustan. No confío en los LLMs, las respuestas que dan no son confiables, y la mayoría de las tareas que hacen son justamente la parte divertida de hacer las cosas. Si no estuviese obligado por la dirección en la que va la industria, no usaría Claude. Tengo mis razones para pensar esto, y personalmente creo que son muy buenas razones, pero independientemente de eso, es inevitable que este preconcepto tiña un poco mis opiniones.

El escenario

El proyecto en el que estoy trabajando actualmente es un proyecto complejo, tanto por la cantidad de cosas que hace, como por la estructura del mismo. Imaginate un montón de microservices que hablan unos con otros pero sin la parte de micro. Hay varios proyectos en un mismo repositorio, luego varios repositorios aparte con otras partes.

La aplicación en la que trabajo principalmente es una aplicación web (angular, typescript) que habla con un montón de APIs. Algunas de esas APIs están en el mismo repositorio, otras en otro. Además, hay otro repositorio que tiene unos tests end-to-end.

La tarea con la que usé Claude por primera vez es bastante sencilla: agregar nuevos tests end-to-end para una funcionalidad reciente. Si estuviese familiarizado con la tecnología que se usa para esos tests (playwright), y con la estructura específica del proyecto, posiblemente sería algo bien sencillo. Pero no es el caso. En teoría, esto debería ser un buen caso de uso para Claude: una incursión corta a un proyecto que no manejo, y el proyecto ya incluye unos “skills”², lo cual hace que debería ser fácil.

Claude Code

Claude Code es una interfaz de línea de comandos que te da un chat con el modelo de lenguaje. Vos le decís lo que querés en lenguaje natural, y va y lo hace, y te consulta si necesita datos. Esa es la teoría, al menos.

Claude tiene la posibilidad de ejecutar comandos por vos, lo cual da miedo, y está perfecto que sea así. Para evitar un poco ese miedo, te pide permiso cada vez que va a correr un comando, así podés revisar lo que hace.

Cuando tiene cambios para hacer, te muestra un diff y te pide confirmación. Acá y para ejecutar comandos, si le decís que no te pregunta “ok, ¿qué hago entonces?” y ahí le das nuevas instrucciones.

Expectativa contra realidad

La forma en la que mucha gente habla de esto es que podés dejarlo corriendo y te vas a hacer otra cosa mientras Claude trabaja por vos. La razón por la que mucha gente dice eso es al menos en parte porque es literalmente lo que te dice cuando entrás a claude.com.

Esto te prometen

Esto obviamente no es así. Claude te pide permiso para cada comando que ejecuta, y para cada cambio que hace, y tenés que estar ahí para hacerle de niñero. Sí, sí, podés decirle que tiene permiso para ejecutar cualquier comando o para hacer cualquier cambio que quiera, pero si hacés eso sos un suicida. Dejando un poco de lado la posibilidad totalmente real de que te tire un sudo rm -fr / así de la nada porque necesitabas espacio en el disco, un escenario mucho más probable es que se termine metiendo en un lío intentando arreglar algo por el camino equivocado y termine haciendo montones de requests y listando archivos y directorios y haciendo grep en directorios enormes, y cuando considerás que se cobra por la cantidad de texto (“tokens”) que manda o recibe, es un poco una locura. No tengo muy claro cómo le cobran a la empresa para la que estoy trabajando en esto, pero ya me pasó que me diga que estaba “rate-limited” por unas horas. No es ideal.

Así que sí, tenés que revisar qué está haciendo, porque así lo podés cortar cuando ves que se está yendo por las ramas por algo que no corresponde.

Y también tenés que revisar los cambios, porque se manda cagadas obvias. Un ejemplo: para agregar un paso que se ejecutara al final de cada una de las tres ramas de un switch, agregó tres líneas idénticas, una en cada case. Si lo estás revisando, ves ese diff y decís “no, pará, así no es”, y le decís que no, y le decís que mejor lo agregue al final del switch, y ya está. Si le dijiste que aplique todos los diffs automáticamente, vas a tener basura de esa por todos lados en nada de tiempo. Y ojo, este caso era re fácil porque justo era modificar algo y agregar esa línea, pero no me parece tan loco que te tire un diff de 500 líneas con varios problemas de este tipo, que no sean tan fáciles de ver porque 500 líneas.

Entonces no, no existe eso de dejarlo corriendo y que se encargue. Olvidate. A menos que no te importe nada el resultado final, es una mala idea. Sí, sí, todos los AI-bros te dicen que sí, y seguro que si alguno lee esto me va a decir que estoy haciendo todo mal y que no sé, algo. O que la legibilidad del código no es importante porque igual después también usás Claude para mantenerlo (leí ese argumento por algún lado, es muy triste).

Ojo, no es algo malo esto. Cualquier otra herramienta que uso necesita que esté ahí para usarla. Incluso si pongo a hacer un git bisect automatizado, tengo que monitorearlo por si algo sale mal, y bueno, eventualmente tomar decisiones respecto a la salida. No me extraña ni me parece mal que Claude tenga el mismo requerimiento. Lo menciono sólo porque parece ser una de las cosas que Anthropic te vende, y simplemente no es cierto.

Claude es una máquina y no es capaz de entender

Una de las razones por las que tenés que controlar lo que está haciendo Claude es que el código que escupe en general no es bueno. No sólo en cuestiones visibles a simple vista, como lo que mencioné arriba sobre el switch/case, sino también, y creo que más importante, en cuestiones de principio.

Por ejemplo, el caso de uso que mencionaba es crear unos tests end-to-end nuevos. Estos tests “usan” la aplicación y verifican los resultados. Esencialmente es una serie de operaciones como “hacé click en este botón, y fijate si aparece este texto”.

Inicialmente, Claude copió tests similares de otra parte, lo cual está perfecto, si lo hiciera a mano hubiese empezado por ahí, y luego los modificó. Hasta ahí todo bien. El problema empezó porque en los otros features similares era elegir una opción, dejar la configuración por defecto, y confirmar. En esta nueva opción que estábamos agregando, no existe una configuración por defecto válida: necesita información del usuario. Eso agrega un paso: ahora es elegí la opción, agregá esta configuración de prueba, y ahí hacé click en confirmar. El tema es que el botón de confirmar está deshabilitado inicialmente, y la entrada del usuario se valida por una llamada a otra API, lo cual significa que el botón de confirmar recién se habilita una fracción de segundo después. Fácil, le decís al test que espere a que el botón esté habilitado y luego siga (con un timeout para que no espere para siempre). El problema era que no estaba funcionando.

La propuesta de Claude era mirar las llamadas a la API, y recién intentar hacer click luego de terminar. Le dije que no, y me puse a mirar. El tema era que el botón no se deshabilitaba con la propiedad disabled, sino agregando una clase CSS. No me gusta ese tipo de cosas, pero bueno, así está hecho, hay que lidiar con eso.

Le dije a Claude que mirara la clase, modificó el test, lo corrió, y seguía fallando. De nuevo, se puso a “debuguearlo” mirando las llamadas a la API, y si lo dejás correr y hacer lo que quiera y no mirás qué está haciendo, te come unos buenos tokens en irse por las ramas con algo que no tiene nada que ver. De nuevo, lo frené, y miré yo el problema. Resultó que el selector que estaba usando el test apuntaba a un <div> y la clase de deshabilitar estaba aplicada a un <button> adentro. Un arreglo re sencillo, pero Claude “quería” ir derecho a la opción de olvidarse de los elementos de la interfaz de usuario y mirar las llamadas a la API.

Claude no sirve para debuguear

Y es que ese era el problema que estaba viendo con ese test, también. No sólo Claude quería hacer una modificación mala, Claude no sirve para debuguear. El error era obvio, y me llevó menos tiempo verlo que entender qué estaba haciendo Claude.

El tema es que debuguear una aplicación no trivial (o sea, cualquier cosa por la que te vayan a pagar por trabajar en ella) requiere mantener una buena cantidad de contexto en la cabeza. No me refieron a como los AI-bros usan contexto, de “tantas palabras de conversación”, me refiero a entender cómo se mueve el flujo del programa, y qué datos se modifican dónde, y saber en qué momento pausar y observar el estado para ver si hay algo fuera de lugar, y entender qué está fuera de lugar.

Todo eso requiere un nivel de razonamiento abstracto que es imposible para algo que tiene cero capacidad de razonamiento abstracto porque es sólo una cadena de Markov con cantidades obscenas de recursos y no una persona.

Sí, por supuesto, Anthropic (o el vendedor que sea) te puede construir escenarios en los que Claude parece que soluciona todo como por arte de magia, y te hacen un demo y vos quedás de cara, pero cualquier programador conoce ese truco. La demo para al cliente la probás veinte veces con el mismo escenario exacto, y si al momento de mostrarla te llegan a pedir que muestres un flujo ligeramente distinto entrás a sudar porque no sabés lo que va a pasar si te desviás de lo que probaste y sabés que funciona. Y cuando Claude se desvía, es una lotería. Capaz que lo hace bien, o capaz que lo hace catastróficamente mal, y te entra a comer tokens a lo bestia, y cuando te querés acordar pum, rate limited, y no estás más cerca de saber qué está pasando, porque Claude no explica.

Claude no explica lo que hace

Cada vez que Claude te pide permiso para correr un comando, incluye un pequeño resumen de qué es lo que está queriendo hacer. Te puede decir que va a correr find -name *.ts | xargs grep pepito y abajo dice algo como “buscar las ocurrencias de la variable pepito”, y ok, es literalmente eso. Te ayuda a leer el comando saber qué es lo que dice hacer, y podés validar que el comando funcione y no te esté rompiendo todo. Ahora, lo que no te dice es por qué corre ese comando. Sí, ta, sabés que está buscando la variable pepito, pero no sabés con qué objetivo. Podés preguntarle, pero no hay garantía de que te diga la verdad, o incluso que te diga algo. Me pasó más de una vez de preguntarle “¿por qué estás haciendo esto?” y que la respuesta sea una variación sobre “tenés razón, no es necesario, voy a hacer otra cosa”.

Si combinás esto con la tendencia que tiene Claude a irse por las ramas y perderse en algo totalmente irrelevante, el resultado no puede ser bueno. Sí, sí, si lo tenés controlado y vas analizando cada cosa que hace, podés limitar o hasta evitar este problema. Por otro lado, es otro punto más en contra de la promesa de “yo me encargo”. Y el nivel de esfuerzo empieza a parecerse a hacerlo yo.

Claude no es una persona

Ok, sí, es obvio, lo sabemos todos. Es evidente que Claude es un cacho de software, no es una persona, no tiene conciencia, ni sentimientos, ni capacidad de razonamiento, ni continuidad de memoria, ni nada que puedas usar para definirlo como persona, excepto la capacidad de interpretar (hasta por ahí nomás) y producir (más o menos) lenguaje natural.

El tema es que los humanos somos bichos raros. Tenemos un montón de atajos en nuestros procesos cognitivos. Hay dos puntos y un paréntesis y vemos una carita feliz. O triste. Porque parece que tiene dos ojos y una boca, y si tiene dos ojos y una boca es una cara, y tenemos unos cerebros con terrible capacidad de proceso pero esa capacidad de proceso viene con un costo energético alto entonces estos atajos que nos permiten ahorrar capacidad de proceso re sirven, sobre todo cuando el costo de errarle y ver una cara en la corteza de un árbol o en una roca no es tan importante pero el costo de no ver una cara donde sí hay una cara puede ser catastrófico si justo la cara era de un tigre o algo así. Y entre esos atajos tenemos eso de que hablamos con otras personas, y entonces si podemos hablar con algo ese algo es una persona. Y vos sabés que no es una persona, si parás dos segundos y lo razonás lo sabés³. El tema es más por el lado emocional que racional.

Y el tema, principalmente, se da porque Anthropic (y las otras empresas) hacen todo lo posible para antropomorfizar a sus productos. Claude tiene una interfaz de chat, y le hablás y te habla como una persona, y tiene un macaquito re lindo que te aparece cuando entrás al programa, y se llama Claude, que es un nombre de persona. Claro que yo sé que no es una persona, por supuesto que lo tengo claro, racionalmente lo sé. Pero cuando me enfrento al chat, siento el impulso de decir “por favor” y “gracias”, porque toda la interacción con Claude me hace despertar las neuronas de cuando interactuás con un ser humano.

Es linda la mascotita

Claude no es del todo inútil

Ok, si leíste hasta acá, seguro que ya te diste cuenta que mi experiencia no es de lo más positiva. Es cierto, no me gusta Claude. Y digo Claude porque es lo que usé, mis críticas aplican a cualquier otro LLM también. Pero eso no quiere decir que no sirva para nada.

O sea, al final, hice los tests con Claude. Fue en un proyecto que no conocía, así que posiblemente hacerlo sin Claude me hubiese llevado más tiempo. Igualmente, me tuve que apoyar en las notas de un compañero de trabajo que había hecho algo similar hace pocas semanas. Esas notas las tenía disponibles independientemente de Claude, y en algunos casos me ayudaron más que Claude. Si conociese bien el proyecto, no estoy seguro si Claude me hubiese ayudado.

Pero para otras cosas, más puntuales, ayudó también. Como buscador dentro de un proyecto, con interfaz de lenguaje natural, por ejemplo. Cosas como preguntarle cómo migrar la base de datos local a la última versión en un proyecto en el que no sabés qué stack exactamente está usando. Por supuesto, esa información estaba en el README del proyecto, y la podría haber buscado yo, sin necesidad de usar Claude. Claude es un poco más rápido, pero tampoco es que sea un ahorro de tiempo increíble.

Pero eso es un poco lo que pasa: Claude no puede hacer nada que no pueda hacer yo personalmente. Y sí, en varios casos es más rápido que hacerlo a mano, y la verdad es que uso muchas herramientas que hacen cosas que podría no necesitar. Por ejemplo, uso un editor con coloreo de sintaxis. Podría no usarlo, podría ver el código en blanco y negro (al final, así empecé a programar allá en mi juventud). Pero me ayuda. Claro, vim es gratis, y Claude no, lo cual plantea la pregunta obvia de si vale la pena.

No usaría Claude si no me viese forzado

Y al final esa es mi conclusión. Ta, sí, admito que vengo de un punto de partida contrario a los LLMs, como dije más arriba. Pero aparte, no disfruto usando Claude.

En el trabajo muchas veces voy a tener que usar herramientas que no disfruto. Es la naturaleza del trabajo en la sociedad en la que vivimos. Y Claude es un caso así. Tampoco volvería a usar ClearCase (el software de control de versiones de IBM) a menos que me vea obligado, así que no es que Claude esté solo en este sentido.

Pero hay una diferencia grande, también. ClearCase es horrible, y cada minuto de tener que usarlo fue una tortura, y los que lo crearon deberían ser llevados a La Haya. Pero lo que hace ClearCase es útil, y es algo que necesito. Resulta que hay mil opciones mejores, y obviamente hoy todos usamos git. ClearCase es una mierda, pero control de versiones es algo bueno. Claude… bueno, no me termina de quedar clara la ventaja.

Tampoco es que no haga nada. Hace cosas. Y a veces ayuda y todo. En algunos casos, incluso podés ver una mejora en productividad, si eso es algo que te importa. Si estás usando métricas ridículas como “cantidad de líneas de código escritas”, entonces te mejora. También vas a tener gente que dice ver una mejora enorme en cantidad de features completadas. Con mi experiencia hasta el momento, si estás ganando tanta velocidad, estás perdiendo en calidad de código. Y yo qué sé, sacrificar calidad del código para ganar velocidad tampoco es que sea una novedad, ¿no? Siempre pudimos hacer eso, y siempre decidimos no hacerlo, porque sabemos que la calidad del código es importante. Capaz que es más lento, sí, pero si tenemos menos bugs y mejor mantenibilidad a futuro, consideramos que vale la pena. Ahora, por alguna razón, a mucha gente con símbolos de pesos en los ojos les cambió un poco la prioridad, y ya parece que la calidad importa menos que la velocidad. Siempre hubo gente así, se llaman “jefes”. Lo que no entiendo es por qué hay tanto programador cayendo en la misma. Se supone que sabemos lo suficiente para no caer en esa.

Claude no es divertido

También hay otro tema, más personal, y es que Claude no es divertido. Si uso grep para buscar texto en un directorio, la parte del trabajo que está agarrando grep es tediosa y aburrida. Grep no sólo me acelera el trabajo, sino que lo hace más divertido, al eliminar partes aburridas. Si uso Claude para algo que no sea buscar texto, la parte que está sacando es la de entender el problema y resolver el puzzle. O sea, lo que hace que sea divertido programar.

En un contexto laboral, eso no importa tanto. Al final, no me pagan por divertirme, lamentablemente, sino por producir código (que igual creo que Claude no ayuda lo suficiente como para justificar el costo, tanto monetario como su efecto en la sociedad en general). En el trabajo siempre te van a clavar con herramientas horribles por una u otra razón (mencionaba más arriba ClearCase, porque tengo experiencia con esa basura). Pero en mis proyectos personales, no me imagino usando Claude. Fuera del trabajo, quiero programar porque es divertido. Claude no es divertido.

Al momento de escribir esto, posiblemente pase un tiempo hasta que lo termine y lo publique. ↩︎
“Skills” es el nombre que Claude le da a una serie de archivos Markdown que le dicen cómo hacer ciertas cosas adentro de un proyecto. ↩︎
Ok, claramente hay gente que no lo sabe, y siguen insistiendo que los LLM son inteligentes. Pero me refiero a personas que no estén todas tomadas por la ideología de los LLMs. ↩︎