Quan la IA va Fer que Construir Fos Més Barat que les Reunions per Planificar-ho
Vam debatre una funcionalitat durant setmanes. Després algú la va construir en un dia amb IA. Quan l'execució costa menys que la coordinació, les reunions es converteixen en el coll d'ampolla. Això està reconfigurant com treballen els equips de software.
Prototipar és Ara Ràpid i Barat
Podem construir coses més ràpid i barat que mai. Els efectes de segon ordre són profunds. Quan l'execució és barata, tot l'aparell que vam construir al voltant de l'execució cara—reunions de planificació, revisions de disseny, cerimònies de sprint, rituals d'estimació—comença a semblar sobrecàrrega (overhead).
Un exemple real de Buffer: Teníem un projecte que va ser desprioritzat. La funcionalitat tenia un valor clar. La lògica del backend ja existia en un servei legacy, però necessitava ser migrada als nostres nous sistemes—noves APIs, nou frontend, nous patrons. El projecte seguia caient en el backlog perquè l'esforç estimat era significatiu: propostes de disseny de backend, revisions d'arquitectura, dissenys de frontend, múltiples rondes de feedback. Vam passar més temps discutint si havíem de construir-ho del que hagués pres simplement construir-ho.
Llavors un dels meus companys va decidir simplement fer-ho. Amb Claude Code i unes poques iteracions, tenia un prototip funcional de tot el projecte en menys d'un dia.
El prototip no estava llest per a producció—necessitava neteja i tests adequats—però seguia els nostres patrons perquè hem ensenyat a les nostres eines d'IA les convencions de la nostra base de codi. Refactoritzar codi funcional que segueix la teva arquitectura és molt més fàcil que reescriure alguna cosa construïda amb patrons aliens.
Les matemàtiques se senten surreals. Vam passar dies en reunions, redactant especificacions, debatent enfocaments—tot per concloure "ara no, massa car". Mentrestant, la implementació real va prendre hores.
El Cost de Coordinació Ara Supera el Cost d'Execució
Hem creuat un llindar on la coordinació sovint costa més que l'execució. La reunió per discutir una funcionalitat—alinear els interessats, reunir requisits, obtenir aprovació—pot prendre més temps que implementar aquesta funcionalitat amb assistència d'IA.
Això inverteix dècades d'economia del software. Les reunions de planificació existien perquè mesura dues vegades, talla una tenia sentit quan tallar era car. Quan tallar és barat, mesura una vegada, talla, mira el resultat, talla de nou, i deixa que el bucle d'iteració serveixi com el procés de planificació.
Construeix Primer, Després Reacciona
El vell flux de treball: Especificació → Aprovació → Construcció → Demo → Feedback → Iterar.
El flux de treball emergent és: Construir → Demo → Feedback → Iterar. L'especificació emergeix de les iteracions.
Això funciona perquè la gent lluita per articular desitjos abstractes. "Què hauria de mostrar el dashboard?" produeix respostes vagues. Però "És útil aquest dashboard?" produeix feedback específic i accionable. Mostra a algú un prototip funcional i pregunta "Què està malament amb això?"—obtindràs millors requisits en tres iteracions que en deu hores de reunions de requisits.
El prototip es converteix en l'especificació funcional. No escrius un document descrivint el que el software hauria de fer; construeixes software que fa alguna cosa i refines des d'aquí. La intenció i les restriccions encara es documenten—però la mecànica es defineix mitjançant codi funcional.
Producte i Disseny Necessiten Adaptar-se També
Aquest canvi no és només sobre enginyeria. Els processos de producte i disseny també van ser construïts sota l'assumpció que la implementació és cara. Quan construir era lent, tenia sentit invertir fortament en wireframes, mockups i PRDs—proxies per a la cosa real que eren més barats d'iterar que el software real.
Aquest càlcul ha canviat. Per a funcionalitats amb molta interacció—dashboards, formularis, fluxos de treball—els mockups d'alta fidelitat sovint prenen més temps que construir la cosa real. Però això no significa saltar-se el design thinking per complet. Un esbós ràpid o wireframe combinat amb prototipatge ràpid amb IA et permet explorar possibilitats més ràpid que qualsevol dels enfocaments per separat.
El disseny no és obsolet. Els dissenyadors i product managers es converteixen en crítics i directors—reaccionant a prototips funcionals i guiant-los cap a bones solucions en lloc d'escriure especificacions per avançat.
Com Són les Empreses AI-Native
Les empreses que abracen aquest canvi no només usen IA—es tornen AI-native. Els seus processos, terminis i expectatives es reestructuren al voltant del que ara és possible.
Anthropic és l'exemple més clar. Claude Code es va llançar al febrer de 2025 i va estar disponible de forma general al maig. Sis mesos després, va assolir $1.000 milions en ingressos anualitzats. Però el més cridaner és com van construir sobre aquest impuls.
Al gener de 2026, Anthropic va llançar Cowork—un agent d'escriptori que porta el poder de Claude Code a usuaris no tècnics. Un equip de quatre enginyers va construir tot el producte en aproximadament deu dies, usant Claude Code. L'eina de codi amb IA va construir el seu propi germà no tècnic.
En una empresa tradicional, un producte com Cowork prendria mesos de recollida de requisits, revisions de disseny, propostes d'arquitectura i alineació de stakeholders. Anthropic es va saltar tot això. Van notar que els usuaris estaven forçant Claude Code a fer tasques no relacionades amb codi—investigació de vacances, presentacions, neteja d'emails—i en lloc de debatre si construir una solució, simplement la van construir.
Però Anthropic construeix IA. Què passa amb les empreses que només la usen?
Sentry va construir el seu servidor MCP usant Claude Code. El resultat és excel·lent—prou bo com per fer-me reconsiderar la nostra pròpia configuració de seguiment d'errors. Quan la teva integració és millor perquè la IA va ajudar els teus enginyers a construir-la més ràpid i iterar més, aquesta és l'avantatge competitiu en acció.
Lovable va assolir $100 milions en ingressos anuals vuit mesos després del seu llançament. Van arribar a $200 milions d'ARR només quatre mesos després. Amb un equip d'aproximadament 45 persones. Tota la plataforma està impulsada per Claude, i quan es va llançar Claude 4, el seu CEO va publicar que "va esborrar la majoria dels errors de Lovable". No estan construint IA—estan construint sobre ella, i llançant a un ritme que hagués estat impossible amb cicles de desenvolupament tradicionals.
Aquesta és l'avantatge competitiu de les empreses AI-native: validen idees amb software funcional en lloc de presentacions, i iteren en dies en lloc de trimestres. Les empreses que descobreixin això superaran les que encara executen cicles de planificació tradicionals.
Construeix Ràpid, Però Fes-te Responsable del que Llances
Hi ha un risc aquí que val la pena nomenar: només perquè alguna cosa sigui barata de construir no significa que hagi d'existir. Un backlog en expansió no és bo—pot portar a saturació de funcionalitats i productes desenfocats. La nova disciplina: "hauria d'existir això en absolut?"
Aquesta és la paradoxa de l'execució barata: perquè podem construir més ràpid, necessitem un judici més agut sobre què construir. La vella restricció—"això prendria massa temps"—forçava la priorització. Sense ella, podem construir eficientment les coses incorrectes. El pensament de "construir primer" requereix més disciplina de producte, no menys.
Una altra disciplina es torna més important: la revisió de codi.
El Vibe Coding No Pertany a Producció
"Vibe coding"—llançar codi generat per IA que no entens—és temptador quan construir és tan ràpid. El prototip funciona, els tests passen, per què no simplement fer merge? Perquè algú ha de ser responsable quan falli a les 3am.
Cada canvi a producció hauria de ser revisat per algú que estarà de guàrdia per a aquest sistema. Aquesta saviesa és anterior a la IA. La diferència és que la IA fa més fàcil produir codi que funciona sense entendre per què funciona. Això està bé per a exploració. És perillós per a producció.
Això és sobre responsabilitat operacional, no sobre gatekeeping. Els no enginyers absolutament poden usar IA per construir prototips útils. Però la restricció per a producció no és l'habilitat tècnica—és la responsabilitat operacional. Si no et trucaran quan el sistema falli, els teus canvis necessiten revisió d'algú a qui sí trucaran. El revisor no està bloquejant la teva contribució; està acceptant la responsabilitat per ella.
Els enginyers aporten coneixement que la IA no reemplaça: experiència operacional i la saviesa acumulada d'haver estat trucat a les 3am per problemes que es veien bé en testing. La IA fa els enginyers més ràpids; no els fa innecessaris.
Això crea una porta de qualitat natural que escala amb l'acceleració de la IA. Construeix tan ràpid com vulguis, prototipa lliurement, però el camí a producció passa per algú que assumeixi les conseqüències, i aquesta responsabilitat separa les demos dels deployments.
La Feina Canvia, Però No Desapareix
El que està canviant és la naturalesa de la feina. Menys temps escrivint boilerplate. Més temps entenent problemes, dirigint la IA, revisant resultats i prenent decisions de judici. El desenvolupador es converteix en un director de codi.
Això requereix habilitats diferents. La claredat es torna primària—necessites articular una intenció precisa perquè la IA executa instantània i literalment. Una entrada vaga produeix una sortida incorrecta immediata i concreta. Depurar codi generat per IA és una habilitat diferent: estàs avaluant les eleccions d'implementació d'un altre, no raonant a través de les teves pròpies intencions.
La revisió es torna més important, no menys. Quan qualsevol pot generar codi plausible, l'habilitat d'avaluar aquest codi—detectar bugs subtils, entendre implicacions de rendiment, anticipar casos límit—és el que separa el software funcional de les bombes de temps. Els enginyers que prosperin seran aquells que puguin dirigir la IA efectivament i després avaluar críticament el que produeix.
La feina sempre ha estat resoldre problemes amb software. La IA elimina la pretensió que es tractava de teclejar.
Estem d'hora en aquest canvi. Les eines estan evolucionant ràpidament, i tots estem descobrint nous fluxos de treball en temps real. Però la direcció és clara: l'execució és barata, la coordinació és cara, i construir és la nova forma de pensar.
La pregunta és com de ràpid pots adaptar-te mentre segueixes fent-te responsable del que llances.