DEV Community: Christian Gonzales Komiya

(Spanish) Las 8 expectativas de un Arquitecto de Software

Christian Gonzales Komiya — Tue, 14 Jul 2026 22:32:20 +0000

La figura del Arquitecto de Software suele asociarse con alguien que toma decisiones técnicas importantes o diseña grandes sistemas. Sin embargo, el rol va mucho más allá de elegir tecnologías o dibujar diagramas.

Más que preguntarnos qué es un arquitecto de software, una mejor pregunta sería:

¿Qué se espera realmente de un arquitecto de software?

A continuación comparto ocho expectativas fundamentales que todo arquitecto debería cumplir. Estas ideas están inspiradas en Fundamentals of Software Architecture (2nd Edition) de Mark Richards y Neal Ford, y representan una excelente guía para quienes desean crecer profesionalmente hacia este rol.

1. 🏗️ Tomar decisiones arquitectónicas

Un arquitecto debe definir las decisiones arquitectónicas y los principios de diseño que orientarán las decisiones tecnológicas del equipo, del departamento o incluso de toda la organización.

La palabra clave aquí es orientar, no imponer.

Por ejemplo, decidir utilizar React en un proyecto es una decisión técnica. En cambio, una decisión arquitectónica consiste en establecer que el frontend debe desarrollarse utilizando un framework reactivo, permitiendo que el equipo elija entre Angular, React, Vue u otra alternativa adecuada.

El trabajo del arquitecto consiste en proporcionar el marco de decisión para que los equipos puedan tomar buenas decisiones técnicas.

Naturalmente, existen excepciones. Cuando una característica arquitectónica como la escalabilidad, el rendimiento o la disponibilidad está en riesgo, el arquitecto puede necesitar imponer una tecnología o una restricción específica.

2. 🔍 Analizar continuamente la arquitectura

Una arquitectura nunca está terminada.

Con el tiempo cambian las necesidades del negocio, aparecen nuevas tecnologías y el software evoluciona. Una buena arquitectura debe evolucionar junto con él.

También existe un fenómeno conocido como deterioro estructural (structural decay): pequeñas modificaciones realizadas por distintos desarrolladores terminan afectando características importantes como el rendimiento, la disponibilidad o la escalabilidad.

El arquitecto debe evaluar continuamente si la arquitectura sigue siendo saludable y detectar oportunidades de mejora antes de que los problemas se vuelvan críticos.

3. 🚀 Mantenerse actualizado con las últimas tendencias

Las decisiones arquitectónicas suelen tener impacto durante muchos años.

Por ello, un arquitecto necesita mantenerse actualizado sobre nuevas tecnologías, herramientas y tendencias de la industria.

Esto no significa perseguir todas las modas tecnológicas.

Significa comprender cuáles realmente aportan valor y cuáles simplemente representan una tendencia pasajera.

4. ✅ Garantizar el cumplimiento de las decisiones arquitectónicas

Diseñar una buena arquitectura no basta.

También es necesario asegurarse de que los equipos realmente la implementen.

Si cada desarrollador comienza a ignorar las reglas arquitectónicas, la arquitectura pierde coherencia y deja de ofrecer las características para las que fue diseñada.

La arquitectura requiere gobernanza, además de diseño.

5. 🌐 Comprender tecnologías diversas

No se espera que un arquitecto sea experto en todas las tecnologías.

Lo que sí se espera es que posea una visión amplia del ecosistema tecnológico.

Debe conocer distintos lenguajes de programación, frameworks, plataformas, bases de datos, herramientas de integración y soluciones en la nube para poder seleccionar la alternativa más adecuada para cada contexto.

En arquitectura suele ser más importante la amplitud del conocimiento que la especialización extrema en una única tecnología.

6. 💼 Conocer el dominio del negocio

La mejor solución técnica puede fracasar si no resuelve un problema de negocio.

Un arquitecto necesita comprender:

los objetivos del negocio;
los procesos que soporta el sistema;
las necesidades de los usuarios;
las restricciones de la organización.

Su credibilidad no depende únicamente de su conocimiento técnico, sino también de su capacidad para hablar el lenguaje del negocio.

7. 🤝 Poseer habilidades interpersonales

Una gran parte del trabajo de un arquitecto consiste en trabajar con personas.

Debe:

liderar equipos;
facilitar acuerdos;
comunicar ideas complejas;
resolver conflictos;
formar y mentorizar desarrolladores.

Como decía Gerald Weinberg:

"No matter what they tell you, it's always a people problem."

("No importa lo que te digan, al final siempre es un problema de personas").

Las habilidades técnicas son indispensables, pero el liderazgo y la comunicación son igual de importantes.

8. 🧭 Comprender y desenvolverse en la política organizacional

Las decisiones arquitectónicas casi siempre generan resistencia.

Cada equipo tiene objetivos distintos.

Cada área posee prioridades diferentes.

Y cada decisión importante afecta a varias personas.

Por ello, el arquitecto necesita desarrollar habilidades de:

negociación;
influencia;
comunicación;
construcción de consensos.

Programar implica tomar decisiones sobre el código.

Ser arquitecto implica tomar decisiones que afectan a toda una organización.

Y eso requiere mucho más que conocimientos técnicos.

🎯 Reflexión final

Muchas personas creen que convertirse en arquitecto significa dejar de programar.

En realidad, significa ampliar el alcance de las decisiones que uno toma.

Un arquitecto exitoso combina:

conocimiento técnico;
visión de negocio;
liderazgo;
comunicación;
capacidad de negociación;
aprendizaje continuo.

La arquitectura de software no consiste únicamente en diseñar sistemas.

Consiste en ayudar a que personas, equipos y tecnología trabajen juntos para construir soluciones que sigan siendo valiosas con el paso del tiempo.

📚 Referencia

Este artículo está inspirado en los conceptos presentados en la siguiente obra:

Richards, M., & Ford, N. (2025). Fundamentals of Software Architecture: A Modern Engineering Approach (2nd ed.). O'Reilly Media. ISBN: 978-1-098-17551-1.

El contenido de este artículo corresponde a una síntesis, interpretación y adaptación realizada por el autor con fines de aprendizaje y divulgación técnica. Para una explicación completa y en profundidad, se recomienda la lectura del libro.

