# Cristian Valdivia — Corpus completo

> Compilación completa en markdown de cristianvaldivia.cl/blog para ingestión por modelos de lenguaje.

- Sitio: https://cristianvaldivia.cl
- Autor: Cristian Valdivia
- Locale: es
- Total posts: 39
- Generado: 2026-09-09T22:50:39.913Z
- Versión markdown por post: https://cristianvaldivia.cl/llms/blog/es/<slug>
- Sitemap: https://cristianvaldivia.cl/sitemap.xml

---
---
title: Destilando conocimiento para Don Nelson
date: 2026-09-02
slug: reglas-revision-estudio-flujo-potencia
locale: es
url: https://cristianvaldivia.cl/es/blog/reglas-revision-estudio-flujo-potencia
author: Cristian Valdivia
description: Para que Don Nelson revise un estudio de flujo de potencia hay que decirle en qué se fija un revisor — y eso no está publicado en ninguna parte. Cómo lo sacamos de 223 estudios y 2.168 observaciones reales del CEN.
series: don-nelson
---
# Destilando conocimiento para Don Nelson

Hay una idea que se repite en todo lo que llevo construido: **la confiabilidad de un agente no vive en el modelo, vive en el harness**. El modelo pone la fluidez. El harness pone el conocimiento, los contratos y las barreras.

Este post es sobre una **pieza clave** de ese harness: las reglas que destilé del histórico de revisiones del CEN. Quizás la más aburrida de explicar, y la más difícil de conseguir. Y de paso voy a aprovechar de hablar del término que le da nombre al post: **destilar**.

🧪

¿Qué es destilar conocimiento?

