Enable javascript in your browser for better experience. Need to know to enable it? Go here.

Claude Code nos ahorró el 97 % del trabajo — luego falló por completo

Experimentando con Claude Code en CodeConcise

Tl;dr

 

Hemos estado experimentando con Claude Code — un asistente de programación recientemente lanzado por Anthropic — en CodeConcise, una herramienta que construimos en Thoughtworks para comprender codebases legacy.


Agregar soporte para nuevos lenguajes de programación es una parte importante, aunque consume mucho tiempo, del desarrollo de CodeConcise; queríamos ver si podíamos usar Claude Code para ayudar. Normalmente, esto tomaría a un par de developers entre dos y cuatro semanas, pero Claude Code y un SME lo hicieron en solo medio día. Sin embargo, aunque los resultados iniciales fueron impresionantes, no siempre funciona, como verás…

¿Qué es Claude Code?

 

Claude Code es un asistente de programación con inteligencia artificial desarrollado por Anthropic y lanzado el 24 de febrero de 2025. Es un ejemplo de lo que se describe como un “supervised coding agent”. Estas son herramientas que pueden realizar tareas relativamente sofisticadas dentro de flujos de trabajo de desarrollo de software, a veces de forma autónoma.

 

La mayoría de los supervised coding agents más conocidos actualmente están integrados a flujos de trabajo mediante un IDE: incluyen Cursor, Cline, Windsurf. (GitHub Copilot actualmente tiene workflows agentic en vista previa, pero es probable que esta funcionalidad esté ampliamente disponible pronto). Claude Code se diferencia porque es una interfaz basada en terminal (herramientas agentic open source como Aider y Goose también funcionan en terminal en lugar de un IDE). Trabajar desde la terminal facilita integrar agentes en un ecosistema más amplio que si estás limitado a un IDE.

 

Comparando Claude Code con otros supervised coding agents

 

Dado el ritmo de cambio acelerado en este campo, es importante advertir que cualquier comparación entre herramientas se vuelve obsoleta rápidamente — tal vez en semanas. Sin embargo, hay algunos puntos que vale la pena destacar:

 

  • Claude Code es similar a Cline y Aider en que requiere una API key para conectarse a un LLM. Lo más probable es que accedas a uno de los modelos de la serie Claude-Sonnet, ya que actualmente son los más efectivos para programación. En cambio, Cursor, Windsurf y GitHub Copilot son productos por suscripción.
  • Claude, al igual que Cline y Goose, puede integrarse con Model Context Protocol (MCP), un estándar abierto para conectar LLMs con fuentes de datos.

 

El rendimiento y la utilidad de Claude en esta etapa dependen de qué tan bien puede orquestar el contexto del código, generar prompts al modelo e integrarse con otros proveedores de contexto.

  Interface LLM connection

Claude Code

Terminal

API key / pay what you use

Aider

Terminal

API key / pay what you use

Goose

Terminal

API key / pay what you use

Cursor

IDE

Monthly subscription (with some limits), or pay what you use with API key

Cline

IDE

API key / pay what you use

Windsurf

IDE

Monthly subscription (with some limits)

¿Por qué nos interesaba Claude Code?

 

Nos interesa la programación asistida por IA y los agentes AI; naturalmente, el lanzamiento de Claude Code llamó nuestra atención.

Aunque hay una gran variedad de posibles usos, específicamente queríamos ver si Claude Code podía ayudarnos con un reto particular que hemos enfrentado en el desarrollo de nuestra herramienta de descubrimiento de código con Generative AI, CodeConcise: agregar soporte para nuevos lenguajes.

 

Hasta ahora, solo hemos agregado soporte cuando ha sido estrictamente necesario. Sin embargo, teníamos la hipótesis de que ampliar el soporte para la mayoría de lenguajes desde el inicio podría mejorar significativamente la efectividad de CodeConcise. Esto no solo por una cuestión técnica: si invertimos menos tiempo en construir soporte para un lenguaje, podemos dedicar más tiempo a otras tareas que agreguen valor.

 

