Las ideas zanjadas tienen fecha de caducidad

Git era la idea más zanjada del software. Veintiún años, tan dominante que "git" y "control de versiones" se volvieron sinónimos, cosido dentro de cada sistema de CI, cada IDE y la memoria muscular de cualquier desarrollador en activo. Y entonces, en cuatro meses, dejó de ser la respuesta correcta dentro de Anthropic: no porque estuviera equivocado, sino porque la única condición alrededor de la cual fue diseñado se multiplicó por doce. Esa es la forma que de verdad tiene la obsolescencia. No llega a las cosas que están rotas. Llega a las cosas que todavía funcionan.

Lo que se rompió no estaba roto

Git no falló. Hizo exactamente aquello para lo que fue construido: darle a cada cliente una copia completa y offline del historial, para que un grupo distribuido de personas con conexiones poco confiables pudiera trabajar de forma independiente. Ese diseño era correcto en 2005 y sigue siendo correcto para casi todos los que leen esto.

Lo que cambió es que los clientes de Anthropic dejaron de ser personas. La mayoría pasó a ser jobs de CI y agentes de código: siempre conectados, sin necesitar una copia local de nada. Los merges diarios pasaron de 2.500 a más de 30.000 entre mayo y septiembre de 2026. La premisa que está debajo de git — que el recurso caro y escaso es la conectividad, y el barato y abundante es el disco local y la paciencia humana — simplemente se invirtió. El detalle de ingeniería es una historia aparte; lo que importa aquí es el mecanismo.

Toda idea zanjada es una apuesta sobre una condición. Git apostó a clientes offline-first. La apuesta pagó durante dos décadas. Nadie notó que era una apuesta, porque cuando una apuesta sigue pagando deja de parecer una apuesta y empieza a parecer una ley.

La obsolescencia no se anuncia

Esta es la parte difícil de ver venir. Algo que falla se anuncia: se cae, cuesta dinero, la gente se queja. Algo obsoleto se comporta perfectamente y en silencio se convierte en el techo.

La merge queue de Anthropic no estaba rota. Funcionaba precisamente como se diseñó, serializando cada cambio para que cada uno se probara contra el estado exacto en el que iba a caer. Eso es una best practice de verdad. Y con 30.000 merges al día se convirtió en lo único que limitaba el throughput de toda la organización de ingeniería, por más rápido que se volviera todo lo anterior.

Así que la señal a vigilar no es el fallo. Es esta: aquello en lo que más confías se convirtió en aquello que estás esperando. Cuando tu proceso más maduro es también tu fila más larga, lo que tienes delante no es un problema de ejecución. Es una premisa vencida.

Separa la necesidad de la implementación

Esta es la distinción que casi toda esta conversación aplasta, y en las dos direcciones.

La necesidad que git atiende es permanente: saber quién cambió qué y poder volver atrás. Esa necesidad no se va a ninguna parte, nunca. La implementación — clones locales completos, offline-first, un packfile en cada laptop — siempre fue condicional. Anthropic conservó la necesidad y tiró la implementación.

Casi todo argumento sobre lo que la IA le está haciendo al trabajo invierte esto. El pánico trata una implementación condicional como si fuera la necesidad ("si nadie escribe el código, la ingeniería se acabó"). La negación hace lo mismo desde el otro lado ("el code review siempre funcionó, así que siempre funcionará"). Las dos defienden una implementación y la llaman principio.

Mira lo que esa distinción le hace a las cosas sobre las que está construida nuestra vida laboral:

La columna de la izquierda está a salvo. La de la derecha es un conjunto de proxies inventados porque la columna de la izquierda era difícil de observar directamente. El currículum existe porque tu trabajo real era invisible para un extraño. Los años de experiencia existen porque el juicio se acumula despacio y no se puede inspeccionar. El headcount como capacidad existe porque la entrega era más o menos proporcional a las personas.

Cada uno de esos proxies fue una apuesta razonable sobre una condición. Varias de esas condiciones se están moviendo ahora, y los proxies no se mueven con ellas.

Tres preguntas que separan lo durable de lo vencido

No todo lo zanjado está venciendo, y eso importa: la mayoría de las cosas durables son durables por buenas razones. Git se ganó veintiún años honestamente. Así que esto es una prueba, no una profecía. Para cualquier cosa de la que dependas:

1. ¿Todavía puedes nombrar la condición para la que fue diseñada? Si no puedes — si la respuesta es "así se hace" — no estás siguiendo un principio, estás manteniendo un fósil. La incapacidad de enunciar el trade-off original es la señal más clara.
2. ¿Esa condición se movió, y en qué dirección? La dirección importa más que la magnitud. Los cambios reversibles son ruido. Los de una sola vía — el costo de generar código, el costo de almacenar datos, el costo de abrir una empresa — son los que retiran ideas.
3. ¿Todavía te habilita o ya te limita? Habilitar es que avanzas más rápido por su causa. Limitar es que estás esperando por ella. La transición entre esos dos estados es exactamente donde vive la obsolescencia, y nada se cae para marcar el momento.

