Escric coses

Parlem de complexitat, no de deute tècnic

2026-04-21T00:00:00+02:00

Fa poc més d'un any, estàvem fent un retir estratègic a l'empresa, i m'havia posat com a objectiu, garantir que tindríem temps i dedicació per a millorar el nostre codi. El que se'n diu pagar deute tècnic.

Tradicionalment, en la meva experiència, i pel que llegeixo en la de molta gent, el deute tècnic és molt difícil de gestionar:

És difícil d'identificar
És difícil de comptabilitzar
És difícil de comunicar
I per tant és difícil d'acomodar temps i esforç a reduir-lo.

Va coincidir que vaig llegir diversos articles (o veure vídeos - ja fa un any d'això) on parlaven d'un concepte diferent, la complexitat, que em va ajudar molt més a raonar sobre aquest tema i a comunicar-lo que no pas el concepte de deute tècnic.

Per això crec que és interessant deixar-ho clar i per escrit, per a mi i per a qui ho trobi.

Les dificultats del concepte "deute tècnic"

D'alguna forma, si tens problemes per pagar un deute, se't mira com algú que no sap gestionar els seus diners. Hi ha un estigma associat al deute:

poca planificació
poca disciplina
poca visió de futur
...

A més, la imatge mental que es té és que s'ha corregut massa i s'han fet les coses malament per arribar als terminis, i ara cal arreglar-ho.

Això fa que quan parles de deute tècnic, la gent ho vegi com un problema de gestió, i no com un problema tècnic. I això dificulta molt la comunicació amb altres departaments (producte, negoci, etc.) que no són tècnics.

Fins i tot es creu que és quelcom que l'equip tècnic ha de resoldre per si mateix, sense ajuda de ningú més, com quelcom que han d'arreglar per que no han fet bé la seva feina abans, com a penyora.

I de fet no és així. Hi ha molts motius per l'acumulació de deute tècnic. Moltes vegades per causes no pròpiament tècniques, com la impossibilitat de conèixer el problema i el mercat, a priori:

el problema original ha canviat i ara és un altre
les prioritats eren diferents
el mercat ha canviat
l'equip ha canviat
les eines han canviat
etc

Però tot això sembla simplement una llista d'excuses per no haver fet bé la feina. I aquí entra el concepte de complexitat.

Pensar en termes de complexitat

Deixem de classificar el codi en bo o dolent: no usem metàfores de deute. Hi ha codi, i en principi fa el que ha de fer.

Volem que faci també alguna altra cosa? Afegim més codi. Segurament canviem una mica el codi existent per a acomodar el codi nou. Ostres!, abans aquesta abstracció pressuposava quelcom que ara ja no és cert: cal canviar tots els llocs on s'usava. Com ho testejo, això? Mirem com ho hem solucionat en altres tests... I aquest problema justament el podríem solucionar amb la nova versió de la llibreria, però, si l'actualitzo, trencaré alguna cosa?

La complexitat ens fa anar més lents per què ens costa més raonar sobre els canvis que estem introduint. Si som capaços de mantenir-ho tot alhora en el nostre cap, podem prendre decisions molt més fàcilment, però si no podem, cada canvi es converteix en una exploració i redescobriment.

Eventualment, tot projecte de programari acaba recordant l'escena famosa de Malcom In the Middle:

Al nostre equip li costava progressar

I és que justament això és el que ens estava passant. Constantment se'ns preguntava com ens podien costar tant les coses. Durant l'any anterior havíem estat dedicant molt de temps a una app mòbil, que semblava encallar-se constantment. El que funcionava una setmana ho deixava de fer la següent.

Havíem arribat al límit de la complexitat que qualsevol membre de l'equip podia mantenir dins el seu cap.

Però era molt difícil d'entendre des de fora de l'equip. Com podia ser tan complicat tot? Al final no semblava pas que el problema que estàvem solucionant fos tan complicat.

I aquí estava una mica el quid de la qüestió.

No tota la complexitat és igual

Hi ha complexitat que és inherent al problema que intentem solucionar. Que correspon a l'àmbit de negoci, a la realitat. Aquesta és innegociable: És la complexitat essencial. Simplificar aquí seria perdre detall del problema i no seríem capaços de solucionar-lo correctament.

En canvi, hi ha complexitat que no correspon al problema en si: la complexitat accidental. Aquesta correspon a tot allò que no és el problema en si que volem solucionar:

sistema de build complex
eines massa complexes o desconegudes
base del codi que ha canviat durant el temps i és difícil de llegir
documentació que ha quedat obsoleta
aquella feature que es va fer a correcuita i és massa enrevessada
la mescla de llenguatges de programació, frameworks, llibreries i versions
...

Aquesta distinció entre complexitat essencial i accidental la va formular Fred Brooks al seu assaig clàssic No Silver Bullet (1986), on argumentava que no hi ha cap avenç tecnològic capaç de reduir la complexitat essencial d'un problema.

I és que amb un projecte d'una dècada de durada, es podia veure la història i l'acumulació de mil cosetes que ho feien tot molt complex.

Per què acumulem complexitat

Ningú té com a objectiu augmentar la complexitat accidental, és més, la complexitat, a l'hora d'introduir-la, mai sembla accidental. És quelcom que passa de forma orgànica: el cert és que en el moment d'afegir complexitat estem solucionant problemes reals que tenim al projecte, i per això no ens n'adonem.

Tal com passava amb la dificultat d'avenç de l'equip, a escala individual tota persona té un màxim nivell de complexitat que pot mantenir al seu cap. Si la complexitat del projecte n'és inferior, té un espai de complexitat vacant. Aquesta complexitat vacant és la moneda corrent que usem per a crear features i afegir coses.

No és bo ni dolent, és la forma en què funciona: mentre hi hagi espai, l'anirem ocupant. Al principi, com més espai tinguem vacant de complexitat, més ràpid anirem afegint coses i fent canvis, i això és molt valuós. Però a mesura que anem omplint tot l'espai disponible, trobar racons costa molt més.

Eventualment, quan la complexitat del projecte excedeix la capacitat de la persona, li és impossible de raonar amb claredat, i això fa que sigui quasi impossible avançar, amb perill d'acabar en un punt de no retorn, on no hi ha prou espai ni per a desfragmentar la complexitat existent.

Com ho podem solucionar?

més gent?

No serveix de res. La complexitat ens fa la punyeta de forma individual.

gent més capaç?

Podria semblar bona idea, però és encara pitjor. Gent més capaç pot tenir un límit més gran de suportar complexitat, però això només vol dir que seran capaços d'augmentar-la més, perjudicant encara més la resta de l'equip, que es veurà desbordat.

separant els problemes

Una possible forma és aquesta: divideix el que fas en dues o més parts independents. Això ajudarà molt si ho pots fer, però si ho pots fer potser és una mala senyal: per què la teva organització està fent dues coses totalment diferents? Segur que no estan relacionades?

Aquest mètode era popular durant l'auge dels microserveis: solució que va néixer per a solucionar un altre problema —l'escalabilitat de serveis gegantins de núvol— que, a més, quasi ningú no tenia. Però cada part no és al final totalment independent de les altres, obligant-se a dissenyar, negociar, mantenir, comunicar i documentar tots els punts de contacte. Suposo que si tens un exèrcit d'enginyers a la teva disposició, pot ser una opció.

reduir complexitat!

Al final, l'única sortida és simplificar. Això ho podem fer de vàries formes:

usant menys eines, més simples i més estàndards.
fent refactors de codi que eliminin excepcions i simplifiquin codi.
usant blocs de construcció que facin més coses (llibreries, frameworks) o transformant codi propi en blocs de construcció ben definits.

I, al final, explica, com va anar?

Al final, amb l'explicació de la complexitat, vaig poder definir objectius de producte de reducció complexitat, per garantir poder tenir temps per a treballar-hi. Cada setmana teníem una reunió on ens preguntàvem què era el que ens frenava, per què anàvem lents. I fèiem una llista de les coses que volíem canviar.

Després prioritzàvem aquesta llista amb una taula RICE i a cada Sprint proposàvem d'atacar algun ítem de la llista de les primeres posicions. Una de les coses més grans que vam fer va ser fer la transició de Bazel a un monorepo organitzat amb uv i pnpm, ja que, al final, tenir shell scripts coordinant les eines de build tenia menys complexitat que entendre Bazel i mantenir-lo...

Finalment, vam poder recuperar les regnes del projecte. Vam sortir de l'espiral en la que ens trobàvem.

Té sentit tot això en l'era de la IA?

La IA ens ajuda a operar en una complexitat molt major a la que teníem fins ara. Llavors, ens hem de preocupar de reduir la complexitat, realment?

Ja escrivia anteriorment que podem pagar el deute tècnic amb la ia, i així ho hem de fer! I de fet no només ho hem de fer per a nosaltres, sinó també per a la IA!

La IA té el mateix problema que nosaltres en termes de límit de complexitat, i hem d'estar vigilants que no se'ns en vagi de les mans, per què llavors ens serà molt més difícil sortir a rescatar la IA d'aquesta nova complexitat que va més enllà dels nostres límits.

Així que la meva recomanació més recent és fer cas de l'olfacte: cada vegada que veiem quelcom que fa mala olor, cada vegada que ens diem a nosaltres mateixos "això hauria de ser una llibreria genèrica" o "tots aquests warnings ens petaran als nassos en algun moment", afegir-ho a una llista. I constantment treballar per reduir aquesta llista amb l'ajuda de la IA, en background.

Per què realment la IA ens accelera, i sembla ser molt més ràpida que nosaltres en afegir complexitat accidental, si no la lliguem curt, si no som exigents i perfeccionistes.

Paga el deute tècnic amb IA

2026-03-13T15:55:00+01:00

Ja comentava a l'article anterior que l'economia de la programació ha canviat radicalment amb els agents de codi. I això també ha afectat el deute tècnic.

Definim el deute tècnic com tot allò que sabem que hem de canviar, que ens fa anar més lents, que augmenta la complexitat; però que l'usuari no veu, i per tant és difícil de justificar el temps que cal invertir-hi.

No em centraré en el deute tècnic avui (ja tinc un article a mitges sobre això). El que vull és parlar de com els agents de codi ens poden ajudar a pagar-lo, amb un exemple pràctic: portar el nostre programari més antic —Mapping Tool— de Mac Intel a Apple Silicon.

El deute que vaig contraure

Durant el màster i el doctorat, m'interessava molt l'art digital i la programació creativa. El que estava de moda en aquells cercles era openFrameworks, un framework que feia fàcil la creació d'aplicacions interactives en C++. M'hi vaig llançar de cap: el feia servir en les pràctiques dels meus estudiants i en projectes del màster i del doctorat.

Quan vaig començar a treballar en el programari que més tard es convertiria en Mapping Tool, naturalment el vaig fer en c++ i openFrameworks. I en el moment va ser una bona elecció: ens va permetre crear ràpidament solucions que podíem iterar molt ràpidament.

I, de fet, per a poder iterar més ràpidament encara i fer-lo més flexible, hi vaig encastar el runtime de python exposant-hi tot openFrameworks. Així, els usuaris -nosaltres, en aquell moment- podíem crear nous continguts luminics interactius sense haver de tocar c++, de forma dinàmica.

En aquell moment no ho sabia, però acabava de contraure un deute tècnic que m'aniria perseguint durant els següents anys: la filosofia de openFrameworks era de trencar la seva API interna sense por, i jo em veia atrapat a una versió concreta d'openFrameworks, però no trencar tot el codi d'usuari que podia estar corrent a casa dels clients.

Per més complicació, openFrameworks venia amb una sèrie de llibreries de tercers pre-compilades, en versions específiques amb pedaços dels propis autors de oF. Només poder navegar la compatibilitat amb els canvis dels compiladors (com el position independent code a linux) ja era un maldecap: vam acabar mantenint un fork privat de oF on hi anàvem aplicant els pedaços que necessitàvem perquè el Mapping Tool seguís funcionant.

No es pot tirar sempre la pilota endavant

A poc a poc, vam anar perdent l'habilitat de compilar Mapping tool en les nostres màquines personals: al principi per tenir versions massa noves del Sistema Operatiu, i després per tenir una arquitectura totalment diferent: Apple silicon, basada en ARM. Però a tot problema s'hi troba una solució, en el nostre cas, mantenir un mac mini antic amb mac intel com a builder.

I el que semblava simplement un inconvenient constant, però portable, es va convertir de cop en un gran problema: Apple va anunciar que deixaria de donar suport a mac intel. A partir d'algun release del proper any, el Mapping Tool no funcionaria a les màquines dels clients. I estavem atrapats amb un framework i llibreries de fa més de 10 anys, algunes discontinuades, sense suport per a un maquinari que encara no existia.

Així que ja teniem una data límit. Però podiem permetre'ns dedicar tant d'esforç a una cosa que no generava valor nou? Per als usuaris, que el programari segueixi funcionant és quelcom que es presuposa. No podíem tornar al cap d'un any dient "Us portem la nova versió de Mapping tool, amb exactament les mateixes capacitats i mancances, però que continua funcionant".

A més a més, per la situació de la companyia i el roadmap que havíem de tirar endavant, resultava clar que continuaríem tirant la pilota endavant fins a l'últim moment, tret que trobéssim una solució imaginativa que ens permetés d'avançar sense comprometre el nostre roadmap.

Codex al rescat

Començo a investigar amb Codex quina seria la forma moderna de gestionar les llibreries. La idea era que si podia substituir les llibreries pre-compilades per altres que es poguessin compilar en ARM, podria compilar tot el binari per Apple Silicon. I per a fer-ho, necessitaria un sistema modern de gestió de dependències. Codex proposa conan, i en fem un petit PoC: passar una sola dependencia, una que havia introduit jo posteriorment i que coneixia bé, pugixml a conan.

Amb el PoC funcionant, li demano a Codex que faci una auditoria de totes les llibreries a substituir, i que creï un document amb tota la informació necessària per, a poc a poc, anar-les atacant d'una en una.

Amb el document de base, es tractava d'obrir una sessió de Codex, demanar que es llegís la documentació i que ataqués la substitució de la llibreria que li semblés més factible. I que apuntés tot el que canviava i havia après al mateix document. Aquest procés dura mesos, en els que vaig treballant entre tasques i fora d'hores. De vegades fent ssh des del mòbil a una màquina on tenia l'agent corrent, per a donar-li indicacions.

Algunes de les llibreries existeixen a conan amb la mateixa versió, algunes amb una versió posterior, i d'altres simplement ja no existeixen i han de ser substituïdes per d'altres. Tot això ho aconsegueix resoldre Codex.

Finalment, després de modernitzar totes les llibreries de base, sóc capaç d'intentar -i succeir- compilar el Mapping Tool per Apple Silicon.

El que vaig fer era gairebé un Ralph Loop

Si heu estat atents a l'actualitat de IA, un ralph loop justament fa això, però d'una forma una mica més autònoma. No és sorprenent que tothom vagi arribant a les mateixes conclusions sobre com operar amb agents de codi de forma efectiva: és molt important donar a l'agent de codi una forma de comprovar els resultats, de compilar i veure els errors. Així pot iterar sol molt millor i durant més temps.

Inicialment passava els errors manualment des del log del CI a Codex, però més tard vaig donar-li un script per a baixar-se tot el resultat de la compilació i trobar els logs del que havia fallat. Això va millorar bastant l'ergonomia.

Claude és millor debugant

No tot ho va fer Codex. Claude va resoldre un problema de violació de segment a Linux. No era senzill, ja que usem tecnologia d'AppImage per empaquetar llibreries del sistema com glibc. Ho va fer entrant per SSH en un ordinador on fallava, per debugar-lo en remot. Vaig quedar genuïnament impressionat.

Al final, pagar deute tècnic sí que tenia valor

Després de fer el port, la versió de Mapping Tool no només funciona fent el mateix. Només pel fet d'estar corrent de forma nativa, ja va molt més ràpid, amb guanys espectaculars. A més, ara hem recuperat la capacitat de fer profiling, i amb una sessió curta hem pogut optimitzar la càrrega de projectes. Entre els dos guanys, projectes que tardaven minuts en carregar, ara carreguen en escassos segons.

Som massa productius

Si bé és cert que he pogut esquivar un gran problema gràcies a l'augment de productivitat que ens dónen els agents de codi i la IA en general, també ho és que això ens crea una pressió molt forta a ser més productius: quan cada minut compta de forma significativa, és molt difícil parar i no fer res.

Quan vaig impulsar el sistema de CI/CD intern per a compilar els productes (en aquell moment amb builds de 1 o 2 hores), sentia que si no estavem fent build tota l'estona - dia i nit - estavem perdent el temps. El mateix em passa ara: la pressió de "hauriem de tenir agents de codi treballant de forma continua dia i nit" és cada cop més present. La tinc i la llegeixo a gent del sector.

Perquè com em deien avui a l'oficina, el programari no s'acaba. Sempre hi ha coses per pulir, eines per fer, casos d'ús per descobrir. I deute tècnic per pagar.

En aquest món tan ràpidament canviant, almenys en aquest moment, estem tots en una espiral de productivitat que haurem d'aprendre a combatre i gestionar. I si ja és tot tant intens ara, imaginem-nos amb els avenços els propers mesos i anys i l'adveniment de la IAG...

L'era del programari personal

2026-01-25T00:00:00+01:00

Portem una progressió d'eines molt interessant l'últim any. Primer, amb agents de langchain s'intentava el que claude code va ser el primer a aconseguir: la combinació de tools amb LLMs, amb un loop d'acció i test. Aquest 2026 tot s'està accelerant amb Ralph loops i clawdbot.

El programari s'està abaratint a xarxes forçaces i, tot i les seves limitacions, hi ha molts casos d'ús on de cop l'economia de la progamació ha quedat trastocada.

No tinc temps, ni l'habilitat, per a fer una disetació d'on ens porta tot això, però puc donar cinc centims de coses que he aconseguit fent servir agents de codi que no hagués pogut fer abans.

Automatitxació del long tail

L'economia de l'automatització estava perfectament capturada per la clàssica vinyeta de XKCD:

El primer cop que vaig veure aquesta vinyeta, em va quedat gravada a la retina. I he intentat no caure al forat negre de crerar codi per a automatitzar coses per a tasques que no tenen un retorn positiu en temps. Aquesta graella ja no té sentit: crear programari és tant barat (en temps) que gairebé qualsevol cosa es pot automatitzar.

Eines d'Onboarding i offboarding

He creat un parell d'eines per a fer onboqarding i offboarding. Backups de dades de google workspace i després pujar-ho en una unitat compartida de drive? Fet! Crear els comptes nous a les diferents plataformes i assignar-los els permisos? Fet! Crear un informe amb tot el procés? Fet!

Eines d'un sol ús

El mateix passa amb tasques que vols automatitzar un sol cop. He creat tot un programari ad-hoc per a transformar un informe en markdown a PDF. Demanant coses extranyes, Etiquetes de colors, index maco... Ha funcionat perfectament i després d'aquest sol ús, no el faré servir mai més. Però no hauria fet manualment, no m'hauria valgut la pena.

Personalització de programari existent

Un dels casos d'ús més interessants. Baixa't el codi d'un repo de github, demana modificacións i úsa'l. No cal ni publicar-lo.

Tukai: aprendre tipografia

Aquest any me n'he adonat que amb els agents de codi el coll d'ampolla del desenvolupament passava a ser la velocitat amb la que podia escriure a màquina. En tants anys de dedicació a aquest aprofessió això no m'havia passat mai, normalment dedicava més temps a pensar que en escriure.

Així que, a la meva edat, em vaig posar a aprendre tipografia. I necessitava un programa per a practicar que a més funcionés en local, per a fer-lo servir en els meus viatges en tren. Vaig trobar Tukai i em va agradar. La pega: ni tenia llista de paraules en català.

Amb claude code (o codex, no ho recordo) en un tres i no res hem afegit diversos diccionaris en català pels diferents nivells d'aprenentatge, basats en les paraules més freqüents de la Viquipèdia, i amb presència equilibrada de totes les lletres.

Claude Code Sleep preventer

Una cosa que em fa molta ràbia del macbook és la com d'agressiu és posant-se en repòs a la mínima que pot. I quan fas servir un agent de codi, aquest tema esdevé un problema.

Aparentment Claude Code Sleep Preventer fa exactament això, però: O forks, 0 estrelles! Així que he baixat el codi i li he fet fer una auditoria al claude code.

Aquest ja m'ha revelat una sorpresa: aparentment el programari també transcriu la veuquan li demanes que ho faci, i per a fer-ho necessita baixar i executar un model en local (whisper) de més de centenars de megues. A part d'això, el programari no sembla maliciós.

Així que amb 5 minuts de modificacions amb claude code, ja el tinc instal·lat, sense la part de transcripció de veu, i funcionant.

I tot aixpo en rust, que ni domino ni casi sé llegir!

Jugant amb clawdbot

L'exemple més radical que he pogut experimentar és el del clawdbot. Quan vaig descobrir què era, una espècie de claude code universal que es pot fer servir com assistent personal, el vaig instal·lar: realment necessito un assistent personal.

El cas és que si li demanes si pot fer tal o qual cosa, et pot dir quelcom en la linia de: no ho puc fer, però puc programar-me un plugin per a fer-ho. I ho fa! El propi programa-assistent es crea les seves pròpies extensions. En el meu cas, volia processar informació de Notion, i pocs minuts més tard ja en podia llegir i escriure articles.

Conclusions

Entrem en una etapa fascinant de la creació de programari. No en tinc ni idea de com serà el futur però el que sí que sé és que l'era de programes fixes, que no evolucionen, de tasques manuals acomplertes en solitari, s'ha acabat. I entrem en l'era del programari. Del programari barat i omnipresent.

The Age of Personal Software

2026-01-25T00:00:00+01:00

Over the last year, these tools have evolved at a remarkable pace. Early LangChain agents were exploring the same idea, but Claude Code was the first tool that really made it work: combining tools with LLMs in an action-and-test loop. In 2026, all of this is accelerating with Ralph loops and clawdbot.

Software is becoming dramatically cheaper to build and, despite its limitations, there are many use cases where the economics of programming have suddenly been turned upside down.

I don't have the time, or the skill, to write a full dissertation on where all of this is taking us, but I can at least share a few things I've been able to do with code agents that I could not have done before.

Automating the long tail

The economics of automation were perfectly captured by the classic XKCD comic:

The first time I saw that comic, it got burned into my brain. I've tried not to fall into the black hole of writing code to automate tasks that don't have a positive return on the time invested. That chart no longer really applies: software is now so cheap to create, in time terms, that almost anything can be automated.

Onboarding and offboarding tools

I've built a couple of tools for onboarding and offboarding. Backing up Google Workspace data and then uploading it to a shared Drive folder? Done. Creating the new accounts across different platforms and assigning permissions? Done. Generating a report with the whole process? Done.

Single-use tools

The same thing happens with tasks you only want to automate once. I built a whole ad-hoc piece of software to transform one report from Markdown into PDF. With odd requirements, color-coded labels, a polished table of contents... It worked perfectly and after that single use, I will never use it again. But I would not have done it manually either. It would not have been worth it.

Customizing existing software

This is one of the most interesting use cases. You can pull down a GitHub repo, ask an agent to adapt it, and just use the result. You don't even need to publish it.

Tukai: learning touch typing

This year I realized that, with code agents, the bottleneck in development had shifted to my typing speed. In all my years in this profession, that had never happened to me before. Usually I spent more time thinking than typing.

So, at this point in my life, I decided to learn touch typing properly. I needed a practice program that also worked locally so I could use it during train trips. I found Tukai and liked it. The problem: it didn't even ship with a Catalan word list.

With Claude Code, or Codex, I don't remember which, we quickly added several Catalan dictionaries for different learning levels, based on the most frequent words in Wikipedia and with balanced coverage of all letters.

Claude Code Sleep Preventer

One thing that really annoys me about the MacBook is how aggressive it is about going to sleep at the slightest opportunity. And when you're using a code agent, that becomes a problem.

Apparently Claude Code Sleep Preventer does exactly that, but: zero forks, zero stars. So I downloaded the code and had Claude Code audit it.

That already revealed a surprise: apparently the software also transcribes speech when you ask it to, and to do that it needs to download and run a local Whisper model weighing in at hundreds of megabytes. Aside from that, the software did not seem malicious.

So with five minutes of modifications in Claude Code, I had it installed, running, and without the speech transcription part.

And all of that in Rust, a language I barely know how to read, let alone write.

Playing with clawdbot

The most extreme example I've personally tried is clawdbot. When I discovered what it was, a kind of universal Claude Code that you can use as a personal assistant, I installed it immediately. That immediately appealed to me, because I could genuinely use a personal assistant.

The thing is, if you ask it whether it can do this or that, it might answer something like: I can't do that, but I can program myself a plugin to do it. And then it does. The assistant can effectively build its own extensions. In my case, I wanted to process information from Notion, and a few minutes later it was already able to read and write articles there.

Conclusions

We are entering a fascinating stage in software creation. I have no idea what the future will look like, but one thing I do know is that the era of fixed programs that do not evolve, of manual tasks completed in isolation, is over. We are entering the age of software that is cheap, abundant, and everywhere.

Benvinguda

2026-01-09T16:57:00+01:00

A vegades tinc ganes d'explicar coses, coses interessants, però mai trobo el temps ni sé on posar-les perquè arribi a algú.

Després de llegir Hacker News de forma regular durant mesos, em queda clara la superioritat dels blogs per a explicar el tipus de coses que vull explicar. Així que muntaré aquest blog com a nucli i replicaré els articles a altres outlets més tancats.

Aquest és també el meu esforç perquè existeixi contingut de qualitat, profund i tècnic, en català.

Espero no quedar-me atrapat en la implementació del blog. Anem veient.

Welcome

2026-01-09T16:57:00+01:00

Sometimes I feel like explaining things, interesting things, but I never find the time or know where to put them so they reach someone.

After reading Hacker News regularly for months, the superiority of blogs for explaining the kind of things I want to explain is clear to me. So I'll set up this blog as a hub and replicate the articles to other more closed outlets.

This is also my effort to ensure that high-quality, deep, and technical content exists in Catalan.

I hope I don't get stuck in the implementation of the blog. We'll see.