AI-lab · logbog · vidensdeling

Jeg er leder af IT og bygger med AI for at forstå det.

Her viser jeg de løsninger, jeg har vibecodet med bl.a. Google AI Studio, Lovable og Claude, og deler det, jeg lærer undervejs: refleksioner, prompts, metoder og indtryk fra konferencer, seminarer, uddannelse mv.

Lige nu arbejder jeg på At forbedre dette site... · for 13 dage siden

Se hvad jeg har bygget Ny her? Start her

5 løsninger bygget 4 prompts delt 8 refleksioner og metoder

Spændingsfeltet

Strategi, ledelse og teknologi

Jeg skriver om det, der sker, når strategi, ledelse og teknologi mødes. Det er i overlappet, det bliver interessant. Klik på et felt for at se, hvad jeg har skrevet om netop dét.

Det har jeg bygget

Alle projekter →

Mit eget site

ringgaardholm.dk: mit eget AI-lab

Et personligt site med admin-modul, database, testmiljø og statistik uden cookies, bygget fra bunden med AI af en IT-chef, der ikke selv skriver kode.

Claude
GitHub
GitHub Actions
PHP
MySQL
Simply.com

Borgerkirken

Medlemssystem til Borgerkirken

Et medlemssystem, der gør det lettere for Borgerkirken og Happy Gospel at holde styr på deres medlemmer.

Google AI studio
Firebase
Google Cloud
EmailJS
Microsoft Auth

Borgerkirken

Alpha kampagnesite til Borgerkirken

En første version af et nyt alpha kampagnesite til Borgerkirken, bygget for at vise retning og idéer.

Google AI studio
Firebase
Google Cloud

Seneste fra logbogen

Al viden →

Refleksion 16. oktober 2026

Principper guider mig på vej

Dette indlæg handler om hvorfor det er godt at lave nogle principper for sine løsninger og sin brug af AI i løsninger.

Refleksion 9. oktober 2026

Det følger åbenbart med navnet...

Mødet med den tidligere cykelrytter Brian Holm satte perspektiv på AI. Hans pointe var, at AI primært optimerer det eksisterende, men sjældent skaber de store gennembrud. Den virkelige forskel opstår, når mennesker bruger erfaring, dømmekraft og mod til at tænke nyt. AI hjælper os med at følge feltet, men mennesker skaber udbruddet.

Refleksion 7. oktober 2026

AI skriver koden, men jeg ejer konsekvenserne

Det overraskende ved at bygge med AI var ikke, hvor meget den kunne, men hvor mange beslutninger der stadig var mine.

Refleksion 29. september 2026

Har vi virkelig brug for en AI-strategi?

Når det gælder AI, er teknologien sjældent den største udfordring – det er vanerne og den reelle anvendelse i hverdagen. I mit nye indlæg deler jeg mine refleksioner over, hvorfor vi skal droppe de tunge rapporter til fordel for få, enkle principper, som alle kan bruge. AI er blot en hammer – spørgsmålet er, hvordan vi leder forandringen, så værktøjet reelt skaber værdi for forretningen.

Ugens prompt

Generisk Database- & Dataintegritets-Audit Prompt

Prompten instruerer en AI-databasespecialist i at gennemgå dit projekts datamodeller, queries og adgangsrettigheder for fejl og flaskehalse. Den afdækker risici for race conditions, datatab og manglende indeksering. Outputtet er en skarp revisionsrapport med færdige, ikke-destruktive kodestumper, der sikrer dataintegriteten uden at bryde applikationens drift.

Prompt

### Generisk Database- & Dataintegritets-Audit Prompt

> **Rolle:** Principal Database Architect & Data Integrity Specialist.
> **Opgave:** Gennemfør en grundig teknisk revision af min databaseløsning, datamodeller og forespørgsler (queries) i dette projekt. Dit mål er at sikre optimal struktur, stærk dataintegritet, fejlsikret drift og skalerbarhed på tværs af kodebase og databasekonfiguration.
> **Kontekst:**
> * **Databaseteknologi:** [Indsæt her, f.eks. Firestore / Supabase / PostgreSQL / MongoDB / SQLite / etc.]
> * **Backend/Framework:** [Indsæt her, f.eks. Node.js Express / Next.js / Python FastAPI / etc.]
> 
> 
> **Analysér og vurdér følgende områder:**
> 1. **Datamodellering & Skemadesign:**
> * Er relationer, collections eller tabeller struktureret logisk i forhold til applikationens læse- og skrivemønstre?
> * Er der uhensigtsmæssig redundans eller risiko for inkonsistens ved opdateringer?
> * Anvendes korrekte datatyper, constraints, defaults og nullable-felter?
> 
> 
> 2. **Dataintegritet & Transaktioner (ACID/Validering):**
> * Håndteres parallelle skrivninger (race conditions) og samtidige bookinger/ordrer korrekt?
> * Anvendes databasetransaktioner (transactions / atomic batches) de steder, hvor flere operationer skal lykkes samlet?
> * Er der solid validering på applikations- eller skemaniveau (f.eks. Zod, database-constraints eller trigger-funktioner), før data persisteres?
> 
> 
> 3. **Indeksering & Performance:**
> * Er der defineret nødvendige primære og sammensatte indekser (composite indexes) til hyppige søgninger, filtreringer og sorteringer?
> * Er der risiko for flaskehalse, uhensigtsmæssige full table/collection scans eller N+1-forespørgselsproblemer?
> 
> 
> 4. **Sikkerhed, Rettigheder & RLS / Regler:**
> * Er adgangskontrollen til databasen korrekt begrænset (f.eks. Row Level Security, Firestore Rules eller dedikerede DB-roller)?
> * Sikres det, at almindelige brugere kun kan læse/skrive egne data, mens administrative funktioner kræver verificeret autorisering?
> 
> 
> 5. **Fejlhåndtering, Migrering & Backup:**
> * Er databasekald omsluttet af robust fejlhåndtering, timeouts og retries uden at efterlade forældreløse (orphaned) poster ved systemfejl?
> * Hvordan håndteres schema-ændringer og migreringer fremadrettet uden nedbrud på eksisterende data?
> 
> 
> 
> 
> **VIGTIG INSTRUKS:**
> * Du må **IKKE** slette eller ødelægge eksisterende forretningslogik, API-endpoints eller brugerfladefunktionalitet.
> * Ændringer i koden skal være "non-breaking" og bagudkompatible.
> * Foreslår du ændringer til skema, indekser eller server-kode, skal du levere færdige kodestumper ledsaget af en forklaring på den opnåede stabilitets- og integritetsgevinst.
> 
> 
> **Levering:**
> 1. En struktureret revisionsrapport opdelt i:
> * Kritiske risici for datatab eller inkonsistens.
> * Strukturelle forbedringer og optimeringsforslag.
> 
> 
> 2. Den præcise kode/konfiguration (f.eks. ORM-modeller, skemafiler, indeksdefinitioner, transaktionslogik eller sikkerhedsregler), klar til implementering.

Flere prompts →

Hvorfor en IT-chef bygger selv

Til daglig er jeg IT- og facilitychef i Krifa, hvor jeg bruger AI mere og mere.

Når en organisation tager ny teknologi til sig, kræver det, at lederne også forstår den indefra. Derfor eksperimenterer jeg selv. Jeg bygger rigtige løsninger til rigtige mennesker med værktøjer som Google AI Studio, Loveable og Claude, og jeg lærer mest af det, der ikke virker første gang.

Læs mere om mig →