Aplica esas tres a una merge queue en un repo lleno de agentes y la respuesta es obvia. Aplícalas a un proceso de contratación que filtra a quien escribe código rápido y la respuesta también es obvia: solo es menos cómoda.

Cómo se ve esto cuando es tu carrera

La versión honesta de este argumento no es "todo lo que sabes no vale nada". Es más estrecha y más útil: el concepto sobre el que construiste tu identidad probablemente era un proxy, y los proxies vencen más rápido que las necesidades.

"Soy ingeniero de backend" es una identidad construida sobre una tarea. "Sé qué se va a romper a las 3 de la mañana y noto cuándo un diseño está mintiendo" es una identidad construida sobre una capacidad. La primera es un proxy de la segunda, y fue un proxy decente durante veinte años. Cada trimestre es un proxy peor.

La evidencia más clara que hemos visto es el propio relato de Anthropic sobre el equipo de Scion. Todos los ingenieros del equipo dirían hoy que Claude escribe mejor código que ellos. Su valor estaba en el juicio de diseño, en entender cómo interactúan los sistemas y — en sus palabras — en decirle "no" al modelo cuando violaba una restricción. Eso no es ingenieros vueltos redundantes por una herramienta. Es la misma necesidad atendida por una implementación radicalmente distinta, y el cargo en la credencial no cambió para reflejarlo.

Por eso organizamos nuestra práctica alrededor de capacidades y no de asientos, y por eso "construimos productos construyendo personas" es una afirmación sobre durabilidad, no sobre sentimiento. Escribimos sobre el reacomodo específico de los roles de producto en quién lleva a producción cuando prototipar es gratis. Esto es la capa de abajo: los roles también son implementaciones.

Qué no concluir

Tres barandas, porque este argumento es fácil de aplicar en exceso:

• La mayoría de las cosas zanjadas están bien. La prueba de arriba va a devolver "durable" muchas más veces que "vencido". La partida doble tiene quinientos años y no se va a ninguna parte. La edad no es evidencia de obsolescencia.
• Estar adelantado es indistinguible de estar equivocado, por un rato. Anthropic reemplazó git porque ya había chocado con el muro, no porque predijera uno. Retirar una práctica que funciona antes de que la condición se mueva de verdad es solo agitación con mejor vocabulario.
• La necesidad es tu ancla. Cuando retires una implementación, nombra la necesidad que atendía y reemplázala a propósito. Anthropic abandonó la merge queue y puso resolución automática de conflictos y pruebas posteriores al merge en su lugar. No abandonó la necesidad de una rama principal confiable.

Conclusiones clave

• La obsolescencia llega a las cosas que todavía funcionan. Un proceso que falla se anuncia; uno vencido funciona perfectamente y en silencio se vuelve tu techo.
• Toda idea zanjada es una apuesta sobre una condición. Cuando la apuesta sigue pagando, la gente deja de verla como apuesta y la trata como ley.
• Separa la necesidad permanente de la implementación condicional. Casi todo argumento sobre IA y trabajo defiende una implementación llamándola principio.
• Las cosas sobre las que están construidas nuestras carreras — cargos, currículums, años de experiencia, headcount como capacidad — son proxies inventados porque lo real era difícil de observar. Los proxies vencen más rápido que las necesidades.
• Prueba lo que usas con tres preguntas: ¿puedes nombrar la condición que asumía?, ¿esa condición se movió en una sola dirección?, ¿hoy te habilita o te limita?
• La edad no es evidencia de obsolescencia, y retirar una práctica antes de que su condición se mueva es solo agitación.

Preguntas frecuentes

¿Qué tiene que ver que Anthropic reemplace git con algo fuera de la ingeniería?

El mecanismo, no el tema. Git era la herramienta más zanjada del software y fue retirada dentro de una organización en cuatro meses: no por ser mala, sino porque una única condición que asumía se multiplicó por doce. Cualquier idea de la que dependas se apoya en una condición parecida. La lección es saber cuál.

¿Cómo distingo una práctica obsoleta de una durable?

Pregunta si todavía puedes nombrar la condición para la que fue diseñada, si esa condición se movió en una sola dirección y si hoy te hace más rápido o te hace esperar. Las prácticas durables sobreviven a las tres preguntas. Los fósiles caen en la primera.

¿Esto significa que los cargos y los títulos ya no valen nada?

No. Significa que son proxies, no necesidades. La necesidad que atienden — demostrar que eres confiable para un trabajo con consecuencias — es permanente. El proxy se inventó porque eso era difícil de observar directamente, y se degrada a medida que el trabajo de abajo cambia de forma. Construye la capacidad; trata la credencial como un recibo, no como el activo.

¿No es esto solo decir que todo está cambiando?

Es lo contrario. La mayoría de las cosas zanjadas lo están por buenas razones, y la prueba de arriba normalmente te dirá que las dejes en paz. El punto es que "funciona desde hace mucho" no es un argumento, y la incomodidad de examinarlo no es prueba de que esté en pie.

¿Qué es lo primero que hay que examinar?

Aquello en lo que más confías y que además tiene una fila delante. Confianza más fila de espera es la firma de una premisa que venció mientras nadie miraba.