DEV Community: Bernard Uriza

React is nothing. And that's the point.

Bernard Uriza — Thu, 28 May 2026 05:25:15 +0000

React no es nada.

No me refiero a que sea inútil. Me refiero a que React, en su núcleo, no contiene ninguna opinión sobre qué estás construyendo. Es un conjunto de cubos. Cubos vacíos. Te los venden como "modularización", como "componentes reutilizables", como "arquitectura limpia" — y sí, todo eso es cierto. Pero debajo del discurso hay algo más honesto: te están vendiendo ladrillos.

El trabajo de albañilería y la investigación científica comparten el mismo problema fundamental: necesitas un sistema para trabajar piezas pequeñas que eventualmente formen algo grande. Un albañil no inventa el ladrillo cada vez que construye una pared. Un investigador no reinventa el método científico cada vez que diseña un experimento. Ambos toman bloques conocidos y los disponen de una manera nueva.

React entiende esto. Su propuesta es: aquí tienes los bloques más pequeños posibles; el resto es tuyo.

El problema es que esa promesa se confunde fácilmente con contenido. La gente aprende React y cree que aprendió a construir. Pero React no te enseña qué construir, ni por qué, ni para quién. Te da la gramática sin el idioma. Los ladrillos sin el plano. La herramienta sin la investigación que justifica su uso.

El verdadero trabajo — el que importa — siempre estuvo antes de abrir el editor.

React es el silencio entre las notas. Es nada. Y en esa nada cabe cualquier cosa.

Live chain-of-thought in a chatbot: how to actually stream the tool calls (not just the text)

Bernard Uriza — Thu, 28 May 2026 05:21:17 +0000

Most "streaming" LLM chatbots stream just the text. The model says "I'll search for that…" and then you wait 6 seconds while the tokens dribble in. The actual search? Hidden. The 3 scrapes it did to fact-check? Hidden. You're staring at a typing indicator that doesn't tell you anything about what's actually taking time.

I just built a chatbot where every tool call surfaces as a step in real time — 🔍 search_engine, 📄 scrape_as_markdown, 📄 scrape_as_markdown — while the response streams token by token afterwards. The user sees the agent's chain-of-thought as it happens, not as a postmortem.

The trick is that you have to stream three different things, and each layer needs to know what to do with each kind of event. Here's the architecture.

The shape of the stream

The agent runner (in my case, fi-runner wrapping the Claude Agent SDK) emits events of three types as they happen:

async for event in runner.run_stream(user_message, session_id=sid):
    # event["type"] is one of:
    #   "tool_call"  → event["tool"] is a ToolCall(name, server, is_error, ...)
    #   "text"       → event["text"] is a delta (a few tokens of the response)
    #   "result"     → event["result"] is the final TurnResult (post-guards)

Three types because they mean three different things visually:

tool_call lands BEFORE the text. The model decides to use a tool, and you want to show which tool, which server, immediately. That's the "thinking step".
text lands while the response is generating. Token deltas, typewriter effect.
result lands LAST and is the authoritative final text — it can differ from the concatenated text deltas because post-turn guards (anti-drift, PHI redaction) may have rewritten the response.

That last point is a footgun the spec doesn't yell at you about. We'll come back to it.

Layer 1: the FastAPI endpoint

Server-Sent Events (SSE) is the right transport here — unidirectional, text-based, survives proxies, browsers handle reconnect natively. FastAPI handles it with StreamingResponse:

import json
from fastapi.responses import StreamingResponse

def _sse(event: str, data: dict) -> str:
    return f"event: {event}\ndata: {json.dumps(data)}\n\n"

