Hi ha una frase que sembla explicar tota la intel·ligència artificial aplicada al codi: un model de llenguatge prediu el token següent.
La frase és tècnicament útil. També pot ser enganyosa quan s’utilitza per descriure el producte complet.
Un autocomplete pren el context proper al cursor i proposa una continuació. Un agent de desenvolupament pot rebre un objectiu, explorar un repositori, consultar documentació, editar diversos fitxers, executar ordres, observar errors, tornar-ho a intentar i lliurar un diff per revisar.
En tots dos casos hi ha un model que genera tokens. El que canvia és el sistema construït al seu voltant.
Aquesta diferència importa perquè Cursor, Codex, Claude Code i Google Antigravity no aporten valor només perquè escriguin codi més de pressa. La seva utilitat apareix quan poden participar en una part més gran del cicle de desenvolupament: recuperar context, prendre decisions acotades, utilitzar eines, verificar resultats i retornar treball revisable.
També explica els seus límits. Un model pot produir codi convincent i incorrecte. Un agent pot convertir aquest error en canvis reals. Per això, com més gran és la capacitat d’execució, més importants es tornen els tests, els permisos, l’aïllament, l’observabilitat i la revisió humana.
En resum
Un LLM genera tokens. Un autocomplete utilitza aquesta capacitat per proposar una continuació local. Un agent la incorpora a un sistema que pot observar un entorn, seleccionar eines, executar accions i corregir-se a partir del resultat.
Això no converteix l’agent en un desenvolupador infal·lible ni elimina la necessitat d’una persona responsable. Significa que la unitat de treball deixa de ser únicament la línia següent i pot passar a ser una tasca completa, com reproduir un bug, afegir un test, actualitzar una dependència o preparar un pull request.
La utilitat real d’aquestes eines depèn de cinc condicions:
- L’objectiu està prou acotat.
- L’agent rep el context necessari.
- Existeixen senyals verificables, com tests, compilació o comportament visible.
- El canvi és reversible i revisable.
- El cost de controlar el resultat és menor que el treball evitat.
La pregunta correcta no és si l’eina “és autocomplete”. La pregunta és quina part del treball pot tancar de manera verificable i dins de quins límits.
Un LLM pot predir tokens sense que el producte sigui només autocomplete
Els models base de llenguatge s’entrenen per predir la unitat següent d’una seqüència. Aquesta unitat acostuma a expressar-se com a token, no necessàriament com una paraula completa. A partir del context anterior, el model assigna probabilitats a possibles continuacions i produeix una sortida.
Aquesta és la mecànica generativa.
Però un producte de desenvolupament incorpora altres capes:
| Capa | Què aporta |
|---|---|
| Model | Interpreta instruccions, relaciona informació i genera codi, plans o crides a eines. |
| Postentrenament | Ajusta el comportament per seguir instruccions, utilitzar eines i respectar determinats límits. |
| Context | Aporta fitxers, regles del repositori, historial, documentació, errors i decisions anteriors. |
| Agent | Gestiona el cicle de treball i decideix quina informació o eina necessita a continuació. |
| Eines | Permeten llegir, cercar, editar, executar ordres, utilitzar Git, consultar APIs o interactuar amb altres aplicacions. |
| Entorn | Retorna senyals reals: tests, compilació, logs, navegador, diff, estat d’una tasca o resposta d’un servei. |
| Controls | Limiten el filesystem, la xarxa, els secrets, les ordres, la identitat, el nombre d’intents i les accions sensibles. |
| Revisió humana | Comprova intenció, arquitectura, risc i alineació amb necessitats que no sempre estan documentades. |
Reduir tot el sistema a la predicció de tokens és com definir un navegador dient que executa instruccions de processador. No és fals, però no permet distingir-lo d’un full de càlcul, un videojoc o un servidor.
Per avaluar un agent cal observar el comportament del conjunt.
Autocomplete, assistent i agent no són la mateixa unitat de treball
L’evolució d’aquestes eines no és només una escala de “més codi generat”.
Autocomplete
Treballa a prop del cursor. Suggereix com continuar una funció, una condició, un test o una crida a una API.
La persona conserva el cicle complet:
pensar → escriure → executar → interpretar → corregirL’autocomplete redueix una part de l’escriptura.
Assistent conversacional
Pot explicar una arquitectura, proposar una funció, revisar un fragment o respondre preguntes sobre fitxers que rep com a context.
Amplia la capacitat d’anàlisi, però sovint la persona continua copiant informació cap al xat i traslladant la resposta al projecte.
Agent de desenvolupament
Rep un objectiu i pot operar dins de l’entorn:
objectiu
→ inspeccionar el repositori
→ formular un pla
→ editar
→ executar eines
→ observar el resultat
→ corregir
→ verificar
→ lliurar per revisarLa diferència no és només de longitud. És una diferència de control de flux.
Un agent pot triar quin fitxer llegir, quina ordre executar i quan la tasca requereix una altra iteració. Segons la definició utilitzada per OpenAI, el LLM controla l’execució del workflow i selecciona eines. Anthropic distingeix de manera semblant els workflows amb rutes predefinides dels agents que dirigeixen dinàmicament els seus processos i l’ús d’eines.
El feedback de l’entorn canvia la qualitat del treball
Un model pot generar una funció que sembla correcta. El terminal pot demostrar que no compila.
Pot proposar una migració. Els tests poden mostrar que trenca la compatibilitat.
Pot afirmar que ha corregit un problema visual. Un navegador controlat per l’agent pot revelar que el component encara desborda en mòbil.
El model no es torna determinista per això, però redueix la dependència d’una única resposta plausible. El sistema pot contrastar la generació amb evidència externa.
Per això el desenvolupament de programari és un terreny especialment adequat per als agents:
- existeix codi estructurat;
- moltes accions es poden executar en un entorn aïllat;
- els canvis queden representats com a diff;
- els tests ofereixen criteris d’acceptació;
- Git permet comparar, revertir i revisar;
- compiladors, linters i analitzadors generen senyals concrets.
La verificació automàtica tampoc no és suficient. Un test pot estar incomplet, una especificació pot ser ambigua i una solució pot passar la suite mentre empitjora l’arquitectura. L’entorn aporta ground truth parcial, no criteri total.
La revisió humana no nega que existeixi un agent
Un sistema no necessita publicar codi sense permís per ser un agent.
Suposem que rep aquesta tasca:
Localitza per què el checkout repeteix un cobrament davant d’un timeout, afegeix un test de regressió i prepara un canvi revisable.
Durant l’execució pot:
- cercar la lògica de reintents;
- reconstruir el recorregut entre diversos mòduls;
- llegir tests existents;
- reproduir la fallada;
- modificar dos o tres fitxers;
- executar la suite;
- corregir un error secundari;
- resumir la causa;
- presentar el diff.
Si una persona revisa aquest resultat abans del merge, el treball anterior no es converteix retroactivament en autocomplete.
La revisió defineix qui té autoritat per acceptar el canvi. També protegeix requisits que l’agent pot no conèixer: decisions de producte, convencions tàcites, dependències organitzatives, impacte operatiu o prioritats futures.
Convé separar capacitat d’autorització:
| Nivell | Capacitat del sistema | Autorització raonable |
|---|---|---|
| Assistència | Explica o proposa codi. | Pot respondre directament. |
| Investigació | Llegeix i diagnostica. | Accés només de lectura. |
| Preparació | Edita en una branca o worktree. | Escriptura acotada i tests. |
| Delegació | Completa una tasca i prepara un PR. | Revisió abans d’integrar. |
| Automatització | S’executa davant d’esdeveniments o cron. | Polítiques per tipus de tasca i límits de volum. |
| Operació sensible | Desplega, modifica dades o utilitza secrets. | Aprovació explícita, identitat separada i auditoria. |
L’autonomia útil no és “tot o res”. Es configura per acció, entorn i risc.
Què aporta Cursor
Cursor combina diverses superfícies dins d’un mateix producte.
Tab continua sent autocomplete: proposa continuacions mentre la persona edita. Agent pot cercar al codebase, llegir i modificar fitxers, utilitzar el terminal i accedir a eines MCP. Cursor CLI porta l’agent al terminal i als scripts. Els agents cloud poden treballar en màquines aïllades, provar canvis i produir artefactes com captures, vídeos o logs per acompanyar un pull request.
Aquesta combinació té un avantatge pràctic: permet canviar el nivell de delegació sense abandonar el flux de treball.
Una persona pot:
- escriure manualment una part sensible;
- acceptar una continuació local;
- demanar una edició sobre diversos fitxers;
- delegar un bug a un agent cloud;
- revisar el resultat des de l’IDE o GitHub.
Cursor és especialment útil quan el centre del treball continua sent l’editor i es vol incorporar agència de manera progressiva.
El risc també neix d’aquesta fluïdesa. És fàcil passar d’un suggeriment petit a una edició àmplia sense redefinir-ne l’abast. Per això convé revisar el pla, el diff i les ordres, i distingir les tasques exploratòries dels canvis que es poden integrar.
Què aporta Codex
Codex CLI treballa directament des del terminal. Pot inspeccionar codi, modificar fitxers, executar ordres, revisar canvis i automatitzar treball repetible. La configuració permet definir instruccions del projecte, permisos i modes de revisió.
Codex cloud canvia la dimensió temporal. Cada tasca pot rebre un entorn aïllat i reproduïble, continuar mentre la persona treballa en una altra cosa i tornar com un resultat revisable. També permet iniciar treball des de GitHub, Linear o Slack i executar diverses tasques en paral·lel.
El seu valor apareix en dos patrons.
Delegació tancada
La tasca té una condició de sortida reconeixible:
Actualitza aquesta API, conserva la compatibilitat, afegeix tests i retorna un diff.
La persona inverteix temps a especificar i revisar, no necessàriament a executar cada pas.
Paral·lelisme
Mentre un desenvolupador treballa en una decisió arquitectònica, diversos agents poden investigar bugs independents, preparar documentació o provar alternatives.
Aquest paral·lelisme no elimina el cost. Trasllada el coll d’ampolla cap a l’especificació, l’avaluació i la integració. Si deu agents produeixen deu canvis mediocres, l’organització no ha multiplicat la productivitat: ha multiplicat la cua de revisió.
Què aporta Claude Code
Claude Code es va orientar originalment al terminal, però actualment també funciona en IDE, escriptori i navegador. Pot llegir el codebase, editar fitxers, executar ordres, treballar amb Git, crear pull requests i connectar eines externes mitjançant MCP.
L’extensibilitat és una part important del producte.
Un fitxer CLAUDE.md pot aportar regles persistents del projecte. Les skills encapsulen procediments reutilitzables. Els servidors MCP connecten sistemes com issue trackers, observabilitat o documentació. Els hooks executen controls en punts específics del cicle.
Els hooks mostren molt bé la diferència entre model i sistema.
No cal confiar que el LLM recordi executar el formatador després de cada edició. Un hook determinista ho pot fer sempre. Tampoc cal esperar que decideixi tot sol bloquejar una ordre perillosa: una regla pot validar-la abans de l’execució.
Claude Code encaixa especialment bé quan l’equip vol construir un entorn agentiu al voltant del terminal, Git, scripts i eines internes.
Què aporta Google Antigravity
Google Antigravity separa de manera explícita l’edició directa de la coordinació d’agents.
L’IDE inclou compleció, ordres i un agent capaç d’operar sobre editor, terminal i navegador. Antigravity 2.0 afegeix una superfície de gestió per llançar, observar i coordinar diversos agents sobre projectes i workspaces diferents. Els subagents poden dividir parts d’un problema, les tasques programades permeten automatitzar treballs recurrents i els artefactes mostren plans, resultats i evidència de verificació.
L’abstracció central ja no és “una conversa amb el codi”, sinó una cartera de tasques.
Això resulta útil quan el treball es pot dividir:
- un agent investiga la causa;
- un altre prepara tests;
- un altre valida la interfície;
- un altre revisa una migració;
- la persona compara artefactes i decideix què integrar.
El repte és organitzatiu. Com més agents treballen en paral·lel, més important és evitar solapaments, conflictes, objectius ambigus i revisions superficials.
No hi ha una eina universalment millor
Les quatre eines se superposen i les seves capacitats canvien ràpidament. La decisió hauria de partir del flux, no del rànquing.
| Necessitat principal | Eina que convé avaluar | Motiu |
|---|---|---|
| Romandre dins de l’IDE i alternar entre Tab, edició i agent | Cursor | Integra diferents nivells d’assistència a la mateixa superfície. |
| Treballar des del terminal i delegar tasques a entorns cloud | Codex | Combina execució local, automatització i treball aïllat en paral·lel. |
| Personalitzar regles, hooks, skills i connexions amb sistemes interns | Claude Code | Ofereix una superfície extensible al voltant del terminal i les eines. |
| Coordinar diversos agents i projectes mitjançant artefactes | Antigravity | Prioritza orquestració, subagents, tasques programades i gestió de resultats. |
| Automatitzar tasques repetitives en CI o davant d’esdeveniments | Cursor, Codex o Claude Code | Tots tres ofereixen modes programàtics; l’elecció depèn de permisos i integracions. |
| Mantenir màxima supervisió en canvis sensibles | Qualsevol amb l’entorn correcte | El control depèn més de permisos, branques, tests i aprovacions que de la marca. |
La comparació s’hauria de repetir periòdicament. En aquest mercat, una taula de funcionalitats envelleix de pressa. Les preguntes més estables són:
- On viu el context?
- Quines eines pot utilitzar?
- Com aïlla l’execució?
- Quina evidència retorna?
- Com es revisa el resultat?
- Quines accions necessiten aprovació?
- Quant costa operar i controlar el flux?
D’on ve la utilitat real
El benefici no es limita a teclejar menys.
Recuperar context
Una part considerable del treball tècnic consisteix a trobar fitxers, reconstruir decisions, seguir crides, llegir logs i recordar com s’executa un projecte.
Un agent pot reduir aquest cost d’orientació, especialment en repositoris desconeguts o tasques que travessen diverses capes.
Tancar bucles de verificació
Generar codi és barat. Comprovar-lo acostuma a ser el treball important.
Quan l’agent pot executar tests, llegir l’error i corregir, absorbeix una part d’un cicle que abans exigia atenció contínua.
Evitar canvis de context
Un bug petit pot trigar poc a resoldre’s, però interromp una tasca més valuosa. Delegar-lo a un entorn separat pot aportar més que accelerar els minuts d’implementació.
Abordar el backlog de baixa prioritat
Documentació, tests que falten, migracions repetitives, actualitzacions mecàniques i fallades intermitents se solen ajornar perquè no justifiquen una interrupció.
Un agent pot reduir el cost d’iniciar aquests treballs.
Explorar alternatives en paral·lel
Per a una decisió reversible, diversos intents independents poden revelar solucions, riscos o diferències d’implementació abans de comprometre temps de l’equip.
El paral·lelisme només aporta valor si després hi ha un criteri eficient per comparar.
L’evidència sobre productivitat és mixta
No existeix una xifra universal que indiqui quant accelera un agent de desenvolupament.
Un assaig controlat de METR, fet amb eines de principis de 2025, va trobar que 16 desenvolupadors experimentats que treballaven en repositoris que coneixien van trigar un 19% més quan podien utilitzar IA. Tot i això, els participants creien que havien treballat més de pressa.
Aquest resultat no s’hauria d’extrapolar sense cura. METR el presenta actualment com a històric i assenyala que ja no reflecteix necessàriament les eines de 2026. L’estudi es va concentrar en desenvolupadors experts, repositoris madurs i tasques reals d’entre aproximadament vint minuts i quatre hores.
El febrer de 2026, METR va publicar dades posteriors amb senyals d’acceleració, però va considerar que l’estimació no era fiable. Alguns desenvolupadors evitaven participar perquè no volien quedar assignats a treballar sense IA; a més, l’ús simultani de diversos agents dificultava mesurar el temps humà invertit.
Un estudi de camp sobre el desplegament de Claude Code i Copilot CLI a Microsoft durant els primers mesos de 2026 va trobar que els adoptants van fusionar aproximadament un 24% més de pull requests que l’estimació contrafactual. Els mateixos autors adverteixen que un PR fusionat és un proxy d’output, no una mesura directa de valor, qualitat o impacte.
També hi ha un cost d’aprenentatge. Un assaig d’Anthropic amb 52 desenvolupadors va trobar que el grup assistit per IA va obtenir un resultat de comprensió un 17% inferior mentre aprenia una biblioteca nova. Va acabar només uns minuts abans, però aquesta diferència de temps no va ser estadísticament significativa. Els participants que van utilitzar la IA per demanar explicacions i construir comprensió van conservar més coneixement que els que van delegar la solució.
Aquestes investigacions mesuren situacions diferents. En conjunt suggereixen una cosa més útil que una xifra mitjana:
La productivitat depèn del tipus de tasca, el coneixement previ, l’eina, la forma d’ús, la possibilitat de verificar i la mètrica escollida.
On solen funcionar millor
Una tasca encaixa bé quan reuneix diverses d’aquestes propietats.
Objectiu concret
“Millora l’arquitectura” deixa massa decisions obertes.
“Extreu aquesta validació a un mòdul, conserva l’API pública i afegeix tests per a aquests casos” defineix millor l’abast.
Resultat verificable
Compilació, tests, lint, tipus, snapshots, benchmarks o comportament del navegador permeten comprovar el progrés.
Canvi reversible
Una branca, worktree, patch o entorn cloud aïllat redueix el cost d’un intent fallit.
Context accessible
El repositori inclou instruccions, ordres, convencions, exemples i decisions tècniques. L’agent no necessita endevinar tot allò que sap l’equip.
Revisió acotada
El diff és comprensible i el resultat inclou una explicació, les ordres executades i els riscos pendents.
Amb aquestes condicions, solen ser bons candidats:
- bugs acotats amb test de regressió;
- refactors mecànics;
- actualització de dependències;
- migracions repetitives;
- generació o ampliació de tests;
- investigació d’errors de CI;
- documentació vinculada al codi;
- prototips descartables;
- anàlisi inicial d’un repositori;
- preparació d’un pull request per revisar.
On poden empitjorar el treball
La utilitat baixa quan:
- el requeriment és ambigu;
- les regles de negoci no estan documentades;
- no existeix una manera de validar el resultat;
- el canvi travessa massa sistemes;
- hi ha decisions de producte pendents;
- el repositori contradiu les seves pròpies convencions;
- l’agent rep permisos o secrets innecessaris;
- revisar el codi costa més que escriure’l;
- l’equip accepta output que no pot explicar;
- una persona en formació delega precisament el raonament que necessita aprendre.
Un altre risc és mesurar activitat en lloc de progrés.
Més línies, commits o pull requests poden significar més valor. També poden significar més volum per revisar, més duplicació i més deute tècnic.
La unitat correcta és treball completat i validat
Per avaluar aquestes eines convé abandonar la pregunta “quant codi ha generat?” i observar el flux complet.
| Dimensió | Mètrica útil |
|---|---|
| Velocitat | Temps des de la tasca fins a un diff revisable. |
| Atenció humana | Minuts actius d’especificació, seguiment i revisió. |
| Acceptació | Percentatge del canvi conservat sense reescriptura substancial. |
| Retraball | Correccions necessàries després del primer lliurament o del merge. |
| Qualitat | Regressions, incidents, resultats de tests i defectes trobats en revisió. |
| Flux | Temps des de la issue fins al merge i temps bloquejat. |
| Cobertura | Treball útil que abans quedava sense fer. |
| Cost | Llicències, tokens, infraestructura, execucions i revisió. |
| Risc | Permisos excessius, exposició de dades, accions externes i incidents. |
| Aprenentatge | Capacitat de l’equip per explicar, depurar i mantenir el resultat. |
Una fórmula conceptual seria:
valor net =
temps humà evitat
+ treball addicional útil
+ millora de qualitat
+ valor del paral·lelisme
- temps d'especificació i revisió
- retraball
- cost d'execució
- risc introduït
- pèrdua de comprensióNo tots els termes són fàcils de monetitzar. Tot i així, la fórmula obliga a mirar més enllà de la velocitat aparent.
Com ho plantejaria Nicolás Torres
No començaria comprant una eina per a tot l’equip ni exigint una quota d’ús.
Començaria triant tres tipus de tasca reals, freqüents i comparables. Per exemple:
- correccions petites amb test de regressió;
- diagnòstic d’errors de CI;
- actualització de documentació o dependències.
Després establiria una línia base:
- temps total;
- temps humà actiu;
- nombre d’intents;
- temps de revisió;
- retraball;
- defectes posteriors;
- cost d’interrupció;
- percentatge de tasques abandonades.
El pilot utilitzaria un entorn acotat:
- instruccions del repositori;
- branca o worktree separat;
- filesystem limitat;
- secrets fora d’abast;
- xarxa controlada;
- ordres definides;
- tests obligatoris;
- aprovació abans d’integrar;
- registre d’accions suficient.
Després de diverses setmanes, compararia per tipus de tasca i perfil d’usuari. No barrejaria un bug mecànic amb una decisió arquitectònica ni una persona experta en el repositori amb algú que s’hi acaba d’incorporar.
També reservaria espais de treball sense delegació per a l’aprenentatge. Un equip que produeix més codi però perd capacitat per entendre’l i corregir-lo està traslladant risc cap al futur.
L’autonomia creixeria únicament on el resultat demostrés valor:
llegir
→ proposar
→ editar en aïllament
→ executar amb risc baix
→ preparar un PR
→ automatitzar tasques repetiblesDesplegar, modificar dades reals o utilitzar credencials sensibles seguiria un altre procés.
Què hauria de quedar clar en triar una eina
Abans de comparar models o plans, demanaria respostes concretes a aquestes preguntes:
- Pot treballar sobre tot el repositori o només sobre context seleccionat?
- Quines accions executa localment i quines al cloud?
- Com es reprodueixen les dependències i les variables de l’entorn?
- Quins permisos té sobre fitxers, terminal, xarxa i eines externes?
- Pot separar cada tasca en una branca, worktree o màquina aïllada?
- Quins artefactes retorna per revisar?
- Com registra ordres, tool calls i decisions?
- Què passa quan falla un test o supera el nombre d’intents?
- Com s’evita que llegeixi secrets?
- Com es calcula el cost real, incloent-hi revisió i retraball?
La millor eina no és la que genera la demo més impressionant. És la que millora un flux concret sense fer opac el risc.
Conclusió
Un model de llenguatge prediu tokens. Aquesta descripció explica una part essencial del seu funcionament.
No explica per si sola què és un agent de desenvolupament.
Un autocomplete utilitza la predicció per suggerir una continuació. Un agent la insereix en una arquitectura amb context, eines, estat, execució, feedback, permisos i condicions de sortida.
Cursor, Codex, Claude Code i Antigravity són útils quan aquesta arquitectura permet tancar una part verificable del treball:
comprendre
→ actuar
→ comprovar
→ corregir
→ lliurarNo són infal·libles. No fan valuosa qualsevol tasca. No substitueixen automàticament el criteri, l’arquitectura, el coneixement de negoci ni la responsabilitat humana.
Però tampoc s’expliquen correctament com a sistemes que només escriuen la línia següent.
La pregunta que hauria de guiar-ne l’adopció és més exigent:
Quin treball útil pot completar aquest agent, quina evidència retorna, quant esforç humà evita i quins límits necessita perquè el resultat sigui fiable?
Quan aquesta pregunta té una resposta mesurable, la discussió deixa de ser semàntica. Passa a ser una decisió d’enginyeria.
Preguntes freqüents
- Un LLM és només un sistema d'autocomplete?
- En el seu mecanisme generatiu, un LLM prediu el token següent a partir del context. Però aquesta descripció no és suficient per explicar un producte complet: el postentrenament, el context, les eines, la memòria, l'entorn d'execució i els controls canvien allò que el sistema pot fer.
- Què diferencia un autocomplete d'un agent de desenvolupament?
- L'autocomplete proposa una continuació local. Un agent rep un objectiu, explora el repositori, selecciona eines, edita fitxers, executa ordres, observa resultats i pot iterar fins a lliurar un canvi verificable.
- Cursor, Codex, Claude Code i Antigravity fan el mateix?
- Comparteixen capacitats agentives, però prioritzen superfícies diferents. Cursor integra compleció, IDE, CLI i agents cloud; Codex combina terminal i delegació en entorns aïllats; Claude Code destaca pel terminal, l'extensibilitat, els hooks i MCP; Antigravity s'orienta a coordinar agents, projectes i artefactes.
- Que una persona revisi el codi significa que el sistema no és un agent?
- No. La revisió humana defineix autoritat i responsabilitat. Un agent pot investigar, editar, provar i preparar un pull request, i tot i així aturar-se abans d'integrar o desplegar perquè aquesta acció requereix aprovació.
- Aquestes eines sempre augmenten la productivitat?
- No. L'evidència mostra resultats diferents segons l'eina, la tasca, l'experiència, el repositori i la mètrica. Poden accelerar treball acotat i verificable, però també augmentar la revisió, el retraball o la pèrdua de comprensió.
- Com les hauria d'avaluar una empresa?
- Amb tasques reals, una línia base i mètriques de treball completat: temps humà actiu, temps fins a un diff revisable, acceptació, retraball, regressions, cost, risc i capacitat de l'equip per mantenir el resultat.