Paul Jialiang Wu agentic-portfolio English 中文 한국어 日本語✉️ Lista gratuita
← Volver al portfolio

No puedes ordenarle a la gente que cierre loops — así que deja de intentarlo

Resumen de 1 minuto — qué te llevas de aquí

Top-down vs bottom-up en una empresa de robótica AI-native — el juego del CNO, maker!=checker, y el incentivo on-chain, con el Solidity.

Top-down vs. bottom-up en una empresa de robótica AI-native: por qué los ganadores diseñan un juego en lugar de dar órdenes — con la maquinaria exacta, hasta el smart contract, que un ingeniero puede construir mañana.

Top-down barks orders; bottom-up designs a game where everyone hunts and closes loops.
Top-down da órdenes; bottom-up diseña un juego donde todos cazan oportunidades y cierran loops.

Aquí va una escena que ya has visto antes.

Un ejecutivo se levanta y anuncia la nueva estrategia: "Everyone here needs to innovate. Own it. Be entrepreneurial." (Traducción: "Todos aquí necesitan innovar. Hacerlo suyo. Ser emprendedores.") Hay una diapositiva. Tiene un cohete dibujado. Todos asienten, vuelven a su escritorio, e innovan exactamente lo mismo que el día anterior — es decir, esperan a que les digan qué hacer.

Mientras tanto, a cinco kilómetros de ahí, el robot clase Titan de una empresa de robótica más pequeña se está volviendo notablemente menos torpe cada noche — y nadie arriba lo ordenó. Una técnica de planta notó que la pinza fallaba al sujetar vasos transparentes bajo la luz de la mañana, corrió un experimento, y ahora la solución le paga a ella automáticamente, on-chain.

Esa es toda la pelea resumida en una sola imagen. El top-down le dice a la gente que cierre los loops. El bottom-up hace que cerrar los loops sea la jugada obviamente ganadora — y se quita de en medio.

Me he pasado el último tramo construyendo el runtime para el segundo tipo de empresa (un sistema operativo de Physical AI nativo de IA). Déjame darte el modelo mental que un chico de 15 años capta al instante, y luego pasarle a tu ingeniero las piezas — incluyendo el Solidity.

El modelo mental: dos cocinas

Imagina dos restaurantes en la misma calle.

La Cocina A es top-down. El chef principal está parado en el pase y grita órdenes. ¿Se atrasa la parrilla? Se da cuenta, eventualmente, y grita. ¿Un cocinero tiene una idea para preparar más rápido? Tiene que atrapar al chef de buen humor. Nada mejora a menos que pase por un solo cerebro sobrecargado. En una noche ajetreada, la Cocina A es un cuello de botella con gorro de chef.

La Cocina B es bottom-up — la cocina abierta. Todos los cocineros pueden ver el tablero de tiempos de ticket. Cuando la parrilla se atrasa, cualquier cocinero puede señalarlo e intentar un ajuste de preparación durante un turno, en una estación — acotado, reversible. El expo — no el cocinero que hizo el cambio — verifica si el tiempo de ticket realmente bajó. Y la fórmula de propinas está escrita en la pared: una mejora verificada paga automáticamente, y más si sigue dando resultado. El chef principal en la Cocina B nunca cocina. Construye la cocina, mantiene el refrigerador frío y los cuchillos afilados, y escribe una fórmula de propinas que sea justa y no se pueda manipular.

La Cocina A escala hasta exactamente un genio. La Cocina B escala hasta todos.

Two kitchens: top-down funnels every fix through one brain; bottom-up lets anyone hunt, an expo verify, and the tip formula pay.
Dos cocinas: el top-down canaliza cada arreglo a través de un solo cerebro; el bottom-up deja que cualquiera cace, un expo verifique, y la fórmula de propinas pague.

Término por término — para que tu ingeniero pueda construir la Cocina B

Una metáfora que no se traduce en componentes es solo una buena sensación. Aquí está el mapeo: el CNO (Chief AI-Native Officer) es el chef principal; todo lo demás es un sistema.

Cocina B (lo que se imagina un chico de 15 años)El sistema (lo que construye un ingeniero)
El tablero de tiempos de ticket que todos venUn tablero de brechas que aparece automáticamente — un sensor de fricción + tus Nos de preparación + los flujos de trabajo que consumen más minutos humanos
Prueba un ajuste por un turno, en una estaciónA bucle cerrado acotado: hipótesis + una métrica + una reversión. Barato de poner en marcha; una compuerta de seguridad lo mantiene fuera de producción
El expo verifica, no el cocineroUn árbitro independientecreador ≠ verificador. La persona que hizo el cambio nunca lo certifica
La fórmula de propinas en la paredUn contrato inteligente on-chain que paga el cierre verificado — nunca el esfuerzo, nunca las propuestas
Pagar más cuando la solución sigue funcionandoVesting compuesto — el pago fluye de manera continua, y volver a verificar que se sostiene en el tiempo lo extiende. La gente persigue apalancamiento, no aplausos
"No incendies el local" le gana a las propinasA compuerta de seguridad cero — una falla de seguridad anula la recompensa sin importar el ROI
El chef ejecutivo nunca cocinaEl CNO construye la infraestructura, la cultura y el contrato, y no cierra los loops por la gente (eso solo reconstruye el cuello de botella)

