Jag säger på min egen hemsida att jag shipar ungefär 10× snabbare än jag kunde för några år sedan. Det stämmer, och anges utan kvalifikation det är vilseledande — för att multiplikatorn gäller vissa av arbetet och nästan inget av resten.
Eftersom den ärliga versionen är mer användbar för dig än marknadsversionen, här är den.
Vad blev faktiskt dramatiskt snabbare
- Allt jag skrivit förut. Auth-flöden, list-detail-skärmar, formulärvalidering, API-klienter, migreringar. Arbete som är väl förstådd men tråkig. Det här är en stor del av vilken verklig produkt som helst och det gick från dagar till timmar.
- Läsa okänd kod. Att bli slängd in i en 200 000-rad kodbas och behöva orientering på torsdag. Det här kanske är den enda största förändringen i mitt arbetsliv — och det är anledningen till att en en-timmas granskning nu kan säga något användbart.
- Tester. Det som alla underinvesterar i för att det är tråkigt är nu billigt nog att det inte finns någon ursäkt.
- Första utkast av allt. Inte något slutgiltigt. Men avståndet från blank sida till något att reagera på kollapsade, och att reagera är mycket snabbare än att skapa.
- Arbeta över stacks. Jag är en iOS-ingenjör från mitt yrke. Jag är nu faktiskt användbar i backend- och infrastrukturkod på ett sätt jag inte var, för syntaxbarriären försvann större delen.
Vad förändrades inte alls
- Veta vad man ska bygga. Ingen modell har träffat dina kunder. Den svåraste delen av produktarbete är att bestämma vad man inte ska göra, och det är oförändrat.
- Arkitektur beslut med en två-årig horisont. En modell kommer självsäkert att föreslå en struktur som fungerar idag och skadar om aderton månader. Att skilja de åt kräver att ha brunnit ut, vilket inte är något du kan prompta för.
- Felsöka den verkligt svåra buggen. Race-villkor, minnesproblem, det där kraschen bara på en enhet-modell. De tar fortfarande exakt lika lång tid som de alltid gjorde.
- Allt som kräver smak. Om en interaktion känns rätt. Om ett felmeddelande läses som hjälpsamt eller anklagande. Om produkten är bra.
- Samordning. Om tre personer behöver komma överens, AI gör dem inte överens snabbare.
Vad blev tyst värre
Det här är avsnittet som saknas från de flesta pitch-däcken, och det spelar roll om du köper.
Trolig felaktighet skalas vackert. Kod som ser rätt ut, läses väl, och är subtilt felaktig produceras nu snabbare än den kan granskas. Flaskhalsen flyttade från att skriva till verifiering, och team som inte flyttade sin uppmärksamhet med det shipar fler buggar, inte färre.
Kodbaser driver. Genererad kod tenderar mot genomsnittet av allt som någonsin skrivits, inte mot konventionerna för din projekt. Utan någon som aktivt håller gränsen är konsistensen eroderas — och konsistens är vad som gör en kodbas billig att ändra senare.
Juniorer lär sig annorlunda. Jag vet inte än om det är dåligt. Jag vet att förståelsen jag fick från att sitta fast i två dagar är inte uppenbart ersatt av att få ett svar på tjugo sekunder.
Vad det här betyder för vad du köper
Om en leverantör säger att AI gör dem 10× snabbare och därför ditt projekt tar en tiondel av tiden, de antingen översäljer eller de har bara gjort den tråkiga halvan någonsin.
Den ärliga versionen: konstruktionsfasen komprimerades enormt; beslutsfasen rörde sig inte. Så formen av ett projekt ändrades. Det brukade vara en kort tänkningsfas följd av månader av byggande. Det är nu en proportionellt mycket större tänkningsfas följd av en kort bygge.
Vilket är varför två-veckor sprints fungerar nu och inte gjorde det 2019. Inte för att ingenjörer blev snabbare på att skriva, utan för att förhållandet förändrades — och om du tillbringar de första dagarna med att besluta ordentligt, byggnaden passar faktiskt i fönstret.
Frågan att ställa en leverantör
Inte "använder du AI?" Alla säger ja.
Fråga: "hur verifierar du vad det producerar?" Svaret säger dig om du köper komprimerad leverans eller komprimerad noggrannhet. En av dessa är värd att betala för.
Och om du ärver en kodbas byggd det här sättet, granskningschecklistan spelar roll mer än den gjorde, inte mindre.