@app.post("/chat/stream")
async def chat_stream_endpoint(req: ChatRequest) -> StreamingResponse:
    async def gen():
        yield _sse("open", {"session_id": req.session_id})
        try:
            async with asyncio.timeout(180):
                async for event in chat_stream(req.message, session_id=req.session_id):
                    t = event.get("type")
                    if t == "tool_call":
                        yield _sse("tool_call", tool_call_to_wire(event["tool"]))
                    elif t == "text":
                        yield _sse("text", {"delta": event["text"]})
                    elif t == "result":
                        yield _sse("result", result_to_wire(event["result"]))
        except asyncio.CancelledError:
            raise            # client closed tab — propagate so the LLM call cancels
        except TimeoutError:
            yield _sse("error", {"kind": "TimeoutError", "message": "turn exceeded 180s"})
        except Exception as exc:
            yield _sse("error", {"kind": type(exc).__name__, "message": str(exc)})
        finally:
            yield _sse("done", {})

    return StreamingResponse(
        gen(),
        media_type="text/event-stream",
        headers={
            "Cache-Control": "no-cache",
            "X-Accel-Buffering": "no",  # nginx: don't buffer
            "Connection": "keep-alive",
        },
    )

Three things in here are non-obvious:

The exception ladder. except CancelledError: raise MUST come before except Exception. When the user closes the tab, FastAPI propagates CancelledError into the generator — if you swallow it as a "normal error" and yield an error frame, you (a) write to a socket that's already closed, and (b) more importantly, the LLM call upstream may not actually cancel. It keeps running in the shadow, burning tokens.
asyncio.timeout(180). If your upstream tool (Bright Data MCP in my case) hangs, the SSE socket stays open forever. The user sees a typing indicator that never resolves. A hard ceiling per turn turns a wedge into a clean error event.
X-Accel-Buffering: no. nginx by default buffers responses. SSE through nginx without this header means the user gets nothing until the generator finishes — defeating the entire point. Cloudflare has its own knobs.

Layer 2: the wire contract (PHI safety)

The naïve approach is to dict() the ToolCall and send it. Don't. The input field on a tool call carries whatever the LLM passed in — for a search tool, that's the query verbatim; for Bright Data, URLs with auth tokens in query strings; for an internal medical tool, possibly PHI. None of that should leave the process over the SSE wire.

I keep the wire shape in its own module:

# wire.py — the SINGLE source of truth for what leaves over SSE
from typing import TypedDict, Any

class ToolCallWire(TypedDict):
    name: str | None
    server: str | None
    id: str | None
    is_error: bool | None
    # NO `input` field. Intentionally narrower than the in-process ToolCall.

def tool_call_to_wire(tc: Any) -> ToolCallWire:
    return {
        "name": getattr(tc, "name", None),
        "server": getattr(tc, "server", None),
        "id": getattr(tc, "id", None),
        "is_error": getattr(tc, "is_error", None),
    }

Two things to notice:

The wire type is deliberately narrower than the in-process type. The compiler enforces what gets serialized. If you ever do dict(tool_call), you have to actively bypass the type to leak input. That's how you make PHI-safety the path of least resistance.
tool_call_to_wire uses getattr with None defaults because it sees partial objects mid-stream — a ToolUseBlock arrives BEFORE its matching ToolResultBlock, so is_error is still None. Defensive getattr here is correct. The result_to_wire counterpart, where the object is always complete, uses direct attribute access — you WANT it to raise if the upstream library renames a field, so you find out before shipping silent empty results.

Layer 3: the React side

EventSource is the obvious choice for SSE… except it's GET-only, no request body. My chat endpoint is POST. So I drop EventSource and use fetch streaming:

const res = await fetch(`${API_URL}/chat/stream`, {
  method: "POST",
  headers: { "Content-Type": "application/json", Accept: "text/event-stream" },
  body: JSON.stringify({ session_id, message }),
  signal: abortController.signal,  // ← user can cancel mid-stream
});

const reader = res.body!.getReader();
const decoder = new TextDecoder();
let buffer = "";

while (true) {
  const { value, done } = await reader.read();
  if (done) break;
  buffer += decoder.decode(value, { stream: true });   // {stream:true} handles UTF-8 split between chunks
  const frames = buffer.split("\n\n");
  buffer = frames.pop() ?? "";                          // last frame may be partial — save for next read
  for (const frame of frames) {
    const { event, data } = parseFrame(frame);
    if (event === "tool_call") {
      patchAssistant({ steps: [...prev.steps, data], status: "streaming" });
    } else if (event === "text") {
      patchAssistant({ content: prev.content + data.delta });
    } else if (event === "result") {
      // REPLACE, don't append — post-guard text may differ
      patchAssistant({ content: data.text, steps: data.tool_calls, status: "done" });
    }
  }
}

