Què vol dir realment «desenvolupador preparat per a la IA»: una definició tècnica
Avui dia, totes les empreses de nearshoring, agències de selecció i plataformes de reclutament asseguren que ofereixen desenvolupadors «preparats per a la IA». El terme ha quedat buit de significat: una etiqueta de màrqueting que es penja a qualsevol que hagi sentit a parlar de ChatGPT.
I això és un problema, perquè la preparació per a la IA és una competència real i avaluable: la que separa els enginyers que converteixen la IA en velocitat de lliurament dels que la converteixen en una fàbrica d'errors més ràpida. Reduir-la a una paraula de moda perjudica les empreses que necessiten contractar enginyers capaços de fer servir eines d'IA en producció de debò.
Així doncs, això és el que vull dir quan parlo de «preparat per a la IA» a nivell d'enginyeria — no un eslògan, sinó el conjunt d'habilitats verificables, amb criteris d'avaluació concrets, que comprovem en cada enginyer que entra a la xarxa de Conectia.
Les sis competències
1. Domini de les eines d'IA
Què vol dir: La capacitat de fer servir assistents de programació amb IA — Copilot, Cursor, Claude, Cody i similars — com una part natural del flux de treball. No de tant en tant. No per provar. Com a procediment operatiu estàndard.
Com es concreta a la pràctica:
Un enginyer amb soltesa en IA fa servir aquestes eines per generar codi repetitiu, escriure tests, documentar, refactoritzar, explicar codi i depurar. Coneix els punts forts i les limitacions de cada eina, i en canvia segons la tasca: Copilot per a l'autocompletat en línia, Claude per al raonament complex i la discussió d'arquitectura, Cursor per a refactoritzacions a escala de tota la base de codi.
Com avaluar-ho:
Encarrega-li una tasca real de refactorització i observa com treballa. Recorre a les eines d'IA amb naturalitat? Dona context útil (referències a fitxers, restriccions, exemples) per obtenir bons resultats? Itera sobre el que rep, o accepta la primera resposta?
El llistó: Un enginyer sènior que el 2025 no fa servir eines de programació amb IA de manera habitual està renunciant a una part molt seriosa de la seva productivitat. No és una qüestió de preferències: és una qüestió de capacitat professional.
2. Enginyeria de prompts
Què vol dir: La capacitat d'escriure prompts que treguin dels LLM resultats útils, precisos i adequats al context. És una habilitat diferent d'escriure codi: demana entendre com processen les instruccions els models de llenguatge, quin context necessiten i com estructurar les peticions perquè el resultat sigui fiable.
Com es concreta a la pràctica:
Un enginyer que domina el prompt aporta context del sistema, especifica el format de sortida, inclou restriccions i casos límit, i fa servir exemples quan cal. Descompon les tasques complexes en passos en lloc d'escriure prompts monolítics. Sap quan toca una cadena de raonament (chain-of-thought) i quan n'hi ha prou amb una instrucció directa.
En generació de codi, concretament, hi inclou: el llenguatge i el framework de destí, el context de codi rellevant, les convencions de nomenclatura, les expectatives de gestió d'errors i els requisits concrets que el codi generat ha de complir.
Com avaluar-ho:
Demana-li que faci servir una eina d'IA per generar una peça de codi moderadament complexa: una classe de servei, un endpoint d'API amb validació, un pipeline de processament de dades. Avalua els prompts que escriu, no només el resultat. Ha donat prou context? Ha acotat bé la sortida? Ha iterat quan el primer resultat no era el bo?
El llistó: Un enginyer que enganxa «escriu-me una funció que faci X» i accepta el que en surti no domina el prompt. L'habilitat és a l'especificitat i a la iteració.
3. Criteri crític (la competència més important)
Què vol dir: La capacitat d'avaluar el que genera la IA amb el mateix rigor que aplicaries a la pull request d'un desenvolupador júnior — perquè aquest és el nivell de confiança que li pertoca.
Com es concreta a la pràctica:
Un enginyer amb bon criteri revisa cada línia de codi generat per IA abans de fer-ne commit. Hi comprova:
- La correcció lògica: el codi fa de debò el que s'ha demanat, casos límit inclosos?
- Les implicacions de seguretat: la IA ha introduït cap vulnerabilitat (injecció SQL, validació d'entrada deficient, credencials exposades)?
- L'encaix arquitectònic: el codi generat segueix els patrons del projecte, o hi ha introduït una incoherència?
- La cobertura de tests: els tests generats per la IA comproven comportament significatiu, o només detalls d'implementació?
- La higiene de dependències: la IA ha suggerit importar cap biblioteca que comporti un risc de cadena de subministrament o un conflicte de llicències?
Com avaluar-ho:
Posa-li al davant codi generat per IA amb errors subtils: un off-by-one a la lògica de paginació, una condició de cursa en un handler asíncron, una consulta SQL vulnerable a injecció en un cas límit. Els troba? Quant triga? Sap on mirar?
El llistó: Aquesta és la competència que separa l'enginyeria assistida per IA productiva de la perillosa. Un enginyer que es refia de la sortida de la IA sense revisar-la posa errors en producció més de pressa que un que ho escriu tot a mà.
4. Sentit arquitectònic en un context d'IA
Què vol dir: Entendre com les capacitats i les limitacions de la IA han de pesar en les decisions de disseny de sistemes.
Com es concreta a la pràctica:
Un enginyer preparat per a la IA amb nivell d'arquitecte sap raonar sobre:
- On la integració d'un LLM aporta valor de debò i on només afegeix complexitat sense un benefici proporcional
- Les implicacions operatives dels sistemes que depenen d'un LLM: latència, cost, fiabilitat i els modes de fallada propis dels components d'IA
- Quan toca un model preentrenat, quan fine-tuning, quan RAG (generació augmentada per recuperació) i quan la lògica tradicional basada en regles
- Com dissenyar sistemes que es degradin de manera controlada quan els components d'IA fallen o retornen resultats inesperats
- L'arquitectura de costos dels sistemes amb IA integrada: consum de tokens, emmagatzematge d'embeddings, infraestructura d'inferència
No cal que tots els enginyers d'un equip tinguin aquesta competència — però almenys un sènior o un tech lead l'hauria de tenir.
Com avaluar-ho:
Planteja-li un escenari de producte que es podria resoldre amb integració d'IA i demana-li que en dissenyi l'enfocament tècnic. Avalua si considera alternatives a les solucions basades en LLM, si aborda els modes de fallada i si pensa en els costos operatius i la fiabilitat.
5. Consciència de seguretat per al desenvolupament assistit per IA
Què vol dir: Entendre els riscos de seguretat específics que les eines d'IA introdueixen en el procés de desenvolupament.
Com es concreta a la pràctica:
Un enginyer conscient de la seguretat entén:
- Els riscos d'injecció de prompts en funcionalitats d'IA de cara a l'usuari — i dissenya la validació d'entrada i la sanitització de sortida en conseqüència.
- La fuga de dades a través de les eines d'IA — no enganxar codi propietari ni dades de clients en serveis d'IA públics.
- Els riscos de les dependències generades — les eines d'IA suggereixen sovint paquets obsolets, abandonats o amb vulnerabilitats conegudes. L'enginyer verifica les dependències abans d'afegir-les.
- L'exposició de credencials — les eines d'IA que operen sobre bases de codi poden treure a la llum, sense voler, patrons amb secrets escrits al codi. L'enginyer té hàbits disciplinats de gestió de credencials.
- Els límits de compliment normatiu — saber quin codi i quines dades es poden processar amb eines d'IA i quins no, sobretot en sectors regulats (sanitat, finances, administració pública).
Com avaluar-ho:
Demana-li que descrigui com fa servir les eines d'IA en un context sensible per a la seguretat. Té límits clars? Sap articular els riscos de fluxos de treball concrets assistits per IA?
6. Comunicació de les decisions assistides per IA
Què vol dir: La capacitat de comunicar amb transparència quan i com s'han fet servir eines d'IA en la feina de desenvolupament.
Com es concreta a la pràctica:
Un enginyer amb aquesta competència documenta l'ús d'eines d'IA allà on toca. A les descripcions de les pull requests, fa constar quan una part substancial del codi ha estat generada o assistida per IA, i descriu la revisió i les modificacions humanes que hi ha aplicat. Als registres de decisions d'arquitectura, deixa constància de quan les eines d'IA han influït en el disseny.
No és qüestió de confessar-se: és qüestió de traçabilitat. Quan apareix un error en producció, saber si una secció de codi és escrita a mà, generada per IA, o generada per IA i després retocada, canvia l'enfocament de la depuració.
Com avaluar-ho:
Revisa les seves descripcions de PR i els seus hàbits de documentació. Comunica amb claredat el seu procés de desenvolupament? Distingeix entre el que ha escrit de zero i el que ha desenvolupat amb ajuda de la IA?
La matriu d'avaluació
Per a cada competència, avaluem en una escala de tres nivells:
| Nivell | Descripció | Implicació |
|---|---|---|
| Operatiu | Fa servir eines d'IA en el flux de treball diari amb criteri i eficàcia demostrats | A punt per al desenvolupament assistit per IA en producció |
| En desenvolupament | Fa servir eines d'IA amb certa eficàcia, però amb criteri irregular o un ventall d'eines limitat | Necessita mentoria; encara no és fiable per a treball autònom assistit per IA |
| Absent | No fa servir eines d'IA de manera habitual, o les fa servir sense revisió crítica | Bretxa de productivitat important respecte dels companys amb soltesa en IA |
Un enginyer avaluat per Conectia puntua «Operatiu» en les sis competències. Aquest és el llindar que hi ha darrere de la nostra taxa d'acceptació del 4%.
Per què importa aquesta definició
La distància entre un equip amb soltesa en IA i un que no en té s'eixampla cada trimestre. A mesura que les eines milloren, els enginyers que les fan servir bé lliuraran més de pressa, produiran codi de més qualitat i costaran menys per funcionalitat lliurada.
Les empreses que contracten enginyers «preparats per a la IA» fiant-se d'una paraula de moda obtindran resultats irregulars. Les que contracten a partir d'una competència verificable i multidimensional construiran equips que acumulen avantatge amb el temps.
Les sis competències definides aquí no són teòriques: són el que avaluem en cada enginyer que entra a la xarxa de Conectia. Són mesurables, són entrenables, i marquen la diferència entre la IA com a multiplicador de productivitat i la IA com a font d'errors subtils i cars.
Vols veure com queden els teus candidats davant d'aquestes sis competències? Parla amb un CTO i accedeix a enginyers preavaluats i preparats per a la IA que ja han superat aquesta avaluació.