✍️ Sobre este artículo

Este artículo forma parte de mis notas de estudio sobre Arquitectura de Software, donde comparto conceptos, aprendizajes y reflexiones obtenidas durante la lectura de libros especializados y mi experiencia profesional.

Mi objetivo es convertir estas notas en contenido práctico que pueda servir tanto a otros ingenieros de software como a mí mismo como material de consulta en el futuro.

(Spanish) Cómo piensa un agente ReAct: por qué el LLM no resuelve todo en una sola llamada

Christian Gonzales Komiya — Mon, 13 Jul 2026 13:32:35 +0000

Cuando empecé a jugar con LangGraph y un agente con tools (add, subtract, multiply), me chocó algo que parecía contraintuitivo: si le pido al LLM 5 + 8/12, el modelo no responde el resultado final de una. Hace una llamada, pide una tool, espera, hace otra llamada, pide otra tool, espera, y recién en una tercera llamada da la respuesta.

Mi primera reacción fue pensar que el modelo era "limitado" o que solo podía resolver la parte para la que tenía una tool a la mano. La explicación real es más simple y más interesante: el modelo no puede escribir una tool call cuyo argumento sea un resultado que todavía no existe. Este post explica esa idea con el ejemplo concreto que usé para entenderla.

El código base

Un agente ReAct minimalista en LangGraph, con tres tools aritméticas:

@tool
def add(a: int, b: int) -> int:
    """Herramienta de suma que agrega dos números."""
    return a + b

@tool
def multiply(a: int, b: int):
    """Función de multiplicación"""
    return a * b

tools = [add, subtract, multiply]
model = ChatDeepSeek(model="deepseek-chat").bind_tools(tools)

def model_call(state: AgentState) -> AgentState:
    system_prompt = SystemMessage(content="Eres mi asistente de IA...")
    response = model.invoke([system_prompt] + state["messages"])
    return {"messages": [response]}

def should_continue(state: AgentState):
    last_message = state["messages"][-1]
    if not last_message.tool_calls:
        return "end"
    else:
        return "continue"

El grafo conecta our_agent → tools → our_agent en bucle, hasta que should_continue ya no encuentra tool_calls en la última respuesta.

La confusión inicial: "resuelve solo una parte porque solo tiene esa tool"

Con el input 5 + 8/12, uno esperaría que el modelo "vea" la expresión completa y la resuelva de un tiro. En cambio, pasa esto:

Llamada 1 → pide divide(8, 12)
Llamada 2 → pide add(5, 0.667)
Llamada 3 → responde en texto

Da la impresión de que el modelo "hizo lo que pudo con la tool que tenía a mano, y no siguió". Pero esa lectura es engañosa. El límite no es la disponibilidad de tools — es la dependencia de datos entre los dos pasos.

La razón real: no se puede prometer un resultado futuro

Una tool call necesita valores concretos, no referencias simbólicas. El modelo no puede generar algo como:

{"name": "add", "arguments": {"a": 5, "b": "resultado_de_divide"}}

Eso no es un valor válido en el esquema de tool calling. Solo puede escribir add(5, 0.667) si 0.667 ya existe como número real en el historial. Y ese número solo existe después de que la tool divide se ejecutó y su resultado volvió como respuesta.

Por eso, en la primera llamada, lo único que el modelo puede pedir es la operación que ya tiene todos sus datos disponibles: la división. No es que "decida" resolver solo esa parte — es la única parte que puede ejecutar con la información que tiene en ese instante.

Analogía: mandarle mensajes a un amigo con calculadora

Imagina que sabes exactamente qué cuenta quieres hacer (5 + 8/12), pero no tienes calculadora — solo puedes escribirle a un amigo que sí tiene una, y esperar su respuesta antes de seguir.

Le escribes: "divide 8 entre 12". Ya sabes que después vas a sumar 5 al resultado — pero no puedes escribir eso en el mismo mensaje, porque tu amigo no interpreta instrucciones encadenadas en lenguaje natural: solo ejecuta funciones con números concretos. Así que lo único que puedes mandar es la operación cuyos números ya tienes: la división. La suma queda para el siguiente mensaje, una vez que tengas la respuesta.

Prueba de que no es "una tool por llamada"

Si el límite fuera "el modelo solo puede usar una tool por llamada", entonces con un input como:

Suma 4+2 y suma 7+8

Debería necesitar dos llamadas. Pero no es así — como ninguna de las dos sumas depende de la otra, el modelo pide ambas tool calls en la misma respuesta:

[
  {"name": "add", "arguments": {"a": 4, "b": 2}},
  {"name": "add", "arguments": {"a": 7, "b": 8}}
]

El ToolNode las ejecuta ambas sin volver a llamar al LLM entre medio. Total: 2 llamadas al LLM, no 3. Esto confirma que la regla real es "no puedo pedir algo cuyo argumento depende de un resultado que aún no existe" — no una limitación arbitraria de cantidad de tools por turno.

Qué pasa cuando falta una tool

Con 5 + 8/12, si el modelo tiene tanto add como divide, ambas operaciones las hace código Python con precisión garantizada, en 3 llamadas. Pero:

Si solo existe la tool add (no hay divide): el modelo calcula la división mentalmente (como cualquier LLM sin tools, con su propio "cálculo interno"), y usa la tool solo para la suma. Total: 2 llamadas.
Si solo existe la tool divide (no hay add): el modelo pide la división como tool call, y luego calcula la suma mentalmente con el resultado. Total: 2 llamadas.

El patrón se mantiene: el número de llamadas depende de cuántos pasos secuenciales con dependencia de datos hay — no de cuántas tools existan en total. Cuando falta una tool para un paso, el modelo simplemente resuelve ese paso con su propio razonamiento en lugar de con código, y sigue adelante.

Lo que el LLM sabe y lo que no sabe desde la primera llamada

Sí sabe, desde el inicio: qué tools tiene disponibles y sus esquemas (nombre, descripción, parámetros). Eso se manda en cada llamada — es literalmente lo que hace bind_tools(tools): adjuntar esa lista de forma fija a cada invocación.

