Claude Code se rompió con las actualizaciones de febrero — y yo también lo sentí

¿Cuándo fue la última vez que escribiste un componente complejo de cero, sin que una IA te sugiriera la estructura? Hacé memoria. Yo lo intenté la semana pasada y tardé el doble de lo normal. No porque hubiera olvidado cómo hacerlo — sino porque mi cerebro buscaba el autocompletado que no llegaba.

Eso me asustó más que cualquier bug en producción.

Todo empezó con un thread en Hacker News. 702 puntos, que en HN no es poco. El título era algo así como "Claude Code has gotten significantly worse" y los comentarios eran un desfile de desarrolladores diciendo exactamente lo que yo había estado sintiendo pero no me había animado a articular: la herramienta que habían integrado en su flujo de trabajo en diciembre empezó a comportarse raro en febrero. Respuestas más genéricas. Menos contexto retenido. Código que antes generaba casi perfecto ahora llegaba con errores obvios que antes nunca aparecían.

Yo lo había notado. Y había hecho lo más humano posible: lo ignoré y seguí adelante.

Claude Code updates febrero 2025: qué cambió (y qué se rompió)

Antes de entrar en lo emocional, vamos a lo técnico. Porque hubo cambios reales.

La percepción general del thread — y la mía propia — es que Anthropic hizo ajustes en el modelo entre enero y febrero que afectaron el comportamiento en tareas de ingeniería complejas. No hay changelog público detallado (gracias, Anthropic), pero los patrones que reporta la comunidad son consistentes:

Lo que dejó de funcionar bien:

• Contexto de proyectos grandes: en repos con más de 50 archivos, empezó a perder el hilo de dependencias entre módulos
• Refactoring incremental: antes podías decirle "refactorizá este hook manteniendo la interfaz" y lo hacía perfecto; ahora a veces rompe contratos de tipos sin avisar
• Debugging con stack traces complejos: se volvió más genérico, menos quirúrgico
• Consistencia de estilo: en sesiones largas empezaba a mezclar patterns distintos en el mismo archivo

Lo que siguió funcionando (o mejoró):

• Tareas de escritura y documentación
• Preguntas de arquitectura de alto nivel
• Generación de tests unitarios simples
• Explicar código ajeno

En mi caso concreto, lo sentí más en el trabajo de performance y optimización que venía haciendo en proyectos Next.js. Le pedía análisis de bundle, sugerencias de lazy loading, identificación de re-renders innecesarios. Antes llegaba con análisis precisos y código funcional. En febrero empezó a darme respuestas correctas pero... vacías. Como cuando le preguntás a alguien algo y te contesta bien pero notás que no lo pensó.

// Lo que le pedía en enero — llegaba bien:
// "Analizá este componente y decime qué está causando re-renders innecesarios"

const MiComponente = ({ data, onUpdate }: Props) => {
  // Claude identificaba que esta función se recreaba en cada render
  // y sugería useCallback con las dependencias correctas
  const handleClick = () => onUpdate(data.id)
  
  return <Button onClick={handleClick}>Actualizar</Button>
}

// Lo que empezó a pasar en febrero:
// Misma pregunta → respuesta genérica sobre "usar useCallback y useMemo"
// Sin analizar el código específico. Sin ver que onUpdate ya era estable.
// Solución correcta en abstracto, incorrecta en contexto.

Esa diferencia parece pequeña. No lo es. La mitad del valor de una IA en el flujo de desarrollo está en que entiende TU contexto, no en que sabe los conceptos generales. Los conceptos generales ya los sé yo.

La pregunta que no quería hacerme

Acá es donde el post se pone incómodo. Para mí, no para vos.

Cuando Claude Code empezó a fallar, mi primer instinto fue frustración con la herramienta. Busqué el thread de HN para validar que no era yo. Encontré 702 personas diciéndome que tenía razón. Me sentí mejor.

Y después me cayó la ficha.

Había pasado los últimos dos meses construyendo juanchi.dev y varios proyectos paralelos con Claude Code como co-piloto permanente. No solo para boilerplate — eso es lo que todos admiten. Lo usaba para decisiones de arquitectura. Para elegir entre patterns. Para debuggear lógica compleja. Para validar si mi approach tenía sentido.

La pregunta que no quería hacerme: ¿estaba yo escribiendo código, o estaba aprobando código ajeno?

No es lo mismo. Y la diferencia importa.

Cursé Ciencias de la Computación en la UBA mientras laburaba full time. Había materias donde llegaba directo del trabajo con el traje puesto. Aprobé Análisis II en el cuarto intento. Eso me dio algo que no se consigue fácil: la capacidad de sostener un problema difícil en la cabeza el tiempo suficiente como para realmente entenderlo. No para googlear la solución. Para entenderlo.

Y en algún momento de los últimos meses, sin que me diera cuenta, había empezado a cortocircuitar ese proceso. Le llevaba el problema a Claude Code antes de haberlo pensado yo solo el tiempo suficiente. El resultado era más rápido. Y más superficial.

// Patrón que empecé a detectar en mi propio código de febrero:
// Código que "funciona" pero que yo no podría explicar completamente
// si alguien me preguntara en una code review por qué hice ESTO
// y no AQUELLO.

// Ejemplo anónimo — no es de un proyecto real pero representa el pattern:
const useDataSync = <T extends Record<string, unknown>>(
  // ¿Por qué este constraint específico? Claude lo sugirió.
  // ¿Tiene sentido? Sí. ¿Lo hubiera elegido yo? No sé.
  key: string,
  fetcher: () => Promise<T>,
  options?: SyncOptions
) => {
  // Lógica que funciona.
  // Que entiendo si la leo.
  // Que no estoy seguro de haber *diseñado*.
}

