2026-08-21 · ca 9 min läsning
Skalbar arkitektur för en ensam utvecklare: så prioriterar jag när AI gör en del av jobbet
Hur en ensam utvecklare med AI-stöd kan leverera i teamtakt utan att arkitekturen blir en flaskhals – vad jag prioriterar, och vad jag medvetet väljer bort.
Ett vanligt antagande är att en ensam utvecklare måste välja mellan hastighet och kvalitet, eller mellan att bygga smått och att bygga skalbart. Med AI-agenter som en del av arbetsflödet ändras den kalkylen – men bara om arkitekturen är byggd för det från start. Här är vad jag faktiskt prioriterar när jag ensam ska leverera något som ett helt team annars skulle bygga.
Domängränser före allt annat
När jag jobbar själv, ofta med flera AI-agenter som hjälper till parallellt med olika delar av kodbasen, är tydliga domängränser inte en akademisk övning – det är det som gör att flera parallella arbetsflöden inte krockar. Om autentisering, betalning och kärnaffärslogik är hopblandade i samma modul blir varje ändring en risk för sidoeffekter ingen såg komma, oavsett om det är jag eller en agent som skriver koden. Tydliga gränser gör också att jag kan granska en agents förslag isolerat, utan att behöva hålla hela systemet i huvudet samtidigt.
Testbarhet är inte valfritt när granskningskapaciteten är begränsad
I ett team med flera utvecklare finns naturlig granskning inbyggd – någon annan läser koden innan den mergas. Som ensam utvecklare måste den granskningen komma från någon annanstans: automatiserade tester, tydliga typer och deterministiskt beteende som går att verifiera utan att en människa manuellt klickar igenom varje flöde. Det är därför jag prioriterar en kodbas där moduler går att testa isolerat, långt innan jag prioriterar fler funktioner. AI-agenter är bra på att skriva tester snabbt, men bara om koden är strukturerad så att det finns något meningsfullt att testa i mindre bitar.
Deploymentflöden som minskar risk vid varje release
Utan ett team som kan dela på ansvaret för driftsäkerhet måste varje release i sig minska risken för mig, inte öka den. Det betyder gradvisa utrullningar där det går, tydliga rollback-vägar, och att aldrig lita på att "jag testade det manuellt en gång" som enda skyddsnät. En AI-agent som hjälper till med kod ska aldrig få en genväg runt samma release-disciplin som gäller för kod jag skrivit själv.
Var jag lägger min tid som människa
AI-agenter är starka på att producera kod, dokumentation och tester snabbt när uppgiften är väldefinierad. Det de inte gör åt mig är att avgöra vilken abstraktionsnivå som är rätt för just det här systemet, vilka kompromisser som är acceptabla givet kundens verkliga begränsningar, eller vilka tekniska skulder som är farliga kontra ofarliga att bära ett tag till. Det är där jag lägger min tid som senior arkitekt – inte i att skriva mer kod snabbare, utan i besluten som avgör om koden som skrivs snabbt fortfarande är rätt kod om ett år.
Vad jag medvetet väljer bort
Att leverera i teamtakt som en person kräver att jag säger nej till saker ett större team hade kunnat ta på sig parallellt: breda plattformssatsningar utan tydlig kundnytta, för många samtidiga teknikval, och funktioner som känns coola men inte flyttar kundens faktiska problem. Skalbarhet handlar lika mycket om att hålla systemets omfång ärligt som om att välja rätt arkitektur.
Sammanfattning
En ensam utvecklare med AI-stöd kan leverera på en nivå som tidigare krävde ett team – men bara om domängränser, testbarhet och release-disciplin är på plats från början. AI-agenterna förstärker det arbetssättet, de ersätter det inte.
Bygger ni något som ska växa och vill ha en arkitektur som håller när teamet – mänskligt eller AI-förstärkt – blir fler? På Avitus IT jobbar vi med samma disciplin oavsett vem eller vad som skriver koden. Hör av er via kontaktsidan.