Cómo uso Claude Code y Cursor para acelerar el desarrollo full-stack

Últimamente me lo preguntan mucho: "¿De verdad usas IA para escribir el código?". La respuesta corta es sí: Claude Code y Cursor forman parte de mi flujo de trabajo diario en proyectos reales de clientes. La respuesta larga es más útil, porque cómo usas estas herramientas marca la diferencia entre entregar más rápido y entregar un desastre.

Este artículo es una mirada práctica a dónde me ahorran tiempo de verdad estas herramientas en el trabajo full-stack, dónde no, y cómo mantengo el resultado con una calidad que firmaría con gusto.

Dos herramientas, dos trabajos

La gente mete todas las "herramientas de programación con IA" en el mismo saco, pero yo las uso para cosas distintas.

• Cursor vive dentro del editor. Es genial para ediciones rápidas y en contexto: refactorizar un componente, escribir una función mientras miro, autocompletar las siguientes líneas obvias. También tiene su propio modo agente para cambios más grandes, pero donde brilla para mí es cuando estoy concentrado y quiero seguir así.
• Claude Code trabaja a nivel de proyecto. Lo uso sobre todo desde la terminal (también tiene extensiones para IDE, una app de escritorio y una versión web). Me apoyo en él para tareas más grandes que afectan a varios archivos, como "conecta este nuevo endpoint a través del servicio, el controlador y los tipos" o "encuentra todos los sitios donde se llama a esta API antigua y actualízalos". Se le da mejor tener en la cabeza un cambio completo.

Ninguna de las dos sustituye a entender el código. Me hacen más rápido en cosas que ya sé hacer.

Ahora ambas herramientas también pueden ejecutar agentes en segundo plano o en la nube y devolver una rama o un pull request terminados. Es práctico para tareas bien definidas, pero eleva la exigencia de la revisión: cuanto menos haya visto del trabajo mientras se hacía, con más cuidado leo el resultado.

El problema de negocio: el tiempo de desarrollo es tu recurso más caro

Si estás pagando por un desarrollo, en realidad estás pagando horas. Cualquier cosa que convierta una tarea de una hora en una de quince minutos, sin bajar la calidad, reduce directamente tu coste y acorta tus plazos.

El problema está en esa parte de "sin bajar la calidad". Las herramientas de IA pueden producir código que parece terminado pero no lo está. Así que la verdadera habilidad no es escribir prompts. Es saber qué trabajo delegar y revisar el resultado como revisarías el pull request de un desarrollador junior.

Dónde me ahorran tiempo de verdad estas herramientas

Código repetitivo y fontanería

Cada funcionalidad full-stack tiene un armazón predecible: un endpoint tipado, validación de la petición, una consulta a la base de datos, el formulario correspondiente en el frontend, estados de carga y de error. Es un trabajo necesario pero poco interesante, y es donde la IA da la mayor y más segura aceleración. Describo la forma, la herramienta escribe un borrador, yo reviso y ajusto.

Cambios repetitivos y mecánicos

Renombrar un concepto en cuarenta archivos, actualizar cada llamada después de un cambio en una API, convertir un lote de componentes a un nuevo patrón. A mano, esto es tedioso y propenso a errores. Claude Code lo hace rápido y de forma coherente, y yo reviso el diff antes de aceptarlo.

Tests que de otro modo tendría la tentación de saltarme

Con una fecha límite encima, los tests son lo primero que se abandona. La IA abarata escribir los casos que me saltaría: la lista vacía, el token caducado, el envío duplicado. Más cobertura con menos esfuerzo es una victoria clara.

Entender código desconocido

Cuando me incorporo a un proyecto existente, puedo pedirle a Claude Code que me explique cómo encaja un subsistema en lugar de leer cada archivo en frío. Es una forma más rápida de entrar, y aun así verifico lo que me dice.

Dónde no me apoyo en ellas

El límite en el que me he asentado no tiene que ver realmente con la herramienta. Son dos preguntas: ¿qué tan reversible es este cambio y puedo demostrar que es correcto? Si algo es barato de revertir y fácil de verificar con tests, me siento cómodo dejando que la IA haga gran parte. Si crea restricciones a largo plazo, la IA es como mucho quien escribe el borrador, y la decisión final sigue siendo mía.

• Arquitectura y modelado de datos. Estas decisiones se acumulan. Las tomo yo y solo uso la IA para poner a prueba las opciones. Un esquema que parece correcto y se genera en treinta segundos puede darte problemas semanas después.
• Cualquier cosa sensible en términos de seguridad. Autenticación, permisos, flujos de pago, aislamiento entre tenants. Los escribo y reviso con cuidado. La IA generará sin problema un endpoint sin ninguna comprobación de autorización.
• Lógica de negocio sutil. Si las reglas son inusuales o hay dinero real en juego, quiero que una persona tenga el control total de los detalles.
• Gestión de fallos. El camino feliz se genera de maravilla; son los fallos parciales, los reintentos y la idempotencia donde la IA adivina mal en silencio, y no te enteras hasta que está funcionando en producción.

