He estado usando Claude Code como mi herramienta de desarrollo principal durante aproximadamente seis meses. No ocasionalmente, no como experimento — como el default. Cada feature, cada sesión de debugging, cada refactor pasó por él.
La respuesta honesta a “¿cambió cómo trabajas?” es sí, pero no de las formas que esperaba. Las ganancias de productividad son reales pero más estrechas de lo que sugiere el marketing. Los costos son reales pero diferentes de las preocupaciones que la gente suele plantear.
Qué cambió realmente
El cambio más grande no es la velocidad — es la proporción de lectura versus escritura.
Antes de Claude Code, escribía código y lo leía después para verificar si era correcto. Con Claude Code, escribo especificaciones (en lenguaje natural, en comentarios, en pseudocódigo) y leo el código generado para verificar si coincide con mi intención. La actividad es similar; la dirección está invertida.
Suena sutil. No lo es. Escribir código te obliga a resolver la ambigüedad — no puedes dejar “manejar el caso de error” como una nota para ti mismo, tienes que implementarlo. Leer código generado permite diferir la resolución de la ambigüedad, lo que significa que se acumula. El código compila, los tests pasan, y tres semanas después descubres que “manejar el caso de error” se interpretó como “tragar el error silenciosamente”.
Los ingenieros que conozco que más aprovechan Claude Code son los que aprendieron a escribir especificaciones más precisas, no prompts más rápidos.
Dónde es genuinamente excelente
Boilerplate con restricciones. Cualquier cosa que siga un patrón que puedo describir con precisión — handlers de API REST, interfaces TypeScript derivadas de un schema, fixtures de tests, archivos de migración — Claude Code lo hace bien. La ganancia no es solo velocidad; es que el patrón se aplica de forma consistente. No hay “olvidé agregar el error handler en esta ruta” porque el patrón lo incluye.
Refactorings entre archivos. Renombrar un tipo usado en treinta archivos, actualizar una interfaz y propagar los cambios a todas las implementaciones, mover un módulo y actualizar los imports — estas operaciones son tediosas manualmente y propensas a errores porque los humanos nos saltamos archivos. Claude Code no se aburre.
Documentación que habría omitido. No estoy orgulloso de esto, pero documenté cosas con Claude Code que habría dejado sin documentar por mi cuenta. La fricción es tan baja que “agrega JSDoc a esta función” toma menos tiempo que decidir si vale la pena hacerlo.
Rubber duck debugging. Describir un problema con suficiente detalle para que Claude Code ayude a menudo revela el problema antes de que responda. Es la técnica Feynman como efecto secundario.
Dónde rinde por debajo de las expectativas
Lógica de negocio compleja con múltiples restricciones. Cuando la lógica requiere mantener varias invariantes de dominio en tensión — el tipo de código que los ingenieros senior escriben lenta y cuidadosamente — Claude Code produce código de apariencia plausible que frecuentemente omite una restricción. No siempre. Con suficiente frecuencia como para que haya dejado de usarlo para esta categoría sin revisión muy cuidadosa.
En sistemas financieros, “de apariencia plausible pero levemente incorrecto” es peor que “obviamente roto”. Los fallos obvios se capturan en testing. Los errores sutiles de lógica en reglas de elegibilidad o cálculos de interés se capturan en producción.
Decisiones arquitectónicas. Claude Code no sabe qué necesita ser un codebase en dos años. No conoce las capacidades del equipo, la tolerancia al riesgo de la organización, o las restricciones regulatorias que una solución debe navegar. Produce soluciones para el problema técnico estrecho frente a él. El contexto que hace una solución realmente buena no está en el prompt.
Debugging de incidentes novedosos en producción. Para patrones de error conocidos, es útil. Para “esto funciona en staging, falla bajo condiciones específicas de carga en producción, y los logs muestran X pero no Y” — el tipo de debugging que requiere intuición sobre el sistema — es una distracción más que una ayuda.
La inversión en CLAUDE.md
La feature más subestimada es el archivo CLAUDE.md. Permite codificar contexto que persiste entre sesiones: convenciones de código, restricciones arquitectónicas, qué evitar y por qué.
Un fragmento de uno que uso en un proyecto TypeScript:
## Restricciones arquitectónicas
- Nunca usar `any` — usar `unknown` y estrecharlo explícitamente
- Todas las respuestas de API se validan con Zod antes de usarse
- Los schemas de validación de formularios viven en `src/schemas/`, no en archivos de componentes
- Los efectos secundarios van en `src/infrastructure/`, nunca en capas de dominio o aplicación
## Qué evitar
- No usar `useEffect` para data fetching — usar React Query
- No agregar `console.log` en código de aplicación
- No escribir bloques catch que traguen errores silenciosamente
- No agregar optional chaining donde el valor siempre debería estar presente — corregir el tipoEl ROI de esta inversión es asimétrico. Treinta minutos escribiendo un buen CLAUDE.md elimina la misma corrección repitiéndose en cada sesión durante meses.
El cambio de mentalidad
El reencuadre más útil: Claude Code es un colaborador rápido, knowledgeable, levemente sobreconfiado, sin memoria, sin contexto de dominio, y sin interés en el resultado.
Tratarlo como un motor de búsqueda — “genera X” — produce resultados mediocres. Tratarlo como un pair programmer con estas características específicas — bueno en patrones, necesita contexto explícito, requiere revisión, confiado incluso cuando está equivocado — produce buenos resultados.
Los ingenieros que tienen dificultades con Claude Code son frecuentemente los que lo tratan como un oráculo y se saltan la revisión, o los que lo tratan con tanto escepticismo que solo lo usan para tareas tan simples que habrían terminado más rápido solos.
Evaluación neta
Seis meses después: escribo menos código del que escribía antes. Reviso más código del que revisaba antes. Paso más tiempo escribiendo especificaciones, pensando en restricciones y revisando output del que pasaba escribiendo código yo mismo.
Para ingenieros experimentados que ya son buenos en especificación y revisión, la ganancia de productividad es real — probablemente 30-40% en tareas donde aplica. Para tareas que requieren conocimiento de dominio, intuición sobre el sistema, o navegación cuidadosa de restricciones, la ganancia es menor o negativa una vez que consideras el tiempo de revisión cuidadosa.
No reemplazó el juicio de ingeniería. Cambió a qué se aplica el juicio de ingeniería.