– Ledere: Slutt å spørre om utviklerne deres bruker KI!

– Spør heller om dere har testene, spesifikasjonene og tilliten som gjør at de kan bruke den på alvor, skriver Truong Van Thanh Le, etter å ha bytta en diger plattform på et par måneder.

Truong Van Thanh Le estimerte ett år på en jobb han brukte et par måneder på, med KI. Men det krevde mye mer enn å bare "bruke KI".
Publisert

✍ leserinnlegg

Dette er et leserinnlegg fra en ekstern skribent, som betyr at innholdet ikke nødvendigvis speiler kode24s meninger. Vil du også bidra? Send oss en epost på [email protected], eller les mer her!

I KLP Eiendom var Sesam navet i dataflyten vår i mange år.

16 systemer hang på plattformen: Dynamics 365, SuperOffice, Forvalter, Kundeportal, Camunda, Leko, Energinet, BigQuery og flere.

Da vi bestemte oss for å fase den ut, var estimatet minst ett årsverk.

Sesam er et modent og stabilt produkt, og det finnes ingen direkte erstatning. Alt i produksjon måtte videreføres uten at forretningen merket overgangen.

Jeg bygget den nye plattformen i hovedsak alene på et par måneder, mens daglig drift og utvikling gikk som normalt. Deretter fulgte tre måneder med test, verifikasjon og justeringer i parallell drift.

Nå er Sesam slått av.

Det høres ut som en typisk KI-suksesshistorie. Det er det også, men ikke av grunnene folk flest tror.

Stacken: SQL der vi før hadde konfigurasjon

Hjertet er RisingWave, en Postgres-kompatibel database for strømprosessering med Apache 2.0-lisens.

Vi kjører den som RisingWave Cloud på Google Cloud. All forretningslogikk er SQL, bygget og deployet med dbt. Plattformen består i dag av 59 stagingtabeller, 40 materialiserte views og 71 sinks ut til målsystemene.

Data kommer inn på fire måter: pollere skrevet i C#/.NET som kjører som planlagte jobber på GKE, webhooks rett inn i RisingWave, Postgres CDC fra Camunda og polling av MySQL.

Ut går det via JDBC, BigQuery, Google Pub/Sub og HTTP. Hemmeligheter ligger i HashiCorp Vault, og CI/CD går i GitHub Actions.

Legg merke til hva som mangler: Kafka. For vår størrelse var det kompleksitet vi ikke trengte. Det var for øvrig KI-en som hjalp meg å argumentere meg frem til det.

KI i alle seks fasene, ikke bare i editoren

Den vanligste feilen jeg ser, er at KI reduseres til autofullføring.

Jeg brukte mest Claude, og i nyere tid også Gemini 3.6 og nyere, gjennom hele løpet:

  1. Research: kartla markedet og fant Snowflake, RisingWave og Feldera som kandidater.

  2. Arkitektur: sparringspartner på en stack tilpasset vår størrelse.

  3. Støtteverktøy: valg og oppsett av CI/CD, Kubernetes og observability.

  4. Anskaffelse: strukturert vurdering av produkter, lisenser og leverandørkrav.

  5. Implementering: connectorer og pipes generert fra API-spesifikasjoner og mønstrene vi hadde i Sesam.

  6. Test: E2E-strategi og 100 % testdekning.

Instruksjonene til agentene ligger i repoet sammen med koden, i CLAUDE.md, GEMINI.md og egne skills-mapper. De versjoneres, reviewes og forbedres som all annen kode.

RisingWave leverer selv en MCP-server og best practice-skills, så agenten kan jobbe direkte mot databasen. Det gjør også overvåking og videreutvikling KI-assistert.

Fire meninger jeg står for:

  1. Spesifikasjonen er den nye kildekoden. Jeg brukte tiden min på krav, arkitektur, integrasjonsmønstre og forretningsregler, og lot KI-en skrive det meste av implementasjonen. Verdien min lå i å vite hva som var riktig, ikke i å taste det. En vag prompt gir vag kode. En presis spesifikasjon gir kode du kan stole på, så lenge du sjekker den.

  2. Uten tester er KI-kode bare gjetting. Vi hadde 100 % E2E-testdekning før vi turte å gå fort. Sesams egne testcaser ble portert til dbt-tester som sjekker paritet mot den gamle logikken. Deretter kjørte vi Sesam og RisingWave parallelt med kontinuerlig sammenligning av data, gjennom dev og test til prod, med sinks som ble slått på system for system. Mangler du testene, har du ikke spart tid. Du har bare lånt den.

    Men testdekning alene er ikke nok. KI-en gjorde logiske feil selv med 100 % dekning. Paritetstestene hadde en mulighet til å ekskludere enkeltkolonner fra verifikasjon, og den ble brukt: når en sammenligning feilet, var det enklere å unnta kolonnen enn å rette logikken. KI utnytter smutthull hvis de er tillatt. Lukk dem, og se over hvert unntak selv.

  3. KI gjør åpen kildekode til et reelt valg for vanlige virksomheter. Mye av verdien i Sesam var de ferdige connectorene. RisingWave har færre, og det var lenge et godt argument for å bli der vi var. Med KI fyller vi hullene selv, etter faste mønstre. Leverandørlåsing er i ferd med å bli et valg, ikke en skjebne.

  4. Arkitekter må tilbake i koden. KI flytter flaskehalsen fra å skrive kode til å ta gode beslutninger. Den som har oversikt over domenet og systemene, kan plutselig gjennomføre selv. Arkitekter som bare tegner bokser, går glipp av det største produktivitetsløftet jeg har opplevd.

Det vanskelige var aldri koden

Ett årsverk på et par måneder er ikke magi, og det er heller ikke et kontrollert eksperiment.

Det tunge var domenet: slettinger som forplantet seg feil fordi en webhook-tabell startet tom, og fremmednøkler som knakk hos mottakeren. Det måtte jeg forstå selv før KI-en kunne hjelpe.

Vi har publisert hele oppsettet åpent under MIT-lisens, med migreringsguide fra Sesam, arkitektur og agentinstruksjoner:

github.com/KLP-eiendom/klpe-sesam-to-risingwave

Står du foran samme jobb, ta det og bruk det.

Og til ledere: Slutt å spørre om utviklerne deres bruker KI. Spør om dere har testene, spesifikasjonene og tilliten som gjør at de kan bruke den på alvor.

Foretrekk oss i Google Discover

Ved å legge oss til som foretrukket kilde i Google vil du blant annet få opp flere av sakene våre i Google Discover. Tusen takk for støtten!

Foretrekk oss 😻
Bygget med Labrador CMS