No sabe, ni falta que sepa: cuántas llamadas totales se van a necesitar. El modelo no planea "esto me va a tomar 3 vueltas" — es reactivo, no planificador de antemano. En cada llamada individual mira el historial actual y decide un solo paso siguiente: pedir tool(s) o responder en texto. Quien determina que habrá otra llamada es LangGraph (should_continue + el edge tools → our_agent), no el modelo.

El input y output real de cada llamada

Un punto clave: el LLM nunca ve clases de Python como AIMessage o ToolMessage. Esas son abstracciones de LangChain. Lo que realmente viaja a la API es JSON con un campo role:

Clase de LangChain	`role` real
`SystemMessage`	`system`
`HumanMessage`	`user`
`AIMessage`	`assistant`
`ToolMessage`	`tool`

Así se ve la secuencia completa para 5 + 8/12 (con tools add y divide):

Llamada 1 — input:

[
  {"role": "system", "content": "Eres mi asistente de IA..."},
  {"role": "user", "content": "5 + 8/12"}
]

Llamada 1 — output:

{"role": "assistant", "content": "", "tool_calls": [
  {"id": "call_001", "function": {"name": "divide", "arguments": "{\"a\": 8, \"b\": 12}"}}
]}

Llamada 2 — input (todo lo anterior + el resultado de la tool):

[
  {"role": "system", "content": "Eres mi asistente de IA..."},
  {"role": "user", "content": "5 + 8/12"},
  {"role": "assistant", "content": "", "tool_calls": [
    {"id": "call_001", "function": {"name": "divide", "arguments": "{\"a\": 8, \"b\": 12}"}}
  ]},
  {"role": "tool", "tool_call_id": "call_001", "content": "0.6666666666666666"}
]

Llamada 2 — output:

{"role": "assistant", "content": "", "tool_calls": [
  {"id": "call_002", "function": {"name": "add", "arguments": "{\"a\": 5, \"b\": 0.6666666666666666}"}}
]}

Llamada 3 — input (historial completo hasta ahora):

[
  {"role": "system", "content": "Eres mi asistente de IA..."},
  {"role": "user", "content": "5 + 8/12"},
  {"role": "assistant", "content": "", "tool_calls": [{"id": "call_001", "function": {"name": "divide", "arguments": "{\"a\": 8, \"b\": 12}"}}]},
  {"role": "tool", "tool_call_id": "call_001", "content": "0.6666666666666666"},
  {"role": "assistant", "content": "", "tool_calls": [{"id": "call_002", "function": {"name": "add", "arguments": "{\"a\": 5, \"b\": 0.6666666666666666}"}}]},
  {"role": "tool", "tool_call_id": "call_002", "content": "5.666666666666667"}
]

Llamada 3 — output (ya sin tool_calls):

{"role": "assistant", "content": "5 + 8/12 = 5.666666666666667 (aproximadamente 5.67).", "tool_calls": []}

Nota clave: el tool_call_id (call_001, call_002) es el hilo que conecta cada tool call con su respuesta correspondiente — así el modelo sabe cuál ToolMessage responde a cuál petición suya.

Output del modelo vs. input acumulado: quién arma el historial

Algo que vale la pena separar bien: el output del LLM es solo el mensaje nuevo, no el historial repetido. model.invoke(...) te devuelve únicamente el assistant que acaba de generar.

Quien acumula todo es LangGraph, gracias al reducer definido en el estado:

class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], add_messages]

Cuando el nodo hace return {"messages": [response]}, el reducer add_messages no sobreescribe state["messages"] — hace un append. Así, para la siguiente llamada, state["messages"] ya contiene todo lo acumulado hasta ese momento, y model_call vuelve a mandar la lista completa ([system_prompt] + state["messages"]) en cada invocación.

Es la diferencia entre "el modelo te contesta una carta" y "tú guardas copia de cada carta en una carpeta, y le mandas la carpeta completa junto con la carta nueva la próxima vez".

Resumen: el patrón completo

El modelo recibe todo el historial acumulado hasta ese punto (nunca recuerda nada por sí mismo — no tiene memoria entre llamadas).
Con esa información, decide un solo paso: pedir tool(s) para las que ya tiene todos los datos concretos, o responder en texto si no falta nada.
Cada tool call se ejecuta como código Python normal (ToolNode), sin costo de LLM.
LangGraph vuelve a invocar al modelo con el historial actualizado — y el ciclo se repite hasta que la respuesta ya no trae tool_calls.
El número de llamadas al LLM depende de cuántos pasos secuenciales con dependencia de datos tiene la tarea — no de cuántas tools existan en total. Tools independientes se piden en paralelo, en una sola llamada.

Cada llamada al LLM es una petición HTTP real, facturable en tokens, y el costo de entrada crece en cada vuelta porque se reenvía todo el historial acumulado — algo a tener en cuenta al diseñar agentes con muchos pasos encadenados.

(Spanish) Dash: Monitoreo del Fenómeno El Niño

Christian Gonzales Komiya — Thu, 09 Jul 2026 21:50:19 +0000

Dash: Monitoreo del Fenómeno El Niño

Hace unas semanas quería construir un dashboard rápido para visualizar datos, y en vez de ir directo a mis herramientas de siempre (Streamlit, o armar un frontend con React), decidí probar Dash. El resultado terminó siendo un proyecto que combina dos cosas que me interesan bastante: la simplicidad de construir dashboards en Python, y un tema que como peruano me toca de cerca — el Fenómeno El Niño.

¿Qué es Dash?

Dash es un framework de Python (de la gente de Plotly) para construir aplicaciones web de datos sin escribir una sola línea de JavaScript. Bajo el capó corre sobre Flask, React y Plotly.js, pero todo eso queda oculto: tú escribes Python, defines un layout con componentes HTML y gráficos, y conectas la interactividad con callbacks (funciones normales de Python decoradas con @app.callback).

Lo que más me sorprendió:

Es sorprendentemente sencillo de aplicar. Si ya sabes armar un gráfico con Plotly, ya sabes el 70% de Dash.
Se ve increíble desde el día uno. Los gráficos de Plotly ya traen zoom, pan, range sliders y tooltips interactivos gratis — sin escribir CSS ni JS.
Todo vive en un solo lenguaje. No hay que saltar entre Python para el backend y JavaScript para la interactividad del frontend.

