Ett år med Copilot: – Vi har blitt bedre utviklere!

- Jeg trodde GitHub Copilot skulle “ta over jobben vår”, men den gjorde meg til en bedre utvikler, skriver daglig leder Simen A. W. Olsen i Bjerk.

Simen A. W. Olsen er utvikler og daglig leder i Bjerk, og mener Copilot har gjort ham til en bedre utvikler. 📸: Bjerk
Simen A. W. Olsen er utvikler og daglig leder i Bjerk, og mener Copilot har gjort ham til en bedre utvikler. 📸: Bjerk Vis mer

Som de fleste andre i bransjen vår, så er jeg veldig glad i nye ting. Derfor var jeg ikke vond å be da GitHub foreslo for meg for circa ett år siden å ta i bruk Copilot.

For de som ikke kjenner verktøyet, så er GitHub Copilot en GPT-modell som er trent på kildekode fra GitHub (og sikkert andre kilder).

Se på det som en variasjon av ChatGPT, men som er spisset til utviklere.

«Det som er den store styrken til Copilot er AI-ens evne til å tolke og forstå.»

Copilots største styrke

GitHub kaller Copilot «your AI pair programmer», og den beskrivelsen passer veldig bra, men kanskje ikke av den grunnen du eller GitHub selger det inn som.

Hovedargumentet for å ta i bruk Copilot er at den skriver kode for deg.

Etter ett år med bruk så er jeg enig at det er en stor fordel, men ikke den største. GitHub tilføyer nemlig at ved å bruke CoPilot kan vi utviklere bruke tiden på de store problemene, så kan Copilot skrive boilerplate og fjerne repetitive oppgaver.

I Bjerk og min arbeidsflyt opplever jeg ikke lenger at boilerplate må skrives, og repetitive oppgaver er mer eller mindre abstrahert bort.

Det som er den store styrken til Copilot er AI-ens evne til å tolke og forstå.

Reduserer kognitiv kompleksitet

Kognitiv kompleksitet er et måleparameter for hvor vanskelig en kodeenhet er å forstå intuitivt. Fra mitt perspektiv, så er utviklernes brukeropplevelse (eller DX) et helt essensielt element for å skape gode produkter og hverdag, og sentralt i dette står selvsagt verktøy, men også kognitiv kompleksitet.

Det må være enkelt å forstå det vi gjør, for at vi kan vedlikeholde noe eller skape mer basert på det. I det vi programmerer gjør hjernen vår mange mentale hopp, som ikke nødvendigvis er logiske eller forståelige for andre.

I mange år har vi snakket om refaktoreringsprinsipper og grep som å først få ting til å fungere, etterfulgt av en umiddelbar refaktorering.

Kode som blir forstått av nestemann

Selv er jeg stor fan av Adam Savage sin modell first order of retrievability, som sier at verktøy du bruker skal være i umiddelbar nærhet fra det stedet du jobber. Jeg opplever at dette kan overføres til hvordan vi organiserer kildekode og kan gi oss gevinster, spesielt når vi itererer på strukturen til vi finner noe som passer best.

«Kvaliteten på det vi har produsert er økt, ikke bare målt opp mot tid, men totalt – over hele blokka.»

I det siste året har jeg og kollegaene mine i Bjerk lært at GitHub Copilot hjelper oss å finne den strukturen, og enda bedre, sikre at vi produserer noe som vil blir forstått av nestemann.

Kvaliteten på det vi har produsert er økt, ikke bare målt opp mot tid, men totalt – over hele blokka.

Det gjenspeiler kanskje også en ting de nye maskinlæringsmodellene kan gi samfunnet generelt også – høyere kvalitet.