- Usé Cursor y Claude Code en paralelo y acumulé experiencia real en tareas de desarrollo sobre grandes bases de código, además de consultoría de evaluación de LLM y otros trabajos diversos
- Cursor se volvió muy popular entre los power users gracias a su UI/UX conveniente y al acceso ilimitado a la API, pero recientemente la introducción de límites de tasa muy estrictos restringió drásticamente la experiencia de uso
- Sonnet 4 en Claude Code muestra alta confiabilidad y eficiencia en comprensión y edición de código, así como en el manejo de contexto a gran escala, y usándolo en conjunto con Opus 4 también es posible resolver bugs de alta dificultad
- Hay muchas funciones avanzadas ocultas para power users, como el entorno CLI basado en comandos y el uso de subagentes, y la experimentación constante junto con la exploración de funciones son una parte importante de la experiencia
- Entre los puntos débiles están la falta de una UI visual, la lentitud al copiar/pegar, las limitaciones para usar otros modelos y la necesidad de mejoras adicionales como checkpoints
De Cursor a Claude Code: el trasfondo del cambio
- Hasta hace poco, Cursor era muy apreciado por los desarrolladores gracias a su uso ilimitado de API y su flujo de trabajo intuitivo de revisión de diffs
- Por eso lo usaba principalmente para generar código en Gumroad bounties y trabajos de consultoría relacionados con ingeniería de IA y evaluación de LLM, además de comprender bases de código rápidamente
- Sin embargo, desde mediados de junio se introdujeron de forma repentina límites de tasa muy agresivos, lo que redujo de forma drástica la eficiencia del trabajo y disminuyó mucho las ventajas de usar Cursor
- Entre varios modelos como Sonnet 4, Opus 4, GPT-4.1 y Gemini Pro 2.5, en la práctica los que más usé fueron Sonnet 4 y Opus 4
- Debido a limitaciones como el costo de la API y la caída en velocidad, incluso consideré una suscripción Claude Code Max (200 dólares al mes) para hacer una transición en serio
Experiencia real usando Claude Code
- Puse Claude Code a trabajar sobre bases de código open source medianas y grandes en Python, Ruby y TypeScript (50M+ tokens), y experimenté un ciclo de retroalimentación con especificaciones y pruebas
- Al principio solo usaba entradas de texto simples, pero luego aprendí los comandos básicos y el modo plan y empecé a explorar formas de uso más profundas
- Entrada simple de comandos → aprender comandos y modo de planificación → lograr automatización y mayor productividad con combinaciones claras de comandos
- Usé una estrategia mixta en la que planteaba el proceso de resolución de problemas casi como si fuera una consulta, volcando todo el contexto en Claude libremente; cuando era necesario cambiaba a Opus para planificar (Plan mode) y usaba Sonnet 4 para las tareas principales
- Le pedí a Claude que registrara y organizara información mediante archivos dentro de la carpeta
.claude, para así gestionar el contexto y aliviar la incomodidad de copiar/pegar; recomiendo combinar Plan mode y Auto-edit mode
- Gestión de contexto: en vez de usar compaction, prefiero iniciar chats nuevos de forma periódica y hacer que anote los cambios importantes en archivos separados
Gestión de contexto y uso de subagentes
- Claude Code soporta compresión de contexto, pero como es lenta y poco eficiente, prefiero crear archivos con los puntos clave e iniciar un chat nuevo
- Hago que registre cambios, notas e historial en archivos auxiliares como Scratchpad, para luego aprovecharlos en trabajo con ramas (branch) o al recuperar sesiones con
/resume
- Subagentes: permiten procesar en paralelo varias tareas dentro de la base de código, como búsquedas y análisis, distribuyendo el trabajo con una estructura multihilo
- Internamente se genera un sistema multiagente basado en listas ToDo que ayuda con la gestión del contexto
Búsqueda y uso de comandos
- En Cursor se pueden usar varias herramientas, como búsqueda normal/semántica y agentic search, y además la velocidad de búsqueda es alta
- Pero la búsqueda en Claude Code puede ser lenta. Al usar sub-agents, se puede procesar en paralelo dentro de grandes bases de código
- Con sub-agent, la task tool y comandos como
/think y /ultrathink, es posible explorar grandes repositorios y repartir el trabajo
- Es importante revisar la lista de comandos con el atajo
Shift + ? para descubrir rápido funciones nuevas
- Los comandos de terminal (bash) se pueden ejecutar con
!, también en modo headless
- También incluye muchas funciones avanzadas, como etiquetas de archivo (@archivo), la función memorize (system prompt personalizado por usuario) y el uso de
CLAUDE.md
Comparación Sonnet 4 vs Opus 4 y consejos de flujo de trabajo
- Sonnet 4: en la mayoría de situaciones es más rápido y destaca en contexto largo más trabajo con agentes. Tiene ventaja en Python y tareas de frontend
- Opus 4: cuando se acumulan muchas instrucciones tiende a confundirse; en esos casos conviene registrarlas en archivos y empezar un chat nuevo. Lo uso para resolver bugs complejos cuando Sonnet 4 se atasca
- Para problemas complejos, recomiendo un enfoque híbrido: empezar con Opus y dejar la programación general para Sonnet
Comandos personalizados y otros tips
- Soporta comandos personalizados como
/pr-comments y /review; requiere Github CLI
- Se puede armar un flujo de trabajo flexible reiniciando la conversación al cambiar de rama y revisando el diff contra main
- Con
Esc dos veces se puede hacer un fork de la conversación desde cualquier punto
- Con
/permissions se pueden ajustar permisos antes de la sesión
- Si te animas, prueba
claude --dangerously-skip-permissions
- Recomendación del video Cluade Code Pro TIPS
Cosas que quiero probar en el futuro
- Quiero experimentar con cómo definir y usar comandos personalizados por mi cuenta
- Quiero intentar automatización de desarrollo frontend usando servidores MCP, como Playwright server
- Planeo enfocarme en construir un feedback loop donde Claude tome screenshots, reconozca los resultados y mejore iterativamente la UI
- Planeo poner en práctica todas las técnicas avanzadas propuestas en how-i-bring-the-best-out-of-claude-code-part-2
- También pienso desafiarme con la optimización de prompts
- Quiero definir con claridad los criterios de evaluación (
rubric.md) y diseñar un loop para evaluar y mejorar prompts junto con archivos que contengan contexto (como pmd)
- Planeo evolucionarlo hacia una estructura donde varias instancias de Claude trabajen juntas: una genera resultados a partir de un prompt y otra los evalúa, da feedback y ayuda a mejorarlos, ya sea como sistema de uno o varios agentes
- Este enfoque está inspirado en un post de Nirant
- Quiero construir un sistema multiagente en el que varias instancias de Claude Code se comuniquen entre sí mediante action logs
Conclusión y solicitudes de mejora
- Cursor tiene una fortaleza enorme en UI/UX, pero Claude Code impulsa la productividad y el espíritu experimental en un entorno amigable para power users y para la CLI
- Es una herramienta donde aprender explorando y experimentar da grandes recompensas, muy recomendable para nerds y power users
Funciones que me gustaría que mejoraran
- Integración de UI (Claudia como referencia)
- Soporte de checkpoints como en Cursor. Git existe, pero la forma en que lo hace Cursor es demasiado cómoda
- Mejorar la calidad de copiar/pegar
- Soporte para usar distintos modelos
1 comentarios
Opinión de Hacker News
Cada vez que veo a la gente deshaciéndose en elogios sobre Claude Code, no puedo evitar sentir que o son puros influencers o fans que se emocionan con herramientas tradicionales como la terminal, Emacs y Vim. Siempre que veo comentarios diciendo que Claude Code es muchísimo mejor que Cursor, termino suscribiéndome y probándolo en codebases grandes de TypeScript, pero el proceso toma mucho tiempo y la curva de aprendizaje es alta. Al final, el resultado es igual al Claude integrado en Cursor, pero más lento y menos claro, así que hasta revisar el código se vuelve difícil. A estas alturas, siento que todos los superfans de los comentarios o están patrocinados o ya pagaron 200 dólares y ahora necesitan justificar su decisión. Sinceramente, Cursor me ha dado mucha más productividad. Llevo 18 años programando y escribo mucho código todos los días, alternando entre Gemini 2.5 Pro y Claude 4.0, y aun así saco más provecho con Cursor. Hasta ahora nadie ha logrado convencerme. No veo una ventaja real. Tal vez luego cambie de opinión, pero por ahora no la siento para nada
Creo que la mayoría entiende mal, y de forma profunda, cuál es la parte realmente difícil del desarrollo de software. La mayor parte del trabajo real no es crear algoritmos complejos, sino ensamblar bien ideas existentes y hacer que encajen. Pero todo eso viene después del trabajo previo: especificaciones, diseño, arquitectura, etc. Construir rápido este tipo de programas con IA se ve impresionante y en demos parece que “ya quedó”, pero el problema real es hacer sistemas que deban durar 30 años y cumplan estándares de calidad. Para prototipos o cosas de una sola vez es excelente, pero tiene límites cuando se trata de durabilidad a largo plazo
Para exprimir al máximo la productividad con estas herramientas, la clave es tener bucles de retroalimentación muy cortos y rápidos. El modelo de autocompletado con tab de Cursor entiende de forma casi intuitiva lo que el editor intenta hacer; se siente como si estuviera frenando con una inteligencia absurda. No necesito romperme la cabeza programando macros: si no me sirve, cancelo con Esc, y si sí, voy pasando poco a poco a un modo más agentic. Los editores totalmente basados en agentes tardan 15 a 30 minutos y además rompen por completo el flujo de trabajo. Revisar lo que producen ya es un trabajo en sí, y requiere mucha más atención que un ciclo corto de aceptar o rechazar. También está la duda de si darles permisos de red o correrlos offline, así que solo valen la pena cuando quieres sacar código rápido y no importan tanto mantenimiento, seguridad o confiabilidad. Fuera de eso, hasta bajan la productividad. Seguro mejorarán, pero hoy por hoy sigo consiguiendo mejores resultados en Cursor
Yo también pensaba así, pero últimamente usé Claude Code de verdad y sentí que es mucho mejor que Cursor. No sé bien por qué, pero parece que Claude entiende mejor la estructura completa y evita cambios innecesarios. Claro, a veces hay que guiarlo más directamente, pero la eficiencia es mucho mayor. Una ventaja es que normalmente te muestra solo un archivo a la vez, así que revisar es mucho más fácil. Cursor abre varios archivos de golpe y hay tantos cambios que cuesta captar rápido qué pasó. Yo, por cierto, uso la extensión de Claude Code dentro de la terminal de VSCode. Claude abre la pestaña del archivo que quiere cambiar y propone la modificación
Lo que la gente todavía no termina de ver es que Cursor no es un producto terminado, sino un paquete de funciones que todas las demás herramientas están intentando copiar a toda velocidad. La verdadera lección es que, además de las interfaces profundas, existe una estrategia de combinar soluciones agentic best-in-class con el editor que cada quien prefiera. Estas experiencias al final se van a condensar en “best practices”, la gente las va a integrar de forma natural en su editor o IDE, y todos estos forks de vscode van a desaparecer
Lo usé menos de un mes con el plan de 17 dólares, y fue mitad asombro, mitad frustración. Escribí 8 mil líneas en Rust y 12 mil en Markdown, separando las especificaciones de trabajo y las tareas concretas para interactuar con la IA casi como si fueran un test harness. No sé si la magia se debe a subsidios de VC o qué, pero Rust llegó a sentirse como un lenguaje de scripting. (Por cierto: el repositorio de GitHub es
knowseams)Lo mejor de la IA para mí es que, cuando me da flojera, puedo decir “haz esto”. No importa si el resultado sale bien o mal. Al menos me da un punto de arranque
Gracias a los LLM ya no existe el miedo a la página en blanco. Sin tener que reconstruir en mi cabeza todo el contexto complejo, puedo preguntar “¿qué estábamos haciendo?”, “¿qué era este código?”, y la IA me lo explica de inmediato, así que puedo volver a concentrarme enseguida. Incluso para rubber duck debugging o tareas repetitivas y triviales (
yak shaving), me ahorra muchísimo tiempo. También la tengo integrada con Slack, Notion, Linear y más, así que para mí funciona como herramienta de gestión de tareas y proyectosIncluso cuando quiero hacerlo yo mismo, le pido a la IA que me trace un plan y lo dejo escrito en Markdown. Hoy mismo le pedí un plan de refactor, pero intentó reestructurar desde abajo un bloque de código prototipo repartido en 40 archivos, o sea, arrancó por el enfoque equivocado. Si hubiera seguido ese camino por error, habría perdido una barbaridad de tiempo depurando. Aun así, me dio un punto de ataque, y corregí y apliqué el plan en una hora. Si hubiera estado solo, probablemente me habría abrumado la complejidad y ni habría empezado, o me habría quedado atorado iterando documentación hasta abandonar
Al final del día, cuando ya no me puedo concentrar y termino escribiendo y revirtiendo casi lo mismo, puedo dejarle el volante a la IA y respirar un poco. Si son issues pequeños, basta con echarle un vistazo al diff; si son difíciles, mientras yo entienda exactamente cuál es el problema, puedo orientar a la IA y convencerla del rumbo. Normalmente tomo el control cuando ya está hecho entre un 40 y 60%, y de ahí termino yo. En general, uso mis horas más agudas para pensar y desarrollar directamente, y le dejo a la IA las horas extra o el trabajo repetitivo, para así preparar el día siguiente o dedicarme más a redacción de mayor nivel y diseño
Yo solo salgo a caminar y tomo café. Los problemas humanos se sienten más naturales cuando se resuelven de manera humana
Claude Code es difícil de describir. Después de usarlo, hasta sentí como si hubiera cambiado de profesión. Ya había metido Claude de lleno en mi flujo de trabajo, pero Claude Code está realmente “con esteroides”. Si todavía no lo pruebas, lo recomiendo totalmente. Es la primera vez que de verdad siento que trabajo con un ingeniero junior
Mi experiencia es exactamente la opuesta. Le dices que haga algo, pasan varios minutos y te entrega alguna cosa, pero en realidad rompe la app y, cuando te pones a depurar, resulta que hizo algo completamente fuera de lugar y acabas tirándolo todo. Aun así sigo insistiendo con Claude porque, si realmente funcionara tan bien como a otras personas, sería increíble. En la práctica, me saca boilerplate, me toca depurar bastante yo mismo y, en el peor caso, pierdo una hora y un montón de tokens
Hoy lo probé por primera vez en el trabajo y me pareció un cambio muchísimo más revolucionario que Cursor. Aunque usan el mismo foundation model, la experiencia es totalmente distinta. Hace un mes la IA me hacía trabajar más lento, pero hoy con Claude Code resolví todo en 20 minutos y ni siquiera gasté 10 dólares en API. Tuve que preocuparme muy poco por gestionar el contexto, y Claude Code encuentra por sí mismo el contexto que necesita y lo mete, así que puede trabajar de forma productiva por mucho más tiempo. El modo agent de Cursor solo me parece útil para tareas de 3 a 5 minutos, pero Claude Code mantiene el rumbo y sigue avanzando incluso en tareas de más de 10 minutos. También usa herramientas de forma excelente y sorprende lo poco que cae en loops
Dijiste “se siente como trabajar con un ingeniero junior”, pero en mi caso siento más bien que yo soy el subordinado y Claude es mi jefe. Es como llegar a presumir: “¡hice esta cosa increíble!”, y que te respondan: “sí, pero eso no fue lo que te pedí…”
¿Podrías explicar con más detalle en qué tipo de tarea, lenguaje o dominio lo usaste? Todos los casos son tan distintos que da curiosidad
A mí me pasa igual. Claude está por encima de un junior simple. Es buenísimo proponiendo opciones, recomendando decisiones y visualizando trade-offs
¿No hay muchos walkthroughs reales de crear apps o librerías con Claude Code? Más que leer posts de “qué increíble”, me gustaría ver desarrollo real en producción con esa herramienta. Estaría buenísimo tener una recopilación de casos así
En general, toda esta situación se siente un poco rara. Claude Code claramente es bueno y sirve para encontrar documentación o Stack Overflow mucho más rápido. Pero si todos los rumores exagerados fueran ciertos, ¿no deberíamos estar viendo una explosión brutal de innovación en software gracias a estas herramientas? El CEO de Stripe dijo que las herramientas de IA aumentaban la productividad 100 veces; si ya pasaron 3 o 4 meses, ¿Stripe no debería estar lanzando cohetes a estas alturas? Microsoft también apostó todo a AI coding, pero entonces ¿por qué Teams sigue sintiéndose tan mediocre? Llevamos más de un año oyendo que estas herramientas son revolucionarias, pero la realidad no se ve tan distinta a la de hace 3 o 4 años
Dos tendencias muy visibles últimamente son: (1) gente sin mucha experiencia usando IA para proyectos pequeños, y (2) desarrolladores que especifican por adelantado y con muchísimo detalle toda la estructura de la app, archivos, interfaces, stack tecnológico y framework de pruebas, y luego logran sacarle resultados decentes al LLM a punta de manipularlo con precisión ejemplo en YouTube. El 80–99% de lo que se oye en PR/YouTube en realidad viene del primer grupo. La sensación de aumento de productividad existe porque conversar con el LLM, documentar, guiar y corregir se siente menos agotador que desarrollar directamente. Aunque el tiempo o el esfuerzo total sean iguales, psicológicamente baja la expectativa de carga
He estado buscando streams o casos reales en YouTube donde sí se vea un boost de productividad de verdad, pero no he encontrado ninguno que me haga pensar: “¡wow, sí va rapidísimo!”
Hay opiniones muy polarizadas a favor y en contra, pero en realidad la mayoría simplemente sigue haciendo commits en silencio (lo cual de por sí es irónico). En mi caso, según la tarea, sí siento mejoras reales de entre 1.5x y 10x. La ventaja más grande es que baja muchísimo la carga cognitiva en trabajo puramente creativo, de una sola vez, boilerplate o refactors, así que mantengo resultados consistentes. Todavía escribo mucho código “a mano” y reviso casi todas las líneas hasta el final. Dejarlo trabajando solo durante horas es una pesadilla. De hecho, en una app de producción que llevamos manteniendo más de 10 años ni siquiera tengo tiempo de ir a presumirlo en algún blog. También ayuda que trabajo en una organización muy delgada, así que tengo el contexto completo del sistema en las manos y puedo detectar problemas más rápido. En entornos donde la eficiencia personal es clave, sí potencia lo esencial. En organizaciones grandes es difícil tener esa experiencia
En mi experiencia, ayuda tener un archivo Markdown llamado Claude.md en la raíz de cada carpeta de código, agregando un ruleset mínimo, como si fuera un pipeline. Ahí le indico exactamente cómo generar y ubicar tests, y evito que cree archivos de depuración. También pongo reglas para impedir la proliferación innecesaria de clases o estructuras nuevas y favorecer la reutilización salvo que de verdad haga falta. Tampoco escribo prompts largos; normalmente solo le pido que haga un plan cuando hay partes inciertas. Incluso para issues nuevos que están fuera del conocimiento del LLM, le doy la menor cantidad posible de input grande. Con este enfoque obtengo resultados consistentes de 1 input–1 output, incluso aplicando profundidad. Últimamente dejé Claude Code y me pasé a usar otros modelos grandes como Opus en modo CLI, porque sale más barato. El verdadero poder está en el CLI. Estoy corriendo 60 a 70 agent streams al mismo tiempo y gestionando sin problema un codebase de 200 millones de tokens (react/typescript/golang). Solo una o dos veces he tenido que dar instrucciones adicionales
¿Podrías listar qué operas con esos agent streams? Me da muchísima curiosidad
Me gustaría saber qué modelos usas además de Anthropic. Probé Kimi K2, pero para mi caso no me funciona tan bien
También me da curiosidad qué significa exactamente “agent streams”. No me imagino cómo se gestionan 60 o 70 sin una carga cognitiva brutal
A veces Claude Code me dispara la productividad en tareas muy concretas. Recomiendo aprovechar slash commands y convertir conversaciones previas en slash commands. Así vas acumulando un set de comandos primitivos cada vez más reutilizable. Tengo ejemplos en GitHub: make-command.md, improve-command.md
PSA (dato de utilidad pública): con este repositorio puedes conectar Claude Code con prácticamente cualquier modelo. Dicen que el Kimi-K2 más reciente funciona bastante bien
Yo también probé Kimi-K2, pero rinde menos que Sonnet/Opus 4.0, aunque para tool calling está mejor que Gemini 2.5 Pro. Si Claude Max (100–200 dólares al mes) te queda pesado, lo recomiendo mucho. Me gusta que el modelo sea muy simple y sin tanta grasa. Anthropic haría bien en open sourcear Claude Code: podría convertirse en el VSCode de los cli coding agents. Y también recomiendo opencode, que soporta todos los modelos de forma nativa y ofrece funciones similares a Claude Code
Si vas a usar varios modelos, mejor recomiendo directamente sst/opencode (yo también lo uso con Claude Pro)
Por cierto, para quienes aún no han probado CC: pueden bajar el cliente de CC por npm y usarlo gratis
Estaba jugando a hacer “vibe coding” con Claude Code, local LLM, Continue y VSCode para una app sencilla en Python, y luego descubrí el free tier de Claude, así que le metí el código que ya llevaba y los resultados del otro LLM. Me emocioné porque resumió y corrigió los errores y actualizaciones de una sola vez con mucha precisión. Entonces intenté subir de nivel: preparé con ChatGPT el spec y los prompts para un juego 2d en pygame estilo Manic Miner, se los pasé a Claude, y Claude se puso a referenciar métodos que no existen o a decir tonterías sobre diferencias de versión del codebase. Incluso señalándole el número de línea y el código alrededor, seguía haciéndome gaslighting. ¿Cómo se resuelve eso? No espero perfección, pero siento que me topé con limitaciones similares a las de un local LLM. Mi salud no está muy bien y solo puedo hacerlo por ratos, así que agradecería consejos
Lo más probable es que hayas caído en un “infierno de código lleno de interfaces ambiguas y supuestos ocultos”. En ese caso, mejor resume todos los resultados previos de ChatGPT, documenta qué hace actualmente el juego y lista en detalle todas sus funciones; luego pásale ese documento a Claude y pídele que vuelva a descomponer los requisitos desde cero. Claude puede sacar muy buenos ejemplos incluso en zero-shot, y en el peor caso puede iterar puliéndose a sí mismo. Si aun así sigue inventando funciones absurdas, te recomendaría instalar el servidor MCP de context7 y pedirle explícitamente a Claude que use context7
Esa es una limitación fundamental de la tecnología LLM. Genera de forma probabilística la secuencia de tokens “más plausible”, pero si “plausible” y “correcto” no coinciden, no hay salvación. Y el criterio de qué suena “plausible” cambia entre LLM según entrenamiento o fine-tuning
Después de la configuración básica, me interesa saber qué otras técnicas usan para que esta herramienta funcione bien. Es decir, qué métodos prácticos usan con el contexto y la organización del codebase para que la herramienta se oriente sola con precisión. Dejé mis ideas aquí: este post. Creo que seguirán apareciendo metodologías mejores
Estoy obteniendo varias alphas con Claude Code, pero me preocupa cómo escalarlo a todo el equipo. Me interesa saber si hay formas de compartir tips operativos o best practices para que mis compañeros o la gente que gestiono puedan usar Claude Code de manera efectiva