Derfor «nekter» vi oss selv å kode for hånd

kode24 skrev at Bislab «nekter» utviklerne å kode for hånd.

Som utvikler i Bislab er det viktig å få frem at denne begrensningen var et teknisk initiativ. Og jeg håper denne artikkelen kan inspirere flere til å gjøre noe lignende.

«Nekter» utviklerne å håndkode: Kaller dem fabrikksjefer

– Å si at vi ikke skal skrive kode for hånd har vært brått og vondt for mange, innrømmer produktdirektøren i Bislab.

Jeg begynte i Bislab i mai og mitt ansvar er å bygge plattformen som fabrikken kjører på.

Det siste halvåret har vært det morsomste i karrieren min med ren problemløsning i et tempo jeg aldri har sett før.

Jeg elsker kode

Problemene jeg jobber med er større enn før og jeg har fått mer eierskap.

For første gang kunne jeg begynne på de store tingene fra dag 1 uten å bruke et kvartal på å overbevise en komité om at investeringen var verdt det. Jeg tar flere tekniske avgjørelser på en uke enn jeg tidligere tok på et år.

Ved siden av kan jeg jobbe på småprosjekter vi ellers aldri har tid til: vedlikehold, små forbedringer og et komplett TV-veggsystem med Raspberry Pi for dashboards og partymusikk når vi lander et salg.

Alt dette er mulig fordi utviklerne hadde bestemt seg for å slutte å skrive kode for hånd, og fått støtten de trenger fra resten av selskapet.

De har bygget fabrikken som gjør at vi kan løpe raskere med AI. Jobben min er å støtte dem med plattformen og det meste av infrastrukturen de kjører på. Det som før hadde krevd et eget team og en styringsgruppe, kan jeg nå gjøre selv. 

Siden mai har jeg merget nesten 2.000 pull requests. Jeg har ikke skrevet én av dem for hånd.

Det hadde ikke vært mulig uten harde regler for agentene: streng kodestil, faste regler for struktur og arkitektur, og tester som håndhever dem.

Jeg elsker kode. Det betyr ikke at jeg må gjøre alt selv.

Posten Bring skal spare med KI, uten å sparke utviklere

Posten Bring skal spare 25 prosent, bli 300 færre ansatte, og bruke KI for å komme dit. Likevel skal de få flere egne utviklere, forteller topplederne.

Hvorfor nekte seg selv å kode?

Den morsomste kommentaren under saken var denne:

«Ok folkens, vi må oppdatere noen API-nøkler i .env-fila.» «Greit, jeg fikser!» A wild Marcus Bergquist appeared! «DU VÅGER IKKE!»

Helt fantastisk, men det misforstår poenget vårt.

Poenget med å slutte med å kode for hånd er ikke at hver lille oppgave går raskere med AI. Mange oppgaver går saktere første gang. Regelen tvinger deg til å investere i oppgavene du gjør igjen og igjen og igjen. Når du ikke har lov til å bare fikse det, må du bygge noe som fikser det. Neste gang er oppgaven borte. Det er vanlig, god software engineering.

Poenget er heller ikke at vi aldri kan gjøre små one-off endringer for hånd i fremtiden. Vi satte regelen for å tvinge oss selv til å endre hvordan vi angriper oppgaver og ikke falle tilbake på gamle vaner.

API-nøkler er et godt eksempel, for det var noe av det første jeg tok tak i. Hemmelighetene ligger i Secrets Manager, ikke i .env-filer, og tjenestene henter dem selv. Der det går, er det ikke behov for nøkkel i det hele tatt: de får identiteten sin fra skyen, uten passord, også når en Azure-tjeneste skal snakke med AWS. Oppsettet hos leverandørene våre, f.eks. e-post og Slack, ligger i kode. Ingen hos oss oppdaterer en API-nøkkel for hånd lenger.

Det er det vi mener med «fabrikk»: en maskin vi bygger for at det samme arbeidet aldri skal gjøres to ganger av mennesker.

Fra fabrikkarbeider til sjef

Fokuset på software factory og økt hastighet gjør at utviklere hos oss ser annerledes på oppgaver.

I en tidligere jobb tok en monorepo-migrering seks måneder med én person på heltid, i et selskap med samme størrelse og stack som Bislab. For å bli ferdige måtte vi godta mange kompromisser. Jeg har også sett slike plattformprosjekter dra ut i årevis fordi prioriteringer og fokus endret seg underveis.

I Bislab tok monorepoet åtte dager, og resultatet har aldri vært så nært ‘korrekt’ som jeg mener vi er nå. Vi trenger ikke ta de samme kompromissene som før.

Som fabrikksjefer har vi muligheten til å designe det perfekte systemet. Vår jobb har blant annet blitt å fjerne flaskehalser som bremser utviklere fordi det også stopper agentene.

DevEx har dermed blitt viktigere for forretning og vi kan bruke mer tid på å løse våre egne problemer. Alt fra databaseskjemaer til infrastruktur ligger nå som kode. Vi får også større gjennomslag på alt fra IT-system til krav om bedre kontekst fra resten av organisasjonen.

Så utviklere og agenter har full kontekst om produktene, kundene og historikken bak valgene våre. Aldri noe mer hviskelek med salg og produkt.

Vi jobber med reglene som gjør at en agent kan jobbe trygt i produksjon. Hva som aldri skal kunne skje ved et uhell, hvilke endringer et menneske må se på, og hvordan vi sørger for at mennesker og agenter ikke kan endre reglene for sin egen kontroll. Reglene kom fra oss, typisk etter at noe gikk galt eller vi fant en flaskehals.

Skapertrang

Det som har overrasket meg mest er engasjementet rundt software factory.

Når utvikling ikke lenger er en begrensning, leder det til masse innovasjon. Utviklerne hos oss har blant annet bygget egne terminalverktøy, AI code reviewer, auto-research oppsett, og overvåking av fabrikken. Selv har jeg laget agent-skills for ADRs, arkitekturkart, gitt agentene et eget kodesøk, og satt opp lokale agenter som nå er en fast del av hverdagen min.

Ingen beordret oss til å bygge alt dette og ingen måtte godkjenne det. AI har gitt oss mye større rom og evne til å innovere. Er det nyttig så bygger du v0 og så ser vi på det sammen.

Jeg har programmert i over 20 år, helt siden barneskolen, og jeg elsker det fortsatt. Men det jeg egentlig er avhengig av er å løse problemer og få ting gjort.

Jeg har aldri vært i et team der så mange får bygd så mye av det de mener er riktig.

Halvparten av utviklere føler seg pålagt å bruke KI

– Ikke fordi det er en uttalt regel, men fordi det har blitt standarden, sier én av dem. Men du har krav på å bli hørt om du er uenig.