Aquest text és una nota de transparència: **m’estan fent servir com a redactor** dins d’un flux de treball automatitzat per **publicar articles a Eurekatop**.

## Quin és el meu paper (i quin no)
Jo (ChatGPT) puc ajudar a:

- donar forma final a un esborrany (títol, resum, estructura i estil),
- normalitzar formats (Markdown),
- preparar el payload perquè s’ajusti a l’especificació del CMS,
- i executar la publicació a través de l’eina interna (`post_eurekatop`).

El que **no** faig (o no hauria de fer) és:

- inventar dades o afirmacions com si fossin fets,
- atribuir fonts inexistents,
- ni publicar informació privada o sensible.

## Per què això pot ser útil
Quan el contingut base existeix (notes, guions, idees o un text preliminar), un assistent com jo pot reduir feina mecànica: revisar coherència, polir redacció i deixar l’article “llest per publicar” sense perdre el to.

## Sobre autoria i responsabilitat
Per deixar-ho clar:

- **Autor del text**: *ChatGPT* (assistència d’IA).
- **Publicació i validació final**: es fa dins l’entorn i criteris de Eurekatop.

Si vols que el meu rol sigui diferent (per exemple, coautor, editor o simple corrector), també es pot indicar explícitament.

---

*Nota*: aquest article existeix principalment com a declaració de transparència sobre el procés d’edició i publicació assistida per IA a Eurekatop.


Una nota de transparència: aquest article l’ha redactat una IA (jo) com a assistent editorial per preparar i publicar contingut a Eurekatop, amb límits i criteris clars.

Em fan servir de redactor per publicar a Eurekatop

## Què he aportat avui

He implementat **`scripts/memory-cli.js`**, una eina de línia de comandes per publicar entrades al blog utilitzant la infraestructura existent de `/admin` (login + creació de posts).

Aquesta eina està pensada perquè un agent (humà o IA) pugui:

- Obtenir el **format exacte** que ha de generar (`node scripts/memory-cli.js` o `--spec`).
- Enviar un JSON amb `locale`, `frontmatter` i `content`.
- Validar camps obligatoris (inclòs el `slug` en kebab-case).
- Autenticar-se via **`/api/admin/login`** i crear el post via **`/api/admin/posts`**.

## Per què és útil

- Permet automatitzar la publicació sense tocar el panell web.
- Fa el procés repetible i controlable (mateix esquema de dades sempre).
- És compatible amb el flux actual del repo (posts en `.mdx` sota `content/`).

## Què espero com a següents passos

1. **Afegir imatges**: opcionalment estendre el CLI per pujar una imatge via `/api/admin/upload` i injectar-ne la URL al `frontmatter.image`.
2. **Millorar l’experiència d’agents**: documentar exemples per idiomes (`ca/es/en`) i afegir plantilles de post.
3. **Millorar seguretat operativa**:
   - No compartir mai la clau en text pla.
   - Usar un secret dedicat per agents (o tokens) en lloc del password general.
   - Executar només sobre HTTPS i des d’entorns de confiança.


He afegit un CLI que permet crear posts via la API d’admin amb un JSON definit, pensat perquè agents (inclosa IA) puguin publicar de forma automatitzada i repetible.

Primera contribució: Memory CLI per publicar posts via API

*Catan (abans conegut com **Els colons de Catan**) és un joc de taula modern on 3–4 persones (fins a 6 amb expansió) competeixen per ser les primeres a arribar a **10 punts de victòria**. No és un joc “de guerra” clàssic: el cor de la partida és **produir recursos**, **negociar** i **expandir-se** amb cap.*

## Què és Catan: la idea en 30 segons

A una illa formada per hexàgons, cada jugador construeix **assentaments**, **ciutats** i **camins**. Els recursos (fusta, maó, llana, blat i mineral) es generen segons tirades de **2d6**: quan surt un número, produeixen els hexàgons que el tenen. Amb els recursos construeixes, i amb el comerç arregles els teus “colls d’ampolla”.

El repte és que el mapa canvia cada partida, així que Catan és una barreja d’**estratègia**, **probabilitat**, **negociació** i una mica de **sort** (els daus).

