Abans de la propera entrevista, fes una prova: enganxa l'enunciat de la teva prova tècnica a Claude Code o a Cursor i mira el rellotge. Si en uns minuts tens una solució que passa els teus tests, la prova ja no distingeix un bon desenvolupador d'algú que sap enganxar un enunciat. I si la fas en directe prohibint la IA, estàs veient com treballa una persona en unes condicions que no tindrà mai al seu lloc de feina.
No cal triar entre prohibir i permetre. Cal decidir què vols mesurar i construir la prova per a això. I el que convé mesurar ha canviat, perquè en un equip que treballa amb agents escriure codi ja no és la part difícil. La part difícil és veure l'error en un codi que sembla correcte.
Dues empreses d'IA, dues respostes oposades
El juny de 2025, Canva va publicar al seu blog d'enginyeria un article amb un títol que no deixa dubtes: «Sí, pots fer servir IA a les nostres entrevistes. De fet, hi insistim». Per als llocs de backend, machine learning i frontend, va substituir l'entrevista de fonaments d'informàtica —problemes com implementar el Joc de la Vida de Conway— per problemes més ambigus i realistes, del tipus «construeix un sistema per gestionar enlairaments i aterratges en un aeroport amb molt de trànsit». I va canviar el que avalua: com es descompon un requisit ambigu, quines decisions tècniques es prenen amb ajuda de la IA, si es detecten i corregeixen els errors del codi generat i si el resultat compleix els estàndards de producció.
El més interessant són les seves conclusions de les primeres proves. Els millors candidats feien preguntes per aclarir el problema, feien servir la IA per a subtasques concretes sense perdre el control del conjunt i revisaven amb ull crític el que generava. I els candidats sense experiència amb aquestes eines ho passaven malament, segons Canva, perquè els faltava el criteri per guiar la IA.
Anthropic manté una guia per a candidats, actualitzada el juliol de 2025, que va en la direcció contrària en el que importa aquí. Al currículum, la IA està bé sempre que el primer esborrany sigui teu. Però les proves per fer a casa es fan sense Claude llevat que s'indiqui el contrari, i a les entrevistes en directe, en paraules seves, «això ets tu»: sense ajuda d'IA, llevat d'indicació expressa. Volen veure com raona la persona en temps real.
Totes dues polítiques són coherents, perquè cadascuna sap què mesura. Anthropic vol veure el raonament individual; Canva, com treballa algú amb l'eina que farà servir. L'incoherent és el que fan moltes empreses: permetre la IA sense canviar la prova, de manera que es mesura la velocitat del model, o prohibir-la a l'entrevista i després demanar al lloc de feina productivitat amb agents des del primer dia.
El que s'ha tornat escàs
Si escriure codi ja no és el coll d'ampolla, què ho és? Dues dades ho deixen força clar.
La primera és de METR, una organització de recerca que avalua models d'IA. El juliol de 2025 va publicar un experiment amb setze desenvolupadors experimentats de projectes de codi obert, que van resoldre 246 tasques reals en repositoris on contribuïen habitualment, unes amb IA i d'altres sense. Amb IA van trigar un 19% més. Abans de començar esperaven anar un 24% més ràpid, i en acabar encara creien que havien guanyat un 20%. Els autors insisteixen que l'estudi no demostra que la IA alenteixi la majoria dels desenvolupadors: és una mostra concreta, en projectes que coneixien molt bé. Però el desajust entre el que es percep i el que es mesura no és un detall, perquè apareix fins i tot en gent amb molta experiència.
La segona és de l'enquesta anual de Stack Overflow de 2025. El 84% dels qui van respondre fa servir o pensa fer servir eines d'IA per programar, però només un 33% se'n refia de la precisió, davant d'un 46% que en desconfia. La frustració més citada, per un 66%, són les solucions que estan «gairebé bé, però no del tot». I un 45% diu que depurar el codi generat per IA li porta més temps.
Juntes dibuixen l'habilitat que cal buscar. No és escriure de pressa, que ja ho fa l'eina. És detectar el «gairebé bé» abans que arribi a producció, i saber mesurar amb honestedat quant t'ha ajudat l'eina. Cap de les dues coses no apareix en una prova d'algorismes, i tampoc en un live coding en què es permet la IA i es mesura si l'exercici queda resolt.
Què mesura cada prova avui
Amb aquest criteri, les proves habituals queden així:
| Prova | Què mesura avui | Per a què serveix |
|---|---|---|
| Algorisme a la pissarra, sense eines | Fonaments i raonament en veu alta. No diu res de com treballarà amb agents | Complement curt, no prova principal |
| Prova per fer a casa sense supervisió | Si sap fer servir un agent, o res, si després no se li pregunta com l'ha feta i per què | Només si es revisa amb el candidat |
| Live coding amb IA permesa i l'enunciat de sempre | La velocitat del model | Per a poca cosa: l'enunciat ja no discrimina |
| Especificar un requisit ambigu abans d'implementar-lo | Si sap dir què cal construir, què queda fora i com se sabrà que està bé | Central en un equip que treballa amb specs |
| Revisar un pull request generat per IA amb errors sembrats | Criteri sobre el codi aliè: la tasca que farà cada dia | Central |
| Depurar un error en un codi plausible | El que més temps costa segons els mateixos desenvolupadors | Molt útil, i ràpid de preparar |
Valoració d'onext. Les proves no s'exclouen: el que canvia és quina pesa més en la decisió
Les dues files centrals tenen una cosa en comú: reprodueixen la feina. En un equip que fa servir Spec-Driven Development, la jornada d'un desenvolupador consisteix en bona part a dir amb precisió què cal construir, deixar que l'agent implementi i comprovar que el que s'ha implementat és el que es va demanar. Si l'entrevista no té aquests tres moments, està avaluant una altra feina.
Una sessió en tres temps
Així plantejaríem una entrevista tècnica d'uns noranta minuts per a un lloc de desenvolupament en un equip que treballa amb agents. No és l'única manera de fer-ho, però cada part té un senyal concret per mirar.
Especificar (uns 20 minuts)
Es dona un requisit deliberadament ambigu, semblant al de l'aeroport de Canva, i es demana una especificació curta abans de tocar codi: què hi entra i què no, quins criteris d'acceptació tindria i què preguntaria al client. Aquí es mira quines preguntes fa i si els seus criteris es poden comprovar. Algú que escriu «ha de ser ràpid» no ha especificat res; algú que escriu quantes operacions per segon i en quines condicions, sí. És el mateix raonament que desenvolupem a l'especificació és on se signa.
Delegar (uns 40 minuts)
El candidat implementa una part amb la seva pròpia eina —la que faci servir en el seu dia a dia, no la que imposi l'empresa— i va explicant el que fa. No es mira si acaba. Es mira com reparteix la feina amb l'agent, què accepta sense llegir, quan l'atura i què fa quan el resultat no encaixa amb l'especificació que acaba d'escriure.
Revisar i trencar (uns 30 minuts)
Se li lliura un pull request generat amb IA sobre el mateix problema, amb tres errors sembrats del tipus que la IA comet de debò: un test que descriu el codi en lloc de provar-lo, un cas límit que ningú no ha tractat i un criteri de l'especificació que s'ha saltat sense avisar. Es mira què troba, com explica per què és un error i què demanaria abans d'aprovar-lo. És, gairebé literalment, la revisió que encara espera un autor que haurà de fer cada setmana.
I una última pregunta, que surt directament de l'estudi de METR: «quant creus que t'ha estalviat la IA en aquesta sessió?». No es tracta de penalitzar una mala estimació, sinó de veure si la persona s'hi ha fixat. Qui respon «a la part d'implementar molt, però a la revisió he perdut temps perquè el test no provava res» està mesurant la seva feina. Qui respon «moltíssim» sense matisos, probablement no. És el mateix problema que veiem a les empreses quan el ROI de Copilot es mesura on no és, però en una sola persona.
Els fonaments no desapareixen: es pregunten al final, sense eines, en una conversa curta sobre per què ha pres cada decisió. És el punt en què Anthropic té raó. Sense fonaments no es detecta un error subtil en un codi generat, perquè no se sap que és un error.
El que la IA no hauria de fer al teu procés de selecció
Hi ha una ironia en tot això. Moltes empreses que demanen als candidats que no facin servir IA la fan servir elles per filtrar currículums. I aquí el problema no és de coherència, és legal.
El Reglament europeu d'IA classifica com d'alt risc els sistemes d'IA destinats a la contractació o selecció de persones, en particular per analitzar i filtrar sol·licituds d'ocupació i avaluar els candidats (annex III, punt 4). Després de la modificació que va entrar en vigor el 27 de juliol de 2026, aquestes obligacions s'apliquen des del 2 de desembre de 2027. L'ajornament no és un permís per esperar: una eina de cribratge que es contracti avui continuarà en ús aleshores, i caldrà poder explicar com decideix i qui supervisa el que descarta.
Hi ha a més una raó menys jurídica. Un procés que filtra amb un model i avalua sense ell envia un missatge estrany a algú a qui demanaràs que treballi amb agents i que revisi el que generen. El raonable és que les decisions sobre les persones les prenguin persones, i dir-ho per escrit. A la nostra pròpia oferta ho hem fet així: cap IA no filtra ni puntua les candidatures, i la nostra política de privadesa ho recull a l'apartat de candidats (en castellà).
L'entrevista s'ha d'assemblar a la feina
Tot l'anterior es resumeix en una idea que no és nova: l'entrevista s'ha d'assemblar a la feina. El que és nou és que la feina ha canviat més de pressa que les entrevistes. Si al teu equip s'especifica, es delega a un agent i es verifica, això és el que cal veure a l'entrevista. Si la prova es pot resoldre enganxant l'enunciat, no diu res del candidat. I si en cap moment no cal trobar un error, deixa fora justament l'habilitat que més falta fa.
Contractar malament és car, i ja vam calcular quant costa tenir un lloc tècnic mesos sense cobrir. Contractar algú que escriu de pressa amb un agent però no veu els seus errors també ho és, només que triga més a notar-se.
Per cert, estem contractant: busquem un Full Stack Developer per treballar amb agents d'IA i Spec-Driven Development, l'oferta és aquí (en castellà).
Preguntes freqüents
Cal deixar fer servir IA a l'entrevista tècnica?
Depèn del que vulguis mesurar, i s'ha de decidir abans. Si vols veure com raona algú pel seu compte, té sentit demanar que no la faci servir, com fa Anthropic a les seves proves i entrevistes llevat que indiqui el contrari. Si vols veure com treballarà al lloc de feina, té sentit exigir-la, com fa Canva des del juny de 2025. El que no funciona és permetre-la sense canviar la prova: aleshores es mesura la velocitat del model, no la persona.
Encara serveixen les proves d'algorismes?
Per comprovar fonaments, sí, i els fonaments continuen comptant: sense ells no es detecta un error subtil en un codi generat. Però ja no serveixen com a prova principal, perquè mesuren com treballa algú sense les eines que farà servir cada dia. Una conversa curta sense eines sobre per què ha pres cada decisió de disseny dona la mateixa informació en menys temps.
Com s'avalua si un candidat sap revisar codi generat per IA?
Donant-li a revisar un pull request generat amb IA en què s'han sembrat errors del tipus que la IA comet de debò: un test que descriu el codi en lloc de provar-lo, un cas límit que no es tracta, un requisit de l'especificació que s'ha saltat sense avisar. Es mira què troba, com explica per què és un error i què faria perquè no arribi a producció. És la tasca que farà cada dia.
Què diu el Reglament europeu d'IA sobre fer servir IA per filtrar candidats?
Que els sistemes d'IA destinats a analitzar i filtrar sol·licituds d'ocupació i a avaluar candidats són d'alt risc (annex III, punt 4). Després de la modificació que va entrar en vigor el 27 de juliol de 2026, aquestes obligacions s'apliquen des del 2 de desembre de 2027. No és un motiu per esperar: una eina de cribratge que es contracti avui continuarà funcionant aleshores, i caldrà poder explicar com decideix.
Els desenvolupadors que fan servir IA són més ràpids?
No sempre, i no ho saben mesurar per si mateixos. A l'estudi de METR de juliol de 2025, setze desenvolupadors experimentats de projectes de codi obert van trigar un 19% més en les seves tasques amb IA, quan esperaven anar un 24% més ràpid, i en acabar encara creien que havien guanyat un 20%. Els autors adverteixen que no es pot generalitzar a tots els desenvolupadors, però el desajust entre percepció i mesura és la lliçó útil per a una entrevista.
Quin perfil cal buscar per a un equip que treballa amb especificacions i agents?
Algú que sàpiga dir què cal construir i com se sabrà que està bé abans d'escriure codi, que delegui a l'agent les parts que pot verificar i que s'aturi a llegir el que accepta. A l'entrevista es nota en tres coses: les preguntes que fa davant d'un requisit ambigu, els errors que troba en un codi que sembla correcte i com estima de bé quant l'ha ajudat l'eina.
Fonts
- Simon Newton, «Yes, You Can Use AI in Our Interviews. In fact, we insist», Canva Engineering Blog, 11 de juny de 2025.
- Anthropic, guia d'ús d'IA per a candidats, actualitzada el 10 de juliol de 2025.
- METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», 10 de juliol de 2025.
- Stack Overflow, Developer Survey 2025, secció d'IA.
- Reglament (UE) 2024/1689 d'Intel·ligència Artificial, annex III, punt 4.
- Comissió Europea, «AI Omnibus enters into force», 27 de juliol de 2026.
Jordi García és Tech Lead a onext. Treballa a portar la IA a producció governada en equips de desenvolupament i de producte —amb Spec-Driven Development, enginyeria de context i verificació humana a cada pas— i signa els insights tècnics d'onext sobre mètode, qualitat i cost de la IA aplicada.
LinkedIn →