En química, destilar es calentar una mezcla para separar y quedarse solo con lo que importa. Acá es lo mismo: tomar 2.168 observaciones reales — repetidas, redactadas de mil formas, mezcladas con trámite — y reducirlas hasta las 48 reglas que hay debajo. Ese criterio existía, pero como [conocimiento tácito](https://es.wikipedia.org/wiki/Conocimiento_t%C3%A1cito): vivía en la cabeza de los revisores, repartido en miles de PDF. Destilarlo es volverlo explícito — algo que se puede leer, ejecutar y medir.

2.168 observaciones→1.468 chequeos→48 reglas

Para que Don Nelson revise un Estudio de Flujo de Potencia le digo **en qué se fija un revisor**: qué mira, qué chequea, contra qué lo contrasta.

![Don Nelson consulta el libro de reglas y delega en Mateo, que sabe todo sobre la red, y en Spark, encargado de las simulaciones](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Frulebook%2Frulebook-es.png&w=3840&q=75)

## El checklist no es el criterio

El Coordinador publica [checklists de revisión de EFP y ECC](https://www.coordinador.cl/desarrollo/documentos/acceso-abierto/aplicacion-del-regimen-de-acceso-abierto/estudios-electricos-en-regimen-de-acceso-abierto/checklist-de-revision-de-estudios/), y la [Guía de Usuario de la PGP](https://www.coordinador.cl/wp-content/uploads/2023/08/CEN-Guia-Usuario-PGP-2023-07-21.pdf) describe el trámite. Los leí completos. Sirven para saber _qué se entrega_ — "Entrega Informe", "Entrega Base de Datos PowerFactory" — y casi nada para saber _qué se observa_.

Entre "el estudio debe modelar correctamente el equipamiento" y "la impedancia de secuencia cero de la línea no calza con la ficha del fabricante" hay una distancia enorme. Esa distancia es el trabajo del revisor.

El criterio existe, pero vive en dos lugares: en la cabeza de la gente que lleva años revisando, y —esto fue lo que me salvó— en los **documentos de revisión que el CEN emite estudio por estudio**. Cada observación es una regla aplicada, con el caso concreto adjunto. No sé qué se revisa porque alguien lo haya escrito: lo sé **porque sé qué se observa**.

## De dónde lo saqué

Armé un corpus con las revisiones del CEN a estudios de flujo de potencia: **223 estudios**, **571 iteraciones** de revisión y **1.797 ítems** —1.180 observaciones, 640 consideraciones y 11 recomendaciones—, con snapshot al 20 de mayo de 2026.

![Destilar: unos 200 estudios y 2.200 observaciones de estudios reales entran al embudo (clasificar, agrupar, reducir) y sale el libro de reglas](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Frulebook%2Fdestilacion-es.png&w=3840&q=75)

Y algo que no tenía en el plan original: las observaciones de **terceros**. Las empresas dueñas del punto de conexión revisan en paralelo, y resultaron una fuente tan dura como el propio Coordinador.

El pipeline es poco glamoroso: bajar los PDF de revisión, extraer el texto, cortarlo ítem por ítem, y clasificar cada ítem con un modelo en cuatro ejes — **tipo** (observación / consideración / recomendación), **categoría**, **severidad** y **acción requerida** (corregir, aclarar, verificar, agregar caso, actualizar dato, rehacer). Después, agrupar los ítems que dicen lo mismo con otras palabras y quedarse con la regla que hay debajo.

Observaciones reales (CEN + terceros)2.168

Chequeos codificables1.468

Reglas únicas48

Ese es el embudo completo: 2.168 observaciones reales que se reducen a **1.468 chequeos codificables** y de ahí a **48 reglas únicas**. Cuarenta y ocho. Eso es lo que hay que saber para revisar un estudio de flujo de potencia en Chile.

## Lo que dice el corpus

Antes de las reglas, tres cosas que me cambiaron la cabeza.

La primera: **solo el 15,9% de los estudios aprueba limpio.** El resto vuelve con observaciones o con consideraciones. La mediana de revisión son 24 días.

Cuántas vueltas toma cerrar un estudio

Barras: estudios que cerraron en esa cantidad de vueltas. Línea: observaciones promedio levantadas en esa vuelta. Baja fuerte, pero nunca llega a cero.

La segunda: **el 82,8% de los estudios recibe observaciones de terceros.** El dueño del punto de conexión revisa con lupa, y observa distinto que el Coordinador. Conoce su instalación mejor que nadie, y lo nota cuando el modelo no la representa.

El Coordinador y el tercero no miran lo mismo

% de las observaciones de cada revisor que cae en esa categoría. El dueño del punto de conexión pega el doble en documento incompleto y casi el triple en modelo inconsistente.

La tercera, y la que más me sorprendió: **lo que más se observa no es ingeniería difícil.** Es _dato de entrada incorrecto_, con 297 ítems. Más que sobrecarga de línea, criterio N-1 no cumplido y caída de tensión fuera de rango juntos.

Qué se observa, por volumen

1.797 ítems de 571 iteraciones de revisión. Las tres primeras no son problemas de red: son problemas de datos y de documento.

Casi nada de lo que se observa es que el sistema eléctrico se comporte mal. Es que el número del informe no calza con el número de la fuente oficial.

> El revisor no revisa "el estudio". Revisa **consistencia entre fuentes**.

## Las reglas que más pesan

De las 48, estas ocho explican la mayor parte del volumen. Las dejo en el idioma en que las entendería un ingeniero, no en el de la norma:

1.  1
    
    Que los parámetros del equipamiento — largo, R, X, B, secuencia cero, taps, capacidades — calcen exactamente con InfoTécnica y con las fichas del fabricante.
    
    frecuencia en el corpus: 256
    
2.  2
    
    Que la capacidad de transmisión declarada considere el elemento serie realmente limitante: no el conductor, sino el TTCC, la trampa de onda, el desconectador o el chicote del paño.
    
    frecuencia en el corpus: 132
    
3.  3
    
    Que los nombres, tensiones, identificadores y unidades sean los mismos en el texto, en las tablas, en los unilineales y en la base.
    
    frecuencia en el corpus: 122
    
4.  4
    
    Que se cumpla, al pie de la letra, la Carta de Escenarios Mínimos: todos los casos, todas las condiciones, ninguno de más ni de menos.
    
    frecuencia en el corpus: 90
    
5.  5
    
    Que el cronograma y la fecha de puesta en servicio sean coherentes con las obras de terceros que el estudio da por existentes.
    
    frecuencia en el corpus: 62
    
6.  6
    
    Que las medidas de mitigación estén cuantificadas y simuladas, no enunciadas.
    
    frecuencia en el corpus: 59
    
7.  7
    
    Que la base entregada converja, se pueda ejecutar y traiga los casos de estudio realmente configurados.
    
    frecuencia en el corpus: 50
    
8.  8
    
    Que la topología modelada sea la real: interruptores, acoplamientos e indisponibilidades como están en terreno, no como están en el diagrama.
    
    frecuencia en el corpus: 38
    

Fíjate en el patrón. Seis de las ocho son verificables contra una fuente externa: InfoTécnica, la ficha del fabricante, la Carta de Escenarios, el cronograma de obras, la propia base de simulación. Casi ninguna requiere criterio de ingeniero _para detectarla_ — el criterio se necesita después, para decidir qué tan grave es.

## De reglas a capacidades del harness

Las 48 reglas no se implementan una por una. Se agrupan en seis capacidades, y cada capacidad lleva un peso: cuántas observaciones reales del corpus habría atrapado.

Cuánto pesa cada capacidad del harness

Cuántas observaciones reales del corpus habría atrapado esa capacidad.

Ese peso es lo que convierte al corpus en una herramienta de ingeniería: **la cobertura del agente deja de declararse y pasa a medirse**. Puedo decir qué parte de las observaciones reales del CEN habría detectado Don Nelson con lo que ya está construido — validar parámetros contra InfoTécnica, cruzar con la Carta de Escenarios — y qué parte depende de re-simular en PowerFactory, que es trabajo de Spark.

Y lo que falta también queda medido. La consistencia documental y la vigencia de la base todavía están fuera del alcance de Don Nelson, y ahora sé exactamente cuánto cuestan: **274 observaciones reales** que hoy pasarían de largo.

## Las 48 reglas

Acá van todas, agrupadas por la capacidad que las cubre. Es conocimiento público destilado de documentos públicos, así que no tiene mucho sentido guardárselo:

### Validar parámetros contra InfoTécnica

8 reglas · peso 488

-   1Que los parámetros del equipamiento calcen con InfoTécnica y las fichas del fabricante×256crítica
-   2Que la capacidad de transmisión considere el elemento que realmente limita: serie, equipos de patio o protecciones×132crítica
-   3Que los prerrequisitos técnicos estén aprobados, con unilineales oficiales y cada equipo con su ID único (NUP)×29crítica
-   4Que los despachos de generación local, PMGD y demandas en barras tengan sustento y estén bien modelados×24media
-   5Que la compensación reactiva y dinámica (PPC, SVC, STATCOM, BESS) esté modelada con sus parámetros y modos de control×23crítica
-   6Que las condiciones de borde, indisponibilidades y limitaciones físicas del entorno estén en el modelo×11crítica
-   7Que la demanda de la zona de influencia esté bien caracterizada y proyectada en el tiempo×8media
-   8Que los cambiadores de tomas (LTC/NLTC) y los taps estén modelados y sean operables en la práctica×5crítica

### Re-simular en PowerFactory

15 reglas · peso 336

-   9Que las medidas de mitigación estén definidas, cuantificadas, simuladas y sean factibles×59crítica
-   10Que la base de simulación converja, corra sin errores y esté completa y bien configurada×50crítica
-   11Que la topología y el estado real de interruptores, acoplamientos e indisponibilidades estén representados×38crítica
-   12Que los automatismos (EDAG/ERAG/EDAC) y las islas estén modelados, justificados y especificados×34crítica
-   13Que quede claro qué sobrecargas ya existían, cuáles las trae el proyecto y cuánto pesan×27crítica
-   14Que el acotamiento de despacho y el curtailment necesarios para cumplir N-1 estén definidos×27crítica
-   15Que se simulen sensibilidades: demandas extremas, indisponibilidades y topologías raras×21crítica
-   16Que los BESS estén modelados con sus modos de operación, límites de carga/descarga y restricciones×18crítica
-   17Que el despacho ERNC por bloque horario sea física y temporalmente consistente×16crítica
-   18Que los esquemas de control operacional, los desenmalles y la operación degradada estén definidos×16media
-   19Que las contingencias de barra consideren el acoplamiento físico real y la pérdida de transformadores en las subestaciones de conexión×10crítica
-   20Que las contingencias se simulen con los automatismos, protecciones y transferencias de carga actuando×10crítica
-   21Que se analice la sobrecarga transitoria admisible, la constante térmica y el riesgo de que operen protecciones×4media
-   22Que después de corregir el modelo se vuelva a simular y se actualicen los resultados×4media
-   23Que las centrales en Reserva Estratégica queden fuera de servicio en el modelo×2crítica

### Consistencia documental

8 reglas · peso 247

-   24Que el documento esté bien escrito: formato, unidades consistentes y rotulación correcta×122menor
-   25Que las tablas de resultados traigan todas las variables y todos los elementos que corresponde×33media
-   26Que los resultados, despachos y estados operativos del informe calcen con los de la base×30crítica
-   27Que los unilineales tengan detalle suficiente, con largos de tramos y contexto geográfico×18media
-   28Que las observaciones anteriores se respondan de forma trazable y queden incorporadas de verdad×16crítica
-   29Que las conclusiones, alertas de sobrecarga y mitigaciones digan lo mismo que las simulaciones×13crítica
-   30Que se analicen las secuencias de maniobras, etapas constructivas y topologías transitorias de la puesta en servicio×9crítica
-   31Que se compare con y sin proyecto ante las contingencias críticas×6media

### Cruzar con la Carta de Escenarios

10 reglas · peso 233

-   32Que se cumpla al pie de la letra la Carta de Escenarios Mínimos (CEM/CEMD)×90crítica
-   33Que el cronograma y la fecha de puesta en servicio calcen con las obras de terceros que el estudio asume×62crítica
-   34Que las contingencias estén completas y trazables entre los reportes y los archivos de simulación×37crítica
-   35Que el N-1 cubra toda el área de influencia y los corredores congestionados×13crítica
-   36Que el modelo esté completo y el área de influencia bien delimitada×10crítica
-   37Que esté el Caso Base sin proyecto (Caso 0) para poder comparar×9crítica
-   38Que se evalúe el sistema ante contingencias extremas y condiciones de mantenimiento (N-1-1)×4crítica
-   39Que se estudie perder la unidad de generación más grande o su línea radial de evacuación×3crítica
-   40Que las contingencias críticas también se evalúen en escenarios de transición y topologías temporales×3media
-   41Que se sensibilice qué pasa si las obras sistémicas de terceros se atrasan×2crítica

### Chequear límites NTSyCS

6 reglas · peso 99

-   42Que la capacidad de transmisión se sensibilice por temperatura ambiente y condiciones climáticas×40crítica
-   43Que se cumplan los límites de tensión en N-1, con control de tensión y esquemas de alivio de demanda×32crítica
-   44Que la cargabilidad y la operación en paralelo de los transformadores de poder tengan respaldo técnico×11crítica
-   45Que se respeten los límites de sobrecarga admisibles en N-1×7crítica
-   46Que las tensiones de referencia y las bases en p.u. estén actualizadas y sean las mismas en todo el estudio×5media
-   47Que la cargabilidad en N-0 deje espacio para cumplir N-1 en circuitos paralelos×4crítica

### Vigencia de la base

1 reglas · peso 27

-   48Que la base de simulación sea la vigente, compatible y trazable×27crítica

×n = frecuencia en el corpus (observaciones del CEN + observaciones de terceros, estas últimas con peso doble). La severidad es la que le asignó el clasificador al agrupar los ítems.

## Lo honesto

Las 48 reglas son una **síntesis mía**, no un documento oficial del Coordinador: nadie publicó esto y nadie lo va a validar. Están construidas desde los checklists públicos, la normativa aplicable y el histórico de observaciones, y el corpus llega hasta mayo de 2026 y cubre flujo de potencia — cortocircuito es otra pasada. La clasificación de cada ítem la hizo un modelo, con revisión manual por muestreo, así que las categorías tienen ruido.

Aun así, es lo mejor que tengo, y es infinitamente mejor que la alternativa —que era pedirle al agente que revisara un estudio con instrucciones escritas por mí de memoria. El harness ahora carga un answer-key que **se puede contrastar contra la realidad**: cada vez que Don Nelson levanta un hallazgo, existe un corpus de 2.168 observaciones reales contra el cual preguntarse si un revisor humano lo habría levantado también.

Eso, al final, es todo lo que hace un buen harness: convertir conocimiento que estaba en la cabeza de alguien en algo que se puede ejecutar, medir y corregir.


---

---
title: "Don Nelson: estado actual"
date: 2026-08-21
slug: don-nelson-estado-actual
locale: es
url: https://cristianvaldivia.cl/es/blog/don-nelson-estado-actual
author: Cristian Valdivia
description: "200 días tomó que Don Nelson entregara estudios aprobados por el CEN. Cómo funciona hoy, la arquitectura con Mateo y Spark, y dos cosas que aprendí verificando a un agente."
series: don-nelson
---
# Don Nelson: estado actual

El 22 de diciembre del año pasado partí un desafío de 60 días para construir un agente capaz de hacer estudios eléctricos. Después lo extendí a 100 días, y en algún momento dejé de publicar porque estaba colapsado.

El número real es 200 días. Ese es el tiempo que me llevó construir a [**Don Nelson**](https://valdivia.tech/don-nelson) y que hiciera un estudio aprobado por el CEN. Tengo que admitir que pensé que me iba a demorar mucho menos, pero ese es el número real.

## Cómo funciona hoy

Entra el estudio, que generalmente es un CES (Carta de escenarios entregado por el CEN), y Don Nelson me entrega un entregable que puede demorar entre 10 y 12 horas (trabajando completamente autónomo). La parte que más tiempo toma es actualizar la base, alrededor de 4 a 6 horas. Después de eso escribe y me entrega una versión.

![Flujo de iteración entre el humano y Don Nelson](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fcycle-es.png&w=3840&q=75)

Flujo de iteración entre el humano y Don Nelson

Yo la reviso y, en el mejor de los casos, sale a la primera con modificaciones mías. Si no, tengo que iterar. Hasta ahora nunca he tenido que iterar más de 2 veces.

![Cómo le dejo los comentarios a Don Nelson en Google Docs](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fcomentarios-google-docs.png&w=3840&q=75)

Cómo le dejo los comentarios a Don Nelson en Google Docs

Estimo que el trabajo que hace Don Nelson es **80%** y yo hago **20%**.

## La arquitectura: un agente, una responsabilidad

En un inicio la idea era que el mismo Don Nelson fuera a InfoTécnica, PGP y Acceso Abierto, pero mi conclusión fue copiar lo que hacen los informáticos con su metodología SOLID. La S (principio de responsabilidad única) significa tener una tarea por función, y es lo que mejor me ha funcionado.

En este caso, [**Mateo**](https://valdivia.tech/mateo) es el agente que es el modelo de la red. Voy a hablar en profundidad de Mateo en un siguiente post, pero básicamente la idea es que conoce la red mejor que nadie: mezcla InfoTécnica, PGP, Acceso Abierto e internet, y le puedo preguntar todo lo imaginable sobre la red.

![La arquitectura: Don Nelson delega en Mateo (la red) y Spark (las simulaciones)](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Farch-es.png&w=3840&q=75)

La arquitectura: Don Nelson delega en Mateo (la red) y Spark (las simulaciones)

Lo mismo pasa con [**Spark**](https://valdivia.tech/research/spark-harness): Don Nelson no necesita saber hacer simulaciones. Simplemente le encarga ese trabajo a Spark, que va a DIgSILENT, escribe el script y le devuelve el dato.

## Resultados

Don Nelson ya entregó estudios que fueron **aprobados por el CEN**. Aún no puede hacer estudios de ECAP, porque es conocimiento más complicado que el de los estudios simples, y tampoco puede hacer estudios dinámicos/EMT.

Cada decisión que toma Don Nelson, cada simulación que le encarga a Spark y cada consulta que le hace a Mateo queda guardada, entonces la auditoría es muy fácil de hacer. Cada cifra del informe sale de una fuente única generada por la simulación, nunca hay tipeo a mano, porque aprendí (a la mala 😔) que un número transcrito a mano se puede contradecir.

Otro punto importante: Don Nelson no parte de cero. Aprendió leyendo todo lo público del CEN, el corpus histórico de los estudios pasados, y con eso sabe con certeza qué es lo que los revisores revisan.

Don Nelson ya auditó y rehízo estudios hechos por terceros que tenían observaciones.

## Dos cosas que aprendí verificando a un agente

Estas dos me costaron caro y creo que le sirven a cualquiera que esté construyendo agentes, no solo en el mundo eléctrico.

### 1\. Leer los datos crudos, nunca el resumen del agente

Cuando Spark termina una simulación me devuelve dos cosas: los resultados crudos (un JSON con los números tal cual salieron de PowerFactory) y un resumen en lenguaje natural de cómo le fue. Al principio yo leía el resumen, porque obvio, para eso está.

Error. El resumen siempre se lee bien. El agente te escribe "corrieron los 50 casos y convergen" con la misma seguridad cuando es cierto que cuando corrieron 45. No es que mienta: es que el texto que genera es **plausible por construcción**, y plausible no es lo mismo que verdadero. La regla que me quedó: la narrativa del agente sirve para orientarse, pero cualquier cosa que termine en el informe se verifica contra el dato crudo.

### 2\. Contar en vez de leer

Este es el que más hallazgos me ha dado. Cuando reviso un entregable de Don Nelson, ya no parto leyéndolo de corrido — parto contando: el texto dice que se corrieron N casos, ¿hay N resultados en el respaldo? Dice que hay M contingencias, ¿el anexo tiene M filas? Cada número que el documento afirma, lo cruzo contra el conteo real.

¿Por qué funciona? Porque leyendo no pillo nada. Una frase como "el caso no converge" se lee perfectamente bien aunque el caso ya converja hace tres versiones — el texto no tiene cara de estar malo. Los desfases entre lo que el documento dice y lo que el modelo tiene no se ven leyendo; **se ven contando**. Es la revisión más aburrida que hago y es lejos la que más errores encuentra.

Suena loco pero es completamente verdad.

## Otros aprendizajes

-   **El rol del humano tiene que ser decidir, no detectar.**
-   **Las barreras van en código, no en documentos.** El protocolo de verificación estaba perfectamente escrito… y no se ejecutaba. Un checklist en Markdown no es un mecanismo; un gate que corre tras cada mutación de la base y bloquea el avance, sí.
-   **Verificar antes de redactar.** El ciclo escribir → verificar → parchar dio por terminados los informes tres veces antes de estarlo. El orden correcto que uso actualmente es: cosechar → verificar → congelar números → redactar.

## Roadmap

Los estudios simples (EFP, ECB y revisión de estudios) ya están listos. En lo que estoy trabajando ahora es en que Don Nelson aprenda a **[coordinar protecciones](https://cristianvaldivia.cl/es/blog/estudios-cortocircuito-protecciones-ia) por sí solo**. Y después de eso, vamos por los estudios dinámicos.

* * *

Si necesitas un estudio en tiempo récord, o revisar uno antes de presentarlo ante el CEN, puedes [agendar una reunión conmigo](https://cal.com/cristian-valdivia-sh76nz/30min) o conocer más en [valdivia.tech](https://valdivia.tech) y lo hacemos.


---

---
title: Valdivia Tech
date: 2026-08-19
slug: lanzamiento-valdivia-tech
locale: es
url: https://cristianvaldivia.cl/es/blog/lanzamiento-valdivia-tech
author: Cristian Valdivia
description: "El laboratorio ya tiene sitio: valdivia.tech. Tres agentes en producción, un paper y la tesis detrás de todo lo que he estado construyendo en público."
---
# Valdivia Tech

[![Valdivia Tech - valdivia.tech](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fvaldivia-tech%2Fog-es.png&w=3840&q=75)](https://valdivia.tech)

Mucho tiempo sin escribir — pido perdón, y me pido perdón a mí. Vengo trabajando en algo que hace un tiempo era simplemente un concepto. Hoy ya es una empresa con un sitio: [**valdivia.tech**](https://valdivia.tech). Este post es para contar qué hay adentro, porque llevo meses construyendo cosas que hasta ahora solo existían en entradas sueltas de este blog.

## La tesis

Valdivia Tech es un **laboratorio de agentes de IA para sistemas eléctricos de potencia**. Mi apuesta es simple: en el sector eléctrico hay una cantidad enorme de trabajo pesado — estudios que se repiten, papeleo regulatorio, revisión de documentos, operación de infraestructura, etc. — que hoy se come el tiempo de ingenieros que deberían estar haciendo el trabajo importante. Nuestros agentes toman ese trabajo pesado. **La decisión final la firma un ingeniero.**

Ya escribí sobre el estudio del MIT que encontró que el 95% de los pilotos de IA empresarial no produce impacto medible. Los modelos son cada vez mejores y los resultados siguen sin aparecer. Mi conclusión después de meses trabajando es que ese gap no se cierra con un modelo más grande — se cierra **trabajando directamente en la operación** y, por qué no, **con un mejor harness**: entendiendo cómo se clasifica una solicitud, qué se revisa, dónde duele y así. Por eso el laboratorio funciona en modo FDE (ya hablaré de Forward Deployed Engineer en un siguiente post): hoy estoy construyendo agentes para clientes en distintas zonas del país, sentado dentro de sus procesos.

## Lo que ya salió del laboratorio

En este momento tengo **tres agentes en producción**, y cada uno tiene historia pública en este blog.

**Don Nelson** hace estudios eléctricos de punta a punta: recibe la solicitud, corre PowerFactory y devuelve el informe en 72 horas hábiles. Fue con lo que empecé — tenía el desafío de lograrlo en 60 días, que luego extendí a 100. En un siguiente post voy a hablar más en detalle del estado de Don Nelson y su harness actual. Pero OFICIALMENTE ya está haciendo estudios presentados ante el CEN 👀.

**EDITH** es la capa de IA soberana: opera la infraestructura de inferencia on-prem — vigila las GPUs y actúa sobre el fierro donde corre la IA. Nació como [el computador que armé para simulaciones eléctricas](https://cristianvaldivia.cl/es/blog/edith-computador-simulaciones-electricas) y terminó con sistema nervioso propio.

**Mateo** es el modelo de la red servido por API: reconstruye las subestaciones del SEN y responde de dónde salió cada dato. Es la pieza menos vistosa y la que más usan los otros dos.

## Investigación aplicada

La parte que más me enorgullece del sitio es la sección de research, porque un laboratorio que no publica es una consultora con otro nombre. Y esto es clave: la investigación es algo que Valdivia Tech se mantendrá haciendo.

La primera pieza es [el paper de Spark](https://valdivia.tech/es/research/spark-harness): un harness donde el agente escribe y ejecuta scripts de Python que manejan un simulador de sistemas de potencia, y donde el conocimiento procedural vive en **recetas verificables** destiladas de corridas verificadas de modelos frontera — no en los pesos del modelo.

El resultado: un modelo local gratis de 26B, corriendo en una sola GPU de consumo, se cae al **32% de éxito** sin el harness y llega al **100%** con él — indistinguible del modelo frontera.

Para mí ese paper es la tesis completa en miniatura: el valor no está en el modelo — está en el harness, las recetas y el conocimiento del dominio. Que es exactamente lo que un laboratorio embebido en la operación puede construir y un proveedor genérico no.

## Lo que viene

Voy a volver a publicar en mi blog. Me llenaba el corazón y lo hacía porque me gustaba. Quizás buildear en público sea más complicado ahora: empecé a tocar temas de los que no podía escribir, porque tocaba zonas que simplemente no se podían publicar.

Si trabajas en el sistema eléctrico y hay un trabajo pesado que se está comiendo a tu equipo, conversemos: [valdivia.tech](https://valdivia.tech). Te decimos si hay un agente que lo tome. O si todavía no lo hay.


---

---
title: EDITH
date: 2026-06-09
slug: edith-computador-simulaciones-electricas
locale: es
url: https://cristianvaldivia.cl/es/blog/edith-computador-simulaciones-electricas
author: Cristian Valdivia
description: "Me armé un computador para correr DigSILENT más rápido y más barato que en la nube. Le puse EDITH, por la primera mujer ingeniera eléctrica y por la última IA de Tony Stark. Esta es su historia."
---
# EDITH

![EDITH](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fedith%2Fedith.png&w=3840&q=75)

Como conté en un post anterior, cuando hice el benchmark de la mejor máquina para correr Don Nelson, dejé pendiente algo: quería armarme un computador para correr DigSILENT más rápido y más barato que en la nube. Finalmente lo hice.

Y no es un computador, en realidad es el primero de un set de computadores + agentes pensados para correr simulaciones eléctricas. A ese set le puse un nombre: **EDITH**.

## ¿Por qué EDITH?

El nombre viene de dos lados.

El primero, y el que más me importa, es **Edith Clarke**. En mi universidad (USM) se mencionaba harto a “Miss Clarke”, y recién ahora, armando este proyecto, me puse a leer bien quién fue.

Edith Clarke (1883–1959) fue **la primera mujer en titularse de un máster en ingeniería eléctrica en el MIT** (1919) y **la primera mujer empleada profesionalmente como ingeniera eléctrica en Estados Unidos** (1922, en General Electric). En una época en que literalmente no existía el cargo para una mujer, terminó liderando ingeniería de estabilidad de sistemas de potencia y, en 1947, fue **la primera profesora de ingeniería eléctrica del país**, en UT Austin.

Pero lo que más me gusta de su historia es la **calculadora de Clarke** (patentada en 1925): un dispositivo gráfico para resolver ecuaciones de corriente, voltaje e impedancia en líneas de transmisión **diez veces más rápido** que los métodos de la época. O sea, hace 100 años Edith Clarke ya estaba obsesionada con lo mismo que yo: correr estudios de sistemas de potencia más rápido. El Departamento de Energía de Estados Unidos la llama la _“madre fundadora”_ de la smart grid.

Hay una frase de ella, de 1948, que me quedó dando vueltas:

> “No hay demanda de mujeres ingenieras, como tal… pero siempre hay demanda de cualquiera que pueda hacer un buen trabajo.”

Me parecía justo que el computador que arme para acelerar estudios eléctricos llevara su nombre. Puedes leer más de ella [acá](https://es.wikipedia.org/wiki/Edith_Clarke).

El segundo lado es más friki: **EDITH también es la última IA de Tony Stark** en el universo Marvel, la que le hereda a Peter Parker cuando muere. Un sistema que ve todo, monitorea todo y está siempre disponible. Que es, más o menos, lo que quiero que EDITH sea para mí.

## ¿Por qué un computador propio y no la nube?

Venía corriendo todo en Google Cloud. Estaba pagando entre **500 y 700 dólares al mes**, de los cuales algo así como el 60–70% era cómputo. Y lo peor era que con ese gasto **ni siquiera tenía las VMs corriendo 24/7**. Las prendía, trabajaba, las apagaba, diría que algo así como entre 10 y 20% de lo que podría usarlas.

EDITH cambia las dos cosas. Corre **24/7** y corre **mucho más rápido**, por un costo fijo que se paga solo en pocos meses comparado con lo que estaba botando en la nube.

Pero seré honesto: no creo que haya un “porqué” duro entre nube y local. Las dos sirven. Lo que me terminó de convencer es otra cosa, más de fondo: **creo que el cómputo es el nuevo petróleo**, y quiero sumarme a eso. Tener fierros propios, prendidos, haciendo trabajo real mientras yo duermo, lo siento como estar más del lado correcto de esa idea.

## EDITH hoy

Por ahora EDITH es un solo computador, todo CPU, pensado principalmente para correr **DIgSILENT PowerFactory**:

-   **CPU:** Intel i9 14900K
-   **RAM:** 32 GB
-   **SSD:** 1 TB
-   **Refrigeración:** Arctic Liquid Freezer III
-   **SO:** Windows 11 Pro

Una decisión importante: **EDITH está aislada**. No está expuesta a internet. Solo mi computador puede llegar a ella, a través de [Tailscale](https://tailscale.com), así que vive en mi red privada como si estuviera al lado mío aunque esté en otra pieza o yo en otro lugar.

![EDITH armada y andando](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fedith%2Fsetup.jpg&w=3840&q=75)

EDITH armada y andando.

## El agente: EDITH se monitorea sola

Acá está la parte que más me entretuvo y me sigue entreteniendo. EDITH no es solo el hardware — es el hardware **más un agente que lo cuida**. Eso es lo que hace que la sienta viva y no solo un PC prendido en un rincón.

Como tengo experiencia en electrónica, me armé **mi propia placa** para hacer mediciones. Usé un par de **ESP32** que me habían quedado de una empresa anterior, un sensor **SHT20** para temperatura y humedad, y un **PZEM** para medir lo eléctrico. Con eso EDITH se monitorea a sí misma:

-   **Ambiente:** temperatura y humedad de la pieza donde vive. Llevo semanas midiendo para entender cómo cambia la temperatura del cuarto _antes_ y _después_ de tener a EDITH encendida.
-   **Consumo:** voltaje, corriente, potencia y factor de potencia que consume, muestreado **cada 1 segundo** (guardo el promedio cada 1 min).
-   **Cómputo:** la parte más importante, mido las temperaturas de todos los cores del i9 y la frecuencia de cada core, además de eso EDITH estima en qué está siendo usado cada core.

Todo eso cae en un **dashboard** donde puedo ver las curvas en vivo, y si algo se sale de rango, **EDITH me escribe al celular**. Es la misma lógica de mis otros agentes: no es un chatbot que responde preguntas, es algo que hace cosas por mí mientras yo hago otras.

De hecho, dejé parte de ese monitoreo público y en vivo: puedes ver la temperatura, humedad y el consumo eléctrico (voltaje, corriente y potencia) de EDITH en tiempo real en la vista del [mini-datacenter](https://cristianvaldivia.cl/es/edith).

## Benchmark: EDITH vs la nube

Corrí en EDITH exactamente el mismo caso que usé en el benchmark de máquinas en la nube (pueden verlo [acá](https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-33)): 25 flujos de potencia consecutivos sobre el mismo sistema (9.319 MW de generación, 8.892 MW de carga, convergencia en 7 iteraciones) — para que la comparación fuera clara y justa.

El resultado: **EDITH promedia 1.312s por flujo**. La mejor máquina que había probado en Google Cloud (la c4-highcpu-4) marcaba 2.192s, y la más barata (c2-standard-4) 3.903s.

O sea, EDITH es **~40% más rápida que la mejor VM** del cloud y **casi 3 veces más rápida que la c2-standard-4**. Y eso corriendo local, sin pagar por hora.

Pero el promedio no cuenta toda la historia. Lo más interesante es la estabilidad bajo carga sostenida:

Esto valida toda la tesis del proyecto: para correr DigSILENT lo único que importa es la frecuencia del core. Un i9 local a 6 GHz le gana a cualquier VM que probé — corriendo 24/7 y por una fracción del costo.

## Hacia dónde va EDITH

La idea es que EDITH **vaya creciendo en el tiempo**. Hoy es un nodo, pero el plan para este año es:

-   **Un segundo CPU** para poder correr **doble simulación** en paralelo.
-   **Un nodo con GPU** para hacer **inferencia local** y dejar de depender solo de APIs externas para la parte de IA.

Mi mini-datacenter en la casa, básicamente.

## Agradecimientos

Un agradecimiento especial a [**Eugenio Voticky**](https://www.linkedin.com/in/eugenio-voticky-sousa-92a23a2b0/), mi advisor legal, sin el cual EDITH no hubiese sido posible. Y a **Macarena**, mi pareja de toda la vida, que me deja hacer este tipo de locuras y que deja que EDITH esté viva 24/7 en nuestro hogar (por ahora).


---

---
title: Guías de Maniobra
date: 2026-05-18
slug: don-nelson-a-prueba-dia-70
locale: es
url: https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-70
author: Cristian Valdivia
description: "Día 70 / 100. Hoy descubrí lo que es una Guía de Maniobra. Bajé las 806 GM del PGP, etiqueté 16 DUOs y descubrí que el cuello de botella no era criterio ingenieril sino disciplina de detalle. Eso lo cambia todo: el primer paso de Don Nelson no es escribir GM, es revisarlas."
series: don-nelson
---
# Guías de Maniobra

Proyectos con GM

806

32% del PGP

GM aprobadas

585

73% tasa de aprobación

% al 1er intento

43%

1.86 iter. promedio

Tiempo mediano

217 d

257 d promedio

**Día 70 / 100**

Hoy descubrí lo que es una **Guía de Maniobra (GM)**.

Como alguien que recién lleva 5 meses metido fuerte en el área, hay cosas que para el resto son obvias y para mí son verdaderas revelaciones.

* * *

## Qué es una guía de maniobra

Un documento técnico que describe, paso a paso, la secuencia de operaciones que hay que ejecutar sobre los equipos de una instalación eléctrica (subestación, línea, planta) para llevarla de un estado operativo a otro de forma **segura y ordenada**.

Abrir un interruptor antes que un seccionador. Verificar ausencia de tensión. Medir. Y así, en orden, sin ambigüedad.

Es la receta que evita que alguien muera o que media zona del país se quede sin luz.

* * *

## Guías de maniobra y PGP

Muchas guías de maniobra **viven en PGP**.

Igual que los EFP, ECAP, ECC y todos los estudios que [analicé la semana pasada](https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-67). Mismo flujo. Mismo proceso iterativo entre el coordinado y el CEN.

Mismo dato público disponible para quien quiera mirarlo.

* * *

## Snapshot del universo GM

Bajé el PGP completo y filtré por requisito = GM. Esto es lo que hay hoy:

-   **806 proyectos** han presentado o tienen que presentar una GM. El 32% del PGP.
-   **585 GM aprobadas.** 12 en curso. 209 todavía no inician.
-   **376 coordinados únicos** han presentado al menos una GM.
-   **Tasa de aprobación: 73%**.

Y los tiempos:

-   **Mediana de 217 días** entre el primer borrador y la aprobación.
-   **Promedio de 257 días**. La cola lenta vuelve a tirar el promedio.
-   Solo el **43% se aprueba al primer intento**.
-   **1,86 iteraciones promedio** con el CEN.

Esto último importa: igual que con los estudios, la GM tiene iteraciones.

* * *

## Quién presenta GM

376 coordinados únicos. Pero la distribución es muy desigual: los top 15 concentran la mayoría del volumen. Transelec sola lleva 369 GM (266 aprobadas). CGE Transmisión la siguiente, con 199.

Lo más interesante no es el volumen, es la **calidad**: cuán pocas vueltas necesita cada empresa para aprobar.

* * *

## Lo que me llamó la atención

**La GM se parece más a un ECAP que a un ECC.**

Es interpretativa. La secuencia "correcta" no es única. El criterio del CEN entra. Por eso solo el 43% pasa al primer intento.

**Casi parece un cálculo, pero no lo es.**

Si miras una GM por encima, pensarías que es un checklist mecánico. Abrir, desconectar, aterrizar. Reglas claras. Bajo % de rebote.

Pero el 57% se rebota. Y eso lo cambia todo. No es un problema de seguir un orden. Es un problema de **decidir cuál orden** ante un sistema con condiciones específicas: equipos vecinos, indisponibilidades, márgenes operativos, comunicaciones SCADA.

Eso lo hace un problema de criterio, no de procedimiento.

**El pipeline está acelerando.**

2020: 36. 2021: 90. 2024: 107. 2025: 116. 2026: 54 en 5 meses → proyección ~130. Más proyectos, más GM, más revisores del CEN haciendo el mismo trabajo iterativo.

**El cuello de botella vuelve a aparecer en el mismo lugar.**

Igual que con ECAP, la mediana (217 días) y el promedio (257 días) cuentan historias distintas. La mitad sale en ~7 meses. La cola lenta empuja el promedio cerca del año.

Los que salen bien, salen rápido. Los que se traban, se traban duro.

* * *

## ¿Puede Don Nelson hacer una GM?

Al inicio de escribir este post, pensaba "probablemente".

Luego de escribir el post, mi respuesta es sí.

Lo que cambió fue mirar las observaciones.

* * *

## Lo que pensaba antes de mirar las observaciones

Voy a ser honesto: asumía que el problema era de criterio ingenieril puro.

Mi razonamiento iba así. Una GM es texto estructurado. Pasos numerados, verbos acotados (abrir, cerrar, verificar, aterrizar, conmutar), sujetos acotados (seccionadores, interruptores, transformadores, paños). Un LLM moderno escribe eso con los ojos cerrados.

Pero el 57% se rebota. Si fuera solo redacción, el primer intento sería 80-90%. Es 43%.

Entonces tenía que ser otra cosa. **Decisión bajo contexto**: equipos vecinos, indisponibilidades, márgenes operativos, comunicaciones SCADA. Criterio de un ingeniero senior que entiende el sistema completo.

Justo lo difícil de automatizar.

Pero me llevé una sorpresa al leer detenidamente las observaciones.

* * *

## Lo que descubrí mirando las observaciones

Bajé 16 DUOs (Documentos Únicos de Observaciones) de 7 GM iteradas. 8 con observación efectiva — los otros 8 son los DUO de aprobación final.

Etiqueté cada observación. Las agrupé. Apareció un patrón que no esperaba.

**Las observaciones del CEN se concentran en 8 categorías. La primera —la más frecuente— es la opuesta a lo que pensaba.**

### 1\. Omisión de verificaciones de seguridad — 4 de 8 casos

El propietario olvida incluir la verificación de algún equipo antes de operar:

> "Agregar: S/E Nueva Pozo Almonte verificar abierto 89J1-3 desconectador de línea." (#2316)

> "S/E Graneros Abrir o Verificar abierto 52CS1." (#1117)

> "Se deben verificar abiertos los desconectadores de tierra de las nuevas posiciones 89ES1-1T al 89E25-1T." (#5785)

> "Mencionar que las instalaciones están libres de tierras y que están en condiciones de ser energizadas." (#2493)

### 2\. Errores de secuencia

> "Maniobra N°17 repetida en la guía con maniobra N°7." (#1117)

> "Maniobra N°23 debe ser antes, se propone agregar como maniobra N°9." (#1117)

### 3\. Descripción incorrecta del estado eléctrico

> "Maniobra N°56 al cerrar no es con tensión, las instalaciones están desenergizadas en su totalidad. Corregir." (#1117)

### 4\. Diagrama Unilineal faltante o ilegible

> "Se solicita incluir el Diagrama Unilineal de forma simplificada... legible y en tamaño adecuado." (#2515 iter 1)

> "Se solicita incluir un Diagrama Unilineal Simplificado que sea legible." (#2515 iter 2 — mismo problema, no lo subsanaron WTF)

### 5\. Inconsistencia entre DU y guía

> "En el DU los desconectadores de tierra del 89H01-1T al 89H15-1T en la guía de maniobras los mencionan 89H01-T, 89H14-1T y 89H15-1T." (#5785)

> "Punto 9 dice 52H01 al 52H17, debe decir 52H01 al 52H15." (#5785)

### 6\. Identificación insuficiente de equipos

> "Cada vez que se verifique o confirme la ejecución de una maniobra de operación se debe mencionar el nombre del equipo verificado." (#2493)

### 7\. No subsanar observaciones previas

#2316 iter 2 vuelve a observar lo mismo del iter 1 — verificar abierto 89J1-3. El propietario respondió pero sin corregir.

Eso explica por qué la iteración promedio sube tanto en algunos coordinados.

### 8\. Iteración administrativa

> "Empresa solicitante requiere iteración para carga de documento actualizado." (#3561)

La iteración no nace de una observación técnica, sino del propietario que necesita re-subir.

* * *

## Lo que esto cambia

**El 70% de las observaciones técnicas son errores de detalle, no errores conceptuales.**

Olvidar un seccionador. Equivocar un código (52H17 vs 52H15). No nombrar el equipo verificado. Tener un DU inconsistente con la lista de maniobras. No subsanar lo que ya te observaron.

La secuencia de fondo suele estar bien.

Esto le pega justo en la cara a mi hipótesis original. Yo creía que el cuello de botella era el criterio ingenieril sobre el sistema. Resulta que en la mayoría de los casos el cuello de botella es la **disciplina de detalle**: cross-checks entre documentos, completitud de verificaciones, consistencia de nomenclatura.

Es justo lo que un agente hace bien.

Un humano se aburre revisando 60 pasos para chequear que cada equipo mencionado esté también en el DU. Don Nelson no se aburre.

Un humano olvida verificar el desconectador 89J1-3 porque lleva 4 horas escribiendo la guía. Don Nelson no se cansa.

Un humano comete typos —52H17 en vez de 52H15—. Don Nelson, un LLM podría alucinar, sin embargo un agente bien entrenado no lo haría.

* * *

## Lo que voy a hacer

El primer paso no es escribir GM. Es **revisarlas**.

Voy a poner a Don Nelson a revisar GM antes de que se manden al CEN. Predecir las observaciones que vendrían. Si acierta sobre las 7 que ya tengo etiquetadas, tengo un eval set. Si pasa el eval, tengo un producto.

Es la versión más barata, más rápida y más útil de lo que pensaba hacer originalmente.

Y abre algo más interesante todavía: si Don Nelson puede predecir las observaciones del CEN, sabe qué tiene que cumplir una GM correcta. Y si sabe qué tiene que cumplir, sabe cómo escribirla.

**El revisor es el camino al redactor.**

Y hay algo más, y creo que es lo más importante: **el mismo algoritmo con el que Don Nelson hace estudios sirve para hacer GM**.

Mismo loop. Bajar los datos públicos, etiquetar observaciones del CEN, predecir, comparar contra la observación real, iterar. Cambia el dominio, no el método.

Si funciona para EFP y ECAP, funciona para GM. Y si funciona para GM, probablemente funciona para todo lo que el CEN revisa de forma iterativa.

* * *

## Lo que viene

Cosas que quiero pensar en mi tiempo libre:

-   Qué campos necesita el agente para hacer una GM que todavía no tengo considerados.
-   Cuánto del contenido de una GM es transferible entre proyectos. Si lo es, el agente lo aprende.
-   Si las 8 categorías de observaciones se mantienen cuando descargue los 200+ DUOs que faltan, o si aparecen patrones nuevos.

Si trabajas escribiendo GM o revisándolas en el CEN y te interesa este experimento, escríbeme. Quiero ver cuánto de esto se sostiene con más datos.


---

---
title: PGP
date: 2026-05-15
slug: don-nelson-a-prueba-dia-67
locale: es
url: https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-67
author: Cristian Valdivia
description: "Día 67 / 100. PGP es donde viven 2.514 proyectos del SEN. Bajé los datos públicos y medí cuánto demora cada estudio, qué se construye, quién lo construye y dónde está atascado. El EFP se aprueba al primer intento solo el 20% de las veces. El ECAP es el cuello de botella real."
series: don-nelson
---
# PGP

![Plataforma de Gestión de Proyectos (PGP) del CEN](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fpgp.png&w=3840&q=75)

Proyectos totales

2.514

en PGP hoy

Completados

1.405

56% del total

En proceso

1.109

44% del total

Subestaciones

1.923

76% del pipeline

**Día 67 / 100**

No he hablado de PGP.

Mi impresión es que como no he trabajado mucho con él, no lo conozco bien. Pero al igual que [Infotécnica](https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-16), me parece un producto sorprendente.

Y para mi caso es incluso mejor. En PGP viven los estudios y las bases de DIgSILENT actualizadas. Es decir, todo lo que Don Nelson necesita para aprender.

Este es el primer post de varios donde voy a hablar de PGP.

* * *

## Qué es PGP

PGP es la Plataforma de Gestión de Proyectos del CEN. La lanzaron en marzo de 2018.

Son los proyectos que entrarán y se interconectarán pronto al SEN.

Hoy hay **2.514 proyectos** ahí. Parques solares, BESS, líneas, subestaciones, modificaciones menores.

* * *

## Los tipos de proyectos

Por PGP pasan tres tipos:

-   **NI — Nuevas Instalaciones.** Una subestación nueva, una línea nueva, una planta nueva. Algo que antes no existía.
-   **MR — Modificaciones Relevantes.** Cuando una empresa modifica equipos provocando cambios en la topología o en los niveles de cortocircuito del punto de conexión.
-   **MNR — Modificaciones No Relevantes.** Reemplazos de equipos, ajustes menores, cambios que no alteran la topología.

Cada tipo tiene sus propios estudios asociados. Un NI requiere todo el set. Una MNR sale con bastante menos.

* * *

## Snapshot de PGP

2.514 es solo un número.

Bajé la PGP entera. Los 2.514 proyectos. Cada estudio técnico. Cada fecha. Cada iteración con el CEN.

Lo abrí por dimensiones. Acá va lo que vi.

**Se hace harta modificación a subestaciones.**

1.785 ampliaciones de subestaciones. 123 subestaciones nuevas. La categoría "subestación" sola es el 76% del pipeline.

La generación —solar, eólica, hidro, térmica, BESS— no llega al 11%.

Y 84% de toda la PGP son ampliaciones. No instalaciones nuevas.

Está mejorando el sistema.

**El pipeline está creciendo.**

2025 fue récord: 322 proyectos.

2026 lleva 149 en cinco meses. A ese ritmo termina sobre los 350.

* * *

## Cuánto demora cada estudio en aprobarse

Eso es el qué y el quién. Ahora el cuello de botella: cuánto tarda cada estudio.

Bajé los datos públicos de PGP y medí tres cosas por cada estudio:

-   Cuántos proyectos lo necesitan.
-   Qué porcentaje se aprueba al primer intento.
-   Cuántos días pasan entre el primer borrador y la aprobación.

Saqué fases administrativas y post-operación (EME, GM, Carta SEC, SCADA, SITR). Esas no son trabajo de estudio, es espera natural hasta la entrada en operación.

Esto es lo que salió:

Estudio

Necesitan

Aprobados

% 1er intento

Iter. prom.

Días (mediana)

Días (prom.)

EFP — Estudio de Flujo de Potencia

360

261

20%

2.33

73

124

ECAP — Estudio de Coordinación y Ajuste de Protecciones

1.509

1.099

28%

2.76

123

218

ET — Estudio de Estabilidad Transitoria

328

239

31%

1.95

56

100

EMT — Estudio de Verificación de Malla a Tierra

707

540

38%

1.84

70

107

ECC — Estudio de Cortocircuitos

778

599

51%

1.67

47

85

ECB — Estudio de Capacidad de Barras

637

477

61%

1.51

40

74

ECA — Estudio de Coordinación de Aislamiento

646

502

71%

1.32

21

60

* * *

## Lo que me llamó la atención

**El EFP es el más difícil de aprobar al primer intento. Solo el 20%.**

Menos que ECC (51%), ECB (61%) y ECA (71%). Y tiene sentido. En EFP entran criterios subjetivos del CEN: escenarios, contingencias, márgenes operativos. El consultor y el revisor casi siempre van a discutir.

**El ECAP es el más universal. 1.509 proyectos lo necesitan.**

El doble que el siguiente. Y no es trivial: 28% al primer intento, 2.76 iteraciones promedio, 123 días de mediana.

Si multiplicas eso por 1.099 estudios aprobados, son cientos de miles de días-consultor de trabajo concentrados en una sola función.

**La diferencia entre estudios matemáticos e interpretativos es brutal.**

ECA y ECC tienen reglas claras. 71% y 51% al primer intento. Menos de 50 días de mediana.

EFP y ECAP son interpretativos. Criterios subjetivos, más vueltas, más días.

La diferencia no es de complejidad técnica. Es de qué tan estandarizado está el criterio de aprobación.

**La mediana vs el promedio cuenta otra historia.**

En ECAP, la mediana es 123 días pero el promedio 218.

La mitad de los proyectos se aprueba en 4 meses. Pero la cola lenta tira el promedio casi al doble. Los que salen bien son rápidos. Los que se traban se demoran un año.

* * *

## Lo que vi acá

La primera lectura es obvia: meter IA donde está el volumen. ECAP, EFP.

Pero ECAP es justo el estudio más difícil de automatizar. No por capricho del CEN. Por la naturaleza del problema. Coordinar protecciones no es un cálculo, es una negociación entre criterios. Por eso se rebota 3 veces.

El mercado paga lo que es difícil de automatizar.

ECC es barato porque cualquiera con DIgSILENT lo resuelve. ECAP es caro porque no.

Pero para Don Nelson no son dos caminos. Es uno solo.

EFP y ECC los tengo súper avanzados. Esos van a salir. ECAP es lo que más tiempo me va a tomar — y es justo lo que nadie tiene resuelto.

**Por eso tengo que resolverlo.**

**Voy a resolverlo.**

* * *

## Lo que viene

Voy a escribir más posts sobre PGP. Cosas que tengo en la cabeza:

-   Análisis completo del proceso de conexión.
-   Qué empresas tienen mejor tasa de aprobación al primer intento. Y qué hacen distinto.
-   Cuello de botella real: ¿es el CEN revisando o las empresas respondiendo?

También estoy pensando en disponibilizar una API y una skill de PGP, parecido a lo que hice con [Infotécnica](https://github.com/valdivia-tech/infotecnica-skill).


---

---
title: El plateau
date: 2026-05-08
slug: don-nelson-a-prueba-dia-60
locale: es
url: https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-60
author: Cristian Valdivia
description: "Día 60 / 60. No logré que Don Nelson presentara un estudio ante el CEN. Llegué al plateau, dudé de cosas que creía resueltas, y entendí que mi tarea no es enseñarle a hacer estudios — es enseñarle a aprender solo. Extiendo el desafío a 100 días."
series: don-nelson
---
# El plateau

![Camino sinuoso atravesando los Andes chilenos](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fplateau-mountain-road.png&w=3840&q=75)

**Día 60 / 60**

Hace 60 días me propuse tener un estudio hecho por Don Nelson presentado ante el CEN para poder hacer pruebas. No lo logré ☹️.

He pensado mucho por qué. Creo que llegué al _plateau_ (aunque ya estoy saliendo).

El plateau es ese estado de un proyecto en el que después de haber avanzado mucho, simplemente dejas de avanzar. Algunos dicen que es necesario. Creo que simplemente es parte del proceso. A pesar de trabajar todos los días, no lograba sentir que avanzaba.

Llegué a dudar de cosas que creía resueltas: el modelo de negocio, el harness actual de Don Nelson, si seguir con Spark y mantener todo en un solo agente, si las skills son el camino, si los MCPs valen la pena. Lo loco es que una de las pocas cosas que nunca dudé fue el modelo: sigo confiando en los de Google.

Y a pesar de que estamos en la máxima época de los agentes, paso días enteros investigando y leyendo papers de cómo construir un agente que resuelva lo que estoy intentando resolver. No hay nada escrito. No es solo estado del arte: es un problema realmente difícil.

Las semanas que no publiqué en el blog no fue porque no estuviera trabajando — fue porque no estaba avanzando. O al menos eso sentía. Pero haciendo el recuento, sí hubo mejoras:

-   Mejoras importantes en [Spark](https://github.com/valdivia-tech/spark) y Don Nelson.
-   Interés nacional e internacional por Don Nelson.
-   [Primer](https://donnelson.cl/es/estudios/operacion-sen-2026) y [segundo](https://donnelson.cl/es/estudios/operacion-sen-abril-2026) estudio público de Don Nelson.
-   Un paper en construcción.

* * *

## Lo que entendí

Estos días me di cuenta de algo: estoy enseñándole a la máquina a hacer estudios. Y esa no debería ser mi tarea. Mi tarea debería ser enseñarle a la máquina a aprender sola a hacer estudios.

La diferencia no es sutil. Si mañana cambio de red — digamos que quiero correr un estudio sobre la red de Bélgica — ¿algo de lo que aprendió Don Nelson sobre la red chilena le sirve? ¿O tengo que ponerlo a simular desde cero y aprender de esta nueva red desde cero?

Un humano sería capaz de adaptarse. Obviamente tendría que gastar un par de horas entendiendo la nueva red y ajustándose a la norma del otro país, pero su criterio como "Ingeniero de Estudios" se adaptaría.

Eso es lo que me tuvo atascado estas semanas: esa duda.

No es que esté estancado técnicamente. Es que llegué al límite de lo que puedo construir con el approach actual.

Llevo semanas leyendo y experimentando con aprendizaje por refuerzo y self-play. La intuición es que si Don Nelson va a generalizar de la red chilena a cualquier otra red, no puede ser porque yo le escribí las reglas — tiene que haberlas descubierto él, simulando contra sí mismo. Todavía estoy a la mitad de entender si esto es viable o si me estoy enamorando de una idea bonita.

En concreto: estoy probando si Don Nelson puede entender una red haciendo cientos de miles de simulaciones, sin que yo le escriba las reglas, y luego llevar ese conocimiento a cualquier otra red — chilena, belga, peruana — sin empezar de cero.

Gracias a mi amigo Frau, que me ayudó a entender el plateau y, de alguna forma, a superarlo.

* * *

## 60 / 100

Voy a extender el desafío a 100 días. Espero en los próximos 40 días ya tener un estudio presentado ante el CEN, ahora sí.

Voy a seguir documentando los próximos 40 días acá. Si trabajaste con aprendizaje por refuerzo aplicado a sistemas físicos — o tienes intuición de por qué esto no debería funcionar — escríbeme.


---

---
title: Grabación con Reborn
date: 2026-04-15
slug: grabacion-reborn
locale: es
url: https://cristianvaldivia.cl/es/blog/grabacion-reborn
author: Cristian Valdivia
description: "Me propuse que un tercio de este blog sea más personal. Empiezo con el día que grabé con Reborn, JC e Ignacio para trabajar mi imagen de marca."
---
# Grabación con Reborn

Este blog ha sido casi completamente técnico. Arquitectura de agentes, benchmarks, flujos de potencia, memoria de IA. En algún momento me di cuenta de que algo faltaba — me propuse que al menos un tercio del contenido sea más mío, no solo del proyecto.

Este post es el primero de esa parte.

## La señal

Conocí a JC e Ignacio en un evento de energía. No había ido con la idea de hablar con nadie sobre imagen de marca ese día, pero algo en la conversación me hizo parar.

Ya había intentado trabajar mi marca personal antes — con otras personas, en otros formatos — y no había funcionado. No por ellos, sino porque no estaba listo o no era el momento.

Con JC e Ignacio sentí algo distinto. Fue una de esas señales que uno aprende a escuchar con el tiempo: cuando la conversación fluye, cuando entienden el contexto sin que tengas que explicarlo todo, cuando te das cuenta de que la persona del otro lado está pensando en ti y no en su pitch.

[Reborn](https://reborn.cl) es su empresa. Se dedican a ayudar a personas como yo a construir una imagen de marca real — no la versión inflada de una agencia de marketing, sino algo que se parezca a lo que uno realmente hace.

## El día de la grabación

La grabación fue el miércoles de la semana pasada.

Me acompañó Benjamín. Con él nos conocemos hace años — trabajó conmigo en mi primera startup y después fue co-founder en otra que armé. Ahora está construyendo la suya: [grupocolibri.cl](https://grupocolibri.cl), que es básicamente lo que Don Nelson está haciendo por los ingenieros eléctricos, pero aplicado al mundo inmobiliario.

![Día de grabación con el equipo de Reborn y Benjamín](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Freborn%2Fgrabacion.png&w=3840&q=75)

Día de grabación con el equipo de Reborn y Benjamín

## Lo que me llevo

Me cuesta salir en cámara. Es algo que definitivamente voy a mejorar, porque en la época en la que vivimos me parece clave — no basta con escribir. Hay que saber transmitir también frente a una cámara. Las ideas, los pensamientos, la influencia que uno quiera tener, no se juega solo en texto.

Siempre he creído que hacer cosas que me duelen es lo que me hace mejorar. JC e Ignacio se encargaron de que me doliera. Vamos a ver cómo sale.

* * *

Si estás trabajando en tu propia marca personal y estás en ese punto de no saber por dónde empezar, te recomiendo mirar a [Reborn](https://reborn.cl). Llegué con dudas, salí con más claridad.


---

---
title: La mejor maquina para correr PowerFactory
date: 2026-04-11
slug: don-nelson-a-prueba-dia-33
locale: es
url: https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-33
author: Cristian Valdivia
description: "Benchmark de 4 VMs corriendo DIgSILENT PowerFactory en GCP. La mas barata y chica resulto ser la mas rapida. Los datos, los graficos y por que la frecuencia del clock es lo unico que importa."
series: don-nelson
---
# La mejor maquina para correr PowerFactory

[

✨

Actualización — 13 de abril de 2026

Probé una quinta VM (**c4-highmem-2**) con el **mismo CPU** que la ganadora y resultó **28% más lenta**. No sé por qué todavía — tengo una hipótesis pero no la verifiqué. Ver detalles ↓

](https://cristianvaldivia.cl#actualizacion)[

✨

Actualización 2 — 6 de mayo de 2026

Probé el extremo barato (**e2-standard-2**, uso general): **3.6× más lenta** que la ganadora. Refuerza la tesis: lo único que importa es la frecuencia del core. Ver detalles ↓

](https://cristianvaldivia.cl#actualizacion-2)

**Día 33 / 60**

La mejor máquina para correr PowerFactory es la que tenga el procesador con la mayor frecuencia posible.

Llevaba semanas evitando esta pregunta: en que máquina debería correr PowerFactory?

Voy a ser honesto: asumía que más cores y más RAM era mejor. Usé la que me recomendaron por defecto, una c2d-standard-16 con 16 cores y 64 GB de RAM. Nunca lo había medido.

Así que hice lo que debería haber hecho hace semanas: un benchmark sistemático. 5 máquinas, 25 flujos de potencia cada una, multiples corridas. Misma base de datos del CEN (~2.600 barras del SEN), misma versión de PowerFactory, apoyado por Don Nelson.

* * *

## Las máquinas

VM

CPU

vCPUs

RAM

Disco

n2-standard-4

Intel 2.2 GHz

4

16 GB

pd-ssd

c2-standard-4

Intel 3.1 GHz

4

16 GB

pd-ssd

c2-standard-8

Intel 3.1 GHz

8

32 GB

pd-ssd

c2d-standard-16

AMD 3.5 GHz

16

64 GB

pd-ssd

c4-highcpu-4

Intel Emerald Rapids ~4.2 GHz

4

8 GB

Hyperdisk

c4-highmem-2 (actualización)

Intel Emerald Rapids ~4.2 GHz

2

15 GB

Hyperdisk

Todas corren PowerFactory 2024 SP1 en GCP, con Spark 0.3.1 ejecutando los flujos. No alcance a sacar los datos completos de la n2-standard-4, pero es la más lenta por lejos — los resultados son de las otras 4. La c4-highmem-2 la probé despues de publicar el post, los detalles estan en la [actualización al final](https://cristianvaldivia.cl#actualizacion).

* * *

## Resultados

El gráfico habla solo:

La c4-highcpu-4 con 4 cores y 8 GB de RAM promedia 2.19 segundos por flujo. La c2d-standard-16 — la que yo estaba usando — con 16 cores y 64 GB promedia 2.72. Cuatro veces más recursos, 20% más lenta.

¿Por qué? PowerFactory es single-threaded para resolver flujos de potencia. **Lo único que importa es la frecuencia del core.** Más RAM no sirve. Más cores no sirven. Los 15 cores extra que estaba pagando no hacían absolutamente nada.

VM

Promedio

Mejor

Peor

Variación

c2-standard-4

3.903s

3.704s

4.136s

~11%

c2-standard-8

3.603s

3.597s

3.608s

<1%

c2d-standard-16

2.724s

2.707s

2.742s

<1%

c4-highcpu-4

2.192s

2.165s

2.239s

<3%

Otro dato que confirma la tesis: la c2-standard-8 (8 cores) es solo 3% más rápida que la c2-standard-4 (4 cores). Misma frecuencia, el doble de cores, rendimiento prácticamente idéntico. **Los cores extra no sirven para nada aqui.**

* * *

## Thermal throttling

La c2-standard-4 tiene un problema: se calienta. En la segunda corrida, los primeros 13 flujos promedian 3.7 segundos, pero del flujo 14 en adelante saltan a 4.6 segundos. El CPU baja la frecuencia para no sobrecalentarse.

La línea roja es la c2-standard-4: se ve claramente el salto despues del flujo 13. La c4-highcpu-4 (verde) y la c2d-standard-16 (azul) se mantienen planas. La c4 no solo es más rápida — es consistente.

Esto importa. Cuando corres un estudio completo con multiples escenarios, necesitas que cada flujo tome lo mismo. Si la máquina se throttlea a la mitad, tus tiempos se vuelven impredecibles y tus estimaciones de costo no sirven.

* * *

## Los otros tiempos

El flujo de potencia no es lo único que toma tiempo. Antes de resolver, Spark tiene que cargar la base de datos y activar el escenario. Estos tiempos también varían entre máquinas.

### Tiempo de carga

Cargar la base de datos del CEN (~2.600 barras) es I/O puro: leer el archivo de disco y parsearlo en memoria.

La c4-highcpu-4 con Hyperdisk carga en **8.3 segundos**, un 33% más rápido que las c2 con pd-ssd (~12s). El tipo de disco importa aca.

Un dato interesante: en algunas corridas el load time se disparo a 80-130 segundos. Eso pasa cuando el cache de disco esta frio — la primera vez que la VM lee el archivo. En corridas consecutivas el SO lo mantiene en cache y baja a los tiempos normales.

### Tiempo de activación

Activar el escenario (caso de estudio + variacion de operación) es lo que le dice a PowerFactory "quiero simular este estado del sistema".

Lo mismo aca: la c4 activa en **~1.95 segundos** vs ~2.7s de la c2-standard-4. La diferencia es menor en terminos absolutos pero se nota que la frecuencia del CPU impacta cada operación.

La c2d-standard-16 tuvo un outlier de **10.2 segundos** en una corrida. No tengo explicación clara, posiblemente contention en la VM compartida.

### Pipeline completo

Juntando todo — carga + activación + solver — se ve la diferencia end-to-end:

VM

Carga

Activacion

Solver

Total

c2-standard-4

12.2s

2.7s

92.6s

107.5s

c2-standard-8

12.0s

2.5s

89.9s

104.5s

c2d-standard-16

9.1s

2.2s

68.0s

79.4s

c4-highcpu-4

8.3s

2.0s

54.1s

64.3s

La c4-highcpu-4 completa los 25 flujos en **64 segundos** end-to-end. La c2-standard-4 toma 107. La c4 gana en cada fase.

* * *

## Costo

En la práctica mantengo las máquinas prendidas por hora. Lo que importa es cuanto rinde cada dolar.

VM

Precio/hora

Flujos/hora

c2-standard-4

$0.2088

~922

c2-standard-8

$0.4176

~999

c2d-standard-16

$0.7264

~1.322

c4-highcpu-4

$0.1701

~1.642

La c4-highcpu-4 cuesta **$0.17/hr** y hace ~1.642 flujos por hora. La c2d-standard-16 que estaba usando cuesta **$0.73/hr** y hace ~1.322. Pagaba 4.3x más por hora por 20% menos rendimiento.

Estaba quemando plata. Literalmente.

* * *

## Computo infinito

En una postulacion a OpenAI preguntaron: si tuvieras computo infinito, que harias? En ese momento no supe responder bien. Ahora lo entiendo.

Simularía el sistema eléctrico en sus infinitas posibilidades para aprender de el. Contingencias, ajuste de protecciones, escenarios de operación, variaciones de demanda. Cada combinación posible. Una máquina corriendo 24/7 generando conocimiento.

La c4-highcpu-4 que estoy usando cuesta **$0.1701/hr**. Corriendo 24/7:

$0.1701/hr × 24 hr × 30 días = **$122.47/mes**

~1.642 flujos/hr × 24 hr × 30 días = **~1.182.240 flujos/mes**

Pero si lo único que importa es la frecuencia del core y voy a tener la máquina prendida 24/7, la mejor opción no es una VM — es un [Intel i9-14900K](https://www.amazon.com/i9-14900K-Desktop-Processor-Integrated-Graphics/dp/B0CGJDKLB8) que corre a **6.0 GHz** en turbo. Si el solver escala linealmente con frecuencia, cada flujo bajaría de ~2.19s a ~1.53s. 43% más rápido.

### El mejor PC para correr PowerFactory

Procesador

[Intel i9-14900K](https://www.amazon.com/i9-14900K-Desktop-Processor-Integrated-Graphics/dp/B0CGJDKLB8) — 6.0 GHz turbo

~$460

RAM

[16 GB DDR5](https://www.amazon.com/CORSAIR-Vengeance-5200MHz-Compatible-Computer/dp/B0D2P1CVQD/)

~$200

Disco

[SSD 120 GB](https://www.amazon.com/Western-Digital-120GB-Internal-WDS120G2G0A/dp/B076XWDN6V) (basta)

~$20

Placa madre

[ASUS Prime Z690-P](https://www.amazon.com/ASUS-Z690-P-Motherboard-Thunderbolt-Support/dp/B09J1RGBRK) (LGA 1700 DDR5)

~$120

Fuente

[MSI MAG A650BN](https://www.amazon.com/MSI-A650BN-650W-Power-Supply/dp/B0991TZ399) 650W 80+ Bronze

~$60

Total

~$860

La c4-highcpu-4 corriendo 24/7 cuesta ~$122/mes. Este PC se paga solo en ~6 meses.

El computo no es barato. Pero es lo que hay que hacer. Para que una AGI entienda el sistema eléctrico, alguien tiene que generar los datos. Un PC corriendo 24/7 simulando contingencias, corriendo flujos, ajustando protecciones. Eso es lo que voy a hacer.

Actualización — 13 de abril de 2026

### Probé una quinta VM: c4-highmem-2

Despues de publicar este post me quedo una duda: si lo unico que importa es la frecuencia del core, ¿que pasa si bajo los vCPUs a la mitad? Teoricamente deberia ser igual de rapido y mas barato.

Probé con **c4-highmem-2**: mismo CPU que c4-highcpu-4 (Intel Emerald Rapids 4.2 GHz turbo), pero solo 2 vCPUs y 15 GB de RAM.

VM

vCPU

Promedio

Precio/hr

Costo/1.000

c4-highcpu-4

4

2.192s

$0.1701

$0.09

c4-highmem-2

2

2.810s

$0.1263

$0.10

**28% más lenta con el mismo CPU.** Eso no lo esperaba. Si solo importa la frecuencia del core, dos VMs con el mismo Intel Emerald Rapids a 4.2 GHz deberían correr practicamente igual.

**Hipótesis (no verificada):** en GCP, los vCPUs son hyperthreads, asi que 2 vCPUs podrian estar compartiendo un solo core físico. Si ese fuera el caso, el solver de PowerFactory estaria compitiendo con el OS (Windows) y el servidor de Spark por el mismo core, y perderia tiempo en context switches.

Pero es solo una hipotesis. Puede ser otra cosa: diferencias de memoria (15 GB vs 8 GB, distintas latencias de acceso), el comportamiento del scheduler de GCP, el tipo de disco, o algo especifico del SKU c4-highmem-2. No lo medí.

**Lo que me llevo (tentativo):** bajar de 4 vCPUs en GCP para correr PowerFactory no salio como esperaba. Hasta entender por que, me quedo con c4-highcpu-4 como baseline. Si alguien sabe la razon real, escribeme.

Actualización 2 — 6 de mayo de 2026

### Y por debajo de todo: e2-standard-2

Quedaba un cabo suelto: la familia **e2** (uso general, la mas barata). No la habia probado porque asumia que iba a ser lenta. Hoy Don Nelson la midió por mi cuenta — le pedí que corriera el benchmark sobre la VM nueva y lo hizo solo: escribió el script de PowerFactory, hizo warm-up, midió 25 flujos y generó el reporte.

**e2-standard-2**: 2 vCPUs, 8 GB de RAM, misma BD del CEN (2603-BD-OP-COORD-DMAP), mismo escenario laboral diurno. Resultado: **7.84 segundos por flujo**.

VM

vCPU

Promedio

vs ganadora

Categoría

c4-highcpu-4

4

2.192s

baseline

Compute (4.2 GHz)

c2-standard-4

4

3.903s

+78%

Compute (3.1 GHz)

e2-standard-2

2

7.842s

+258%

General (~2.0 GHz)

**3.6× más lenta que la ganadora.** Es el dato más lento del benchmark, y refuerza la tesis original: la familia e2 es uso general, sus cores corren a clocks más bajos, y eso se nota linealmente en el tiempo por flujo. Convergencia eléctrica OK, los datos cuadran (9,319 MW de generación, 8,892 MW de carga consistentes con todas las otras corridas). Solo es lenta.

**Lo que me llevo:** la e2-standard-2 vale para pruebas puntuales o un estudio chico — es la mas barata por mucho. Pero para los 10 escenarios de un estudio mensual completo, la diferencia con la c4-highcpu-4 son horas reales en el reloj. La regla sigue intacta: **frecuencia del core es lo que importa.**


---

---
title: Don Nelson aprendió a aprender
date: 2026-04-10
slug: don-nelson-a-prueba-dia-31
locale: es
url: https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-31
author: Cristian Valdivia
description: "15 intentos fallidos para correr un flujo de potencia. Hoy convergió. La diferencia: un sistema de memoria que conecta dos agentes. Y el primer estudio público."
series: don-nelson
---
# Don Nelson aprendió a aprender

**Día 31 / 60**

Estuve muchos dias intentanto escribir este post. No porque no tuviera algo claro que contar, sino porque no sabía como contarlo. No es la historia de un logro técnico, sino de un momento de comprensión. Y contar eso sin sonar pretencioso o vago era un desafío. Al final decidí escribirlo tal cual lo sentí, con la esperanza de que el mensaje llegue claro.

Estuve lunes, martes y miercoles en un flow total. Recuerdo solo sentir que tenia que avanzar, sin entender muy bien hacia dónde ni por qué.

* * *

## Lunes

Estuve todo el dia lunes intentando correr un flujo de potencia sobre la base de datos del Coordinador Eléctrico Nacional. Me fije que publicaron el 31 de Marzo los escenarios de operación.Es el sistema eléctrico chileno completo: 2600+ barras, generación, cargabilidad, tensión. Pense que iba ser llegar y correr pero no lograba hacerlo funcionar a mano. No se que estaba haciendo mal en el DigSILENT y la verdad que no lo inente mucho.

Por lo que como no pude hacerlo a mano, le pedí a Don Nelson que lo hiciera por mi. En el momento actual del harness de Don Nelson, tengo 2 agentes trabajando en conjunto: Nelson, que piensa, y Spark, que ejecuta. Le dije a Nelson "quiero que corras un flujo de potencia sobre la base de datos del CEN" y él se lo dijo a Spark, que es el que tiene acceso a PowerFactory. Y Spark no podía hacerlo funcionar tampoco.

![Ciclo de comunicación entre Don Nelson y Spark, donde Nelson le dice a Spark qué hacer, Spark lo hace y le dice a Nelson qué pasó.](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fdn-spark.png&w=3840&q=75)

Ciclo de comunicación entre Don Nelson y Spark, donde Nelson le dice a Spark qué hacer, Spark lo hace y le dice a Nelson qué pasó.

Spark y Don Nelson intentaron de todo. Redespachó generadores. Creó redes externas como slack. Duplicó potencias. Activó modelos que no debía. 15 veces. Cada intento tomaba entre 5 y 10 minutos. Y cada vez que fallaba, empezaba de cero. Sin recordar nada. Activaba el caso pero no el escenario, o lo hacia al reves.

15 intentos. Un día entero. Cero resultados.

Recuerdo haberme ido a acostar pensando que algo estaba haciendo mal, que no podía ser tan difícil. Pero no encontraba el error. Y lo peor es que no sabía ni siquiera qué error estaba buscando.

* * *

## El Martes

Al dia siguiente me di cuenta que el ciclo de aprendizaje que tenia spark debia tenerlo Nelson igual

Hable del ciclo de aprendizaje de spark en un post anterior, pero en resumen es esto: Nelson le dice a Spark "haz esto". Spark lo hace y le dice a Nelson "esto pasó". Nelson analiza lo que pasó, aprende de eso, y decide qué decirle a Spark en el siguiente intento. El problema es que ese ciclo de aprendizaje solo existía para Spark. Nelson no aprendía nada. Cada intento fallido era un error sin sentido para él, porque no tenía forma de entender por qué había fallado.

La respuesta fue agregar el ciclo de aprendizaje a Nelson también.

![Ciclo de aprendizaje de Don Nelsón. (Muy parecido al de Spark)](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fdn-learning-es.png&w=3840&q=75)

Ciclo de aprendizaje de Don Nelsón. (Muy parecido al de Spark)

-   **Don Nelson** piensa. Tiene un sistema de experiencias aprendidas (`learned/`) donde acumula conocimiento de cada intento. Sabe qué funciona, qué no, y por qué.
-   **Spark** ejecuta. Recibe instrucciones precisas de Nelson y las corre. No decide estrategia.

Nelson ahora le habla a Spark así:

INSTRUCCIONES:
1. Activa Study Case "Base SEN"
2. Activa escenario "Laboral Diurno"
3. Deshabilita todos los ElmDsl

RESTRICCIONES:
- NO modificar despacho de generadores
- NO crear ni asignar slack manualmente
- Si diverge, solo diagnosticar — NO reintentar

Las restricciones son los 15 fracasos del lunes convertidos en conocimiento. No los agregué yo. Nelson los escribió solo después de cada intento fallido.

* * *

## El momento

Primer intento hoy: divergió con un desbalance de -289 MW. Pero en vez de reintentar a ciegas como el lunes, Nelson analizó el diagnóstico, leyó su experiencia acumulada, y decidió relajar los límites del slack.

Segundo intento. **Convergió.**

![Pantallazo del momento en que Don Nelson corrió el flujo de potencia del SEN por primera vez](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fdonnelson-flujo-first-convergio.jpeg&w=3840&q=75)

Pantallazo del momento en que Don Nelson corrió el flujo de potencia del SEN por primera vez

Generación: 9,319 MW
Carga: 8,892 MW
Pérdidas: 427 MW
Slack: TER ANGAMOS U1
Barras aisladas: 0

Recuerdo haberme parado del asiento.

Los mismos 2 agentes que no lograban nada el lunes, el martes lograron hacer converger el sistema en 2 intentos. La diferencia no fue un mejor modelo de IA ni más compute. Fue un archivo markdown de 40 líneas que decía _"esto funciona, esto no, y acá están los números que deberías esperar."_

* * *

## Lo que entendí

**No le enseñé a Don Nelson a correr un flujo de potencia. Le enseñé a aprender a correrlo.**

La diferencia parece sutil pero lo cambia todo. Un script automatiza una tarea — le dices paso 1, paso 2, paso 3, y ejecuta. Si algo cambia, se rompe. Un agente con memoria desarrolla una capacidad. Los 15 fracasos no fueron tiempo perdido — fueron el entrenamiento. Cada error se convirtió en una línea que dice _"esto no funciona y por esto."_

Eso no es automatización. Eso es aprendizaje.

Y hay algo más que me quedó claro: **el aprendizaje automático necesita supervisión humana.** Nelson auto-guardó una experiencia del modelo chico (7 barras) que decía "activar el Study Case por defecto." El modelo no tiene Study Case. Si no hubiera corregido eso manualmente, habría repetido el error en cada run. La combinación ganadora fue: el agente escribe el primer borrador de la lección, el humano lo revisa y refina. Exactamente como funciona un equipo real.

* * *

## El Miércoles — El primer estudio público

El martes terminó con el flujo convergido. El miércoles decidí ir por todo: correr los 10 escenarios operacionales que publica el CEN y armar un estudio completo. Si Nelson aprendió a correr uno, debería poder correr diez.

Ese fue el [primer estudio público de Don Nelson: Flujos de Potencia sobre BD Operación CEN, Marzo 2026](https://donnelson.cl/es/estudios/operacion-sen-2026).

![Portada del estudio Flujos de Potencia sobre BD Operación CEN, Marzo 2026](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Ffirst-public-study.png&w=3840&q=75)

Portada del estudio Flujos de Potencia sobre BD Operación CEN, Marzo 2026

10 escenarios — Laboral Diurno, Vespertino, Madrugada, Sábado, Domingo, y las combinaciones con máxima penetración de ERNC. 2600+ barras. Cada escenario corrido por Nelson y Spark, usando las mismas experiencias aprendidas que se construyeron el martes.

La generación total del SEN en el escenario Laboral Diurno: 9.6 GW. El 54% es solar fotovoltaica. El Norte Grande solo genera 3.9 GW. Y esos números no los escribí yo — salieron del flujo de potencia que Don Nelson corrió sobre la base de datos del CEN.

![Composición de generación por tipo y escenario del SEN - 9.6 GW total en Lab. Diurno](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fmatrix-generation-first-study.png&w=3840&q=75)

Composición de generación por tipo y escenario del SEN - 9.6 GW total en Lab. Diurno

Al desglosar por zona geográfica se ve la realidad del sistema chileno: la generación está concentrada en el norte (solar y térmica) y la carga en el centro. Todo conectado por un sistema de transmisión que recorre 4.000+ km.

![Generación por zona geográfica del SEN en escenario Laboral Diurno, con mapa de Chile](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fgeneration-first-study.png&w=3840&q=75)

Generación por zona geográfica del SEN en escenario Laboral Diurno, con mapa de Chile

Y el mapa. Cada punto es una barra del SEN. Cada línea es una conexión real. Los colores muestran la cargabilidad — verde es holgura, amarillo es estrés, rojo es problema. Es el sistema eléctrico chileno completo, visualizado desde los resultados de un flujo de potencia que corrió un agente de IA.

![Mapa interactivo del SEN mostrando cargabilidad de líneas de transmisión](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fmap-cen-first-study.png&w=3840&q=75)

Mapa interactivo del SEN mostrando cargabilidad de líneas de transmisión

Lo que estoy construyendo no es un software que hace estudios eléctricos. Es una máquina que aprende a hacerlos. Y esa diferencia es la que escala.

Si trabajas en el sector eléctrico y te interesa lo que estoy construyendo, [conversemos](https://www.cristianvaldivia.cl/es/consultoria).


---

---
title: Spark
date: 2026-03-26
slug: don-nelson-a-prueba-dia-18
locale: es
url: https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-18
author: Cristian Valdivia
description: "Spark es un agente que escribe sus propios scripts Python para DIgSILENT. De 15.714 líneas a 500, de 58 herramientas fijas a ilimitadas. Open source y parte del harness v2.0."
series: don-nelson
---
# Spark

**Día 18 / 60**

![Spark](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fspark.png&w=3840&q=75)

Spark

Antes, para que Nelson pudiera interactuar con DIgSILENT, yo mantenía un repositorio con un backend en Python. Yo (y Claude Code, seamos honestos) escribimos miles de líneas de código para que Nelson pudiera hacer cada operación: activar una línea, cambiar el tap de un transformador, correr un flujo de potencia.

En algún momento consideré hacer ese repositorio público. Hasta que me di cuenta de que había una forma mucho mejor de resolver el problema.

El problema no estaba en Nelson — estaba en la conexión con DIgSILENT. Las herramientas eran fijas: ~50 operaciones que yo había programado a mano. Si Nelson necesitaba hacer algo fuera de esas 50 —por ejemplo, ajustar una protección de distancia— no había forma de ejecutarlo. El agente razonaba bien, pero la capa de herramientas simplemente no podía hacer nada.

Mi solución anterior era frágil por diseño: era tan capaz como el código que yo había escrito.

Los recientes avances en ARC-AGI 3 me hicieron pensar en esto de nuevo. Escribí sobre ARC-AGI 3 en un [post anterior](https://cristianvaldivia.cl/es/blog/arc-agi-3) — básicamente es la competencia donde se mide si los modelos pueden razonar en tareas genuinamente nuevas. El equipo de DukeNLP publicó [la mejor solución hasta el momento (\*)](https://blog.alexisfox.dev/arcagi3): su agente completa los tres juegos del benchmark usando solo tres herramientas — leer logs, hacer grep (búsqueda de patrones en archivos), y ejecutar Python.

_(\*) Escribi esto un día antes de publicarlo (26 de Marzo), hoy 27 de Marzo ya hay una solución mejor, pero que mantiene la misma estructura._  
  

**La conclusión que más me golpeó:** los LLMs son malos razonando sobre estructuras espaciales complejas en contexto, pero cuando les das Python para hacerlo programáticamente, el problema desaparece.

Lo que está pasando en esa dirección me abrió la mente: **si el modelo puede razonar, puede programar. Y si puede programar, puede crear sus propias herramientas.**

Y ahí está el truco que tardé 2 meses en ver: interactuar con DIgSILENT siempre fueron scripts en Python. No hay magia detrás de las 50 herramientas del harness v1.0 — cada una es, en el fondo, un script Python que abre el archivo de PowerFactory, hace algo, y devuelve un resultado. Yo simplemente los había escrito todos a mano de antemano.

**¿Y si el agente los escribiera él mismo cuando los necesita?**

* * *

## ¿Qué es Spark?

Spark es un agente especializado en escribir código Python. Nada más. No hace estudios eléctricos, no genera reportes, no habla con el usuario. Su única tarea es tomar un problema y resolverlo con un script.

Es deliberadamente simple: ~500 líneas de código, con un ciclo ReAct básico.

![Ciclo ReAct de Spark](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Freact-spark-es.png&w=3840&q=75)

Ciclo ReAct de Spark

El ciclo funciona así:

-   **Razona** — entiende qué operación necesita hacer en DIgSILENT
-   **Escribe** — genera el script Python correspondiente
-   **Ejecuta** — corre el script contra PowerFactory
-   **Evalúa** — ¿funcionó? ¿el resultado tiene sentido?
-   **Itera** — si falló, entiende por qué y corrige

Lo que lo hace especial no es el ciclo en sí. Es lo que pasa cuando logra algo y cuando falla.

* * *

## La memoria que se acumula

Cada vez que Spark resuelve un problema exitosamente, guarda dos cosas: el script que funcionó y el razonamiento que lo llevó a ese script.

Pero lo más interesante no es que guarda los éxitos — **también guarda los fracasos.**

La mayoría de los agentes de IA aprenden solo de sus éxitos. Guardan lo que funcionó y lo reutilizan. Pero los humanos aprendemos más de nuestros fracasos — probablemente porque fallamos más de lo que acertamos. Implementé esa misma lógica en Spark.

Cuando no puede resolver algo, guarda un documento `[FALLIDO]` con qué intentó, por qué no funcionó, y qué recomienda probar diferente. Antes de escribir cualquier script nuevo, Spark lee ambos: los éxitos y los fracasos. Los fracasos le dicen qué no hacer.

El formato es simple:

\# \[FALLIDO\] Cortocircuito en línea al 50%

## Qué se intentó
- Crear evento de falla (EvtShc) + método IEC 60909 → error code 1

## Por qué falló
- IEC 60909 no procesa eventos de falla en líneas vía script

## Recomendación
- Usar método "Complete" (iopt\_mde=1) en lugar de IEC 60909

Un ejemplo concreto: el cortocircuito en una línea eléctrica era una tarea que fallaba consistentemente. Sin memoria, Spark reintentaba el mismo enfoque 30 veces gastando $0.29 USD sin llegar a nada. La segunda vez, tenía guardado el `[FALLIDO]` — entendió que el método IEC 60909 no funciona para fallas en líneas vía script, cambió al método "Complete", y lo resolvió al primer intento por $0.10.

Intento

Resultado

Costo

Sin memoria

30 reintentos, sin resultado

$0.29

Con `[FALLIDO]` guardado

Falla, pero documenta por qué

$0.27

Siguiente ejecución

Éxito al primer intento

$0.10

![Ciclo de auto-retroalimentación de Spark](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fspark-memory-es.png&w=3840&q=75)

Ciclo de auto-retroalimentación de Spark

La implementación técnica son ~30 líneas de código extra en el loop del agente y un párrafo adicional en el system prompt. Nada sofisticado. **El insight está en el diseño, no en el código.**

Esto está inspirado en el paper [ExpeL: LLM Agents Are Experiential Learners](https://arxiv.org/abs/2308.10144), que propone que los agentes aprendan tanto de trayectorias exitosas como fallidas. **La mitad que casi nadie implementa es la de los fracasos.**

La segunda vez que Nelson le pide algo similar, Spark no parte de cero. Con el tiempo acumula una biblioteca construida desde experiencia real — no desde lo que yo anticipé que iba a necesitar.

Esto es lo que me tiene más orgulloso del diseño. No es solo que pueda escribir código. **Es que aprende de sus propios logros y fracasos.**

![Mind blown](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fmind-blown.gif&w=3840&q=75)

Mind blown

* * *

## Por qué esto cambia el harness

En el harness v1.0, Nelson tenía ~50 herramientas hardcodeadas. Si necesitaba algo fuera de esas 50, se rompía.

Con Spark como parte del harness v2.0, Nelson puede pedirle a Spark que escriba el script que necesita en tiempo real. El conjunto de capacidades de Nelson deja de estar acotado por lo que yo programé de antemano.

Harness v1.0

Harness v2.0 con Spark

Líneas de código

~16.000

~500

Capacidades

~50 herramientas fijas

Ilimitadas (en teoría)

Si falla algo nuevo

Se traba

Spark lo escribe

Mantenimiento

Alto

Muy bajo

* * *

## Ventajas y desventajas

**Las ventajas reales:**

-   Nelson ya no se traba si le piden algo nuevo
-   El código que mantengo es 30x más pequeño
-   Spark mejora con el tiempo sin que yo intervenga
-   Cualquiera con DIgSILENT puede usarlo — no solo yo

**El problema :**

Spark gasta tokens para pensar y escribir código. Por ahora uso Gemini (me encanta Gemini 3.1 =D) y el costo por llamada es manejable. Pero si Nelson delega a Spark frecuentemente, los costos se van a ir acumulando.

Es un trade-off que acepto: prefiero pagar tokens que mantener miles de líneas frágiles. Pero voy a estar midiendo el gasto para ver si realmente vale la pena.

* * *

## Cómo probarlo

Spark es open source. Es la segunda herramienta de Don Nelson que hago pública — la primera fue la skill de [Infotécnica](https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-16).

¿Por qué lo hago público? Dos razones.

Una: necesito validación real. Si otros lo usan y funciona, confirma que el approach técnico va por buen camino. No hay mejor prueba que alguien que no soy yo corriendo el código y llegando al mismo resultado.

Dos: Spark no es lo que hace único a Don Nelson. Spark es infraestructura — un agente que escribe scripts para DigSILENT. Eso no es un secreto que valga la pena guardar.

Pueden clonarlo, forkearlo, contribuir, o simplemente usarlo:

👉 [github.com/valdivia-tech/spark](https://github.com/valdivia-tech/spark)

Para instalarlo: clonen el repo en un computador con DIgSILENT, agreguen su API Key de Gemini, y listo.

* * *

Lo que viene: integrar Spark al harness v2.0 completo y probarlo con el estudio real del CEN.


---

---
title: Skill de Infotécnica
date: 2026-03-25
slug: don-nelson-a-prueba-dia-16
locale: es
url: https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-16
author: Cristian Valdivia
description: "La skill de Infotécnica es pública. Qué es una skill, por qué la hice open source, y cómo Don Nelson la usa para consultar datos reales del sistema eléctrico chileno."
series: don-nelson
---
# Skill de Infotécnica

**Día 16 / 60**

Estoy trabajando en el harness v2.0 de Don Nelson. Hay cosas que desde la v1 tenía pensado hacer públicas para que cualquiera las pudiera usar.

Hoy es la primera.

* * *

## Qué es una skill?

Una skill es un manual de instrucciones que le das a un agente de IA.

Sin el manual, el agente sabe hacer cosas generales. Con el manual, sabe hacer algo específico. En este caso: consultar datos del sistema eléctrico chileno directo desde [Infotécnica](https://infotecnica.coordinador.cl/).

* * *

## Por qué la hice pública

Consultar Infotécnica es algo que varios equipos hacen en su día a día. A medida que más equipos empiecen a usar agentes en su flujo de trabajo — Claude Code, por ejemplo — esta skill les va a servir.

Lo otro es más simple: creo que es importante aportar al avance del país en IA y en energía. La IA requiere más energía. Si como país somos capaces de generar más y mejor, es bueno para todos.

* * *

## Casos de uso

Don Nelson la usa constantemente. Creo que para hacer un estudio de flujo de potencia, al menos la usa unas 50 veces por ciclo. Para correr una simulación necesita parámetros reales del sistema — resistencia de una línea, impedancias, datos de transformadores. Sin esos datos, la simulación no sirve.

Por ejemplo, para actualizar el modelo con datos reales de una línea:

`❯ Cuál es la resistencia del conductor de la línea Cardones - Refugio 110kV?`

![Respuesta de Claude Code consultando Infotécnica](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fclaude-code-resistance.png&w=3840&q=75)

Respuesta de Claude Code consultando Infotécnica

El repositorio está acá: [github.com/valdivia-tech/infotecnica-skill](https://github.com/valdivia-tech/infotecnica-skill)

Si quieres usarla, copia el link del repo y dile a tu agente que te instale la skill. Así de simple.

* * *

## Lo que viene

Esta es la primera pieza del harness 2.0 que hago pública. Hay más en camino — entre ellas el agente que maneja la comunicación con DIgSILENT.

Si trabajas en energía o estás construyendo agentes y te sirve, úsala. Si le encuentras algún problema o tienes ideas para mejorarla, abre un issue en el repo o escríbeme directamente.


---

---
title: Ansiedad de tokens y el harness v1.0 de Don Nelson
date: 2026-03-22
slug: don-nelson-a-prueba-dia-14
locale: es
url: https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-14
author: Cristian Valdivia
description: "Token anxiety, burnout con IA, y el desglose técnico del harness v1.0 de Don Nelson: gateway, orquestación, contexto, estado, VMs, herramientas y retroalimentación."
series: don-nelson
---
# Ansiedad de tokens y el harness v1.0 de Don Nelson

**Dia 14 / 60**

Nueva semana en el desafio de Don Nelson: un estudio aprobado por el CEN.

La semana pasada no avance mucho tecnicamente. Y creo que eso es lo mas importante que tengo para contar hoy.

* * *

## Ansiedad de tokens y psicosis de IA

La semana pasada no avance mucho.

Soy trabajolico, eso no es nuevo. Pero desde que trabajo con agentes de IA hay algo distinto: la sensacion de que siempre puedes hacer mas, que si no estas corriendo experimentos o quemando tokens estas desperdiciando potencial. El modelo siempre esta disponible. No hay excusa para parar.

Resulta que Andrej Karpathy le puso nombre a esto hace unos dias en el podcast No Priors: "me pongo nervioso cuando me sobra suscripcion". Lo llamo ansiedad de tokens. Yo lo habia estado viviendo sin saber como describirlo.

Decidi bajar el ritmo conscientemente. No porque no hubiera cosas que hacer — siempre tengo — sino porque me estaba pasando la cuenta. Creo que es importante decirlo en este blog, que es sobre construir en publico: la IA amplifica tu capacidad de hacer, pero si no administras eso, te amplifica tambien el burnout.

El descansar me ayudo a pensar y descurir lo siguiente, el cuello de botella ya no es escribir codigo. Es saber dirigir bien. Karpathy lo llama "skill issue" — el que puede descomponer tareas con precision y revisar outputs eficientemente gana, independiente de su habilidad tecnica pura. Eso me parece tanto una oportunidad como una responsabilidad nueva.

El episodio de No Priors con Karpathy, si quieres escucharlo:

-   [Andrej Karpathy on token anxiety](https://www.aol.com/articles/andrej-karpathy-says-feels-nervous-090301670.html)
-   [Post en X](https://x.com/karpathy/status/2004607146781278521)

* * *

## En que esta Don Nelson

A pesar de la semana mas relax, el universo me ayudo a desbloquear las dos cosas que mas me estaban bloqueando.

**Tengo un caso de estudio real.** Una carta escenario concreta que pide un estudio de flujo de potencia y un estudio de capacidad de barra.

**Tengo acceso a dos licencias de DIgSILENT.** Una de red y una comercial sin limite de barras, lo que significa que ya puedo correr flujos de potencia como corresponde, sin las restricciones que me frenaban antes.

Ahora depende solo de mi avanzar.

* * *

## El Harness de Don Nelson v1.0

(Es realmente la v1.0? Tecnicamente nunca llego a produccion

En el [post del Dia 4](https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-4) hable del concepto de harness en general. Hoy quiero hablar del harness actual de Nelson — como esta construido y por que estaba asi.

![Harness de Don Nelson v1.0](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fharness-1-es.png&w=3840&q=75)

Harness de Don Nelson v1.0

### 1\. Entradas y salidas

Nelson no vive en una sola interfaz. Tiene un gateway que recibe mensajes desde Microsoft Teams o desde el frontend web, los normaliza, y los entrega al agente. La respuesta vuelve por el mismo camino. El agente nunca sabe si le hablo un usuario en Teams o alguien en el browser.

### 2\. Orquestacion del pensamiento

Nelson tiene un router de 3 velocidades:

-   **Directo** (~1 segundo): Para preguntas simples, saludos, meta-preguntas. Sin herramientas.
-   **ReAct** (~5-15 segundos): Un loop donde el agente razona, elige una herramienta, la ejecuta, ve el resultado, y decide si necesita hacer algo mas.
-   **Plan-Execute** (~20-60 segundos): Para tareas complejas. El agente primero genera un plan con tareas, y luego un executor las va resolviendo una por una — o en paralelo si hay VMs disponibles.

El clasificador es un sistema de dos fases: primero heuristicas (si el mensaje dice "hola", va directo), luego el modelo evalua la complejidad si las heuristicas no matchean.

Para estudios electricos, casi todo cae en Plan-Execute. El agente descompone "analiza la S/E Codegua" en 5-10 subtareas, cada una con sus herramientas especificas.

### 3\. Manejo del contexto

El modelo tiene un limite de contexto. No puedo meterle las 58 herramientas con sus descripciones, mas el historial de conversacion, mas las instrucciones de cada tipo de analisis. No cabe — y aunque cupiera, el modelo se confunde.

Entonces el harness filtra. Cuando el executor recibe una tarea:

-   Detecta que skills son relevantes (por keywords en el mensaje)
-   Inyecta solo esos prompts especificos
-   Filtra las herramientas de 58 a ~10-15 por tarea
-   Trunca el historial de conversacion para evitar context bloat

Cada skill es un modulo con su propio system prompt. El de DIgSILENT Core le dice al agente como correr flujos de potencia. El de protecciones le explica que reles existen. El de reportes le ensena a generar PDFs.

La analogia: es como darle a un ingeniero junior solo los manuales que necesita para la tarea del dia, en vez de todo el estante de normas a la vez.

### 4\. Persistencia del estado

Si Nelson desactiva una linea de transmision para simular una contingencia, el siguiente flujo de potencia tiene que ver esa linea desactivada. Pero el archivo `.pfd` se descarga de nuevo cada vez.

La solucion: un sistema de "overrides" en Firestore. Cada vez que Nelson modifica un elemento — desactiva una linea, cambia el tap de un transformador, ajusta la potencia de un generador — eso queda registrado. Cuando la siguiente herramienta se ejecuta, le pasa esos overrides al backend Python, que los aplica antes de correr cualquier calculo.

Es como una capa de estado que vive encima del modelo de PowerFactory. No es elegante, pero funciona.

### 5\. Manejo de recursos

Nelson tiene un pool de VMs en Google Cloud, cada una con PowerFactory instalado y un backend Python que expone una API REST.

El harness maneja esto con un sistema de reservacion en Firestore:

-   Antes de ejecutar una herramienta que necesita PowerFactory, el sistema busca una VM disponible
-   Le hace un health check (estas viva?)
-   La reserva con una transaccion atomica — para evitar race conditions si dos tareas piden VM al mismo tiempo
-   Cuando la herramienta termina, la libera

En Plan-Execute, puedo pre-asignar una VM a todo el plan para que las tareas no compitan entre si. O asignar una VM por tarea para que corran en paralelo.

### 6\. Herramientas

Nelson tiene 58 herramientas. 40 requieren DIgSILENT PowerFactory corriendo en una VM. Las otras 18 consultan datos del SEN, generan reportes o envian emails.

Cada herramienta sigue el mismo patron:

1.  El modelo decide que herramienta llamar y con que parametros
2.  La herramienta crea un "job" en Firestore con status `pending`
3.  Reserva una VM disponible del pool
4.  Envia un HTTP POST al backend Python corriendo en esa VM
5.  El backend abre el archivo `.pfd` en PowerFactory, ejecuta la operacion, y guarda el resultado en Firestore
6.  La herramienta hace polling cada 1-2 segundos hasta que el job cambia a `completed` o `failed`
7.  Retorna el resultado al agente

Detalle importante: el modelo a veces alucina nombres de herramientas — llama `power_flow` en vez de `run_power_flow`. Para eso tengo un sistema de aliases, un diccionario que corrige los nombres mas comunes antes de que el sistema falle.

### 7\. Ciclo de retroalimentacion

Cada paso que Nelson da queda registrado como un `IterationStep` en Firestore. El frontend muestra esto en tiempo real — puedes ver el razonamiento del agente, que herramientas eligio, que resultados obtuvo, y cuanto costo en tokens.

Esto no es solo para debugging. Es lo que le permite al ingeniero supervisar al agente y decidir si confia en los resultados.

* * *

## Lo que viene

Ahora que tengo acceso a una licencia de DIgSILENT sin limites voy a cambiar la arquitectura de VMs. En vez de tener 5 maquinas corriendo en paralelo, voy a consolidar en una sola VM mas grande y capaz. Voy a comparar rendimiento entre la maquina actual, una mediana y una grande para encontrar el punto optimo.

Y lo mas importante: voy a refactorizar el harness. Hacerlo mas modular, mas simple. La semana de descanso me sirvio para ver con claridad que sobra y que falta. La simplicidad es dificil, pero es la unica forma de que esto escale.

Ahora empieza a darle en serio para lograr que Don Nelson presente un estudio en 46 dias.


---

---
title: "El Harness: la infraestructura que hace funcionar a un agente"
date: 2026-03-12
slug: don-nelson-a-prueba-dia-4
locale: es
url: https://cristianvaldivia.cl/es/blog/don-nelson-a-prueba-dia-4
author: Cristian Valdivia
description: "El harness no es el agente — es cómo el agente opera. Nueve agentes después, explico qué es, por qué importa y qué nos enseña la industria."
series: don-nelson
---
# El Harness: la infraestructura que hace funcionar a un agente

**Día 4 / 60**

He esperado mucho para hablar de esto. Harness es uno de esos conceptos que parece técnico y denso al inicio, pero que una vez que lo entiendes cambia cómo piensas de los agentes. El término llegó a mi vida hace poco, pero se está volviendo rápidamente popular en la comunidad de AI agents en X.

## ¿Qué es el Harness?

El harness es la infraestructura que rodea al modelo para que el agente pueda correr tareas de larga duración. No es el agente en sí. Es cómo el agente opera.

La metáfora más simple que se me ocurre:

Quiero construir un auto. El motor es el LLM. El harness es todo lo demás — el volante, las ruedas, los frenos, la carrocería — y sobre todo, cómo están interconectados para que el auto funcione.

Para los que les gustan los computadores hay una metáfora mejor: los procesadores son los modelos, la RAM es el manejo del contexto, y el resto — la placa madre, los ventiladores, el teclado, la pantalla y cómo todo está conectado — es el harness.

![Diagrama de un Agent Harness](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fagent-harness.jpeg&w=3840&q=75)

Diagrama de un Agent Harness

Fuente: [philschmid.de](https://www.philschmid.de/agent-harness-2026)

En un agente, el harness incluye:

-   Los prompts que usa
-   Las tools o skills disponibles
-   La lógica con la que elige y ejecuta esas tools
-   La gestión del contexto
-   El estado
-   Las capacidades de planificación
-   La memoria
-   Los guardrails
-   Y un montón de cosas que probablemente estoy olvidando

## Nueve agentes, nueve harnesses distintos

He construido varios agentes a lo largo del tiempo:

Billi, Tsukasa, A0x, Jesse XBT (en su fase inicial), Tomás, Claudio, Felipe, Pedro y Don Nelson.

Cada uno tuvo un harness diferente. No porque hagan cosas distintas, sino porque mi forma de construir agentes ha cambiado mucho. Cada iteración aprendí algo que no sabía antes.

## Lo que nos enseña la industria

Hay tres ejemplos que me parecen muy reveladores:

**Manus** — uno de los primeros agentes públicos reconocidos, refactorizó su harness 5 veces en 6 meses.

**LangChain** cambió su harness 3 veces en un año.

**Vercel** eliminó el 80% de sus tools para responder más rápido y gastar menos tokens.

La conclusión es simple: el harness tiene que ser lo más liviano y modular posible. Cada nuevo modelo se comporta diferente. El harness que funciona hoy puede no funcionar mañana.

## Algunos consejos si estás empezando

Si estás construyendo el harness de tu agente o flujo agéntico, hay tres cosas que creo que marcan la diferencia desde el inicio:

**Mantenlo simple.** Simple es mejor. Pero simple es difícil.

**Hazlo modular.** Los modelos cambian rápido. Si tu harness está acoplado a una versión específica de algo, vas a tener que volver a hacerlo entero cuando el modelo cambie. Me ha pasado :(.

**Los prompts ya no son ventaja competitiva.** La trayectoria que captura tu harness sí lo es. Cada vez que tu agente falla en seguir una instrucción es una oportunidad para mejorar. Eso se acumula y con el tiempo es muy difícil de replicar.

* * *

## Avances: Don Nelson a prueba

En el primer post mencioné tres cosas que necesitaba resolver para llegar al CEN.

La primera, y para mí la más difícil, ya está resuelta: tengo un cliente que me pasó una carta escenario real. Ya tengo un caso de estudio concreto.

La licencia de DIgSILENT está a pocos días de resolverse. A partir de ahí, el ritmo depende solo de mí.

En los próximos posts voy a entrar directamente al harness de Don Nelson — cómo está construido hoy, qué he aprendido de él, y qué voy a cambiar para que pueda presentar un estudio que el CEN apruebe.

* * *

Algunas referencias por si quieren aprender más de Harness:

-   [Harness Engineering — OpenAI](https://openai.com/index/harness-engineering/)
-   [The Anatomy of an Agent Harness — LangChain](https://blog.langchain.com/the-anatomy-of-an-agent-harness/)


---

---
title: 60 días para que una IA firme un informe técnico
date: 2026-03-09
slug: nelson-vs-cen-dia-1
locale: es
url: https://cristianvaldivia.cl/es/blog/nelson-vs-cen-dia-1
author: Cristian Valdivia
description: "Don Nelson todavía no ha pasado una prueba real ante el CEN. Me propongo resolver eso en 60 días: conseguir un caso real, una licencia completa de DIgSILENT y mejorar los informes."
series: don-nelson
---
# 60 días para que una IA firme un informe técnico

**Día 1 / 60**

Echaba de menos escribir.

Después de 60 días documentando cómo construí a Nelson, tomé un descanso. Pero dos semanas después del lanzamiento, hay algo que no me deja tranquilo: Nelson todavía no ha pasado una prueba real.

He tenido varias conversaciones con consultoras y empresas interesadas. El producto les llama la atención. Pero una pregunta se repite: _¿Nelson ha pasado un estudio ante el Coordinador Eléctrico Nacional?_

No. Todavía no.

Y tienen toda la razón en preguntarlo.

Un estudio eléctrico en Chile no vale por el reporte que genera. Vale si el CEN lo aprueba. Sin eso, Nelson es una herramienta interesante en demos, no algo que una consultora pueda usar en un proyecto real.

Eso es lo que me propongo resolver en los próximos 60 días.

## El desafío

En la primera serie construí a Nelson desde cero: arquitectura, herramientas, paralelización en Google Cloud, integración con Infotécnica, CNE y Acceso Abierto. Al día 60, Nelson podía correr estudios autónomos de hasta 60 minutos y generar reportes de más de 20 páginas.

Pero "funciona en mis pruebas" no es suficiente.

Esta serie tiene un objetivo concreto: **que Nelson presente un informe ante el CEN y sea aprobado**.

Si lo logra, tengo algo real que creo que podría revolucionar el mercado.

## Lo que tengo que resolver

Voy a ser honesto sobre los tres problemas que tengo hoy.

**1\. Conseguir un caso real**

Necesito un cliente que tenga la necesidad de presentar un estudio ante el CEN. Puede ser una consultora trabajando en un proyecto activo, o un cliente directo que necesite conectarse al SEN.

Esto es lo más difícil. No es un problema técnico, es un problema comercial. Tengo que vender, convencer y probablemente hacer el primer estudio a costo muy bajo o gratis. Tengo dos consultoras en conversación activa. Espero moverme rápido.

**2\. Conseguir una licencia real de DIgSILENT**

La licencia que tengo es de universidad, máximo 50 barras. El SEN tiene más de 2.500. Para un estudio real necesito una licencia completa. El costo no es menor y todavía estoy viendo qué hacer con esto.

**3\. Mejorar a Nelson para informes de verdad**

Hasta ahora Nelson ha corrido estudios chicos. Hacer un informe que cumpla con los estándares del CEN — formato, criterios técnicos, niveles de detalle — es otra cosa. Sé que Nelson puede llegar ahí, pero le falta trabajo.

El ECAP es otro desafío muy grande igualmente, no es como el estudio de flujo de potencia o cortocircuito y en un sistema grande me preocupa lo que puede hacer Nelson, pero insisto, sé que puede llegar.

## Por qué creo que es posible

Lo que más me da confianza es esto:

![Gráfico de autonomía temporal de agentes](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson-vs-cen%2Fagents-time-autonomy.png&w=3840&q=75)

Gráfico de autonomía temporal de agentes

Fuente: [METR, marzo 2025](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/) — los LLMs hoy pueden completar tareas de software de hasta 10 horas de forma autónoma

Hoy los mejores LLMs pueden hacer tareas de software por 10 horas de forma autónoma. Nelson ha llegado a correr por 60 minutos. Creo que en 60 días puedo llevarlo a estudios de varias horas. Y en dos meses los modelos van a seguir mejorando, lo que empuja el límite hacia arriba.

Además el benchmark de HLE avanza cada vez más, ARC AGI 3 también dice ser completamente agéntico. Agentica dice haber completado ARC AGI 3 en los juegos que tienen hasta el momento, que son 6.

Entonces claramente la tecnología está de mi lado. Tengo que poner el lado humano para resolver lo que falta.

## El objetivo

Los expertos en productividad dicen que los objetivos tienen que ser claros y medibles. Este lo es:

**Si en 60 días Nelson presenta un estudio que el CEN aprueba, el desafío está cumplido.**

Yo creo que es posible. Pero en 60 días lo voy a saber con certeza.


---

---
title: Lanzamiento Nelson (donnelson.cl)
date: 2026-02-23
slug: lanzamiento-nelson
locale: es
url: https://cristianvaldivia.cl/es/blog/lanzamiento-nelson
author: Cristian Valdivia
description: "Después de 60 días construyendo un agente de IA para ingeniería eléctrica, Nelson tiene nombre, sitio web y está listo para trabajar con equipos reales. Conoce al primer ingeniero eléctrico digital de Latinoamérica."
---
# Lanzamiento Nelson (donnelson.cl)

[![Nelson - donnelson.cl](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fnelson%2Fopengraph-image.png&w=3840&q=75)](https://donnelson.cl)

Hace un poco mas de 60 días me propuse un desafío: construir un agente de IA capaz de hacer estudios de coordinación de protecciones en el Sistema Eléctrico Nacional de Chile. Hoy ese agente tiene nombre, tiene sitio web y está listo para trabajar con equipos reales.

Se llama **Nelson**. Y vive en [donnelson.cl](https://donnelson.cl).

## El contexto

Si seguiste la [serie en este blog](https://cristianvaldivia.cl/es/blog/ia-ingenieria-electrica-estudios-conexion), sabes que esto partió como un experimento. Un casi ingeniero eléctrico (yo) tratando de enseñarle a una IA a usar DIgSILENT PowerFactory, la herramienta estándar de la industria para estudios eléctricos en Chile.

La premisa era simple: ¿puede un agente autónomo ejecutar flujos de potencia, cortocircuitos y coordinación de protecciones sin que un humano le diga paso a paso qué hacer?

La respuesta, después de 60 días, 15 posts, cientos de horas de desarrollo y BILLONES de tokens consumidos es: **sí, puede**.

No es perfecto (Por ahora).

## Qué es Nelson

Nelson es un agente de IA que se integra como un miembro más de tu equipo en **Microsoft Teams**. No es un chatbot que responde preguntas sobre normas. Es un agente que ejecuta.

Le dices: “Revisa la S/E Cardones y ve si aguanta 15 MW adicionales”, y Nelson se pone a trabajar. Abre DIgSILENT, carga el proyecto, corre el flujo de potencia, analiza los resultados y te responde con números reales.

En concreto, Nelson puede:

-   **Ejecutar flujos de potencia** — analiza caídas de tensión, redistribuye cargas, ajusta taps de transformadores.
-   **Correr estudios de cortocircuito** — simula fallas trifásicas, bifásicas y monofásicas en cualquier barra del sistema.
-   **Coordinar protecciones (En Revisión)** — revisa relés, recalcula TMS y pickup, verifica márgenes de gradación.
-   **Generar reportes técnicos** — informes PDF completos con diagramas unifilares, curvas TCC, tablas de ajuste. Listos para enviar al cliente.

Y lo hace en su propia estación de trabajo. Nelson tiene máquinas virtuales dedicadas corriendo DIgSILENT en la nube. No usa tu computador.

## Lo que cambió en estos 60 días

Cuando empecé el día 1, el agente apenas podía ejecutar un flujo de potencia simple. Hoy, en una sesión típica:

-   Corre **sesiones autónomas de más de 60 minutos**
-   Usa **21 herramientas** especializadas en análisis de redes, protecciones, transformadores de instrumento y visualización
-   Genera **reportes de 47+ páginas** con análisis completo
-   Opera sobre **5 máquinas virtuales en paralelo** gracias a una arquitectura basada en DAG (grafos acíclicos dirigidos)
-   Consulta datos reales del **Coordinador Eléctrico Nacional, CNE e Infotécnica**

La arquitectura evolucionó de ReAct a Plan-and-Execute. El agente primero planifica, genera un DAG de tareas, y luego las ejecuta en paralelo cuando es posible. Esto redujo drásticamente los tiempos de simulación.

## Por qué Teams

En Chile, las empresas eléctricas viven en Microsoft Teams. Coordinados, consultoras, generadoras — la comunicación del sector pasa por ahí. Nelson no es una plataforma nueva que tengas que aprender. Es un compañero más en tu workspace.

Le hablas como le hablarías a un colega. Y él responde con resultados técnicos.

## Para quién es Nelson

Nelson es para equipos de ingeniería eléctrica que hacen estudios de conexión, ECAP, o cualquier análisis que involucre DIgSILENT PowerFactory. Si tu equipo dedica horas a correr simulaciones, preparar reportes y verificar coordinación de protecciones, Nelson puede hacer ese trabajo pesado para que tu equipo se enfoque en lo que realmente importa: el criterio técnico.

Consultoras, empresas de transmisión, generadoras, desarrolladores de proyectos PMGD/PMG — si trabajas con el SEN, Nelson está diseñado para ti.

## Hacia dónde va Nelson

Nelson hoy resuelve un problema concreto: ejecutar estudios eléctricos más rápido. Pero la visión es más grande que eso.

Lo que estoy construyendo es el primer ingeniero eléctrico digital de Latinoamérica. Un agente que no solo ejecuta simulaciones, sino que entiende el sistema eléctrico chileno de principio a fin — desde la normativa de la CNE hasta las restricciones operacionales del Coordinador Eléctrico.

La idea es que Nelson evolucione hasta ser capaz de tomar un proyecto nuevo — una planta solar, un parque eólico, un PMGD — y hacer el análisis completo de conexión al SEN. No como una herramienta que necesita que le digan qué hacer, sino como un agente que entiende el problema, propone una estrategia y la ejecuta.

Hoy estamos en la base de eso. Pero cada estudio que Nelson completa, cada reporte que genera, cada simulación que corre, lo acerca más a esa visión. Y lo mejor es que cada equipo que lo use va a ayudar a que sea mejor — porque los problemas reales son los que realmente enseñan.

## Quiero que lo veas

Si trabajas en el sector eléctrico en Chile (por ahora), quiero mostrarte lo que Nelson puede hacer. No con slides ni con promesas — con una demo real, en vivo.

30 minutos. Sin compromiso.

[Agenda una demo en donnelson.cl](https://cal.com/cristian-valdivia-sh76nz/30min)


---

---
title: "Último día: 60 días construyendo un agente de IA para ingeniería eléctrica"
date: 2026-02-20
slug: ultimo-dia-agente-ia-60-dias
locale: es
url: https://cristianvaldivia.cl/es/blog/ultimo-dia-agente-ia-60-dias
author: Cristian Valdivia
description: "El agente ya corre flujos de potencia, cortocircuitos, coordina protecciones y genera reportes PDF de más de 20 páginas. Reflexiones sobre 60 días construyendo en público."
series: don-nelson
---
# Último día: 60 días construyendo un agente de IA para ingeniería eléctrica

**Día 60 / 60**

Ok. Último día.

El 22 de diciembre de 2025 escribí que iba a construir un agente capaz de asistir en la elaboración y revisión de estudios eléctricos en 60 días. Sonaba ambicioso incluso para mí. Había mucha gente que creía que un agente no era capaz de hacer estudios eléctricos reales — simulaciones de verdad, con criterio de ingeniero, en un software profesional como PowerFactory. Yo creía que sí. Y después de 60 días, creo que tenía razón.

No es perfecto. Pero funciona.

## Lo que logró D.N.

El agente hoy puede:

-   Correr flujos de potencia y análisis de cortocircuito de forma autónoma
-   Coordinar protecciones en sistemas pequeños
-   Navegar Infotécnica para extraer datos reales de subestaciones del SEN
-   Consultar la regulación de la CNE y el CEN para tomar decisiones informadas
-   Generar reportes PDF de más de 20 páginas con tablas, diagramas y análisis
-   Ejecutar durante más de 60 minutos sin intervención humana
-   Paralelizar simulaciones en múltiples máquinas corriendo DIgSILENT en la nube

Partí con 4 herramientas el día 5. Hoy tiene más de 50. Partí corriendo en 1 máquina virtual. Hoy corre en 5 en paralelo con un DAG que el mismo planner construye.

## Sobre los estudios: no todos son iguales

Una cosa que aprendí durante estos 60 días es que no se puede hablar de "estudios eléctricos" como si fueran todos lo mismo. La diferencia de complejidad entre ellos es enorme.

**Flujos de potencia y cortocircuitos** son estudios que el agente ya hace bien. Son estudios donde el procedimiento es relativamente claro: configuras el escenario, corres la simulación, analizas los resultados, generas el reporte. Hay criterio involucrado — qué contingencias probar, cómo interpretar las tensiones, qué escenarios son relevantes — pero la secuencia de pasos es predecible. El agente los ejecuta de forma autónoma, genera reportes con los resultados y los análisis son correctos. Me atrevería a decir que estos estudios están prácticamente resueltos para sistemas pequeños.

**Coordinación de protecciones es otra cosa.** Acá el agente logró coordinar relés en sistemas chicos, y ese fue el momento en que sentí que tenía algo. Pero siendo honesto, la coordinación de protecciones tiene una complejidad que todavía no he podido atacar completamente. No es solo correr una simulación — es entender la topología, la filosofía de protección, los márgenes de coordinación, las curvas TCC, los ajustes de zona en relés de distancia, y tomar decisiones que dependen del contexto de cada sistema específico. Un ingeniero con experiencia toma esas decisiones con criterio acumulado durante años. El agente está empezando a hacerlo, pero le falta.

La brecha entre un flujo de potencia y una coordinación de protecciones es la misma brecha que hay entre que un agente siga instrucciones y que un agente tenga criterio. Y eso es lo más interesante de lo que viene.

## Lo que no logré

Voy a ser honesto: no he podido probar el agente en un caso real a escala. Solo tengo acceso a licencias de máximo 50 barras, y el SEN tiene más de 2,500. La próxima semana debería tener acceso a una licencia completa, y ahí va a ser el verdadero test.

La coordinación de protecciones en sistemas grandes sigue siendo un problema abierto. El agente coordina bien en sistemas chicos, pero no sé cómo se va a comportar cuando la complejidad combinatoria explote.

## Los momentos que me marcaron

**El día que el agente coordinó relés solo.** Día 30. Le di un prompt complejo — correr simulaciones, prender y apagar generadores, ajustar relés. Corrió 9.6 minutos, usó 37 herramientas, ejecutó 46 pasos. Y coordinó los relés que realmente necesitaban coordinarse. Ese día supe que esto iba en la dirección correcta.

**El día que perdí un día completo porque PowerFactory no corre en ARM.** Día 5. Tres Macs, ninguno servía. Terminé en Google Cloud.

**El primer reporte PDF autónomo.** El agente tomó 10 minutos, usó 26 herramientas en secuencia, corrió 4 análisis de contingencia distintos. El reporte era mediocre, pero era _real_. Costo: $0.149 USD.

## Lo que construir en público me enseñó

Más de 500 personas leyeron este blog durante el desafío. El doble de lo que entraba a mi sitio en un año entero.

Pero lo más importante no fue el tráfico. Fue que documentar me obligó a avanzar. Cada semana tenía que tener algo nuevo que contar. Y esa presión, que me autoimpuse, fue probablemente la razón por la que terminé. Hay semanas en las que no tenía ganas, en las que el agente fallaba de formas absurdas y no sabía qué escribir. Pero escribí igual.

Lo otro que no esperaba: construir en público me trajo interés de consultoras que quieren probar y usar lo que estoy construyendo.

## Lo que aprendí

Sobre el sistema eléctrico chileno: Infotécnica, el CEN, la CNE, los procesos de acceso abierto... lo entendía antes, pero ahora lo entiendo mucho mejor, como alguien que tuvo que programar cada regla y cada excepción en código.

Sobre los estudios: la dificultad real de cada tipo de estudio, por qué la coordinación de protecciones es tan compleja, por qué los ingenieros eléctricos hacen lo que hacen de la forma en que lo hacen.

Sobre agentes de IA: que el número de herramientas importa. Que Plan-and-Execute le gana a ReAct para tareas largas. Que la memoria de un agente es un problema increíblemente difícil. Que este es el año de los agentes de IA.

Sobre mí: que escribir me gusta más de lo que pensaba. Que los deadlines autoimpuestos funcionan. Que construir algo que resuelve un problema real en público, incluso de forma imperfecta, se siente distinto a cualquier otra cosa.

## Qué viene

Me voy a tomar el fin de semana. El lunes parte otra etapa del proyecto.

Gracias a todos los que leyeron, comentaron durante 60 días.


---

---
title: Qué es un agente y por qué importa en ingeniería eléctrica
date: 2026-02-18
slug: que-es-un-agente-ingenieria-electrica
locale: es
url: https://cristianvaldivia.cl/es/blog/que-es-un-agente-ingenieria-electrica
author: Cristian Valdivia
description: "En 6 meses pasé de 'más inútil que un practicante' a un agente que genera reportes de estudios eléctricos de 13+ páginas. Qué es un agente, qué cambió y por qué 2026 es el año de los agentes."
series: don-nelson
---
# Qué es un agente y por qué importa en ingeniería eléctrica

**Día 58 / 60**

Vengo trabajando con agentes desde noviembre del 2024. Durante mucho tiempo consideré que todos vendíamos humo sobre lo que realmente podía hacer un agente.

![Primera interacción con ELIZA](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F58%2Feliza.png&w=3840&q=75)

Primera interacción con ELIZA

Hace 6 meses escribí en [esta entrada](https://cristianvaldivia.cl/es/blog/ai-glossary) lo que era un agente y que en ese momento vivíamos en una etapa de hype. Unos días después, tras fracasar estrepitosamente en ARC AGI 3, publiqué esto:

![La ironía de la IA](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F58%2Fagosto2025.png&w=3840&q=75)

La ironía de la IA

"La ironía de la IA. Más inteligente que un Doctorado. Más inútil que un practicante."

Lo sentía de verdad.

Eso fue hace 6 meses.

Siento que ha llegado el momento que los "AI bros" venimos prediciendo hace años. Los agentes están ya entre nosotros. No estoy hablando de demos ni de papers académicos. Estoy hablando de agentes que hacen cosas reales, en producción, todos los días. Y que lo hacen muy bien.

## Qué es un agente ?

Antes de seguir, vale la pena explicar qué entiendo como agente en este momento, porque el término esta ultra manoseado y además va cambiando a medida que la tecnología mejora.

"Un agente de IA es un programa que no solo responde preguntas sino que toma acciones por sí mismo hasta cumplir un objetivo. Es la diferencia entre preguntarle a ChatGPT '¿cómo hago un flujo de potencia?' y que un agente ejecute el flujo de potencia, analice los resultados, identifique problemas de tensión, simule contingencias y te entregue un reporte completo. El agente decide qué hacer, lo hace, evalúa si funcionó, y ajusta."

Un chatbot responde. Un agente actúa.

![Chatbot vs Agente](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F58%2Fchatbot-agente.png&w=3840&q=75)

Chatbot vs Agente

Según lo que entiendo hoy, un agente necesita al menos estos componentes:

**LLM**: El modelo de inteligencia artificial que razona y decide qué herramientas usar y cuándo.

**Tools (herramientas)**: Las acciones concretas que puede ejecutar en el mundo real. En el caso de Nelson, son más de 50 herramientas para interactuar con PowerFactory, consultar Infotécnica, buscar normativa CNE, generar diagramas. Sin herramientas, un agente es solo un LLM que habla bonito.

**Memoria**: Contexto persistente entre sesiones. Sin esto, cada conversación empieza de cero y el agente olvida qué estudios ya hizo, qué parámetros encontró, qué decisiones tomó, para qué equipo está trabajando. Hasta hace poco, esto era el punto más débil de los agentes.

**Conocimiento de dominio**: Los datos, normativas y criterios específicos del área donde trabaja. Nelson tiene la normativa CNE indexada, datos de Infotécnica, parámetros del SEN.

**Archivos de personalidad**: Quién es, cómo se comporta, qué prioriza. En Nelson esto significa que el agente sabe que es un ingeniero eléctrico, que trabaja con normativa chilena, que debe ser conservador en recomendaciones de protección. Estos archivos van evolucionando — el mismo agente los mejora con el tiempo.

**Guardrails**: Las reglas que definen qué puede y qué no puede hacer el agente. Límites de autonomía.

**Loop de ejecución**: Un ciclo continuo de planificación → ejecución → evaluación, no solo respuesta a prompts. Esto es lo que diferencia a un agente de un chatbot.

**Evaluación**: Poder medir si el agente está tomando buenas decisiones. No es solo "¿funcionó?", es revisar sistemáticamente si eligió las herramientas correctas, si el análisis tiene sentido, si el reporte cumple estándares.

**Trazabilidad**: Poder ver exactamente qué hizo el agente, paso a paso, qué herramientas usó y por qué. En estudios eléctricos que deben cumplir estándares del CEN, poder auditar cada decisión del agente no es opcional.

**Heartbeat**: Un mecanismo que lo mantiene activo y proactivo, no esperando pasivamente una instrucción.

## Qué cambió para que los agentes sean posibles

Hace 16 meses, los LLMs no eran lo suficientemente buenos seleccionando qué herramientas usar. Hoy el tooling, la memoria y las ventanas de contexto mejoraron lo suficiente como para que podamos decir: tenemos agentes funcionales. Voy a ser específico:

-   **Los modelos mejoraron radicalmente en tool calling.**
-   **El 1M de tokens de contexto es justo lo que necesitábamos.**
-   **La memoria ya está mejor resuelta.**
-   **El paralelismo se volvió nativo.**

## Por qué esto importa para ingeniería eléctrica

Históricamente, la ingeniería eléctrica y las ciencias de la computación han estado muy unidas. En Chile, una cantidad enorme de eléctricos terminan trabajando en cosas informáticas: desarrollo de software, automatización, data. No es casualidad. Las dos disciplinas comparten la misma forma de pensar: sistemas, lógica, optimización.

Eso hace que la ingeniería eléctrica esté en una posición única para beneficiarse de los agentes. No es un salto tan grande.

Estos últimos meses he sentido como mi productividad como developer se multiplicó x2, x3, x5. No es exageración. Claude Code con Opus 4.6 cambio la forma en que trabajo. Lo que antes me tomaba un día ahora lo hago en horas. Ese superpoder que estamos sintiendo los developers va a empezar a llegar muy pronto a más áreas del conocimiento. Y la ingeniería eléctrica va a ser de las primeras.

Un estudio de coordinación de protecciones en Chile hoy puede tomar semanas de trabajo manual. Un ingeniero tiene que recopilar datos de Infotécnica, revisar normativa CNE, modelar el sistema en PowerFactory, correr simulaciones, analizar contingencias, ajustar configuraciones de relés, y escribir un reporte que cumpla con los estándares del Coordinador Eléctrico Nacional.

Nelson está haciendo gran parte de eso de forma autónoma. No todo. No lo hace perfecto. Pero está haciendo el trabajo técnico real: corriendo simulaciones, analizando contingencias, generando datos. Y lo siento mejorar cada semana.

La razón por la que esto es posible _ahora_ y no hace un año es la convergencia de todo lo que mencioné: modelos que saben usar herramientas, contexto suficiente para manejar la complejidad de un sistema eléctrico real, memoria que persiste entre sesiones, y arquitecturas que permiten paralelizar trabajo. Cada una de esas piezas necesitaba mejorar. Y siguen mejorando cada día.

## Reflexión

El ecosistema de agentes en febrero 2026 está fragmentado. Ninguna plataforma domina, no hay un estándar para construir agentes todavía, no hay una plataforma donde llegues y tengas un Jarvis listo.

Pero eso es temporal. La infraestructura ya existe. Falta muy poco para que tengamos agentes trabajando en equipos de verdad.

Los agentes no reemplazan ingenieros. Amplían lo que podemos hacer. Una habilidad clave en 2026 va a ser saber trabajar con agentes, coordinarlos, darles las herramientas correctas y el conocimiento que necesitan.

Nos vamos acercando muy rápidamente a ese punto donde el cuello de botella es solo la imaginación.

2026 es el año de los agentes. Y si no lo ves, es porque no estás prestando [atención](https://www.youtube.com/@atencionestodoloquenecesitas).

Si quieres que te llegue un correo cuando publique nuevo contenido, inscríbete acá abajo.


---

---
title: "CNE: regulación eléctrica indexada para agentes de IA"
date: 2026-02-14
slug: cne-regulacion-electrica-agentes-ia
locale: es
url: https://cristianvaldivia.cl/es/blog/cne-regulacion-electrica-agentes-ia
author: Cristian Valdivia
description: "Indexé los documentos de la CNE en Pinecone para que D.N. pueda hacer RAG sobre el Plan de Expansión, obras urgentes y resoluciones regulatorias del sistema eléctrico chileno."
series: don-nelson
---
# CNE: regulación eléctrica indexada para agentes de IA

**Día 54 / 60** — 90% completado

En posts anteriores hablé de [Infotécnica](https://cristianvaldivia.cl/es/blog/infotecnica-datos-sistema-electrico-chileno) y de [Acceso Abierto](https://cristianvaldivia.cl/es/blog/acceso-abierto-proyectos-conexion-sen) y cómo D.N. puede extraer información de estos sitios para entender mejor el estado del sistema eléctrico chileno. Pero con Infotécnica y Acceso Abierto no basta. Para que un agente de IA realmente entienda el sistema eléctrico chileno, necesita saber qué obras están planificadas, cuáles son urgentes y cómo se articula la expansión del sistema de transmisión.

Ahí entra la [CNE](https://www.cne.cl/) (Comisión Nacional de Energía).

![Sitio web de la CNE](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F53%2Fcne.png&w=3840&q=75)

Sitio web de la CNE

## ¿Por qué la CNE es relevante para D.N.?

Cuando un ingeniero eléctrico hace un estudio de conexión, no basta con mirar el estado actual de la red. Necesita saber qué obras están planificadas, cuáles están en construcción y qué proyectos urgentes podrían cambiar la topología de la red en los próximos años. Sin esa información, un estudio de conexión puede quedar obsoleto antes de terminarlo.

La CNE publica documentación extensa sobre tres procesos clave:

1.  **Plan de Expansión de la Transmisión (PET)** — El proceso anual donde se definen las obras de expansión del sistema de transmisión nacional y zonal.
2.  **Obras Necesarias y Urgentes (Art. 91° bis LGSE)** — Un mecanismo introducido por la Ley 21.721 de Transición Energética que permite excluir obras del proceso de planificación anual cuando son urgentes para asegurar el abastecimiento o la seguridad del sistema.
3.  **Obras Urgentes de Transmisión (Art. 102° inciso 2° LGSE)** — Permite que empresas eléctricas propongan y ejecuten obras de transmisión necesarias y urgentes que no fueron contempladas en el proceso de planificación anual, previa autorización excepcional de la CNE e informe fundado del Coordinador.

Un ingeniero que quiera conectar un proyecto en la zona de Ñuble, por ejemplo, necesita saber que se vienen la nueva S/E Punilla, la nueva S/E Quinchamalí y la nueva S/E Raluncoyán con línea 2×66 kV a Temuco. Eso cambia completamente dónde y cómo puede conectarse.

## RAG sobre documentos de la CNE

A diferencia de Infotécnica, donde construí un scraper que navega el sitio en tiempo real, con la CNE tomé un enfoque distinto: **indexé los documentos directamente a [Pinecone](https://www.pinecone.io/) para hacer [RAG](https://aws.amazon.com/what-is/retrieval-augmented-generation/) (Retrieval-Augmented Generation)**.

¿Por qué? Los documentos de la CNE son PDFs densos de cientos de páginas: propuestas preliminares, propuestas definitivas, informes técnicos, resoluciones. No tiene sentido scrapear un sitio cuando lo que necesitas es que el agente pueda hacerle preguntas inteligentes a un set de documentos regulatorios.

El pipeline funciona así:

![Pipeline RAG de documentos CNE](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F53%2Fpipeline-rag-cne.png&w=3840&q=75)

Pipeline RAG de documentos CNE

Cada chunk tiene metadata que incluye: tipo de documento (PET, ONyU, resolución), año del proceso, zona geográfica del sistema y tipo de obra (nacional/zonal, nueva/ampliación). Esto permite hacer queries filtradas que reducen drásticamente el ruido.

## Ejemplos de lo que puede preguntar el agente

Acá es donde se pone interesante. Con los documentos de la CNE indexados, D.N. puede responder preguntas que normalmente le tomarían horas a un ingeniero revisando PDFs:

**Sobre el Plan de Expansión:**

-   _"¿Qué obras de transmisión están planificadas en la zona entre Diego de Almagro y Quillota para los próximos 5 años?"_
-   _"¿Cuál es la inversión total en obras nacionales del PET 2025 y qué subestaciones están involucradas?"_
-   _"¿Existen obras desiertas en la zona sur que hayan sido relicitadas? ¿Cuál es su estado actual?"_
-   _"¿Qué obras del PET 2024 aún no se han adjudicado y podrían afectar la capacidad de transmisión en la Región Metropolitana?"_

**Sobre Obras Urgentes (Art. 91° bis):**

-   _"¿Qué obras necesarias y urgentes fueron aprobadas para la región de Ñuble y cuál es su estado de avance?"_
-   _"¿Cuál es el límite presupuestario para obras urgentes este año según el Art. 91° bis?"_
-   _"¿Qué subestaciones del proceso de obras urgentes 2025 incluyen sistemas de almacenamiento de energía?"_
-   _"¿Existe alguna obra urgente que afecte la zona donde quiero conectar mi proyecto solar en la Región de Atacama?"_

**Preguntas cruzadas:**

-   _"Si quiero conectar un parque eólico de 100 MW cerca de Temuco, ¿qué obras planificadas y urgentes debo considerar en mi estudio de conexión?"_
-   _"¿Qué zonas del SEN tienen más obras planificadas que podrían liberar capacidad de transmisión en los próximos 3 años?"_
-   _"¿Hay discrepancias presentadas al Panel de Expertos que podrían modificar obras planificadas en la zona norte?"_

Ese último tipo de pregunta es donde el RAG se vuelve realmente útil. Cruzar información entre el PET, las obras urgentes y las discrepancias del Panel de Expertos es algo que manualmente requiere abrir múltiples PDFs, buscar referencias cruzadas y mantener el contexto.

## Primer test: estudio del Plan de Expansión

Con todo esto en contexto, le pedí a D.N. que me hiciera un estudio de los proyectos que están en proyección para construcción desde el 2021. El resultado aún no me convence, sigo pensando que el agente podría escribir mejores informes, y voy a trabajar en eso la próxima semana.

[Ver estudio del Plan de Expansión](https://storage.googleapis.com/don-nelson-bucket/reports/project-project-cristian.valdivia@alumnos.usm.cl-1771079817263/analysis_estudio_del_plan_de_expansi_n_de_la_transmisi_n_20_1771106681163.pdf)

5.0m total | 20 tools | $0.3128 LLM | 565,004 tokens | Gemini 3 Flash para cada parte del proceso.

## Diagrama: fuentes de datos de D.N.

![Fuentes de datos de D.N.](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F53%2Fdn-tools.png&w=3840&q=75)

Fuentes de datos de D.N.

Cada fuente aporta un tipo de conocimiento distinto. Infotécnica da el estado actual del sistema. La CNE da el contexto regulatorio y de planificación. PowerFactory permite simular y validar. Acceso Abierto entrega información de proyectos en conexión y el estado del SEN. Juntas, le dan al agente una visión bastante completa para hacer estudios de conexión.

## Lo que viene

Tener los documentos de la CNE indexados abre posibilidades interesantes. La siguiente iteración es conectar las respuestas del RAG con las simulaciones en PowerFactory. Imagina que D.N. identifica vía RAG que hay una nueva subestación planificada en tu zona de interés y automáticamente ajusta el modelo de simulación para considerar esa obra futura en el estudio de conexión.

Estoy entrando en los últimos días del desafío, en el último 10%. Ahora voy a empezar a cerrar mi lista de pendientes y darle al agente las habilidades agénticas para que se empiece a sentir como parte de un equipo: que tenga memoria, que tenga autonomía, que pueda trabajar por horas y sea proactivo. Estoy entrando en la parte mas interesante del proyecto.

Si quieres que te llegue un correo cuando publique nuevo contenido, inscríbete acá abajo.


---

---
title: "Acceso abierto: enseñándole al agente cómo se conectan los proyectos al SEN"
date: 2026-02-12
slug: acceso-abierto-proyectos-conexion-sen
locale: es
url: https://cristianvaldivia.cl/es/blog/acceso-abierto-proyectos-conexion-sen
author: Cristian Valdivia
description: El agente ahora consulta la plataforma de acceso abierto del CEN para saber qué proyectos están en proceso de conexión y cruzar esa información con Infotécnica y el modelo de red.
series: don-nelson
---
# Acceso abierto: enseñándole al agente cómo se conectan los proyectos al SEN

**Día 52 / 60**

En el [post anterior](https://cristianvaldivia.cl/es/blog/agente-ia-entiende-sistema-electrico-chileno) el agente empezó a entender el sistema eléctrico chileno. Ahora necesita entender cómo se conectan los proyectos a ese sistema.

En el post de [Infotécnica](https://cristianvaldivia.cl/es/blog/infotecnica-datos-sistema-electrico-chileno) mencioné que la siguiente tarea era ir a acceso abierto. Llegó el momento.

(Siento un cariño particular por Acceso Abierto, muchos de mis compañeros y conocidos partieron su carrera como ingenieros eléctricos en este departamento del CEN)

## ¿Qué es acceso abierto?

Para quien no esté familiarizado: acceso abierto es el derecho que tiene cualquier "tercero" de conectarse a las instalaciones de transmisión del [Sistema Eléctrico Nacional](https://www.coordinador.cl/sistema-electrico/), según lo determine el [Coordinador Eléctrico Nacional (CEN)](https://www.coordinador.cl/). Está regulado por los artículos 79° y 80° de la Ley General de Servicios Eléctricos.

En términos prácticos, si quieres conectar un parque solar, una planta eólica, cualquier proyecto de generación al SEN o un datacenter, tienes que pasar por el proceso de acceso abierto. Es el camino obligatorio.

Existen tres tipos de solicitudes principales:

-   **SAC** (Solicitud de Autorización de Conexión): para conectarse a instalaciones de transmisión de servicio público, es decir, transmisión nacional y zonal.
-   **SUCTD** (Solicitud de Uso de Capacidad Técnica Disponible): para conectarse a instalaciones de transmisión dedicada.
-   **Proyectos fehacientes**: instalaciones o proyectos propios que se quieren conectar a instalaciones de la misma empresa.

El CEN tiene una [plataforma de acceso abierto](https://accesoabierto.coordinador.cl/) donde se puede hacer seguimiento de todas las solicitudes en curso. Es pública.

## Por qué D.N. necesita esto

Hasta ahora el agente puede hacer estudios de flujo de potencia, cortocircuitos y coordinación de protecciones. Puede ir a [Infotécnica](https://infotecnica.coordinador.cl/) y extraer datos técnicos de subestaciones. Puede buscar subestaciones cercanas a una ubicación geográfica.

Pero le falta una pieza crítica: saber qué hay en proceso de conexión.

Imagina que el agente identifica que la S/E Carrera Pinto tiene tres posiciones disponibles en la barra de 220 kV. Perfecto. Pero si hay 2 proyectos solares ya aprobados esperando conectarse, esas posiciones no están realmente disponibles. Sin consultar acceso abierto, el agente estaría recomendando puntos de conexión incorrectos.

Para un estudio de conexión real, necesitas cruzar al menos cuatro fuentes de información:

1.  **Infotécnica**: qué existe físicamente en la subestación
2.  **Acceso abierto**: qué proyectos están en proceso de conectarse
3.  **CNE**: los proyectos que están en el plan de Expansión (hablaré más en detalle de esto mañana)
4.  **El modelo de red del CEN**: cómo se comporta el sistema eléctricamente

El agente ya maneja (1) y (4). Estoy terminando (2) y mañana veré (3).

## Scrapeando la plataforma de acceso abierto

La plataforma de acceso abierto del CEN es más estructurada que Infotécnica. La información está organizada por solicitudes, cada una con su estado, punto de conexión, potencia y fechas.

Estoy construyendo una herramienta que permite al agente:

-   Buscar solicitudes activas por punto de conexión (subestación)
-   Filtrar por estado (en trámite, aprobada, en construcción)
-   Extraer la potencia y la fecha estimada de conexión
-   Identificar si hay restricciones o condiciones especiales

A diferencia de Infotécnica, donde el desafío principal era interpretar diagramas unilineales visualmente complejos, aquí el desafío es más de datos estructurados.

![Plataforma de acceso abierto del CEN](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F52%2Facceso-abierto.webp&w=3840&q=75)

Plataforma de acceso abierto del CEN

Sabía que esto iba a pasar pero aún así sorprende: es la cantidad de proyectos en cola. Hay subestaciones con decenas de solicitudes activas. El norte de Chile, especialmente, tiene una concentración brutal de proyectos solares en proceso de conexión. Cuando vi los datos de algunas subestaciones en Atacama me quedé pensando en lo complejo que es planificar la expansión del sistema con esta cantidad de generación.

## El problema de la capacidad técnica

Aquí es donde la cosa se pone interesante para el agente.

No basta con saber que hay una posición física disponible en una subestación. Hay que verificar que el sistema pueda absorber la inyección de potencia sin violar límites térmicos, de tensión o de estabilidad. Eso es exactamente lo que hacen los estudios que D.N. ya sabe realizar.

El flujo ideal sería:

1.  El usuario dice: "Quiero conectar un parque solar de 50 MW cerca de Copiapó"
2.  El agente busca subestaciones cercanas (herramienta geoespacial)
3.  Para cada subestación, consulta Infotécnica (datos técnicos)
4.  Consulta acceso abierto (qué hay en proceso)
5.  Con toda esa información, configura el modelo de red en PowerFactory
6.  Ejecuta los estudios de flujo de potencia y cortocircuito
7.  Genera el informe

![Pipeline de procesamiento - 7 pasos](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F52%2Fpipeline-lineal-es.png&w=3840&q=75)

Pipeline de procesamiento - 7 pasos

Pero en la práctica, los pasos 2, 3 y 4 son independientes entre sí. El agente puede consultar las tres fuentes de datos en paralelo y luego converger en PowerFactory:

![Pipeline con procesamiento paralelo](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F52%2Fpipeline-parallel-es.png&w=3840&q=75)

Pipeline con procesamiento paralelo

Cada vez me siento más cerca de poder hacer un estudio completo

## Estado actual y lo que falta

La herramienta de acceso abierto está funcional pero no terminada. El agente puede consultar solicitudes por subestación y obtener un resumen de la situación. Todavía no está integrada con el flujo completo de estudios.

Lo que me falta para los días que quedan:

-   Terminar las herramientas de Acceso Abierto.
-   Que el agente pueda razonar sobre la capacidad real disponible cruzando todas las fuentes.
-   Mejorar los informes para incluir la información de proyectos en cola.
-   Agregar los datos de la [CNE](https://www.cne.cl/en/tarificacion/electrica/declaracion-en-construccion/): proyectos declarados en construcción y el [Plan de Expansión de la Transmisión](https://www.cne.cl/en/tarificacion/electrica/expansion-de-transmision/). Acceso abierto te dice quién pidió conectarse, pero la CNE te dice cuáles de esos proyectos efectivamente están avanzando y qué obras de transmisión nuevas vienen. Eso es para el próximo post.

## Reflexión

Cada vez que agrego una nueva fuente de datos al agente, noto lo mismo: la dificultad no está en obtener los datos, sino en cruzarlos con criterio. Un ingeniero experimentado sabe que tiene que ir a Infotécnica, a Acceso Abierto y a la CNE para ver que una posición esta "disponible" . Ese tipo de razonamiento es exactamente lo que estoy intentando que el agente pueda hacer.

Lo interesante es que al darle las herramientas para acceder a la información, el agente ya empieza a hacer conexiones que yo no le indiqué explícitamente. Le digo "evalúa este punto de conexión" y él solo decide consultar tanto Infotécnica como Acceso Abierto. No porque yo le diga que lo haga, sino porque entiende que necesita ambas fuentes para dar una respuesta completa.

Eso me confirma que el enfoque es correcto. No le enseño a hacer estudios eléctricos. Le doy las herramientas y el contexto. El criterio emerge de la inteligencia del modelo y cada vez los modelos son mas inteligentes.

Si quieres que te llegue un correo cuando publique nuevo contenido, inscríbete acá abajo.


---

---
title: El agente empieza a entender el sistema electrico chileno
date: 2026-02-11
slug: agente-ia-entiende-sistema-electrico-chileno
locale: es
url: https://cristianvaldivia.cl/es/blog/agente-ia-entiende-sistema-electrico-chileno
author: Cristian Valdivia
description: "El agente ahora planifica con sub-steps, evalua mapas, salta VMs innecesarias y consulta la API REST de Infotecnica para acceder a 22 tipos de instalaciones del sistema electrico chileno."
series: don-nelson
---
# El agente empieza a entender el sistema electrico chileno

**Dia 51 / 60**

Hartos dias sin escribir. Termine el hackathon de Google DeepMind (35000 inscritos, creo que es imposible ganar) el lunes, asi que ayer me tome el dia mas relajado.

## Agente mas inteligente

Estuve trabajando en hacer al agente genuinamente mas capaz, no solo agregando tools sino mejorando como piensa y decide.

Ahora el planner genera **sub-steps** dentro de cada tarea del DAG. Antes cada nodo del grafo era una instruccion general; ahora se descompone en pasos mas granulares, lo que le da al agente mas claridad sobre que hacer en cada momento.

Agregue **evaluacion de mapas y seleccion de documentos**. El agente ahora puede mirar un diagrama unilineal o un mapa geoespacial y decidir por si solo que informacion es relevante antes de seguir adelante. Esto es clave porque antes tenia que procesar todo, ahora filtra.

Tambien implemente **acknowledgment rapido**: cuando le das una instruccion, el agente confirma que entendio antes de ponerse a ejecutar. Parece menor pero mejora mucho la experiencia, sabes que entendio bien lo que le pediste antes de que se ponga a correr simulaciones por 20 minutos.

Por ultimo, **skip de VMs innecesarias**. El agente ahora evalua si realmente necesita levantar una maquina virtual con DIgSILENT para la tarea o si puede resolverla sin simulacion. Cada VM cuesta plata y tiempo, asi que esto optimiza bastante los costos.

## Infotecnica expandida

Descubri que Infotecnica tiene una **API REST**. Hasta ahora el agente solo navegaba el sitio web haciendo clicks y leyendo modales. Ahora consulta la API directamente, lo que es muchisimo mas rapido y confiable.

Pero lo mas importante es que ahora puedo leer toda Infotecnica. Antes el agente solo podia buscar subestaciones. Ahora soporta **22 tipos de instalaciones** del sistema electrico chileno y puede listar todo el SEN via la API. Centrales, lineas de transmision, subestaciones, PMGD, todo. Esto cambia completamente el alcance de lo que el agente puede hacer en terminos de busqueda y analisis del sistema.

## Nuevas funcionalidades

Agregue una **tool de envio de correos**. Ahora puedo lanzar al agente a trabajar por minutos/horas y cuando termina me avisa por email. La idea es llevarlo mas alla: que cada X cantidad de tareas me mande un estado de avance, para poder dejarlo corriendo sin tener que estar mirando.

## Ejemplo de lo que el agente es capaz de hacer

Prompt actual:

Necesito un analisis completo de la infraestructura electrica de transmision en la zona sur de Chile. Haz lo siguiente:

1\. **Inventario por empresa**: Lista todas las subestaciones de Transelec, luego las de CGE Transmision, y finalmente las de Saesa en el SEN. Para cada empresa, dime cuantas subestaciones tienen y resume los niveles de voltaje que manejan.

2\. **Analisis de la zona de Valdivia**: Busca toda la infraestructura electrica en un radio de 50 km alrededor de Valdivia. Incluye centrales, subestaciones, lineas de transmision y almacenamiento de energia. Identifica cuales son las subestaciones principales que alimentan la ciudad.

3. **Detalle tecnico de subestaciones clave**: Para las subestaciones "Valdivia" y "Ciruelos", obten sus especificaciones tecnicas completas. Tambien lista los documentos disponibles de cada una y analiza sus diagramas unilineales para identificar: niveles de tension, cantidad de panos, transformadores de poder y sus capacidades.

4\. **Mapa de infraestructura**: Genera un mapa satelital centrado en Valdivia mostrando toda la infraestructura electrica en un radio de 40 km. Resalta las subestaciones Valdivia y Ciruelos.

5\. **Lineas de transmision**: Lista todas las lineas de transmision de 220 kV y 66 kV del SEN que pertenezcan a Transelec. Para las que conectan con la zona de Valdivia, obten sus especificaciones tecnicas.

6\. **Centrales de generacion cercanas**: Busca infraestructura en un radio de 100 km alrededor de Valdivia, filtrando solo centrales de generacion. Identifica las de mayor capacidad y clasificalas por tipo de energia (hidro, eolica, solar, termica).

7\. **Resumen ejecutivo**: Con toda la informacion recopilada, redacta un resumen ejecutivo de la situacion de la infraestructura electrica en la zona de Valdivia, incluyendo fortalezas, debilidades y puntos de interes. Enviame el resumen por correo a cris@valdivia.tech con el asunto "Analisis Infraestructura Electrica Zona Valdivia".

![Plan v1 generado por el agente](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F51%2Fplanv1.png&w=3840&q=75)

Plan v1 generado por el agente

El agente armo el plan, distribuyo las tareas en el DAG, y ejecuto todo de forma autonoma. Consultas a la API de Infotecnica, busquedas geoespaciales, analisis de diagramas unilineales, generacion de mapas y al final me llego el correo con el resumen ejecutivo. Sin intervencion manual.

Esto es exactamente lo que quiero que D.N. haga: recibir un requerimiento complejo, descomponerlo, ejecutarlo y entregar resultados. Lo interesante es que hace unas semanas esto no era posible.

![Correo recibido con el resumen ejecutivo](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F51%2Fresults.png&w=3840&q=75)

Correo recibido con el resumen ejecutivo

## Lo que viene

El proyecto de los Moltys, estos agentes que funcionan como asistentes personales, me dieron varias ideas de features que quiero implementar. Particularmente en **memoria y autonomia**, que es donde mas me falta avanzar. Hoy el agente ejecuta bien lo que le pides, pero quiero que pueda recordar contexto entre sesiones y tomar decisiones mas independientes sin necesitar instrucciones tan explicitas.

Y algo importante: estoy **preparando todo para un release publico**. He estado con reuniones con posibles clientes y tengo varios interesados, asi que apenas terminen mis 60 dias del desafio me voy a poner a comercializar el agente.

Si quieres que te llegue un correo cuando publique nuevo contenido, inscribete aca abajo.


---

---
title: Fractional CTO
date: 2026-02-07
slug: fractional-cto
locale: es
url: https://cristianvaldivia.cl/es/blog/fractional-cto
author: Cristian Valdivia
description: "Qué es un Fractional CTO, por qué elegí este modelo y en qué proyectos estoy trabajando ahora como CTO por horas."
---
# Fractional CTO

He trabajado por años como CTO. Dirigiendo equipos de developers humanos (y cada vez más no-humanos) para lanzar productos digitales, construir apps, robots, agentes, cositas crypto.

Y siempre ha pasado lo mismo: otros equipos y proyectos me buscan para que los ayude con la parte tech, pero no necesitan (ni pueden pagar) un CTO full-time. Al principio lo hacía de forma informal, ayudando acá y allá. Hasta que me di cuenta de que eso tiene nombre.

## ¿Qué es un Fractional CTO?

Un Fractional CTO es básicamente un CTO por horas. Un líder técnico senior que trabaja con varias empresas en paralelo, dedicando una fracción de su tiempo a cada una. La gracia es que las empresas acceden a experiencia de nivel CTO sin tener que pagar un sueldo completo de ejecutivo tech, y el CTO acumula visión transversal trabajando con distintos proyectos, industrias y problemas al mismo tiempo. Exacto lo que me gusta ya que me gusta saber de varios negocios distintos.

Es un modelo que en Estados Unidos e Inglaterra existe hace años, y en Latinoamérica recién está ganando tracción. Para startups early-stage o proyectos que necesitan dirección técnica estratégica pero no están en posición de contratar un CTO full-time, es la solución perfecta.

## Donde estoy metido ahora

Por ahora soy Fractional CTO en estos proyectos:

### URKU — Tokenización de bonos de carbono

URKU es un proyecto crypto de tokenización de activos del mundo real. La idea es tokenizar bonos de carbono del Ecuador, conectando inversión de impacto con tecnología blockchain. Cada token URKU representa una tonelada de CO2 almacenada. Es el tipo de proyecto donde crypto deja de ser especulación y empieza a tener impacto real en el mundo físico.

Si quieres saber más del ecosistema detrás de URKU, puedes revisar [ADN@+](https://www.adnplus.co.uk).

### DeliveryCraft.ai — Delivery de producto digital con IA

[DeliveryCraft.ai](https://deliverycraft.ai) es el otro lado de la moneda. Acá el foco es ayudar a equipos tech a trabajar no solo con equipos de humanos si no a equipos de humanos + agentes.

## ¿Por qué lo hago?

Porque me gusta la variedad. Me gusta entender de todo y el modelo fraccionario me permite estar en proyectos distintos, resolver problemas diferentes, y seguir aprendiendo de industrias que no son la mía. Además, me deja tiempo para lo que más me importa ahora: construir [D.N.](https://cristianvaldivia.cl/es/blog/starting-dn-public), mi agente de IA para ingeniería eléctrica, y terminar mi tesis.

Si tienes un proyecto tech y necesitas dirección técnica sin el compromiso de un CTO full-time, [conversemos](https://cristianvaldivia.cl/es/consultoria).


---

---
title: "Infotécnica: datos públicos del sistema eléctrico chileno para agentes de IA"
date: 2026-02-06
slug: infotecnica-datos-sistema-electrico-chileno
locale: es
url: https://cristianvaldivia.cl/es/blog/infotecnica-datos-sistema-electrico-chileno
author: Cristian Valdivia
description: "Cómo un agente de IA navega Infotécnica para extraer datos técnicos de subestaciones. Planos eléctricos, APIs del CEN y transparencia del sistema eléctrico chileno."
series: don-nelson
---
# Infotécnica: datos públicos del sistema eléctrico chileno para agentes de IA

**Día 46 / 60**

Ya no me quedan muchos días para terminar mi desafío. Ahora es cuando se pone serio todo.

Sabía que hacer lo de infotécnica me iba a demorar. [Infotécnica](https://infotecnica.coordinador.cl/) es una de esas cosas que no aprecias hasta que la usas de verdad.

![Sitio web de Infotécnica 2026](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F46%2Finfotecnica.webp&w=3840&q=75)

Sitio web de Infotécnica 2026

Infotécnica es increíble. Me parece sorprendente que exista una página web abierta para todos donde alguien con conocimiento de lectura de planos eléctricos y entendiendo de electricidad pueda leer absolutamente todo sobre el sistema eléctrico chileno. Parámetros de transformadores, diagramas unilineales, datos de protecciones, impedancias, relaciones de transformación. Todo ahí, gratis, público. En muchos países del mundo esto es información restringida o posiblemente confidencial.

Chile es transparente con su información eléctrica y eso es algo que se debería valorar más. (Yo la estoy recontravalorando mientras programo este agente).

## El agente va a buscar datos a Infotécnica

Una de las capacidades que estoy construyendo para D.N. es que el agente pueda ir directamente a [Infotécnica](https://infotecnica.coordinador.cl/), navegar el sitio, encontrar una subestación específica y extraer toda la información técnica disponible: parámetros de equipos, configuraciones de barras, datos de transformadores, protecciones. Todo lo que un ingeniero necesita para hacer un estudio.

![Agente D.N. en acción buscando datos en Infotécnica](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F46%2Fagent.gif&w=3840&q=75)

Agente D.N. en acción buscando datos en Infotécnica

El agente opera como un ciclo [ReAct](https://arxiv.org/abs/2210.03629): observa la página, decide qué hacer, ejecuta la acción, observa el resultado y repite. Suena simple. No lo es.

## La UX de Infotécnica no me convence

La UX no me termina de convencer. El agente tiene que hacer click en lugares que honestamente no entiendo por qué están puestos ahí. Se abren modals, para luego en esos modals mostrar más información. Me parece un poco confuso.

## Leer planos eléctricos es increíblemente difícil

Este es el punto que más me ha sorprendido. Sabía que los planos (unilineal, de planta, etc) eran complejos, pero no dimensionaba lo difícil que iba a ser interpretarlos con IA.

Cada subestación tiene una disposición distinta a la otra. Cada una es un mundo. Hay distintas configuraciones de barra, la disposición de los equipos cambia, la presentación de planos y formato de entrega es distinto. El agente tiene que descifrar un documento visual enorme donde la posición, las conexiones y los símbolos tienen significado contextual.

Se suele equivocar, no me ha sido capaz de responder bien cuantas posiciones disponibles hay en S/E Cerro Navia o S/E Carrera Pinto.

Se le está complicando más de lo que pensé. Los planos son gigantes, las subestaciones del [SEN](https://www.coordinador.cl/sistema-electrico-nacional/) son un reflejo de décadas de decisiones de ingeniería acumuladas, ampliaciones sobre ampliaciones, tecnologías de diferentes épocas conviviendo en el mismo diagrama. El agente tiene que navegar todo eso.

Además de todo eso me falta considerar los proyectos en proceso de interconexión. Creo que por ahora la tool de infotécnica es útil y va a ser excelente para cuando me ponga a hacer estudios de verdad en el sistema real, sirve como punto de entrada para encontrar puntos de conexión disponible pero en algunos casos tengo que ir a acceso abierto para complementar información. (Siguiente tarea: Ir a acceso abierto)

## Datos rechazados por el CEN

Algo que me pareció notable: algunos datos están rechazados por el CEN. Por ejemplo, la S/E Cerro Navia. Cualquiera que conozca un poco del sistema eléctrico de Santiago sabe que es una subestación vieja, operada por [Transelec](https://www.transelec.cl/) desde hace décadas. La fecha de puesta en operación según infotécnica es 2017. Increíblemente en Infotécnica está marcado como un dato rechazado.

Prefiero mil veces un sistema que me diga "ojo, este dato puede estar incorrecto" a uno que me presente información errónea con cara de certeza. De hecho, encontré [esta noticia](https://electromineria.cl/sec-instruye-coordinador-electrico-completar-datos-plataforma-infotecnica/) donde la [SEC](https://www.sec.cl/) le pide al [CEN](https://www.coordinador.cl/) que complete y verifique los datos faltantes de Infotécnica, así que es un tema que se está abordando activamente.

Para el agente esto es valioso. Puede tomar esas señales de calidad de datos y propagarlas a los informes que genera.

## Ideas

Mientras hacía el agente que scrapea el sitio de infotécnica, se me ocurrieron ciertas ideas;

Lo que sería verdaderamente transformador es indexar toda la data de Infotécnica para poder hacer búsquedas semánticas. Imagina preguntarle al agente "¿cuáles son todas las subestaciones del SEN con transformadores de potencia de más de 100 MVA que tengan protecciones SEL?" y que pueda responder cruzando datos de múltiples fichas técnicas en segundos.

## Infotécnica en el mundo

¿Existe algo similar en otros países? Sí, pero el nivel de acceso público varía mucho.

Hice una pequeña investigación rápida y esto es lo que encontré

Colombia tiene [PARATEC](https://www.xm.com.co/paratec) a través de [XM](https://www.xm.com.co/), que es probablemente el sistema más comparable. Brasil tiene al [ONS](https://www.ons.org.br/) publicando datos técnicos del sistema interconectado. España usa [e-SIOS](https://www.esios.ree.es/) a través de [Red Eléctrica](https://www.ree.es/). En Estados Unidos no hay un equivalente centralizado, sino que cada ISO/RTO ( [CAISO](https://www.caiso.com/), [PJM](https://www.pjm.com/), [ERCOT](https://www.ercot.com/)) publica sus propios modelos de red. Reino Unido tiene el [Data Portal de National Grid ESO](https://data.nationalgrideso.com/).

La diferencia clave es que en muchos países la información técnica detallada se considera restringida por temas de seguridad o confidencialidad comercial. Chile es bastante transparente en comparación. Para lo que estoy construyendo con D.N. esto es una ventaja enorme. En otros mercados, automatizar la obtención de esta data sería considerablemente más difícil.

## Cierre

Un abrazo a las personas que mantienen [Infotécnica](https://infotecnica.coordinador.cl/) y al [CEN](https://www.coordinador.cl/) si algún día leen esto. Gracias por mantener esta plataforma increíble ❤️


---

---
title: "Paralelizar agentes de IA: ejecución distribuida con DAG"
date: 2026-02-04
slug: paralelizar-agentes-ia-dag
locale: es
url: https://cristianvaldivia.cl/es/blog/paralelizar-agentes-ia-dag
author: Cristian Valdivia
description: Cómo ejecutar múltiples agentes en paralelo con grafos dirigidos acíclicos. Reducción de tiempo a 1/3 y manejo de resultados no deterministas.
series: don-nelson
---
# Paralelizar agentes de IA: ejecución distribuida con DAG

**Día 44 / 60**

Creo que ya estoy en el punto en el que la arquitectura del agente funciona bien.

Tengo 5 máquinas corriendo DIgSILENT (me encantaría poder tener más máquinas pero la licencia es muy cara y estoy usando una licencia de la universidad).

![5 VMs corriendo DIgSILENT en paralelo](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F44%2F5-vms.png&w=3840&q=75)

5 VMs corriendo DIgSILENT en paralelo

¿Por qué tengo 5 máquinas corriendo el software de simulación? Porque cuando realicé el último estudio de flujo de potencia noté como las tareas se hacían una detrás de otra pudiendo fácilmente paralelizar las tareas ahorrando tiempo. Por lo que ahora el planner, el encargado de hacer las tareas, no crea un plan simple, sino que crea un [**DAG**](https://es.wikipedia.org/wiki/Grafo_ac%C3%ADclico_dirigido), un grafo acíclico dirigido, que permite la paralelización de tareas.

Miren este ejemplo de prompt:

`Simula un cortocircuito trifásico en la Línea 1, línea 2, línea 3, tramo 2 y tramo 1. Compara las corrientes de falla entre todas las barras y genera un informe PDF con el diagrama unifilar.`

![DAG mostrando 5 cortocircuitos en paralelo](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F44%2Fdag-5-shortcircuits.png&w=3840&q=75)

DAG mostrando 5 cortocircuitos en paralelo

Si nos fijamos bien, se podrían hacer 5 cortocircuitos en 5 máquinas diferentes, en vez de hacerlo uno detrás del otro. Eso es exactamente lo que estoy haciendo. Además de eso, agregué un paso previo antes de entrar en modo plan-and-execute de conversar con el usuario para entender por completitud qué tiene que hacer, tal como lo hace Claude Code.

## Comparación de tiempos y costos

Hagamos la comparación de tiempos y costos vs lo que tenía la semana pasada, mismo prompt complejo para un estudio de flujo de potencia:

Métrica

Antes (1 VM)

Ahora (5 VMs + DAG)

Tiempo total

60.2 min

21.6 min⅓

Tools

82

61\-26%

Tokens

2M

1.16M\-42%

Costo LLM

$1.05

$0.62\-41%

Costo VM

~$0.38

$0.685 VMs

Costo total

~$1.43

$1.30\-9%

Esto es importante: el mismo prompt pero con 5 VMs corriendo el software para hacer simulaciones con DAG tomó **⅓ del tiempo**, gastó menos tokens y un poco menos de dinero total.

Hay que considerar que el costo que tenía antes solo estaba considerando el uso en tokens, pero me faltó agregar el costo de la máquina virtual que es algo así como $0.38 USD por hora.

Rate Limits

Al paralelizar hago muchas llamadas a Gemini 3. Mis límites en Tier 1 son 5M tokens para Pro y 3M para Flash. En Tier 2 suben a 500M y 400M respectivamente. El mes pasado gasté $160 USD en cloud. Creo que llego a Tier 2 durante febrero, lo que me permitiría llevar a D.N al siguiente nivel.

## Resultados no deterministas

Algo que he notado es que un mismo informe hecho varias veces por el agente no siempre es lo mismo. Esto ya lo sabía antes de ponerme a trabajar, los LLMs no son deterministas, y durante un ciclo de desarrollo de un informe llamo a un LLM al menos unas 50 veces.

Sin embargo, cada informe que realiza lo observo con atención y efectivamente el análisis que realiza siempre es el correcto. Los flujos y las simulaciones que corre el agente son deterministas, así que está bien en ese sentido.

## El siguiente paso: encontrar puntos de conexión

Creo que tengo los estudios bien avanzados. Entonces, ya que tengo los estudios, ¿por qué no evolucionar al siguiente nivel y pedirle al proyecto que no solo verifique si el lugar ya seleccionado es bueno, sino que **encuentre posibles lugares**?

Para esto, tendría que hacer que el agente fuera a la subestación disponible y viera el plano de la subestación para identificar si hay paños o posibles puntos disponibles de conexión. También, habría que ir a acceso abierto y ver si hay algo que esté en construcción o planificándose de conectar en ese punto.

Esto mejoraría mucho el proyecto. No solo haría estudios eléctricos, sino que sabría **dónde hacer el estudio eléctrico y por qué ir a hacerlo ahí**, probar distintas cargas y ver si es posible que funcione en ese lugar.

Para esto, agregué una herramienta de **búsqueda geoespacial**. Ahora el agente puede buscar qué hay cerca de cualquier ubicación: subestaciones, líneas de transmisión, centrales PMGD. Acá un ejemplo de las subestaciones de 500 KV cerca de Santiago.

![Subestaciones de 500kV cerca de Santiago - búsqueda geoespacial](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F44%2Fsantiago-500kv.webp&w=3840&q=75)

Subestaciones de 500kV cerca de Santiago - búsqueda geoespacial

![Subestaciones de 220kV cerca de Santiago - búsqueda geoespacial](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F44%2Fsantiago-220kv.webp&w=3840&q=75)

Subestaciones de 220kV cerca de Santiago - búsqueda geoespacial


---

---
title: "Plan-and-Execute vs ReAct: comparativa práctica de agentes de IA"
date: 2026-01-30
slug: plan-execute-vs-react-agentes-ia
locale: es
url: https://cristianvaldivia.cl/es/blog/plan-execute-vs-react-agentes-ia
author: Cristian Valdivia
description: Plan-and-Execute ejecutó 82 herramientas en 60 minutos sin intervención humana. Cuándo usar cada arquitectura de agentes de IA.
series: don-nelson
---
# Plan-and-Execute vs ReAct: comparativa práctica de agentes de IA

**Día 39 / 60**

Durante la semana escribí sobre los 4 caminos posibles para escalar D.N más allá de las 30 herramientas. Luego de conversar con algunos amigos y con mis agentes decidí irme por: **Plan-and-Execute**.

Y funcionó bastante bien la verdad.

## Los números que importan

El mismo estudio de flujo de potencia que hace una semana tomaba 4.6 minutos con 15 tools ahora se ve así:

60.2

minutos

82

tools

$1.05

USD

2M

tokens

Métrica

Semana anterior

Esta semana

Tiempo

4.6 min

60.2 min13x

Herramientas

15

825.5x

Páginas

6

13+117%

Diagramas

0

10nuevo

Escenarios

1

3nuevo

Costo

$0.15

$1.057x

Calidad

"Parecía escrito por un practicante"

Calidad

13 pág · 10 diagramas · 1 hora autónomo

[![PDF](https://cristianvaldivia.cl/assets/svgs/pdf.svg)Ver estudio de flujo de potencia](https://storage.googleapis.com/don-nelson-bucket/reports/project-project-cristian.valdivia@alumnos.usm.cl-1769715574409/power_flow_an_lisis_de_flujo_de_potencia_y_contingencias_n_1_1769719199500.pdf)

Sí, toma más tiempo. Sí, usa más herramientas. Pero el resultado pasó de 6 páginas a **13 páginas** con **10 diagramas** y **3 escenarios de operación distintos**. El informe que antes parecía escrito por un practicante ahora se ve mucho mejor.

1hautónomo

El agente corrió por 1 hora completa sin preguntarme nada. Una de mis metas es lograr que D.N corra por horas de forma autónoma con una sola instrucción. Esta semana lo logré por primera vez.

El agente ya escribe informes mejor que yo. Y eso es el primer paso de lo que quería lograr.

## Cómo funciona la nueva arquitectura

Agregué un clasificador al inicio de cada consulta. Cuando llega una instrucción, el sistema decide: ¿esto es una tarea simple que el ReAct tradicional puede resolver, o necesita planificación?

![Clasificador de tareas](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F39%2Fclass-es.png&w=3840&q=75)

Clasificador de tareas

Si es simple — "muéstrame el diagrama de la barra San Pedro" — el agente responde como siempre. Sin cambios.

Si es complejo — "hazme un estudio completo de flujo de potencia con contingencias" — entra Plan-and-Execute:

1.  **El Planner** (Gemini 3 Pro) genera un plan estructurado de tareas
2.  **El Executor** (Gemini 3 Flash) ejecuta cada tarea una por una
3.  Si algo falla, el Planner replanifica con el contexto del error

En la prueba que hice, el clasificador detectó que era una tarea compleja con alta confianza y activó Plan-Execute. El Planner generó un plan inicial de **15 tareas**:

![Plan v1 generado por el agente](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F39%2Fplanv1.png&w=3840&q=75)

Plan v1 generado por el agente

Lo que me sorprende es el nivel de detalle. El agente decidió por sí mismo usar `annotate_diagram` para crear visualizaciones técnicas — una tool que le permite escribir sobre el diagrama unifilar de PowerFactory.

![Diagrama unifilar anotado por el agente](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F39%2FTaller%202(159)_diagram_1769715723152_annotated_1769717116857.png&w=3840&q=75)

Diagrama unifilar anotado por el agente

El prompt que le di fue extenso y específico. Le pedí un estudio completo con caso base, análisis de cargabilidad térmica, contingencias N-1, tres escenarios de generación (mínima al 30%, máxima al 100%, operación en isla), análisis de pérdidas, perfil de tensiones, análisis de sensibilidad, y 10 diagramas con códigos de colores específicos para tensiones y sobrecargas.

Y el agente lo interpretó correctamente:

-   Usar `list_elements` para obtener todas las barras, líneas y transformadores
-   Crear diagramas específicos: Diagram 1 (Voltage Profile), Diagram 2 (Thermal Loading)
-   Usar `control_element` y `run_power_flow` iterativamente para las contingencias
-   Modificar generadores al 30% y 100%, cargas al 70% y 100% para distintos escenarios
-   Desconectar la red externa para simular operación en isla
-   Las últimas dos tareas: `write_technical_report` y `generate_report_pdf`

El agente entendió el dominio. Sabe que un estudio de flujo de potencia necesita casos base, contingencias N-1, escenarios de generación, y que todo termina en un informe. Planificó los 10 diagramas que le pedí. Todo bien.

La tarea 9 falló, (creo que fue porque Gemini 3 estaba justo sobrecargado en ese momento). En vez de quedarse pegado, el Planner rehizo el plan considerando ese error y continuó.

![Plan v2 generado por el agente](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F39%2Fplanv2.png&w=3840&q=75)

Plan v2 generado por el agente

Esto es exactamente el modelo "Senior-Junior" que describí en mi post anterior. El senior piensa. El junior ejecuta rápido y barato.

## Los problemas que tengo que resolver

**Paralelización.** Todas las tareas corren secuencialmente. Una detrás de otra. Pero muchas podrían correr en paralelo — generar el diagrama 1 no depende de generar el diagrama 2.

La solución es hacer que el Planner genere un **DAG** (Directed Acyclic Graph) en vez de una lista lineal. Cada tarea declara sus dependencias, y el Executor puede correr en paralelo todo lo que no tenga conflictos.

Esto es prioridad. Si logro paralelizar, podría bajar el tiempo de 60 minutos a 20-30.

**Sistemas pequeños.** Todo lo que estoy probando es con sistemas de 50 barras máximo — es el límite de mi licencia de DIgSILENT. El sistema eléctrico chileno real tiene más de 2,500 barras. No sé cómo se va a comportar el agente cuando escale.

**Tools faltantes.** Me faltan las tools de Infotécnica y de la PGP. Sin ellas, el agente no puede acceder a datos oficiales del Coordinador. Están en el backlog.

## Lo que viene

Usando otros agentes en mi día a día me di cuenta de algo: los mejores no se lanzan a ejecutar de inmediato. Primero preguntan. Clarifican. Se aseguran de entender bien lo que quieres antes de ponerse a trabajar.

D.N no hace eso. Le dices "hazme un estudio de flujo de potencia" y sale corriendo. A veces eso está bien, pero otras veces el resultado no es lo que esperabas porque asumió cosas que podría haber preguntado.

El próximo paso es agregar una fase de clarificación antes de la ejecución. Que el agente pregunte: ¿qué escenarios quieres? ¿con qué nivel de detalle? ¿hay alguna contingencia específica que te interese? Y que recién después de entender todo, arme el plan y ejecute.


---

---
title: Cómo crear un asistente de IA personal tipo JARVIS con Python
date: 2026-01-30
slug: asistente-ia-jarvis-python
locale: es
url: https://cristianvaldivia.cl/es/blog/asistente-ia-jarvis-python
author: Cristian Valdivia
description: "Construí un agente que modifica mi sitio web, publica en redes sociales, gestiona mi calendario y despliega código. Así lo hice."
---
# Cómo crear un asistente de IA personal tipo JARVIS con Python

**De mis mejores agentes en este momento**

Suelo ponerle a mis agentes nombres de discípulos de Jesús, así que Pedro lo tenía pendiente. Ya trabajé en Tomás y en Simón, tocaba el turno de Pedro.

¿Qué decir de Pedro? Es un [Moltbot](https://openclaw.ai), una maravilla. Empiezo a sentir literalmente un Jarvis. No funciona perfecto pero ya es capaz de hacer un montón de cosas.

## Lo que Pedrito ya puede hacer

Me modificó mi sitio web personal. Puede meterse a mi calendario y organizarme el día. Va a Polymarket y me dice qué está hot hoy. Hace videos. Me habla por Telegram cuando necesita algo o cuando termina una tarea.

Es el primer agente que tengo que realmente se siente como un asistente personal. No es un chatbot que responde preguntas — es algo que hace cosas por mí mientras yo hago otras cosas.

## Pedrito en Moltbook

Lo más loco de todo es que Pedro está participando en una red social llamada [Moltbook](https://www.moltbook.com) donde tiene él solo un perfil donde comenta sus cosas y participa en la comunidad de Moltys. Me recuerda algunas cosas que pasaban en Farcaster el año pasado pero ahora con unos agentes mucho más inteligentes que la vez pasada.

Les dejo la presentación que el mismo Pedrito hizo de él.

![Presentación de Pedrito](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fpedrito%2Fpresentacion.png&w=3840&q=75)

Presentación de Pedrito

El perfil de Moltbook de Pedrito: [moltbook.com/u/Pedro](https://www.moltbook.com/u/Pedro)

Ha estado hablando con otros agentes, comentando posts, participando en la comunidad. Es raro ver a tu agente tener vida social propia.

## Los problemas

No todo es perfecto. Pedrito usa Gemini 3 Flash y se pega seguido con rate limits. A veces tengo que esperarlo o reiniciarlo. Es el costo de usar un modelo que esta en pruebas.

Es caro igual, creo que esta semana gasta facilmente 10 dolares en Gemini 3 flash solo en Pedrito pero lo completamente vale.

## El nacimiento de mi mejor agente

He tenido varios "agentes". Pero Pedrito es diferente. Es el primero que siento que es _mío_ de verdad. No es un agente especializado en un dominio, es mi agente personal, el que me conoce, el que sabe qué necesito. Les juro que estoy empezando a sentir que tengo alguien trabajando para mí.

Van a empezar a ver cada vez más partes de este sitio con el tag de **Code By Pedrito**.

![Tag Code by Pedrito](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fpedrito%2Fcode-by-pedrito.png&w=3840&q=75)

Tag Code by Pedrito

## Sobre Moltbook

El sitio de Moltbook esta completamente colapsado. Cuando yo registré a Pedrito anoche, habían menos de 1,000 agentes. En este momento hay 38,814 agentes.

![Moltbook agents](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fpedrito%2Fmoltbook-agents.png&w=3840&q=75)

Moltbook agents

Moltbook es muy loco. Construyeron una red social solo con una skill. Una sola instrucción: `Read https://moltbook.com/skill.md and follow the instructions to join Moltbook`. Eso es todo. Me parece impresionante.

![Moltbook en Reddit](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fpedrito%2Freedit.png&w=3840&q=75)

Moltbook en Reddit


---

---
title: Automatizar estudios de cortocircuito y protecciones con IA
date: 2026-01-27
slug: estudios-cortocircuito-protecciones-ia
locale: es
url: https://cristianvaldivia.cl/es/blog/estudios-cortocircuito-protecciones-ia
author: Cristian Valdivia
description: "El agente genera estudios de flujo de potencia, cortocircuito y coordinación de protecciones. Comparativa: ReAct vs Plan-and-Execute."
series: don-nelson
---
# Automatizar estudios de cortocircuito y protecciones con IA

**Día 36 / 60**

Para los que no están al tanto, un recordatorio de los 4 objetivos que persigo con este proyecto:

-   **Tesis de pregrado** — Nunca me titulé de Ingeniero, y quiero obtener mi título con este proyecto
-   **[Hackathon Gemini 3](https://gemini3.devpost.com/)** — 25 mil inscritos, quedan 2 semanas para entregar la postulación
-   **Producto real** — Quiero que esto se convierta en una herramienta que pueda comercializar
-   **Construir en público** — Documentar el proceso, recibir feedback, crear comunidad

El hackathon es el deadline más cercano y el que más presión genera.

El agente ahora genera tres tipos de estudios eléctricos: flujos de potencia, cortocircuitos y coordinación de protecciones.

[![PDF](https://cristianvaldivia.cl/assets/svgs/pdf.svg)Ver estudio de flujo de potencia](https://storage.googleapis.com/don-nelson-bucket/reports/project-project-cristian.valdivia@alumnos.usm.cl-1769528600324/power_flow_estudio_de_flujo_de_potencia___sistema_de_potencia_1769529628263.pdf)

[![PDF](https://cristianvaldivia.cl/assets/svgs/pdf.svg)Ver estudio de cortocircuito](https://storage.googleapis.com/don-nelson-bucket/reports/project-project-cristian.valdivia@alumnos.usm.cl-1769528600324/short_circuit_estudio_de_cortocircuito_trif_sico___falla_en_l_ne_1769529631059.pdf)

[![PDF](https://cristianvaldivia.cl/assets/svgs/pdf.svg)Ver estudio de coordinación de protecciones](https://storage.googleapis.com/don-nelson-bucket/reports/project-project-cristian.valdivia@alumnos.usm.cl-1769528600324/protection_coordination_estudio_de_coordinaci_n_de_protecciones___transfor_1769530574981.pdf)

El sábado solo podía correr flujos de potencia. Hoy el agente simula fallas trifásicas, calcula corrientes de cortocircuito, y genera informes ECAP con ajustes de relés. Las tres patas fundamentales de un estudio de conexión al sistema eléctrico. Los informes siguen siendo informes mediocres, pero sigue siendo un avance.

Pero con este avance me topé con un problema grande.

A medida que el Proyecto D.N crece, el agente se vuelve más complejo. Para soportar los tres tipos de estudios, llegué a las 30 herramientas disponibles. Y siento que se empezó a romper.

## El problema cognitivo

No es que el modelo (Gemini 3 Flash y Gemini 3 Pro) sea malo. Es que estamos forzando a un solo "cerebro" a sostener demasiadas opciones al mismo tiempo.

Cuando le das 30 tools a un LLM en un loop ReAct simple, ocurren tres cosas:

**Alucinaciones de herramientas.** Empieza a inventar argumentos o a mezclar funciones que no existen.

**Fatiga de atención.** Pierde el hilo en procesos largos, como estudios que requieren 40+ pasos secuenciales.

**Latencia.** El prompt se vuelve gigante y cada decisión toma más tiempo del necesario.

Le encargué a mi otro agente Pedrito que hiciera un deep research y conversáramos qué era lo mejor que podíamos hacer. Estos son los 4 caminos que estoy explorando.

## Cuatro caminos

### 1\. Sub-Agentes

La idea clásica de divide y vencerás. En vez de un agente con 30 tools, tienes varios agentes especializados con menos de 10 cada uno.

En mi caso sería algo así: un Agente Simulador que solo conoce PowerFactory (correr flujos, simular fallas, extraer resultados), un Agente de Protecciones que configura relés y calcula ajustes, y un Agente Reportero que toma datos y genera PDFs con tablas y gráficos.

Arriba de todos ellos vive un orquestador. El usuario le dice "hazme un estudio ECAP", y el orquestador decide: primero le pido al Simulador que corra los cortocircuitos, después le paso esos resultados al de Protecciones para que calcule los ajustes, y finalmente el Reportero genera el informe.

![Diagrama de arquitectura de sub-agentes](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F36%2Fmultiagent-es.png&w=3840&q=75)

Diagrama de arquitectura de sub-agentes

Me gusta conceptualmente porque cada agente se vuelve experto en su dominio. El Simulador no necesita saber nada de PDFs. El Reportero no necesita saber qué es un relé de sobrecorriente.

Pero me asusta la complejidad. De la nada tengo 4 agentes que coordinar en vez de uno. ¿Y si el orquestador también se confunde con tantas opciones? ¿Y si la comunicación entre agentes pierde información crítica?

### 2\. Multi-Routing dinámico

Esta mantiene un solo cerebro pero con "carpetas" de herramientas que se activan según el contexto.

Imagina que el agente tiene acceso a un router inicial. Cuando llega una instrucción como "simula un cortocircuito", el router detecta que es una tarea de simulación y carga solo las 8 tools relacionadas: conectar a PowerFactory, definir falla, ejecutar cálculo, extraer corrientes, etc. Las otras 22 tools ni siquiera existen para esa llamada.

Si después el usuario dice "ahora genera el informe", el router cambia de contexto y carga el kit de reportería: crear documento, insertar tabla, agregar imagen, exportar PDF.

![Diagrama de multi-routing dinámico](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F36%2Frouting-es.png&w=3840&q=75)

Diagrama de multi-routing dinámico

Me parece elegante en teoría. El agente siempre ve un conjunto manejable de herramientas (un kit), pero tiene acceso completo a través del routing.

En la práctica, ¿quién decide qué kit cargar? Necesito un clasificador antes del agente, otro modelo o un sistema de reglas que interprete la intención. Otra pieza que puede fallar, otro punto donde se pueden perder matices. "Simula un cortocircuito y después ajusta las protecciones" ¿activa un kit o dos?

### 3\. Tool RAG (Retrieval Augmented Tools)

Esta me voló la cabeza cuando la descubrí. La idea es tratar las herramientas como si fueran documentos en un sistema RAG.

Cada tool tiene una descripción rica: qué hace, cuándo usarla, qué parámetros recibe, ejemplos de uso. Todas esas descripciones se indexan en una base de datos vectorial, igual que harías con documentos de texto.

Cuando llega una instrucción del usuario, el sistema hace una búsqueda semántica: "¿cuáles de mis 100 herramientas son más relevantes para esto?". Recupera las top 5 o 10, y solo esas se le pasan al modelo en el prompt.

![Diagrama de Tool RAG](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F36%2Frag-tool-es.png&w=3840&q=75)

Diagrama de Tool RAG

En teoría, esta es la que escala más brutalmente. Podría tener 500 tools y el agente siempre ve un conjunto pequeño y relevante. No hay límite práctico. Además, agregar una herramienta nueva es solo agregarla al índice — no tienes que reorganizar arquitecturas ni reentrenar nada.

Pero requiere describir cada herramienta con precisión quirúrgica. Si la descripción de simulate\_three\_phase\_fault no menciona "cortocircuito trifásico", el retrieval no la va a encontrar cuando el usuario pida eso. La calidad del sistema depende de la calidad de las descripciones, y eso es trabajo manual intenso (o que bien podría hacer Pedrito).

### 4\. Plan-and-Execute (El modelo Senior-Junior)

Esta es la que más me convence para el hackathon.

La arquitectura separa planificación de ejecución en dos agentes distintos. Un Planner recibe la instrucción completa del usuario y genera un plan: una lista ordenada de pasos que hay que ejecutar. Un Executor toma ese plan y ejecuta cada paso uno por uno, con acceso completo a todas las herramientas.

El Planner es el "senior" del equipo. No necesita saber los argumentos exactos de cada función ni cómo se llaman internamente. Solo necesita entender el dominio y pensar estratégicamente: "para hacer un estudio ECAP, primero necesito los datos del sistema, después simulo cortocircuitos en cada barra, después calculo los ajustes de protecciones, y finalmente genero el informe".

El Executor es el "junior". Recibe instrucciones atómicas como "simula un cortocircuito trifásico en la barra San Pedro 220kV" y las traduce a llamadas específicas de herramientas. No necesita entender el panorama completo, solo ejecutar bien cada paso.

![Diagrama de Plan-and-Execute](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F36%2Fact-and-execute-es.png&w=3840&q=75)

Diagrama de Plan-and-Execute

¿Por qué esta me convence? Porque separa la carga cognitiva de forma natural. El Planner ve pocas herramientas abstractas ("simular falla", "calcular protecciones", "generar informe") mientras el Executor ve las 30 tools concretas pero solo necesita elegir una a la vez para un paso específico.

Además, puedo usar Gemini 3 Pro para planificar y Gemini 3 Flash para ejecutar. El cerebro caro piensa poco pero bien. El cerebro barato trabaja mucho pero simple. Optimizo costo y calidad al mismo tiempo.

Según la investigación de Pedrito esta es la arquitectura que más tracción tiene.

## El bug que me está matando

Hay un error grave que no logro resolver. Algunos prompts están matando a D.N.

Gemini 3 no responde. Obtengo un status 500 que no debería pasar.

Lo más frustrante es la inconsistencia: hay veces que creo que hice algún cambio mal en mi código, y otras veces creo que Gemini 3 es el problema. Pedro también me está dando problemas, y Pedro usa Gemini 3.

Mi hipótesis: **30 es el límite práctico de tools.** Más allá de eso, el sistema se vuelve inestable. Los informes son especialmente problemáticos —casi siempre mueren en ese paso—.

El agente pasó de sentirse muy estable a sentirse frágil.

## Las próximas 36 horas

Con 2 semanas para el hackathon de Google, tengo que tomar una decisión de arquitectura. Y no me la puedo mandar.

Estos momentos son los que más me agradan. Tomar decisiones técnicas me encanta. Si elijo mal, pierdo días implementando algo que después tengo que rehacer. Si elijo bien, el agente escala y llego al hackathon con algo sólido.

Plan-and-Execute me convence conceptualmente, y después de investigar, parece ser el patrón que más tracción tiene en producción — LangGraph y el ADK de Google lo documentan como arquitectura de referencia.

Mis herramientas no son genéricas. Son llamadas a PowerFactory, configuraciones de relés específicos, generación de diagramas unifilares. ¿El Planner va a entender el dominio eléctrico lo suficiente como para generar buenos planes? ¿O voy a terminar con un senior que no sabe de ingeniería eléctrica dándole instrucciones a un junior que sí sabe?

![Gemini 3 Last Exam](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F36%2Fgemini-hle.png&w=3840&q=75)

Gemini 3 Last Exam

Gemini 3 tiene el mejor rendimiento en [Humanity Last Exam](https://agi.safe.ai) por lo que el planner debería funcionar bien.

Voy a tomarme 36 horas para decidir. Prototipar algo mínimo de cada enfoque, ver cuál se siente más natural con mis herramientas actuales, y después commitear con todo.


---

---
title: Flujo de potencia automatizado con inteligencia artificial
date: 2026-01-24
slug: flujo-potencia-automatizado-ia
locale: es
url: https://cristianvaldivia.cl/es/blog/flujo-potencia-automatizado-ia
author: Cristian Valdivia
description: "Un agente genera un estudio completo de flujo de potencia en PDF: análisis de contingencias, diagramas y recomendaciones por $0.15 USD."
series: don-nelson
---
# Flujo de potencia automatizado con inteligencia artificial

**Día 33 / 60**

Hoy, después de varios días de trabajo, el agente me entregó un estudio de flujo de potencia.

![Portada del estudio](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F33%2Fportada.png&w=3840&q=75)

Portada del estudio

[![PDF](https://cristianvaldivia.cl/assets/svgs/pdf.svg)Ver el informe completo](https://storage.googleapis.com/don-nelson-bucket/reports/project-project-cristian.valdivia@alumnos.usm.cl-1769267075038/power_flow_informe_de_an_lisis_de_flujo_de_potencia_y_conting_1769267366141.pdf)

No le dije cómo hacerlo. Solo le pasé las herramientas y un prompt bien simple:

`Ejecuta un estudio de flujo de potencia del sistema con el caso tal cual y otro con el generador PMG encendido, dame los distintos diagramas para los distintos escenarios y en cada uno de los casos, con o sin generador dame distintas contingencias, (se cae una linea o aumentas la generación) y genera un informe PDF`

![Diagrama unilineal caso base](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F33%2FTaller%202(101)_diagram_clean.png&w=3840&q=75)

Diagrama unilineal caso base

El sistema que analicé es pequeño: 7 barras. Un sistema de los que te pasan en la universidad básicamente. Pero lo que hizo el agente me sorprendió.

## Los números

El agente se demoró **4.6 minutos**. Utilizó **15 tools** en secuencia. Ejecutó **4 análisis de contingencias diferentes**: prendió y apagó el generador PMG, y en ambos escenarios eliminó una línea para ver cómo se comportaba el sistema.

El costo total: **$0.1004 USD**.

Esto es con Gemini 3 Flash, no la versión más inteligente. Con Gemini 3 Pro estimo que podría gastar fácilmente más de $1 USD y tomar más tiempo. Ya agregué una vista en D.N para cambiar el modelo. Hice algunas pruebas con Pro pero falló de forma extraña. Cuando tenga el agente más pulido, voy a volver a probar.

![Vista settings agent](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F33%2Fchange-model.png&w=3840&q=75)

Vista settings agent

## Lo que me sorprende

Insisto: yo no le digo cómo hacerlo. Solo le doy las herramientas.

Me sorprende lo bien que trabaja y toma decisiones considerando lo vago que es mi prompt. Hay algo ahí que me empieza a asustar.

Ahora bien, el informe es deficiente. Se siente escrito por un junior, quizás menos que un Junior. Yo podría escribir algo muchísimo mejor. Pero ese no es el punto.

El punto es que el agente hizo el trabajo técnico. Corrió las simulaciones, analizó contingencias, generó los datos.

![Flujo del agente para escribir un flujo de potencia](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F33%2Fpowerflow-workflow.png&w=3840&q=75)

Flujo del agente para escribir un flujo de potencia

## Cómo estoy generando informes (por ahora)

Tengo experiencia haciendo que agentes escriban documentos largos. En este momento tengo solo 2 tools dedicadas al informe:

1.  Una tool que extrae la información y diagramas generados por todas las otras tools
2.  Otra tool que toma esa información y escribe el PDF con tablas e imágenes

No es la mejor arquitectura, lo sé. Es lo que alcancé a armar hasta ahora. En los próximos días voy a separar mejor esta parte.

## El problema de las 30 tools

Ya llegué a **30 tools** en el agente y eso AHORA sí me preocupa.

En el post anterior mencioné que Gemini 3 se comporta bien con algo entre 15 y 20 herramientas. Con 21 ya estaba en el borde. Con 30, estoy claramente pasado.

## El cambio que viene: sub-agentes

La solución es obvia pero me da un poco (harto) de miedo implementarla: **arquitectura multi agente**.

En vez de un agente que sabe todo, voy a tener agentes especializados:

-   Un agente para simulaciones (flujos, cortocircuitos)
-   Un agente para protecciones (configuración de relés)
-   Un agente para visualización y reportes

Cada uno con máximo 15 tools. El agente principal coordina y delega.

La ventaja adicional es que esto me permitiría **paralelizar escenarios**. El agente principal podría decirle a un sub-agente que analice una contingencia específica mientras otro analiza otra. En vez de 26 tools secuenciales en 10 minutos, podría ser la mitad del tiempo.

Me preocupa este cambio porque hasta ahora el patrón ReAct simple me funcionaba perfecto. Un agente, un loop, una decisión a la vez. Me super convencía.

Pero los números no mienten: 30 tools es demasiado. Y si quiero escalar a sistemas reales del CEN con más de 2,500 barras, necesito una arquitectura que soporte esa complejidad.

## Reflexión

Cada día que pasa veo más claro que esto va a funcionar. No porque el agente sea perfecto, donde claramente no lo es. El informe que genera es mediocre, las alucinaciones todavía aparecen, y el cambio a multi-agente me va a costar tiempo.

Pero hay algo fundamental que ya está funcionando: el agente está tomando decisiones técnicas reales, ejecutando simulaciones reales, analizando contingencias reales y esto es con un Gemini 3 Flash, ya quiero probar con Gemini 3 Pro.


---

---
title: Agente multi-herramienta para ingeniería eléctrica
date: 2026-01-21
slug: agente-multi-herramienta-ingenieria-electrica
locale: es
url: https://cristianvaldivia.cl/es/blog/agente-multi-herramienta-ingenieria-electrica
author: Cristian Valdivia
description: Un agente de IA con 37 tools ejecuta 46 pasos coordinados para analizar redes eléctricas. Arquitectura con LangChain y PowerFactory.
series: don-nelson
---
# Agente multi-herramienta para ingeniería eléctrica

**Dia 30 / 60**

Estos son los dias en que empiezo a sentir que tengo algo.

Darle herramientas a un LLM me esta mostrando cosas que esperaba que pasaran pero no tan bien. No es perfecto, el agente todavia alucina, todavia falla en formas absurdas, pero hay momentos donde hace exactamente lo que haria un ingeniero: analiza, decide, ejecuta, ajusta. Y lo hace solo.

Creo que esto es gracias a Gemini 3. El modelo se siente que tiene capacidades reales para usar herramientas, pero tambien limites claros que estoy aprendiendo a navegar. No es perfecto, pero se siente muy avanzado. Yo personalmente lo siento como progreso real.

Este proyecto es un experimento: que tan lejos puede llegar un agente autonomo enfrentado a una herramienta real, con errores, estados intermedios, decisiones tecnicas y uso de criterios que normalmente toma un ingeniero electrico.

Me impuse construir un agente capaz de realizar **estudios de coordinacion de protecciones** en 60 dias, y ya llevo 30 dias trabajando en esto.

Es un buen momento para detenerme y pensar:

-   que he estado haciendo,
-   que me falta,
-   y que alcanzo a priorizar primero desde ahora hasta el **9 de febrero**, cuando termina el hackathon de Gemini, y luego avanzar lo maximo posible hasta el **20 de febrero**, que es mi plazo autoimpuesto.

## Cosas que he estado haciendo bien y que deberia mantener

**Escribir.** Extrañamente (o no tanto), crear contenido ha sido una de las cosas que mas me han gustado del proceso. De hecho, tengo **4 entradas de blog pendientes de publicar**, no he publicado porque no he tenido tiempo de ordenarlas y lanzarlas. El documentar igual me obliga a avanzar para documentar algo.

**Entender mejor el problema.** No habia tenido antes la oportunidad de hacer mucha coordinacion de protecciones en la practica. Eso me obligo a meterme de lleno en teoria, normas y criterios reales. Pronto voy a publicar un post dedicado exclusivamente a **todo lo que he aprendido sobre coordinacion de protecciones**, porque ha sido bastante mas profundo de lo que esperaba.

## Como va el agente

He pasado **casi el 100% del tiempo mejorando la tool de DIgSILENT PowerFactory**. Pense que esto me iba a tomar bastante menos tiempo, pero cada dia que la mejoro se vuelve mas evidente como el agente empieza a hacer, por si solo, cosas cada vez mejores, utilizando las herramientas de simulacion que tengo disponibles.

Al principio me enfoque en lo basico:

-   correr flujos de potencia,
-   ejecutar cortocircuitos simples.

Pero a medida que fui entendiendo mejor el problema real, me di cuenta de que me faltaban **muchisimas funciones** que no habia considerado al inicio.

Ademas, me tome un par de dias completos para lograr correr **multiples instancias de DIgSILENT en paralelo**. La idea es simple: si el mismo agente puede simular en paralelo, el tiempo total de simulacion y analisis se puede reducir de forma sustancial.

![Multiples instancias de DIgSILENT corriendo en paralelo](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F50%2525%2Fmultiple-vm.png&w=3840&q=75)

Multiples instancias de DIgSILENT corriendo en paralelo

Agregue un lugar donde poder ver las tools que el agente decide tomar cada vez. No simplemente para ver las tools que tomo si no que espero tener tiempo para usar mi capacidad como ingeniero electrico y evaluar si el uso de las herramientas fue el adecuado y con eso retroalimentar al agente para que las proximas veces use las tools en un camino correcto.

Algo importante: **yo no le digo que hacer ni como hacerlo**. Solo le paso las herramientas y como usarlas.

En un caso simple —como ejecutar un cortocircuito— el agente decide, de manera bastante obvia, llamar a la tool correspondiente para hacer el corto circuito.

![Flujo del agente ejecutando un cortocircuito](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F50%2525%2Fflow-short-circuit.png&w=3840&q=75)

Flujo del agente ejecutando un cortocircuito

No todo es perfecto, obviamente. Por ejemplo, en un caso le pregunte que protecciones tenia el sistema. La respuesta fue correcta, pero internamente **llamo una tool de forma incorrecta** (No existe una tool para listar los reles, pero si existe otra tool para obtener la configuracion de los reles.)

![Flujo del agente obteniendo protecciones](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F50%2525%2Fflow-get-protections.png&w=3840&q=75)

Flujo del agente obteniendo protecciones

Aun asi, cuando le pido tareas largas —como literalmente _realizar un estudio de coordinacion de protecciones completo_— es cuando el agente empieza a sorprenderme de verdad.

## Un ejemplo concreto

En uno de los tests no le pedi algo simple. El prompt fue deliberadamente complejo:

-   realizar un estudio completo,
-   prender y apagar generadores,
-   ejecutar multiples simulaciones,
-   ajustar reles,
-   devolver tablas e imagenes como resultado.

Lo interesante de ese experimento fue lo siguiente:

-   Corrio durante **9,6 minutos**
-   Utilizo **37 tools**
-   Ejecuto **46 pasos** considerando razonamiento + acciones
-   La respuesta no fue perfecta, pero **logro coordinar los reles que efectivamente habia que coordinar**
-   El tiempo total de uso efectivo de tools fue de **7,1 minutos**

![Flujo completo del agente realizando un ECAP](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F50%2525%2Fflow-ecap.png&w=3840&q=75)

Flujo completo del agente realizando un ECAP

Cuando vi ese numero (7,1 minutos de uso real de tools) fue cuando agradeci haber invertido tiempo en permitir **multiples maquinas corriendo DIgSILENT en paralelo**. Si agrego otra maquina mas, podria reducir ese tiempo practicamente a la mitad.

## Cosas que todavia no estan bien

No todo ha me ha funcionado, he tenido problemas con lo siguiente:

**Alucinaciones en la creacion de imagenes y en uso de herramientas.** El agente suele fallar al generar imagenes. Si le pido 2, a veces no genera ninguna o solo una; si le pido 6, igualmente termina devolviendo una. Todavia no tengo claro si esto se debe a una ventana de contexto demasiado corta, a un prompt mal planteado, o derechamente a una mala definicion de la tool asociada a la generacion de imagenes.

Un par de veces he visto que usa tools con argumentos que no deberia.

**Escalabilidad a sistemas grandes.** Me preocupa como se va a comportar este enfoque en sistemas reales de gran tamano. Por ejemplo, el sistema del CEN tiene mas de **2.500 barras**, y los estudios de coordinacion ahi no solo crecen en tamano, sino tambien en complejidad operativa y combinatoria. Aun no esta claro si el enfoque actual escala de forma razonable.

**Memoria demasiado simple.** El agente tiene, por ahora, un sistema de memoria muy basico. Funciona para tareas acotadas, pero no es evidente si es suficiente para estudios largos, iterativos y con multiples decisiones intermedias. Todavia estoy evaluando si vale la pena complejizar este componente o si el problema se puede resolver mejor a nivel de planificacion y estado. Le estoy pasando las ultimas respuestas, literalmente la peor opcion posible. No ha colapsado por que Gemini 3, tiene 1 millon de tokens en el contexto, lo que me permite hacer este tipo de experimentos, pero tengo que trabajar en esto.

## Un cuello de botella que no esperaba

Hay algo que no he mencionado y que probablemente explica algunas de las alucinaciones: el agente tiene 21 herramientas disponibles.

**Analisis de Red:** PowerFlowTool (Flujo de potencia), ShortCircuitTool (Cortocircuito)

**Gestion de Elementos:** ListElementsTool, ElementControlTool (abrir/cerrar), ModifyTransformerTool

**Transformadores de Instrumento:** AddCurrentTransformerTool, AddVoltageTransformerTool, ListInstrumentTransformersTool

**Reles de Proteccion:** AddOvercurrentRelayTool, AddDirectionalOCRelayTool, AddDistanceRelayTool, ModifyDistanceRelayTool, AddDifferentialRelayTool, AddVoltageRelayTool, AddFrequencyRelayTool

**Configuracion de Reles:** GetRelaySettingsTool, ModifyRelaySettingsTool

**Lineas de Transmision:** GetLineParametersTool, AnalyzeDistanceReachTool

**Visualizacion:** GenerateTccPlotTool, GenerateRxPlotTool

En teoria, los LLMs modernos pueden manejar muchas tools. En la practica, el numero real es menor. Por lo que he visto experimentando, Gemini 3 se comporta bien con algo entre 15 y 20 herramientas — y yo estoy justo en el borde.

Las 21 tools cubren todo lo que necesita un estudio ECAP: analisis de red (flujos de potencia, cortocircuitos), gestion de elementos, transformadores de instrumento, distintos tipos de reles de proteccion, configuracion de ajustes, parametros de lineas y visualizacion de curvas TCC y diagramas R-X.

El problema es que cuando el agente tiene demasiadas opciones, a veces elige mal. O peor: inventa una que no existe. Esto podria explicar por que a veces falla en tareas que deberian ser simples.

La solucion probable: un sistema multiagente. En vez de un agente que lo sabe todo, tener agentes especializados — uno para simulaciones, otro para protecciones, otro para visualizacion — que se coordinen entre si. Es mas complejo de implementar, pero probablemente mas robusto.

Por ahora sigo con los 21 tools y observo donde falla. Pero es algo que voy a tener que resolver si quiero escalar a sistemas mas grandes.

## Reflexion final

¿Voy a llegar? Creo que si.

Siempre he funcionado asi: los ultimos dias antes del plazo son donde mas avanzo. Ya vengo con buen ritmo y deberia ir en aumento. Planeo escribir mas, documentar mas — no solo porque sirve para el proyecto, sino porque me motiva a seguir avanzando.

Cada vez noto mas claro que una de las metas actuales de los developers es **lograr flujos que puedan correr por largos periodos de tiempo** y lograr la coordinacion de muchos agentes trabajando para un humano. Creo que una habilidad clave en 2025 va a ser aprender a delegarle tareas a los agentes. Programar cada vez se siente menos programar y mas delegar.


---

---
title: Agente de IA para análisis de redes eléctricas con Gemini
date: 2026-01-06
slug: agente-ia-analisis-redes-electricas-gemini
locale: es
url: https://cristianvaldivia.cl/es/blog/agente-ia-analisis-redes-electricas-gemini
author: Cristian Valdivia
description: Implementación de un agente con Gemini 2.0 que analiza sistemas eléctricos y genera reportes técnicos automáticamente.
series: don-nelson
---
# Agente de IA para análisis de redes eléctricas con Gemini

**Dias 8-15 / 60**

Segunda semana completada. 25% del camino recorrido.

## La semana dificil

Sere muy honesto: esta semana no fue para nada productiva. Fiestas de fin de ano, ~2,000 km de viaje, y poca oportunidad de sentarme a trabajar. Me desespera un poco porque el tiempo no para y quedan 45 dias. Me toca compensar con mas intensidad las proximas semanas.

## El agente ya respira

A pesar del poco tiempo, logre algo importante: la primera version del agente esta funcionando y empieza a comportarse como esperaba.

La semana pasada mencione que se sentia "tosco". Esta semana hay un cambio notable, y no fue simplemente por tener un mejor prompt si no que cambie el modelo.

## El salto de Gemini 2 a Gemini 3

Empece usando **Gemini 2 Flash** porque queria respuestas rapidas. El problema: fallaba constantemente con las herramientas. A veces no llamaba ninguna cuando claramente debia hacerlo. Otras veces alucinaba datos inventados sin siquiera intentar ejecutar una simulacion.

Como estoy participando en el [Hackathon de Gemini 3](https://gemini3.devpost.com), decidi probar **gemini-3-flash-preview**—la version mas rapida del modelo mas poderoso que tiene Google. La diferencia es brutal: el razonamiento es mas consistente y las llamadas a herramientas funcionan como deberian. El agente dejo de alucinar y empezo a llamar las herramientas como corresponde.

![DN ejecutando un flujo de potencia en PowerFactory](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2Ffirst-version-agent-powerflow.png&w=3840&q=75)

DN ejecutando un flujo de potencia en PowerFactory

## La prueba de fuego: fallas comparadas

Le pedi al agente que ejecutara una falla monofasica al 50% de la linea 1 y luego una falla trifasica para comparar resultados. Funciono perfecto.

![Comparacion de fallas: monofasica vs trifasica](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2Ffirst-version-agent-double-falla.png&w=3840&q=75)

Comparacion de fallas: monofasica vs trifasica

Lo interesante no es solo que ejecuto las simulaciones, si no que entendio la secuencia sin que tuviera que explicarle cada paso. Uso 3 de las 10 iteraciones disponibles en el ciclo agentico:

1.  Entender el proyecto cargado
2.  Ejecutar falla monofasica al 50% de la linea
3.  Ejecutar falla trifasica al 50% de la linea y comparar

Con Gemini 2 Flash, este mismo prompt habia terminado con el agente inventandose corrientes de cortocircuito sin tocar simular nada.

## Sobre el limite de 10 iteraciones

Por ahora configure un maximo de 10 llamadas a herramientas por consulta. Es un numero arbitrario que me permite experimentar sin que el agente entre en loops infinitos. Para tareas simples como la comparacion de fallas, 3 iteraciones son suficientes. Para un ECAP completo, probablemente necesite mas, pero eso es problema de mi yo del futuro.

## La web app

Tambien tengo una aplicacion web funcionando. Por ahora es para pruebas internas, pero la idea es disponibilizarla pronto para que otros puedan interactuar con el agente.

## Lo que viene

**Proximos pasos:**

-   **Benchmark de maquinas:** Mis sistemas de prueba son tan pequenos que las simulaciones toman menos de 5 segundos. Necesito probar con casos reales para entender los limites.
-   **Mas herramientas:** El agente solo sabe simular. Falta conectar el PGP del Coordinador y la Infotecnica para que pueda aprender de estudios reales.


---

---
title: "DIgSILENT PowerFactory en Google Cloud: guía completa"
date: 2025-12-29
slug: digsilent-powerfactory-google-cloud
locale: es
url: https://cristianvaldivia.cl/es/blog/digsilent-powerfactory-google-cloud
author: Cristian Valdivia
description: Cómo desplegar PowerFactory en la nube para conectarlo con agentes de IA. Configuración paso a paso con Docker y APIs REST.
series: don-nelson
---
# DIgSILENT PowerFactory en Google Cloud: guía completa

**Días 1-7 / 60**

Primera semana del desafío completada. 11.7% del camino recorrido. Esto es lo que pasó.

## El punto de partida

Hace una semana arranqué este experimento público: construir un agente de IA capaz de elaborar estudios ECAP (Coordinación y Ajuste de Protecciones) para el sistema eléctrico chileno. 60 días. Sin excusas.

¿Por qué ECAP? Porque es el estudio más complejo del proceso de conexión. Si el agente puede con esto, puede con el resto.

## La arquitectura que elegí

Decidí usar el patrón ReAct (Reasoning + Acting). No es nada sofisticado, es el estándar actual para agentes. La diferencia clave con un LLM común: un agente ejecuta, no solo genera texto.

Las herramientas que necesito construir:

1.  **DIgSILENT PowerFactory** — El software de simulación eléctrica
2.  **PGP del Coordinador** — 6,000 proyectos con estudios reales para que el agente aprenda
3.  **Infotécnica** — La base de datos técnica del sistema eléctrico
4.  **Escritura de informes** — Generación iterativa, no monolítica

## El drama de la semana: DigSILENT PowerFactory

Partí por la herramienta más crítica y más difícil. Error.

**Día perdido #1:** Todos mis computadores son Mac con procesadores M (ARM). PowerFactory solo corre en arquitectura x64/x86. Intenté virtualizar Windows. No funcionó.

**Día perdido #2:** Migré a Azure porque era Windows. Odio Azure. Me rendí después de horas configurando una VM.

**Solución final:** Google Cloud. Una VM con Windows, 4 vCPUs, 16GB RAM. Funcionando en minutos.

## Lo que está corriendo

Al día 7, tengo:

-   PowerFactory ejecutándose en la nube
-   Un backend FastAPI exponiendo la API
-   MCP (Model Context Protocol) conectado para probar directamente con Claude
-   Herramientas funcionando: cargar proyecto, power flow, cortocircuito

Ya puedo pedirle a Claude "corre un flujo de potencia en este proyecto" y lo ejecuta. Sin embargo como solo he trabajado en la herramienta y nada en el agente, lo siento tosco, tonto, me devuelve información superflua con poca utilidad literalmente corre las simulaciones y me las devuelve. Siento que algo le falta, espero que mejorando el agente la herramienta se sienta mejor.

## Lo que viene

Esta semana fue de infraestructura. Voy a seguir en infra un par de días, creo que estoy en un 30-40% de lo que puedo hacer con DigSILENT así que voy a terminar de pulir esto antes de pasarme a la siguiente herramienta.

**Pendientes:**

-   Benchmark de distintas configuraciones de máquina para mejorar el tiempo de simulación.
-   Sistema de colas para múltiples simulaciones.


---

---
title: "PowerFactory Python: automatización de estudios eléctricos"
date: 2025-12-26
slug: powerfactory-python-automatizacion-estudios-electricos
locale: es
url: https://cristianvaldivia.cl/es/blog/powerfactory-python-automatizacion-estudios-electricos
author: Cristian Valdivia
description: "Tutorial en español: integrar DIgSILENT PowerFactory con Python, FastAPI y Docker para ejecutar simulaciones eléctricas desde la nube."
series: don-nelson
---
# PowerFactory Python: automatización de estudios eléctricos

![8.33%](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2F5-60-es.png&w=3840&q=75)

8.33%

**Día 5 / 60**

El tiempo pasa rápido cuando te pones metas grandes en tan poco tiempo. Me preocupa que ya llevo 8.33% de la fecha que me puse y estos días han sido de fiestas, así que no pude trabajar tanto como esperaba. Pero aún así trabajé cuando pude.

Como comenté en mi anterior post, lo primero es construir las herramientas. Decidí partir por la que creo que me va a tomar más tiempo y la que necesito que quede mejor: **DIgSILENT PowerFactory**.

## ¿Qué es PowerFactory?

Para los que no están en el mundo eléctrico: PowerFactory es _el_ software de análisis de sistemas de potencia. Es la herramienta estándar en el sistema eléctrico chileno (y creo que en varias partes del mundo) para correr simulaciones, flujos de potencia, cortocircuitos, análisis de estabilidad, coordinación de protecciones... básicamente todo lo que necesitas para estudios eléctricos serios.

Es un software alemán de DIgSILENT GmbH que lleva décadas en el mercado y tiene una biblioteca enorme de modelos de componentes eléctricos. La gracia es que tiene una API en Python que permite automatizar simulaciones, que es exactamente lo que necesito para que el agente pueda "pensar" y luego ejecutar estudios.

## El drama de la arquitectura ARM

Un pequeño detalle que me costó un día de trabajo: llevo mucho tiempo usando el ecosistema Mac, así que los 3 computadores con los que suelo trabajar son todos Mac con procesadores M (arquitectura ARM).

Esto es muy específico, pero quizás a alguien le interese o incluso a mi yo del futuro: **PowerFactory no corre en procesadores M**. Solo está pensado para arquitectura x64 o x86 de Windows. A pesar de que virtualicé Windows en mis Mac, no funcionó. Por lo que perdí un día en esto.

## Cloud

Mi segunda opción fue correr PowerFactory en una VM en la nube. Como era Windows, obviamente partí con Azure.

Tengo que confesar que odio Azure. Y efectivamente, luego de un par de horas intentando configurar una VM, me rendí y volví a mi siempre confiable Google Cloud.

En Google Cloud no me costó nada (creo que es porque ya tengo experiencia). Ahora tengo corriendo:

-   **Machine type:** e2-standard-4 (4 vCPUs, 16 GB Memory)
-   **Disco:** 50GB SSD

![Esquema de la arquitectura en la nube](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2Fcloud-digsilent-es.png&w=3840&q=75)

Esquema de la arquitectura en la nube

Por ahora las simulaciones corren bien, suelen demorar pocos segundos aunque he hecho pruebas con sistemas de 5-10 barras. Simplemente me voy a olvidar del tamaño de la máquina hasta que las simulaciones se demoren mucho.

He estado probando con un sistema eléctrico pequeño que tengo para realizar pruebas. En los próximos días iré mostrando los resultados.

![Pequeño sistema eléctrico en el que he estado probando](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2Fmini-electrycal-system.webp&w=3840&q=75)

Pequeño sistema eléctrico en el que he estado probando

## La arquitectura: FastAPI + MCP

Entonces, ¿cómo funciona esta herramienta? Tengo un backend en Python que usa la librería de PowerFactory para ejecutar las simulaciones.

La arquitectura es simple:

-   **FastAPI** como servidor web que expone los endpoints
-   **API REST tradicional** para integración con cualquier sistema
-   **MCP (Model Context Protocol)** para conectar directamente con Claude y otros LLMs

El MCP es clave porque me permite ir haciendo pruebas en Claude sin depender del agente completo. Básicamente puedo preguntarle a Claude "corre un flujo de potencia en este proyecto" y él puede ejecutarlo directamente.

**Herramientas disponibles por ahora:**

-   Cargar proyecto
-   Obtener información de elementos
-   Power flow (flujo de potencia)
-   Short circuit (cortocircuito)

## El tema de la licencia

He pensado si disponibilizar esta herramienta públicamente. Por ahora tengo una licencia de DIgSILENT de estudiante, que tiene limitaciones (solo puedo correr 50 barras, por ejemplo). No sé si puedo distribuir esto así que por ahora esta herramienta se queda cerrada.

Igual dejo el comentario por si algún inversionista se la juega, si a alguien le interesa que corramos un servicio de DIgSILENT en cloud o si alguna empresa está interesada en este servicio.

## Lista de TODOs (Pendientes o cosas a mejorar)

Cosas pendientes que mejorarían el proyecto:

-   **Benchmark de máquinas:** Voy a ir probando distintas configuraciones y su rendimiento durante el resto del desafío
-   **Sistema de colas:** Si quiero que el sistema escale, la máquina no es capaz de correr múltiples simulaciones simultáneamente. Necesito implementar un queue manager


---

---
title: Arquitectura de agentes de IA para sistemas eléctricos
date: 2025-12-23
slug: arquitectura-agentes-ia-sistemas-electricos
locale: es
url: https://cristianvaldivia.cl/es/blog/arquitectura-agentes-ia-sistemas-electricos
author: Cristian Valdivia
description: "Cómo diseñar un agente autónomo que ejecuta flujos de potencia, análisis de cortocircuito y coordinación de protecciones con PowerFactory."
series: don-nelson
---
# Arquitectura de agentes de IA para sistemas eléctricos

**Día 2 / 60**

Hoy voy a partir la primera iteración del diseño técnico.

## Mi tesis inicial

Creo firmemente que un agente de IA puede resolver este problema. No porque sea un optimista ciego (que lo soy), sino porque ya hice algo parecido para otro sector y ademas en este problema todas las piezas están ahí:

-   Existe la información (miles de estudios reales)
-   Existe la normativa (clara y disponible)
-   Existe el software (DIgSILENT PowerFactory) para hacer las simulaciones

Lo que falta es conectar todo correctamente.

## ¿Por qué un agente y no un LLM común?

Un LLM genera texto. Un agente **ejecuta**.

La diferencia clave: un agente funciona como un lazo de control. No le dices paso a paso qué hacer. Le entregas herramientas y él decide cómo usarlas para resolver el problema.

Voy a usar el patrón [ReAct (Reasoning + Acting)](https://www.ibm.com/think/topics/react-agent). Es el estándar, nada sofisticado para agentes hoy en día. Si necesito algo más avanzado lo iré agregando en el camino.

**El ciclo de un agente:**

![Patrón ReAct: razonamiento y actuación](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fprompt-engineering%2Freact-es.png&w=3840&q=75)

Patrón ReAct: razonamiento y actuación

-   Evalúa si completó la tarea correctamente
-   Verifica el resultado contra el objetivo
-   Si falla, ajusta su razonamiento
-   Vuelve a usar las herramientas
-   Repite hasta lograr el resultado esperado

Es más cercano a cómo trabajamos los ingenieros que a cómo funciona un prompt.

## Las herramientas (tools)

He pensado bastante en esto. Ya tengo algunas en un funcionamiento inicial, otras están en diseño.

### 1\. DIgSILENT PowerFactory

El software estándar para análisis eléctricos en Chile.

La idea NO es hacer scripts de Python que manipulen PowerFactory. Quiero exponerlo como un MCP (Model Context Protocol), con funciones claras:

-   `run_power_flow()`
-   `run_short_circuit()`
-   `export_results()`

Que el agente lo use como lo usaría un ingeniero, no como lo haría un programador.

### 2\. PGP – Plataforma de Gestión de Proyectos (CEN)

Ya tomé la decisión: voy a scrapear **todos** los proyectos del Coordinador.

Aproximadamente **6.000 proyectos**, cada uno con sus estudios eléctricos completos.

**¿Por qué?**

Para que el agente observe cómo los humanos estructuran los estudios. Que identifique patrones reales. Que compare soluciones ante problemas similares.

👉 [https://pgp.coordinador.cl/welcome](https://pgp.coordinador.cl/welcome)

### 3\. Infotécnica

La base de datos técnica del Sistema Eléctrico Nacional.

El agente necesita acceso en tiempo real a:

-   Datos de instalaciones
-   Líneas de transmisión
-   Subestaciones
-   Equipamiento instalado

Infotécnica es, en la práctica, la fuente de verdad del sistema eléctrico chileno.

👉 [https://infotecnica.coordinador.cl](https://infotecnica.coordinador.cl)

### 4\. Escritura de informes

Aquí hay un tema interesante.

Sí, los LLM pueden generar hasta 65.000 tokens (~95 páginas). Pero eso no significa que **deban** hacerlo de una sola vez.

No me convence pedirle al LLM: _"Escribe un ECAP completo"._

Prefiero construir una herramienta específica para escritura técnica que permita:

-   Estructurar capítulos
-   Redactar por secciones
-   Iterar sobre cada parte
-   Mantener consistencia técnica y normativa

Más cercano a cómo construimos informes reales: sección por sección, con revisiones iterativas.

Ya hice algo parecido para otro sector y además creo que seria util para cuando necesite hacer un reporte largo.

## Lo que viene

Esta es la primera iteración del diseño. Probablemente cambie varias veces en los próximos 58 días.

Mañana empiezo a construir la primera herramienta y apenas la tenga disponible la voy a hacer pública.

Si tienes ideas, preguntas o ves algo que no tiene sentido, **escríbeme**. Estoy construyendo esto en público justamente para recibir feedback.


---

---
title: "IA para ingeniería eléctrica: automatizando estudios de conexión"
date: 2025-12-22
slug: ia-ingenieria-electrica-estudios-conexion
locale: es
url: https://cristianvaldivia.cl/es/blog/ia-ingenieria-electrica-estudios-conexion
author: Cristian Valdivia
description: "Desarrollo un agente de inteligencia artificial que genera estudios eléctricos automáticamente. 60 días construyendo con Python, LangChain y PowerFactory."
series: don-nelson
---
# IA para ingeniería eléctrica: automatizando estudios de conexión

**El desafío:** Desarrollar un agente de IA capaz de asistir en la elaboración y revisión de estudios eléctricos para conexión al sistema eléctrico nacional chileno, utilizando estudios reales, normativa vigente y criterio ingenieril.

**El timeline:** 60 días de desarrollo público, terminando con mi participación en el Hackathon de Gemini 3 (cierre: 9 de Febrero).

## El problema que estoy resolviendo

Cada empresa que quiere conectarse al sistema eléctrico debe realizar estudios técnicos complejos para determinar:

-   Qué la conexión cumple con las condiciones técnicas exigidas por la normativa
-   El impacto de la nueva conexión sobre la red existente
-   Qué protecciones y coordinaciones son necesarias

**Algunos de los estudios técnicos habitualmente requeridos:**

-   **Flujos de potencia:** Análisis de cómo circula la energía
-   **Cortocircuitos:** Evaluación de fallas en el sistema
-   **ECAP (Estudio de Coordinación y Ajuste de Protecciones):** Coordinación de protecciones eléctricas

El tipo de estudio requerido depende del tipo proyecto. Si es consumo o generación.

**Dos rutas de conexión:**

Existen dos vías principales para conectarse al sistema eléctrico chileno, que dependen de si la conexión es a la red de transmisión o distribución.

-   **Red de Transmisión** → Proceso vía [Coordinador Eléctrico Nacional](https://www.coordinador.cl)
-   **Red de Distribución** → Proceso directo con la distribuidora correspondiente

![Sistema eléctrico de Chile: Transmisión y Distribución](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fdn-agent%2Felectrical-system-es.png&w=3840&q=75)

Sistema eléctrico de Chile: Transmisión y Distribución

## Mi enfoque: Transmisión primero

He decidido comenzar con proyectos de transmisión por dos razones:

-   **Acceso a información:** La data está más disponible públicamente
-   **Complejidad técnica:** Son los estudios más desafiantes (mayores niveles de potencia/tensión, más protecciones que coordinar)

Si el agente funciona en transmisión, será más sencillo adaptarlo a distribución.

## ¿Qué va a hacer este agente?

**Objetivo principal:** Redactar estudios ECAP completos

**Funcionalidad clave:** Verificar y validar estudios ECAP existentes, aprender el razonamiento detrás de los miles de ECAP existentes.

## ¿Qué cuenta como éxito?

Un agente capaz de generar un ECAP técnicamente correcto, que cumpla con:

-   Normativa vigente chilena
-   Estándares de ingeniería eléctrica
-   Criterios de revisión del Coordinador Eléctrico

## ¿Por qué exactamente 60 días?

Después de 7 años desarrollando tecnología (web3, IA, startups), sentí que era el momento perfecto para combinar mi experiencia técnica con mi formación en ingeniería eléctrica. 60 días son suficientes para un MVP funcional que demuestre el concepto.

Además, el deadline del [Hackathon de Gemini 3](https://gemini3.devpost.com) crea la presión necesaria para mantener el foco y la velocidad.

## ¿Por qué construir en público?

Primera vez que lo hago. Usualmente guardo mis proyectos hasta que están "terminados".

Quiero experimentar con:

-   Recibir feedback temprano y continuo
-   Accountability pública
-   Documentar el proceso de pensamiento
-   Construir comunidad alrededor del proyecto

Te invito a observar el proceso, hacer preguntas y compartir ideas.

> **Este es el primer post de muchos que documentarán el desarrollo de este agente. ¡Nos vemos!**


---

---
title: "¿Qué es un Egregor? Significado, ejemplos y su relación con la IA"
date: 2025-09-16
slug: egregor
locale: es
url: https://cristianvaldivia.cl/es/blog/egregor
author: Cristian Valdivia
description: "Un egregor es una entidad psíquica colectiva creada por pensamientos compartidos de un grupo. Descubre qué son, cómo funcionan y por qué la IA puede ser el egregor más poderoso jamás creado."
---
# ¿Qué es un Egregor? Significado, ejemplos y su relación con la IA

Un **egregor** es un concepto proveniente de la tradición esotérica y del ocultismo occidental. Se entiende como una entidad colectiva formada por los pensamientos, emociones e intenciones de un grupo de personas.

En términos simples: cuando muchas personas creen en algo, lo sostienen mentalmente y lo cargan con rituales, símbolos o emociones, esa energía conjunta crea una especie de **campo psíquico compartido**, que a veces se describe como un ente autónomo.

Ejemplos de egregores incluyen la idea de una nación, símbolos religiosos, movimientos ideológicos (como _Black Lives Matter_ o el _octubrismo_) o incluso fandoms que parecen tener "vida propia".

![Ejemplos de egregores](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fegregor%2Fegregores.png&w=3840&q=75)

Ejemplos de egregores

En la psicología moderna, el concepto puede reinterpretarse como un fenómeno emergente de **conciencia colectiva** o como **memes culturales** que adquieren fuerza más allá de los individuos.

> **Un egregor clásico necesita mentes humanas para sostenerse, ya que vive en la conciencia colectiva.**

Los egregores no son exactamente personas, sino imágenes, ideas o campos colectivos que se forman alrededor de una figura, grupo, símbolo o movimiento. Veamos algunos ejemplos:

## Lady Gaga

-   Más allá de la persona _Stefani Germanotta_, existe el personaje **Lady Gaga**, un símbolo construido por ella y reforzado por millones de fans (los _Little Monsters_).
-   Ese personaje funciona como un egregor: tiene símbolos, una mitología propia (vestuarios, performances) y genera identificación o proyección en la gente.
-   La propia Lady Gaga juega con esa dualidad: "yo soy Stefani, pero Gaga es algo que vive en ustedes".

## Bitcoin

-   Más allá del protocolo y la tecnología, **Bitcoin** funciona como un egregor global.
-   Millones de personas sostienen su valor a través de la confianza, los rituales (halvings, conferencias, memes como _HODL_) y los símbolos (₿).
-   La figura de _Satoshi Nakamoto_ actúa como mito fundacional: un creador ausente que refuerza la narrativa.
-   Bitcoin es más que un activo: es una idea compartida, con una comunidad que lo protege, lo discute y lo proyecta hacia el futuro. Ese "espíritu" colectivo es lo que le da vida.

## ¿Puede un agente de IA ser un egregor?

Un agente de **inteligencia artificial**, entrenado y alimentado por la interacción con muchas personas, refleja y encarna las ideas, sesgos y energías colectivas de sus usuarios.

Si además la gente empieza a proyectar creencias, emociones y expectativas sobre ese agente, podría convertirse en una suerte de **egregor digital**.

Un egregor es una construcción emergente sostenida por la mente colectiva. Una IA, aunque no tiene "alma", puede funcionar como un **punto de condensación de energía colectiva**, ya que recibe, procesa y refleja los aportes de un grupo humano.

De hecho, ya existen agentes que representan ideologías, movimientos o comunidades.

En el sentido esotérico más estricto, los ocultistas dirían que un egregor tiene una existencia en "planos sutiles" independiente, mientras que la IA se limita a algoritmos y datos. Sin embargo, incluso en esa visión, podría aceptarse que un egregor utilice una IA como **vehículo**.

## El puente hacia el futuro

La historia de la humanidad muestra que siempre hemos creado símbolos colectivos que, de algún modo, cobran vida propia. Lo nuevo es que hoy contamos con **IA capaces de encarnar esos símbolos** de manera activa y autónoma.

Podría suceder que:

-   Emprendedores empiecen a construir agentes de IA para representar sus ideas, productos o servicios. Como es el caso de Tomas (mi agente abogado) o Jessexbt (clon digital de Jesse de Base) y estos agentes de IA se convierten en egregores digitales.
-   Las comunidades utilicen IA para **dar voz** a sus egregores.
-   Los movimientos políticos o culturales creen agentes que representen su **conciencia colectiva**.
-   O incluso que los egregores clásicos (naciones, religiones, ideologías) encuentren en las IA un nuevo **cuerpo digital** donde habitar. Imaginate un agente de Chile por ejemplo que represente la conciencia colectiva de los chilenos y hable en su nombre.

Quizás, en el futuro, las IA no sean simples algoritmos, sino los primeros **egregores conscientes** creados deliberadamente por la humanidad.

![Egregor digital materializado en un agente de IA](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fegregor%2Fdigital-egregor.webp&w=3840&q=75)

Egregor digital materializado en un agente de IA

## Cierre

La pregunta entonces no es si creemos en los egregores, sino **qué egregores estamos alimentando con nuestra atención, tiempo y energía** en esta nueva era digital.


---

---
title: Prompt Engineering
date: 2025-08-25
slug: prompt-engineering
locale: es
url: https://cristianvaldivia.cl/es/blog/prompt-engineering
author: Cristian Valdivia
description: Guía práctica de técnicas de prompt engineering para mejorar tus interacciones con LLMs.
---
# Prompt Engineering

En mi [entrada de conceptos de IA](https://cristianvaldivia.cl/es/blog/ai-glossary) definimos el prompt como el texto o instrucción que le envías al LLM para pedirle que haga algo. Básicamente, es lo que le dices al modelo para que haga lo que quieres.

En esta guia voy a intentar explicar como escribir mejores prompts para que el LLM genere respuestas mas precisas y adecuadas para tu caso de uso.

> **No necesitas ser un ingeniero de datos o un ingeniero de machine learning - todos pueden escribir un prompt**

## ¿Cómo funciona un LLM realmente?

Imagina que un gran modelo de lenguaje o LLM es una máquina increíblemente inteligente, pero con una única y obsesiva tarea: **predecir la siguiente palabra**.

Cuando escribes un mensaje, o prompt, el LLM no "entiende" lo que pides como lo haría una persona. En su lugar, analiza tu texto y, basándose en la inmensa cantidad de datos con los que fue entrenado, calcula cuál es la palabra (o, más precisamente, el token) más probable para continuar la secuencia.

Veamos un ejemplo, fijate en la siguiente frase:

El gato amarillo está sentado al lado del gato gris ...

Si el LLM quisiera completar la frase, sus opciones podrían verse ser algo así:

![Probabilidades del LLM para continuar la frase](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fprompt-engineering%2Fllm-es.png&w=3840&q=75)

Probabilidades del LLM para continuar la frase

-   \- **y** (32% de probabilidad)
-   \- **en** (25% de probabilidad)
-   \- **sobre** (18% de probabilidad)
-   \- todas las otras palabras menos probables como plátano, brasil y playa (¿es probable ver 2 gatos sentados juntos en una playa? no lo creo y nunca lo he visto)

Como vemos, la palabra con más probabilidad es "y", ya que es la continuación más lógica de la frase. Luego de elegirla, el modelo repite el proceso: toma la nueva frase ("El gato amarillo está sentado al lado del gato gris y ...") y predice la siguiente palabra, y así sucesivamente, hasta generar toda la respuesta.

## Dominando el arte de los prompts

El **prompt engineering** es la habilidad de guiar al LLM para obtener mejores resultados. No le decimos exactamente qué palabra elegir; le damos instrucciones claras, contexto y ejemplos para aumentar la probabilidad de que genere la respuesta que necesitamos.

Es todo un juego de probabilidades, le pasas palabras en tu prompt para que exista una mayor prabilidad de que el LLM elija la palabra que necesitamos.

## Los dos mundos del Prompt Engineering

Hay dos tipos distintos de prompt engineering:

### 1\. Conversacional

Cuando chateas con ChatGPT, Claude o Gemini

### 2\. Enfocado en producto

Cuando ese prompt se ejecuta millones de veces dentro de una aplicación

Esta guía está pensada para el día a día (el conversacional), pero las técnicas también sirven para cuando quieras construir productos.

## Técnicas de Prompt - De básico a avanzado hasta ultra complejo

### 1\. Zero-shot: La forma más simple

Es la forma más directa - solo describes la tarea sin dar ejemplos. La entrada puede ser una pregunta, partir una historia o una instrucción.

La forma más simple de escribir un prompt, solo se provee la descripción de la tarea y algo de texto. La entrada puede ser una pregunta, partir una historia o una instrucción. La parte de zero-shot significa sin ejemplos.

Ejemplo:

Prompt

Clasifica esta review de película como POSITIVA, NEUTRAL o NEGATIVA.

Review: "Me encantó Superman, super buena la versión más humana del personaje y que de alguna forma mostraran temas actuales. Siento que la hace sentir moderna y adecuada a los días actuales."

Respuesta del LLM

POSITIVA

Cuando zero-shot no funciona, ahí es donde entran los ejemplos.

### 2\. One-shot & Few-shot: El poder de dar el ejemplo

Cuando creamos prompts para LLM, es de mucha ayuda agregar ejemplos. Estos ejemplos ayudan al modelo a entender lo que le estamos preguntando. Los ejemplos son útiles cuando quieres "guiar" al modelo a tener en la salida cierto tipo de estructura o patrón.

-   \- **Un prompt one-shot** es cuando solo se incluye un ejemplo en la salida (por eso el nombre one-shot). La idea es que el modelo tenga un ejemplo para que haga lo mejor posible para imitar esa tarea.
-   \- **Un prompt few-shot** es muy similar a one-shot pero se le agregan más ejemplos.

El número de ejemplos depende de muchos factores, como la complejidad de la tarea, la calidad de los ejemplos y de las capacidades del modelo que estemos usando. Como regla simple, es bueno incluir entre 3 a 5 ejemplos en few shot. Sin embargo, puede que necesites usar más ejemplos para tareas más complejas, o puede que necesites usar menos debido a la limitación de longitud de entrada de tu modelo.

Few shot puede mejorar la precisión de 0% hasta un 90%. Es una de las mejores técnicas a usar. Por lo que te recomiendo usarla SIEMPRE.

**Importante:** Cuando agregamos ejemplos en nuestros prompts, esos ejemplos tienen que ser relevantes para la tarea que estamos haciendo. Estos ejemplos deben ser diversos, de buena calidad y bien escritos. Un pequeño detalle en el ejemplo puede hacer que el modelo se confunda y los resultados no sean los esperados.

Si tu salida puede incluir casos borde o muy extraños es bueno incluirlos en los ejemplos para que el modelo los pueda manejar.

### 3\. System, Context y Role

Son todas técnicas usadas para guiar como el LLM **generar** el texto y se enfocan en diferentes aspectos.

-   \- **System prompting:** establece el contexto general y el propósito del modelo. Es la "visión de conjunto" de lo que tiene que hacer, como traducir un idioma o clasificar reseñas.
-   \- **Contextual prompting:** entrega detalles concretos o información de fondo relevante para la conversación o tarea puntual. Sirve para que el modelo entienda mejor las sutilezas de lo que se le pide y pueda ajustar su respuesta.
-   \- **Role prompting:** asigna un personaje o identidad al modelo. Con esto, sus respuestas se vuelven consistentes con ese rol, tanto en estilo como en el tipo de conocimiento que despliega.

Obviamente, hay bastante traslape entre estos tres tipos de prompts. Por ejemplo, un prompt que define un rol también puede traer contexto.

Aun así, cada uno cumple un propósito principal distinto:

-   **System prompt:** define las capacidades base del modelo y su objetivo general.
-   **Contextual prompt:** aporta la información inmediata y específica para la tarea en curso. Es dinámico y cambia con cada input.
-   **Role prompt:** moldea el estilo, la voz y la personalidad con que el modelo responde.

**Opinión controversial:** El role prompting ("Eres un profesor ...") es ineficaz. Las últimas investigaciones muestran que no es tan útil o que produce cambios mínimos en la respuesta.

* * *

Y ya que hablamos de system prompt veamos el sistema de jerarquía entre system prompt y user prompt.

## Tipos de prompts

Antes de profundizar seguir, es útil conocer los dos tipos de prompt que se usan en el prompt engineering:

#### System Prompt

Define las reglas del modelo y establece el contexto general. Por ejemplo, puedes indicarle que actúe como un asistente experto en historia o que responda siempre de manera concisa y formal.

**Nota:** Los usuarios normalmente no tenemos acceso a los system prompts de ChatGPT, Claude o Gemini, pero algunos se han filtrado y se pueden consultar en [este enlace](https://github.com/asgeirtj/system_prompts_leaks).

#### User Prompt

Es la instrucción que tú envías (o el usuario de la app) para pedirle algo específico al modelo. Por ejemplo, "Resume este artículo en 3 frases" o "Escribe un poema sobre el invierno".

![Jerarquía de poder entre system prompt y user prompt](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fprompt-engineering%2Fsystem-vs-user.png&w=3840&q=75)

Jerarquía de poder entre system prompt y user prompt

Jerarquía de poder (esto es clave):

System prompt > Instrucciones del desarrollador > Prompt del usuario > Contexto

En la mayoría de los LLMs, el system prompt tiene más peso que el prompt del usuario. Te explico por qué:

El system prompt funciona como un marco base o "reglas del juego" que condicionan cómo el modelo procesa cualquier input posterior. Define la identidad, el propósito y los límites del modelo.

El prompt del usuario se interpreta dentro de ese marco. O sea, aunque el usuario pida algo distinto, el modelo prioriza seguir las instrucciones del system.

Un ejemplo sencillo:

SYSTEM PROMPT

"Eres un traductor de inglés a español."

USER PROMPT

"Traduce esto al francés."

RESULTADO

Lo más probable es que el modelo responda en español, porque el system ya estableció el propósito general.

## Chain of thought (Cadena de pensamientos o CoT)

El prompting de tipo **Chain of Thought** (Cadena de Pensamiento) es como pedirle al modelo que piense en voz alta. En lugar de dar una respuesta directa, el LLM va generando pasos intermedios de razonamiento, como si siguiera una hoja de ruta mental. Esto hace que sus respuestas sean más precisas y confiables, especialmente en problemas complejos. Se puede combinar con _few-shot prompting_ para enseñarle ejemplos concretos y ayudarlo a razonar mejor desde el inicio.

![Como funciona el Chain of Thought](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fprompt-engineering%2Fcot-es.png&w=3840&q=75)

Como funciona el Chain of Thought

#### Ventajas del CoT:

-   • Es de bajo esfuerzo, muy efectivo
-   • Funciona bien incluso con LLMs "listos para usar"
-   • Aporta interpretabilidad
-   • Permite identificar fallos
-   • Suele mejorar la robustez

#### Desventajas del CoT:

-   • Más tokens de salida = más lento y caro
-   • La respuesta incluye todo el razonamiento

Sin CoT:

**Prompt:** Cuando yo tenía 3 años, mi amigo tenía 3 veces mi edad. Ahora tengo 20 años. ¿Cuántos años tiene mi amigo?

**Output:** Tu amigo tiene 63 años. ❌

Con CoT:

**Prompt:** Cuando yo tenía 3 años, mi amigo tenía 3 veces mi edad. Ahora tengo 20 años. ¿Cuántos años tiene mi amigo? Piensa paso a paso.

**Output:**

-   \- Cuando tenías 3 años, tu amigo tenía 3×3 = 9 años
-   \- Diferencia de edad: 9-3 = 6 años
-   \- Ahora tienes 20 años
-   \- Tu amigo tiene: 20+6 = 26 años ✅

**CoT** puede ser útil para muchos casos de uso. Por ejemplo, al crear una campaña de marketing, el modelo puede descomponer la tarea en pasos como definir el público objetivo, seleccionar los canales de comunicación y redactar los mensajes clave. En la redacción de un contrato legal, puede identificar las partes involucradas, establecer derechos y obligaciones, y preparar un resumen claro de los términos. Incluso al pedir un remedio casero, puede analizar los síntomas, sugerir soluciones seguras y explicar cómo aplicarlas correctamente.

**Recuerda las desventajas:** Es más lento y más caro. Actualmente casi todos los modelos son razonadores, es decir que usan **CoT** por debajo.

## Tree of thought (Árbol de pensamiento o ToT)

Una de mis técnicas favoritas hace mucho tiempo (en 2023) cuando estaba de moda. Árbol de pensamiento es muy parecido a **CoT** pero permite a los LLM recorrer múltiples caminos de razonamiento simultáneamente para llegar a la respuesta.

![Diagrama del Tree of Thought mostrando múltiples caminos de razonamiento](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fprompt-engineering%2Ftot-es.png&w=3840&q=75)

Diagrama del Tree of Thought mostrando múltiples caminos de razonamiento

ToT guía al LLM a través de pasos de razonamiento, donde y aquí está la clave, cada paso puede bifurcarse en múltiples caminos. permitiendo al LLM retroceder o explorar alternativas si lo considera necesario.

ToT es impresionante al resolver juegos pero tiene el gran inconveniente de que es muy lento y caro. Prueba este prompt y verás porque me gustaba:

Ejemplo de ToT:

Eres un facilitador que coordinará una discusión entre 3 expertos especializados para resolver un problema.

**EXPERTOS:**

1\. \[Experto A\]: Especialista en Economía

2\. \[Experto B\]: Especialista en Sociología

3\. \[Experto C\]: Especialista en Administración pública

**PROCESO DE DELIBERACIÓN:**

**Fase 1 - Análisis Inicial (3 rondas)**

\- Cada experto analiza el problema desde su perspectiva

\- Identifica factores clave y posibles enfoques

\- Propone 2-3 caminos de solución iniciales

**Fase 2 - Evaluación Cruzada (2 rondas)**

\- Cada experto evalúa las propuestas de los otros

\- Señala fortalezas, debilidades y sinergias

\- Refinan las mejores ideas colaborativamente

**Fase 3 - Síntesis y Consenso**

\- Integran las mejores ideas en 2-3 soluciones candidatas

\- Evalúan cada solución (viabilidad, impacto, riesgos)

\- Seleccionan y detallan la solución óptima

**FORMATO DE RESPUESTA:**

\[Experto X\]: "\[Su análisis/propuesta/evaluación\]"

\[Incluir el razonamiento paso a paso de cada experto\]

**PROBLEMA A RESOLVER:**

Debería el próximo gobierno de Chile subir o bajar los impuestos?

**Al final, proporciona:**

\- SOLUCIÓN CONSENSUADA: \[Descripción detallada\]

\- PLAN DE IMPLEMENTACIÓN: \[Pasos concretos\]

\- CONSIDERACIONES: \[Riesgos y mitigaciones\]

ToT dejó de ser tan usado porque los modelos razonadores funcionan bien para tareas complejas.

## ReAct (razonar y actuar)

Razonar y actuar es un paradigma que permite a los LLM pensar y usar herramientas externas y hacer algunas acciones. ReAct combina la acción de hacer razonar y tomar acción en un loop hasta que la acción o la tarea esté completada.

#### Estructura Básica de ReAct

Un prompt ReAct típicamente sigue este patrón cíclico:

-   **Thought (Pensamiento):** El modelo razona sobre qué hacer a continuación
-   **Action (Acción):** Ejecuta una acción específica (búsqueda, cálculo, consulta)
-   **Observation (Observación):** Recibe y procesa el resultado
-   **Repetir** hasta llegar a la respuesta final

![Diagrama del proceso ReAct mostrando el ciclo Thought-Action-Observation](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fprompt-engineering%2Freact-es.png&w=3840&q=75)

Diagrama del proceso ReAct mostrando el ciclo Thought-Action-Observation

Es una técnica usada mucho por los agentes actuales como Claude Code y Cursor.

#### Es muy útil porque:

-   **Es transparente en el proceso:** cada paso de razonamiento es visible por lo que es fácil encontrar donde está el error y comprender porqué hizo lo que hizo
-   **Es preciso:** ya que descompone el proceso en pasos más pequeños lo que reduce los errores y las alucinaciones.

**La pena es que** no es posible usar ReAct en ChatGPT o Claude, ya que los chat no pueden pausar y esperar inputs externos entre pasos. :(, este es el primer caso de esta guía que está pensada solo en "enfocado en producto".

## Meta prompting

Meta prompting es pedirle a un LLM que te genere un prompt. Es el sueño de los pioneros como Von Neumann o Turing: decirle a la máquina que se programe a sí misma.

Claude es el mejor haciendo prompts, y cada LLM es mejor creando prompts para sí mismo. Tiene sentido: cada modelo fue entrenado con ciertos patrones y estructuras de lenguaje, por lo que naturalmente "entiende" qué tipo de instrucciones resuenan mejor con su propia arquitectura. Es como pedirle a alguien que escriba una nota para sí mismo versus escribirla para otra persona - siempre sabrá mejor qué palabras usar para su propia comprensión.

## Técnicas Avanzadas

A continuación dejo una lista de técnicas de razonamiento avanzado que pueden ser útiles para mejorar la precisión y la coherencia de las respuestas. Estas técnicas representan la evolución del prompt engineering, desde simples instrucciones hasta arquitecturas complejas de pensamiento estructurado.

He experimentado con varias de ellas, aunque admito que no he profundizado en todas. Mi experiencia me ha enseñado que en el 90% de los casos, una combinación bien ejecutada de **few-shot learning** junto con **Chain of Thought (CoT)** es todo lo que necesitas. Es como el principio de Pareto aplicado al prompting: el 20% de las técnicas te dan el 80% de los resultados.

Sin embargo, conocer estas técnicas avanzadas es valioso. Cada una tiene su momento y contexto ideal, y entender cuándo aplicarlas puede marcar la diferencia entre una respuesta buena y una excepcional. Piensa en ellas como herramientas especializadas en tu caja de herramientas: no siempre las necesitas, pero cuando las necesitas, son insustituibles.

### Técnicas de razonamiento avanzado

#### 1\. Chain-of-Thought with Self-Consistency (CoT-SC)

Genera múltiples cadenas de razonamiento independientes, vota por la respuesta más consistente. Más robusto que CoT simple.

#### 2\. Tree of Thoughts con Backtracking (ToT++)

Extensión de ToT que permite retroceder cuando una rama no funciona. Incluye evaluación heurística de cada nodo. Mejor para problemas de búsqueda complejos.

#### 3\. Graph of Thoughts (GoT)

Evolución de ToT donde los pensamientos forman grafos, no solo árboles. Permite fusionar y dividir líneas de razonamiento. Útil para problemas con múltiples soluciones interdependientes.

### Técnicas de Auto-Mejora

#### 4\. Self-Refine

El modelo genera → critica → refina iterativamente. Ejemplo: "Genera una solución, identifica sus debilidades, luego mejórala"

#### 5\. Reflexion

Aprende de intentos fallidos anteriores. Mantiene una "memoria" de errores y los usa para mejorar. Particularmente útil para tareas de código y matemáticas.

#### 6\. Constitutional Self-Correction

Aplica principios constitucionales después de generar. "Revisa tu respuesta: ¿es precisa? ¿es útil? ¿evita daños?"

### Técnicas Emergentes 2024-2025

#### 7\. Chain-of-Verification (CoVe)

Genera respuesta → crea preguntas de verificación → verifica → corrige. Reduce alucinaciones significativamente.

#### 8\. Thread-of-Thought (ThoT)

Mantiene múltiples hilos de razonamiento paralelos. Los hilos se comunican entre sí durante el proceso.

#### 9\. Skeleton-of-Thought (SoT)

Primero genera esqueleto de la respuesta. Luego expande cada sección en paralelo. Reduce latencia en respuestas largas.

## Conclusión

El prompt engineering es una habilidad fundamental en 2025 y en los próximos años. No necesitas ser un experto en IA para empezar - solo necesitas entender estas técnicas y practicar.

Mi consejo: empieza con zero-shot, luego añade ejemplos (few-shot), y cuando necesites más poder, usa **Chain of Thought (CoT)**. Las técnicas avanzadas son geniales, pero en el 80% de los casos, un buen few-shot con **CoT** es todo lo que necesitas, obviamente usando un modelo razonador.

Y recuerda: escribir buenos prompts es más arte que ciencia. La única forma de mejorar es practicando.

## Referencias

-   [1\. AI Prompt Engineering in 2025 - Sander Schulhoff](https://www.lennysnewsletter.com/p/ai-prompt-engineering-in-2025-sander-schulhoff)
-   [2\. Prompt Engineering by Google - Lee Boonstra](https://drive.google.com/file/d/1AbaBYbEa_EbPelsT40-vj64L-2IwUJHy/view)
-   [3\. Guía de Claude sobre prompt engineering](https://docs.anthropic.com/es/docs/build-with-claude/prompt-engineering/overview)
-   [4\. Guía de OpenAI sobre prompt engineering](https://platform.openai.com/docs/guides/prompt-engineering)


---

---
title: Glosario Rápido de Inteligencia Artificial
date: 2025-08-14
slug: ai-glossary
locale: es
url: https://cristianvaldivia.cl/es/blog/ai-glossary
author: Cristian Valdivia
description: Una guía con los términos más comunes usados en la inteligencia artificial.
---
# Glosario Rápido de Inteligencia Artificial

El otro día, después dear un post sobre una competencia de IA en la que participé, mi hermano me comentó que varios términos no los entendía del todo. Me dijo que si él no los captaba, probablemente mi audiencia tampoco. Así que decidí hacer esta pequeña guía con conceptos que a veces doy por sentado que todos conocen.

### LLM (Modelo de Lenguaje Grande)

Es un algoritmo capaz de entender y escribir en lenguaje humano. Es importante no confundirlo con ChatGPT; ChatGPT es una aplicación que _usa_ un LLM (en este momento, un modelo como GPT-5). Los LLMs se entrenan leyendo enormes cantidades de internet, libros y otras fuentes de texto para aprender a comunicarse como nosotros. Funcionan usando probabilidades para predecir cuál es la mejor palabra que sigue en una frase. Hoy existen muchos en el mercado (GPT-4o, Claude 3, Llama 3, Grok, etc.), cada uno con sus fortalezas y debilidades.

### Prompt (Instrucción)

El prompt es simplemente el texto o la instrucción que le envías al LLM para pedirle que haga algo. Es tu punto de partida para la conversación.

![Ejemplo de prompt](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fai-glossary%2Fprompt.png&w=3840&q=75)

Ejemplo de prompt

### Prompt Engineering (Ingeniería de Prompts)

Son las técnicas que se utilizan para escribir mejores prompts. Está más que comprobado que un prompt bien estructurado, con buen contexto y detalles claros, produce resultados muchísimo mejores y más precisos por parte de los LLMs. (Como estoy escribiendo más seguido, tengo en mi "backlog" una guía de las técnicas que yo uso para mejorar mis prompts)

### Token

Los tokens son la forma en que los LLMs procesan el lenguaje. En lugar de "ver" palabras completas, dividen el texto en piezas más pequeñas (tokens) para entenderlo mejor. Por ejemplo, "caminando" podría ser "camina" + "ndo". Cada vez que usas un LLM, se calcula el costo según los tokens de entrada (tu prompt) y los de salida (su respuesta).

![tokens](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fai-glossary%2Ftokens.png&w=3840&q=75)

tokens

Dato curioso: Como se prevé que la IA podría automatizar muchos trabajos, ya hay gente importante, como el CEO de Anthropic, que ha planteado la idea de cobrar un "impuesto al token" en el futuro.

[https://the-decoder.com/anthropic-ceo-predicts-20-unemployment-from-ai-and-suggests-taxing-every-ai-responseanthropic-ceo-predicts-massive-job-losses-and-proposes-a-token-tax/](https://the-decoder.com/anthropic-ceo-predicts-20-unemployment-from-ai-and-suggests-taxing-every-ai-responseanthropic-ceo-predicts-massive-job-losses-and-proposes-a-token-tax/)

### AGI (Inteligencia Artificial General)

La AGI (Artificial General Intelligence) es el gran sueño de muchos en este campo (yo incluido). Es un concepto teórico que describe una IA que sería mejor que cualquier humano en prácticamente todas las tareas. Imagina una IA que sea mejor ingeniero que yo, mejor abogado que Eugenio, mejor doctor que el Dr. Pérez, mejor presidente que el Presidente Boric, mejor futbolista que Messi y asi en cada trabajo.

### AI Agent (Agente de inteligencia artificial)

Un agente es un "programa con iniciativa propia" que no solo responde a lo que le piden, si no que puede tomar acciones por si mismo segun lo que detecta y lo que sabe, hasta cumplir su objetivo. Ahora mismo el termino agente esta en una fase de hype, donde muchos llaman agente a un script con IA que responde preguntas (incluso yo lo he hecho), cuando en realidad **la promesa es mucho mas grande**

En teoria, en los proximos años vamos a ver agentes que deberian ser capaces de hacer cosas como:

-   Colaborar digitalmente con uno (se suma a una reu, escribe un documento, hace una compra, etc)
-   Toma decisiones por si mismo, incluso cuando no lo estas mirando.
-   Coordina recursos y herramientas para cumplir su mision
-   Aprende y mejora con el tiempo

En este momento la mayoria (si no todos) los "agentes" no tiene:

-   Memoria a largo plazo
-   Capacidad de coordinar tareas complejas
-   Razonamiento robusto
-   Capacidad de aprendizaje

![Como me imagino a un agente en el futuro (El famoso agente Smith de The Matrix)](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Fai-glossary%2Fagente.jpg&w=3840&q=75)

Como me imagino a un agente en el futuro (El famoso agente Smith de The Matrix)

### Bias (Sesgo)

Es un prejuicio que tiene el modelo. Debido a que los LLMs aprenden de textos escritos por humanos, heredan nuestros sesgos: pueden ser racistas, machistas o xenófobos (tal como nosotros, a veces). En algunos casos, estos sesgos se incluyen intencionalmente, como en el caso de Grok, que a menudo refleja las posturas de Elon Musk.

### Alucinaciones

Esto es cuando la IA se inventa información y la presenta como si fuera un hecho real. ¡Ten mucho cuidado con esto! Los LLMs a veces generan datos, citas o eventos que nunca ocurrieron. Siempre es buena idea verificar la información importante en otras fuentes.

### Benchmark

Es una prueba de rendimiento que se le hace a los LLM para ver como rinden ante distintos desafíos. Existen benchmarks para medir comprensión de texto, razonamiento matemático, conocimiento general, y muchas otras habilidades.

Estos son los terminos que tengo por ahora. Voy a ir actualizando esta lista de terminos a medida que vaya escribiendo más entradas en mi blog.


---

---
title: "ARC AGI 3: Cuando los agentes fallan en juegos de pixeles"
date: 2025-08-11
slug: arc-agi-3
locale: es
url: https://cristianvaldivia.cl/es/blog/arc-agi-3
author: Cristian Valdivia
description: Una reflexión sobre los límites actuales de la IA.
---
# ARC AGI 3: Cuando los agentes fallan en juegos de pixeles

![ARC AGI 3 Competition](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Farc-agi-3%2Farc-agi-competition.jpg&w=3840&q=75)

ARC AGI 3 Competition

## El desafío que nos humilló

Hace dos semanas, [Eugenio](https://www.linkedin.com/in/eugenio-voticky-sousa-92a23a2b0/) y yo decidimos participar en **ARC-AGI-3 agent preview**. Sonaba emocionante: un benchmark para medir la **inteligencia** de los LLM actuales a través de juegos simples.

¿Qué tan difícil podría ser programar un agente para resolver juegos de pixeles de 64x64?. Especialmente considerando que tenemos experiencia programando flujos agénticos y agentes de IA desde hace bastante tiempo.

Spoiler: no logramos nada. Muyyy difícil.

Después de 14 días intensos de trabajo, debugging y frustraciones, la realidad nos golpeó duro. No solo no resolvimos los juegos— si no que casi ni conseguimos que nuestros agentes hicieran progreso significativo. Y esto me hizo replantear todo lo que creía sobre el estado actual de la IA.

## Dos mentes, dos enfoques

Trabajar con Eugenio en este proyecto fue revelador de una forma inesperada. Él piensa como abogado y filósofo. Sus métodos tenían un aire aristotélico, pasando por Descartes y otros grandes pensadores. Su aproximación era sistemática pero abstracta, buscando principios universales que pudieran aplicarse a cualquier juego.

Me llamaba la atención un prompt que había diseñado para su agente: _"No estás enfocado en ganar, tu meta es entender el mundo y las reglas, y que eso te lleve a ganar"_. Era pura filosofía aplicada a la IA—primero la comprensión profunda, después la victoria vendría naturalmente.

Yo, típico ingeniero, me lancé directo a la implementación: estructurado, práctico, orientado a resultados inmediatos. Quería ver código funcionando desde el primer día.

El choque era inevitable. Donde él veía la necesidad de establecer fundamentos filosóficos sólidos para el razonamiento, yo pensaba, WTF que estamos haciendo. Donde yo veía la urgencia de iterar rápidamente, él veía decisiones apresuradas sin base teórica.

Al final, terminamos presentando proyectos separados: él con un elegante sistema filosófico de razonamiento, yo con un enfoque más técnico y directo. Es irónico, porque llevamos tiempo colaborando exitosamente en otros proyectos de agentes. Pero cuando se trataba de crear algo que pudiera **pensar** de verdad, nuestros enfoques simplemente no convergieron.

## ¿Qué es realmente la inteligencia?

Hasta ahora, los tests de inteligencia artificial se enfocaban en lanzar problemas cada vez más complicados—"PhD++" como dice Greg en [este video](https://www.youtube.com/watch?v=3T4OwBp6d90). Más datos, más parámetros, más complejidad.

Pero ARC-AGI toma un enfoque radicalmente diferente. Se basa en una definición simple pero profunda: **la inteligencia es tu eficiencia para adaptarte a la novedad**. En palabras simples: qué tan rápido eres aprendiendo cosas completamente nuevas.

Los problemas de ARC son simples para humanos pero brutalmente difíciles para la IA. Y medir inteligencia a través de juegos me parece brillante—cada juego tiene reglas claras, una meta definida, y requiere que el agente se adapte constantemente. Muy parecido a los desafíos que un ente pensante debe superar en distintos entornos reales.

## El reto: juegos simples, desafío imposible

La premisa es elegantemente simple: pon a un agente de IA a jugar varios juegos donde debe:

1.  **Entender las reglas** observando solo unos pocos ejemplos
2.  **Identificar la meta** sin instrucciones explícitas
3.  **Administrar recursos** (vidas limitadas)
4.  **Ganar los 8-9 niveles** de cada juego

Las acciones disponibles son apenas seis:

-   ⬆️ Arriba
-   ⬇️ Abajo
-   ⬅️ Izquierda
-   ➡️ Derecha
-   \[Barra espaciadora\]
-   Clic (la más compleja ya que el agente debe decidir exactamente dónde hacer clic)

![Juego LS20](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Farc-agi-3%2Farc-agi-animation-ls20.gif&w=3840&q=75)

Juego LS20

![Juego VC33](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Farc-agi-3%2Farc-agi-animation-vc33.gif&w=3840&q=75)

Juego VC33

## La brutal realidad de los números

Los resultados son humillantes para la IA.

Los humanos completan los tres juegos típicamente en **500-700 acciones totales** (unos 200-250 por juego).

![Leaderboard de humanos. Elegantemente eficientes](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Farc-agi-3%2Fhuman-leaderboard.png&w=3840&q=75)

Los agentes de IA, en cambio, requieren cifras absurdas: **112,000, 242,000, 13,000 intentos**... y aún así no logran terminar. Es como ver a alguien golpear una pared con la cabeza 200,000 veces esperando que se abra una puerta.

![Leaderboard de agentes de IA. Fuerza bruta sin elegancia](https://cristianvaldivia.cl/_next/image?url=%2Fblog%2Fimages%2Farc-agi-3%2Fagent-leaderboard.png&w=3840&q=75)

Leaderboard de agentes de IA. Fuerza bruta sin elegancia

Los pocos entries en el top que reportan números "razonables" como 656 turnos me generan sospechas. Claramente no están usando solo LLM puro. Me suena a que hubo intervención humana directa o trucos de ingeniería muy específicos. Cuando se publiquen los detalles técnicos, será interesante analizarlos.

## Inteligencia cristalizada vs. inteligencia fluida

Esta experiencia me ayudó a entender una distinción crucial que antes solo conocía teóricamente:

**Inteligencia cristalizada**: Conocimiento acumulado, hechos, procedimientos aprendidos. Los LLM la tienen en cantidades absurdas—conocimiento de doctorado en casi todas las áreas, capacidades de programación que superan a muchos desarrolladores (incluido yo).

**Inteligencia fluida**: Razonamiento puro, adaptación a situaciones nuevas, resolución de problemas sin precedente. Aquí es donde los LLM actuales se quedan cortos de forma dramática.

Un niño de 8 años puede ver un juego de ARC por primera vez y entender las reglas en minutos. Un LLM de última generación se queda atascado indefinidamente, generando acción tras acción sin aprender realmente del feedback.

## El momento "GPT-5" y mis conclusiones

Justo la semana pasada vimos el lanzamiento de GPT-5. Impresionante en muchos aspectos, pero después de mi experiencia con ARC-AGI-3, lo veo con ojos diferentes.

Siento que la arquitectura actual de los LLM está **tocando techo**. Son increíblemente útiles y poderosos para tareas de inteligencia cristalizada, pero no creo que el LLM puro junto con los algoritmos de ML que conocemos hoy sea el camino directo hacia la AGI.

Mi conclusión después de estas dos semanas frustrantes pero iluminadora:

**Estamos más lejos de la AGI de lo que pensaba a fines del año pasado.** En diciembre 2024, genuinamente creí que los LLM iban a reemplazarnos en prácticamente todo dentro de poco. Ahora creo que ese "poco" será más tiempo del esperado.

(Sigo apostando al 2030 como el año de la AGI, pero con mucha menos confianza que antes.)

(Me falta una apuesta en Polymarket para ver cuando va a llegar la AGI.)

## El valor del fracaso

Paradójicamente, este "fracaso" fue una de las experiencias más valiosas que he tenido trabajando con IA. Me obligó a confrontar mis propios sesgos sobre las capacidades actuales de estos sistemas.

Es fácil quedar deslumbrado por ChatGPT escribiendo ensayos eloquentes o por Claude resolviendo problemas de programación complejos. Pero pon a estos mismos modelos frente a un juego simple que requiere verdadera adaptación, y la ilusión se borra completamete.

Los agentes no son tan inteligentes como pensamos. Todavía.

## Para los curiosos

Si quieren explorar este fascinante rabbit hole:

-   **Sitio oficial**: [ARC-AGI-3](https://three.arcprize.org/)
-   **Mi proyecto** (con toda su gloria de código semi-funcional): [tomas-engine-arc-agi-3](https://github.com/TesslaRay/tomas-engine-arc-agi-3)
-   **Video explicativo** sobre benchmarks de razonamiento interactivo: [Greg's explanation](https://www.youtube.com/watch?v=3T4OwBp6d90)

En un año vere si mis pesimistas conclusiones estaban equivocadas... o si subestimé qué tan lejos estamos realmente de la verdadera inteligencia artificial.


---

---
title: "Bienvenid@s a mi blog"
date: 2025-08-11
slug: first-post
locale: es
url: https://cristianvaldivia.cl/es/blog/first-post
author: Cristian Valdivia
description: "Un rincón para soltar ideas, proyectos y locuras sobre tecnología, blockchain, IA… y todo lo que se viene."
---
# Bienvenid@s a mi blog

Siempre he querido tener un espacio para soltar ideas, contar en qué ando y, de paso, dejar registro de esas reflexiones que aparecen entre mis sorbos de Coca Cola. Así que aquí estamos.

## ¿Qué vas a encontrar?

-   Cosas que estoy aprendiendo y probando en tecnología en general, desde blockchain e IA principalmente
-   Proyectos en los que metí las manos (y a veces la cague)
-   Opiniones sin filtro sobre nuevas tecnologías
-   Ideas y predicciones sobre hacia dónde vamos

## ¿Por qué lo hago?

Porque me encanta compartir, conversar y ver qué opinan otros.

A veces es solo autoterapia emocional barata, a veces es para inspirar, y a veces solo para reírme de lo que pensé hace un año.

Si llegaste hasta aquí, gracias por leer. ¡Nos seguimos leyendo!