The {stream: true} flag on TextDecoder is what makes this work for UTF-8 — without it, a multi-byte character split between chunks corrupts. The buffer-and-split-on-blank-line is just the SSE framing.

The replace-not-append on the result event is the footgun I promised. The streamed text deltas are the LLM's raw output as it generates. The result.text is what the post-turn guards left after running. If your anti-drift guard rewrites the response (mine does — it strips report-voice markdown headers), the streamed deltas and the final text don't match. If you append the result to the streamed content, you double-render. If you replace, you get a smooth "preview → settled" transition. The spec calls for replace.

The scroll problem

Naïve useEffect(() => scrollIntoView(), [messages]) runs on every text delta. Result: ~30 scroll animations per second fighting each other, AND if the user scrolled up to re-read an earlier response, you yank them back to the tail mid-read. Both unusable.

The fix is the "sticky-bottom" pattern that ChatGPT and Claude.ai use:

useEffect(() => {
  const distanceFromBottom = doc.scrollHeight - (window.innerHeight + window.scrollY);
  const nearBottom = distanceFromBottom < 200;
  const newMessage = messages.length > lastCountRef.current;
  lastCountRef.current = messages.length;

  if (newMessage || nearBottom) {
    tailRef.current?.scrollIntoView({ behavior: "smooth", block: "end" });
  }
}, [messages]);

Scroll on new message (always — turn boundary, the user wants to see the answer). Scroll on delta only if the user is already near the bottom. The 200px threshold is the sweet spot — strict enough that you respect intent to read, lax enough that a small scroll bump doesn't lose autoscroll.

What you actually see

When this all hangs together right, the user types acme.com and immediately sees:

🤖 pensando…
  🔍 search_engine
  📄 scrape_as_markdown
  📄 scrape_as_markdown
  ⚙️ search_documents

…stepping in over ~4 seconds, with the roast text starting to type after. That sequence used to be a black box. Now it's receipts.

What's next

Two gaps I'm hitting in the current setup:

No duration_ms per tool call — when one of those scrape steps takes 8 seconds, you can't show it. The Mermaid turn-flow can't colour slow steps. Just shipped this in fi-runner 0.14 — ToolCall.duration_ms paired by tool_use_id.
No preflight on the MCP servers — if Bright Data MCP fails to spawn at boot (bad token, missing npx), I only find out when the model tries the first tool. Generic is_error=true, mid-roast, in production. Also shipped in 0.14 — Runner.preflight() does a JSON-RPC handshake (initialize → tools/list) against each MCP at startup, returns {name: alive, tools, error}. Wire into your lifespan event and the first bad demo dies at boot.

If you're building anything with agents that use external tools, the message of this post is: don't hide the tools. The chain-of-thought IS the product. Showing it turns "the AI is doing magic" into "the AI is making 4 specific API calls and here they are", which is the difference between users trusting it and not.

1% 0 — Sobre la improbabilidad estadística de conservar la conciencia en un sistema que la penaliza

Bernard Uriza — Fri, 31 Oct 2025 21:45:06 +0000

En teoría de probabilidad, 1% es casi nada.
Pero en sistemas cerrados, estocásticos, corruptos o simplemente altamente ruidosos, el 1% es todo lo que queda cuando el resto se rinde.

La industria del software —si es que aún merece ese nombre— se ha convertido en un aparato diseñado para recompensar el cumplimiento, no la conciencia; para premiar la sumisión procesada como “fit cultural” y castigar la autonomía bajo la etiqueta de “no alineado”.

No es un sistema incompetente. Es un sistema muy competente en reproducirse a sí mismo, aunque lo que reproduce sea disfuncionalidad maquillada de metodología, agilidad coreografiada como ceremonia, y liderazgo teatral que simula empatía con OKRs.