Hay una diferencia entre entender código y haberlo diseñado. La segunda te da intuición. La primera, solo comprensión.

Los errores que cometí (y que probablemente estés cometiendo)

Sin juzgar — porque yo caí en todos estos:

1. Usar la IA antes de pensar, no después El flujo correcto: pensás el problema, tenés una hipótesis, usás la IA para validarla o explorar alternativas. El flujo que adopté sin querer: abrís Claude Code y describís el problema esperando que te dé la dirección. El segundo es más rápido a corto plazo y más caro a largo plazo.

2. No cuestionar el código generado con suficiente rigor Cuando el código funciona, el incentivo para entender por qué funciona desaparece. En el stack que uso hoy — Next.js, TypeScript, PostgreSQL — hay suficiente complejidad como para que esto te pase factura eventualmente.

3. Confundir velocidad con productividad Sí, estaba shipeando más rápido. ¿Pero cuánta deuda técnica invisible estaba acumulando? ¿Cuántas decisiones de arquitectura había delegado sin registrarlas mentalmente?

4. No mantener el músculo Este es el más jodido. Las habilidades técnicas son literalmente musculares — si no las ejercitás, se atrofian. Yo vengo de 30 años con la tecnología, diagnostiqué cortes de red en un cyber a las 11pm, tiré un servidor de producción con rm -rf en mi primera semana de trabajo. Ese background me da criterio. Pero el criterio también se oxida.

5. Olvidar que la IA optimiza para coherencia local, no para arquitectura global Este es el error técnico más concreto. Claude Code es muy bueno generando código que es localmente correcto. Es menos bueno manteniendo consistencia arquitectural a través de un proyecto grande. Eso requiere que vos tengas el mapa mental del sistema completo. Si terciarizás ese mapa, perdés el timón.

FAQ: Claude Code, las actualizaciones de febrero y el elefante en el cuarto

¿Claude Code realmente se deterioró en febrero 2025 o es percepción? Es una pregunta legítima y honesta. Anthropic no publicó un changelog detallado de los cambios al modelo. Lo que existe es evidencia anecdótica consistente de muchos desarrolladores — el thread de HN con 702 puntos es la punta del iceberg. Mi experiencia personal coincide con los patrones reportados: degradación en tareas complejas de ingeniería, no en tareas simples. ¿Podría ser placebo colectivo? En teoría sí. En práctica, cuando 700 personas describen el mismo patrón específico, algo pasó.

¿Sigue valiendo la pena usar Claude Code después de esto? Sí, con ajustes. El deterioro es real pero parcial — sigue siendo muy útil para ciertas tareas. La clave es ser más intencional sobre cuándo lo usás y para qué. Yo volví a usarlo, pero cambié el workflow: primero pienso yo, después lo consulto. Antes era al revés.

¿Cómo sé si estoy dependiendo demasiado de la IA en mi trabajo? Hacé este test: tomá un problema de complejidad media de tu trabajo actual e intentá resolverlo sin ninguna IA, en el tiempo que normalmente te llevaría. Si tardás mucho más o te sentís perdido, es una señal. Otro indicador: ¿podés explicar todas las decisiones de diseño del código que mandaste a producción en el último mes? ¿O hay partes donde dirías "Claude lo sugirió y funcionó"?

¿Esto aplica solo a Claude Code o a GitHub Copilot y otros también? Aplica a todos, pero el vector de riesgo varía. Copilot tiene más presencia en el autocompletado granular — el riesgo es más sobre patrones micro. Claude Code (y similar: ChatGPT en modo coding, Cursor) tiene más presencia en decisiones de arquitectura y lógica compleja — el riesgo es más sobre el diseño macro del sistema. Los dos son reales, los dos requieren atención.

¿Debería dejar de usar IA para programar? No. Esa conclusión sería tan incorrecta como la dependencia total. La IA es una herramienta genuinamente poderosa — el trabajo de TypeScript con patterns avanzados que hago sería más lento sin ella. La pregunta no es si usarla, sino cómo mantener tu propio criterio técnico activo mientras la usás. Es la misma tensión que existe con Stack Overflow desde hace 15 años, pero amplificada por un orden de magnitud.

¿Las actualizaciones de Anthropic van a mejorar esto? Probablemente sí, para el deterioro específico de febrero. Anthropic itera rápido. Pero el problema estructural que describe esta reflexión — la dependencia cognitiva — no lo resuelve ninguna actualización del modelo. Ese es tu problema, no el de ellos.

Conclusión: el deterioro de la herramienta como servicio

Cuando Claude Code empezó a fallar, la reacción sana hubiera sido usarlo menos y pensar más. Mi reacción inicial fue buscar validación en HN y esperar que Anthropic lo arreglara.

Lo segundo va a pasar. Lo primero dependía de mí.

Lo que me llevo de este episodio es una regla nueva en mi workflow: la IA entra al proceso después de que yo tengo una hipótesis propia, no antes. No es una regla anti-IA — es una regla pro-criterio. El valor que le aporto a los proyectos que construyo no es solo que sé usar las herramientas. Es que tengo 30 años de intuición técnica acumulada sobre qué funciona y qué explota a las 11pm con el local lleno.

Esa intuición no se delega. Se ejerce.

Y sí — cuando Anthropic arregle el modelo y Claude Code vuelva a estar en su mejor forma, voy a seguir usándolo. Pero con el músculo propio un poco más activo que antes.

El deterioro de febrero me hizo un favor que no pedí.