Där du börjar är där du stannar

Jag körde en workshop med sex utvecklare nyligen. Samma uppgift: designa en audit log-komponent för en riktig kundkodbas. Samma brief, samma material, samma vecka att arbeta innan vi möttes igen.

När vi möttes hade sex radikalt olika saker byggts.

En utvecklare hade en fungerande RabbitMQ publisher/consumer med ett polerat UI. En hade fyra parallella loggmetoder designade i detalj men ingen kod ännu. En hade en dual-store-arkitektur med OpenSearch och ett komplett läs-gränssnitt. En hade en fullständig PRD, software requirements-spec och arkitekturdokument - och inte en enda rad kod. En hade ett ramverk fokuserat helt på vem som skulle använda audit-loggen och vilka indikatorer de skulle behöva. En hade inte börjat.

I några minuter trodde jag att teamet hade misslyckats med att konvergera. Sedan insåg jag att mångfalden var datan.

Startpunkten kodar in en bias

Varje utvecklare valde var de skulle börja. Det valet - oftast omedvetet - bestämde allt som följde.

Den med det fungerande RabbitMQ-systemet började genom att fråga "vad ska det spåra?" Det är en datamodellsfråga. En backend-ingenjörs standardupplägg. Han byggde nedströms från data.

Den med fyra parallella metoder började från "hur ska detta integreras med befintlig kodbas?" Det är optionalitetsbias. Han designade flera vägar så teamet kunde välja senare. Metodisk. Risk-avers.

Den med den fullständiga OpenSearch-implementationen började från "vilka arkitekturalternativ har jag?" Forskningsdriven. Han hade nyligen läst om dual-store-design och valde differentieraren medvetet. Hans första drag var att be Codex om tre alternativ innan han rörde någon kod.

Den med fullständig spec men ingen kod började från "vad behöver systemet egentligen vara?" Specifikationsbias. Han var CTO. Han hade skrivit riktlinjerna teamet jobbar efter. Hans standard är rigorös top-down-design.

Den fokuserad på användaren började från "vem är det för, och vilka slutsatser kommer de dra?" Det är en produkt/slutanvändar-bias. Han var VD. Audit-loggen var för honom ett beslutsstöd, inte en logg.

Den som inte hade börjat alls - ja, det är en annan fråga. Men hans erkännande satte tonen för hela rummet.

Där du börjar är där du alltid kommer börja

Här är det som ingen berättade för dessa utvecklare när de fick uppgiften: deras startpunkt är inte en egenskap hos uppgiften. Den är en egenskap hos dem.

Samma person kommer upprepa samma startdrag på nästa uppgift. Och den efter den. Backend-ingenjörer kommer börja från data även när uppgiften i grunden handlar om användarflöde. CTO:er kommer börja från spec även när uppgiften är liten nog att bara skriva. Produktinriktade personer kommer börja från "vem är det för" även när målgruppen är uppenbar. Vi väljer inte startpunkter - vi känner igen dem i efterhand, eller så känner vi inte igen dem alls.

Det är inte ett misslyckande. Biasen är vanligtvis korrekt för den typ av arbete personen normalt gör. Backend-ingenjörens data-först-instinkt är vad som gör honom bra på backend. CTO:ns spec-först-instinkt är vad som gör hans riktlinjer koherenta. Produktpersonens användar-först-instinkt är vad som gör honom till en användbar produktperson.

Men när uppgiften inte är den de är optimerade för, missar biasen. Och eftersom biasen är omedveten är missen osynlig.

Första hävstången är att lägga märke

Du kan inte ändra ditt standardstartdrag genom att försöka hårdare. Du ändrar det genom att lägga märke till det.

Detta är den enskilt mest användbara övning jag hittat för team som arbetar med AI: fråga var och en, efter att de avslutat något, var började du? Inte vad du byggde. Inte vilken modell du använde. Var började du.

