¿Cuánto cuesta de verdad construir una funcionalidad?

Una funcionalidad construida de dos maneras es una anécdota con recibos. Eso vale algo, y vale menos que una tasa. Los límites publicados están en la página porque los acabarías descubriendo de todos modos.

1. 01

   n = 1.

   Una funcionalidad. Una demostración, nunca una tasa. Poco favorable, mixta o fallida en cualquiera de los dos brazos: se publica tal cual.

2. 02

   El control no es reproducible.

   Una persona que dirige Claude Code varía de una ejecución a la siguiente. Congelamos el prompt y la configuración de subagentes por escrito y publicamos la transcripción, lo cual lo reduce. No lo cierra.

3. 03

   Elegimos la tarea nosotros mismos, y la regla se enmendó cuatro veces.

   Quien elige la tarea elige al ganador, y aquí quien elige somos nosotros. La regla se publicó antes de listar cualquier candidato, y su primera aplicación devolvió un conjunto vacío. Luego se eliminó en público una cláusula, la que excluía las incidencias abiertas por nuestro propio equipo, y la regla se aplicó de nuevo a ocho candidatos: todos se descartaron por no cambiar el Ruby propio de este repositorio. El plan alternativo, nombrado de antemano, era que un tercero presentara la tarea, y no hubo ningún tercero disponible. Así que la regla se enmendó una vez más, en público y antes de que existiera la incidencia, para decir que la presenta el equipo que dirige el estudio. Eso es lo que pasó. La objeción más fuerte a esta comparación, que la tarea favorece a nuestro propio brazo, ya no tiene respuesta salvo dos comprobaciones: la enmienda se publica antes de que exista la incidencia, y la tarea sale de una carencia que este repositorio ya documentaba sobre sí mismo. El cuerpo de la incidencia sigue sin editar y cada versión de la regla es pública en orden de publicación.

4. 04

   Los dos brazos son nuestros.

   Las personas que construyeron el brazo B son las que dirigen el brazo A, el control contra el que competimos. Una ejecución independiente valdría más que la nuestra, y preferimos decirlo a insinuar lo contrario.

5. 05

   El tiempo de calendario no es esfuerzo.

   Nuestro reloj incluye el tiempo en cola que de verdad esperarías. El reloj del control es la atención ininterrumpida de una persona. Ese encuadre favorece al control, no a nosotros.

6. 06

   El revisor es uno de los nuestros.

   Un revisor, de nuestro equipo. Es quien dirige el brazo de control, así que reconoce su propio diff antes de abrir ninguno de los dos. Los dos diffs llegan sin nombres de rama y sin autoría en los commits, y eso es todo lo que significa aquí la palabra ciego. Un revisor externo eliminaría este límite en vez de suavizarlo; no lo tenemos.

7. 07

   Mantenemos el repositorio de la prueba.

   Los dos brazos se ejecutan en un repositorio público que mantenemos nosotros: nuestra organización, nuestra CI y nuestro bot en la vía de merge. Un repositorio ajeno cerraría este límite. Lo que haría falta es un mantenedor que no seamos nosotros dispuesto a dejar que los dos brazos abran pull requests, pasen su CI y fusionen, y no lo tenemos.

8. 08

   El modelo congelado cambia dos veces y luego vuelve.

   Tres comentarios fechados en el pre-registro lo cambian y luego lo restauran. Los dos primeros parten de una lectura equivocada: todas las credenciales de la cuenta para ese modelo están revocadas, lo cual es cierto y no viene al caso, porque el carril de código corre sobre el backend propio de la máquina y la sede sigue sirviendo ese modelo todo el tiempo. Cada versión es pública y fechada antes de que arranque cualquier brazo, sin ningún resultado en contra, así que ninguna cifra de aquí es una vista primero y elegida después. El modelo es idéntico en ambos lados, así que cambia lo que cada uno ejecuta y nunca lo que los distingue, y la regla 6 sigue prohibiendo repetir la tirada. Lea el hilo en orden de publicación y juzgue usted con cuánto cuidado se operó esto.

9. 09

   La predicción conoce la tarea, solo no la respuesta.

   Publicamos lo que esperamos que muestren los registros antes de que corra ningún brazo, para que una página que enseña sus cifras solo después no pueda pedirle que crea que esas cifras no sorprendieron a nadie. Está protegida frente a conocer el resultado. No lo está frente a conocer la tarea, porque la regla de selección nombra primero la función, y esa asimetría es la razón de llamarla predicción y nunca pre-registro. Ninguna regla fija el conjunto después de los hechos: la regla 6 prohíbe repetir la tirada de la función, no reescribir una predicción, así que la protección es la propia publicación: las predicciones y sus reglas de puntuación son comentarios públicos fechados en una incidencia cuyo historial de ediciones está abierto, publicados antes de que exista cualquier registro, y toda revisión aparece allí como revisión. Una predicción que caiga lejos del registro permanece en la página junto al registro que la rompe. Una cosa queda fuera a propósito: qué pull request prefiere el revisor, porque es el único juicio de aquí sin instrumento detrás.