Inicio›Blog›Lo que Claude Code cambió en el trabajo de los desarrolladores, y lo que todavía no
Ferramentas de IAClaude CodeDesenvolvimentoAgentic AI

Lo que Claude Code cambió en el trabajo de los desarrolladores, y lo que todavía no

Rudinei Gehm29 de marzo de 20266 min de lectura

Claude Code cambió la unidad de trabajo de un desarrollador. La pregunta ya no es "cómo escribo esta función", sino "cómo describo este cambio y cómo compruebo que es correcto". La primera parte se abarató mucho. La segunda sigue siendo tan cara como siempre, y es donde se separan los buenos equipos de los mediocres.

Qué es, en la práctica

Claude Code es el agente de programación de Anthropic que funciona en el terminal. Se lanzó como versión preliminar en febrero de 2025 (Anthropic, 2025) y pasó a estar disponible para todos en mayo de ese año (Anthropic, 2025). Lee el repositorio, edita archivos, ejecuta comandos y pruebas, hace commits y utiliza las herramientas de línea de comandos que el desarrollador ya usa.

La diferencia con un asistente de chat está en la posición. En el chat, usted copia un fragmento, lo pega, recibe otro fragmento y lo adapta. En el terminal, el agente lee el tsconfig, entiende la estructura de carpetas, ve que el proyecto usa un alias para src y escribe código que encaja con lo que ya existe. Después ejecuta el build para comprobar si algo se ha roto.

Dos funciones cambian el uso en equipo. El archivo CLAUDE.md guarda instrucciones persistentes del proyecto (convenciones, comandos, lo que no se debe hacer) y se carga al inicio de cada sesión. Y la propia documentación advierte de que esas instrucciones son contexto, no un bloqueo: para impedir una acción independientemente de lo que decida el modelo, se usan hooks, scripts que se ejecutan antes o después de cada herramienta (Claude Code Docs). Es una distinción que todo CTO debería conocer antes de abrir la herramienta al equipo.

Qué muestran los estudios, y qué no

La adopción ya es mayoritaria. En la encuesta de 2025 de Stack Overflow, con más de 49.000 participantes, el 84% de los desarrolladores dijo usar o planear usar herramientas de IA, frente al 76% del año anterior. En la misma encuesta, el 46% dijo no confiar en la precisión de lo que producen, frente al 31% de 2024 (Stack Overflow, 2025). Uso al alza y confianza a la baja al mismo tiempo: un retrato fiel del momento.

El estudio más citado sobre productividad va en contra del entusiasmo. En julio de 2025, METR publicó un experimento controlado con 16 desarrolladores experimentados de proyectos open source, trabajando en 246 tareas reales en sus propios repositorios. Con herramientas de IA tardaron un 19% más. Antes del experimento esperaban ganar un 24%. Después, seguían creyendo que habían sido un 20% más rápidos (METR, 2025).

El propio METR volvió al tema en febrero de 2026. Un nuevo experimento apuntó a una mejora de velocidad, pero el instituto calificó el resultado de poco fiable: muchos desarrolladores se negaron a participar si tenían que trabajar sin IA, y parte de ellos evitó presentar tareas que creían que la IA resolvería rápido (METR, 2026). La lectura honesta es que la ganancia probablemente existe, es difícil de medir, y la percepción de quien usa la herramienta no sirve como vara de medir.

El informe DORA 2025 de Google, basado en casi 5.000 profesionales de tecnología, ofrece el marco más útil para quienes dirigen equipos: la IA funciona como amplificador. Aumenta las fortalezas de los equipos con una buena plataforma interna y flujos de trabajo claros, y aumenta los problemas de los que ya estaban desorganizados (DORA, 2025).

Dónde aparece la ganancia

Según nuestra experiencia, en tres tipos de trabajo.

Cambios amplios y mecánicos. Renombrar un patrón en decenas de archivos, migrar de una librería a otra, actualizar una interfaz en todos los componentes que la usan. El tipo de tarea que una persona hace mal por aburrimiento.

Código repetitivo con contexto. No el boilerplate genérico, sino el que sigue el sistema de tipos, las convenciones y los componentes del proyecto. Generar un componente es trivial. Generar el componente adecuado para este proyecto es lo que ahorra tiempo.

Lectura amplia para depurar. El agente lee muchos archivos, sigue la cadena de llamadas y encuentra inconsistencias que nadie estaba buscando.

Un caso real, en este sitio