Con esa primera impresión, busqué un dataset con el que valiera la pena practicar. Y ahí es donde entra el segundo interés.

Por qué El Niño

Como peruano, El Fenómeno El Niño no es un tema abstracto de oceanografía: es lluvias e inundaciones en el norte del país, sequías en otras zonas, impacto directo en la pesca (nuestra anchoveta se mueve o desaparece), y en los casos más fuertes, desastres naturales que golpean carreteras, cultivos y ciudades enteras. Cada cierto tiempo el país entero está pendiente de si "viene El Niño" o no, y de qué tan fuerte va a ser.

Quería entender mejor cómo se mide esto oficialmente, y construir algo que me permitiera ver la evolución del fenómeno en el tiempo, no solo el titular de la noticia del día.

ICEN y RONI: dos formas de medir el mismo fenómeno

Investigando, encontré que no existe un solo índice para "El Niño" — hay al menos dos que se complementan:

ICEN (Índice Costero El Niño): mide la anomalía de temperatura superficial del mar frente a la costa peruana (región Niño 1+2). Lo calcula el IGP (Instituto Geofísico del Perú), y refleja las condiciones oceánicas locales que afectan directamente el clima y la pesca en el país.
RONI (Relative Oceanic Niño Index): mide la anomalía en el Pacífico central-oriental (región Niño 3.4). Lo calcula NOAA CPC (el organismo climático de EE.UU.) y es el estándar internacional para monitorear el ENOS (El Niño-Oscilación del Sur) a escala global.

¿Por qué existen ambos si miden "lo mismo"? Porque el fenómeno puede manifestarse distinto según la zona: un evento puede verse fuerte en RONI (a nivel global) pero débil en ICEN (en la costa peruana), o viceversa. Perú necesita su propio índice porque las condiciones costeras locales no siempre siguen el patrón del Pacífico central al pie de la letra.

Con ambos índices en un mismo gráfico, se puede comparar la "foto global" del ENOS con la "foto local" que de verdad le importa al país.

El proyecto: Vigía ENOS

Repo: github.com/ckomiya/vigia-enos
Demo: vigia-enos.onrender.com

La estructura del proyecto es deliberadamente simple:

etl/
  fetch_icen.py     # descarga y parsea ICEN (IGP)
  fetch_roni.py     # descarga y parsea RONI (NOAA CPC)
  transform.py      # une ambas series, categoriza y detecta eventos RONI
app/
  main.py           # dashboard Dash (single page)
data/
  raw/              # snapshots crudos descargados
  processed/        # CSVs procesados (icen.csv, roni.csv, merged.csv)

La idea fue separar completamente la obtención de datos (ETL) de la presentación (Dash). El pipeline ETL son tres scripts que se corren en secuencia:

venv\Scripts\python.exe etl\fetch_icen.py
venv\Scripts\python.exe etl\fetch_roni.py
venv\Scripts\python.exe etl\transform.py

fetch_icen.py y fetch_roni.py descargan los datos crudos directamente de las fuentes oficiales (IGP y NOAA CPC respectivamente) y los guardan como snapshots en data/raw/. transform.py toma ambas series, las une por fecha, calcula la categorización (Neutro / Cálida / Fría, según los umbrales oficiales) y detecta eventos por persistencia. El resultado es un único merged.csv que alimenta todo el dashboard.

Y del lado de la app, todo el dashboard vive en un solo archivo: app/main.py. Nada de blueprints, nada de carpetas de componentes — solo funciones de Python que arman piezas de HTML y un callback que conecta el botón de actualizar con el pipeline ETL.

El gráfico principal: serie temporal con umbrales

El corazón visual del dashboard es un gráfico de líneas con Plotly que muestra ICEN y RONI en el tiempo, más las líneas de umbral que definen cada categoría:

def build_timeseries_figure(df: pd.DataFrame) -> go.Figure:
    fig = go.Figure()
    fig.add_trace(go.Scatter(
        x=df["date"], y=df["icen"], name="ICEN", mode="lines",
        line=dict(color=COLOR_WARM),
    ))
    fig.add_trace(go.Scatter(
        x=df["date"], y=df["roni"], name="RONI", mode="lines",
        line=dict(color=COLOR_COLD),
    ))

    icen_thresholds = [
        (ICEN_FRIA_THRESHOLD, "ICEN Fría"),
        (ICEN_NEUTRA_THRESHOLD, "ICEN Neutra/Cálida déb."),
        (ICEN_CALIDA_DEBIL_THRESHOLD, "ICEN Cálida déb./Cálida"),
    ]
    for value, label in icen_thresholds:
        fig.add_hline(
            y=value, line_dash="dot", line_color=COLOR_WARM, opacity=0.5,
            annotation_text=label, annotation_position="top left",
            annotation_font_size=9, annotation_font_color=COLOR_TEXT_MUTED,
        )
    ...

Cada línea de umbral se agrega con fig.add_hline() — una sola llamada te da la línea punteada, el color, y la anotación con el texto flotando encima. Esto es lo que quiero decir con "se ve increíble sin esfuerzo": no hace falta calcular posiciones de texto ni dibujar nada a mano, Plotly lo resuelve.

También agrego un selector de rango temporal (botones de "1 año", "5 años", "10 años", "Todo") y un range slider debajo del gráfico, con una sola configuración:

fig.update_xaxes(
    range=[default_start, last_date],
    rangeselector=dict(
        buttons=[
            dict(count=1, label="1 año", step="year", stepmode="backward"),
            dict(count=5, label="5 años", step="year", stepmode="backward"),
            dict(count=10, label="10 años", step="year", stepmode="backward"),
            dict(step="all", label="Todo"),
        ],
        ...
    ),
    rangeslider=dict(visible=True, bgcolor=COLOR_PANEL, bordercolor=COLOR_GRID),
)

Esos botones y el slider son 100% interactivos desde el navegador, sin ningún callback de Dash detrás — vienen incluidos en el objeto Figure de Plotly.

Los KPIs tipo semáforo

Además del gráfico, quería una respuesta rápida a "¿cómo estamos ahora mismo?" — para eso están las dos tarjetas KPI, una para ICEN y otra para RONI, con un color de "semáforo" según el estado:

