AI skriver akkurat denne funksjonen for deg på omtrent et minutt, og den ser helt riktig ut. Det er fellen. Her er et ekte tilfelle, fra et system jeg faktisk drifter.
En pasient satte seg ved en selvbetjeningskiosk for å signere et samtykkeskjema før timen, og tastet inn navn og telefonnummer. Kiosken kastet en feil:
Kunne ikke opprette pasient.
Det ga ingen mening. Personen var allerede booket den dagen, allerede i systemet. Så hvorfor prøvde kiosken å opprette en ny oppføring, og hvorfor feilet det?
Den selvmotsigelsen viste seg å være hele historien.
Hva kiosken skal gjøre
Kioskens første jobb er enkel: avgjøre om personen foran den er noen vi allerede kjenner, eller noen ny.
Allerede kjent: last inn oppføringen, fortsett.
Ny: opprett en oppføring, fortsett.
Tar den den ene avgjørelsen feil, blir alt nedstrøms også feil.
Før: identitet ved navn, stavet perfekt
Det opprinnelige oppslaget matchet en person på navn og telefonnummer sammen, og begge måtte stemme nøyaktig. Fellen lå i navnesammenligningen. Den skilte ikke mellom store og små bokstaver, men var følsom for aksenter og stavemåte. Så for datamaskinen:
"Pal" ≠ "Pål"
"Anne-Marie" ≠ "Anne Marie"
"Jon Erik" ≠ "Jon" (et mellomnavn som mangler)Hvilken som helst av de bittesmå forskjellene, og kiosken konkluderte: jeg kjenner ikke igjen denne personen. Så den gikk til plan B og prøvde å opprette en ny oppføring.
Men databasen har en fornuftig regel: ingen to pasientoppføringer kan dele samme telefonnummer. Personen fantes allerede, så telefonnummeret var allerede opptatt. Den nye oppføringen ble avvist i døra. Resultat: «Kunne ikke opprette pasient.» En blindvei.
Paradokset, sagt rett ut
Kiosken klarte ikke å opprette pasienten fordi pasienten allerede fantes. Men den oppdaget aldri at de fantes, fordi navnet ikke ble tastet helt likt.
Den hadde rett og feil samtidig. Rett i at denne personen allerede er her. Feil i å lage en ny. Regelen om unikt telefonnummer var det eneste som sto mellom denne feilen og en haug med dupliserte oppføringer. Den forvirrende feilmeldingen var sikkerhetsnettet som gjorde jobben sin, bare med en dårlig merkelapp.
Etter: identitet ved telefon, så e-post
Fiksen er en endring av hva som teller som identitet.
Folk taster navn feil. De dropper aksenter, legger til mellomnavn, forkorter. Et navn er en etikett, ikke en identifikator. Et telefonnummer, som allerede håndheves som unikt, er det pålitelige fingeravtrykket.
Så oppslaget nøkler nå på telefonnummer først, så e-post, og ignorerer navnet helt for matching:
Eksisterende pasient med navnet tastet litt feil: funnet på telefon, oppføringen gjenbrukt, ingen feil.
Genuint ny person: opprettet som normalt, akkurat som før.
Sikkerhetsnett: hvis en opprettelse likevel kolliderer (rar formatering av telefonnummer, to nesten samtidige innsjekkinger), går den tilbake og henter den eksisterende oppføringen i stedet for å kjøre seg fast.
Én linje av filosofien endret seg: gjenkjenn folk på det som er stabilt og unikt, ikke på det de taster om igjen ved hvert besøk.
En fin bonus: dette er nøyaktig slik den nettbaserte bookingløypa allerede fant pasienter. Kiosken var den som skilte seg ut. Nå snakker begge samme språk.
Før og etter
Matcher på: før nøyaktig navn og telefon, nå telefon og deretter e-post.
Pål mot Pal: før to forskjellige personer, nå samme person.
Eksisterende pasient med navnet litt feil: før et forsøk på å opprette som ble avvist med feil, nå funnet og gjenbrukt.
Helt ny pasient: opprettet før, opprettet nå, uendret.
Når en duplikat slipper gjennom: før hard feil og blindvei, nå gjenoppretting som henter den ekte oppføringen.
Samstemt med nettbooking: før nei, nå ja.
Vrien: det så ut som et infrastrukturproblem
Her er delen jeg nesten tok feil av.
Samme morgen fikk innlogginger til et par interne apper sporadiske tidsavbrudd. Lett å anta én årsak. Men tidsavbruddene var et separat problem: verten var overbelastet og ressurssultet, og å trimme det som kjørte på den fikset det.
Feilen «kunne ikke opprette pasient» var noe helt annet, en logikkfeil i kiosken. Overbelastningen hadde bare maskert den. Et tregt oppslag som får tidsavbrudd kan stille lese som «ikke funnet», som sender koden ned akkurat den samme dødfødte opprett-løypa.
To feil i samme frakk. Den late løsningen er å skylde på det høylytte, åpenbare (serveren) og bomme på det stille, ekte (logikken). Les den faktiske feilen, ikke den nærmeste overskriften.
Slik verifiserte jeg det, uten å gjette
Jeg ville ikke fikse det og håpe. Så jeg reproduserte både den gamle og den nye oppførselen mot det ekte systemet, innlogget som en ekte bruker med ekte rettigheter:
1. Opprettet en engangstest-pasient, allerede i systemet, navn med aksent.
2. Gammel måte (navn pluss telefon, navnet tastet uten aksenten): ingen match, ville opprette, blokkert av regelen om unikt telefonnummer. Feil reprodusert.
3. Ny måte (slå opp på telefon): funnet umiddelbart, oppføringen gjenbrukt.
4. Ny pasient (nytt telefonnummer): opprettet rent, ingen regresjon.
5. Duplikat med vilje: avvist, så fant gjenopprettingssteget den ekte oppføringen.
6. Slettet testdataene. Null rester.
Reproduser feilen og fiksen før du kaller det ferdig. Får du ikke feilen til å skje på kommando, har du ikke forstått den ennå.
Hva du tar med deg
Et navn er en etikett, ikke en identitet. Match folk på noe stabilt og unikt (telefon, e-post, en ID), aldri på fritekst.
Få alle inngangspunktene til å være enige. Hvis én løype finner brukere på telefon og en annen på navn, driver de fra hverandre, og den som skiller seg ut er der feilen bor.
En forvirrende feil kan være et vern som virker. Regelen om unikt telefonnummer gjorde en stille duplikatdata-katastrofe om til en høylytt, fiksbar en.
Ikke la det høylytte problemet skjule det stille. Den åpenbare hendelsen og den ekte feilen er ikke alltid samme hendelse.
Her er delen som betyr noe hvis du bygger med AI. Claude eller Lovable skriver navneoppslaget og opprett-fallbacken på sekunder, og den leser som riktig, fordi den er riktig, helt til to personer som heter Pål og Pal dukker opp. Det AI-en ikke kan, er å avgjøre hva identitet betyr for systemet ditt, eller bevise at fiksen faktisk holder. Den dømmekraften og den verifiseringen er jobben. Liten diff. Bedre system. Shipp det.