Esta sección se añadió en septiembre de 2026. El repositorio de este sitio incluye commits hechos en sesiones con Claude Code, y dos episodios muestran con claridad dónde ayuda el agente y dónde la persona sigue siendo necesaria.

En el primero, después de corregir un error de idioma en el blog, una sesión dedicada a otra tarea encontró el mismo patrón en otras cuatro páginas: ofertas, la lista y el detalle de casos y la página de RÜNARA estaban fijadas al contenido en portugués, fuera cual fuera el idioma de la URL. Nadie había pedido esa búsqueda. Meses después, al añadir páginas nuevas, encontró una copia desactualizada del árbol de rutas en el código de prerenderizado que hacía que esas páginas devolvieran 404 precisamente a los rastreadores, aunque funcionaban bien en el navegador.

En el segundo, al corregir el seguimiento de Google Analytics, el agente validó lo que podía validar (script cargando solo después del consentimiento, ID correcto, evento disparándose en cada cambio de página) y dejó por escrito lo que no podía: la petición final a Google no era observable en el entorno de pruebas, y la confirmación real dependía del informe en tiempo real de GA4 tras el despliegue. Lo comprobó una persona. Es el comportamiento que se quiere de un agente: decir dónde termina su propia verificación.

Lo que todavía no ha cambiado

La arquitectura sigue siendo humana. El agente ejecuta bien dentro de una estructura definida. Elegir las abstracciones, aceptar los compromisos y rechazar una dependencia sigue siendo trabajo de quien responderá por ello dentro de dos años. Un agente rápido sobre una mala arquitectura solo produce deuda técnica más deprisa.

La revisión sigue siendo obligatoria. Que funcione no significa que esté bien. Reglas de negocio sutiles, casos límite y efectos secundarios en otra parte del sistema pasan el build y las pruebas sin avisar.

Instruir bien es una habilidad. Quien pide "haz esto" obtiene un resultado mediocre. Quien pide "haz esto, siguiendo este patrón, sin tocar ese módulo, y ejecuta estas pruebas al final" obtiene otro nivel. Es una competencia nueva, y no es trivial.

Datos, privacidad y código de clientes

Para las empresas que manejan código de clientes o datos personales, la pregunta de seguridad va antes que la de productividad. Según la documentación de Anthropic, en los planes comerciales (Team, Enterprise y API) Anthropic no entrena modelos con el código ni con los prompts enviados a través de Claude Code, y la retención estándar es de 30 días. En los planes individuales, el uso para entrenamiento depende de una configuración que controla el propio usuario (Claude Code Docs). La herramienta también puede funcionar a través de Amazon Bedrock o Google Cloud, lo que facilita las cosas a quien ya tiene contratos y controles con esos proveedores.

La consecuencia práctica es directa: el código de clientes, los datos personales y los secretos comerciales no deben pasar por la cuenta personal de un desarrollador. Y si el repositorio contiene datos personales reales en archivos de prueba, están sujetos a la normativa de protección de datos, como el RGPD o la LGPD brasileña, igual que cualquier otro tratamiento.

Cómo introducirlo en el equipo

  1. Empiece con cuentas corporativas y una política de una página sobre lo que puede y no puede entrar en una sesión.
  2. Escriba un CLAUDE.md por repositorio, con los comandos de build y pruebas, las convenciones y las áreas que el agente no debe tocar.
  3. Use hooks y permisos para lo que de verdad deba bloquearse, como comandos destructivos o la lectura de archivos de credenciales.
  4. Mantenga la revisión de código obligatoria para todo lo que produzca el agente, con el mismo criterio que un pull request humano.
  5. Mida antes y después con métricas de entrega, como el tiempo de ciclo y la tasa de fallos en cambios, no con la sensación del equipo.
  6. Elija un tipo de tarea para empezar, como migraciones o pruebas, y amplíe a partir de lo que funcione.

Lo que se está automatizando no es ser desarrollador. Es la parte del trabajo que menos lo necesitaba: convertir una especificación clara en código previsible. Gana valor lo contrario: hacer las preguntas correctas antes de la primera línea y juzgar la calidad, no solo si funciona.

Si su empresa quiere adoptar agentes de programación sin renunciar al control, Advisor As a Service es el formato en el que acompañamos a equipos técnicos en estas decisiones semana a semana. Para formar al equipo, consulte nuestros programas de formación.

Escríbanos por WhatsApp contándonos cuál. En la conversación le mostramos si la IA lo resuelve, cuánto cuesta validarlo y en cuánto tiempo verá resultados.

Hablar por WhatsApp