Kommentaren som røper for mye

Det finnes en spesiell type kommentar som har blitt nesten epidemisk i kodebaser der AI brukes flittig. Du kjenner igjen typen:

# Nå bruker vi dictionary comprehension som avtalt
user_emails = {user.id: user.email for user in users}

# Fikset bugen vi snakket om med null-håndtering
if data and data.get('value'):
    process(data['value'])

Disse kommentarene forklarer ikke koden. De dokumenterer samtalen. Og det er problemet.

Hvorfor "prompt-lekkasje"-kommentarer er kode-lukt

Når en kommentar forklarer hva utvikleren ba AI-en gjøre i stedet for hva koden faktisk gjør, oppstår det flere problemer:

1. Tidsmessig forvirring Kommentaren forutsetter en leser som var til stede under utviklingsprosessen. "Nå bruker vi..." impliserer at noen var vitne til utgangspunktet. Framtidige vedlikeholdere – inkludert fremtidig-du – har ikke den konteksten.

2. Dokumentasjonsforfall Kommentarer knyttet til prompten blir umoderne så snart kravene endres. Hvis kravene utvikler seg, villeder disse kommentarene aktivt leserne om kodens formål.

3. Støy over signal Gode kommentarer forklarer hvorfor, ikke hva. Koden viser allerede hva den gjør. Kommentarer bør belyse intensjon, begrensninger og kontekst som ikke er opplagt fra implementasjonen.

Testen: Ville en marsboer forstå det?

Her er en enkel diagnose: Kan noen uten kunnskap om din utviklingsprosess forstå denne kommentaren?

Dårlig kommentar:

# Endret fra for-løkke til list comprehension for effektivitet
results = [transform(x) for x in data]

God kommentar:

# List comprehension er raskere enn løkke for store datasett på grunn av tolk-optimalisering
results = [transform(x) for x in data]

Den gode versjonen forklarer hvorfor tilnærmingen ble valgt, noe som forblir verdifullt selv lenge etter at koden ble skrevet.

Hva "Vibet" kode egentlig trenger

"VIBe"-koding – AI-assistert utvikling som prioriterer levering over perfeksjon – har legitim verdi. Hastighet betyr noe. Men fart bør ikke komme på bekostning av vedlikeholdbarhet.

Når AI-assistenten din foreslår en kommentar, spør deg selv:

• Forklarer dette hvorfor denne koden eksisterer?
• Ville det gi mening for noen som leser det om to år?
• Dokumenterer det kodens formål eller utviklingsprosessen?

Hvis det er det siste, slett det. Ditt fremtidige jeg vil sette pris på det.

Bedre AI-samarbeidsvaner

Løsningen er ikke å slutte med AI-assistenter – det er å utvikle bedre gjennomgangsvaner:

1. Les kommentarer før du godtar dem. Tilfører kommentaren verdi eller bare forteller utviklingschatten?

2. Omskriv AI-genererte kommentarer. Enda bedre: skriv dine egne. Du forstår forretningskonteksten AI-en ikke har.

3. Etabler teamstandarder. Hvis kommentarer som dette slipper gjennom kodegranskning, vil kodebasens kvalitet gradvis forringes.

4. Bruk selvdokumenterende kode. Tydelig navngiving, god struktur og passende abstraksjoner fjerner ofte behovet for kommentarer helt.

Poenget

Kode leses langt oftere enn den skrives. Kommentarer som dokumenterer prompten heller enn formålet skaper teknisk gjeld som vokser over tid. I hastverket med å levere er det fristende å la disse passere – men de er en form for teknisk gjeld som aktivt villeder framtidige utviklere.

De beste kodebasene forteller en historie. Kommentarene bør forklare plottet, ikke regissørens notater.

Hos NameOcean tror vi at gode utviklingspraksiser strekker seg utover bare hosting. Enten du vibekoder din MVP eller arkitekter bedriftssystemer, er grunnleggende prinsippene for ren, vedlikeholdbar kode avgjørende. Ditt domain er din digitale identitet – sørg for at koden bak det reflekterer deg godt.