Claude Code: tengo Opiniones

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 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.

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.