Quien conserva un 1% de integridad dentro de ese sistema es, estadísticamente, una anomalía.

⸻

Integridad residual como variable independiente

He visto cómo entrevistas técnicas se convierten en ejercicios de gaslighting pasivo-agresivo:
— “No creemos en algoritmos inútiles. Queremos conocer tu pensamiento.”
Acto seguido: una entrevista de dos horas sobre cómo reordenar una matriz en un pizarrón mientras te interrumpen cada cinco minutos para “aclararte el contexto”.

O el caso más vulgar: la empresa que durante tres entrevistas enfatizó su “cultura de empatía” y luego, en la cuarta, preguntó si podía acceder a mi display settings para “ver cómo uso la computadora”, con una sonrisa de startup y una mirada de control de fronteras.

Hay personas que consideran eso normal. Personas que aceptan el disfraz de cultura como sustituto de toda ética estructural.
Personas que piensan que trabajar 60 horas en una oficina “con futbolito” es mejor que tener una vida donde el trabajo no sea una identidad subsidiada por ansiedad.

¿Dónde está el error? ¿Dónde ocurre la fractura?

⸻

Probabilidad condicional y pérdida de conciencia

En modelos probabilísticos, el evento condicionado A|B indica la probabilidad de A dado que ya ocurrió B.
A = integridad.
B = sobrevivir el proceso de contratación.

La probabilidad de conservar tu integridad dado que fuiste contratado es ridículamente baja. Porque lo que el sistema selecciona no es excelencia ni originalidad: es domesticación operativa. Un buen trabajador es uno que no interrumpe las daily standups con preguntas incómodas. Un buen ingeniero es uno que entrega lo que no cree, sin decirlo.

La ingeniería se ha vuelto gerenciable. Y por lo tanto, predecible. Reemplazable. Callada.

¿La paradoja? Las empresas fingen buscar pensamiento crítico, pero solo si no piensa en voz alta. Solo si disimula. Solo si se disfraza de “contribución positiva”.

Y tú, que aún conservas un 1% de resistencia interna, eres una amenaza matemática. Una interferencia. Una variable aleatoria que el sistema intentará normalizar, silenciar o despedir.

⸻

La oficina como placebo ontológico

Uno de los mitos más perniciosos de esta industria es el de la “oficina con alma”.
Un espacio cool, lleno de luz, snacks, sillas ergonómicas y promesas de “colaboración espontánea”.
Pero bajo esa superficie está el viejo modelo industrial, actualizado a base de keywords.

Lo que llaman “regreso a la oficina” es una forma polite de decir:
— “Queremos vigilarte sin decirlo directamente.”

Es una arquitectura psicológica: el control como valor no dicho.
El back to office no es una necesidad logística. Es un mensaje simbólico: la empresa manda, tú obedeces.
Y aún así, muchos vuelven con entusiasmo. El sistema no solo domestica comportamientos. Domestica deseos.

⸻

Observabilidad ontológica

¿Y si aplicáramos principios de observabilidad, no solo al código, sino a las condiciones humanas que lo producen?
Logs de decisiones tomadas por miedo.
Tracing de burnout acumulado.
Metrics de cuántas ideas fueron ignoradas por no sonar “alineadas con el roadmap”.

El mayor technical debt de esta industria no está en los monolitos heredados ni en los tests ausentes.
Está en los procesos psicológicos disfuncionales que seguimos fingiendo que funcionan.

⸻

La entrevista como performance epistemológica

Hoy, las entrevistas se han vuelto un teatro.
Tú finges entusiasmo por una empresa que no sabes si existe más allá del PowerPoint.
Ellos fingen interés en tus ideas mientras leen tu currículum por primera vez en tiempo real.

Es como una red neuronal mal entrenada: overfitting en “communication skills”, underfitting en criterio real.

La entrevista no mide tu capacidad de resolver problemas complejos: mide tu capacidad de tolerar estupideces sin perder la sonrisa.