Svaren klustras. Backend-ingenjörer beskriver datan först. Frontend-ingenjörer beskriver användarinteraktionen. Arkitekter beskriver kontrakten och gränserna. Operations-folk beskriver deployen och övervakningen. PM:er beskriver användarhistorien.

Gör startpunkterna synliga för teamet. Plötsligt ser alla: aha, det är vad vi alltid gör. Jag börjar alltid där. Biasen är i rummet.

"Det första jag brukar göra med varje projekt är att läsa strukturen av loggfilerna."

Det var en utvecklare som beskrev sitt tillvägagångssätt. Inte fel. Inte rätt. Bara hans standard. När han väl namngett det hade han ett val nästa gång.

Varför det här spelar mer roll med AI

I förra-AI-mjukvaruutveckling spelade din startbias mindre roll. Kod tog tillräckligt lång tid att skriva att du skulle stöta på biasens felfunktioner och korrigera mitt i flykten. Slitet med att skriva skyddade dig.

Med AI-assistans är slitet borta. Du kan producera ett komplett första utkast av nästan vad som helst på 30 minuter. Biasen skalar nu: vad du än började tänka på, det har du nu byggt. Fel startpunkt saktar inte ner dig - den producerar bara mer fel output snabbare.

Resultatet är att AI-assisterade team antingen:

Utvecklar stark självmedvetenhet om startpunkter och väljer medvetet, eller
Bygger sex olika saker och upptäcker i efterhand att ingen löste samma problem

Den första gruppen har en arbetsflödes-supermakt. Den andra har dyr churn.

Vad man gör åt det

Om du är utvecklare som arbetar med AI:

Lägg märke till ditt standardstartdrag. Skriv ner det. "När jag får en ny uppgift är det första jag sträcker mig efter ___." Var specifik.
Fråga om uppgiften matchar din standard. En datamodellerings-uppgift passar en data-först-utvecklare. En användarflödes-uppgift gör det inte, även om den så småningom har data i sig.
Om det är en mismatch, börja medvetet någon annanstans. Läs specen, börja sedan från användaren. Läs koden, börja sedan från integrationsytan. Tvinga ett annat första drag.

Om du leder ett team:

Gör startpunkter till en återkommande fråga. Efter varje levererad feature, fråga varje bidragsgivare var de började.
Kartlägg teamets standarder. Du kommer hitta kluster och luckor. Luckorna är där ni har blinda fläckar.
Para personer med motsatta standarder på uppgifter där arbetet behöver spänna båda biaserna. En backend-ingenjör + en produktinriktad ingenjör producerar ofta mer än två backend-ingenjörer, även när uppgiften tekniskt är backend-tung.

Om du är facilitator som kör en workshop eller utbildning:

Fråga inte "vad byggde du?" Fråga "var började du?" Den första frågan producerar självgratulationer. Den andra producerar självmedvetenhet.
Visa upp mångfalden av startpunkter som lärdomen - inte som ett koordinationsmisslyckande. Lärdomen är spridningen.
Låt teamet dra slutsatsen själva. De kommer se det. Föreläs inte om det.

Det djupare påståendet

Metodikbitarna i Mindtastic - foundation pillars, arbetsloopen, röstmetodik, de tre angreppssätten - är alla försök att göra implicit tänkande explicit. Var-du-börjar är den mest uppströms av dessa. Allt annat händer efter.

Du kan köra arbetsloopen perfekt och ändå sluta med fel sak byggd, om du började från fel ställe. Arbetsloopen är nedströms från startpunkten. Likaså prompten. Likaså modellvalet. Likaså granskningsdjupet.

Att veta var du börjar är den billigaste, mest pålitliga produktivitetsinterventionen jag känner till i AI-assisterad utveckling. Det kostar inget. Det tar trettio sekunder. De flesta team har aldrig gjort det.

Börja där.

Baserat på observationer från ett nyligt Mindtastic Sprint-engagemang med ett seniort utvecklingsteam, maj 2026. Sex utvecklare, en uppgift, sex legitima startpunkter. Kundidentitet ej angiven.

Var detta till nytta?