Hvordan anvender du AI-verktøy i ditt daglige arbeid som tech lead?

Question

Accepted Answer

Jeg behandler AI som en **rask, utrettelig junior-partner** — utmerket for første utkast og utforsking, aldri den endelige autoriteten. Det fremskynder arbeidet; **vurdering og verifisering ligger hos meg.** Som leder setter også måten jeg bruker det på eksempel for teamet.

## Hvor det hjelper daglig

- **Skrive kode og tester.** Generer et første utkast av en funksjon, en standard handler, eller en tabell med enhetstester — så leser, korrigerer og eier jeg hver linje.
- **Gjennomgå diffs.** En første gjennomgang for åpenbare bugs, manglende edge cases, eller uklart navn før jeg gjør den ordentlige gjennomgangen.
- **Utforske ukjent kode.** "Forklar hva denne modulen gjør og hvor X håndteres" får meg orientert i et nytt område langt raskere enn å grep blindt.
- **Skrive dokumentasjon og RFCs.** Gjør punktlister om til et lesbart utkast, så strammer jeg argumentet og sjekker fakta.
- **Oppsummere diskusjoner.** Kondenser en lang tråd eller møtetranskript til beslutninger og handlingspunkter.
- **Rubber-ducking design.** Snakk gjennom en tilnærming og la det peke på hull — en billig second opinion før jeg forplikter meg.

## Holde vurdering i løkken

Feilmodusen er å stole på flytende output. Så jeg:

- **Verifiserer påstander og APIer** — kjør det, test det, sjekk dokumentasjonen. AI halusinerer selvsikkert.
- **Merge aldri det jeg ikke forstår.** Hvis jeg ikke kan forklare det, sendes det ikke.
- **Bruk det for leverage, ikke abdikasjon** — det skriver utkast, jeg bestemmer.

## Sett et eksempel som leder

Når jeg deler en prompt som fungerte, eller viser hvordan jeg oppdaget en halusinert API i gjennomgang, lærer teamet den **gode praksisen**, ikke bare verktøyet. Normen jeg modellerer er: AI akselererer, men ingeniøren er ansvarlig.

## Hvorfor det betyr noe

Brukt på riktig måte fjerner AI sysselsetting og frigjør teamet for det vurderingskrevende arbeidet som bare mennesker gjør. Brukt blindt, oversvømmer det kodegrunnlaget med sannsynlige bugs. Forskjellen ligger helt og holdent i hvordan lederen bruker det og hva de modellerer.