El riesgo más profundo no suele ser el código en sí. Son las suposiciones que incorpora sin decírtelo. Una función generada puede pasar todos los tests mientras asume en silencio que "este campo siempre está ahí" o que "esta lista nunca crece mucho". Nadie lo dejó por escrito, así que nada lo vigila. Mi verdadero filtro es: ¿este código incorpora una suposición operativa que nada más está comprobando? En validadores, CRUD y estados de la interfaz, esas suposiciones son locales y visibles, así que no me preocupan tanto. En el modelo de datos y en los puntos de integración son globales y silenciosas, que es justo donde una suposición errónea hecha con total seguridad sobrevive a la revisión.

Un ejemplo real

Gran parte de mi trabajo reciente ha sido en plataformas SaaS multi-tenant y sistemas de venta de entradas, el tipo de proyectos con un backend en NestJS o Node, un frontend tipado en React o Next.js y mucha superficie CRUD repartida entre muchos módulos: usuarios, eventos, entradas, pagos, notificaciones.

En ese tipo de código, el patrón es repetitivo por diseño: cada módulo se parece al anterior. Ese es el punto ideal para la asistencia de la IA. Puedo generar la estructura de los endpoints, los DTOs, la validación y los formularios del frontend de un nuevo módulo en una fracción del tiempo habitual, y luego dedicar mi atención real a las partes que son diferentes: las reglas de permisos, los casos límite, cómo encaja en la arquitectura existente.

El resultado, siendo sinceros, no es magia. Es que el 70% aburrido va más rápido, lo que deja más tiempo y energía para el 30% que decide si la funcionalidad es realmente buena.

Errores comunes que veo

• Aceptar grandes cambios de la IA sin leerlos. Cuanto mayor es el diff, más probable es que haya algo sutil mal.
• Escribir prompts en lugar de pensar. Si no sabes cómo es algo bien hecho, la IA no puede decírtelo. Simplemente producirá algo.
• Saltarse el paso del modelo de datos. Un esquema hecho con prisas por la IA es un esquema contra el que lucharás durante meses.
• No tener tests. Velocidad sin red de seguridad solo significa que rompes cosas más rápido.
• Dejar que el estilo se desvíe. Sin orientación, la IA escribe código con su propio estilo, no con el del proyecto. Me aseguro de que coincida con el código que lo rodea y escribo las convenciones del proyecto en el archivo de instrucciones de cada herramienta (un CLAUDE.md para Claude Code, reglas de proyecto para Cursor) para que parta de los patrones correctos.
• Ignorar el acoplamiento sutil. El bug caro rara vez es de sintaxis. Es una función auxiliar generada que, sin que nadie lo note, se convierte en el lugar donde se cruzan la autenticación, el estado de facturación y las suposiciones del producto. Se publica rápido y cobra intereses más tarde.
• No saber quién usa la IA y para qué. Puedes tener una disciplina de revisión impecable y aun así llevarte un disgusto si la mitad del equipo está pasando esquemas de producción a una herramienta de IA sin decírselo a nadie. La gobernanza, sin caer en la paranoia, es un problema en sí misma.

Cómo mantengo la calidad alta

1. Cambios pequeños y revisables: prefiero guiar diez ediciones concretas antes que aceptar una gigante.
2. Leerlo todo: cada línea escrita por la IA recibe la misma revisión que el PR de un compañero.
3. Tests en los caminos importantes: sobre todo en los casos de fallo.
4. Seguir los patrones existentes: el código debe parecerse al resto del proyecto, no dar la impresión de venir de otro.
5. Mantener humanas las decisiones humanas: la arquitectura, la seguridad y la lógica del dinero siguen en mis manos.
6. Hacer que cada cambio de la IA rinda cuentas: para cualquier cosa no trivial, quiero que el cambio muestre lo que realmente ha tocado: qué tablas, rutas o permisos han cambiado, qué podría corromper datos o filtrarse entre tenants, pruebas del antes y el después, tests añadidos u omitidos deliberadamente, y un plan para revertirlo. Ese justificante importa más que la herramienta que produjo el código.

Si te interesa la visión general de construir productos ligeros de esta forma, escribí sobre cómo el desarrollo asistido por IA ayuda a construir MVPs más rápido sin perder calidad.

¿Quieres un desarrollador que use bien las herramientas modernas?

Usar bien la IA es una habilidad. Es la diferencia entre un desarrollo más rápido y limpio y una limpieza cara más adelante. Uso estas herramientas cada día para entregar proyectos full-stack web y móviles más rápido sin recortar en lo que importa.

Si ese es el tipo de desarrollador que quieres en tu proyecto, echa un vistazo a mi trabajo o escríbeme y cuéntame qué estás construyendo.