SEMAFORO_COLOR = {
    "El Niño": COLOR_WARM,
    "Cálida": COLOR_WARM,
    "Cálida débil": COLOR_WARM,
    "Neutro": COLOR_TEXT_MUTED,
    "Neutra": COLOR_TEXT_MUTED,
    "La Niña": COLOR_COLD,
    "Fría": COLOR_COLD,
}

def kpi_card(titulo: str, estado: str, valor: float, fecha_label: str) -> html.Div:
    color = SEMAFORO_COLOR.get(estado, COLOR_TEXT_MUTED)
    return html.Div(
        style=_kpi_card_style(color),
        children=[
            html.H4(titulo, style={...}),
            html.H2(estado, style={..., "color": color}),
            html.P(f"Valor: {valor:.2f} ({fecha_label})", style={...}),
        ],
    )

Aquí es donde se ve claramente el estilo declarativo de Dash: html.Div, html.H2, html.P son funciones de Python que devuelven el equivalente a las etiquetas HTML del mismo nombre, y el style es simplemente un diccionario de Python que mapea 1:1 a CSS. No hay plantillas, ni Jinja, ni archivos .html sueltos — todo es Python puro que se compone como cualquier otra función.

La tarjeta de RONI tiene un pequeño extra: no solo muestra el valor puntual más reciente, sino que detecta si hay un evento activo por persistencia (5 temporadas consecutivas cruzando el umbral de ±0.5, que es el criterio real que usa NOAA para declarar un evento El Niño/La Niña oficial, no solo un mes suelto):

def find_active_roni_event(roni_df: pd.DataFrame):
    df = roni_df.sort_values(["year", "ref_month"]).reset_index(drop=True)
    latest = df.iloc[-1]
    if pd.isna(latest["evento_roni"]):
        return None, None, None
    evento = latest["evento_roni"]
    i = len(df) - 1
    while i > 0 and df.iloc[i - 1]["evento_roni"] == evento:
        i -= 1
    inicio = df.iloc[i]
    return evento, inicio["season"], int(inicio["year"])

Es un while simple que retrocede en el tiempo mientras la categoría del evento se mantenga igual, para encontrar desde cuándo empezó la racha actual. Nada sofisticado, pero le da al KPI un contexto real ("La Niña desde DJF 2024") en vez de solo un número aislado — esa fue una de las mejoras que pedí explícitamente al iterar sobre el dashboard.

La parte reactiva: un solo callback

Todo el dinamismo del dashboard se reduce a un callback. El botón "Actualizar datos" dispara el pipeline ETL completo (los tres scripts de arriba) sin reiniciar el servidor:

@app.callback(
    Output("dashboard-content", "children"),
    Output("ultima-actualizacion", "children"),
    Input("actualizar-btn", "n_clicks"),
    prevent_initial_call=True,
)
def actualizar_datos(n_clicks):
    try:
        run_etl_pipeline()
        df = load_data()
        return build_dashboard_content(df), get_last_update_label()
    except Exception as exc:
        df = load_data()
        mensaje = f"Error al actualizar ({exc}). Mostrando últimos datos disponibles."
        return build_dashboard_content(df), mensaje

Esta es la esencia del modelo de Dash: declaras qué Input dispara el callback (el número de clics del botón) y qué Output va a actualizar (el contenido del dashboard y el texto de "última actualización"). Dash se encarga de todo el cableado — escuchar el evento en el navegador, mandar la petición al servidor, correr la función de Python, y actualizar el DOM con lo que la función devuelva. Yo nunca escribí una línea de JavaScript para lograr esto.

El try/except es a propósito defensivo: si las fuentes externas (IGP o NOAA) fallan o cambian de formato, el dashboard no se rompe — muestra un mensaje de error y sigue mostrando los últimos datos disponibles en vez de una pantalla en blanco.

Y para que el estado de "última actualización" sobreviva incluso a un reinicio del servidor, en vez de guardarlo en una variable en memoria, lo derivo directamente del mtime (fecha de modificación) del archivo merged.csv:

def get_last_update_label() -> str:
    if not MERGED_PATH.exists():
        return "Sin datos aún"
    mtime = datetime.fromtimestamp(MERGED_PATH.stat().st_mtime)
    return f"Última actualización: {mtime.strftime('%d/%m/%Y %H:%M:%S')}"

Es un detalle pequeño, pero es el tipo de decisión que evita bugs raros cuando el servidor se reinicia (por ejemplo, en un deploy) y de repente el estado en memoria ya no coincide con lo que realmente hay en disco. Fue justamente uno de los puntos donde Claude Code propuso este enfoque en vez de una variable global, al pedirle explícitamente que el estado sobreviviera a un reinicio.

Cerrando

Lo que más rescato de esta experiencia con Dash es lo poco que hubo que pelear contra el framework para lograr algo que se ve profesional: un solo archivo main.py de menos de 500 líneas contiene layout, estilos, y toda la interactividad de un dashboard con gráficos de serie temporal, zoom interactivo, KPIs dinámicos y actualización de datos en vivo. Y trabajando con Claude Code, ese "poco esfuerzo" se sintió todavía más real: pude enfocarme en decidir qué mostrar y cómo interpretarlo (los umbrales, la lógica de eventos, la UX del semáforo), mientras la implementación del layout y los callbacks avanzaba en paralelo.

Si vienes del mundo Python y quieres construir dashboards de datos sin meterte a aprender un framework de frontend completo, Dash vale mucho la pena probarlo — con o sin un agente como Claude Code de por medio — y si de paso el tema es algo que te importa como país, mejor todavía.

Repo completo, con el detalle de metodología de los umbrales (por qué ICEN usa valores fijos en vez de percentiles) en el CLAUDE.md: github.com/ckomiya/vigia-enos

(Spanish) El navegador ya no es solo para humanos

Christian Gonzales Komiya — Thu, 25 Jun 2026 23:36:21 +0000

Por qué las páginas web públicas son ahora accesibles de formas que antes eran impensables

Hubo un tiempo en que "ver algo en una web" y "usar ese dato en código" eran dos mundos separados. El primero era para humanos. El segundo requería que la empresa dueña del sitio te diera una API, documentación, credenciales, y su bendición.

