← Volver al blog

Cómo usamos Claude en nuestros desarrollos (y cómo no deberías usarlo)

Conceptual Creative ·

Hay dos formas de usar Claude en un equipo de desarrollo. La primera produce código mediocre que hay que reescribir a los tres días. La segunda multiplica lo que un equipo pequeño puede entregar sin sacrificar calidad.

En Conceptual Creative llevamos tiempo usando Claude en nuestros procesos internos. No como sustituto del programador, sino como lo que realmente es: un compañero de equipo que necesita contexto para dar lo mejor de sí.

Este artículo no es publicidad de Anthropic. Es lo que hemos aprendido a base de errores.

El error más común: tratar la IA como un buscador glorificado

La mayoría de equipos que incorporan Claude lo usan así: “escríbeme una función que valide emails”, “explícame qué hace este código”, “genera los tests para esta clase”.

Funciona. Pero es la versión de mínimos.

El problema es que Claude no tiene contexto de tu proyecto. No sabe que ya tienes un sistema de validación en src/utils/validators.ts. No sabe que usas una versión concreta de Laravel con ciertas convenciones. No sabe que el mes pasado decidisteis no usar ciertos patrones por una razón específica.

Cuando le pides código sin contexto, te da código correcto en abstracto pero incorrecto para tu base de código. Y eso genera más trabajo del que ahorra.

Lo que cambia cuando le das contexto real

El contexto lo es todo. No estamos hablando de pegar el archivo completo en el chat — estamos hablando de que Claude entienda:

  • La arquitectura del proyecto
  • Las convenciones de código que sigue el equipo
  • Las decisiones técnicas ya tomadas y por qué
  • El stack tecnológico específico

Cuando Claude trabaja con ese contexto, la diferencia es enorme. No solo genera código que encaja en tu proyecto — también detecta inconsistencias, sugiere refactorizaciones coherentes con lo que ya existe, y evita duplicar funcionalidad.

En nuestro caso, construimos un sistema de contexto para cada proyecto: arquitectura, convenciones, decisiones. Claude lo lee antes de tocar una línea de código.

El rol del programador no desaparece — cambia

Hay un miedo legítimo en los equipos de desarrollo: ¿me va a quitar el trabajo?

La respuesta honesta es: te quita las tareas repetitivas y tediosas. Y eso es bueno.

Lo que sigue necesitando criterio humano:

El diseño de arquitectura. Claude puede ejecutar una arquitectura perfectamente, pero decidir si un sistema necesita microservicios o un monolito bien estructurado requiere juicio contextual que la IA no tiene.

La comprensión del negocio. Cuando un cliente en Canarias necesita un sistema que gestione el RIC o las particularidades del REF, eso no está en ningún manual que Claude haya leído. Tú conoces el contexto de tu cliente.

La revisión crítica. Claude se equivoca. A veces de formas sutiles. Un programador que entiende lo que está haciendo detecta esos errores. Uno que usa la IA como caja negra los pasa a producción.

El programador que sabe usar bien la IA entrega más en menos tiempo. El que delega sin criterio produce deuda técnica.

Lo que hemos incorporado en nuestro flujo

Sin entrar en detalles técnicos de nuestra metodología interna, hay principios que aplicamos:

Especificación primero. Antes de que Claude genere código, existe un contrato claro de qué hay que construir, con qué restricciones y por qué. Esto elimina la improvisación y los malentendidos. Es parte de cómo trabajamos en SpecLeap, nuestro framework de desarrollo.

Contexto persistente. Cada proyecto tiene documentación de arquitectura y convenciones que la IA lee antes de trabajar. No empezamos desde cero en cada sesión.

Revisión humana de todo. Ningún código generado por IA va a producción sin que un programador lo haya leído y aprobado. Esto no es desconfianza — es responsabilidad profesional.

Iteración, no generación completa. En lugar de pedir a Claude “escribe el módulo de facturación”, le pedimos partes específicas, revisamos, y seguimos. Los módulos grandes generados de una vez tienden a ser inconsistentes.

¿Cuándo no usar Claude?

Tan importante como saber usarlo es saber cuándo no.

Si estás trabajando con información sensible de clientes — datos personales, datos financieros, información estratégica del negocio — hay que ser muy cuidadoso con qué se comparte con servicios en la nube. Los términos de uso de las IA no siempre garantizan la privacidad de los datos que envías.

Para ese tipo de trabajo, existen alternativas. Pero eso da para otro artículo.

La conclusión práctica

Claude usado bien ahorra tiempo real, reduce errores repetitivos y ayuda a mantener la consistencia en proyectos grandes. Claude usado sin contexto ni criterio produce código que parece correcto pero que acumula problemas.

La diferencia no está en la herramienta — está en cómo la incorporas al flujo de trabajo del equipo.

Si estás pensando en cómo estructurar ese flujo para tu equipo de desarrollo, es exactamente el tipo de problema que resolvemos. Cuéntanos qué estás construyendo.