Hi ha un vídeo que es repeteix cada setmana. Algú obre un Figma, arrossega una pantalla a un xat i, trenta segons després, apareix una pàgina maquetada que s’assembla bastant al disseny. El comentari final sol ser el mateix: «això abans eren dos dies de feina».
I és cert. Aquella pantalla, ella sola, abans eren dos dies.
El problema comença a la pantalla dotze.
Perquè aleshores ja tens quatre maneres diferents d’escriure un botó, tres escales d’espaiat convivint dins el mateix CSS i una llista de classes que ningú no podria mantenir d’aquí a sis mesos. No hi ha res trencat. Tot es veu bé. I tot i així tens un projecte pitjor que si l’haguessis fet a mà.
La IA no maqueta malament. Maqueta sense saber en quin projecte és.
Fa mesos que faig servir els MCP de Figma i Zeplin dins del VSCode per maquetar pantalles de client. Funciona. Però no funciona com es explica per aquí, i la diferència entre que surti bé o surti malament no és al prompt. És en el que hi ha preparat abans d’escriure’l.
Continguts
Maquetar ràpid no és maquetar bé
Les demos funcionen perquè la pantalla està sola.
Una pantalla aïllada no ha de conviure amb res. No hereta estils, no comparteix components, no ha d’encaixar amb el que va maquetar una altra persona el mes passat. És un exercici tancat i la IA el resol bé.
Un projecte real és el contrari. Un web de client són trenta o quaranta plantilles que comparteixen components, un tema de WordPress amb les seves convencions, un CSS que ja té decisions preses i, gairebé sempre, un històric que no pots llençar a les escombraries.
En aquest context, la pregunta deixa de ser si la IA pot generar l’HTML d’una pantalla. Pot. La pregunta és si aquell HTML s’assembla a la resta del projecte.
El primer cop que ho vam provar de debò, el resultat visual va ser bo des de la segona iteració. El problema va aparèixer en revisar el diff: tres components nous que ja existien amb un altre nom, valors d’espaiat en píxels on el projecte feia servir variables, i una estructura de classes que no seguia cap de les convencions del tema.
Res d’això es veu al navegador. Tot això es paga després.
La IA no coneix el teu sistema fins que l’hi dones
Això sona obvi i, tot i així, és l’error que he comès més vegades.
Quan fa setmanes que ets dins d’un projecte, tens al cap coses que no estan escrites enlloc: que els espaiats van en múltiples de 4, que els components es prefixen amb c-, que les utilitats viuen en un fitxer a part, que els breakpoints són tres i no cinc, que l’h1 de les plantilles internes el pinta un component de capçalera i no la plantilla.
La IA no té res de tot això. I com que no ho té, s’ho inventa. Amb criteri, a més, cosa que ho empitjora: genera una solució raonable que un desenvolupador sense context aprovaria.
Quan dic sistema em refereixo a coses molt concretes:
Variables de color i la seva nomenclatura. Escala tipogràfica i com s’aplica. Sistema d’espaiat. Breakpoints. Convenció de noms de classes. Què és un component i què és una variant. On viu cada fitxer. Què està prohibit tocar.
Quan això està escrit en un fitxer que la IA llegeix abans de cada tasca, el resultat canvia de manera notable. No perquè el model sigui més llest, sinó perquè deixa de tenir buits per omplir.
Cada buit que no omples tu l’omple l’eina, i l’omple amb la mitjana d’internet.
Aquesta és la feina que no surt als vídeos. Asseure’t a escriure què és el teu projecte no és glamurós i és exactament el que separa una maqueta aprofitable d’una que només ho sembla.
Del disseny al codi: quina part s’automatitza de debò
Amb els MCP connectats, la IA llegeix el fitxer de disseny directament. No li descrius la pantalla: la té al davant.
Això resol bé una part de la feina, i val la pena dir quina:
Extreure valors és on més hi guanya. Colors, mides, espaiats, tipografies, mesures exactes d’un component. Aquella feina d’anar a mirar cada capa i copiar el valor desapareix gairebé del tot, i és una feina que, a més, fèiem malament: tots hem posat un padding: 23px perquè el vam llegir malament a l’inspector.
Muntar l’estructura també funciona. Una graella, una secció amb la seva capçalera i les seves targetes, un formulari amb els seus camps. Si el sistema està definit, surt amb les classes correctes i a la primera.
Els estats i les variants surten a mitges. Si el dissenyador els ha deixat documentats al fitxer, bé. Si no hi són, la IA no t’avisa que falten: t’entrega el component amb el seu estat per defecte i prou. El hover, el focus, el disabled, l’estat d’error i l’estat buit continuen sent una conversa amb disseny, no una tasca de maquetació.
I hi ha una part que no s’automatitza en absolut: decidir si allò que estàs veient hauria d’existir. Un disseny pot portar una targeta gairebé igual a una altra que ja tens, amb dues diferències cosmètiques. La IA maquetarà totes dues. La teva feina és preguntar si no haurien de ser la mateixa amb una variant.
El cost que ningú no explica: cada pantalla es torna a llegir
Aquest és el detall més pràctic que m’he trobat i gairebé mai no es menciona.
Llegir una pantalla de disseny consumeix molts tokens. Milers. I cada vegada que fas una pregunta nova sobre aquella mateixa pantalla, es torna a llegir. Preguntes pel marge inferior d’una targeta i tornes a pagar el cost de processar el fitxer sencer.
En una pantalla solta tant és. En una sessió de feina de quatre hores sobre un mòdul amb diversos estats, es nota molt: en temps d’espera, en cost i en el fet que la conversa es degrada abans del que hauria.
El que ens ha funcionat és deixar de tractar el fitxer de disseny com una cosa que es consulta en directe. Primer fem una lectura, extraiem els valors i l’estructura a un document propi, i a partir d’aquí treballem contra aquell document. És menys espectacular que ensenyar la connexió directa, però és el que fa que el flux sigui sostenible més enllà de la demo.
Continua sent un problema obert. Estic provant maneres de guardar aquella lectura entre consultes i, ara mateix, la solució és manual.
El codi generat sol ser correcte i estructuralment pobre
Hi ha una diferència entre codi que funciona i codi que està ben fet, i la IA es queda del primer costat amb molta facilitat.
El que m’he trobat més sovint:
Elements que haurien de ser semàntics i no ho són. Un div amb un gestor de clic on tocava un button. Una llista d’enllaços que no és una llista. Un acordió sense cap atribut que indiqui si està obert.
Jerarquies d’encapçalaments que salten nivells perquè el disseny té un text gran i un altre petit, i el model tradueix mida visual a nivell d’encapçalament. Cosa que té una lògica, només que no és la lògica correcta.
Estats de focus que desapareixen. El disseny no els dibuixa, així que el codi no els té. I quan el projecte és d’un client amb obligacions d’accessibilitat, això no és un detall.
Cap d’aquestes coses trenca res. Es veuen perfectes. Passen una revisió visual sense problema i surten a producció si ningú no mira l’HTML.
Revisar una maqueta generada no és mirar si s’assembla al disseny. És mirar allò que el navegador no ensenya.
Quan entra el CMS, la maqueta deixa de ser una maqueta
Aquí és on la feina amb IA passa d’anar molt ràpid a anar normal.
Una maqueta estàtica és contingut controlat. Els títols mesuren el que tu decideixes, totes les targetes tenen imatge i el llistat sempre porta sis elements. Un WordPress amb ACF Pro i WPML al darrere no s’assembla gens a això.
El que apareix tan bon punt connectes el contingut real:
Un títol de producte de noranta caràcters en una targeta dissenyada per a quaranta. Un repeater buit perquè el client encara no ha omplert aquella secció. Una imatge destacada que no existeix i una plantilla que no té fallback. Textos escrits directament a la plantilla, sense passar per les funcions de traducció, que en un projecte multiidioma és un error que es descobreix tard i s’arregla a poc a poc.
La IA pot generar el codi de la plantilla. El que no pot és anticipar com es comporta aquell disseny quan l’omple una persona que no era a la reunió de disseny.
Per això el primer contingut real entra aviat al nostre procés. No al final, quan la maqueta està «acabada». Tan bon punt hi ha tres components en peu, hi posem dades lletges a propòsit: el títol més llarg, el camp buit, el llistat amb un sol element.
El que no deleguem
Hi ha decisions que no tenen res a veure amb escriure codi i que condicionen tota la resta.
Posar noms. Com es diu un component determina si algú el troba d’aquí a un any o en crea un de nou. La IA proposa noms correctes i genèrics. Nosaltres necessitem els nostres.
Decidir si una cosa és un component nou o una variant. És la decisió que genera més deute a mitjà termini i la que la IA resol sempre pel camí fàcil: component nou.
Discutir el disseny quan el disseny està malament. Un fitxer de Figma no és una especificació tancada. De vegades la millor resposta a una pantalla és una trucada al dissenyador, no una maqueta. La IA no et dirà mai que allò no s’hauria de fer així.
Accessibilitat i rendiment. Totes dues es poden revisar amb ajuda, cap de les dues es pot delegar. Són criteris que algú ha de sostenir.
Quan és més ràpid fer-ho a mà
No faig servir la IA per a tot, i no per principis. Per temps.
Si el canvi són tres línies de CSS, escriure-les és més ràpid que explicar on són. Si el component és petit i el tinc clar al cap, escriure’l és més ràpid que revisar el que em tornin. Si estic depurant alguna cosa rara, descriure el problema amb la precisió necessària perquè l’ajuda serveixi ja m’ha fet entendre el problema, i aleshores sol estar resolt.
Hi ha un càlcul bastant honest que es pot fer abans de començar: si preparar el context costa més que la tasca, la tasca és més ràpida a mà.
Això canvia segons el projecte. En un projecte on el sistema ja està documentat, el context és gairebé gratis i la balança s’inclina de seguida. En un projecte que acabes d’heretar, amb un CSS de cinc anys i sense convencions clares, preparar el context és la meitat de la feina.
Què ha canviat de debò en el nostre procés
No és que maquetem més ràpid. És que l’ordre s’ha invertit.
Abans, el sistema de disseny es consolidava mentre maquetaves. Començaves per la home, anaves resolent i, cap a la pantalla quinze, tenies clares les regles. Funcionava perquè el cost d’improvisar el pagava una sola persona sobre la marxa.
Ara el sistema ha d’estar abans. Si no hi és, la IA multiplica la improvisació per quaranta pantalles en dues tardes, i això no s’arregla refactoritzant: s’arregla tornant a començar.
Dit d’una altra manera: la IA ha fet que preparar bé el sistema sigui rendible. Abans era una bona pràctica que de vegades et podies saltar. Ara és la condició perquè la resta funcioni.
El temps no ha marxat de la maquetació. S’ha mogut a la preparació i a la revisió.
Una maqueta mal feta no es veu, es paga
Una maqueta mal feta no es detecta el dia de l’entrega. Es detecta sis mesos després, quan cal afegir una secció i ningú no sap quin component reutilitzar, o quan un canvi d’espaiat obliga a tocar quinze fitxers.
Això és el que fa que aquesta feina sigui difícil de jutjar des de fora. El dia que es publica, tot es veu bé.
El que és difícil de maquetar no va ser mai escriure l’HTML. Va ser organitzar un projecte perquè es pugui mantenir, veure que dos components són en realitat el mateix, saber que aquell div havia de ser un button i detectar que un títol de noranta caràcters trencarà la targeta al mòbil. Tot això continua sent igual de necessari que abans.
El que canvia és el volum. Amb experiència, la IA et treu del damunt la part mecànica i et deixa més temps per a les decisions que importen. Sense experiència, t’entrega molt codi que sembla bo i no tens amb què avaluar-lo, així que l’acceptes.
La IA no baixa el nivell de coneixement que cal per maquetar bé. El puja.
Si estàs començant a incorporar-la al teu flux, el que jo faria no té res d’espectacular: dedicar el primer dia a escriure com funciona el teu projecte, i tot el temps que vingui després a revisar el que et torna. Aquí es decideix si el projecte es podrà mantenir o si algú el pagarà més endavant.
Preguntes freqüents sobre maquetar amb IA
Es pot maquetar un web sencer amb IA?
Es pot generar el codi de totes les pantalles, però això no equival a tenir el web maquetat. Sense un sistema de disseny definit i una revisió estructural, el resultat són desenes de solucions semblants que no comparteixen criteri i que són difícils de mantenir. La IA accelera la producció, no substitueix l'arquitectura del projecte.
Què necessita la IA per maquetar seguint el meu sistema de disseny?
Necessita que el sistema estigui escrit: variables de color, escala tipogràfica, sistema d'espaiat, breakpoints, convenció de noms de classes, quins components ja existeixen i on viu cada fitxer. Si aquesta informació no està documentada en un lloc que l'eina pugui llegir, generarà una solució raonable però aliena al projecte.
Serveix l'MCP de Figma per maquetar?
Serveix, sobretot per extreure valors exactes i muntar l'estructura d'una pantalla sense haver d'anar capa per capa. El seu límit és el cost: cada lectura del fitxer consumeix molts tokens i es repeteix en cada consulta posterior, així que en sessions llargues convé extreure la informació un sol cop i treballar després contra aquell document.
El codi que genera la IA és accessible?
No per defecte. Els errors més habituals són elements no semàntics amb comportament interactiu, salts en la jerarquia d'encapçalaments i absència d'estats de focus, perquè el disseny no els solen dibuixar. Són errors invisibles al navegador que cal revisar a l'HTML, no a la pantalla.
Quant temps s'estalvia realment maquetant amb IA?
L'estalvi és clar en la part mecànica: extreure valors, muntar estructures repetitives i generar variants. En canvi apareix temps nou a preparar el context del projecte i a revisar el codi generat. El balanç sol ser positiu en projectes amb el sistema ben definit i bastant pitjor en projectes heretats sense convencions.
Cal saber maquetar per fer servir IA en desenvolupament front?
Cal més que abans. L'eina entrega codi que sembla correcte i només algú amb criteri pot distingir el que està ben fet del que simplement funciona. Sense aquest criteri no hi ha manera d'avaluar el resultat, i els problemes apareixen en el manteniment, no en l'entrega.
Què falla quan la maqueta s'integra en un CMS?
El contingut real. Títols més llargs del previst, camps buits, imatges que no existeixen, llistats amb un únic element i textos escrits a la plantilla sense passar per les funcions de traducció en projectes multiidioma. Convé posar contingut real, i incòmode, tan bon punt hi hagi dos o tres components en peu.