Ese tiempo terminó.

Lo que descubrí explorando

Estaba analizando cómo obtener datos de una página web pública — sin registro, sin login, sin nada que el usuario promedio no pudiera ver con sus propios ojos. Información completamente pública.

El camino obvio parecía ser el scraping tradicional: descargar el HTML, parsear el contenido. Pero la web moderna no funciona así. La mayoría de sitios hoy son Single Page Applications — React, Angular, Vue — donde el HTML inicial está vacío y el contenido llega después, cargado dinámicamente por JavaScript.

<div id="root"></div>

Eso es todo lo que ves si intentas descargar el HTML directamente. Un div vacío esperando que JavaScript haga su trabajo.

La API interna que nadie documenta

Abrí las herramientas de desarrollo del browser, filtré por Fetch/XHR, y observé el tráfico. Lo que vi fue revelador: la app de React estaba consumiendo una API interna con endpoints bien estructurados, respuestas en JSON limpio, y toda la información organizada perfectamente.

Datos que visualmente aparecen en pantalla para cualquier usuario, pero que internamente viajan como JSON estructurado, listo para ser procesado.

El problema: esa API tenía protección. Un WAF (Web Application Firewall) en Azure que analizaba cada request y bloqueaba cualquier cosa que no pareciera un browser legítimo. Tokens de sesión con expiración. Cookies generadas dinámicamente. Un ecosistema de seguridad diseñado para que solo browsers reales pudieran consumir esos datos.

Y tenía razón en bloquearte — si intentabas replicar el request manualmente, para cuando copiabas todos los headers necesarios, los tokens ya habían vencido.

El agente como humano digital

Aquí entra el cambio de paradigma.

Un agente con control de browser — usando herramientas como Playwright — no simula un request. Abre un browser real. Chromium de verdad. Navega como lo haría un usuario. Las cookies se generan naturalmente. Los tokens están vigentes. El WAF ve exactamente lo que espera ver.

Pero a diferencia del humano, el agente puede hacer algo que el humano no puede: obtener y usar los datos en el mismo instante, dentro del mismo contexto de sesión.

El flujo es así:

Agente abre browser
    → navega al sitio (tokens se generan automáticamente)
    → intercepta la respuesta de la API en tiempo real
    → extrae los datos estructurados
    → los guarda en base de datos
    → cierra el browser

Todo en segundos. Sin que ningún token tenga tiempo de vencer. Sin que ningún WAF detecte anomalías. Porque técnicamente no hay ninguna.

El problema del humano vs. el agente

Cuando un humano intenta hacer esto manualmente:

Abre DevTools
Filtra el tráfico de red
Encuentra el request correcto
Copia los headers
Los pega en un cliente HTTP
Ejecuta el request

Resultado: Token vencido. Request bloqueado.

El tiempo que tarda el humano en completar esos pasos es mayor que el tiempo de vida de los tokens de sesión. Es una carrera que el humano pierde por diseño.

Cuando el agente hace lo mismo, no hay pasos separados. La obtención y el uso son una sola operación continua. El agente no anota el token para usarlo después — lo usa mientras aún está caliente, en el mismo contexto donde nació.

¿Es esto vulnerar algo?

No. Y esa es la parte más interesante del análisis.

Cualquier información que una página muestra públicamente, sin requerir autenticación, es información que el usuario tiene derecho a ver. El agente no hace nada que el usuario no pudiera hacer manualmente — simplemente lo hace más rápido y de forma programática.

La línea ética está clara:

Información pública, uso personal o académico → completamente legítimo
Automatización masiva que sature servidores → problemático
Uso comercial de datos ajenos → requiere revisar términos
Acceso a cuentas de terceros → ilegal

8 requests al día para leer información pública genera menos tráfico que un usuario humano visitando el sitio dos veces. No hay daño, no hay saturación, no hay violación.

Lo que esto significa para el desarrollo

Estamos en un momento donde la barrera entre "ver datos" y "usar datos en código" prácticamente desapareció para información pública.

Antes necesitabas:

Una API oficial con documentación
Credenciales y proceso de registro
Límites de uso negociados
Meses de espera para aprobación

Ahora necesitas:

Un agente con Playwright
Decirle qué quieres obtener
Esperar segundos

Las implicancias para el desarrollo de software son enormes. Cualquier fuente de datos pública se convierte potencialmente en una fuente estructurada para tus aplicaciones. Sin fricción. Sin burocracia. Sin depender de que la empresa decida publicar una API.

La arquitectura que emerge

Lo interesante no es solo obtener los datos una vez — es cómo esto se integra en una arquitectura completa:

Agente recopilador (cron programado)
    → navega fuentes públicas
    → extrae datos estructurados
    → guarda en base de datos local

MCP Server
    → lee la base de datos
    → expone herramientas al agente de consulta

Usuario
    → pregunta en lenguaje natural
    → el agente consulta las herramientas
    → respuesta instantánea desde datos frescos

El agente recopilador y el agente de consulta son independientes. Uno escribe, el otro lee. La base de datos es el punto de encuentro. Y el usuario final nunca sabe — ni necesita saber — de dónde vienen los datos.

Conclusión

Las páginas web públicas siempre fueron accesibles para humanos. Lo nuevo es que ahora son igualmente accesibles para agentes — y en algunos aspectos, el agente las maneja mejor que el humano.

No porque rompa barreras de seguridad. Sino porque opera dentro de los mismos canales legítimos que usa cualquier browser, pero sin las limitaciones de tiempo y coordinación que tiene un humano copiando y pegando headers.

El browser ya no es solo para humanos. Y eso cambia bastante cómo pensamos el acceso a datos en el desarrollo moderno.

Este post es parte de una exploración práctica sobre agentes de IA. Las conclusiones son aplicables a cualquier fuente de información pública en la web.

(Spanish) [App] Visualización de Denuncias en el mapa del Perú - Uso de Streamlit + Pandas + Folium

Christian Gonzales Komiya — Tue, 09 Jun 2026 15:30:56 +0000

