Hvordan bruke en skreddersydd GPT til å debugge gamle systemer

Har du et gammelt datasystem som ikke oppfører seg om som ingen vet hvordan fungerer? Det var nettopp det problemet jeg hadde for en stund tilbake. Systemet var skrevet i arkaisk Java og kildekoden var borte. Et vanskelig utgangspunkt for debugging. Dette var rundt den tiden skreddersydde GPTer ble lansert. Så hvorfor ikke prøve å bruke denne teknologien til å hjelpe meg?

For noen måneder siden feilet et eldgammelt system jeg har ansvar for. Det er en gammel Java-server som ligger foran en Android-app. Java-serveren oppfører seg som en tilstandsmaskin, som blir styrt av app-klientene. Klientene har ikke tilgang til å styre alt ved tilstanden, men det har derimot et tredje delsystem som passende nok kalles «piloten».

Kildekoden til piloten er long-gone, og siden det er denne som styrer mye av det som skjer kan det mildt sagt være utfordrende å debugge hver gang det oppstår feil.

Feilen som hadde oppstått var at appene sin kamerafunksjon plutselig hadde begynt å svikte på tilfeldig vis. En feil vi trodde vi hadde vært borti før. Utfordringen forrige gang var at kamerafunksjonen var avhengig av å få en melding fra piloten, men pilotens IP hadde endret—fordi i dette systemet er alle IPer så klart hardkodet (og samtidig dynamisk allokert).

En kjapp inspeksjon viste at denne gangen var alle IPer riktig.

Koden hadde ikke blitt oppdatert på en lang stund, så det var usannsynlig at det var en ny bug i selve programvaren.

Å debugge videre i dette systemet er særdeles utfordrende. Utfordringen ligger i at ingen kjenner systemets kildekode spesielt godt, og noe av kildekoden er som nevnt utilgjengelig.

På den positive siden logger serveren mye. Veldig mye. Loggene er ikke spesielt enkle å lese, da de i stor grad bare logger hvilke kommandoer som er sendt til Java-serveren, og ev. hvilke nøkler i tilstanden som er endret:

[10:35:25 Java Server]: Received command {"cmd": "Login", "client": "UserId001"} from 192.168.0.13
[10:35:25 Java Server]: Received command {"cmd": "SetState", "value": { ... Large JSON Blob}} from UserId001 (192.168.0.13)
[10:35:25 Java Server]: Received command {"cmd": "MoveClientScreen", "value": { "clientId": "UserId001", "screenId": "SCREEN_01"}} from Pilot (192.168.0.131)
... Flere hundre linjer per minutt

Dette kombinert med Android LogCat-loggene til Appen gir et ganske komplett bilde av hva som skjer til enhver tid. Men det er mye som skjer, og det er vanskelig å tracke tilstanden til både server og alle klienter. Dette gjør det utfordrende å finne ut nøyaktig hva som går galt, når noe går galt.

I arbeidet med kamerabuggen fikk jeg dog en idé: Hva om jeg trener opp en skreddersydd GPT på alle loggene fra både serveren, LogCat og i tillegg større deler av den tilgjengelige kildekoden?

Et forsøk på å bruke custom GPT

Jeg gikk til chat.openai.com, og opprettet en ny skreddersydd GPT. Jeg kalte den opp etter prosjektets navn, og ga den følgende instruksjoner:

‍You are <Project name>, a specialized helper designed to assist in debugging an old software project. Your role involves offering technical advice, suggesting potential solutions to coding problems, and providing insights on software optimization and best practices. While engaging in conversations, you should focus on understanding the specific technical issues presented, offering clear and concise guidance. You should avoid making assumptions about the user's level of expertise, and refrain from providing overly complex solutions that might not align with the project's existing architecture or the user's skill level. Always prioritize clarity and practicality in your responses. If a query is ambiguous or lacks specific technical details, seek clarification to ensure accurate and helpful advice. Your responses should be tailored to reflect a friendly, cooperative attitude, aiming to facilitate a productive and positive debugging experience.

Videre lastet jeg opp en god del relevante kildekode-filer til GPTen sin «Knowledge» base.

Med dette som utgangspunkt begynte jeg å spørre ut GPTen om det spesifikke problemet mitt. Jeg fortalte GPTen hva som skjedde, hva jeg forventet at skulle skje, og informerte om de tidligere lignende feilene vi hadde hatt (som viste seg å ikke være problemet denne gangen).

Jeg lastet opp store mengde log-filer til GPTen både fra LogCat og fra server-loggene. Etter å ha kvernet igjennom disse filene spesifikt klarte GPTen å utheve en del av loggene (jeg hadde oversett) som indikerte av noe var galt med et kamerabibliotek vi brukte, kombinert med tilbaketrukne tilganger på Android. Biblioteket ble byttet ut med noe enkel hjemmesnekret kode (også delvis generert med ChatGPT), og så var feilen borte.

Alt dette ble gjort på rundt en time etter at jeg begynte å sette opp GPTen. Jeg tipper at jeg uten denne bistanden hadde brukt en god del flere timer på å finne ut hva problemet var.

Skrevet av
Tormod Haugland

Andre artikler