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

## 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

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.

Categoria: ia