En los últimos meses, la inseguridad ciudadana en el Perú ha ido en aumento.
Quise explorar una manera simple y accesible de visualizar esta problemática usando datos abiertos y herramientas de análisis de datos.
Este es un pequeño proyecto motivado por un dataset de denuncias policiales publicado por la Policía Nacional del Perú en la plataforma oficial de datos abiertos del Estado Peruano.

Dataset utilizado: Denuncias Policiales - Enero 2018 a Junio 2025
(También lo puedes encontrar buscando "Denuncia" en datosabiertos.gob.pe)

El dataset incluye (al corte de agosto 2025) modalidades como:

Estafa
Extorsión
Homicidio
Hurto
Robo
Violencia contra la mujer
Otros

Link de la app -> https://denuncias-pnp.streamlit.app/

🎯 Motivación
La idea nació como una forma de:

Analizar cómo han evolucionado las denuncias en el tiempo.
Ubicarlas en un mapa para identificar zonas con mayor incidencia.
Darle un formato visual e interactivo, aprovechando herramientas de código abierto.

🛠 Herramientas utilizadas

Streamlit → Framework en Python que permite crear aplicaciones web interactivas para análisis de datos de forma rápida y sencilla.
Pandas → Librería para manipulación y análisis de datos en Python. Ideal para trabajar con tablas, filtrar y agrupar datos.
Folium → Librería para generar mapas interactivos en Python usando Leaflet.js.

🌍 Visualización en mapa
La parte más llamativa del proyecto es la representación geográfica de las denuncias.
A partir de los datos filtrados por año y tipo de modalidad, se agrupan las denuncias por distrito y se dibujan círculos proporcionales a la cantidad de casos.

# --- Mapa por distrito ---
df_map_filt = df[df["ANIO"] == year]
if modalidad != "Todas":
    df_map_filt = df_map_filt[df_map_filt["P_MODALIDADES"] == modalidad]

df_map = (
    df_map_filt.groupby("UBIGEO_HECHO", as_index=False)["cantidad"].sum()
    .merge(
        df_ubigeo[["inei", "distrito", "latitude", "longitude"]],
        left_on="UBIGEO_HECHO", right_on="inei", how="left"
    )
    .dropna(subset=["latitude", "longitude"])
)

st.subheader("🌍 Mapa por distrito")
m = folium.Map(location=[-9.19, -75.02], zoom_start=5)
max_c = df_map["cantidad"].max()
for _, r in df_map.iterrows():
    radius = 3 + (r["cantidad"] / max_c) * 15 if max_c > 0 else 3
    folium.CircleMarker(
        location=[r["latitude"], r["longitude"]],
        radius=radius,
        color="crimson",
        fill=True,
        fill_opacity=0.6,
        popup=f"{r['distrito']}: {r['cantidad']}"
    ).add_to(m)
st_folium(m, width=800, height=600)

Qué hace este código:

Filtra las denuncias por año y modalidad.
Agrupa por distrito (usando el código UBIGEO) y suma la cantidad de casos.
Une la información con coordenadas geográficas para cada distrito.
Crea un mapa con círculos rojos cuyo tamaño es proporcional a la cantidad de denuncias.
Muestra un popup con el nombre del distrito y el número de denuncias.

📈 Gráfico de tendencia por tipo de denuncia
Además del mapa, la aplicación muestra un gráfico de tendencia donde se observa la evolución de cada tipo de denuncia a lo largo de los años, desglosado por departamento.
Esto permite identificar patrones, por ejemplo, si ciertos delitos han ido aumentando o disminuyendo con el tiempo.

📦 Código fuente
El código completo y los datos procesados están disponibles en mi repositorio de GitHub:
🔗 https://github.com/ckomiya/data_science_denuncias_pnp

(Spanish) Arquitectura Hexagonal (Ports & Adapters) - Beneficios y Ejemplo en Java

Christian Gonzales Komiya — Tue, 09 Jun 2026 15:22:23 +0000

Mientras leía el libro Hexagonal Architecture Explained de Alistair Cockburn y Juan Manuel Garrido, me encontré con una sección que destaca beneficios clave de este patrón.

En este artículo represento en código Java los tres pasos esenciales para implementar la arquitectura y lograr dichos beneficios.

Beneficios destacados

El sistema queda abierto a tener pruebas de regresión para todas sus funciones, de extremo a extremo.
Es posible variar las tecnologías externas conforme evolucionan (como siempre lo hacen) sin un esfuerzo enorme.
Estos dos beneficios adicionales superan fácilmente el pequeño costo extra de implementar la solución.

Paso 1 – API del sistema (interfaz proporcionada)

Creamos la aplicación para que sus servicios estén disponibles como llamadas a funciones, sin depender directamente de UI o base de datos.

// Paso 1: API del sistema (interfaz proporcionada)
public class TaxCalculatorApp {

    // Servicio principal expuesto como API
    public double calculateTax(double amount, double rate) {
        return amount * rate;
    }
}

Aquí la aplicación no sabe nada de dónde viene el rate ni de si hay base de datos: es solo lógica pura.

Paso 2 – Variables para las conexiones externas (interfaces requeridas)

Agregamos variables para cada conexión externa (por ejemplo, un servicio que da la tasa de impuestos).

// Interfaz requerida: servicio externo para obtener tasa de impuestos
public interface TaxRateProvider {
    double getTaxRate();
}

// Paso 2: la aplicación ahora tiene una variable para su conexión externa
public class TaxCalculatorApp {

    // Variable para el proveedor de tasas (actor secundario)
    private TaxRateProvider taxRateProvider;

    // Inyectamos la dependencia (aún puede ser null si no se configura)
    public void setTaxRateProvider(TaxRateProvider provider) {
        this.taxRateProvider = provider;
    }

    // Servicio principal usa la interfaz requerida
    public double calculateTax(double amount) {
        double rate = taxRateProvider.getTaxRate();
        return amount * rate;
    }
}

Ahora la aplicación no llama directamente a un servicio concreto: usa una interfaz requerida (TaxRateProvider).

Paso 3 – Configuración con actores reales o adaptadores (inyección de dependencias)

En la construcción/configuración, conectamos la app con un adaptador concreto, o con un doble de pruebas.