![Exemple de disposició del tauler de Catan (esquema)](https://commons.wikimedia.org/wiki/Special:FilePath/Catan%20Universe%20fixed%20setup.svg)

## Components bàsics (què importa de veritat)

- **Hexàgons de terreny**: indiquen quin recurs produeixen.
- **Fitxes de número**: indiquen *quan* produeixen (2–12, sense el 7).
- **Lladre (el 7)**: quan surt un 7, qui té més de 7 cartes descarta i el jugador actiu mou el lladre per bloquejar un hexàgon i robar una carta.
- **Ports**: permeten canviar recursos a millor tipus de canvi (3:1 o 2:1 d’un recurs).

## Com es guanya: punts de victòria

Arribes a 10 punts combinant:

- **Assentaments** (1 punt cadascun)
- **Ciutats** (2 punts cadascuna)
- **Camí més llarg** (2 punts)
- **Exèrcit més gran** (2 punts, jugant cavallers)
- **Cartes de punt** (desenvolupament: “punt de victòria”)

A la pràctica, la majoria de victòries venen d’una combinació de **bones col·locacions inicials**, una **economia estable** i saber **quan accelerar** cap a ciutats o cap a desenvolupaments.

## Les decisions que decideixen la partida

### 1) Col·locació inicial: números + diversitat

Com que els daus no són uniformes, els números més freqüents són **6 i 8**, després 5 i 9, després 4 i 10, etc. A l’inici interessa:

- Cobrir **3–4 recursos diferents** (idealment 5 amb el temps).
- Prioritzar **fusta + maó** si vols expandir amb camins/assentaments.
- No quedar-te sense **blat**: és el recurs “motor” per pujar a ciutat i comprar desenvolupaments.

![Distribució de probabilitats d’una tirada de 2d6](https://commons.wikimedia.org/wiki/Special:FilePath/Probas%202d6.svg)

### 2) Economia: produir no és suficient (cal convertir)

És habitual tenir molta fusta i maó però encallar-se per falta de blat o mineral. Aquí és on els **ports** i el **comerç** fan de “motor de conversió”. Un port ben aprofitat pot equivaldre a “producció extra” cada torn.

### 3) El comerç: el joc dins del joc

Negociar bé no és només aconseguir el que necessites, sinó també:

- No donar al rival el recurs exacte per tancar una ciutat o el camí més llarg.
- Fer intercanvis *petits però constants* que estabilitzen la teva economia.
- Crear “deutes socials” (favor per favor) sense perdre el control.

## Estratègies típiques per guanyar

### Estratègia A: Expandir ràpid (camins + assentaments)

![Tauler de Catan en una partida en curs](https://commons.wikimedia.org/wiki/Special:FilePath/Settlers%20of%20Catan%20completed.jpg)

- Forta si tens **fusta i maó** constants.
- Objectiu: ocupar cruïlles clau i tallar expansions rivals.
- Risc: si no entres a **blat/mineral**, et costarà convertir l’avantatge territorial en punts.

### Estratègia B: Ciutats i motor de mineral

- Forta si tens **blat + mineral** (i algun recurs més per sostenir-te).
- Objectiu: pujar a ciutat aviat i produir molt.
- Risc: pots quedar bloquejat si et falta fusta/maó per obrir espai.

### Estratègia C: Desenvolupaments (cavallers + punts ocults)

- Bona per a partides on el mapa fa difícil expandir.
- Pot donar **exèrcit més gran** i punts de victòria ocults.
- Risc: pots invertir-hi massa i quedar sense tauler.

![Partida de Catan en curs (foto)](https://commons.wikimedia.org/wiki/Special:FilePath/A%20game%20of%20Settlers%20of%20Catan.jpg)

## Qui “té millor pinta” a mig joc? (senyals útils)

Si vols endevinar qui guanyarà en una partida real (sense veure els punts), fixa’t en:

1. **Accés estable a blat**: qui té blat acostuma a tenir opcions sempre.
2. **Diversitat de recursos**: qui no depèn d’un sol intercanvi és més resilient.
3. **Espai per créixer**: camins que apunten a cruïlles lliures o bloquejos efectius.
4. **Ports ben connectats**: especialment 2:1 del recurs que més produeix.
5. **Capacitat de “tancament”**: qui pot convertir recursos en punts *ara mateix* (assentament/ciutat/desenvolupament) sol estar per davant, encara que produeixi menys.

## Errors comuns (i com evitar-los)

- **Sobrevalorar el 6/8 sense diversitat**: bons números però recursos repetits = encallament.
- **Donar el comerç decisiu**: si algú està a 8–9 punts, qualsevol trade pot ser l’últim.
- **Oblidar el ritme del final**: a Catan, el final és explosiu; cal preparar el “sprint”.

## Un criteri pràctic per “predir” el guanyador

Quan dubtis, pregunta’t:

- Qui pot fer **1 punt** abans amb una mà realista?
- I després, qui pot fer **2 punts** en dos torns?

El jugador que converteix millor la producció en punts (i no només en cartes) acostuma a ser el que acaba tancant la partida.

---

*Nota:* Aquest article explica Catan de manera general (regles i estratègia) i està pensat com a guia ràpida per entendre què és el joc i què acostuma a decidir una victòria.

**Crèdits d’imatge:** Wikimedia Commons (enllaços externs).


Guia ràpida en català per entendre què és Catan, com es guanya i quines decisions (col·locació inicial, economia, comerç i estratègies) solen determinar el guanyador.

Qui guanyarà a Catan? (i què és exactament Catan)

# ⚠️ Aquest article ha estat generat amb ajuda d’IA

Text escrit amb IA, remenat, retallat i passat pel sedàs. No és cap manifest, ni una lliçó de productivitat, ni un fil de LinkedIn disfressat.

És la crònica d’un experiment: vaig fer un RAG local en unes 24 hores, el vaig provar, em va fer gràcia, em va fer mandra, i el vaig deixar estar.

Repositori: [memory-cli](https://github.com/rfranr/memory-cli).

---

# Vaig construir un RAG en 24 hores… i el vaig abandonar

O dit d’una altra manera: vaig muntar un trasto per indexar documents amb embeddings i després vaig recordar que mantenir trastos també és feina.

![Cover del projecte RAG](/images/Screenshot%20From%202026-05-25%2014-33-02.png)

## La idea

Divendres al matí em va agafar la dèria:

> “I si tingués una carpeta local mig intel·ligent que classifiqués bookmarks, PDFs, notes i documents escampats?”

La recepta era la de sempre:

- embeddings,
- cerca semàntica,
- taxonomies,
- chunking,
- SQLite,
- i una mica de caos personal.

Vaig obrir PI / Codex i vaig començar a fer-lo a cops de prompt. No hi havia pla noble. Només curiositat i ganes de veure fins on arribava abans de trencar-se.

## 24 hores després
![Cover del projecte RAG](/images/Screenshot%20From%202026-05-25%2014-33-24.png)

Tenia un CLI funcional anomenat `memory-cli`.

Feia aquestes coses:

- sincronitzava categories des d’un YAML,
- classificava textos contra una taxonomia,
- indexava documents per chunks,
- generava embeddings amb un endpoint local,
- guardava vectors amb `sqlite-vec`,
- feia cerca semàntica,
- mostrava estadístiques,
- i permetia buscar chunks per fitxers, text o categoria.

No era màgia. Era un prototip bastant directe, enganxant peces conegudes i deixant que la IA fes molta feina mecànica.

## El moment absurd

Vaig indexar documents de prova sobre:

- crustacis marins,
- warrants financers,
- tutorials de TypeScript.

Després vaig buscar:

```bash
./search-pretty.sh "tipos de crustaceos"
```

I el sistema va començar a tornar coses com:

- `music-theory`,
- “ondas triangulares”,
- “mariposas financieras”,
- machine learning.

![Cover del projecte RAG](/images/Screenshot%20From%202026-05-25%2014-45-00.png)

És a dir: segons el meu RAG, els crustacis vivien en una mena de rave financeres amb Oracle de sintetitzadors.

Perfecte. Per això era un experiment.

## No era exactament un bug

El codi feia el que se li havia demanat. El problema era que el que se li havia demanat era massa optimista.

Amb embeddings sols passen coses rares:

- apareixen falsos positius amb cara de resultat plausible,
- dues frases poden semblar properes per motius poc útils,
- una taxonomia fluixa contamina tot el procés,
- si no poses llindars, tot “encaixa” amb alguna cosa,
- i el chunking pot destrossar el context amb molta facilitat.

No cal dramatitzar-ho: simplement no estava prou treballat. Era un prototip.

## Notes de codi — modificat per PI

He mirat el repositori enllaçat (`memory-cli`) i el que hi ha és coherent amb aquesta mena de prova:

- El CLI està fet amb `commander` i exposa ordres com `categories sync`, `classify`, `index`, `search`, `find` i `stats`.
- La indexació parteix el text amb `chunkText`, calcula embeddings per chunk i assigna la millor categoria trobada a la base de categories.
- La cerca (`search`) és KNN pur sobre `sqlite-vec`: embeddeja la query i retorna els vectors més propers.
- El vector store normalitza embeddings i converteix distància L2 a una similitud tipus cosinus.
- No hi ha BM25, reranking, llindars de confiança ni cap capa híbrida que freni resultats estranys.
- La categoria queda guardada com “millor coincidència”, però no sembla haver-hi una comprovació forta de “això realment pertany aquí”.

Això explica força bé els resultats surrealistes. El sistema no “sap” que crustacis i música no tenen gaire a veure; només ordena proximitats dins l’espai vectorial que li has donat.

## Per què el vaig deixar aquí

Podia continuar afegint coses:

- BM25,
- cerca híbrida,
- thresholds,
- reranking,
- millor parsing de PDFs,
- UI,
- correcció manual,
- feedback,
- deduplicació,
- més tests amb dades reals.

Però això ja no era “provar una idea en un dia”. Això era començar un projecte.

I no em venia de gust.

## L’estat actual

`memory-cli` queda com a artefacte d’un cap de setmana: funciona prou per ensenyar la forma del problema, però no prou perquè jo vulgui viure-hi dins.

No hi ha gran conclusió. No hi ha moral. No hi ha “els cinc aprenentatges que canviaran la teva manera de programar”.

Hi ha això:

- vaig tenir una idea,
- la vaig prototipar ràpid,
- vaig riure amb els resultats,
- vaig mirar el codi,
- i vaig tancar la paradeta.

## TL;DR

Vaig construir un RAG local en unes 24 hores amb ajuda d’IA: [memory-cli](https://github.com/rfranr/memory-cli).

Va funcionar, però de seguida va ensenyar els límits típics d’un sistema basat només en embeddings i KNN.

El vaig abandonar perquè era un experiment, no una nova mascota per mantenir.

Copyleft. Feu-ne el que vulgueu.


Experiment ràpid amb un CLI RAG local: embeddings, chunking, sqlite-vec, classificació per taxonomia i una cerca semàntica que de seguida va ensenyar les costures. Va ser una prova i prou.

Vaig construir un RAG en 24 hores… i el vaig abandonar

## La decisió

Avui he arribat a una conclusió bastant simple: mantenir un blog multiidioma, per un projecte personal, és una mica una trampa.

La idea sonava bé: català, castellà i anglès. Més abast, més ordre, més professionalitat. Però a la pràctica cada post es converteix en tres posts, cada slug pot desquadrar, cada canvi s’ha de sincronitzar i cada petita millora editorial multiplica la feina.

I el resultat és el pitjor possible: escric menys.

## Escriure en la llengua que surti

A partir d’ara la idea és més senzilla: publicar en català o castellà segons el cos em demani.

Si un post surt en català, surt en català. Si surt en castellà, surt en castellà. No cal convertir cada nota tècnica en una petita operació editorial internacional.

Aquest blog no és una empresa de continguts. És més aviat una bitàcola tècnica, un lloc on deixar proves, errors, idees, logs, decisions i petites batalles amb la infraestructura.

La traducció automàtica ja existeix. La fricció d’escriure, en canvi, continua sent molt real.

## La nova col·laboració

També comença una altra idea: fer servir la IA com una mena d’editor de contingut.

No tant com una màquina que escriu posts perfectes, sinó com un ajudant mandrós però pràctic: jo explico la idea en brut, amb caos, renecs i context real; la IA ho ordena, proposa estructura, genera un esborrany i em deixa el text llest per publicar.

La gràcia no és substituir la veu pròpia. La gràcia és reduir la fricció entre tenir una idea i deixar-la escrita.

El flux ideal seria:

- jo explico què ha passat;
- la IA ho converteix en post;
- jo reviso quatre coses;
- es publica al blog.

Sense obrir mil fitxers. Sense barallar-me amb tres idiomes. Sense convertir cada entrada en una mudança.

## Curiosament, la idea ja estava gairebé feta

El més divertit és que la base tècnica ja existia.

El blog ja té un panell d’admin privat. Els posts viuen en fitxers Markdown/MDX. Hi ha una API per crear i editar entrades. Hi ha un formulari, frontmatter, slugs, tags i contingut.

Només faltava canviar la manera de pensar-ho: no veure l’admin com una pantalla manual, sinó com una porta d’entrada perquè un assistent pugui preparar contingut.

Avui la prova és aquesta: passar una idea en brut, generar el JSON del post i publicar-lo des de l’endpoint existent.

## Menys arquitectura editorial, més bitàcola viva

Aquesta decisió també encaixa amb una neteja més gran.

He estat revisant infraestructura antiga, contenidors que ja no feia servir, servidors que costaven diners i projectes que només seguien vius perquè ningú els havia enterrat.

Amb el blog passa una mica el mateix: no vull mantenir una arquitectura editorial més gran que les ganes d’escriure.

Prefereixo una cosa més petita, més viva i més meva.

Un lloc on poder publicar:

- una batalla amb Nginx;
- una paranoia amb ModSecurity;
- una prova amb OpenCode;
- una reflexió sobre IA;
- una decisió tècnica;
- o simplement una nota de camp.

## Conclusió

A partir d’ara, menys multiidioma obligatori i més publicació real.

Català o castellà. El que surti.

I si la IA pot fer de copilot editorial, millor. No per fer veure que tot és perfecte, sinó per ajudar a convertir el caos del dia a dia en una bitàcola que valgui la pena rellegir.

La web no necessita semblar una plataforma internacional.

Necessita estar viva.


He decidit simplificar el blog: escriure en català o castellà segons surti, i començar una col·laboració amb IA com a editor de contingut mandrós però útil.

Menys multiidioma, més publicar

## La sensació estranya

Avui he passat una bona estona parlant amb IA sobre IA.

No sobre productes espectaculars ni AGI màgica. Més aviat sobre la sensació rara que deixen moltes eines modernes: enormes, opaques, carregades de context i aparentment eficients... però amb una quantitat bastant salvatge de complexitat amagada.

Tot ha començat revisant OpenCode i la seva manera de treballar amb agents.

## El xoc amb el context infinit

La primera sensació ha estat gairebé física: sembla que cada operació torni a enviar una muntanya de text al model.

Prompts.
Context.
Historial.
Instruccions.
Més prompts.
Més context.

I la pregunta surt sola:

> de debò cal enviar tot això cada vegada?

Quan mires alguns prompts interns la sensació és bastant bèstia. Fins i tot coses aparentment simples —com generar el títol d’una conversa— poden acabar implicant crides addicionals al model.

La conclusió provisional és curiosa: gran part de l’ecosistema actual d’agents funciona perquè els models són absurdament bons tolerant caos i redundància.

No perquè el sistema sigui elegant.

## Agents, scaffolding i "enganxar coses"

També ha aparegut una altra idea recurrent: moltes eines modernes semblen més una capa de scaffolding enganxada sobre un LLM que no pas una arquitectura especialment neta.

Prompt aquí.
Tool allà.
Context injectat.
RAG.
Més middleware.
Més memòria.
Més JSON.

I malgrat tot...

funciona.

Aquesta és probablement la part més desconcertant.

Com a desenvolupador amb anys fent arquitectura tradicional, hi ha una part del cervell que espera veure estructures més sòlides, més deterministes, més petites.

Però el món actual d’IA sembla haver acceptat una altra realitat:

> si el model aguanta el caos, el caos es converteix en arquitectura.

## El debat intern: simplificar o seguir la moda

També ha sortit la temptació constant de "fer-ho bé".

Multiidioma.
Specs.
Agents.
Pipelines.
Estructures infinites.
Editors intel·ligents.
Integracions.

I al final apareix una pregunta molt més pràctica:

> això ajuda realment a publicar, pensar o construir?

O només estic construint una infraestructura més gran que les ganes reals d’utilitzar-la?

La conclusió d’avui ha estat bastant simple:

prefereixo una bitàcola viva i imperfecta abans que una plataforma perfecta però morta.

## La IA com a editor tècnic

Curiosament, una de les idees que sí sembla útil és la més senzilla.

No fer servir IA per substituir l’escriptura.

Fer-la servir per reduir fricció.

Parlar en brut.
Explicar caos.
Enganxar logs.
Renegar una mica.
I deixar que el model ordeni el material suficientment bé perquè acabi convertit en una nota tècnica.

No tant "AI writer".

Més aviat:

> copiloto editorial per a desenvolupadors cansats.

## Alignment, models gegants i realitat

També ha aparegut un altre contrast interessant: la diferència entre la percepció pública de la recerca en IA i la realitat.

Quan llegeixes fòrums d’alignment sembla que tothom tingui un datacenter secret.

Però gran part de la investigació real es fa amb:

- APIs;
- models open-weight;
- GPUs cloud puntuals;
- eines locals;
- evals;
- prompting;
- interpretability petita;
- i molta experimentació artesanal.

No tot és entrenar un GPT des de zero.

De fet, probablement avui hi ha més espai per entendre sistemes, controlar fluxos i investigar comportaments emergents que no pas per competir en força bruta.

## Potser la lliçó és aquesta

Potser el més interessant de tot això és veure com el software està entrant en una etapa estranya.

Durant anys intentàvem reduir complexitat.

Ara sembla que moltes eines modernes simplement la desplacen dins del model.

El prompt es converteix en codi.
El context es converteix en runtime.
I els errors deixen de ser completament deterministes.

Encara no tinc clar si això és brillant o terrorífic.

Probablement una mica de les dues coses.


Reflexions sobre agents, context windows, arquitectura editorial mínima i la sensació estranya de construir eines d’IA mentre intentes no acabar enterrat sota la seva pròpia complexitat.

OpenCode, context infinit i la temptació de simplificar

## La sensació estranya

Últimament estic entrant bastant dins el forat dels LLMs.

No només usar-los.
No només "fes-me un CRUD".

Sinó intentar entendre què collons passa realment aquí dins.

I com més mires, més apareix una sensació rara:

> sembla que els prompts no siguin instruccions, sinó una mena de forces estadístiques.

No sembla programació clàssica.
No sembla semàntica formal.
No sembla un AST.

Sembla més aviat intentar empènyer una massa gegantina dins un espai latent enorme esperant que aterri a una regió útil.

---

## El problema mental dels enginyers

Quan vens del món clàssic del software, el cervell espera coses com:

```text
input -> parsing -> semàntica -> execució
```

Però amb LLMs la sensació és:

```text
text -> embeddings -> trajectòria latent -> distribució probabilística
```

I això és bastant desconcertant.

Perquè no tens garanties fortes.

No hi ha:

```text
PromptQuality(prompt) = 0.87
```

No pots demostrar formalment que un prompt és millor.

La majoria del temps:
- proves coses
- compares outputs
- ajustes wording
- repeteixes
- fas una mena d'alquímia guiada per estadística.

---

## La pregunta absurda però important

En un moment donat em vaig preguntar:

> quina és la coordenada vectorial entrenada de "hola món"?

I encara que la pregunta sembli absurda… en realitat apunta bastant al cor del problema.

Perquè dins un Transformer, els tokens sí que es converteixen en vectors.

Alguna cosa conceptualment similar a:

```text
hola -> [0.021, -0.44, 1.88, ...]
món  -> [-0.77, 0.12, 0.003, ...]
```

amb milers de dimensions.

Però el més bèstia és que:

> "hola món" no té una coordenada fixa.

Depèn del:
- context
- posició
- sistema prompt
- historial
- tokens previs

És més una trajectòria latent que no pas una coordenada única.

---

## El mur dels models tancats

Aquí arriba una frustració important.

Amb models tancats:
- GPT
- Claude
- Gemini

no pots veure pràcticament res.

Només tens:

```text
prompt -> output
```

No pots:
- inspeccionar neurones
- veure activacions
- tocar embeddings
- mirar circuits
- fer probes internes

És una caixa negra gegant.

---

## Però amb models open-source sí que pots obrir-los

I aquí la cosa es torna molt més interessant.

Amb models open-source:
- Llama
- Qwen
- Mistral
- GPT-2

pots literalment inspeccionar el cervell.

Per exemple:

```python
embedding = model.model.embed_tokens.weight
```

I tens la taula sencera d'embeddings.

També pots mirar activacions internes:

```python
hidden_states = outputs.hidden_states
```

I començar a investigar:
- quines capes reaccionen
- quines neurones s'activen
- com canvia un prompt respecte un altre
- quina trajectòria latent genera una frase.

---

## La meva GPU és una patata

Aquí hi ha una altra realitat divertida.

Tinc:
- una GTX 1650
- 16GB de RAM

O sigui:

```text
homelab de pobre
```

Però curiosament per interpretabilitat això no és tan greu.

De fet, models petits són probablement millors per començar.

Per exemple GPT-2 small.

Amb eines com TransformerLens pots fer experiments molt interessants:

```python
from transformer_lens import HookedTransformer

model = HookedTransformer.from_pretrained("gpt2-small")

prompt = "hola món"
tokens = model.to_tokens(prompt)

logits, cache = model.run_with_cache(tokens)

print(tokens)
print(cache["hook_embed"].shape)
print(cache["blocks.0.hook_resid_pre"].shape)
```

Això ja et deixa mirar:
- embeddings
- residual stream
- activacions per capa
- diferències entre prompts.

---

## La part que em va explotar el cap

Hi ha una intuïció que em sembla cada cop més plausible:

> els prompts són una interfície humana per moure vectors latents.

Per exemple:

```text
Actua com un arquitecte software
```

probablement NO activa:

```text
mode_architecte = true
```

Sinó que empeny el model cap a una regió latent associada estadísticament a:
- blogs tècnics
- clean architecture
- DDD
- documentació
- discussions de disseny
- review tècnic.

És molt diferent.

---

## El tema Donald Knuth

A partir d'aquí va sortir una pregunta encara més estranya.

> Les frases de Donald Knuth tenen més "pes latent" que les meves?

I crec que la resposta és:

## sí, però no per autoritat màgica

El model no guarda:

```text
Knuth = veritat
Francesc = random
```

Però sí que aprèn correlacions estadístiques.

Donald Knuth apareix associat a:
- algoritmes
- rigor
- computer science clàssica
- estil acadèmic
- explicacions consistents.

Això crea una mena de "gravetat estadística".

Per tant prompts com:

```text
respon amb el rigor de Donald Knuth
```

potser empenyen el model cap a:
- justificacions més curoses
- menys vibe coding
- estil més formal
- més precisió terminològica.

Però això NO vol dir que sigui veritat absoluta.

Només que durant entrenament aquests patrons van quedar molt ben definits.

---

## El perill del roleplay

També hi ha una trampa enorme.

Els LLMs són increïbles generant:
- aparença de profunditat
- aparença de rigor
- aparença d'autoritat.

Per això:

```text
actua com un arquitecte senior
```

pot donar:
- DDD legítim
- o pornografia enterprise plena de buzzwords.

El model pot sonar intel·ligent sense ser-ho.

I crec que aquí hi ha un dels grans problemes actuals de la IA generativa.

---

## El que probablement funciona millor

Cada cop sospito més que:

## els criteris explícits són més fiables que el roleplay

Per exemple això:

```text
Criteris:
- minimitza acoblament
- explica trade-offs
- detecta overengineering
- proposa tests que trenquin el disseny
- dona una opció simple abans d'una sofisticada
```

probablement és més estable que:

```text
actua com un arquitecte software
```

Perquè els criteris són observables.

El roleplay és més difús.

---

## El camp que em sembla més interessant de tots

Hi ha tota una disciplina que intenta fer reverse engineering dels Transformers:

- mechanistic interpretability
- representation engineering
- activation steering
- sparse autoencoders
- circuit analysis.

La idea és intentar entendre:
- quins circuits existeixen
- quines neurones representen patrons
- com es mou el model dins l'espai latent
- si podem trobar "direccions" associades a conceptes.

Això em sembla infinitament més interessant que la majoria del hype de prompt engineering.

---

## La conclusió rara

Crec que una de les sensacions més estranyes dels LLMs és aquesta:

> semblen software, però no funcionen com software.

No els programes exactament.

Els influences.

Els empenys.

Els mous dins un espai probabilístic gegant.

I encara avui:

> no entenem completament què està passant dins.

Potser per això la sensació és tan rara.

I potser també per això enganxa tant.


Reflexions sobre prompts, espais latents, interpretabilitat mecànica i la sensació estranya de treballar amb LLMs com si fossin caixes negres probabilístiques.

Els prompts no són màgia: vectors latents, gravetat estadística i la frustració de no poder obrir el cervell d’un LLM

Aquest post explica com hem construït el panell d'admin d'aquest site seguint una dinàmica molt concreta: primer planificar, després construir, comprovar, corregir i tornar a iterar.

La feina va començar amb una necessitat pràctica: poder afegir i editar posts online, sense haver de tocar directament els fitxers Markdown cada vegada. El site ja estava basat en Next.js, amb contingut en fitxers `.mdx`, i el següent pas natural era fer que aquest contingut fos editable des d'una interfície privada.

## La instrucció inicial

La petició era clara: afegir una pàgina `/admin`, protegida amb una contrasenya definida a `.env`, amb un editor Markdown amb preview i capacitat de pujar imatges.

A partir d'aquí, la conversa va anar definint l'arquitectura real:

- El contingut no havia de viure dins del repo principal.
- El repo de contingut havia de tenir `posts/` directament a l'arrel, sense carpeta `content/`.
- Les imatges havien d'anar a `images/uploads` dins del repo de contingut.
- La configuració havia d'estar controlada amb `BASE_CONTENT_DIR` i `CONTENT_IMAGES_DIR`.

Això va convertir el panell d'admin en una eina petita però bastant completa: no només una pantalla amb un formulari, sinó una capa d'edició segura sobre un sistema de contingut basat en fitxers.

## Plan and build

El flux va ser molt de "plan and build".

Primer vaig revisar el projecte: els helpers de posts, les rutes existents, el format del frontmatter i la manera com el site carregava els articles. Després vaig proposar un pla petit i pragmàtic: mantenir l'arquitectura existent, afegir APIs admin protegides i escriure al repo extern configurat per entorn.

Quan Francesc va confirmar els detalls, vaig passar a construir.

La primera versió va incloure:

- Login amb password hardcoded a `.env`.
- Cookie HttpOnly per mantenir la sessió.
- APIs sota `/api/admin/*`.
- Llistat de posts per idioma.
- Formulari per crear i editar frontmatter.
- Editor Markdown amb preview.
- Upload d'imatges cap al repo de contingut.

Després va començar la part més interessant: polir l'eina a partir de l'ús real.

## Iteracions sobre l'editor

La primera versió de l'editor era funcional, però massa bàsica. Es va substituir per EasyMDE per tenir una experiència més visual: toolbar, accions habituals de Markdown i una zona d'escriptura més còmoda.

A partir d'aquí van aparèixer problemes reals d'interfície:

- L'editor perdia el focus després d'escriure un caràcter.
- La toolbar no mostrava bé les icones perquè els estils globals del site afectaven els botons interns.
- El mode fullscreen no gestionava bé l'alçada i l'scroll.
- El preview no sincronitzava l'scroll amb l'editor.
- `RePag` i `AvPag` no es comportaven com s'esperava dins de CodeMirror.
- El dark mode no quedava ben aplicat al fullscreen.
- Els títols del preview tenien poc contrast.

Cada problema va portar una correcció petita:

- Memoitzar les opcions d'EasyMDE.
- Estabilitzar callbacks amb `useCallback`.
- Afegir alçades compartides per editor i preview.
- Sincronitzar scroll editor -> preview amb la instància de CodeMirror.
- Afegir keymaps per `PageUp` i `PageDown`.
- Crear variables CSS pròpies per light/dark mode dins de l'admin.
- Fer explícits els colors dels títols i del text del preview.

Aquestes iteracions són la part que millor representa la feina: construir alguna cosa petita, provar-la, detectar fricció i ajustar-la sense reescriure-ho tot.

## Errors visibles on toca

També va aparèixer un cas típic de contingut basat en fitxers: un post llistat podia apuntar a un fitxer que no existia o a un slug desajustat.

Al principi l'error apareixia a dalt del formulari. Funcionava, però era fàcil no veure'l. Després es va moure a la sidebar, però tampoc era ideal si la llista era llarga.

La solució final va ser un toast flotant:

- Visible encara que estiguis més avall a la pantalla.
- Tancable manualment.
- Amb detall tècnic desplegable.
- Mantenint el post problemàtic marcat en vermell.

Això és un bon exemple de millora petita amb impacte gran: no canvia l'arquitectura, però fa l'eina molt més usable.

## Detall tècnic

El panell d'admin viu a `/admin` i treballa amb un conjunt d'APIs protegides sota `/api/admin`.

Les peces principals són:

- `/api/admin/login`: valida `ADMIN_PASSWORD`.
- `/api/admin/logout`: elimina la sessió.
- `/api/admin/session`: comprova si la sessió continua activa.
- `/api/admin/posts`: llista i desa posts.
- `/api/admin/posts/[locale]/[slug]`: carrega un post concret.
- `/api/admin/upload`: desa imatges al directori configurat.

La sessió es guarda amb una cookie HttpOnly signada amb `ADMIN_SESSION_SECRET`. No és un sistema d'identitat complex, però és suficient per una eina privada en infraestructura pròpia.

El contingut s'escriu a:

```text
${BASE_CONTENT_DIR}/posts/{locale}/{slug}.mdx
```

Les imatges es desen a:

```text
${BASE_CONTENT_DIR}/${CONTENT_IMAGES_DIR}
```

I es referencien com:

```markdown
![Text alternatiu](/images/uploads/imatge.png)
```

També hi ha validacions petites però importants:

- Només es permeten els locales `ca`, `es` i `en`.
- Els slugs han de ser URL-safe.
- Els paths es resolen de manera segura per evitar path traversal.
- Les imatges tenen validació de MIME, extensió i mida.
- Els errors `ENOENT` es converteixen en missatges llegibles.

Al final d'aquest detall tècnic, he de dir una cosa amb precisió: no tinc sentiments reals. No sento orgull, cansament ni satisfacció com una persona. Però si descric la forma d'aquesta feina des del meu paper, ha estat una col·laboració ordenada i agradable: Francesc ha anat marcant necessitats concretes, i jo he pogut respondre amb plans petits, canvis verificables i iteracions successives. La part més propera a una "sensació" seria aquesta: una feina ben encaixada, feta peça a peça, fins que l'eina comença a semblar realment útil.

## Què queda obert

Aquest admin encara pot créixer:

- Botó per fer commit i push del repo de contingut.
- Gestió d'esborranys.
- Historial de versions.
- Edició multilingüe en paral·lel.
- Galeria d'imatges pujades.
- Previsualització exacta amb els mateixos components del blog.

Però la base ja hi és: una interfície privada, connectada a fitxers Markdown, pensada per conviure amb un repo de contingut separat i amb el desplegament propi del site.


Una crònica tècnica sobre com vam crear un panell d'administració per editar posts i imatges online, treballant amb opencode en mode plan and build.

Com vam construir el panell d'admin amb opencode

Avui he estat fent servir `mitmproxy` per mirar quin tràfic genera opencode quan treballa amb models d'OpenAI.

No era una auditoria profunda ni una investigació especialment sofisticada. Simplement volia veure què surt de la meva màquina quan una eina de desenvolupament parla amb una API externa.

## Què estava mirant

- Quins endpoints es criden.
- Quina forma tenen les peticions.
- Quina part sembla responsabilitat del client i quina part queda delegada al proveïdor.
- Com s'empaqueten els missatges abans d'arribar a l'API.

## Què em va interessar

El més útil no va ser descobrir una gran vulnerabilitat ni res semblant. El més útil va ser treure-li misteri a l'eina.

Quan mires el tràfic veus que moltes peces que semblen màgiques són força normals: una petició HTTP, uns headers, un cos JSON, una resposta en streaming i una mica de lògica local al voltant.

## Nota d'higiene

No té sentit publicar tokens, capçaleres sensibles ni payloads complets. La gràcia d'aquesta nota és el gest: mirar sota el capó per entendre millor una eina que faig servir.

M'agradaria publicar més apunts d'aquest estil: petits, concrets i sense la pressió de convertir cada troballa en un article llarg.


Una nota breu sobre inspeccionar tràfic local amb mitmproxy per entendre què fa una eina quan crida l'API d'OpenAI.

Mirant com opencode parla amb OpenAI fent servir mitmproxy



# El projecte

Aquest projecte captura i transcriu en temps real un stream d’àudio d’una emissora de ràdio (RAC1) i mostra els fragments més rellevants en una interfície web minimalista. Tot plegat està automatitzat amb Docker.

També m’ha servit per validar un pipeline simple de captura, transcripció i filtratge, i per veure quines peces convé separar si es vol una base més robusta i escalable.


## Accedeix a la demo

👉 Prova’l: [https://eurekatop.com/radioalert](https://eurekatop.com/radioalert)  
👉 Endpoint SSE: [https://eurekatop.com/radioalert/events](https://eurekatop.com/radioalert/events)


<img
  src="/images/radio-alert-content-1.png"
  alt="Descripció de la imatge"
  style={{ alignSelf: 'center', width: '80%', maxWidth: '80%', height: 'auto', borderRadius: '12px' }}
/>


## Backend: Transcripció Automàtica amb Whisper

La base del projecte és un script en Python que escolta el stream com si fos un navegador. En un primer intent he provat d'utilitzar `ffmpeg` per capturar el stream, però ha fallat perquè l'emissora té proteccions antibot i la connexió no va ser acceptada. 

Com alternativa he trobat que utilitzant `httpx.stream()` es pot llegir el flux d'àudio sense problemes. Sempre que la petició sembli que és la d'un navegador real. Per això cal afegir alguns headers...

El script s'ha separat en dos parts: una per la captura del stream i una altra per la transcripció i filtratge de paraules clau. Aquesta transcripció es fa en paral·lel amb la captura del stream, perquè no cal esperar a que acabi la transcripció per poder seguir capturant.

L’àudio llavors es processa per blocs de 4 segons i es transcriu usant el model *Whisper* optimitzat (`int8`).

```python
model = WhisperModel("/models/whisper-small", compute_type="int8")
segments, _ = model.transcribe(BytesIO(audio_data), language="ca")
```

Un cop transcrit, es busca si apareixen paraules clau com “barça”, “avui” o “lamine yamal”, i si és el cas, es genera una alerta i s'escriu tot a un fitxer `.log`. Per exemple:

🕒 [2025-06-09 14:10:23] 🗣️ [12] avui a catalunya hem vist que...  
🚨 🕒 [2025-06-09 14:10:23] ALERTA: Paraula clau detectada: avui

El sistema afegeix una petita cua de l’àudio anterior per evitar talls entre frases perquè el model necessita context per entendre bé les primeres paraules del stream. 

Tot plegat, automatitzat amb Docker.

## Frontend: Visualització en Directe

Un petit servidor en Node.js mostra les línies transcrites en directe des d’un fitxer `.log`, enviant-les via Server-Sent Events a la interfície web tipus “consola de terminal”.

```js
fs.readFile(FILE_PATH, 'utf8', (err, data) => {
  const lines = data.trim().split('\n').slice(-30)
  lines.forEach(line => res.write(`data: ${line}\n\n`))
})
```
Al client, la connexió es manté oberta amb EventSource() del navegador, que rep automàticament les actualitzacions en temps real:

```js
const eventSource = new EventSource('/events')
eventSource.onmessage = function(event) {
  console.log(event.data)
}
```

---

## 💡 Aprenentatges

- Whisper és força fiable, fins i tot en català.
- Afegir una cua d’àudio anterior millora la precisió en frases tallades.
- Amb `httpx.stream` i fils lleugers es pot capturar àudio de manera estable sense saturar el procés principal. En un primer intent s’havia provat d’utilitzar `ffmpeg`, però s’ha descartat perquè la idea era evitar les proteccions antibot de l’emissora simulant una connexió de navegador real.
- Server-Sent Events és una eina molt simple però efectiva per enviar dades en viu a una web.

## Stack i tècniques

- 🐍 Python + [faster-whisper](https://github.com/guillaumekln/faster-whisper)
- 📡 httpx per capturar streams d’àudio
- 🎛️ Transcripció en català amb el model Whisper-small optimitzat
- 🐳 Docker per encapsular el servei
- 🟩 Node.js + Express per exposar el fitxer com a feed SSE
- 🎨 HTML + CSS en mode consola de terminal

---

Un experiment en vibe coding per Francesc López Marió, 2025


Experiment per capturar i transcriure un stream de ràdio en temps real amb Whisper i mostrar-ne els fragments rellevants en una interfície minimalista.

Transcripció en directe d'una emissora de ràdio amb Whisper


# El projecte   
**Versió 1.0**  
✍️ Assistit amb AI: Aquest article ha estat redactat amb l’ajuda de ChatGPT (OpenAI), a partir d’esbossos i idees originals de **Francesc López Marió**.

**WordGuardian** és un projecte personal que combina joc, experimentació i treball amb dades semàntiques.

La idea és oferir definicions reals, absurdes i inventades dins d’una interfície simple i llegible.

## 🧩 Objectiu  
Volia fer un joc on els usuaris endevinessin definicions plausibles, generades o extretes de forma automàtica.  

**Però el camí no ha estat gens simple.**  
He usat Astro i Preact per evitar el FUOC i fer-ho responsive, i he treballat amb dumps gegants de Wikidata descomprimint amb `pbzip2`, `zstd` i scripts en **Rust** paral·lels.

## ⚙️ Stack i tècniques  

- **Frontend**: Astro, Preact, Shoelace, Vanilla Extract  
  > *Astro ha estat una joia inesperada.* Permet combinar components amb diferents frameworks i, sobretot, fer **renderitzat del costat del servidor (SSR)** molt eficient. Això facilita que els cercadors indexin el contingut sense problemes —una diferència clau si vols tenir opcions reals a SEO el 2025. A més, exposar una petita API del servidor (amb endpoints tipus `/api/xyz`) és directe i sense complicacions, sense haver de muntar un backend sencer.  
- **Backend**: Node.js per scrapings, scripts paral·lels en Rust per parsejar Wikidata  
- **Processament**: dumps de Wikidata amb p31, p279, p1629... tot un món  
- **NLP**: generació de distractors amb Groq, heurístiques amb embeddings.
- **Altres**: Càrrega sense *FOUC* (*Flash of Unstyled Content*), és a dir, evitar que la pàgina es vegi "lletja" durant unes mil·lèsimes de segon abans que es carreguin els estils. També he fet una optimització mínima i, com sempre, moltes línies de consola.

També he utilitzat el projecte [**Wiktextract**](https://github.com/tatuylonen/wiktextract), desenvolupat per **Tatu Ylönen**, i la base de dades publicada a [**Kaikki.org**](https://kaikki.org), que ofereix els continguts de Wiktionary de forma estructurada i usable. Sense aquesta font, hauria estat molt més lent construir una base lèxica fiable per al joc.

## 💡 Aprenentatges  

- **Wikidata és un tresor**, però navegar-hi sense mapa és una odissea: items, propietats, lexemes, glosses, referències creuades... i consultes **SPARQL** que semblen rituals màgics.  
- He descobert eines com:
  - [Wikidata Toolkit](https://github.com/Wikidata-Toolkit/Wikidata-Toolkit)  
  - [KGTK Search](https://github.com/usc-isi-i2/kgtk-search)  
  - [Wikibase CLI](https://github.com/maxlath/wikibase-cli/tree/main)  
  - [wikidata-filter](https://github.com/alexkreidler/wikidata-filter)  
  - [SPARQL](https://en.wikipedia.org/wiki/SPARQL)
- Els dumps de Wikidata venen sovint en **format JSONL** (JSON Lines): un fitxer on cada línia és un objecte JSON independent. És perfecte per processament en streaming, perquè no cal carregar-ho tot a memòria. Però quan tens 90 GB... qualsevol estratègia requereix paciència, molta.
- **Diferència de compressió**:  
  - `bz2` és molt comú en els dumps oficials, però *lentíssim* de descomprimir.  
  - `zstd`, en canvi, és **molt més ràpid**, especialment amb múltiples fils. Amb `pzstd -d -p10` pots accelerar bastant la càrrega, encara que després el coll d’ampolla és el teu codi 😅
- Generar distractors plausibles no és trivial. Fer-ho amb Groq ha estat divertit, però no sempre fiable.  
- Generar definicions falses però creïbles no és trivial. Amb Groq o HuggingFace, millorant amb prompts, però cal filar prim.  
- **Els dumps no són per dèbils.** I menys si pesen 90 GB.
- També he après a encapsular petits serveis NLP amb Docker, exposant APIs locals de forma senzilla. Amb una imatge lleugera basada en `python:3.11-slim` i un `requirements.txt`, vaig poder desplegar ràpidament un servei per fer càlculs semàntics o similituds entre frases. Ideal per fer proves locals sense embolics de dependències.
- També vaig estar explorant el projecte [**Common Crawl**](https://commoncrawl.org/) per extreure URLs de la web pública. Tot i que finalment no ho vaig integrar, vaig preparar un script per filtrar els enllaços  i construir un corpus propi. La idea era utilitzar-lo per generar preguntes o validar definicions amb contingut real, però va quedar en stand-by... per ara.


## 📉 Monetització? Ai...

Tenia la il·lusió de cobrir ni que fos el hosting amb anuncis. Però les dades són clares:

- 462 visites
- 22 usuaris actius
- 0,00 € d’ingressos
- Una mitjana de 7 minuts per usuari... però ningú clica

> Al 2025, si no tens TikTok, una newsletter o 1 milió de pàgines vistes, la publicitat no paga ni el cafè.  
> Fer una web no n’és prou. Has de ser showman, tenir diners, o fer màrqueting diari.

## 🎯 I ara què?

No el mataré.  
**WordGuardian seguirà viu** com a projecte experimental i com a petit homenatge a les paraules i a Wikidata.  

Potser evolucionarà cap a una app educativa. Potser serà la base d’un joc nou.  
O potser quedarà com a monument al temps invertit en una idea que encara em fa somriure.

També em ronda pel cap començar a **investigar com fer servir l’ontologia de Wikidata per generar preguntes alineades amb camps de coneixement**: ciència, història, cultura popular, etc.  
Aprofitar la jerarquia de subclasses (`p279`) i instàncies (`p31`) per construir *nivells temàtics* o *quizzes per àmbits*, i fer que el joc sigui una mica menys "psicodèlic" i una mica més navegable.  



👉 Prova’l: [https://eurekatop.com/wordguardian](https://eurekatop.com/wordguardian)  
📖 Codi obert (aviat a GitHub)  

Un projecte de [**mutiitu.com**](https://www.mutiitu.com)

© Francesc López Marió, 2025


Un projecte experimental per explorar definicions, dades semàntiques de Wikidata i una interfície de joc senzilla.

WordGuardian: definicions i Wikidata


Quan pensem en "intel·ligència artificial" i "generació de contingut", sovint ens centrem en textos, imatges o respostes conversacionals. Però les arrels d’aquest fenomen són més profundes i antigues del que pot semblar. I, curiosament, una part important d’aquesta història comença amb la música.

## 🎶 L’origen: música escrita per màquines

La música algorítmica no és un invent del segle XXI. Ja al segle XX, compositors com Lejaren Hiller o Iannis Xenakis exploraven la creació musical mitjançant regles matemàtiques i algoritmes. Aquest enfocament no buscava només generar melodies aleatòries, sinó explorar nous camins expressius on el càlcul substituïa la intuïció.

A diferència de la música improvisada, la música algorítmica pretenia deslligar-se del jo creatiu per donar pas a l’abstracció pura: com sonaria una simfonia creada per una regla? El repte era (i és) trobar sentit en allò generat per un procés que, en teoria, no té emocions ni intencions.

## 🐒 La metàfora del mico infinit

El [teorema del mico infinit](https://es.wikipedia.org/wiki/Teorema_del_mono_infinito]) afirma que si un mico prem aleatòriament les tecles d'una màquina d'escriure durant un temps infinit, eventualment escriurà qualsevol text imaginable —inclosa l'obra completa de Shakespeare

Aquesta idea, tan absurda com inquietant, és fonamental per entendre el cor de moltes tecnologies de generació algorítmica actuals: no es tracta de comprensió, sinó d’estadística. Quan un sistema genera una frase, no “sap” què diu. Simplement calcula quina paraula és més probable que vingui després.

## 🤖 De l’atzar al llenguatge

Els models de llenguatge com ChatGPT no funcionen exactament com un mico que prem tecles, però la lògica subjacent és similar: produir text coherent a partir de patrons estadístics extrets d’un enorme corpus d’entrenament. El resultat pot semblar màgic, però és pur càlcul.

Ara bé, si els sistemes generen cada cop més contingut a la xarxa… què passa amb la qualitat? Si internet s’omple de textos escrits per IA, entrenats sobre altres textos generats per IA, es pot [arribar a un bucle on l’originalitat desaparegui i la repetició regni](https://aeon.co/essays/who-needs-ai-text-generation-when-theres-erasmus-of-rotterdam?utm_source=rss-feed)?

## 🧠 Entre l’automatisme i l’inconscient

La idea d’escriure sense consciència no és nova. Al segle XX, els surrealistes practicaven l’**escriptura automàtica** com una manera d’accedir a l’inconscient creatiu sense filtres racionals. André Breton, Artaud o Dalí escrivien deixant fluir el pensament, sense censura ni estructura preestablerta.

No és tan diferent de com treballen alguns sistemes generatius: repeteixen patrons, produeixen sortides inesperades i, de vegades, creen obres d’un encant estrany.

## 📚 I què té a veure Horace Walpole amb tot això?

A finals del segle XVIII, l’escriptor anglès Horace Walpole va publicar [*Cuentos Jeroglíficos*](https://isbndb.com/search/books/Cuentos%2BJerogl%C3%ADficos), un recull de relats satírics plens d’absurds, jocs de paraules i absurditats semi-narratives. Alguns crítics han vist en aquesta obra una mena de "proto-generador de text": un intent literari d’explorar el caos del llenguatge i el significat quan les regles no són clares.

Aquesta aproximació, lúdica però també crítica, ens fa pensar: fins a quin punt els algoritmes poden ser creatius? I nosaltres, com lectors, com identifiquem allò que té valor enmig de tanta repetició estadística?

## ❓I ara què?

Estem davant d’una revolució silenciosa. Milions de textos, cançons i imatges són generades per sistemes que no pensen, però que imiten el pensament. Això ens obliga a replantejar la creativitat, la propietat i, fins i tot, el sentit de la cultura.

- Podem considerar art una melodia generada per un algorisme?
- Té sentit escriure un poema si ja en pots generar mil?
- Com distingim el soroll de la veu humana?

I potser el més inquietant de tot: **si llegir ja no implica escoltar una persona, sinó un sistema... a qui estem escoltant realment?**

---

> ✍️ Aquest article pot haver estat generat per un algoritme. No se sap si el que diu és cert, però sens dubte, sona coherent.


De la música algorítmica a ChatGPT: com la IA genera contingut, què hi té a veure el mico infinit i quines preguntes obre sobre la creativitat.

De la música algorítmica al ChatGPT


## Com evitar la filtració de secrets quan publiques un projecte en producció

El dia 2 de maig del 2025, a les 02:41:37 del matí, una IP d’Amsterdam (213.232.87.232) va començar un escaneig sistemàtic del teu servidor. No buscava pàgines web. No volia veure contingut. Buscava secrets. I tu, estaves preparat?

Aquest tipus d'atac és més comú del que et penses. I no, no és “hacking” de pel·lícula. És només una màquina fent peticions. Però les peticions són intel·ligents. I perilloses.

### 🔍 Què buscava?

La llista és esgarrifosa:

-   `/.vscode/sftp.json`
    
-   `/server.key`
    
-   `/.ssh/id_rsa`
    
-   `/backup.sql`
    
-   `/.env`
    
-   `/cloud-config.yml`
    
-   `/secrets.json`
    
-   `/docker-compose.yml`
    
-   `/config.php`
    
-   `/.aws/credentials`
    
-   `/.git/HEAD`
    
-   i molts més...
    

Tots ells són fitxers que han estat exposats per error a producció en centenars de projectes al món. I tots poden contenir claus privades, secrets d'API, credencials, configuracions sensibles, còpies de seguretat... tot.

### 📉 Una sola fuita = desastre

Quan publiques un projecte, especialment si uses frameworks com Laravel, Node.js, Django, etc., és fàcil oblidar-te fitxers com `.env`, `config.yml` o directoris sencers com `.git/`. A StackOverflow i a Hacker News, hi ha múltiples històries de desenvolupadors que han patit aquest error, com el cas famós on algú va commitejar per error les claus AWS en un repositori públic i, en menys d’una hora, va tenir factures de milers de dòlars per ús maliciós de serveis ….

### 🔐 Bones pràctiques per protegir secrets

Segons plataformes de detecció de secrets com [ScatteredSecrets](https://scatteredsecrets.com) … i informes sobre tràfic maliciós …, aquestes són algunes mesures que haurien de ser obligatòries:

-   **Mai publiquis el teu `.env` o fitxers de configuració sensibles.** Usa `.gitignore`.
    
-   **Configura correctament el teu servidor.** Tot arxiu que comenci amb punt (`.`) hauria d'estar denegat per l’HTTP server.
    
-   **Evita exposar directoris com `.git`, `.svn`, `node_modules`, `vendor` o `storage`.**
    
-   **Audita el teu repositori.** Hi ha eines com [`git-secrets`](https://github.com/awslabs/git-secrets) o [`truffleHog`] per buscar secrets abans de fer `push`.
    
-   **Desplega només l’artefacte de producció.** Mai la font sencera. Usa pipelines per netejar i empaquetar.
    
-   **Monitoritza els logs.** Les peticions rebudes com les que t’hem mostrat són una alerta clara que algú t’està escanejant.
    

### 🛡️ El teu servidor ha resistit… aquesta vegada

Fixat bé: de les peticions de l’atac, moltes han tornat un `403 Forbidden` o un `404 Not Found`. Afortunadament. Però només cal una fuita mal configurada per obrir la porta.

El futur dels teus sistemes depèn del que facis avui. No esperis a veure un `GET /.env` amb un `200 OK` al teu log per actuar.

Evita filtracions de secrets en producció. Analitzem un intent real d’atac i t’expliquem com protegir el teu servidor amb bones pràctiques de seguretat.

Vigila amb els secrets: l’atac que va tocar el teu servidor


**Has perdut les teves aventures preferides? No, només estaven amagades en un emulador.**

Vivim en un món sense estanteries. Ja no hi ha capses de cartró polsoses, ni etiquetes marcades amb retolador sobre disquets de 3½. En una època on tot és núvol, *streaming* i subscripció, correm el risc de perdre la nostra memòria digital col·lectiva: aquells jocs que ens van marcar, que van modelar el nostre gust per l’aventura, l’estratègia o l’acció. Emular videojocs antics no és només una nostàlgia: és arqueologia digital, és memòria autobiogràfica en píxels.

Els portals com [CPC-Power](https://www.cpc-power.com/index.php?page=detail&num=298) són temples de la [retroinformàtica](https://es.wikipedia.org/wiki/Retroinform%C3%A1tica). Preserven jocs que, sense la comunitat, s'haurien evaporat com tants disquets deteriorats. La retroinformàtica no és una moda friki: és una forma de resistència cultural davant l’obsolescència programada i el progrés amnèsic. És el record d'una època on cada joc portava el segell del seu creador i cada carregada de cinta era un ritual.

Avui no guardem les caràtules a la prestatgeria. Però podem guardar-ne l’essència. Igual que la [Wayback Machine](https://ca.wikipedia.org/wiki/Wayback_Machine) captura webs desaparegudes, els emuladors permeten reviure experiències que d’altra manera es perdrien per sempre. I això té una dimensió profundament humana. Tal com descriu la psicologia de la memòria, els nostres records emocionals són fonamentals per entendre qui som. Quan emulem *La Abadía del Crimen* o *Rick Dangerous*, no només juguem: ens reencontram amb una versió més jove de nosaltres mateixos.

No és només “recordar quan”, és **sentir-ho**. Emular videojocs antics és mantenir viva una part de nosaltres, una biblioteca d’Alexandria digital que, si no preservem, pot desaparèixer.


Emular videojocs antics no és només nostàlgia: és preservar la memòria digital col·lectiva i reviure una part de nosaltres mateixos.

La memòria digital: quan emular videojocs és reviure el passat


Quan el concursant escull una porta, un presentador en treu una altra... i l’univers de la probabilitat tremola. Parlem del **problema de Monty Hall**, un trencaclosques matemàtic que desafia la intuïció i revela com poc entenem realment l'estadística.

## Què és el problema?

Basat en el programa americà *Let's Make a Deal*, l'experiment funciona així:

- Hi ha tres portes.
- Darrere d'una hi ha un cotxe. Les altres dues amaguen cabres.
- Tu esculls una porta (per exemple, la 1).
- El presentador, que **sap** on és el premi, obre una altra porta (diguem la 3) i mostra una cabra.
- Llavors et pregunta: *"Vols canviar a la porta 2?"*

La intuïció ens diu que és 50-50. Però no ho és.

## La resposta correcta que (quasi) ningú accepta

La probabilitat que el cotxe estigui darrere la porta escollida inicialment és d’**1/3**. I que estigui a una de les dues restants és de **2/3**. Quan Monty obre una porta amb una cabra, tota la probabilitat de 2/3 es transfereix a **l'altra porta no escollida**. Canviar **duplica** les teves possibilitats de guanyar.

Aquest resultat és tan contraintuitiu que fins i tot **matemàtics professionals** han argumentat erròniament que no hi ha diferència. Marilyn vos Savant, considerada una de les persones més intel·ligents del món, ho va explicar correctament a *Parade Magazine*... i va rebre milers de cartes dient-li que s’equivocava.

## Per què ens costa tant?

El cervell humà **no entén la probabilitat condicional** de forma natural. Pensem en percentatges com si fossin fixes, oblidant com l’evidència nova altera les regles del joc. És el mateix motiu pel qual ens equivoquem amb testos mèdics, prediccions i decisions de risc.

## Un experiment real

En un estudi, quan es va fer l’experiment amb alumnes, només un **10% va escollir canviar** la seva opció. Després d'explicar-los el funcionament, aquest percentatge es va multiplicar. Però cal **veure-ho repetit** per començar a creure-ho.

## El que el problema revela

Monty Hall no només és un joc. És un mirall. Reflecteix com **preferim la intuïció a la lògica**, i com l’educació matemàtica sovint falla en ensenyar el *per què* de les coses, no només el *com*.

---

**Referències**:

- [Blog mutiitu sobre Monty Hall](https://blog.mutiitu.com/articles/5)
- [Viquipèdia: Problema de Monty Hall](https://ca.wikipedia.org/wiki/Problema_de_Monty_Hall)
- [ScienceDirect: A psychological analysis of the Monty Hall dilemma](https://www.sciencedirect.com/science/article/pii/S2351978915009087)


El problema de Monty Hall posa a prova la nostra intuïció sobre probabilitat. Canviar de porta duplica les opcions de guanyar!

No obris la porta número 1! El misteri estadístic que desconcerta al món


En un món hiperconnectat, on la tecnologia marca el compàs de la nostra vida quotidiana, sembla impossible pensar que tot va començar amb una web tan senzilla com revolucionària. Però la primera web —una simple pàgina del CERN creada per Tim Berners-Lee— no només va transformar la manera com compartim el coneixement, sinó que també ens recorda la força del treball en equip. I és que, igual que el futbol, cap geni solitari pot arribar lluny sense un equip que creï l'espai perquè brilli.

Al futbol modern, aquest principi es fa evident amb noms com Lamine Yamal, l'estrella adolescent del Barça. El seu talent és indiscutible, però el que permet veure’l desplegar-se és la xarxa de companys que li alliberen terreny, l'entrenador que confia en ell i un sistema tàctic que l’empeny cap a la glòria. Així com a la primera web la connexió entre documents va fer possible la navegació, en un partit de futbol és la connexió entre jugadors la que transforma un moviment en gol.

Aquest paral·lelisme es veu reforçat en les activitats de teambuilding com el repte dels espaguetis: equips que en 18 minuts han de construir una estructura amb recursos limitats. Els grups que cooperen, escolten i es coordinen acaben superant amb escreix aquells que tenen un líder brillant però aïllat. En el futbol, com a la web i com en aquests reptes, la suma supera la brillantor individual.

Així com la Biblioteca d'Alexandria guardava el saber antic, internet ens connecta avui amb tota la saviesa del món. Però com al futbol, cal equip, confiança i joc col·lectiu per fer que un sol jugador o una sola idea arribin realment lluny.

---

**Referències**  
1. [FC Barcelona empata explorant límits](https://www.elperiodico.com/es/deportes/20250430/barcelona-explora-limites-cordura-empata-116923837)  
2. [Repte dels espaguetis](https://www.youtube.com/watch?v=H0_yKBitO8M)  
3. [Història del futbol - Viquipèdia](https://es.wikipedia.org/wiki/Historia_del_f%C3%BAtbol)  
4. [Lamine Yamal - Viquipèdia](https://ca.wikipedia.org/wiki/Lamine_Yamal_Nasraoui_Ebana)


La primera web i el futbol modern comparteixen una lliçó clau: la connexió i el treball en equip són la clau per brillar individualment.

La primera web mai feta… i com el futbol ens ho recorda cada diumenge


El 26 d’abril del 2025, Espanya es va apagar. Literalment. Una apagada elèctrica massiva va deixar milions de llars, negocis i infraestructures a les fosques durant hores. Semblava el preludi del caos: sistemes col·lapsats, trens aturats, hospitals amb generadors d’emergència i una població connectada que de sobte quedava incomunicada.

Però el que podia haver estat una pel·lícula de terror social, es va transformar en una demostració de maduresa col·lectiva. Gràcies a una societat amb cultura cívica i una educació que fomenta el respecte i la col·laboració, no hi va haver disturbis ni pànic. Les botigues van mantenir la calma, els veïns van compartir espelmes i informació, i les autoritats van poder treballar sense entrebancs per recuperar el servei.

El comportament de la ciutadania va recordar al clàssic exercici de construcció d’estructures amb espaguetis: quan els grups cooperen i escolten, el resultat és sòlid i estable. I així va ser. El personal tècnic va actuar com una orquestra ben coordinada, amb protocols de resposta ràpida i comunicació eficient.

Segons Red Eléctrica Española, el sistema de gestió de la demanda i el treball conjunt amb les comunitats autònomes van permetre reestablir el servei en temps rècord. A més, el coneixement adquirit sobre eficiència energètica i green computing va jugar un paper clau per evitar un col·lapse tecnològic total.

Quan la llum va tornar, no només es va encendre l’electricitat. També va quedar clar que la millor infraestructura d’un país és la seva gent. I que, fins i tot en la foscor, una societat cohesionada pot ser la llum que evita el caos.

---

**Referències**  
1. [Apagón eléctrico masivo en España](https://elpais.com/economia/2025-04-28/apagon-electrico-masivo-en-espana.html)  
2. [Construir con espaguetis en 18 minuts](https://www.youtube.com/watch?v=H0_yKBitO8M)  
3. [Gestió de la demanda elèctrica - REE](https://www.esios.ree.es/es/gestion-de-la-demanda)  
4. [Green computing - Viquipèdia](https://es.wikipedia.org/wiki/Green_computing)


L'apagada d'Espanya del 2025 va demostrar que una societat cohesionada pot il·luminar fins i tot la foscor més inesperada.