Seis semanas usando Claude Code
(blog.puzzmo.com)- Desde la adopción de Claude Code, la forma de escribir y mantener código cambió drásticamente a gran escala; se le compara incluso con “la llegada de la fotografía al mundo de la programación”, al permitir implementación rápida y libertad de expresión
- Tareas repetitivas y vistas como “deuda técnica” (migraciones, cambio de frameworks, etc.) ahora pueden hacerse en paralelo rápidamente incluso por una sola persona, con casi nada de carga extra aunque se combinen con el trabajo principal
- Un patrón de desarrollo experimental de “primero probar y después decidir”, donde se puede generar y borrar fácilmente código de pruebas, abstracciones y experimentos, obteniendo productividad e insight en el desarrollo
- El prototipado de juegos, la colaboración y los despliegues experimentales se aceleraron enormemente: un diseñador de juegos puede convertir una idea en ejecución en cuestión de horas, sin escribir código
- En entornos favorables para Claude Code, como monorepos, stacks tecnológicos claros y codebases actualizados, la velocidad y flexibilidad del trabajo real de desarrollo mejoran de forma notable
Introducción: cambios tras adoptar Claude Code
- Tras usar Claude Code durante las últimas 6 semanas, se percibe un cambio importante en la forma de escribir y mantener código
- Da la sensación de haber ganado una "libertad de expresión" al ya no tener que escribir personalmente todo el código
- Con Claude Code, es posible pensar la estructura completa de una sola vez y producir resultados a través de capacidades de revisión y edición
- Así como la aparición de la fotografía redujo el atractivo de dibujar todo a mano, ahora también está cambiando radicalmente la forma de introducir y producir programación
- Aunque el cambio puede generar inquietud, la llegada de herramientas basadas en LLM está provocando un cambio de paradigma en la programación
1. Cómo Claude Code cambió la forma de escribir y mantener código
- Tareas de migración, refactorización y reducción de deuda técnica que antes tomaban semanas o meses, ahora pudieron hacerse en paralelo y completarse en apenas 6 semanas desde la adopción de Claude Code
- Ejemplos: migrar cientos de componentes de React Native a React, reemplazar un sistema de RedwoodJS, migrar de Jest a Vitest, server-side rendering, refactor del sistema de diseño, upgrade a Node 22, etc.
- Side projects o pendientes que antes requerían “apartar tiempo específicamente para resolverlos” ahora pueden hacerse en ratos libres en paralelo con el trabajo principal, con casi nada de carga adicional
- La fórmula tradicional de “la deuda técnica requiere asegurar tiempo → gran inversión de recursos” se rompe, y aparece una inmediatez de “empezar al momento → avanzar → terminar”
2. Una cultura de desarrollo experimental de “probar primero y decidir después”
- Cuando surge una idea, primero se intenta con Claude Code, aprendiendo en el proceso al generar y borrar repetidamente cosas como tests desde etapas tempranas
- Incluso sin una estrategia definida de testing frontend, es posible generar y eliminar al instante distintos enfoques de prueba con Claude Code en cada PR, acumulando experiencia y ayudando a definir la dirección general
- Las dudas sobre ideas o abstracciones también pueden validarse y explorarse rápidamente bajo un modelo de “probar directamente → si falla, no pasa nada”
- Como el costo de fallar baja drásticamente, el ciclo de experimentar-aprender-decidir se acelera de forma importante
3. Cambios en el desarrollo en paralelo y en la colaboración
- Usando dos clones de git/perfiles de VSCode, se realizan trabajos independientes en cada clon (por ejemplo, uno para preparar un PR y otro para desarrollo experimental)
- Mientras Claude Code trabaja en un clon, se puede avanzar en paralelo en el otro, o distinguir claramente cada uno usando temas y puertos distintos
- Esto permite redactar Pull Requests en paralelo, evitar conflictos de puertos en servidores de desarrollo y mejorar la eficiencia de trabajo
4. Innovación en el proceso de prototipos de juegos y desarrollo experimental
- Un proceso que antes tomaba semanas o meses —crear un prototipo de juego → desplegarlo internamente → recibir feedback → publicarlo o descartarlo— cambió con Claude Code: ahora incluso un diseñador puede escribir código y desplegarlo al sitio en pocas horas
- La idea → ejecución → feedback del equipo → cierre del experimento o paso a producción (reescribiéndolo) tiene ahora ciclos de despliegue muchísimo más cortos
- Aun así, esto también trae nuevas preguntas operativas, como cómo gestionar juegos temporales y definir criterios para formalizarlos o desecharlos
5. Uso de Claude Code en la programación cotidiana y la colaboración
- Durante el triage semanal, se pueden crear PRs y hacer experimentos al instante usando la GitHub Action de Claude Code, aplicando de inmediato los issues pequeños
- Los miembros del equipo con capacidad tanto de producto como técnica, y con iniciativa propia, son quienes mejor aprovechan Claude Code: los llamados “full-breadth developers”
- "Full-breadth developers": ayuda a que una sola persona pueda liderar con libertad todo el flujo de trabajo
- Cuando los humanos conservan el rol de revisión de código, provisión de contexto, corrección y toma de decisiones, aumenta la productividad y creatividad de todo el equipo
6. Un entorno de codebase favorable para Claude Code
- Monorepo: al tener en un solo lugar todo el código, el esquema de DB, las APIs y la lógica de pantallas, Claude Code puede entender mejor el contexto y automatizar tareas con más eficacia
- Al adoptar un stack tecnológico estandarizado (React, Relay, GraphQL, TypeScript, StyleX, Bootstrap, etc.), el LLM puede comprenderlo y automatizarlo más fácilmente
- Mantener el codebase actualizado y minimizar el legado maximiza la eficiencia del uso de LLMs
7. Limitaciones de Claude Code y cambios percibidos en la práctica
- Aunque los cambios cuantitativos como el número de PRs o commits no sean tan grandes, la sensación de velocidad, flexibilidad y productividad mejora muchísimo
- Claude Code funciona como un programador en pair programming de nivel “junior experimentado o un poco más”; si el ingeniero gestiona la calidad del código, la lógica y el contexto, se vuelve el mejor compañero posible
- Ofrece una experiencia de trabajo cualitativamente distinta para tareas repetitivas, reducción de deuda técnica y avance rápido de side projects
8. Estrategia de “implementación paralela” recomendada para juniors y aprendices
- No hace falta obsesionarse en exceso con las últimas tendencias del ecosistema LLM
- Para desarrolladores principiantes, se recomienda escribir primero el código por cuenta propia y luego pedirle la misma tarea a Claude Code para comparar y aprender del análisis
- Al revisar la solución de Claude Code, se pueden adquirir rápidamente distintas abstracciones y patrones reales de trabajo
- Usar al LLM como “competidor + mentor” permite crecer al mismo tiempo en capacidad práctica y en sensibilidad hacia el ecosistema actual
- Claude Code es como un teléfono móvil: no hace falta tenerlo siempre encendido
- En última instancia, lo importante es mantener el control y usarlo de forma eficiente
9. Aumento explosivo de side projects y experimentos de corto plazo
- Pequeños experimentos, herramientas y mejoras para el blog que antes eran difíciles por falta de tiempo o energía, ahora pueden realizarse con Claude Code en cuestión de horas
- Idea → implementación inmediata → si falla, no pasa nada: se vuelve mucho más fácil llevar en paralelo experimentos creativos y proyectos personales separados de producción
10. Ejemplos reales de conversaciones con Claude Code y code review
- Se muestran ejemplos concretos del proceso de definir requisitos → generar código → ejecutarlo → corregirlo → revisarlo, como scripts de limpieza de DB, un REPL de rompecabezas o el layout PDF de un crucigrama
- El LLM puede equivocarse (razonamiento, exageraciones, hardcoding, etc.), por lo que el ingeniero debe asumir la validación lógica y la responsabilidad por la calidad para obtener valor real
11. El lugar de Claude Code en ingeniería y conclusión
- Claude Code destaca por su capacidad de aceptar contexto amplio, como código de referencia, screenshots y explicaciones adicionales
- Claude Code es un programador asistente de nivel "post-junior" (junior avanzado o más): con paciencia y velocidad infinitas, resulta muy eficiente como partner de trabajo
- El diseño, la calidad y el control final siguen a cargo del ingeniero humano, mientras que Claude Code expande enormemente el alcance y la velocidad de implementación, experimentación y automatización
- Se hace posible un entorno de desarrollo donde, al dejar atrás la limitación de “tener que programar línea por línea personalmente”, se puede concentrar más energía en diseño, gestión de calidad e innovación
7 comentarios
Yo también estoy muy satisfecho usando Claude Code.
Creo que ya llevo unas 6 semanas usándolo.
Me identifico con la mayor parte del contenido.
https://jeho.page/essay/2025/07/15/claude-code.html
Siento exactamente lo mismo que el autor de la publicación original jaja
Pagué $200 y en una hora resolví un problema dificilísimo que llevaba 4 años.
Probablemente yo solo..., con Cursor, nunca habría podido resolverlo.
¿Podría saber cuál es la diferencia al usar Claude Code frente a Cursor + Claude LLM?
Yo uso Cursor, pero estoy pensando en cambiarme a Claude Code.
¿Cuando dice Claude LLM, se refiere a la API key?
¿O más bien se refiere a los modelos Agent que están debajo de la ventana de chat?
También usé Cursor bastante satisfecho, pero me topaba seguido con los límites de uso, así que incluso pagando el plan de $60 vivía preocupado por si me iba a quedar bloqueado.
Para evitar eso, alternaba con gemini cli y me generaba bastante estrés.
Cursor + Claude 4 sonnet ya era bastante bueno, pero el mayor problema era que al pasar un día me caía el límite, y una vez que te lo aplicaban no podías usarlo durante un mes.
Ni siquiera me animaba a probar Cursor + Claude 4 opus.
Al final, como Claude Code está basado en CLI y no depende de las características del IDE, decidí probarlo.
Al principio usé el plan de $20, pero este tampoco tiene opus.
Así que cuando ya estaba por toparme con el límite, pensé en probarlo solo un mes, pagué $200 y empecé a usarlo,
y se te abre un mundo nuevo. opus... de verdad está en otra liga...
Ahora voy en el día 4 desde que pagué los 200, y ya estoy resolviendo todos esos problemas difíciles que tenía guardados jaja
No se puede editar el texto.
Creo que no era un mes sino un día. Fue algo así. Durante todo el mes estuve con el corazón en un puño.
Y además peleé mucho con Cursor, pero con Claude Code no peleo tanto.
Oh, muchas gracias por la respuesta tan detallada.
Yo también estoy usando Cursor en modo Auto porque llegué al límite y no me quedó de otra, pero supongo que tendré que cambiarme.
Opinión de Hacker News
Tras usar Claude Code unas 2 semanas, aunque normalmente era bastante escéptico con la programación con IA, me sorprendió muchísimo. Para sacarle provecho hay que pasar una pequeña curva de aprendizaje, y es esencial dar buen contexto y dividir bien el trabajo. Obviamente hace falta saber programar; si le tiras todo a la IA sin entenderlo, seguro habrá problemas. Como tengo más de 25 años de experiencia, me siento con la confianza de revisar cualquier resultado que entregue Claude Code y corregirlo en cuanto se equivoque. Hace unos 10~15 años soñaba con algo parecido a una interfaz neuronal donde no hiciera falta escribir código directamente, y siento que Claude Code lo vuelve real hasta cierto punto. A veces me topo con el límite diario de uso y he usado más bien Gemini CLI 2.5 pro como reemplazo, pero no hay comparación posible con Claude Code. Gemini desespera demasiado y no lo puedo usar. Antes jamás habría imaginado pagar más de 100 dólares al mes por una herramienta de desarrollo, pero estoy considerando muy seriamente subir al plan Max.
Si un desarrollador senior puede aconsejar y guiar a un desarrollador junior, creo que esta herramienta encaja muy bien en ese contexto. Por lo que escucho de otros desarrolladores senior, muchos se quejan de que los juniors generan con LLM código todavía más raro, más lento, inseguro o directamente desastroso, y luego lo suben a un PR sin entenderlo. Lo que más me sirve a mí es generar boilerplate (si le das una descripción, hasta te arma el diseño de clases), convertir JSON a clases u otros formatos, y hacer preguntas como “¿qué problema tiene este código? ¿Cómo lo cambiaría un ingeniero nivel Staff?”. De hecho, también me ha encontrado bugs por adelantado en código que escribí yo mismo.
Lo interesante es que la gente escéptica con el “vibe coding” suele tener expectativas bajísimas antes de usar realmente la herramienta. Muchos piensan que el código que generan los LLM va a ser basura y toman ejemplos extremos como si fueran el promedio. Pero cuando lo prueban por sí mismos, terminan sorprendidos de lo bueno que es, más de lo que esperaban. Claro, no puedes levantar de la nada un SaaS valuado en mil millones de dólares con un equipo de 10 personas usando Claude Code, pero aun así hay mucha gente que subestima el poder real de la herramienta.
Estrictamente hablando, en realidad tú no estás haciendo vibe coding. Se parece más a ingeniería de software asistida por IA. El vibe coding significa aceptar sin más cualquier código que la IA produzca y seguir avanzando sin entenderlo. Como cada quien define el término distinto, mejor no confiar demasiado en esa etiqueta.
Yo tampoco pagaba más de 20 dólares por ningún servicio de suscripción hasta hace apenas unos meses, y ahora estoy pagando 200 dólares al mes por el plan Max 20. También me sorprende, quizá porque soy desarrollador con 20 años de experiencia, eslovaco viviendo en EE. UU. He probado otras herramientas, pero siempre fue difícil sentir de forma tan directa este nivel de productividad y eficiencia. Claude Code de verdad está en otra liga. Claro, todavía hay que supervisarlo en detalle, pero mi flujo es armar bien los requisitos y el plan de cambios en el código con Plan Mode; cuando estoy 100% de acuerdo, lo ejecuto y luego reviso el resultado. (Errores del compilador, pruebas unitarias y problemas de lint los corrige la IA por su cuenta). Se siente como tener a un ingeniero junior rapidísimo, un poco raro pero con mucho conocimiento. El desarrollo de software claramente va para este lado, y este es el futuro.
Últimamente he sentido que los modelos de Claude son poco confiables al escribir o modificar SQL. Por ejemplo, arma bien las condiciones, pero no agrupa AND/OR con paréntesis, y Gemini pro sí me detectó correctamente eso como bug.
Coincido totalmente en que Claude Code va claramente por delante de todas las herramientas competidoras. Desde 2023 he venido construyendo mis propias herramientas CLI para generación de código con IA y podría decir que he probado casi todas las opciones importantes. Me identifico mucho con varios de los métodos del autor:
docs/external-deps).Sobre el segundo punto (empezar con una buena especificación), me da curiosidad cómo organizas la especificación en concreto. Si la separas en un documento Markdown, qué tanto detalle hace falta, etc. También coincido con el consejo de “tener pruebas desde el inicio”, pero en la práctica, cuando Claude detecta hooks de testing, a veces se salta el proceso de crear primero los tests y solo repite cambios sin validar bugs ni supuestos. Incluso he llegado a usar flags para activar o desactivar ciertos comportamientos relacionados con pruebas.
El monorepo te ahorra tiempo, pero las llamadas a herramientas y el consumo de tokens de Claude aumentan muchísimo. Me parece mejor el enfoque tipo Aider, donde solo seleccionas los archivos necesarios y se los pasas a la IA. No entiendo muy bien por qué Claude es tan popular. Aider es mejor en casi todo y además te deja integrar distintos LLM.
Para usar bien CC, el proyecto tiene que estar bien estructurado. En un proyecto Django con pruebas, tipos y documentación bien puestos, CC me resolvía casi todo, aunque necesitaba guía de vez en cuando. Últimamente también estoy haciendo un side project para correr CC offline con un modelo local. La primera versión la construí bien con ayuda de ChatGPT, pero al pasarme a CC, CC más bien se puso a dar vueltas alrededor de los problemas clave, evitando errores y, en vez de refactorizar el código existente o arreglar bugs, tenía la costumbre de crear archivos o scripts nuevos todo el tiempo.
Me da curiosidad si formateas directamente la documentación externa dentro del proyecto. La mayoría de los proyectos solo tienen documentación en un sitio web, así que quisiera saber si realmente te tomas el tiempo de crear archivos Markdown limpios por separado.
El verdadero poder de Claude Code no está solo en programar, sino en que puede controlar toda la computadora. Si existe una herramienta CLI, Claude puede usarla; y si no existe, igual muchas veces te sorprende lo que logra si se lo pides. Por ejemplo, le he encargado tareas varias como recortar o redimensionar imágenes, extraer mp3 de videos de YouTube o eliminar silencios de archivos de audio. Me ha ahorrado una cantidad enorme de tiempo. Ya ni me acuerdo de cómo era antes; siento que no podría volver a trabajar como antes.
En vez de conectar Claude a tu computadora real, es mejor darle una máquina separada (y no siempre tu equipo personal). En mi caso, el IDE corre en una VM en la nube, conecto Claude ahí y entro desde el navegador (https://brilliant.mplode.dev). Creo que esta es la UX óptima más cercana a operar agentes de verdad. No hace falta preparar terminal ni ssh; solo inicias sesión y la instancia se crea o se pausa automáticamente. En la práctica, es como abrir directamente Claude + una instancia personal de Linux + un IDE desde un simple enlace. Más adelante quiero poder levantar varias instancias como quiera y controlar con detalle permisos, sistema de archivos y permisos de contenedores (JWT, etc.). Si surge una falla o algo que revisar, entro directo al IDE y lo resuelvo. Ni siquiera hace falta una UI aparte; puedes verlo en varios paneles dentro del IDE o levantar la webapp directamente en el contenedor y usarla ahí mismo. Hace mucho que no me emocionaba tanto con el avance de la tecnología.
Aunque todo se vea bien, si miras solo el output real de código, los datos muestran muy poca diferencia entre antes y después. Incluso trabajando con Claude, mis commits, PR y líneas de código no cambian tanto como antes. O sea, la programación con IA te da la sensación de “soy más productivo” y de “qué bien se siente crear algo sin tocarlo mucho”, pero en realidad exige mucho review, corrección y re-prompts, y al final el volumen total de output es parecido. Además, al delegarle lo difícil a la IA, tu propia capacidad de diseño y razonamiento se va debilitando. Si pasas un mes usando solo Claude y otros LLM y luego intentas hacer una app pequeña por tu cuenta, no solo el código sino hasta el diseño general de la estructura se siente más difícil. A largo plazo existe el riesgo de que el codebase se deteriore lentamente y termine siendo un saldo negativo (al menos con la generación actual de LLM).
Antes uno armaba a mano comandos de ImageMagick como
mogrify, uno por uno, al estilo antiguo. Con apoyo de herramientas de IA el ahorro de tiempo ha sido una locura.Le pedí a Claude que diagnosticara por qué mi PC Linux se estaba cayendo constantemente; revisó logs con
journalctl, encontró la causa y me ayudó muchísimo. Fue una experiencia donde sí me ayudó directamente a resolver el problema.Otro caso es que generar sitios estáticos se volvió facilísimo. Puedo escribir un texto en cualquier sintaxis y pedirle a Claude Code que lo convierta al formato de mi blog, y lo hace solo. Por ejemplo, si escribo “mete la imagen
image.jpeg”, lo resuelve de inmediato. Es muy cómodo no tener que preocuparse por Markdown o por el formato de Hugo.Como alguien que ha usado Claude code entre 12 y 16 horas al día, encontré los siguientes tips:
El punto 5 también se puede extender más allá de Docker si lo conectas con un servidor MCP de playwright, para que también revise de inmediato la UI y las requests. 6. Empezar con plan mode e iterar hasta que te guste el plan. 7. Aprovechar mucho los slash commands (
/comando) como mini-prompts para mejora continua, aportar contexto e incluso indicarle que use herramientas externas comogh. El compacting no conviene hacerlo de golpe en 0%; es mejor aplicarlo en un punto intermedio adecuado. Puede que no todos estén de acuerdo con el punto 1 (recomendar sonnet).Aunque tiendo a evitar Docker, me dio mucha curiosidad el tip 5 (usar Claude para orquestación de Docker). Quisiera saber qué formato de prompt usas.
También me ha funcionado crear primero un archivo
plan.mdmuy detallado (con conexiones entre sistemas, arquitectura completa, etc.) y dejarlo corriendo toda la noche con herramientas como claude-loop(https://github.com/DeprecatedLuke/claude-loop), para luego hacer patches manuales por la mañana.Me da curiosidad cómo usa alguien Claude Code 16 horas al día.
A veces Claude mete demasiado mano dentro del contenedor. Solo quería que entendiera el código, pero terminaba ejecutándolo de mil maneras dentro del contenedor y a veces lo dejaba peor. Antes incluso hacía cosas como pasar archivos por tuberías de comandos CLI sin que eso produjera ningún efecto; es un ejemplo de esa tendencia medio obsesiva a ejecutar cosas.
No sé realmente qué tan bueno sea Claude Code (no lo he usado personalmente), pero sí tengo un conflicto personal. Quiero refactorizar a C# un proyecto personal hecho en gdscript (tipo Python), muy lento y desordenado. Quiero dejarlo más limpio y rápido. Para mí este trabajo es un reto nuevo y tiene bastante valor educativo. Si uso Claude siento que me estoy quitando una oportunidad valiosa de aprender (y a largo plazo creo que también me ayudaría a crecer), pero si no lo uso siento que estoy gastando tiempo valioso en una tarea tediosa que en realidad se va a automatizar de todos modos. Vivo atrapado en ese dilema.
En 35 años de carrera como desarrollador, con cualquier LLM hago esto: solo se lo delego a la IA cuando yo mismo podría resolverlo, pero no quiero hacerlo porque es aburrido o repetitivo. Por ejemplo, corregir un esquema Open API 3.0 no me iba a enseñar nada si lo hacía a mano, así que se lo dejé a Claude; también le pido que genere código de ejemplo. Cuando sí hay algo realmente nuevo por aprender, lo convierto en flashcards en apps como Anki SRS o lo apunto en un blog de TIL. O también implemento yo mismo varios ejemplos para convertirlo en experiencia real. La clave es conectar ese nuevo aprendizaje en el cerebro al menos dos veces para que el aprendizaje sea efectivo. Es como aprender una palabra nueva en lenguaje natural y usarla integrada en tres oraciones.
Si no revisas tú mismo el código generado (o sea, si no aprendes suficientemente C#), el codebase se arruina rapidísimo. El coding con LLM tiende a acumular errores, así que eso sí o sí tiene que mejorar; si no, termina convertido en basura imposible de mantener. Amigos míos dicen que hacen que la IA genere suficientes tests para detectar los problemas pronto, pero yo todavía no he logrado usar ese método. Como mi código está más orientado a lógica que a algoritmos, escribir tests también me resulta ambiguo.
Llevo 16 años trabajando como desarrollador profesional, y siento que Claude Code me ha ayudado a resolver mucho más fácilmente cosas donde antes me quedaba atorado dándome de cabeza contra la pared. Para aprender cosas nuevas rápido, las herramientas de IA (en especial el modo “ask” de preguntas y respuestas) son efectivas; uso mucho analogías, casos y mnemotecnia. Si tu objetivo es un aprendizaje profundo mediante un crecimiento lento, entonces sigue siendo mejor el método clásico, aunque sea más tardado. Pero si tu objetivo es aprender rápido, aprovechar la IA tampoco está mal. Si lo que quieres es simplemente sacar resultados, entonces es importante escribir bien las especificaciones y tener suficientes tests. Al final, sea cual sea el método, creo que lo importante es seguir construyendo cosas.
Antes hubo una tendencia en blogs de decir “crea tu propia librería x”. Es en el proceso de implementar algo tú mismo donde más aprendes. Por ejemplo, si quieres entender un router del lado cliente, lo mejor es construir uno tú mismo. En la era de los LLM, cualquier cosa puede terminar reemplazada por código de librería, pero si de verdad quiero aprender C#, lo mejor sería hacer yo mismo el port. Si solo necesito el resultado y quiero concentrarme en otra cosa, entonces puedo dejarlo en manos de Claude. Aprender necesariamente trae una etapa de dolor; si todo es demasiado fácil, en realidad no estás aprendiendo nada.
Antes de la IA, lo que mandaba era copiar y pegar. Los amigos que se robaban código de Stackoverflow sin entender por qué al final no aprendían nada. Pedirle consejo a la IA o explicaciones conceptuales me parece totalmente válido. Pero si le pides que te escriba todo, claramente no hay aprendizaje. Aun así, también es sensato cuidar tu tiempo como desarrollador. Hay demasiadas cosas que aprender, así que si tu meta es hacer videojuegos, puede que portar GDscript no sea una experiencia imprescindible. Claro que sí se aprende algo, de todos modos.
Tras unas 3 semanas programando con Claude Code, trabajo desde hace 10 años principalmente con Python ML e ingeniería de datos. Hay varias razones:
Quitar el dolor de arrancar de verdad pesa muchísimo. Antes había cosas que pensaba “haría esto si tuviera tiempo”, y ahora basta con unos cuantos prompts para ponerlas en marcha. De hecho, quería hacer una versión en terminal del juego NYT Connections, y quedó lista en 3 prompts (https://github.com/jleclanche/connections-tui).
El punto 4 me llamó especialmente la atención. Antes era normal dejar pendiente una prueba o deuda técnica, pero ahora basta con decir “hace falta” para que te genere automáticamente un test suite bastante decente. No es perfecto, pero sí permite ir atendiendo con más facilidad tareas de dificultad intermedia.
Como parte de esa pequeña minoría curiosa que sigue intentando programar con agentes, he estado pensando por qué mi experiencia es tan distinta a la visión dominante. Creo que la clave está en esta frase:
Me gustaría preguntar si de verdad sigue existiendo un entorno donde la gente pinta y paga por pintura. Muchas formas de trabajo artesanal fueron desplazadas por procesos ensamblados y de producción masiva; ahora parece que el valor no está tanto en el producto mismo como en la experiencia compartida entre productor y consumidor a través de la imaginación. Ya no se trata solo de pedir algo por Amazon, sino de consumir también la relación con el artesano y la narrativa del proceso creativo. Creo que para sobrevivir, la programación también va a tener que ir por ese lado.
Entiendo demasiado bien esa postura. Reconozco la utilidad de la programación con agentes para tareas pequeñas, corrección de bugs y borradores. Lo que no entiendo es por qué se volvió tan intensa la pelea a favor o en contra de distintas interfaces que envuelven a unos pocos modelos. También sigo pensando mucho en el impacto para los junior devs. Si la IA pudiera automatizar también el code review, mi vida sería todavía más feliz.
No creo que esa analogía sea completamente válida. Históricamente, la pintura era el único medio para reproducir el mundo real, pero el arte no es simple copia; es interpretación del creador. Por eso la gente sigue pintando. Si piensas la programación misma como arte, puedes seguir haciéndola. Pero para mucha gente el objetivo es desarrollar un producto, y ese producto también puede ser arte. Si con IA puedes llegar a esa meta más rápido, entonces parecería natural elegir la IA. A la vez, también extraño un poco la época del “code monkey”, cuando uno solo programaba. Siento que se acerca un escenario donde todos actuarán más como lead developers, tomando dirección, haciendo code review y decisiones técnicas. Da un poco de nostalgia pensar que en el trabajo diario se tocará menos código directamente.
Una analogía más apropiada sería el paso de herramientas manuales (
hand-tool) a herramientas eléctricas (power-tool). La comparación pintura-fotografía parece exagerada porque aquello sí fue la aparición de un medio completamente nuevo. La programación con agentes no es tan revolucionaria como eso.He intentado usar bastante Claude Code, pero me desespera porque es demasiado lento y siempre parece irse un poco fuera de lugar. En la mayoría de las tareas no siento que me ahorre energía mental. En algunas sí me ayudó, pero también me ha traicionado demasiadas veces como para querer usarlo seguido. Por ejemplo, le pedí que me convirtiera un
.zshrca nushell y después de pelear 30 minutos seguía sin funcionar; revisar la documentación oficial por mi cuenta me habría tomado menos de 10 minutos. Por experiencias decepcionantes como esa, me cuesta mucho querer volver a usar Claude.Mi experiencia se parece mucho a esta. Quise usarlo para ayudar con tests, pero terminaba reescribiéndolos todos yo mismo. En debugging nunca vi resultados reales. Solo me ha servido para conversiones muy simples de scripts (como parsear salida de comandos) o para scaffoldings de proyectos nuevos (aunque, ¿qué tan seguido haces eso?). Para ports de código sencillos estuvo bien, pero he tenido muchos más fracasos que éxitos.
Me gustaría saber si has probado algo como context7 MCP. Los LLM suelen ser débiles en lenguajes menos populares o dominios poco familiares. Me da la impresión de que un enfoque como context7, que trae referencias directamente desde fuentes actualizadas, funciona mejor.
Por RSI y síndrome del túnel carpiano había estado programando menos, pero gracias a Claude ahora puedo volver a programar (el dolor se redujo a una décima parte). Es una tecnología que más bien quería rechazar, pero si quiero seguir con mi carrera, ahora siento que la necesito sí o sí.
He escuchado muchas historias parecidas. Para la gente con RSI, herramientas como Claude son un verdadero game changer. Hacen muchísimo más llevadero el trabajo repetitivo más pesado y aburrido, como el boilerplate. Antes, con solo ver código repetitivo me dolían tanto la muñeca como la mente; ahora ya no tengo que pensar en eso y puedo concentrarme más en problemas abstractos o nuevos, así que programar se volvió más disfrutable. Existe la preocupación de que “estas herramientas pueden acabar con mi carrera”, pero yo más bien creo que la van a salvar.
Desde que empecé a usar Claude, el dolor por RSI casi desapareció. En especial porque puedes sustituir trabajo repetitivo por instrucciones y frases muy precisas. También he oído muchos casos de uso con reconocimiento de voz, y siento que esto abre una puerta enorme en accesibilidad.
Pienso que sería todavía más útil si se pudiera usar Claude Code directamente por voz. En MacOS hay opciones gratuitas de TTS/ASR, y también puedes conectar otros motores de voz con BYOK (https://github.com/robdmac/talkito).
Si usas una app de STT/reconocimiento de voz suficientemente precisa y cómoda, también resulta efectivo para transmitirle a Claude Code contexto detallado. Tras probar varias apps de voz, la que mejor me ha funcionado es Wispr Flow, porque combina exactitud, velocidad y un modo manos libres basado en atajos de teclado. Eso sí, me gustaría que también soportara apps locales.
Me da curiosidad si tú haces incluso la entrada de texto por voz.
Desde la perspectiva de mantenimiento, coincido mucho con el autor. Antes había tareas para las que solo creaba TODOs o tickets de refactorización/recordatorio, pero ahora gracias a Claude las implemento de una vez. Eso reduce muchísimo el esfuerzo repetitivo. También es fácil probar rápido ideas de refactorización y descartarlas si no convencen. La energía de activación necesaria para este tipo de tareas bajó drásticamente. Estoy de acuerdo en que si te pones a lanzar agentes de IA en paralelo y offline sin control, puedes terminar más bien en burnout y deterioro de calidad del código, así que hay que mantener sí o sí un modo de supervisión humana. También escribí una nota adicional al respecto en https://www.modulecollective.com/posts/agent-assisted-coding...