Construir ese soporte no es simple — pensamos que Claude Code podría ayudar. Como el experimento coincidió con su lanzamiento, lo probamos de inmediato...

 

Algo de contexto técnico sobre CodeConcise

 

Para entender cómo estábamos experimentando con Claude Code, vale la pena explicar cómo funciona CodeConcise. CodeConcise utiliza abstract syntax trees (AST) no solo para descomponer codebases y extraer su estructura, sino también para navegar por esas codebases cuando un LLM se usa para resumirlas y explicarlas.

 

Más específicamente, CodeConcise requiere implementaciones concretas, específicas por lenguaje, de una clase abstracta conocida en el código como IngestionTool. Esta implementación está diseñada para devolver una lista de nodes y edges extraídos del código, los cuales pueden poblar el knowledge graph. Hasta ahora, nuestras propias implementaciones utilizan ASTs para lograrlo. Luego, realizamos recorridos agnósticos al lenguaje sobre esta estructura, que se enriquecen con la información extraída (usando un LLM) del código. Este knowledge graph es luego utilizado por la app que, con un agent y GraphRAG, brinda insights del código a los usuarios.

 

Aunque los LLMs pueden ser herramientas muy poderosas para analizar una codebase, una desventaja es que cada vez que queremos soportar un nuevo lenguaje — y extraer partes relevantes de su AST — debemos escribir nuevo código para producir e interpretar ese árbol. Esto toma tiempo; típicamente entre dos y cuatro semanas. Necesitamos encontrar ejemplos relevantes, construir un set de tests automáticos y luego realizar los cambios en el codebase. Esa es la razón principal por la que solo lo hacemos cuando es necesario.

¿Qué ha funcionado bien con Claude Code hasta ahora?

 

Éxito: pedirle a Claude Code que identifique los cambios necesarios

 

Primero, le pedimos a Claude Code orientación sobre los cambios necesarios para agregar soporte para Python en CodeConcise. Esta pregunta puede parecer sencilla para un developer con semanas trabajando en el codebase, pero es muy valiosa si eres nuevo en él.

Teniendo acceso al código y la documentación junto a este, Claude Code produjo resultados sorprendentes. Identificó con precisión todos los cambios necesarios para soportar Python. Además, el código sugerido al final demuestra que el agent no solo inspeccionó otras herramientas de ingestion que habíamos desarrollado, sino que también consideró los patrones usados para implementarlas en el nuevo código.

Éxito limitado: pedirle a Claude Code que implemente los cambios

 

Nuestra segunda instrucción fue que Claude Code implementara directamente los cambios sugeridos:

 

Necesito crear una nueva herramienta para cargar código Python en CodeConcise. Por favor, hazlo y pruébalo.

 

Tardó un poco más de tres minutos de trabajo autónomo. Todos los cambios se implementaron localmente, incluidos los tests. Todos los tests pasaron, pero al usar CodeConcise para cargar su propio código fuente en el knowledge graph y correr nuestros end to end tests, identificamos algunos problemas:

 

  1. La estructura del filesystem no era parte del graph.
  2. Los edges que conectaban nodes no seguían el modelo que tenemos en CodeConcise. Por ejemplo, faltaban dependencias de llamadas (otras partes como la comprehension pipeline no podrían recorrerlo como esperábamos).

La importancia del feedback en la programación asistida por IA

 

Este experimento es un buen recordatorio de lo importante que es tener múltiples ciclos de retroalimentación cuando se usan IAs para escribir código. Si no tuviéramos tests para validar la integración, no habríamos descubierto estos problemas hasta mucho después. Eso habría sido tanto costoso como disruptivo; tanto el developer como el agent habrían perdido el contexto del trabajo.

Después de dar este feedback a Claude Code, esperamos unos segundos para ver el código actualizado. A primera vista, el nuevo código mostraba cuán bien este agent seguía los patrones, como el uso de Observers para crear la estructura del filesystem mientras se analiza el código.

 

