El 2 d'octubre de 2026, Anthropic va anunciar un programa per formar 10.000 «Frontier Deployed Engineers» abans del final del 2027. És el senyal més clar d'una cosa que el sector repeteix des de fa temps: el model ja no és el coll d'ampolla. Ho és portar-lo a l'operació real d'una empresa.
Aquesta peça no va de qui té més enginyers desplegats. Va de la pregunta que s'hauria de fer qui els rep. La tesi: un projecte agèntic amb un equip extern es mesura també pel que deixa escrit a casa teva. Si el coneixement del desplegament marxa amb l'enginyer, el que has comprat no és un sistema: és una dependència.
Què és un enginyer desplegat
El terme ve de les empreses de programari que posaven enginyers a casa del client perquè el seu producte funcionés de debò. a16z ho resumeix així: són els equips que són més a prop del client i que converteixen el model en una solució del món real. La seva tesi és que, en IA, aquesta capa d'integració i context és on es construeix l'avantatge, encara que redueixi el marge.
El programa d'Anthropic, la Claude Frontier Academy, posa xifres a l'aposta:
Entre els participants que cita l'anunci hi ha consultores com Accenture, Bain, Capgemini, Deloitte i McKinsey, i empreses com Commonwealth Bank of Australia, Morgan Stanley o Novo Nordisk. El recorregut que descriu va «del cas d'ús adequat, passant per la revisió de seguretat, fins al traspàs». Matthew Mayo, a KDnuggets, ho diu en una frase: la tecnologia és capaç, i l'última milla fins a l'empresa continua sent difícil.
Res d'això és dolent. És una bona notícia per a qualsevol empresa que hagi vist morir un pilot a la frontera dels seus sistemes: hi haurà més gent que sap creuar-la.
Per a qui treballa el que aprèn
La pregunta incòmoda la formula el mateix article de KDnuggets. Per distingir un enginyer desplegat d'un consultor, proposa una prova: el que aprèn al client arriba al full de ruta de producte de la seva empresa? Si hi arriba, és un enginyer desplegat. Si no, «és consultoria amb un altre nom».
Fixa't cap a on va l'aprenentatge en aquesta definició: torna al proveïdor. És raonable des del seu costat, i és exactament el que a16z anomena canviar marge per fossat: controlar on i com entren les dades al sistema. Però el fossat és del proveïdor. El mateix article de KDnuggets no diu què es queda el client, i esmenta encàrrecs que s'allarguen en lloc d'acabar.
No és qui ve ni quants són. És què podrà fer el teu equip sense ells l'endemà que marxin.
El que s'ha de quedar escrit
En un sistema amb agents, bona part del que fa que funcioni no és al codi. És en decisions: què ha de fer el sistema, amb quines regles, com se sap que ho fa bé i qui decideix quan hi ha risc. Si aquestes decisions només viuen al cap de qui el va construir, marxen amb ell.
| Què es queda | Què respon | Com comproves que existeix |
|---|---|---|
| Especificacions | Què fa el sistema i amb quins criteris s'accepta | Són al teu repositori i algú del teu equip en pot explicar una sense llegir-la del proveïdor |
| Regles i permisos de l'agent | Què pot fer l'agent i què té prohibit | Són fitxers versionats, no instruccions dites en una reunió |
| Evals (casos amb resposta coneguda) | Com se sap que una resposta és bona | El teu equip els executa sense ajuda i entén per què en falla un |
| Qui signa què | On decideix una persona i amb quin criteri | Cada punt de decisió té un nom de la teva empresa, no del proveïdor |
| Guia d'operació | Què fer quan la qualitat baixa o el cost puja | Hi ha alertes, llindars i un procediment que el teu equip ja ha seguit una vegada |
Lectura pròpia d'onext; no és una norma ni una llista tancada
Cada fila té el seu desenvolupament. Els criteris d'acceptació poden convertir-se en la porta del merge, com expliquem a la teva spec ja és un eval. On ha de signar una persona és a specs i agents: on se signa. Les regles que comparteix un equip, a instruccions compartides i curades. I el que passa quan un agent arriba a producció sense evals ni monitoratge, a el gap de qualitat dels agents en producció.
Això no és una mania de documentació. DORA, el programa de recerca de Google sobre equips de programari, va trobar en els seus estudis del 2021 i el 2022 que la qualitat de la documentació interna impulsava l'adopció de totes les pràctiques tècniques que va analitzar. Aquest estudi no parla d'agents. Però apunta al mateix: el que no està escrit, o no es pot trobar, l'equip no ho pot fer servir.
Quatre preguntes per a la reunió d'inici
Abans de signar amb un equip extern, sigui un enginyer desplegat del fabricant, una consultora gran o una boutique, convé tenir aquestes respostes per escrit:
- En quin repositori viu el que construïu? Si la resposta és «a la nostra plataforma», pregunta què et podries endur si demà canviessis de proveïdor.
- Qui del meu equip treballa al vostre costat des de la primera setmana? El traspàs no és una reunió al final: és algú que ha vist prendre cada decisió.
- El meu equip pot executar els evals sense vosaltres? Si no pot, no pot saber si un canvi empitjora el sistema.
- Com comprovem que el traspàs ha funcionat? Una proposta raonable: el teu equip canvia una regla, executa els evals i desplega, sense trucar a ningú.
La primera pregunta és la mateixa que plantegem per decidir entre construir i comprar a l'enginyeria d'IA del pilot a producció: si d'aquí a dos anys volguessis canviar de proveïdor, què t'enduries?
Quan la dependència sí que compensa
Seria deshonest presentar la dependència com un error sempre. No ho és.
Per al que és infraestructura comuna i no et diferencia, dependre d'un proveïdor pot ser el més assenyat: és el marc de construir, comprar o portar un partner. I a16z té raó que algú ha de fer la feina dura d'integració; que la faci el proveïdor no és un abús, és el seu model de negoci.
El problema apareix en un altre lloc: quan el sistema codifica com treballa la teva empresa, les seves regles, les seves excepcions i els seus criteris de qualitat. Aquí el coneixement és el teu actiu. Si només existeix al cap d'un enginyer extern, no l'has comprat: l'has llogat.
Límit El que està escrit no ho transfereix tot. Hi ha criteri que només s'aprèn veient decidir, i per això la segona pregunta pesa tant com la primera. A més, documentar costa: DORA recorda que la documentació s'ha de crear i mantenir, i que això és feina. Un traspàs seriós es pressuposta; no surt gratis al final.
Com ho plantegem a onext
És el criteri amb què treballem en els projectes d'agents: el que construïm es queda al teu equip, i una persona decideix on hi ha risc. No és una promesa que el teu equip sigui autònom en un termini concret: és l'objectiu amb què comença el projecte, i les quatre preguntes de més amunt són les que ens pots fer a nosaltres.
Preguntes freqüents
Què és un forward deployed engineer?
És un enginyer de programari que treballa a casa del client per convertir un model o una plataforma en una solució que funcioni en la seva operació real: integracions, dades, seguretat i desplegament. a16z el descriu com l'equip que és més a prop del client i que porta el model a una solució del món real. Anthropic fa servir el nom Frontier Deployed Engineer per al seu programa de formació.
En què es diferencia d'un consultor?
Segons la prova que proposa KDnuggets, en si el que aprèn al client acaba canviant el que la seva empresa construeix després. Si aquest aprenentatge torna al producte del proveïdor, és un enginyer desplegat; si no, és consultoria amb un altre nom. Per al client, la diferència importa menys que una altra pregunta: què es queda a casa seva quan l'enginyer marxa.
Què hauria de quedar escrit en acabar un projecte d'agents amb un equip extern?
Com a mínim, cinc coses en un repositori teu: les especificacions del que fa el sistema, les regles i els permisos amb què treballa l'agent, els evals (casos amb resposta coneguda que el teu equip pot executar), qui signa cada decisió i la guia d'operació (alertes, costos i què fer quan la qualitat baixa).
Dependre d'un proveïdor extern és sempre un error?
No. Per al que és infraestructura comuna i no et diferencia, dependre d'un proveïdor pot ser l'opció assenyada. El problema apareix quan el sistema codifica com treballa la teva empresa i aquest coneixement només existeix al cap de qui el va construir. Aquí la dependència no es va comprar: es va deixar de demanar per escrit.
N'hi ha prou amb demanar documentació al final del projecte?
No. Un document escrit l'últim dia descriu el que algú recorda, no el que fa el sistema. El que funciona és que especificacions, regles i evals siguin el material amb què es treballa des del principi, i que algú del teu equip treballi al costat des de la primera setmana. DORA recorda, a més, que la documentació s'ha de crear i mantenir, i que això costa feina.
Com comprovo que el traspàs ha funcionat?
Amb una prova, no amb una reunió: el teu equip canvia una regla o un criteri, executa els evals sense ajuda del proveïdor i desplega el canvi. Si això és possible, el coneixement és a casa teva. Si cada canvi necessita tornar a trucar a l'equip extern, encara no.
Fonts
- Anthropic, «Claude Frontier Academy», 2 d'octubre de 2026 (consultat el 12 d'octubre de 2026).
- Joe Schmidt (a16z), «Trading Margin for Moat: Why the Forward Deployed Engineer Is the Hottest Job in Startups», 4 de juny de 2025.
- Matthew Mayo (KDnuggets), «Forward Deployed Engineer: AI's Hottest New Career, or Consulting With a Better Title?», 2 d'octubre de 2026.
- DORA, «Capabilities: Documentation quality», basat en els informes State of DevOps del 2021 i el 2022 (pàgina sense data; consultada el 12 d'octubre de 2026).
- Les cites de fonts en anglès són traduccions d'onext. La taula del que es queda i les quatre preguntes són lectura pròpia d'onext.
Bernat López és fundador i CEO d'onext, boutique d'IA. Acompanya equips de desenvolupament i de producte a treballar amb IA amb mètode —especificació abans de programar, una persona que decideix on hi ha risc i Spec-Driven Development— i aplica a la seva pròpia empresa el que proposa: onext funciona amb el seu propi sistema agèntic.
LinkedIn →