Jeg sier på min egen hjemmeside at jeg shipper omtrent 10× raskere enn jeg kunne for noen år siden. Det er sant, og angitt uten kvalifikasjon er det misvisende — fordi multiplikatoren gjelder noen av arbeidet og nesten ingen av resten.
Siden den ærlige versjonen er mer nyttig for deg enn markedsføringsversjonen, her er den.
Hva som genuint ble dramatisk raskere
- Alt jeg har skrevet før. Auth flows, list-detail screens, form validation, API clients, migrations. Arbeid som er godt forstått men kjedelig. Dette er en stor andel av ethvert ekte produkt og det gikk fra dager til timer.
- Lesing av ukjent kode. Å bli kastet inn i en 200 000-linjer kodebase og trenge orientering innen torsdag. Dette kan være den enkelte største endringen i arbeidslivet mitt — og det er grunnen til at en en-times revisjon nå kan si noe nyttig.
- Tester. Tingen alle underinvesterer i fordi det er kjedelig er nå billig nok til at det ikke er noen unnskyldning.
- Første utkast av alt. Ikke noe sluttprodukt. Men avstanden fra blank side til noe å reagere på kollapset, og reagering er mye raskere enn kreering.
- Arbeid på tvers av stacks. Jeg er en iOS ingeniør etter yrke. Jeg er nå genuint nyttig i backend og infrastrukturkode på en måte jeg ikke var, fordi syntaksbariæren for det meste forsvant.
Hva som ikke endret seg i det hele tatt
- Å vite hva man skal bygge. Ingen modell har møtt kundene dine. Den hardeste delen av produktarbeid er å bestemme hva man ikke skal gjøre, og det er uendret.
- Arkitektursbeslutninger med en to-års horisont. En modell vil selvsikkert foreslå en struktur som fungerer i dag og gjør vondt om atten måneder. Å fortelle dem fra hverandre krever å ha blitt brent, som ikke er noe du kan prompte for.
- Debugging den virkelig vanskelige buggen. Race conditions, memory issues, den ene krasjen bare på en enhetmodell. Disse tar fortsatt nøyaktig like lang tid som de alltid gjorde.
- Alt som krever smak. Om en interaksjon føles riktig. Om en feilmelding leses som hjelpsom eller anklaugende. Om produktet er bra.
- Koordinasjon. Hvis tre personer må bli enige, gjør AI dem ikke enige raskere.
Hva som stille ble verre
Dette er delen som mangler fra de fleste pitch decks, og det betyr noe hvis du kjøper.
Plausibel wrongness skaleres vakkert. Kode som ser riktig ut, leser godt, og er subtilt feil produseres nå raskere enn den kan bli gjennomgått. Flaskehalsen flyttet fra skriving til verifisering, og team som ikke flyttet oppmerksomheten med den shipper mer bugs, ikke færre.
Kodebaser driver. Generert kode tenderer mot gjennomsnittet av alt som noen gang ble skrevet, ikke mot konvensjonene til ditt prosjekt. Uten noen som aktivt holder linjen, eroderer konsistens — og konsistens er hva som gjør en kodebase billig å endre senere.
Juniorer lærer annerledes. Jeg vet ikke ennå om det er dårlig. Jeg vet at forståelsen jeg fikk fra å være fast i to dager er ikke åpenbart erstattet av å få et svar på tjue sekunder.
Hva dette betyr for hva du kjøper
Hvis en leverandør forteller deg at AI gjør dem 10× raskere og derfor tar prosjektet ditt en tiendedel av tiden, selger de for høyt eller de har bare gjort den kjedelige halvdelen.
Den ærlige versjonen: konstruksjonsfasen komprimert enormt; beslutningsfasen flyttet ikke. Så formen på et prosjekt endret seg. Det pleide å være en kort tenkefase etterfulgt av måneders bygging. Det er nå en proporsjonalt mye større tenkefase etterfulgt av en kort bygging.
Hvilket er hvorfor to-ukers sprinter fungerer nå og ikke i 2019. Ikke fordi ingeniører ble raskere til å skrive, men fordi forholdet endret seg — og hvis du bruker de første dagene på å bestemme ordentlig, passer byggingen genuint inn i vinduet.
Spørsmålet å stille en leverandør
Ikke "bruker dere AI?" Alle vil si ja.
Spør: "hvordan verifiserer dere hva det produserer?" Svaret forteller deg om du kjøper komprimert levering eller komprimert due diligence. En av disse er verdt å betale for.
Og hvis du arver en kodebase bygget på denne måten, betyr revisjonssjekklisten mer enn den gjorde før, ikke mindre.