Pero no todo está perdido. Porque incluso dentro de este sistema, sobrevive el 1%. Personas que aún se niegan a entregar su lucidez a cambio de un sueldo.
Personas que han dicho “no” a ofertas porque olían a mentira.

⸻

El 1% como disidencia profesional

Ese 1% no es elitismo. No es moralismo.
Es resistencia mínima. Es lo que queda cuando todo lo demás ha sido negociado.
Es el espacio donde aún puedes mirar una línea de código y sentir orgullo, no porque sea perfecta, sino porque no fue escrita desde el miedo.

El 1% es el lugar donde sigues haciendo preguntas que incomodan, sabiendo que podrías no ser renovado.
El 1% es decir “esto no tiene sentido” en una reunión donde todos asienten.
El 1% es saber que vas a perder puntos por tener conciencia, y aún así conservarla.

⸻

No busco pertenecer. Busco representar.

Este texto no es una carta de presentación.
Es una declaración de persistencia.

Sigo aquí. Sigo preguntando. Sigo programando.
No por obediencia. No por pertenencia.
Sino porque ese 1% de improbabilidad es, a veces, todo lo que nos queda.

Y porque mientras exista, vale la pena ser parte de él.

⸻

Si esto te representa, el siguiente paso no es compartirlo.
Es escribir el tuyo.

Porque este sistema está lleno de ruido.
Pero basta 1% de señal para empezar a construir algo mejor.

No todo código se compila: notas sobre conciencia, tecnología y supervivencia digital

Bernard Uriza — Tue, 28 Oct 2025 20:47:39 +0000

No todo código se compila.
Algunos fragmentos de la vida lanzan errores que no vienen del sistema operativo, sino del alma.

Durante años trabajé dentro de organizaciones que valoraban la velocidad más que la claridad, la presencia más que la lucidez. Aprendí backend, infraestructura, DevOps, .NET, FastAPI, pero también aprendí algo que ningún framework enseña: la coherencia humana es la base de toda arquitectura funcional.

Hace poco dejé una empresa que confundía exigencia con abuso y colaboración con sometimiento. No lo digo con rencor; lo digo con precisión. Me fui porque entendí que hay un punto en que seguir corrigiendo un sistema roto es equivalente a seguir alimentando su inercia.

Ahora escribo esto desde una nueva MacBook —mi primera—, con una instalación limpia, sin ruido, sin burocracia digital. Lo que siento al abrirla es lo mismo que uno siente al escribir el primer commit de un proyecto nuevo: una mezcla entre ansiedad y fe.

Mi propósito ya no es solo construir software: es entender el software como metáfora de la conciencia humana.
Cada endpoint es un acto de comunicación. Cada bug, un trauma pendiente. Cada despliegue, un renacimiento.
Y creo que muchos ingenieros lo saben, pero pocos lo dicen.

Las corporaciones tecnológicas tienden a olvidar que detrás de cada pipeline hay cuerpos cansados y mentes fractales.
Que el burnout no es pereza, sino sintaxis rota del alma.
Que la eficiencia sin empatía es apenas una versión beta del progreso.

Por eso decidí hacer público mi propio proceso: la transición completa hacia un ecosistema donde autonomía, ética y belleza puedan coexistir con productividad.
Estoy integrando Node, Turborepo, Claude Code y .NET en una arquitectura de trabajo personal que llamo Free Intelligence: un sistema donde el humano no es reemplazado por la IA, sino ampliado.

Este será mi espacio para documentar esa búsqueda.
No es un diario técnico ni un manifiesto filosófico —es ambas cosas.
Aquí hablaré sobre cómo sobrevivir dentro del capitalismo digital sin perder la curiosidad, sobre cómo programar sin apagar la sensibilidad, y sobre cómo seguir creando cuando el mundo parece compilar en otro lenguaje.

Porque, al final, la ingeniería también es una forma de poesía.
Y en un tiempo donde los sistemas piensan por nosotros, tal vez el verdadero acto revolucionario sea seguir sintiendo mientras depuramos.

— Bernard Uriza Orozco
VHouse Founder · Software Architect · Free Intelligence Project