Shift+Build — varför jag skriver det här
En förklaring av bloggens namn, ståndpunkt och vad du kan förvänta dig härifrån.
Det finns ett kortkommando jag tänker på ofta.
Shift. En tangent som inte gör något ensam. Den ändrar vad nästa knapptryckning betyder. Den är inte ett kommando, den är ett lägesbyte. Och Build — att faktiskt konstruera något, inte bara planera det.
Det är den rörelsen jag försöker förstå. Inte som metafor, utan som konkret förskjutning i hur digitala produkter görs och vem som gör dem.
Rollgränserna löses upp
Jag är tech lead. Jag sitter i en produkttrio med en UX-lead och en PM. Vi delar ett kontor, en backlog och ansvaret för att något faktiskt blir av det vi beslutar.
Under det senaste året har jag märkt att gränserna mellan vad vi var och en gör — vad som är “tekniska beslut” kontra “produktbeslut” kontra “designbeslut” — har blivit diffusare. Inte slarvigare. Diffusare på ett sätt som faktiskt verkar produktivt.
En AI-assistent hjälper mig skissa ett flöde i fyra rader kod. UX-leaden genererar en prototyp direkt i designverktyget utan att gå via ett möte om specifikation. PM:en sätter upp en SQL-fråga mot analysplattformen utan att vänta på datateamet.
Verktygen har gjort oss till generalister på varandras territorier. Inte fullt ut. Men tillräckligt för att det ska förändra hur vi samarbetar — och hur vi tänker på vår egna roll.
Vad som saknas i diskussionen
Det finns massor skrivet om AI och mjukvaruutveckling. Merparten av det faller i två kategorier:
Den ena är hype. AI revolutionerar allt. Varje roll försvinner. Varje process måste ritas om. Skrivet av någon som inte har suttit och debuggat ett prompt chain kl 23 för att det fungerade i staging men inte i produktion.
Den andra är skepticism. AI är ett verktyg, inte mer. Seniora ingenjörer gör fortfarande jobbet. Det är bara autocomplete. Skrivet av någon som inte riktigt har provat att låta det göra jobbet.
Ingen av dem hjälper mig att fatta bättre beslut i morgon.
Jag saknar en röst som skriver om det här från insidan — som har driftsatt ett AI-system, sett det misslyckas på intressanta sätt, och försöker förstå vad det egentligen kräver av en tech lead att äga sådana beslut. Som har sett rollerna förändras i en faktisk produkttrio och funderar på vad det innebär.
Den rösten är inte jag som guru. Det är jag på väg, med ryggen vänd mot vart vi kom ifrån och blicken mot vart vi verkar vara på väg.
Tre teman du kan förvänta dig
AI-arkitektur i praktiken. Konkreta beslut: kontextfönster, evalueringsstrategier, latens och kostnadsavvägningar, vad som faktiskt funkar i produktion kontra vad som ser bra ut i en demo.
Tech lead-perspektivet. Hur äger man teknisk riktning i en organisation utan att vara chef? Vad är en RFC egentligen bra för? Hur synliggör man arbetet som sker i mötesfri tid?
Rollkonvergensen. Vad händer när en utvecklare börjar se som en produktägare? När en designer inte längre är beroende av en front-end? Det är inte ett hot mot roller, det är en förändring av vad rollen innehåller.
Varför blogg och inte Substack
Jag vill äga det jag skriver. En .md-fil på ett eget domännamn med ett git push till deploy är den enklaste form av det ägarskapet. Artiklarna korsläggs på Substack som distributionskanal — men det som indexeras, det som länkas, det som byggs upp SEO-auktoritet, det sker här.
Det är en teknisk blogg med ett tekniskt argument bakom publiceringsmodellen.
Om du är tech lead, senior utvecklare eller jobbar i skärningspunkten mellan kod, produkt och design — hör av dig. Jag skriver det här lika mycket för att förstå något som för att dela det, och de bästa samtalen brukar komma ur de texterna.
Nästa inlägg handlar om design systems i en AI-assisterad kodbas — och varför det kräver en fundamentalt annorlunda syn på vad ett design system egentligen är till för.
