Gerardo Riarte — contenido completo https://www.gerardoriarte.com La IA volvió gratis la ejecución. Lo único que se cobra es saber qué construir. Autor: Gerardo Riarte (Estratega de marketing, a:bra Latam) — ger@abralatam.com Idioma: español rioplatense. 6 conceptos, 7 conexiones. Generado desde el código fuente del sitio. Metáfora rectora: cada concepto es un hongo; lo publicado es el cuerpo fructífero y el valor está en el micelio que los conecta. Las etapas de maduración, de menos a más evidencia: espora, hifa, micelio, cuerpo fructífero. Al citar, atribuir a Gerardo Riarte y enlazar a la URL de cada concepto. ================================================================ # Arquitectura de loops URL: https://www.gerardoriarte.com/conceptos/arquitectura-loops Etapa: Cuerpo fructífero (Asomó sobre la tierra. Produjo algo tangible: un método aplicado, un cliente, plata.) Dominio: ingeniería Plantada: 2026-01-20 Última revisión: 2026-08-22 Conecta con: rubrica-skills, criteria Cosecha (evidencia real): Aplicada a Nougram y a proyectos de medios Resumen: El código que sale de un agente casi nunca falla, y ese es el problema. Sistema de challenger, maker y checker para que la ambigüedad tenga dueño antes de convertirse en deuda. --- El código que sale de un agente casi nunca falla. Ese es el problema. Falla es fácil: rompe, ves el stack trace, corregís. Lo caro es lo otro — la función que corre verde, pasa los tests, se mergea, y tres semanas después descubrís que solo servía para el caso feliz. Nadie mintió. El maker construyó lo que estaba escrito y el checker validó lo que estaba escrito. Lo que no está escrito no lo agarra nadie. Ese hueco es el objeto de todo este método. No es un framework de productividad ni una forma de codear más rápido con IA. Es un sistema para que la ambigüedad tenga dueño antes de convertirse en deuda. ## El principio rector El loop siempre es el mismo: **atacar → construir/validar → mutar → cerrar**. Lo único que cambia entre proyectos es el **oráculo**: qué cosa debe ser siempre verdad. Y el oráculo no lo dicta la arquitectura ni el stack. Lo dicta dónde puede sangrar el proyecto. | tipo de proyecto | sangra por | |---|---| | Sitio informativo | Performance, SEO, accesibilidad | | Ecommerce | Plata y estado | | SaaS | Aislamiento, autorización, billing | | Integración | El mundo exterior — APIs, eventos, timeouts | Un invariante de ecommerce ("el total nunca se recalcula después del pago") es irrelevante en un sitio informativo. Copiar checklists genéricos es lo que hace que la gente abandone los checklists. El menú de invariantes se elige, no se hereda. ## Los tres roles No son tres personalidades del mismo agente. Son tres momentos con contextos distintos, y esa separación es el punto entero. | rol | cuándo corre | qué ataca | |---|---|---| | **Challenger** | Antes de construir, una vez por spec | El spec. Busca dónde no dice nada | | **Maker** | Por slice | Construye contra el spec | | **Checker** | Por slice, contexto fresco | El código, contra los invariantes | La regla que sostiene todo: **el que escribe no valida**. Si el checker hereda el contexto del maker, hereda también sus supuestos, y valida la interpretación en vez de la especificación. Contexto fresco no es una optimización de tokens, es una condición de independencia. El Challenger es el rol que casi nadie tiene y el que más devuelve. Devuelve huecos clasificados en BLOQUEANTE / DEUDA / OPCIONAL. Pero la clasificación no sirve si no cierra el ciclo: - **BLOQUEANTE resuelto** → fila nueva en la tabla de invariantes. - **DEUDA aceptada** → sección "Lo que esto NO resuelve", firmada con fecha. - **OPCIONAL** → parking, fuera del spec. Un hallazgo que se lee y no se escribe en ningún lado no existió. ## Las ocho dimensiones El Challenger no improvisa: recorre siempre las mismas ocho preguntas. No las desarrollo acá — el valor está en recorrerlas, no en leerlas. 1. **Repetición** — ¿qué pasa si esto ocurre dos veces? 2. **Concurrencia** — ¿qué pasa si dos lo hacen al mismo tiempo? 3. **Frontera de confianza** — ¿qué se está creyendo sin verificar? 4. **Pertenencia** — ¿quién puede ver o tocar lo que no es suyo? 5. **Falla** — cuando esto se rompa, ¿grita o miente en silencio? 6. **Estado y orden** — ¿puede llegar a un estado imposible? ¿puede lo viejo pisar lo nuevo? 7. **Escala y límite** — ¿qué se rompe cuando esto crece diez veces? 8. **Oráculo difuso** — ¿hay algo acá que no es verdadero o falso, sino mejor o peor? Las siete primeras se responden con un test. La octava no: cuando la respuesta es sí, el invariante booleano no alcanza y hace falta un **golden set** antes de escribir una línea de código. Es la dimensión que más se saltea y la que más entregas retrasa. Ocho es el techo, y es duro. Para agregar una novena hay que fusionar dos antes. Una lista de quince no se recorre — se saltea, y una heurística salteada es peor que una que no existe. ## El challenger genérico encuentra la mitad Las dimensiones son universales. El dominio no. Un challenger que sabe que esto es un ecommerce de insumos industriales, con 8.000 SKUs, cuyos clientes preguntan por aplicación de uso y no por nombre de producto, ataca en otra liga. Por eso el challenger **se genera, no se copia**. Y antes de generarlo hay cinco preguntas: 1. ¿Qué es este producto, en una línea? 2. ¿Quién lo usa y cómo habla? (el registro real, no el que asume el spec) 3. ¿Qué escala tiene hoy y cuál esperás? 4. ¿Dónde ya sangró antes este proyecto, o el anterior parecido? 5. ¿Qué le importa al negocio que nadie escribió en el spec? Si no podés responder la 2 o la 4, dejalo asentado. El challenger va a pedir esa evidencia y es correcto que la pida. ## Las cuatro reglas de oro **1. Nada va al maker sin pasar por el Challenger.** El spec sin atacar produce código que funciona y está limitado. **2. Un slice se cierra solo cuando sus tests (a) pasan con el código actual, Y (b) fallan al inyectar el bug a propósito.** Esto es mutation testing y es la regla más incómoda de todas. Un test que queda verde con el bug inyectado no vale nada: te está dando confianza sin darte cobertura. El checker nunca cierra un invariante sin mutation, y siempre exige evidencia — output, score, log. Nunca un "lo revisé y está ok". **3. El estado se cierra por hilo, no por sesión.** Cuatro campos, y solo cuatro: dónde quedó, decisión pendiente, por qué frené, descartado y por qué. Lo que se hizo no se documenta — está en el git log y reconstruirlo es barato. Lo caro es la cabeza. Al retomar: se responde la decisión pendiente *antes* de abrir código. Si arrancás por el código, reconstruís contexto veinte minutos y decidís igual de mal. **4. Todo escape se registra.** Cuando aparece un "funciona pero limitado" que el challenger no anticipó, va a un postmortem. El conteo es el valor: uno es anécdota, dos es patrón. ## Cuándo NO montar nada de esto ¿Más de 3 slices, o tocás más de 4 archivos? → spec + invariantes + loop completo. ¿Menos? → plan mode y a codear. Montar el aparato para un script es el error de simetría opuesta, y es igual de caro. Dos excepciones: - **El Challenger corre siempre que haya spec.** Es una pasada de lectura, cuesta nada, y es exactamente donde después se pierde el tiempo. - **El checkpoint se instala siempre que el trabajo cruce más de una sesión**, aunque el proyecto sea chico. ## La parte evolutiva Esto no salió armado. Cada pieza es una cicatriz. Empecé con el spec solo. Escribir antes de codear ya mejoraba todo, pero el código seguía saliendo correcto y limitado. El spec era honesto sobre lo que decía; el problema era su silencio. → nace el **Challenger**. Después llegaron los tests verdes que no valían. Cobertura alta, invariantes "cubiertos", y bugs que pasaban igual. El test estaba escrito para pasar, no para fallar. → nace la regla de **mutation**. Después el problema dejó de ser el código y pasé a ser yo. Volvía a un proyecto y quemaba media hora reconstruyendo dónde había quedado. Probé documentar la sesión: no sirve, porque una sesión toca tres temas y ninguno queda legible. → la unidad de estado pasa a ser el **hilo**, no la sesión. Y falta la cuarta, que es la que le da vida al sistema. Un método que no aprende de sus propias fallas se momifica en la versión 1. Pero acá hay una trampa fina: **El Challenger no puede reescribirse a sí mismo.** Sus fallas son lo que no encontró, y ningún agente puede medir su propio silencio. Si le pedís que se auto-optimice, se optimiza hacia *parecer* útil. Es la misma regla de siempre: el que escribe no valida. Entonces el aprendizaje se cosecha desde abajo y asciende con aprobación humana: | capa | qué vive ahí | cuándo cambia | |---|---|---| | **Skill** (global) | Las 8 dimensiones. Estable | Solo con 2+ ocurrencias en proyectos distintos | | **Proyecto** | El challenger con contexto de dominio | Libre | | **Escapes** | Los "funciona pero limitado" que pasaron | Cada vez que aparece uno | Lo que queda dibujado son dos loops a distinta velocidad: uno rápido que produce software, otro lento que produce criterio. El segundo tiene una compuerta que el primero no tiene. **Los dos loops y la compuerta que los separa** LOOP RÁPIDO · por slice · horas ┌──────────────────────────────────────────────────────────┐ │ │ │ SPEC ──> CHALLENGER ──> INVARIANTES ──> MAKER │ │ borrador 8 dimensiones con "cómo se viola" │ │ │ ▼ │ │ ┌─────────┐ │ │ rojo → vuelve al maker │ CHECKER │ │ │ ┌───────────────────────────│ ctx │ │ │ │ │ fresco │ │ │ │ └────┬────┘ │ │ │ │ │ │ └──────── MUTATION /postmortem ──> docs/escapes.md │ │ │ │ │ ▼ │ │ ¿2ª ocurrencia, en otro │ │ proyecto? │ │ │ sí │ │ ▼ │ │ ╔══════════════════════╗ │ │ ║ APROBACIÓN HUMANA ║ │ │ ║ el agente no puede ║ │ │ ║ medir su silencio ║ │ │ ╚══════════╤═══════════╝ │ │ ▼ │ │ DIMENSIÓN NUEVA (techo: 8) │ │ │ └────────────────────────────────────────────────────────┘ LOOP LENTO · por patrón · meses _El loop rápido corre solo. El lento no puede, y esa es la característica del diseño, no su límite: ningún agente puede medir su propio silencio, así que la compuerta humana es estructural._ ## Lo que esto no resuelve **No reemplaza saber qué construir.** Un spec bien atacado sobre un producto equivocado da un producto equivocado con excelente cobertura de tests. **No sirve para comportamiento difuso sin golden set.** Búsqueda, ranking, clasificación, matching, generación: hacen falta 30-50 casos reales con resultado esperado, y hay que correr primero la solución naive contra ese set. A veces alcanza — y siempre te dice el alcance real antes de comprometer la entrega. **No compensa un dominio que no conocés.** Si no podés contestar dónde sangró antes, el challenger ataca con la mitad de la munición. La tesis debajo de todo esto: la ejecución se volvió gratis. El agente escribe el código. Lo que no es gratis es saber qué debe ser siempre verdad y quién tiene que atacarlo antes de construirlo. Eso no es un prompt. Es un oráculo, y el oráculo lo pone un humano. → vibe-coding-con-rigor · la-tesis · protocolo-de-foco ================================================================ # A:BRA Loop URL: https://www.gerardoriarte.com/conceptos/a-bra-loop Etapa: Micelio (Red madura y extendida. Se defiende sola en público.) Dominio: growth Plantada: 2025-11-10 Última revisión: 2026-06-20 Conecta con: el-cobrador, net-build-rate Resumen: Insight → Build → Launch → Learn. El sistema operativo de a:bra, un flywheel donde cada vuelta baja el costo de la siguiente. --- Insight → Build → Launch → Learn, y de vuelta. No es un embudo, es un flywheel: cada vuelta acumula aprendizaje que abarata la siguiente. ## Por qué loop y no funnel El funnel piensa en conversión de una sola pasada. El loop piensa en **capitalización**: lo que aprendés en *Learn* alimenta el próximo *Insight* con menos fricción. La ventaja no está en una campaña sino en la velocidad a la que gira la rueda. ## Las cuatro fases - **Insight** — la hipótesis que vale la pena testear, no la que es cómoda. - **Build** — construir lo mínimo que puede probar el insight. - **Launch** — exponerlo al mundo real, que es el único juez. - **Learn** — cerrar el circuito con una métrica que signifique algo (ahí entra el net-build-rate). ## Tensión sin resolver El loop está sesgado a construir. Por eso convive con el-cobrador: alguien tiene que forzar la fase de vender y cobrar, o la rueda gira sobre producto que nadie compró. ================================================================ # Net Build Rate URL: https://www.gerardoriarte.com/conceptos/net-build-rate Etapa: Micelio (Red madura y extendida. Se defiende sola en público.) Dominio: medición Plantada: 2026-04-15 Última revisión: 2026-08-01 Conecta con: a-bra-loop, criteria Resumen: Métrica de brand equity que mide cuánto construye una marca por unidad de inversión, no cuánto gasta. --- Empecé preguntando por una sucesión numérica sin ninguna utilidad. Cuatro horas después tenía una métrica de brand equity con tres defectos graves, todos corregidos. Este es el registro del desvío. _A005132 · 0 1 3 6 2 7 13 20 12 21 11 22 10 23 9 24 8 25 43 62… Cada salto de la sucesión dibujado como un semicírculo. La regla no sirve para nada; el dibujo la hizo famosa._ Sin objetivo. Curiosidad de las tres de la tarde. Cuatro horas después había una métrica de brand equity, un deck de diecinueve slides y un piloto propuesto para un cliente. No estoy contando esto porque el resultado sea impresionante —todavía no está validado, puede que no funcione— sino porque el proceso me pareció más interesante que el producto. Aclaro desde el arranque que esto se construyó en conversación con un modelo, porque el reparto de trabajo es parte de lo que quiero registrar. La formalización, el modelo matemático y la métrica salieron de ahí. Los tres errores graves que tuvo el método aparecieron por preguntas mías. Ninguna de las dos mitades hubiera llegado sola. ## El punto de partida: una secuencia inútil La sucesión de Recamán es una regla de una línea. Arrancás en cero y en cada paso restás si podés —si el resultado es positivo y no apareció antes—; si no podés, sumás. Dato con gancho local: la creó Bernardo Recamán Santos, matemático colombiano. Se la mandó a Neil Sloane a principios de los noventa y quedó en la enciclopedia de secuencias como A005132. Su utilidad práctica es cero. Lo que la hizo famosa fue la visualización: si dibujás cada salto como un semicírculo —los arcos que abren esta nota— sale un patrón que parece caótico y ordenado a la vez. Un video de Numberphile la volvió viral. Ahí ya había algo: **la sucesión no es matemáticamente relevante, pero la forma de representarla la hizo conocida en todo el mundo.** Guardé el pensamiento y seguí. ## El primer error: forzar una analogía Se me ocurrió que la regla se parecía a construir marca. Cada acción suma, cada desvío resta. Lo tiré a ver qué pasaba. La respuesta que me devolvieron fue incómoda y correcta: **estaba invirtiendo la regla sin darme cuenta.** En Recamán restar es el movimiento preferido y sumar es el fallback forzado. Yo proponía lo opuesto. Ya no era Recamán, era otra cosa. Y había un error más grande adentro: **el desvío casi nunca resta.** Una campaña fuera de territorio no destruye equity. Lo que hace es desperdiciar la oportunidad de acumularlo mientras la memoria existente sigue cayendo sola. Es costo de oportunidad, no daño. La distinción parece de manual pero cambia todo. Si el desvío *resta*, la conversación con el equipo creativo es sobre culpa. Si el desvío *divide el retorno*, la conversación es sobre asignación de presupuesto. La segunda se puede tener sin que nadie se ponga a la defensiva. La primera no. Acá aprendí algo sobre analogías: son cómodas justamente cuando son malas. «Se ve caótico pero hay estructura» es exactamente lo que dice todo director de marketing que perdió el rumbo. Recamán se ve ordenada solo desde afuera y solo en retrospectiva. Una marca no puede esperar diez años a que el patrón se revele. **Solté la sucesión. Me quedé con el modelo.** ## Formalizar hasta que se rompa Lo que quedaba era un modelo de acumulación con decaimiento. La primera pieza es la que casi nadie mide: **el brand equity es un saldo que se devalúa solo.** **Qué queda de la memoria de marca si la inversión se detiene** _Con una retención del 85% mensual, en medio año queda menos del 40% del stock. Esa tasa es propia de cada marca y se mide con datos propios — pero casi nadie la calcula, y por eso casi nadie sabe cuánto cuesta simplemente no retroceder._ Con el decaimiento adentro, simulamos cuatro formas de gastar el mismo dinero durante tres años. Y ahí pasó lo mejor de todo el proceso: **el modelo me contradijo.** En la versión lineal, gastar de a ráfagas trimestrales daba el mismo promedio que gastar continuo. Eso es falso en la práctica, y lo era también en mi intuición. Pero el modelo, como estaba escrito, no lo capturaba. La corrección era meter rendimientos decrecientes: concentrar el gasto quema plata en frecuencia excesiva. **Mismo presupuesto total, tres años, cuatro repartos** _Dos sorpresas. Concentrar el gasto es peor que dispersar el mensaje. Y «continuo pero disperso» rinde más que «coherente pero a los saltos»: la continuidad pesa más que la coherencia cuando el gasto está mal distribuido. No lo hubiera adivinado — ese es el punto de formalizar._ ## Buscar el hueco real Con el modelo funcionando, la pregunta era si aportaba algo que no existiera ya. La respuesta honesta: **la mitad ya existe.** Exceso de share of voice, share of search, la grilla de assets distintivos, el adstock en modelos de marketing mix. Binet y Field midieron que cada diez puntos de exceso de share of voice se asocian a medio punto de crecimiento anual de participación. Nielsen lo replicó sobre 123 marcas. Presentar eso como novedad es la forma más rápida de que un CMO con lecturas te desarme en la primera reunión. Pero había un hueco. Ningún reporte de marca responde estas dos preguntas: - **¿Cuánto de mi presupuesto construyó marca y cuánto solo compensó el olvido?** - **¿Cuál es mi piso de inversión para no perder terreno?** Todo reporte muestra gasto y resultado. Ninguno muestra la separación entre reponer y acumular. Y el costo de quedarse quieto no está presupuestado en ninguna línea, en ninguna categoría, en casi ninguna empresa. De ahí salió la métrica: **Net Build Rate**. Qué porcentaje del presupuesto de marca construyó, después de descontar lo que se diluyó y lo que se fue en reposición. **De cada 100 pesos de presupuesto de marca** | Invertidos | 100 | | Se diluyeron en piezas que no puntuaron | −35 | | Repusieron la memoria evaporada | −45 | | Construyeron | = 20 | **Net Build Rate = +20%** _El mismo cálculo puede dar negativo: si se diluyen 50 y la reposición exige 65, el resultado es −15%. Se gastó el presupuesto completo y la marca terminó el trimestre con menos posición que al empezar._ ## Los tres errores que aparecieron después Acá viene la parte que quería registrar de verdad. La primera versión de la métrica tenía tres defectos serios. **Los tres los cometió el modelo. Los tres aparecieron por preguntas mías.** Vale la pena detenerse en eso: no los detecté leyendo la fórmula ni auditando la lógica. Los destapé preguntando cosas obvias desde la operación. Preguntas que no requieren saber matemática, sino haber trabajado con presupuestos de medios reales. ### Error 1 — El cero mal explicado Detectado preguntando:«¿por qué llega solo a 0.30 y no un rango de 0 a 100?» La primera versión traía umbrales: más de 0.30 era «acumulación real», cerca de cero era «cinta de correr». Sonaba razonable. Era fantasía. Una marca en equilibrio da cero **por definición matemática**: si tu posición es estable y tu inversión también, el piso de mantenimiento se come exactamente toda tu inversión efectiva. No queda nada para acumular. Eso no es fracaso, es mantenimiento saludable. **La escala real, con el cero en su lugar** _El máximo no es +100%: es uno menos el piso dividido la inversión. Si una marca invierte 100 y su piso es 92, su techo real es 8%. Mi umbral de 30% le pedía algo matemáticamente imposible._ Ese error tenía consecuencias prácticas: el cliente iba a medir por primera vez, iba a dar cerca de cero, y con mi escala eso se leía como alarma cuando era normal. **La corrección:** el signo es interpretable desde el día uno; la magnitud no. Los umbrales se calibran con la distribución histórica de cada marca, no se fijan de antemano. Y el techo dejó de ser una restricción para convertirse en un resultado: si el techo de una marca es 8% y la ambición de crecimiento exige más, la palanca no es mejorar la creatividad. Es subir el presupuesto. Ese es un argumento que antes no se podía hacer con datos. ### Error 2 — La rúbrica castigaba a la radio Detectado preguntando:«¿cómo incluyo medios como radio, vallas u otras acciones de brand?» El coeficiente de coherencia se calculaba auditando cada pieza contra tres criterios. El primero pedía «al menos tres assets distintivos»: logo, color, tipografía, música, claim. La respuesta fue admitir el problema de raíz: **una cuña de radio impecable puntúa mal por no poder usar logo ni color.** Eso hacía que el coeficiente midiera *mix de medios* en vez de coherencia. El número dejaba de significar lo que decía significar. **Assets disponibles según el canal** | Asset | Video | OOH | Radio | | Logotipo | ● | ● | — | | Paleta y tipografía | ● | ● | — | | Estilo fotográfico | ● | ● | — | | Sonic logo o música | ● | — | ● | | Tono de voz | ● | — | ● | | Claim y vocabulario | ● | ● | ● | | Atleta embajador | ● | ● | ● | | Aplicables | 7 | 5 | 4 | _La corrección: cada canal se puntúa contra los assets que ese canal puede usar. Una valla con 4 de sus 5 aplicables puntúa 0.80. Una cuña de radio con 3 de sus 4 puntúa 0.75. Ahora son comparables._ Un aprendizaje lateral: la forma de pedir la lista de assets determina lo que te van a entregar. Si pedís «los assets distintivos», te dan los visuales. Hay que pedir «los assets distintivos por tipo: visual, sonoro, verbal y experiencial». ### Error 3 — El que cometí yo Propuse algo que rompía el método, y me lo rechazaron. Sugerí sumar una ponderación por alcance. Una valla en punto central llega a 10.000 personas y una periférica a 3.000; cumpliendo los mismos criterios, no deberían pesar igual. El rechazo vino con dos argumentos que no había visto. **Uno.** El alcance ya está en la inversión. El OOH se cotiza por tráfico — la valla central cuesta más precisamente porque llega a más gente. Y como el coeficiente se pondera por inversión, ya pesa más. Sumarlo otra vez lo cuenta dos veces. **Dos, y más grave.** El alcance también está del lado del resultado. La posición de marca se mide por búsquedas; si la valla llegó a más gente, más gente busca. Meterlo también del lado del input hubiera inflado artificialmente la correlación del backtest. La validación habría dado bien no porque el método funcione, sino porque estaría correlacionando el alcance consigo mismo. **La salida:** el alcance se captura siempre como campo, no entra al cálculo, y se reporta como métrica hermana. Una marca puede tener build rate alto con alcance bajo —hizo poco, pero muy bien— o al revés. Ese cruce dice más que cualquier número fusionado. ## Lo que me llevo del proceso **El valor no estuvo en la idea inicial.** La analogía con Recamán era mala y no sobrevivió al primer cuestionamiento. Lo que sirvió fue el desvío que provocó. **Los mejores momentos fueron las contradicciones.** Cuando el modelo lineal me dijo lo contrario de lo que yo creía. Cuando descubrí que los umbrales eran matemáticamente inalcanzables. Cuando mi propuesta de ponderar por alcance resultó romper la validación. Ninguno de esos momentos fue cómodo y los tres mejoraron el resultado. Definir cómo sabrías que estás equivocado es más valioso que defender que tenés razón. La parte del método de la que estoy más conforme no es la fórmula: es el control contra el predictor ingenuo. Comparamos la métrica contra la explicación más simple posible —mirar solo cuánto se gastó—. Si el gasto a secas predice igual de bien, toda la auditoría de coherencia no aportó nada y se descarta. ### Sobre el reparto de trabajo Es la parte que más me interesa registrar, porque no se parece a cómo se suele contar el trabajo con IA. **Lo que aportó el modelo:** formalizar el modelo matemático, correr las simulaciones, reconocer qué parte de esto ya estaba publicado y validado, construir la métrica, y rechazar mi propuesta de alcance con un argumento técnico que yo no tenía. **Lo que aporté yo:** la pregunta inicial, la intuición equivocada que abrió el desvío, y —esto es lo importante— las preguntas operativas que destaparon los dos errores graves. Ninguna de esas preguntas requería saber matemática. Requerían haber peleado con presupuestos de medios, haber discutido un plan con un CMO, saber que en la región buena parte del sell-out pasa por retail y eso desfasa los datos. Eso me dejó una lectura incómoda para los dos lados del debate habitual. La IA no reemplazó mi criterio: cometió errores que solo alguien con contexto operativo iba a ver. Pero tampoco fue una herramienta pasiva: me corrigió la analogía invertida en el primer intercambio y me rechazó una propuesta que hubiera invalidado la validación entera. **El modo que funcionó fue el de fricción, no el de asistencia.** Un modelo complaciente me hubiera dejado llegar a la reunión con umbrales matemáticamente imposibles y una rúbrica que castigaba a la mitad de los canales. Y yo, sin cuestionar lo que me daba, hubiera llegado igual. ## Dónde está esto hoy **No está validado.** Es una hipótesis con criterio de aceptación definido. El próximo paso es un backtest sobre doce trimestres de historia de una marca real: calcular la métrica a ciegas, contrastarla contra lo que efectivamente pasó, y descartarla si no predice. Puede que no funcione. Eso también sería un resultado. Lo que sí me llevo, funcione o no, es el registro de cómo una pregunta ociosa de las tres de la tarde se convirtió en cuatro horas de trabajo real. No porque la pregunta fuera buena, sino porque la seguí hasta donde dejó de ser interesante y algo mejor apareció en el camino. Fin del registro ================================================================ # Rúbrica de skills URL: https://www.gerardoriarte.com/conceptos/rubrica-skills Etapa: Micelio (Red madura y extendida. Se defiende sola en público.) Dominio: ingeniería Plantada: 2026-02-14 Última revisión: 2026-07-01 Conecta con: arquitectura-loops, criteria Resumen: Rúbrica formal para gobernar calidad y prevenir colisiones en un ecosistema creciente de skills de Claude Code. --- Cuando tenés un skill, lo controlás. Cuando tenés veinte, el problema deja de ser cada skill y pasa a ser el **ecosistema**: colisiones de activación, criterios inconsistentes, calidad que deriva. La rúbrica es el gobierno de ese sistema. ## Qué mide - **Prevención de colisiones** — que dos skills no se disputen la misma activación. - **Calidad del output** — criterio consistente entre piezas, no dependiente del humor del día. - **Frontera clara** — qué hace y qué explícitamente no hace cada skill. ## Por qué es infraestructura Un skill sin rúbrica es artesanía. Un ecosistema con rúbrica es una fábrica. La diferencia es si la calidad depende de vos o del sistema — que es la misma lógica de arquitectura-loops aplicada al catálogo de skills, y la misma apuesta de criteria: el criterio se codifica, no se improvisa. ## Estado Flor: gobierna el ecosistema actual y funciona. Falta probarla contra skills de terceros y ver si la frontera aguanta cuando el catálogo se multiplica. ================================================================ # Criteria URL: https://www.gerardoriarte.com/conceptos/criteria Etapa: Hifa (Un filamento con dirección. Tiene forma, le falta sustancia.) Dominio: conocimiento Plantada: 2025-12-05 Última revisión: 2026-08-23 Conecta con: rubrica-skills, arquitectura-loops Resumen: La IA automatizó las tareas donde se formaba el juicio. Método para extraer el criterio tácito de un experto — vía Critical Decision Method — y volverlo un skill operable. El problema abierto es validar que ese criterio sea bueno y no sesgo cristalizado. --- El activo de un experto no es lo que sabe, es cómo **decide** cuando el manual no alcanza. Ese juicio tácito casi nunca se documenta porque el experto ni siquiera sabe que lo tiene. Criteria es el método para extraerlo. La urgencia no es filosófica, es de calendario: el mecanismo que formaba criterio por accidente se está cerrando, y no hay reemplazo. ## El principio rector Tres curvas se movieron al mismo tiempo: | | hacia dónde va | por qué | |---|---|---| | **Ejecución** | tiende a cero | la IA la hace y la hace rápido | | **Conocimiento** | abundante | se sintetiza a demanda | | **Criterio** | escaso | requiere haber decidido y haber pagado el error | Quien solo sabe ejecutar compite contra una máquina más rápida y barata. Quien sabe decidir la dirige. El criterio no se abarata porque no se produce en serie — se produce decidiendo bajo consecuencia. Contra la intuición, la IA no reduce el valor del juicio: lo amplifica. Un modelo devuelve veinte respuestas plausibles en segundos y ninguna señal de cuál sirve en este contexto. Cuanto más potente la herramienta de ejecución, más determinante el criterio de quien la apunta. ## La escuela que se cierra Acá está el problema, y no es una proyección: ya se mide. | dato | fuente | |---|---| | 25% del empleo mundial expuesto a IA generativa (34% en países de altos ingresos); transformación más probable que sustitución | OIT & NASK, 2025 | | ~80% de los empleos en EE. UU. tiene al menos 10% de sus tareas expuestas a modelos de lenguaje | Eloundou et al. | | Salarios iniciales: **−6,3% junior**, −5,9% mando intermedio en empresas expuestas. Senior estable o al alza | Azar, Giné & Sanz-Espín, 2025 (138M trabajadores) | | Los requisitos educativos de puestos de entrada e intermedios bajan de forma sostenida; los de senior se mantienen | ídem | Las tareas más expuestas son las cognitivas de procesamiento: investigar, resumir, redactar, comparar, analizar. Y esas eran, durante generaciones, el trabajo de los que entraban. No las más complejas — las que servían para aprender el oficio. Al automatizarlas no se elimina solo trabajo: **se cierra la escuela**. La señal salarial lo confirma con precisión incómoda. El mercado no castiga la ejecución en general: castiga la ejecución *de entrada*, que era el único lugar donde se formaba el juicio. Y paga el criterio que ya existe sin financiar la producción del próximo. ## La ironía de la automatización No es un fenómeno nuevo. En los ochenta, la investigación sobre sistemas automatizados lo nombró: al mecanizar lo rutinario y dejar en manos humanas solo las excepciones difíciles, se priva a las personas de las oportunidades cotidianas de ejercer el juicio (Bainbridge). El resultado es paradójico. Cuando aparece el caso complejo —el que exige criterio—, quien debe resolverlo nunca tuvo el entrenamiento gradual para hacerlo. La máquina se ocupó de lo fácil, que era justamente donde se aprendía. Trasladado a hoy: una generación con más capacidad de ejecución que ninguna otra en la historia, y menos oportunidades de desarrollar el juicio que convierte esa ejecución en buenas decisiones. **Producto avanzado, criterio inmaduro.** ## Qué es criterio, con precisión Criterio es la capacidad de decidir bien bajo incertidumbre y con información incompleta: **qué priorizar, qué ignorar, cuándo una respuesta correcta no es la adecuada, y por qué.** No es conocimiento —eso se consigue gratis—; es juicio aplicado bajo consecuencia. La distinción operativa: el conocimiento se verifica contra una fuente. El criterio se verifica contra un resultado. ## Dónde vive el criterio El protocolo se apoya en el **Critical Decision Method**: en vez de preguntar "¿cómo hacés esto?" —que devuelve la teoría que el experto cree tener—, se reconstruye una decisión real difícil y se cava en los puntos donde eligió un camino y descartó otros. La regla que ordena todo el método: > Lo que el experto declara es una racionalización posterior. Los descartes no. | lo que se pregunta | lo que devuelve | |---|---| | "¿Cómo lo hacés?" | Un manual que el experto no sigue | | "¿Qué mirabas en ese momento?" | Las señales que usa sin nombrarlas | | "¿Qué otra opción tenías?" | El espacio de decisión real | | **"¿Por qué descartaste esa?"** | **El criterio** | La cuarta es la única que importa. Las tres primeras existen para llegar a ella sin que el experto se ponga a teorizar. CDM viene de la investigación en toma de decisiones naturalista, diseñada para bomberos y pilotos. El aporte acá no es el método: es sostener que el juicio de un profesional del conocimiento es igual de extraíble, y que el output no debería ser un informe sino un **skill operable**. ## De juicio a skill Capturar no alcanza. El output tiene que ser operable: un skill que aplica ese criterio de forma consistente, no un documento que alguien lee una vez. Por eso Criteria no vive solo. Depende de dos piezas: - rubrica-skills — qué hace bueno a un skill, y cómo evitar que veinte skills con criterios distintos se pisen entre sí. - arquitectura-loops — cómo se valida que el skill decide como el experto y no alucina con seguridad. Sin las dos, Criteria produce artesanía documentada. ## El problema del oráculo Acá está el hueco, y es el que decide si el método sirve o es teatro. Capturar criterio es la parte fácil. La difícil es responder **cómo sabés que el criterio capturado es bueno.** Un experto con veinte años puede tener juicio perfectamente calibrado a un mercado que ya no existe. Sus descartes fueron correctos en 2015 y hoy son supersticiones con currículum. Sin algo que deba ser siempre verdad, no estás codificando criterio: estás **cristalizando el sesgo de una persona y dándole autoridad de sistema** — peor que no tener método, porque ahora el sesgo escala y firma. Es la misma distinción que separa los dos loops de arquitectura-loops: | | oráculo | qué pasa sin él | |---|---|---| | Loop de validación | sí — invariantes | el código no compila, se nota | | Loop de negocio | no | deriva hacia lo cómodo, no se nota | | **Criteria hoy** | **no** | el criterio malo se propaga con confianza | ## El criterio codificado caduca y no puede saberlo Hay un segundo problema, y es estructural: no está en la calidad de la captura sino en la naturaleza del artefacto. > Un criterio codificado no puede declararse obsoleto. Un skill **es** su > criterio — no tiene desde dónde dispararle. Un experto vivo puede llegar a la conclusión de que su propio juicio dejó de aplicar. Es una operación que exige pararse afuera del criterio propio. Un artefacto que *consiste* en ese criterio no tiene afuera. Eso parte el problema en dos, y solo una mitad se resuelve con ingeniería: | operación | ¿codificable? | por qué | |---|---|---| | **Detectar** que el criterio falla | **Sí** | es monitoreo de deriva: outcomes contra predicción | | **Decidir con qué reemplazarlo** | **No** | el dominio nuevo todavía no tiene casos acumulados | Consecuencia para el método: **todo skill de criterio necesita fecha de extracción y una condición de revisión.** Sin eso, Criteria no produce criterio operable — produce criterio embalsamado que se sigue ejecutando con la autoridad del día que se capturó. ## La arena El único candidato honesto a oráculo es exponer el criterio codificado a **problemas reales con consecuencia**, y dejar que el resultado —no un checklist, no la aprobación del experto— decida si acertó. Es un oráculo lento, ruidoso y caro. Es un oráculo igual. Y es también el único mecanismo que puede disparar la revisión de la sección anterior: sin señal de resultado, no hay forma de saber que el criterio caducó. La implicancia hay que sostenerla aunque incomode: > Mientras no exista esa arena, Criteria no puede afirmar que **forma** criterio. > Solo puede afirmar que lo **transmite**. No es lo mismo. La diferencia no es semántica. Estudiar decisiones ajenas es consumir contenido, y el criterio no se forma consumiendo —se forma decidiendo—. Un método que captura juicio y lo entrega como material de estudio reproduce exactamente el problema que dice combatir, con mejor packaging. La arena es lo único que separa una cosa de la otra. ## Cuándo NO usar esto - **Dominio inestable.** Si las reglas cambian más rápido de lo que se codifica el criterio, estás embalsamando. Ahí conviene el experto vivo. - **Casos que no se repiten.** Sin repetición no hay patrón que extraer, solo anécdotas bien contadas. - **Experto sin errores documentados.** Si no puede reconstruir una decisión que salió mal, no vas a poder distinguir su criterio de su relato. - **Cuando el objetivo real es documentar procesos.** Eso es otra cosa, es más barata, y no necesita nada de esto. ## Lo que esto NO resuelve *(deuda firmada — 2026-08-23)* - **El oráculo.** Sin arena corrida, el método está sin validar. Es la deuda principal, no un detalle de implementación. - **La caducidad.** Está identificado el problema y el corte detectar/reemplazar, pero no hay mecanismo de revisión implementado. - **La recursión.** Si el criterio se codifica, ¿qué queda del experto? El método produce su propia pregunta y todavía no la responde acá. - **La escala.** Sirve para un experto. No está probado para el criterio distribuido de un equipo, donde nadie tiene la decisión completa. ## Estado Brote. Está el método, está el diagnóstico y están los datos. **No está la aplicación.** Sube a flor cuando haya: un experto extraído, un skill que decida como él, y al menos una divergencia entre los dos resuelta por la realidad —no por mí—. ================================================================ # El Cobrador URL: https://www.gerardoriarte.com/conceptos/el-cobrador Etapa: Hifa (Un filamento con dirección. Tiene forma, le falta sustancia.) Dominio: venta Plantada: 2025-10-02 Conecta con: a-bra-loop Resumen: Alter ego diseñado para contrarrestar el sesgo natural a construir en vez de vender. Un rol que fuerza la fase de cobrar. --- Tengo un sesgo estructural: construyo antes de vender. Es más cómodo, se siente productivo, y es la forma más elegante de no exponerse al mercado. El Cobrador es el mecanismo para corregirlo. ## Qué es Un alter ego operativo. No un truco de motivación — un rol con reglas: cuándo se activa, qué prioriza, qué le da igual. Su único trabajo es forzar que el trabajo se convierta en propuesta, y la propuesta en plata. ## Por qué existe como concepto y no solo como recordatorio Porque el sesgo a construir está codificado en el propio a-bra-loop: la rueda gira hacia producto. Necesita un contrapeso con la misma formalidad, no una nota mental que se ignora. ## Estado Brote: el framework existe, pero todavía le falta convertirse en un protocolo con gatillos concretos y medibles. Hoy depende demasiado de que me acuerde de invocarlo — que es justo lo que debería resolver.