Vale la pena notar que para este caso específico, mucho del pensamiento complejo ya había sido hecho por los developers que diseñaron la herramienta. Ya se había decidido separar la lógica central del dominio de los detalles más repetitivos necesarios para soportar el parsing de un nuevo lenguaje. Claude Code solo tuvo que unir esta información y entender — desde el diseño existente — qué debía construirse como específico del lenguaje.

 

¿Qué aprendimos?

 

A pesar de que la solución existente está bien estructurada, normalmente toma entre dos y cuatro semanas para que un par de developers y un SME construyan soporte para un nuevo lenguaje. Tener a un SME trabajando con Claude Code tomó solo unos minutos para producir el código para este caso, y pocas horas para validarlo.

¿Qué no funcionó?

 

Fracaso total: pedirle a Claude Code que agregue soporte para JavaScript

 

Satisfechos con los resultados, intentamos lo mismo para JavaScript:

 

Quiero que agregues una herramienta de ingesta para JavaScript. Ya incluí el analizador léxico y el analizador parserbase. Usa stageobserver como en otros sitios y el patrón visitor para el analizador léxico y el analizador parser, como se hace en el cargador tsql.

 

La primera vez intentó hacerlo usando la gramática ANTLR para JavaScript. No pudimos hacer que funcionara (algo fuera del alcance tanto de Claude Code como de CodeConcise), así que no pudimos verificar si el código era funcional.

 

La segunda vez le pedimos usar treesitter. Nuestra suerte parecía acabarse: comenzó a usar librerías que no existen. Nuevamente, no pudimos verificar el código generado.

 

La tercera y última vez, intentó usar patrones regex para analizar el código.

 

¿Funcionó? No: el código hacía referencia a paquetes internos que ni siquiera existen.

Claude Code evidentemente carece de un mecanismo más fuerte de verificación para el código que produce. Es como si le faltara el feedback que un simple unit test podría ofrecer. Esto no es nuevo; lo hemos observado muchas veces con otros asistentes de programación.

 

Nos preguntamos si tuvimos suerte con el trabajo en Python la primera vez, así que le pedimos hacer lo mismo con C. Los resultados fueron similares, aunque usó matching con expresiones regulares en lugar de un enfoque más confiable basado en AST.

 

¿Qué aprendimos sobre Claude Code y los agentes de codificación?

 

Este experimento abordó un caso de uso muy específico, así que no se deben sacar conclusiones generales. Sin embargo, hay aprendizajes importantes:

 

  1. Los resultados pueden ser muy inconsistentes. Claude Code produjo resultados impresionantes para Python y C, pero muy pobres para JavaScript.

  2. El desempeño de los asistentes de codificación depende de múltiples factores:

    1. Calidad del código. Lo que siempre ha sido importante para los humanos, también lo es para los agents. Cuando trabajan con código limpio, modular y bien documentado, hay mayor probabilidad de que generen buenos resultados.

    2. Ecosistema de librerías. ¿Fue más fácil construir el parser de Python porque Python ya ofrece un módulo estándar para convertir código en ASTs? Creemos que los agents necesitan buenas herramientas para tomar decisiones, pero la calidad del output también depende de si pueden resolver el problema con librerías establecidas.Training data. LLMs, and, by extension, AI agents, are known to produce better code on a programming language for which plenty of data is available as part of its original training dataset. 

    3. Modelos de lenguaje grandes. El rendimiento de los agents depende directamente del modelo subyacente.

    4. El propio agent. Incluye prompt engineering, diseño del workflow y las herramientas disponibles.

    5. Parejas humanas. Cuando humanos y agents trabajan juntos, se obtienen los mejores resultados. Además, los developers con experiencia en agents saben cómo guiarlos para obtener mejores outcomes.

 

Claude Code muestra mucho potencial, y es emocionante ver otro supervised coding agent, especialmente uno que puede usarse en terminal. Claude Code sin duda evolucionará — como el resto del panorama — y esperamos seguir explorando cómo integrarlo al trabajo que hacemos.

 

Agradecimientos especiales a Birgitta Böckeler por su apoyo y guía en nuestros experimentos y en este artículo.

Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.

Trabaja con Thoughtworks para aprovechar mejor la IA en toda tu organización