När jag började min kod-AI-resa var jag alltid vid tangentbordet, ofta sent in på nätterna. Jag försökte få AI:n att förstå exakt vad jag ville ha och höll tempot uppe genom att prompta, korrigera och styra varje steg. Det gick fort — nästan för fort. Arkitekturen hann inte sätta sig, och vi sprang rakt in i dead ends där beslut som fungerade kortsiktigt blev stoppklossar när vi skulle skala, säkra och förvalta lösningen.

Nu har jag siktet inställt på nästa nivå: Att bygga ett strukturerat AI-team. Det handlar inte längre om att prompta fram en specifik lösning – som en gitarrstämmare eller en matlista – utan om att leda ett fullt fungerande AI-team som kan ta sig an vilken uppgift som helst, från idé till produktion.

Mitt virtuella team

Istället för att bara ha en konversation igång arbetar jag nu med flera specialiserade agenter som har tydliga roller, så som:

• “Nya Arkitekten”: Som ser till att vi följer de långsiktiga målen.
• Test-ledaren: Som vägrar släppa igenom kod utan validering.
• Infra-agenten: Som hanterar allt från molnkonfiguration till persistent data och nätverk.
• Frontendaren: Som fokuserar på UX och användarupplevelse.
• Säkerhets-ledaren: Som säkerställer att säkerhetsprinciper följs från dag ett.
• Backend-utvecklaren: Som bygger robusta API:er och hanterar datalogik.

(Listan är inte fullständig – teamet växer och specialiseras kontinuerligt.)

Bortom SaaS: Att äga sin infra

En viktig del av mina tester är att inte ta den enkla vägen. Istället för att bara koppla på en SaaS-tjänst för t.ex. persistent data, vill jag att mina agenter ska kunna hantera och konfigurera hela infrastrukturen själva. Vi började på AWS, men nu skalar vi upp och testar även GCP för att se hur agenterna hanterar olika molnmiljöer.

Från överförtroende till krass realism

I början av min resa antog jag att agenterna kunde lösa allt på egen hand. Jag hade ofta för många agenter igång samtidigt, vilket ledde till timmar av oändliga loopar där de ändrade samma saker fram och tillbaka utan framsteg.

Nu är jag mer selektiv och håller en betydligt stramare tygel. Men mitt mål är det motsatta: att kunna ha många agenter igång samtidigt utan att förlora kontrollen. Det är precis det jag arbetar med just nu — att bygga den räls och de guardrails som krävs för att skala upp teamet utan att hamna i oändliga loopar. AI:n är en fantastisk medarbetare, men den behöver en senior projektledare (mänsklig sådan) för att faktiskt leverera värde.

Kod som vaktar plånboken

För att optimera både tid och pengar har jag flyttat tunga processer närmare källan. Lokala E2E-tester körs via skript istället för att bränna GitHub Action-minuter på varje iteration — agenterna får inte committa förrän testerna är gröna på min maskin. Kontext-kontroll begränsar sessioner till ~1000 rader för att undvika förvirring och onödiga kostnader. Lokala verifieringar (kod-standarder, linting, valideringar) körs innan något når CI/CD, vilket säkerställer att agenterna följer etablerade mönster och att vi inte bränner onödiga GitHub Action-minuter på uppenbara fel. Git worktrees isolerar parallella agenter — varje agent får sin egen arbetskatalog som delar samma repository men separata working directories, vilket eliminerar merge-konflikter och överlappande ändringar. Detta är nu en del av SDLC och säkerställer att agenterna kan arbeta parallellt utan att störa varandra.

Framtiden: Agenter som jobbar medan jag sover

Det ultimata målet är workflows där jag inte ens behöver vara inloggad. Jag utforskar just nu workflow-ramverk och Slack-integrationer för att styra agenter via chatt och centraliserade flöden, samt GitHub Issue-driven utveckling där agenter regelbundet (“den nya tidens cron”) laddar hem issues, analyserar dem och börjar bygga lösningar självständigt.

De dolda kostnaderna och AI-fällorna

Att bygga med AI-acceleration kräver också en ny form av resurshantering. Här är några av mina största lärdomar:

1. Kontext-fällan: Om du inte begränsar kontexten blir sessionerna snabbt extremt dyra och AI:n tappar fokus. Att veta när man ska “rensa tavlan” är en Tech Lead-skill i sig.
2. Modell-ekonomi: I början betalade jag för dyra abonnemang i onödan. Nu vet jag vilka uppgifter som kräver en “Opus” och vilka som löses bättre av snabbare, billigare modeller.
3. Loop-bevakning: En AI som fastnar i en cirkelgång kan bränna GitHub Action-minuter och tokens på nolltid. E2E-tester är fantastiska, men om de körs i varje misslyckad AI-iteration blir det snabbt kostsamt.

Att gå från att vara en “prompt operator” till att vara en arkitekt av autonoma flöden är den mest spännande delen av min resa just nu. Det handlar inte längre om vad jag kan skriva, utan om vilka system jag kan sätta i rörelse.