// Adaptador concreto que obtiene tasa desde una BD (ejemplo simple)
public class DatabaseTaxRateAdapter implements TaxRateProvider {
    @Override
    public double getTaxRate() {
        // Aquí iría la lógica real de conexión a base de datos
        return 0.21; // Ejemplo: IVA 21%
    }
}

// Adaptador doble de pruebas
public class FixedTaxRateStub implements TaxRateProvider {
    private final double fixedRate;
    public FixedTaxRateStub(double fixedRate) {
        this.fixedRate = fixedRate;
    }
    @Override
    public double getTaxRate() {
        return fixedRate;
    }
}

// Paso 3: Configuración y uso
public class Main {
    public static void main(String[] args) {
        TaxCalculatorApp app = new TaxCalculatorApp();

        // Configuración para producción
        TaxRateProvider dbAdapter = new DatabaseTaxRateAdapter();
        app.setTaxRateProvider(dbAdapter);
        System.out.println("Impuesto: " + app.calculateTax(100));

        // Configuración para pruebas
        TaxRateProvider testStub = new FixedTaxRateStub(0.10);
        app.setTaxRateProvider(testStub);
        System.out.println("Impuesto (prueba): " + app.calculateTax(100));
    }
}

✅ Qué logramos siguiendo los pasos

La app expone su lógica a través de una API clara (calculateTax), sin UI ni BD acoplada.
Creamos variables para las dependencias externas (TaxRateProvider).
Conectamos esas dependencias en tiempo de configuración, ya sea con adaptadores reales o dobles de prueba.

(Spanish) Cómo iniciar un proyecto con Claude Code

Christian Gonzales Komiya — Tue, 09 Jun 2026 15:01:25 +0000

Guía rápida para desarrolladores que quieren arrancar un proyecto de forma ordenada y sacarle el máximo provecho a Claude Code.

Este artículo no pretende ser una guía exhaustiva — es mi guía de bolsillo personal. La escribí para consultarla cada vez que inicio un proyecto nuevo y no querer recordar de memoria qué pasos seguir. Si te sirve a ti también, genial.

Fuente: Claude Code Advanced de Javier Rayon.

Paso 1 — Pre-Setup: prepara el terreno

Antes de escribir una sola línea de código, pídele a Claude que configure la estructura del proyecto.

Prompt:

Estoy comenzando un proyecto de [descripción]. Antes de programar, ayúdame a crear:
- Estructura de directorios
- CLAUDE.md con convenciones
- Scripts de desarrollo (dev, test, build)
- Configuración de linting y formateo

Claude generará algo así:

my-project/
- src/
    - routes/
    - services/
    - models/
    - utils/
- tests/
- scripts/
- .claude/
    - settings.json
    - CLAUDE.md
    - rules/
        - testing.md
        - api-patterns.md
        - security.md
    - skills/
        - deploy/skill.md
        - db-migrate/skill.md
    - agents/
        - reviewer.md
        - qa.md
    - commands/
        - COMMANDS.md

Cada carpeta tiene un propósito claro:

rules/ — lo que Claude siempre debe respetar (frameworks, patrones, seguridad)
skills/ — procedimientos reutilizables (deploy, migraciones)
agents/ — roles especializados (revisor de código, QA)
commands/ — comandos slash personalizados (/deploy, /migrate)

Ejemplo de regla (.claude/rules/testing.md):

# Reglas de Testing
- Framework: vitest (NUNCA jest)
- Convención de nombres: *.test.ts
- Toda función pública debe tener al menos una prueba

Ejemplo de skill (.claude/skills/deploy/skill.md):

# Desplegar a Producción
1. Ejecutar pruebas: `npm test`
2. Compilar: `npm run build`
3. Verificar que no haya cambios sin commit
4. Ejecutar: `./scripts/deploy.sh production`

Agrega .claude/worktrees/ a tu .gitignore desde el inicio.

Paso 2 — Plan: define qué vas a construir

Con el proyecto configurado, entra en modo planificación antes de tocar código.

/plan

Claude analizará el problema y presentará un plan detallado sin modificar nada todavía. Tú revisas, ajustas y le das luz verde.

Prompt vago (evitar):

Build a login system

Prompt específico (usar):

Plan an OAuth2 login implementation (Google and GitHub).
Requirements:
- JWT with refresh tokens
- 24h expiration
- Rate limiting of 5 attempts per minute
- E2E tests with Playwright

Técnica avanzada — revisión cruzada:

Usa dos sesiones de Claude en paralelo:

Sesión A genera el plan completo.
Sesión B lo revisa con este prompt:

Revisa este plan como si fueras un Staff Engineer.
Busca puntos débiles, casos límite no considerados
y dependencias faltantes.

Ajusta el plan con el feedback de la Sesión B antes de ejecutar.

Paso 3 — Worktrees: ejecuta en paralelo

Con el plan listo, identifica 3 a 5 tareas que puedan avanzar simultáneamente y crea un worktree para cada una.

Opción A — Worktrees manuales (control total):

git worktree add -b feature/auth ../wt-auth main
git worktree add -b feature/api ../wt-api main
git worktree add -b test/e2e ../wt-tests main

Luego lanza Claude en cada uno:

# Terminal 1
cd ../wt-auth && claude

# Terminal 2
cd ../wt-api && claude

# Terminal 3
cd ../wt-tests && claude

Opción B — Worktrees nativos de Claude (más rápido):

claude --worktree auth-feature

Claude crea la rama, el directorio y la sesión en un solo paso. Al terminar, limpia automáticamente si no hubo cambios.

Flujo de cierre:

# Cada worktree hace commit y crea su PR
git add . && git commit -m "feat: auth OAuth2"
gh pr create --title "Auth OAuth2" --body "Descripción"

# Al terminar todos, limpia
git worktree remove ../wt-auth
git worktree prune

Tip: Si en lugar de tareas puntuales necesitas cambios masivos en todo el proyecto (por ejemplo, migrar 50 archivos), usa /batch en lugar de worktrees manuales — Claude los gestiona automáticamente.

Resumen

Paso	Qué haces	Herramienta
Pre-Setup	Configuras estructura, reglas, skills y agentes	Prompt inicial
Plan	Defines qué construir y lo validas	`/plan`
Worktrees	Ejecutas tareas en paralelo	`git worktree` / `claude --worktree`