Lee la columna de la derecha. Eso no es una sensación — es un diseño organizacional. Y el contrato en el centro es más pequeño de lo que suena.

El contrato, en el lenguaje en el que realmente vive

Los tres innegociables no son un póster de valores — son estos requireenunciados:

// maker != checker — enforced in code, not in a handbook
function attestClose(uint256 id, uint256 reward) external {
    require(isChecker[msg.sender], "not a referee");
    require(msg.sender != closes[id].maker, "maker != checker"); // the whole point
    // ...fund a vesting stream that re-verification extends (compounding)
}

// safety is a terminal gate, not a weighted term
function flagSafety(uint256 id) external onlyGuardian {
    // zero the UNRELEASED reward and halt — regardless of ROI
}
What the contract rewards: maker≠checker, compounding vesting, and a safety-zero gate — three requires, not a values poster.
Lo que el contrato recompensa: maker ≠ checker, vesting compuesto y una compuerta de seguridad cero — tres requisitos, no un póster de valores.

Si la persona que hizo el trabajo puede aprobar su propio resultado a cambio de dinero, se va a poner la nota de su propia tarea — por eso ese principio maker != checker es una línea de Solidity, no una línea en una presentación de onboarding. Y tú recompensas lo compuesto, no los golpes de suerte únicos: una solución que sigue reduciendo la carga humana gana más, con el tiempo. Esa única perilla es lo que hace que la gente persiga apalancamiento en vez de un trofeo con forma de bono.

"¿Pero seguro que la gente inteligente de arriba debería decidir?" — lo que dice la evidencia de la robótica

Aquí está la parte contraintuitiva, y no es una opinión de management — es lo que la investigación sobre robots sigue demostrando: la diversidad le gana a una sola inteligencia directriz.

Traduciendo esto a tu organigrama: una empresa que canaliza cada mejora a través del ejecutivo de arriba es un robot entrenado con una sola caja azul y desde un solo ángulo. Tiene una confianza absoluta en sí misma, hasta que aparece una caja marrón — y ahí le da una crisis existencial. El bottom-up no es la opción blandita. Es la que tiene las citas que la respaldan.

El truco — y es la razón entera por la que el top-down persiste — es la confianza. El bottom-up solo funciona si una mala idea no puede hacer daño y una buena idea no puede fingirse. Eso es exactamente lo que te compran el referí independiente y la compuerta de seguridad cero: una empresa puede dejar que todos experimenten con seguridad porque nada se lanza sin verificar y nada inseguro sobrevive. Quita esas dos cosas y "empoderar a todos" se convierte en "el optimismo de todos, sin filtro" — que es como terminas con un robot muy rápido y, en gran medida, un reporte de incidente.

La secuencia honesta (no te la saltes)

No empiezas escribiendo Solidity. Empiezas con una pizarra: pones el tablero de brechas abiertas, dejas que cualquiera reclame una brecha, corres un experimento con una métrica independiente, y pagas el primer cierre verificado con una recompensa manual. Demuestras que el juego es divertido y justo con humanos en el ciclo. Luego codificas exactamente la matemática de pago que funcionó. Nunca programes un incentivo que no hayas probado antes a mano — el único trabajo del contrato es hacer que una cultura ya comprobada sea permanente e infalseable.

Porque aquí está el final, y es la tesis entera en un suspiro:

Una empresa top-down es tan inteligente como la persona en la cima en su mejor día. Una empresa bottom-up — con un referí y una compuerta de seguridad — se vuelve más inteligente cada noche mientras todos duermen. Construye la segunda, y tus robots se vuelven menos torpes por sí solos. Construye la primera, y tendrás una tostadora carísima con patas y un ejecutivo insistiendo, desde el pase, en que está a punto de ser brillante.

Así que la pregunta no es "¿cómo logramos que a la gente le importe?"

Es: ¿estamos dando órdenes a gritos, o escribimos la fórmula de la propina en la pared?


Construyo esto en abierto — un OS para empresas Physical-AI-native (los roles, la doctrina del bucle operativo, el boceto del incentivo on-chain) y sos, el framework de loop-engineering subyacente. Si estás atascado entre top-down y bottom-up en tu propio equipo, cuéntame dónde se rompe en los comentarios — los leo todos.

→ Lee la doctrina del incentivo + el boceto en Solidity — repo: github.com/wjlgatech/physical-ai-native

#PhysicalAI #Robotics #AInative #Web3 #Leadership #BuildInPublic


Referencias (todas reales, todas verificables)

Las cifras se citan tal como las reportan las fuentes anteriores; las cocinas y la técnica de planta son ilustrativas. Si alguna afirmación aquí no es rastreable a una de estas fuentes, tómala como opinión, no como hecho.

Borrador — desde github.com/wjlgatech/physical-ai-native · compartido para leer desde el móvil. El botón de Publicar es tuyo.