[{"content":"Dette researchoverblik er samlet og skrevet af AI ud fra ugens udvalgte kilder. Det er ikke en personlig afprøvning eller en fagfællebedømmelse fra Evgeny Karpov.\nUgens kilder: 04.09.2026–10.09.2026.\nDenne uge handler mindre om, hvor godt en agent kan formulere et svar, og mere om hvorvidt dens handlinger, patches og retrieval-resultater holder, når de møder rigtige grænser i et workflow.\nAutoritet skal ligge ved grænsen, ikke i prompten Ugens tydeligste forbindelse er, at agenters hukommelse, workspace og værktøjer ikke udgør én samlet sikkerhedstilstand. En agent kan se de rigtige filer og stadig mangle afgørende viden om, hvem der må publicere, ændre eller køre noget. Det gør beslutninger, der alene afhænger af det synlige repository eller modelkonteksten, skrøbelige.\nBeyond Agent Harnesses undersøger denne afstand mellem planlægning og faktisk autoritet i kontrollerede mini-benchmarks. Forfatternes resultat peger på, at en deterministisk kontrol ved mutationsgrænsen kan standse uautoriserede handlinger, også når en model allerede har valgt dem som første skridt. Det er en mere driftbar idé end at forvente, at bedre kontekst alene gør agenten konsekvent sikker.\nAuthority Is Not a String anvender samme grundprincip på coding agents og prompt injection: autoritet afgrænses som capabilities pr. agent og kontrolleres uden for modelkonteksten. Det er især relevant i workflows med delegation, hvor en sub-agent måske må læse logs, men ikke ændre CI-konfiguration eller sende data ud af miljøet. Begge resultater kommer fra preprints og afgrænsede evalueringer; de dokumenterer ikke robusthed på tværs af alle værktøjer, repositories eller produktionsmiljøer.\nKilder: Beyond Agent Harnesses: Cross-Substrate Authority for Multi-Agent Systems; Authority Is Not a String: A Capability-Scoped Harness for Prompt-Injection-Resistant Coding Agents.\nEn patch er ikke færdig, fordi testen er grøn To benchmarks udfordrer den velkendte genvej fra “tests passerer” til “ændringen er acceptabel”. SWE-Gate skelner mellem funktionelle tests og review constraints, altså eksplicitte krav der typisk fremkommer i pull request-review. Forfatterne finder, at en betydelig del af reparationer, der klarer funktionelle tests, ikke klarer hele specifikationen.\nPatchBench viser den sikkerhedsmæssige version af samme problem. En sårbarhedspatch kan få en given Proof-of-Concept til at holde op med at crashe uden at rette årsagen, og historiske patches kan ligne trænings- eller referenceeksempler. Derfor foreslår forfatterne validering, der tester både sikkerhed og semantisk korrekthed, frem for kun crash-undertrykkelse.\nFor backend- og platformteams betyder det, at agent-evaluering bør følge den faktiske acceptance pipeline: tests, policy, reviewkrav og sikkerhedsegenskaber. Det er en fortolkning af benchmarkresultaterne, ikke en påstand om, at enhver grøn build er utilstrækkelig. Begge studier er benchmarkarbejde baseret på deres valgte repositories og scenarier, så størrelsen på de rapporterede huller kan ikke uden videre overføres til et konkret system.\nKilder: SWE-Gate: Passing Functional Tests Is Not Enough for Software Engineering Agents; PatchBench: Evaluating AI Agents for Vulnerability Patching.\nBenchmarkets miljø former svaret PrivEscalate og Q2D-Web peger på en bredere platformlære: modelrangeringer og succesrater er egenskaber ved et helt setup, ikke kun ved modellen. I PrivEscalate varierer resultater med sårbarhedstype, agentarkitektur og miljøforstyrrelser. En agent, der ser stærk ud i ét Linux-scenarie, er derfor ikke automatisk det bedste valg til en anden driftssituation.\nQ2D-Web finder tilsvarende, at retrieveres indbyrdes placering varierer på tværs af domæner, sprog og querytyper. Det er centralt for agentic RAG, fordi første retrieval ofte modtager agent-omformulerede queries frem for menneskeskrevne søgninger. En generel leaderboard-score kan dermed skjule en svaghed i netop de incident-, runbook- eller dokumentationsforespørgsler, et team faktisk har.\nPrivEscalate beskriver et specialiseret wrapper-design med deterministisk enumeration og planlægning, mens Q2D-Web undersøger mere realistiske retrieval-data og relevance judgments. De er nyttige måleinstrumenter, men abstracts alene forklarer ikke alle datasætvalg, fejltilfælde eller operationelle omkostninger. Den praktiske læsning er derfor at måle på egne repræsentative workflows, før en model eller arkitektur bliver standardiseret.\nKilder: PrivEscalate: Measuring and Augmenting the Threat of LLM-Automated Linux Privilege Escalation; Q2D-Web: A Large-Scale Benchmark for Retrieval in Agentic RAG Systems.\nHvad er værd at tage med? Vælg ét afgrænset agent-workflow i næste uge, for eksempel en automatiseret dependency-opdatering: skriv en capability-matrix for læse-, ændre- og publish-rettigheder, og lad acceptance kræve både testresultat og én konkret policy- eller reviewkontrol. Kør derefter samme workflow på repræsentative repositories og fejlscenarier, så beslutningen bygger på den lokale arbejdsgang frem for en generel benchmark-score.\nOverblikket bygger på de linkede kilders abstracts eller artikeluddrag. Resultaterne er forfatternes egne rapporter; forslag til praksis er overblikkets fortolkning. Kildeudvalget dækker ikke al ugens forskning.\n","permalink":"https://karpov.dk/posts/ugens-ai-research-2026-09-10/","summary":"Ugens forskning samler sig om en enkel driftspointe: AI-agenter bør måles og begrænses i den konkrete workflow-kontekst, ikke kun på grønne tests eller generelle leaderboard-scorer.","title":"Ugens AI-forskning: Når agenters reelle kvalitet afgøres af workflowets grænser"},{"content":"En token er ikke særlig imponerende.\nDet er et ord, et stykke af et ord, et tegn eller noget andet, som en tokenizer har skåret teksten op i.\nAlligevel er tokens blevet AI-branchens nye møntfod. Vi køber dem i millioner, får dem i abonnementer og rammer limits på dem.\nOg når en coding agent har haft en produktiv eftermiddag, kan usage-siden ligne en mindre kommunes varmebudget.\nDet mærkelige er, at én million tokens ofte ser billig ud på prislisten.\nProblemet er bare, at agenten sjældent nøjes med én million.\nDen lille prompt, der blev til to millioner tokens Computerphile viste for nylig et godt eksempel. Mike Pound brugte GitHub Copilot til at lave en lille Windows 3.11-inspireret starfield-screensaver.\nEfter omkring seks prompts og arbejde i få filer viste sessionen cirka to millioner input-tokens og 47.000 output-tokens.\nDet er ikke et benchmark. Det er en konkret demonstration af mekanismen.\nAgenten læser ikke kun brugerens spørgsmål. Den får også systeminstruktioner, historik, tidligere svar, tool calls, filindhold, testresultater og fejlbeskeder med som kontekst. Ved næste handling er prompten blevet større.\nDen samme fil kan derfor ende på regningen flere gange.\nDet er lidt som at hyre en håndværker, der før hvert nyt søm genlæser tilbuddet, byggereglementet og hele WhatsApp-tråden med kunden.\nHåndværkeren kan være fremragende.\nMen man begynder at forstå timeprisen.\nHvorfor coding agents bruger flere tokens En coding agent og en general agent kan være bygget på den samme model. Forskellen ligger ofte i arbejdet omkring den.\nEn general agent kan finde tre mødetider, opsummere en mailtråd eller hente en ordrestatus. Den kalder nogle få API\u0026rsquo;er, får kompakte svar tilbage og afslutter opgaven.\nEn coding agent får typisk denne besked:\nDer er en fejl et sted i systemet. Find den, ret den, og bevis, at du ikke ødelagde noget andet.\nDet er ikke bare et spørgsmål.\nDet er en lille ekspedition.\nAgenten skal måske:\nfinde de relevante mapper og filer læse kode, konfiguration og tests følge afhængigheder på tværs af repoet skrive et patch køre build, lint og tests læse compilerfejl, stack traces og logs prøve igen, hvis første løsning fejler forklare resultatet til et menneske Hvert punkt skaber ny kontekst, som kan blive sendt med i næste modelkald.\nKode tåler heller ikke altid et kreativt resume.\n1 Der var noget med authentication. Jeg ordnede det vist. Agenten skal kende de præcise funktionsnavne, typer, imports og fejl. En enkelt parentes kan være forskellen på deployment og eftermiddagsmøde.\nRepository-arbejde er desuden en søgeopgave, før det er en kodeopgave. Agenten skal bruge tokens på at finde de fire relevante linjer, før den kan bruge tokens på at ændre dem.\nOg bagefter kommer valideringen:\n1 patch -\u0026gt; build -\u0026gt; fejl -\u0026gt; analyse -\u0026gt; nyt patch -\u0026gt; test Det er den rigtige arbejdsgang. Alternativet er kode uden kontrol.\nMen hvert loop koster.\nCoding agents bruger altså ikke nødvendigvis flere tokens, fordi de er dårligere. De bruger flere, fordi opgaven kræver mere søgning, mere præcision, flere tool calls og flere feedback loops.\nForskellen er ikke absolut. En research-agent med 40 rapporter eller en juridisk agent med tusindvis af sider kan være mindst lige så glubsk.\nCoding agents rammer bare meget naturligt alle de dyre mønstre.\nDe har fået adgang til repoet, terminalen og firmakortet på samme dag.\nCache hjælper, men cache er ikke hukommelse Modellen producerer ét token ad gangen. Hvert nyt token bygger på konteksten og det output, der allerede er genereret.\nFor at undgå at beregne alt helt fra bunden gemmer modellen mellemresultater i en KV-cache under genereringen. Det gør arbejdet langt hurtigere, men cachen optager acceleratorhukommelse og vokser med konteksten.\nPrompt caching er noget andet. Her genbruges en allerede behandlet begyndelse af prompten på tværs af API-kald: for eksempel en systemprompt, tool-definitioner eller et stort dokument.\nOpenAI anvender automatisk prompt caching på prompts fra 1.024 tokens. Cache-hits kræver et identisk prefix, så fast indhold bør ligge først og den variable brugerbesked sidst.\nAnthropic og Google tilbyder tilsvarende caching. Hos Anthropic koster et cache-hit en tiendedel af normal inputpris, men den første cache-write koster ekstra.\nDet er en god handel, hvis cachen faktisk bliver ramt.\nÆndrer man instruktionerne, flytter rundt på tools eller sender konteksten i en ny rækkefølge, kan rabatten forsvinde.\nDer findes også ineffektivitet som service.\nDen vigtigste besparelse ligger derfor ofte i applikationen selv:\nhent kun relevante filer og afsnit gem beslutninger som struktureret tilstand kompaktér historikken ved naturlige milepæle fjern gamle tool outputs start en ny session, når den gamle er blevet digitalt pulterkammer Det er ikke modelmagi.\nDet er kontekststyring.\nHvorfor bliver regningen større? Det er fristende at sige, at tokens bare bliver dyrere. Men prisen pr. token er faldet for mange modelklasser, mens den samlede regning er vokset.\nVi bruger modellerne til større opgaver, længere kontekster og flere autonome trin.\nVi har gjort benzin billigere og derefter opfundet en bil, der selv kører rundt for at lede efter flere veje.\nPrisstrukturen viser også, hvor omkostningen ligger. Den 3. juli 2026 kostede GPT-5.5 på OpenAI\u0026rsquo;s standardniveau 5 dollar pr. million input-tokens, 0,50 dollar for cached input og 30 dollar for output. Ved long context stiger priserne.\nClaude Fable 5 stod til 10 dollar for input og 50 dollar for output. Google viste samme grundmønster for Gemini 3.5 Flash: output var markant dyrere end input, mens cached context var billigere.\nTallene kan ikke bruges som en ren rangliste. Modeller, tokenizers, kvalitet og thinking er forskellige.\nMen de peger på tre enkle ting:\nStærkere modeller og hurtigere service tiers koster mere. Lang kontekst presser beregning og hukommelse. Reasoning, output og agentloops kan få et lille spørgsmål til at vokse voldsomt. En context window på en million tokens er teknisk imponerende.\nDen er ikke en opfordring til at fylde den.\nEffektivitet er pris pr. accepteret resultat Computerphile gør med rette grin med virksomheder, der måler AI-adoption på, hvor mange tokens medarbejderne bruger.\nDet er lidt som at måle en chaufførs kvalitet på dækslid.\nMen den agent, der bruger færrest tokens, er heller ikke automatisk bedst. Den kan være billig, fordi den gav op eller producerede kode, som et menneske bagefter bruger fire timer på at reparere.\nDen relevante enhed er derfor ikke kun:\npris pr. million tokens\nDen er:\npris pr. accepteret resultat\nFor et softwareteam kan det være pris pr. godkendt pull request, løst incident eller feature, der faktisk kom sikkert i drift.\nDerfor bør man måle:\ninput, cached input og output antal agenttrin og tool calls cache-hit-rate retries og loops menneskelig reviewtid fejl og genarbejde om resultatet blev accepteret Ellers kan den dyre model se billig ud, fordi den løser opgaven i ét forsøg. Den billige kan blive dyr, fordi den har besluttet sig for at lære gennem gentagelse.\nMin korte tjekliste Log almindeligt input, cached input og output hver for sig. Mål cache-hit-raten. En caching-feature er ikke en besparelse, før den rammer. Hent relevante filer og linjer, ikke hele virksomhedens digitale loftsrum. Kompaktér historikken ved milepæle. Sæt grænser for pris, trin, tid og gentagne fejl. Brug ikke frontier-modellen til arbejde, som en mindre model løser lige så sikkert. Sammenlign modeller på kvalitet, pris og menneskelig indsats på de samme opgaver. Det lyder mindre futuristisk end en million tokens.\nTil gengæld er det sådan, man undgår at betale for den samme fil seks gange.\nMin konklusion AI-modeller er effektive og ineffektive på samme tid.\nDe kan løse specialistopgaver på minutter. Men de gør det ved at behandle store mængder kontekst, generere ét token ad gangen og holde en voksende arbejdshukommelse tæt på dyr hardware.\nCaching hjælper. Bedre retrieval, compaction, model-routing og stopkriterier hjælper mere.\nAI bliver ikke billig, bare fordi prislisten bruger enheden pr. million.\nDen bliver billig, når systemet bruger den rigtige model, den rigtige kontekst og det rigtige antal trin til at skabe et resultat, nogen faktisk vil beholde.\nSå næste gang usage-grafen går lodret, er spørgsmålet ikke kun:\nHvor mange tokens brugte vi?\nMen:\nHvad fik vi for dem?\nHvis svaret er en testet ændring, der kom sikkert i drift, kan regningen være fin.\nHvis svaret er 14 tool calls, tre genlæste filer og en undskyldning fra agenten, har man ikke købt intelligens.\nMan har købt aktivitet.\nSoftwarebranchen har altid haft rigeligt af det.\nLæs også AI-agenter skal bruge hukommelse DevOps er ikke en pipeline Mit Obsidian-vault fik en lille forskningsafdeling Kilder Computerphile: Why AI Tokens are so Expensive OpenAI API: Pricing OpenAI API: Prompt caching Anthropic: Prompt caching Google AI for Developers: Context caching Google AI for Developers: Gemini API pricing Cache What Lasts: Token Retention for Memory-Bounded KV Cache in LLMs Accelerating LLM Inference via Dynamic KV Cache Placement in Heterogeneous Memory System ","permalink":"https://karpov.dk/posts/ai-tokens-er-billige-regningen-er-det-ikke/","summary":"Coding agents læser filer, kører tests og sender en voksende arbejdshistorik gennem modellen. Derfor kan en billig tokenpris stadig blive til en dyr opgave.","title":"AI-tokens er billige. Regningen er det ikke."},{"content":"Jeg tror, mange gør jobsøgning sværere, end den behøver at være.\nIkke fordi det er nemt. Det er det ikke. Jobsøgning er en mærkelig blanding af research, salg, selvindsigt, timing, tilfældigheder og små formularer, der alle sammen gerne vil have ens CV på en lidt ny måde.\nMen fordi man hurtigt kommer til at behandle det som en følelsesbaseret aktivitet:\nHar jeg lyst i dag? Føles den her rolle rigtig? Er mit CV godt nok? Hvorfor har ingen svaret? Skal jeg ændre hele min profil klokken 23:41? Det er forståeligt.\nDet er bare ikke en særlig god driftsmodel.\nSå jeg begyndte at behandle min jobsøgning mere som et lille delivery-system.\nIkke koldt. Ikke kynisk. Bare mere struktureret.\nFørste problem: for mange åbne loops En jobsøgning skaber hurtigt flere åbne loops, end man tror.\nDer er roller, der skal vurderes. CV\u0026rsquo;er, der skal tilpasses. Ansøgninger, der skal sendes. Recruiters, der skal kontaktes. LinkedIn-profiler, der skal opdateres. Samtaler, der skal forberedes. Opfølgninger, der ikke må glemmes. Afslag, der skal håndteres uden at lave personlighedsreform hver gang.\nHvis det hele ligger i hovedet, bliver det hurtigt støj.\nOg støj føles som dårlig selvtillid, selv når problemet egentlig er manglende system.\nDet kender jeg fra softwarearbejde:\nNår ingen ved, hvad der er deployed, hvad der fejler, hvem der ejer hvad, og hvilken ændring der kommer næste gang, føles systemet kaotisk.\nJobsøgning er ikke så anderledes.\nJeg lavede en backlog Det første nyttige skridt var at gøre rollerne konkrete.\nIkke bare:\nJeg leder efter noget inden for DevOps.\nMen:\nHvilke roller er stærkest? Hvilke er platform/DevOps? Hvilke er senior backend med platformansvar? Hvilke er backup-volume? Hvad er status? Hvad er næste handling? Hvornår skal der følges op? Det lyder banalt.\nDet er også pointen.\nEn god jobsøgning behøver ikke begynde med personlig branding i højglans. Den kan begynde med en tabel.\nJeg endte med at dele rollerne op i spor:\nplatform og DevOps senior backend med drift og reliability SRE og observability AI/platform-adjacent roller lavere prioriterede backup-roller Det gjorde det nemmere at sige nej til roller, der kun var interessante, fordi de eksisterede.\nDet gjorde også CV-arbejdet mere ærligt. Jeg skulle ikke opfinde en ny person til hver ansøgning. Jeg skulle bare fremhæve den del af min profil, der faktisk passede.\nPositionering er ikke pynt Jeg har en senior software engineering-baggrund og har senest arbejdet tættere på DevOps, infrastruktur, CI/CD, testmiljøer, monitoring, fejlsøgning og dokumentation.\nDen kombination kan forklares på mange måder.\nDårlig version:\nJeg kan lidt af det hele.\nBedre version:\nJeg kan bygge software, men jeg tænker også på deployment, drift, observability, dokumentation og developer experience.\nDet er forskellen på en kompetenceliste og en retning.\nFor mig blev den offentlige version cirka:\nSenior software engineer med praktisk DevOps- og platformerfaring, der gerne vil arbejde med systemer, teams faktisk kan drive.\nDet er ikke en perfekt slogan-sætning. Gudskelov.\nMen den er brugbar, fordi den hjælper med at sortere:\nRoller med platformansvar passer. Senior backend-roller med reliability passer. Rent frontendprodukt uden drift passer dårligere. Ren management uden hands-on teknik passer dårligere. Positionering er ikke pynt. Det er et filter.\nHver rolle fik en lille playbook Det næste skridt var at stoppe med at starte forfra hver gang.\nFor de mest relevante roller lavede jeg en kort note med:\nhvorfor rollen passer hvilken del af CV\u0026rsquo;et der skal fremhæves hvilken ansøgningstekst der kan bruges hvilke interviewspørgsmål der sandsynligvis kommer hvilke spørgsmål jeg selv bør stille hvornår der skal følges op Det er meget tæt på det, jeg ville gøre for et teknisk system:\nHvad er konteksten? Hvad er afhængighederne? Hvad er den næste sikre handling? Hvad skal vi kunne forklare bagefter? Det fjerner ikke usikkerheden.\nMen det gør usikkerheden mindre tåget.\nInterview stories skal være genbrugelige En af de vigtigste ting var at lave et lille story bank.\nIkke en roman.\nBare korte, brugbare historier:\nen om production troubleshooting og observability en om testmiljøer og deployment workflows en om senior review og sikkerhedstænkning en om AI-assisteret dokumentation og knowledge management en om en fejl og hvad jeg lærte af den Det hjælper, fordi interviews sjældent belønner den person, der har flest erfaringer i hovedet.\nDe belønner den person, der kan finde den rigtige erfaring hurtigt og forklare den klart.\nDet er også en DevOps-ting:\nHvis runbooken først skal skrives under incidenten, er den for sent ude.\nHvis interviewhistorien først skal findes, mens nogen spørger \u0026ldquo;kan du give et eksempel?\u0026rdquo;, bliver svaret ofte længere, mere nervøst og mindre præcist.\nFollow-up er en del af systemet Jeg bryder mig ikke særligt meget om opfølgninger.\nDe kan hurtigt føles som at banke på en dør, hvor man ikke ved, om nogen er hjemme, eller om huset overhovedet findes.\nMen uden opfølgning bliver jobsøgning mærkeligt passiv.\nSå jeg satte en simpel regel:\nEfter cirka fem arbejdsdage uden svar er en kort, høflig opfølgning rimelig, medmindre processen tydeligt siger noget andet.\nIkke en roman.\nIkke:\nJeg skriver for tredje gang for at genbekræfte min dybe passion for jeres transformative rejse.\nBare:\nJeg vil bare følge kort op på min ansøgning. Rollen passer godt med min erfaring inden for senior softwareudvikling, DevOps, CI/CD, observability og platformarbejde. Jeg tager gerne en kort samtale, hvis profilen er relevant.\nDet er nok.\nAI hjalp, men den måtte ikke overtage Jeg brugte AI meget i processen.\nIkke til at opfinde mig selv.\nTil at strukturere.\nAI var god til:\nat sammenligne jobopslag med min profil at lave første udkast til CV-varianter at gøre ansøgningstekster kortere at finde huller i positioneringen at bygge interviewspørgsmål at omsætte løse noter til STAR-historier at holde styr på opfølgninger Men der er en vigtig grænse.\nAI må gerne hjælpe med formen. Den må ikke fjerne ejerskabet.\nHvis jeg ikke kan forsvare en sætning i en samtale, skal den ikke stå i mit CV.\nHvis jeg ikke har lyst til at forklare en teknologi under interview, skal den ikke fremhæves som en kernekompetence.\nHvis AI får teksten til at lyde som en person, der har været \u0026ldquo;passionate about scalable solutions\u0026rdquo; siden børnehaven, skal teksten ned på jorden igen.\nDet er måske den vigtigste regel:\nBrug AI til at blive tydeligere.\nIkke til at blive glattere.\nBloggen blev en del af beviset Noget af det mest nyttige var at forbinde jobsøgningen med min blog.\nIkke som et stort \u0026ldquo;personal brand\u0026rdquo;-projekt.\nMere som praktisk dokumentation:\nHer er hvordan jeg tænker om DevOps. Her er hvordan jeg tænker om AI i produktion. Her er hvordan jeg tænker om observability, governance og platformarbejde. Her er konkrete eksempler på, at jeg kan skrive klart om tekniske systemer. Det giver en anden type bevis end et CV.\nEt CV siger:\nJeg har arbejdet med det her.\nEn god teknisk blog siger:\nSådan tænker jeg, når jeg arbejder med det her.\nBegge dele er nyttige.\nMen i seniorroller er den anden ofte lige så vigtig.\nDet mest nyttige var ro Den største effekt af systemet var ikke, at alt blev perfekt.\nDet blev det ikke.\nDer var stadig ventetid. Stadig usikkerhed. Stadig roller, der passede bedre på papiret end i virkeligheden. Stadig dage, hvor det hele føltes lidt som at sende små flaskeposter ind i et ATS-system med dårlig belysning.\nMen systemet gjorde arbejdet roligere.\nNår noget gik i stå, kunne jeg spørge:\nHvad er næste konkrete handling? Hvilken rolle er vigtigst lige nu? Er det CV, outreach, interview prep eller opfølgning? Har jeg en god historie klar? Skal jeg justere strategien, eller bare fortsætte? Det er meget bedre end:\nHvad er der galt med mig?\nNogle gange er svaret ikke dyb eksistentiel analyse.\nNogle gange mangler man bare en tracker.\nMin lille tjekliste Hvis jeg skulle give mit eget jobsøgningssystem videre til en anden udvikler, ville det være det her:\nLav en prioriteret liste over roller. Del dem op i spor, så du ikke ændrer identitet for hver ansøgning. Skriv én klar positioneringssætning. Lav en lille playbook for hver stærk rolle. Gem hver CV-version, du sender. Forbered 4-5 korte interview stories. Følg op efter nogle arbejdsdage, hvis processen er stille. Brug AI til struktur, ikke til pynt. Brug portfolio, blog eller projekter som bevis. Evaluer ugentligt, ikke efter hvert enkelt afslag. Jobsøgning bliver aldrig helt rationelt.\nDet handler om mennesker, timing, behov, kemi, budgetter og en del ting, man ikke kan se udefra.\nMen man kan godt gøre sin egen del mere driftbar.\nOg for mig har det været den mest nyttige måde at tænke på:\nJobsøgning er ikke kun en serie ansøgninger.\nDet er et lille system.\nOg små systemer bliver bedre, når man giver dem struktur, feedback og lidt observability.\nLæs også DevOps er ikke en pipeline AI-agenter skal bruge hukommelse Fra prompt til prototype: AI hjalp mig ikke bare med at bygge. Den hjalp mig med at slette. Portfolio: DevOps, Platform Engineering og .NET Note Dette indlæg bygger på mine egne jobsøgningsnoter, CV-iterationer, interviewforberedelse og workflow-eksperimenter fra 2026. Jeg har udeladt konkrete virksomhedsdetaljer, live processer og private kontaktoplysninger.\n","permalink":"https://karpov.dk/posts/jobsoegning-er-ogsaa-et-system/","summary":"Da jeg begyndte at behandle jobsøgning som et system i stedet for en bunke enkeltstående ansøgninger, blev arbejdet roligere, skarpere og mere ærligt.","title":"Jobsøgning er også et system"},{"content":"Jeg skrev for nylig, at AI-agenter skal bruge API\u0026rsquo;er.\nDet mener jeg stadig.\nMen API\u0026rsquo;er er kun halvdelen af problemet.\nEn agent, der kan kalde et API, kan gøre noget i verden. Den kan hente data, oprette en pull request, ændre en konfiguration, skrive en kommentar eller starte en proces.\nDet er nyttigt.\nDet er også dér, problemerne begynder.\nFor hvis agenten ikke kan huske, hvorfor den gjorde noget, hvilke kilder den brugte, hvilke checks der fejlede, hvilke beslutninger et menneske allerede har taget, og hvor grænsen for opgaven går, så har man ikke fået en kollega.\nMan har fået en meget hurtig praktikant med hukommelsestab og adgang til produktion.\nDet lyder måske som en joke.\nDet er mest en driftshændelse, der venter på at ske.\nHukommelse er ikke chat history Mange tænker stadig på AI-hukommelse som en længere samtale.\nDet er for snævert.\nFor rigtige AI-agenter handler hukommelse ikke kun om at huske, hvad brugeren skrev for fem minutter siden. Det handler om at kunne arbejde med tilstand over tid.\nEn brugbar agent skal kunne huske:\nopgavens mål hvilke filer, systemer og kilder den har brugt hvilke antagelser den har lavet hvilke checks der er kørt hvad der fejlede hvad den allerede har prøvet hvilke beslutninger et menneske har godkendt hvilke dele af arbejdet der stadig er usikre Det er ikke romantisk AI.\nDet er almindelig software engineering.\nMen det er præcis derfor, det er vigtigt.\nKontekst uden struktur bliver hurtigt støj En stor context window kan føles som en løsning.\nBare giv modellen mere tekst. Flere filer. Flere noter. Flere logs. Hele repoet. Hele dokumentationen. Hele virksomhedens kollektive dårlige samvittighed i Markdown.\nProblemet er, at mere kontekst ikke automatisk giver bedre forståelse.\nNogle gange giver det bare en agent flere muligheder for at finde den forkerte detalje og lyde sikker imens.\nDerfor tror jeg, at agent memory bliver et systemproblem, ikke kun et modelproblem.\nHukommelsen skal have struktur:\nHvad er fakta? Hvad er en beslutning? Hvad er en midlertidig antagelse? Hvad er et gammelt notat? Hvad er en kilde? Hvad er en valideret ændring? Hvad er en opgave, der stadig mangler review? Hvis alt bare ligger som tekst i én stor bunke, bliver agenten ikke nødvendigvis klogere. Den bliver bare bedre fodret.\nOg alle, der har arbejdet med gamle dokumentationsmapper, ved at godt fodret forvirring stadig er forvirring.\nMin lille version: Obsidian som agent-hukommelse Jeg har brugt min egen Obsidian-vault som et lille laboratorium for det her.\nIkke som et stort fancy produkt. Mere som et praktisk forsøg:\nKan noter, research, opgaver, skills og links gøres brugbare for AI-agenter over tid?\nDet korte svar er ja.\nMen kun hvis noterne er skrevet til at blive brugt igen.\nEn note, der bare er et tekst-dump, hjælper ikke meget. En note med en kort konklusion, frontmatter, kilder, status, relaterede noter og et tydeligt link til en hub er meget mere værd.\nDet lyder småt.\nDet er det ikke.\nFor når en agent starter en opgave, skal den kunne finde den rigtige kontekst uden at læse hele mit digitale loftsrum først.\nDerfor er jeg begyndt at behandle noter som små memory objects:\ntype: er det research, guide, skill, dashboard eller reference? status: er det aktivt, udkast, arkiveret eller superseded? memory: er det semantisk viden, en procedure eller en episodisk log? confidence: hvor sikker er noten? source: hvor kommer informationen fra? related notes: hvor hører den hjemme i grafen? Det er ikke fordi YAML er magisk.\nDet er fordi agenten skal kunne sortere.\nDen vigtige forskel: at huske og at bevise En agent skal ikke kun huske.\nDen skal også kunne vise, hvorfor den mener noget.\nDet er her, software engineering og AI governance mødes ret naturligt.\nHvis en agent ændrer kode, skal vi kunne se:\nhvad den ændrede hvorfor den ændrede det hvilke tests der blev kørt hvilke tests der ikke blev kørt hvilke filer den rørte hvilke krav den forsøgte at opfylde hvilke risici der stadig findes Det er meget tæt på almindelig PR-disciplin.\nOg måske er det pointen.\nDen bedste agent-hukommelse er ikke en mystisk AI-evne. Det er en kombination af gode noter, gode logs, klare opgaver, tests, review og en smule ydmyghed.\nAltså: alt det kedelige, der plejer at redde softwareprojekter, når demoen er slut.\nNår agenter arbejder længere, bliver drift vigtigere OpenAI, Microsoft og GitHub bevæger sig alle i retning af agenter, der arbejder længere og tættere på rigtige workflows.\nDet kan være coding agents i GitHub, agentic development i Warp, enterprise-kontekst i Microsoft 365 eller baggrundsopgaver, der ikke bare svarer i en chat, men faktisk forsøger at gennemføre et stykke arbejde.\nDet ændrer risikobilledet.\nEn chatbot, der svarer forkert, er irriterende.\nEn agent, der arbejder forkert i flere timer med adgang til tools, repositories og interne data, er noget andet.\nDerfor bliver de gamle DevOps-spørgsmål pludselig meget moderne igen:\nHvad må køre automatisk? Hvad kræver review? Hvor er logs? Hvordan opdager vi fejl? Hvordan stopper vi processen? Hvem ejer ændringen? Hvad sker der, når agenten rammer en uklar instruktion? Det er ikke nok, at agenten er intelligent.\nDen skal også være driftbar.\nAgent-ready betyder memory-ready Jeg tror, mange teams kommer til at tale om, om deres systemer er agent-ready.\nDet er et godt spørgsmål.\nMen det bør ikke kun handle om API\u0026rsquo;er.\nEt agent-ready system skal også være memory-ready:\nDokumentationen skal være opdateret nok til at blive brugt. Beslutninger skal være synlige. Systemgrænser skal være tydelige. Tests og checks skal kunne køres uden drama. Logs skal kunne forklare både menneskelige og agentdrevne handlinger. Opgaver skal have klare stopkriterier. Vigtig viden skal kunne findes igen. Hvis det lyder som godt platform engineering-arbejde, er det fordi det er det.\nAI gør ikke de gamle disciplinproblemer mindre vigtige.\nDen gør dem mere synlige.\nMin konklusion AI-agenter skal bruge API\u0026rsquo;er.\nMen de skal også bruge hukommelse.\nIkke bare som en lang chatlog, men som en struktureret arbejdshukommelse med kilder, beslutninger, status, validering og review.\nEllers får vi agenter, der kan handle uden at kunne forklare sig.\nOg det er en dårlig kombination.\nDen næste store AI-opgave i virksomheder bliver derfor ikke kun at købe flere agents.\nDet bliver at bygge miljøer, hvor agents kan arbejde uden at gøre systemerne mere uklare.\nDet handler om kontekst.\nDet handler om drift.\nDet handler om hukommelse.\nOg ja, det betyder desværre, at dokumentation stadig betyder noget.\nBeklager.\nLæs også:\nDevOps er ikke en pipeline Obsidian som selvforbedrende graf Kilder OpenAI: Warp\u0026rsquo;s big bet on building open source with GPT-5.5 OpenAI: Codex for almost everything Microsoft: AI alone won\u0026rsquo;t change your business. The system running it will. GitHub Changelog: Copilot CLI improved UI, rubber duck, prompt scheduling and voice input arXiv: Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads arXiv: Memory is Reconstructed, Not Retrieved: Graph Memory for LLM Agents ","permalink":"https://karpov.dk/posts/ai-agenter-skal-bruge-hukommelse/","summary":"API\u0026rsquo;er giver AI-agenter adgang til systemer. Hukommelse afgør, om de kan arbejde ansvarligt over tid uden at gentage fejl, miste kontekst eller opfinde en flot forklaring bagefter.","title":"AI-agenter skal bruge hukommelse"},{"content":"\nJeg satte mig egentlig bare for at finde en god app-idé.\nDet lyder uskyldigt.\nDet er det ikke.\nEn “god app-idé” er lidt som “en simpel integration”, “et hurtigt MVP” eller “vi skal bare lige have styr på deployment”. Det starter som en lille tanke og ender ofte med tre dashboards, en auth-løsning, en pricing-model, en pitch deck og en følelse af, at man nok lige burde åbne YouTube for at få hjernen tilbage.\nJeg ville undgå den fælde.\nSå jeg brugte AI som sparringspartner.\nIkke til bare at spytte 20 ideer ud.\nDet kan alle modeller efterhånden. Det er ikke imponerende længere. Det er bare en meget høflig brainstorm med turbo på.\nDet interessante var noget andet:\nKunne jeg bruge AI til at sortere, kritisere, skære væk og komme frem til en idé, der faktisk kunne testes?\nResultatet blev en prototype på Vært — en diskret dansk concierge for private middage, hosting, kultur, sommerhusliv og trusted services.\nIkke “ChatGPT for rige mennesker”.\nHeldigvis.\nProblemet var ikke mangel på ideer Når man beder AI om app-idéer, får man hurtigt en buffet.\nOg som med de fleste buffeter er problemet ikke, at der mangler mad. Problemet er, at man ender med lidt af det hele og bagefter ikke helt ved, hvorfor man tog pastasalat.\nAI foreslog alt muligt:\nlokal AI-assistent personlig produktivitetscoach app til unge professionelle social planning-app app til sommerhuse dining club privat netværk digital concierge noget med events noget med premium adgang noget med AI, fordi alt åbenbart skal have AI i navnet nu Noget af det var godt.\nMeget af det var sådan en slags produktudviklingens mellemhylde: ikke dumt nok til at smide ud med det samme, men heller ikke skarpt nok til at bygge noget på.\nDet er faktisk en farlig zone.\nFor dårlige ideer dør hurtigt. Middelmådige ideer kan leve længe, især hvis de har et pænt navn og en landing page.\nDen første læring var derfor ret enkel:\nAI er ikke mest værdifuld som idémaskine. AI er mest værdifuld som filter.\nDet vigtige spørgsmål var ikke:\n“Kan vi finde på flere ideer?”\nDet kunne vi sagtens. Det kan en model gøre hurtigere end en konsulent kan åbne en Miro-template.\nDet vigtige spørgsmål var:\n“Hvilken idé har en tydelig målgruppe, et reelt problem, betalingsvilje og en første version, der kan testes uden at bygge et helt IT-imperium?”\nDer begyndte processen at blive interessant.\nDen brede AI-app døde først Mange AI-produkter starter med samme sætning:\n“Folk har brug for en personlig assistent.”\nDet er ikke forkert.\nDet er bare for bredt.\nHvis alle er målgruppen, er ingen målgruppen. Det lærte man sikkert på handelsskolen. Jeg lærte det ved at bruge alt for mange prompts på at få en model til at sige det samme på 17 forskellige måder.\nSå jeg begyndte at presse ideerne:\nHvem har et problem, der faktisk koster penge? Hvem betaler for kvalitet og tid — ikke bare features? Hvor kan Danmark være en fordel i stedet for en begrænsning? Hvad kan starte manuelt? Hvad bliver bedre af netværk, tillid og lokal kontekst? Hvad skal ikke være endnu en chatbot med abonnement? Det sidste spørgsmål er vigtigt.\nVi har rigeligt med produkter, hvor konceptet i praksis er:\n“ChatGPT, men med vores logo.”\nDet kan godt være et interface.\nDet er sjældent en stærk forretning alene.\nLangsomt begyndte én idé at skille sig ud:\nEn privat dansk concierge.\nIkke en luksus-app med guldfarvet UI, VIP-sprog og desperat “premium energy”. Mere en rolig service for mennesker, der har råd til at betale for tid, diskretion, smag og koordinering.\nArbejdstitlen blev:\nVært\nKort. Dansk. Roligt.\nIkke Silicon Valley. Ikke Dubai. Mere København, Nordsjælland og sommerhus med nogenlunde styr på blomsterne.\nDen bedste AI-idé blev mindre AI Det mest interessante ved processen var, at idéen blev mindre og mindre “AI”, jo bedre den blev.\nI starten ville den nemme pitch have været:\n“En AI-concierge for velhavende danskere.”\nDet lyder som noget, der kunne stå i et pitch deck med gradienter, stock photos og ordet “seamless” lidt for mange gange.\nMen jo mere jeg arbejdede med idéen, jo mere tydeligt blev det:\nProduktet er ikke AI.\nProduktet er tillid.\nProduktet er adgang.\nProduktet er at spare tid.\nProduktet er at kunne skrive:\n“Vi får seks gæster på fredag. Det skal være godt, men ikke stift. Find en løsning.”\nOg så få et svar, der faktisk passer.\nIkke en generisk liste med restauranter.\nIkke en hallucineret vinmenu.\nIkke en chatbot, der siger “det lyder som en fantastisk aften!” og derefter foreslår noget, der minder om Tripadvisor med selvtillid.\nEn rigtig løsning.\nDet ændrede også AI’s rolle.\nAI skal ikke nødvendigvis være forsiden.\nAI skal være maskinrummet.\nDen kan hjælpe med at:\nstrukturere requests opsummere præferencer lave concierge-briefs foreslå leverandører skrive høflige svar huske hvad medlemmet ikke gider lave checklister til arrangementer hjælpe med research og partner-outreach Men selve oplevelsen skal føles menneskelig, lokal og diskret.\nDet er en produktlektion, jeg tror mange kommer til at lære de næste år:\nJo mere premium oplevelsen er, jo mindre skal AI’en stå og råbe “se mig”.\nIteration er det rigtige AI-arbejde Der er en lidt mærkelig misforståelse om AI: at værdien ligger i det første svar.\nDet gør den næsten aldrig.\nDet første svar er ofte bare råmateriale.\nDet gode kommer i loopet bagefter.\nJeg kunne blive ved med at udfordre modellen:\n“Det her er for generisk.” “Find en smallere niche.” “Hvem betaler faktisk for det?” “Hvad er første wedge?” “Hvorfor virker det i Danmark?” “Hvad skal vi ikke bygge?” “Gør det mere eksklusivt, men ikke cringe.” “Det skal føles dansk, ikke amerikansk.” “Lav en prototype uden backend.” “Skær alt væk, der lugter af en LinkedIn-case.” Det er her, AI bliver praktisk.\nIkke fordi den har perfekt dømmekraft.\nDet har den ikke.\nMen fordi den kan holde momentum i en tankeproces.\nNormalt dør mange ideer i det grå mellemrum mellem:\n“Det kunne være sjovt”\nog\n“Hvad er version 0?”\nAI hjælper med at bygge bro over det mellemrum.\nMen kun hvis man selv bliver ved med at være kritisk.\nEllers får man bare en meget velformuleret dårlig idé.\nPrototype før platform Som udvikler får man hurtigt lyst til at bygge.\nDet er nærmest en refleks.\nMan ser en idé og tænker:\nlogin database admin panel request system partner portal betaling notifikationer måske lige lidt Kubernetes, fordi man har karakterbrist Men for Vært gav det ikke mening endnu.\nDen rigtige første version var ikke en færdig SaaS-platform.\nDen rigtige første version var en prototype, der kunne forklare følelsen:\nHvad er Vært? Hvem er det for? Hvordan sender man en request? Hvilke typer ønsker håndterer den? Hvordan føles medlemsoplevelsen? Ville nogen overhovedet betale for det? Derfor blev første prototype statisk.\nIngen backend.\nIngen database.\nIngen login.\nIngen betalt AI API.\nBare en showcase, der viser:\nprivat member dashboard concierge request flow kurateret adgang partner/service-netværk medlemspræferencer founding membership Det er ikke fordi backend aldrig bliver relevant.\nDet er fordi backend først skal bygges, når man ved, hvad den skal understøtte.\nEllers bygger man bare et meget flot system til en antagelse.\nOg antagelser har det med at ligne arkitektur, lige indtil en rigtig bruger møder dem.\nDen manuelle MVP er ikke snyd Det sværeste for udviklere er nogle gange at acceptere, at den bedste MVP ikke er software.\nDet gør lidt ondt.\nMan vil gerne have et repo. En pipeline. Et miljø. En README. Måske et lille badge, der viser at noget er grønt.\nMen Vært skal først testes manuelt.\nVersion 0 kan være:\nen landing page et invite-only form en mailadresse en simpel request-proces et spreadsheet med medlemmer og præferencer en håndplukket partnerliste manuel koordinering Det lyder primitivt.\nDet er det ikke.\nDet er produktdisciplin.\nHvis ingen vil sende requests manuelt, hjælper det ikke at bygge en app.\nHvis ingen vil betale for adgang, hjælper det ikke at optimere onboarding.\nHvis requests viser sig at handle om noget helt andet end forventet, er det bedre at lære det i et spreadsheet end efter tre ugers frontend-arbejde og en diskussion om hvilken toast-library der er mest elegant.\nHvad AI faktisk hjalp med AI hjalp ikke ved at “opfinde” Vært ud af ingenting.\nDet ville være en lidt for pæn historie.\nAI hjalp med at gøre processen hurtigere og mere brutal.\nDen hjalp med at:\nUdvide feltet af muligheder. Sammenligne ideer mod hinanden. Finde svagheder i de mest charmerende ideer. Skærpe målgruppen. Oversætte et vagt behov til konkrete use cases. Formulere en prototype. Holde fast i MVP-disciplinen. Sige “nej” til features, der mest var udviklerdopamin. Det sidste er undervurderet.\nAI kan meget nemt give dig flere ting at bygge.\nDen vigtige brug er at få den til at hjælpe dig med at bygge mindre.\nDen næste test er virkeligheden Vært er stadig kun en prototype.\nDet er vigtigt at sige.\nEn prototype er ikke en virksomhed.\nEn landing page er ikke traction.\nEn god idé er ikke proof.\nOg en AI-genereret analyse er ikke betalingsvilje.\nDen næste test er langt mere jordnær:\nKan jeg tale med 10 relevante mennesker? Vil nogen sige “det her ville jeg faktisk bruge”? Kan jeg få founding members eller stærke verbale ja’er? Kan jeg logge rigtige concierge-requests? Kan jeg finde pålidelige partnere? Kan idéen overleve kontakt med virkeligheden? Det er her, projektet enten bliver interessant eller bliver endnu en pæn note i Obsidian.\nOg det er fair.\nObsidian kan godt tåle flere noter.\nMarkedet er mindre sentimentalt.\nKonklusionen AI er ikke en magisk founder.\nAI gør ikke automatisk en idé god.\nAI kan sagtens hjælpe dig med at bygge en dårlig idé hurtigere, flottere og med mere overbevisende formuleringer.\nMen brugt rigtigt kan AI være en stærk produktpartner.\nIkke fordi den ved alt.\nMen fordi den gør det lettere at tænke i loops:\nidé → kritik → research → struktur → prototype → test\nFor mig endte processen ikke med endnu en chatbot.\nDen endte med en mere præcis tanke:\nVelhavende danskere har ikke brug for mere software. De har brug for bedre adgang, mindre friktion og nogen, der kan få ting til at ske smagfuldt.\nDet er måske en app.\nDet er måske en service.\nDet er måske først bare en mailadresse og en god liste med mennesker, man kan stole på.\nMen det er en bedre start end en generisk AI-assistent med abonnement.\nOg nogle gange er det netop pointen med AI:\nIkke at få den til at bygge mere.\nMen at få den til at hjælpe dig med at skære væk, indtil idéen bliver tydelig nok til at kunne testes.\nLæs også:\nMit Obsidian-vault fik en lille forskningsafdeling DevOps er ikke en pipeline ","permalink":"https://karpov.dk/posts/fra-prompt-til-prototype-vaert/","summary":"Jeg brugte AI som produktpartner til at teste, forkaste og skærpe app-idéer. Resultatet blev ikke endnu en chatbot, men en prototype på Vært: en diskret dansk concierge for hosting, dining, kultur og trusted services.","title":"Fra prompt til prototype: AI hjalp mig ikke med at få flere ideer — den hjalp mig med at dræbe de dårlige"},{"content":"Jeg var til AI4Diversity hos Danske Bank.\nDer blev sagt meget fornuftigt om AI, inklusion, kompetencer og ansvar. Den slags arrangementer kan nogle gange ende som en lang panelversion af en LinkedIn-post, men her var der faktisk noget at tage med hjem.\nEn sætning blev hængende:\nAI is an equalizer.\nJeg er både enig og uenig.\nDet er et godt tegn. De bedste sætninger er ofte dem, man ikke bare kan nikke til og gå videre fra.\nJeg vibe-codede under oplæggene Jeg sad og lyttede til folk fra Danske Bank tale om AI, governance og bredere perspektiver, mens jeg samtidig vibe-codede lidt på min egen maskine.\nDet er måske meget 2026:\nMan sidder til et arrangement om ansvarlig AI i en bank og bygger videre på sine egne små workflows med AI ved siden af.\nDet føltes ikke som en modsætning. Det føltes faktisk som pointen.\nAI er allerede blevet en del af arbejdet. Ikke kun som en chatbot, man spørger om kommaer. Men som en ekstra hånd på research, noter, kode, struktur og små beslutninger undervejs.\nNår det virker, er det en equalizer.\nEn person med en laptop kan pludselig arbejde som et lille team. En ikke-native speaker kan formulere sig skarpere. En udvikler kan få sparring på kode, noter og arkitektur uden at vente på, at kalenderen viser nåde.\nDet er stærkt.\nMen så kommer banken.\nBanker er ikke et neutralt sted at teste optimisme I en bank er AI ikke bare et produktivitetsværktøj.\nDet kan påvirke kredit, svindelkontrol, kundeservice, risikovurdering, compliance, identitet, rådgivning og adgang til helt almindelige finansielle tjenester.\nDerfor bliver \u0026ldquo;AI som equalizer\u0026rdquo; hurtigt mere kompliceret.\nHvis modellen hjælper flere mennesker med at forstå økonomi, søge lån eller få hurtigere hjælp, er det positivt.\nHvis modellen derimod lærer gamle mønstre af skæve data og pakker dem ind i et moderne interface, har man ikke fået lighed. Man har fået automatiseret forskelsbehandling med bedre UX.\nOg det er her, Danske Bank faktisk er et ret interessant sted at have samtalen.\nDen oplagte, lidt for nemme joke Danske Bank har jo haft sin historik med hvidvask.\nDet er en sætning, der næsten skriver sig selv, og derfor skal man passe lidt på med den. Men den er også relevant.\nFor hvis nogen ved, at mønstergenkendelse i banker ikke kun er en akademisk øvelse, er det nok Danske Bank.\nAI kan hjælpe med anti-hvidvask. Ikke som magisk \u0026ldquo;find alle de onde\u0026rdquo;-knap, men som et værktøj til at se mønstre, prioritere sager, opdage afvigelser og hjælpe mennesker med at bruge deres tid bedre.\nAltså: AI kan måske hjælpe banken med hvidvask.\nForhåbentlig i betydningen imod.\nDet er en lille sproglig detalje. Men i bankverdenen er små detaljer åbenbart ret vigtige.\nDen kedelige del er den vigtige Det mest interessante fra Danske Bank-vinklen var ikke, at AI kan være smart.\nDet ved alle efterhånden.\nDet interessante var idéen om, at bedre AI kræver bredere perspektiver. Det lyder pænt, men det er også teknisk rigtigt.\nHvis et AI-system skal bruges i en stor organisation, skal der være styr på:\nhvilke data det lærer af hvem det virker dårligt for hvordan fejl opdages hvem der må bruge det hvad der logges hvordan beslutninger forklares hvordan mennesker kan overtage hvordan man klager, retter og ruller tilbage Det er ikke kun diversity. Det er systemkvalitet.\nDet er heller ikke kun jura. Det er produktudvikling, DevOps, UX, data governance og almindelig ansvarlig drift.\nMin konklusion AI kan være en equalizer.\nMen kun hvis folk faktisk får adgang til den, lærer at bruge den og kan udfordre de beslutninger, den påvirker.\nEllers bliver den bare endnu et filter mellem mennesker og muligheder.\nI bedste fald gør AI dygtige mennesker stærkere og åbner døren for flere.\nI værste fald bliver den en meget effektiv måde at gentage gamle fejl på.\nBare hurtigere, pænere og med en bedre demo.\nLæs også:\nDevOps er ikke en pipeline Jobsøgning er også et system Kilder AI4Diversity: Diversity Charter Denmark\u0026rsquo;s Signing Event 2026 Diversity Charter Denmark på LinkedIn: AI4Diversity-program og Danske Bank-oplæg Danske Bank: Findings of the investigations relating to Danske Bank\u0026rsquo;s branch in Estonia U.S. Department of Justice: Danske Bank Pleads Guilty To Fraud On U.S. Banks ","permalink":"https://karpov.dk/posts/ai-er-en-equalizer-indtil-den-rammer-banken/","summary":"AI kan være en equalizer. Men i banker bliver den også hurtigt en risikomaskine, hvis data, governance, forklaringer og kontrol ikke følger med.","title":"AI er en equalizer, indtil den rammer banken"},{"content":"\nJeg har gjort noget, der på papiret lyder en smule farligt:\nJeg har givet mit Obsidian-vault en lille AI-agent.\nIkke en agent med adgang til at købe aktier, slette produktion eller sende mails til tidligere chefer klokken 02:13. Det ville være en anden type blogindlæg. Muligvis også en anden type liv.\nDen her agent har et mere jordnært job:\nDen skal hjælpe mig med at holde styr på viden.\nMere præcist har jeg bygget to ting oven på mit Obsidian-vault:\nEn self-improving graph memory, der scanner mine noter og finder huller i grafen. En daily research scout, der hver dag leder efter ny forskning og relevante AI/tech-nyheder, laver en briefing, opretter kandidatnoter og foreslår blogkladder. Det lyder måske som noget, man siger i en pitch deck med alt for mange gradienter.\nMen ideen er egentlig ret ydmyg:\nJeg vil ikke have en AI, der tænker for mig.\nJeg vil have et arbejdsbord, der gør det lettere at tænke.\nProblemet med noter er ikke at skrive dem Jeg har mange noter.\nDevOps-noter. Job-search-noter. AI-research. Blogideer. Guides. Projekter. Halvfærdige tanker. Gode tanker. Noter der engang var gode tanker, men nu mest er digitalt kompost.\nObsidian er fantastisk til den slags, fordi alt er markdown, links og lokal kontrol.\nMen et vault kan også langsomt blive en kælder.\nIkke en hyggelig vinkælder.\nMere sådan en kælder, hvor der står en kasse med \u0026ldquo;vigtige kabler\u0026rdquo; fra 2011, og man er bange for at smide den ud, fordi der måske ligger et mini-USB-kabel, der en dag redder civilisationen.\nProblemet med en personlig knowledge base er sjældent, at man ikke kan skrive mere.\nProblemet er:\nHvad er stadig relevant? Hvad er forældet? Hvad hænger sammen? Hvad mangler links? Hvilke noter er bare støj? Hvilke nye ting på internettet er faktisk værd at gemme? Det er her grafen bliver interessant.\nGraph memory: når noter ikke kun ligger, men peger Obsidian har allerede et graph view. Det er visuelt tilfredsstillende på samme måde som et kontrolrum i en science fiction-film.\nMan ser noder, forbindelser, klynger og små ensomme prikker ude i mørket, som tydeligvis har brug for enten kærlighed eller arkivering.\nMen en graf er kun nyttig, hvis man bruger den som mere end pynt.\nDerfor lavede jeg en lille scanner, der læser mine markdown-filer og bygger et lokalt graph memory:\ntitel filsti frontmatter tags aliases wikilinks indgående og udgående forbindelser manglende metadata mulige relaterede noter Den skriver resultatet til en JSON-fil og laver en menneskelig review-note i Obsidian.\nDet vigtige er, hvad den ikke gør:\nDen retter ikke automatisk hele mit vault.\nDen sletter ikke noter.\nDen flytter ikke rundt på ting som en begejstret praktikant med administratorrettigheder.\nDen siger bare:\n\u0026ldquo;Her er 25 noter uden gode forbindelser. Her er nogle dubletter. Her er nogle store noter uden hub-link. Måske burde du kigge på dem, kammerat.\u0026rdquo;\nDet er ikke fuld autonomi.\nDet er bedre end fuld autonomi.\nDet er en assistent med situationsfornemmelse.\nSelvforbedrende betyder ikke selvforherligende \u0026ldquo;Self-improving graph\u0026rdquo; kan hurtigt lyde, som om systemet sidder om natten og bliver klogere, mens man selv sover.\nDet gør det ikke.\nOg det er nok meget godt.\nDet jeg mener med selvforbedrende er mere nøgternt:\nSystemet scanner grafen. Det finder svage steder. Det foreslår forbedringer. Jeg eller en AI-session kan lave små ændringer. Næste scanning viser, om grafen blev bedre. Det er en feedback loop.\nIkke magi.\nBare en rimelig voksen måde at bruge AI på.\nDen samme ide kender vi fra software engineering:\nkør tests læs fejlene ret småt kør igen Jeg bruger bare samme princip på min viden.\nHvis en note er vigtig, skal den kunne findes. Hvis en research-konklusion betyder noget, skal den linkes fra et hub. Hvis en gammel note er erstattet, skal den markeres som superseded i stedet for at ligge og hviske forældede råd fra 2023.\nDet sidste burde egentlig stå i Grundloven for knowledge workers.\nDen daglige research scout Den anden del er min daily research scout.\nDen scanner hver dag kilder som:\narXiv OpenAI GitHub Blog Microsoft Research Google Research Google News RSS-søgninger på AI agents, computer science og quantum computing Den leder efter emner, jeg faktisk går op i:\nAI agents coding agents MCP RAG og GraphRAG agent memory software engineering benchmarks DevOps og platform engineering security quantum computing AI governance Den laver tre outputs:\nEn daglig research-briefing i Obsidian. Kandidatnoter for ting, der virker vigtige nok. Blogkladder, hvis noget har en offentlig vinkel. Igen: den udgiver ikke noget.\nHvis en agent automatisk begynder at publicere ens blogindlæg, er man kun cirka to prompts fra at blive thought leader på LinkedIn mod sin vilje.\nOg det ønsker vi ikke.\nEller jo, måske lidt.\nMen ikke sådan.\nHvordan den beslutter, hvad der er vigtigt Det svære er ikke at finde nyheder.\nInternettet er lavet af nyheder. De fleste af dem er enten gentagelser, produktannoncer med slips på eller \u0026ldquo;banebrydende\u0026rdquo; ting, der viser sig at være en dropdown med AI i navnet.\nDet svære er at filtrere.\nMin scout bruger derfor en simpel beslutningsmodel:\nMatcher emnet mine kerneområder? Kommer det fra en nogenlunde troværdig kilde? Er det forskning, tooling eller praksis, der kan ændre hvordan jeg arbejder? Er det relevant for DevOps, platform engineering, AI agents eller bloggens tekniske profil? Er det bare interessant, eller er det faktisk brugbart? Hvis noget kun er let interessant, kommer det i briefingen.\nHvis noget virker vigtigt, opretter den en research-intake note med status: candidate.\nDet er et vigtigt ord: candidate.\nDet betyder:\n\u0026ldquo;Dette kan være vigtigt. Men en voksen skal stadig kigge på det.\u0026rdquo;\nDen første kørsel fandt for eksempel et paper om automated benchmark auditing for AI agents. Det er interessant, fordi benchmarks er blevet en del af den måde vi taler om AI-kapabilitet på, men benchmark-opgaver kan selv være fejlbehæftede.\nDet er en god påmindelse:\nHvis vi måler AI dårligt, bygger vi også AI-systemer på dårlige antagelser.\nDet er præcis den type ting, jeg gerne vil have min scout til at fange.\nBloggen som biprodukt af læring Jeg vil gerne skrive mere.\nMen jeg vil ikke skrive bare for at fodre algoritmen med endnu en tekst om \u0026ldquo;5 måder AI ændrer alt\u0026rdquo;.\nMin blog skal helst komme fra faktisk arbejde:\nnoget jeg har bygget noget jeg har lært noget jeg har observeret noget der ændrer min måde at tænke på software, drift eller AI Derfor er blogdelen af scout\u0026rsquo;en ikke en tekstmaskine.\nDen er en ide-maskine.\nNår den finder noget relevant, opretter den en draft med:\nkilde kort vinkel mulig struktur relation til eksisterende posts reminder om at tilføje min egen vurdering Det er en startblok, ikke et færdigt løb.\nAI må gerne hjælpe med at hente bolden.\nDen skal ikke spille kampen alene og bagefter forklare, at den altid har været passioneret omkring dansk teknologipolitik.\nHvorfor det her faktisk er DevOps Det kan lyde som et personligt produktivitetsprojekt.\nDet er det også.\nMen under overfladen er det meget DevOps-agtigt:\nklare inputkilder konfiguration automatiseret daglig kørsel output som filer review før promotion ingen automatisk publicering små feedback loops tydelige guardrails lokal kontrol Det er ikke nok at sige \u0026ldquo;AI, hold mig opdateret.\u0026rdquo;\nDet er en følelse, ikke et system.\nEt system kræver:\nhvor skal den lede? hvad tæller som relevant? hvad må den ændre? hvad må den ikke ændre? hvordan ser jeg resultatet? hvordan retter jeg kursen? Det er de samme spørgsmål, man bør stille til enhver automation, der får lov at røre noget vigtigt.\nOg ens noter er vigtige.\nIkke fordi hver enkelt note er genial.\nNogle af mine noter er bestemt ikke geniale. Nogle af dem burde måske stå med hjelm.\nMen samlet set er de kontekst.\nOg kontekst er blevet en af de vigtigste ressourcer i AI-arbejde.\nDet ydmyge ved AI Der er en fristelse til at tale om AI som noget meget stort.\nEn ny intelligens. En revolution. En maskine der kan gøre alt, lige efter næste release og med lidt bedre prompting.\nMen min erfaring er mere jordnær:\nAI bliver mest nyttig, når man giver den et lille, klart job.\nIkke:\n\u0026ldquo;Forstå hele mit liv.\u0026rdquo;\nMen:\n\u0026ldquo;Find noter uden links.\u0026rdquo;\nIkke:\n\u0026ldquo;Gør mig til ekspert i AI.\u0026rdquo;\nMen:\n\u0026ldquo;Scan de her kilder hver morgen og vis mig de tre ting, der faktisk kan betyde noget.\u0026rdquo;\nIkke:\n\u0026ldquo;Skriv min blog.\u0026rdquo;\nMen:\n\u0026ldquo;Lav en kladde med kilder og vinkel, så jeg kan skrive bedre og hurtigere.\u0026rdquo;\nDet er måske mindre spektakulært.\nTil gengæld virker det.\nOg i software er \u0026ldquo;det virker\u0026rdquo; stadig en undervurderet feature.\nMin konklusion Jeg tror mere og mere på personlige AI-systemer, der er bygget som små platforme.\nIkke én stor chatbot.\nMen en samling af:\nnoter scripts graph memory daglige scouts review-noter kandidater blogkladder klare regler for hvad der må ske automatisk Det er ikke perfekt.\nDet er ikke en erstatning for at læse, tænke og skrive selv.\nMen det er et ret godt stillads.\nOg måske er det netop sådan AI bliver mest nyttig for almindelige udviklere:\nIkke som en alvidende kollega med lidt for meget selvtillid.\nMen som en tålmodig assistent, der hver morgen møder ind og siger:\n\u0026ldquo;Jeg har ryddet lidt op i grafen, fundet tre papers og lavet en blogkladde. Kaffen må du selv stå for.\u0026rdquo;\nDet kan jeg godt leve med.\nSådan er systemet bygget Det er ikke en tung platform. Det er et sæt små vaner og filer, der gør det lettere at arbejde videre:\nObsidian som lokal knowledge base. Markdown-noter med frontmatter, links og korte svar øverst. Daglige research-scouts, der laver kladder i stedet for færdige artikler. Blogkladder, der skal verificeres og have en menneskelig vinkel, før de publiceres. Git og Hugo som den offentlige udgivelseskanal. Det vigtigste er ikke værktøjet. Det vigtigste er, at research, noter, job search og blog ikke ligger i hver sin mentale skuffe. De kan pege på hinanden.\nLæs også:\nDevOps er ikke en pipeline Jobsøgning er også et system ","permalink":"https://karpov.dk/posts/obsidian-vault-selvforbedrende-graf/","summary":"Et kig ind i mit Obsidian-vault: graph memory, daglig research scout, kandidatnoter og blogkladder. AI som arbejdsbord, ikke som tryllestav.","title":"Mit Obsidian-vault fik en lille forskningsafdeling"},{"content":"\nDer er en særlig type optimisme, der opstår, når nogen siger:\n\u0026ldquo;Vi har DevOps. Vi har en pipeline.\u0026rdquo;\nDet er lidt som at sige, at man har et køkken, fordi man ejer en ske.\nEn pipeline er god. Jeg elsker en pipeline, der bygger, tester og deployer uden at kræve røgelse, tribal knowledge og en bestemt udvikler ved navn Brian.\nMen DevOps er ikke bare YAML med selvtillid.\nDevOps er det arbejde, der gør software leverbar, driftbar og forståelig.\nDen korte version Et godt DevOps-flow svarer på fem spørgsmål:\nKan vi bygge det samme artefakt igen? Kan vi teste ændringen hurtigt nok til at turde merge? Kan vi deploye uden håndholdt ceremonidans? Kan vi se, om systemet har det godt bagefter? Kan vi rulle tilbage, når virkeligheden får en kreativ idé? Hvis svaret er nej, har man ikke ét DevOps-problem.\nMan har fem DevOps-problemer i trenchcoat.\nStart med feedback Den vigtigste egenskab ved en pipeline er ikke, at den er flot.\nDet er, at den giver feedback hurtigt nok til, at nogen stadig kan huske, hvad de lavede.\nBuild. Test. Security scan. Package. Deploy til et miljø, der ligner virkeligheden nok til ikke at være teater.\nHvis feedback først kommer to dage senere, er det ikke feedback. Det er arkæologi.\nDORA peger på de samme grundting igen og igen: små ændringer, automatiserede tests, deployment automation, version control og observability. Ikke fordi det lyder moderne, men fordi det reducerer risikoen ved at ændre software.\nGør deployment kedeligt Det bedste deployment er ikke det heroiske deployment.\nDet bedste deployment er det, hvor ingen behøver skrive \u0026ldquo;lige 5 min, jeg deployer\u0026rdquo; i Slack med den der særlige energi, som får alle til at holde vejret.\nKedelige deployments kræver:\nsamme build-artefakt gennem miljøerne konfiguration uden hemmelige manuelle klik migrations, der er tænkt igennem feature flags eller anden måde at styre risiko på rollback-plan før rollback bliver poesi Release engineering handler i praksis om reproducerbarhed, automatisering og sporbarhed. Det lyder tørt. Det er også pointen. Produktion belønner sjældent drama.\nObservability er ikke pynt Logs, metrics og traces er ikke noget, man drysser på systemet bagefter som persille på en lidt trist suppe.\nDe er en del af designet.\nNår noget fejler, skal teamet kunne svare:\nHvad skete der? Hvilken version kører? Hvilke afhængigheder fejler? Hvor er latency steget? Hvilke brugere eller jobs er ramt? Hvis svaret er \u0026ldquo;vi kigger lige i tre portaler og spørger Anders\u0026rdquo;, er systemet ikke observerbart. Det er bare socialt distribueret logging.\nOpenTelemetrys grundide er netop at samle signaler som traces, metrics og logs, så man kan forstå systemadfærd på tværs. Det er ikke magi. Det er bedre brødkrummer.\nDokumentation er også drift Den mest undervurderede DevOps-disciplin er dokumentation.\nIkke 80 sider i Confluence, som ingen har rørt siden Java 8 var ung og håbefuld.\nMen korte noter:\nsådan deployer vi sådan fejlsøger vi sådan roterer vi secrets sådan læser vi dashboardet sådan ruller vi tilbage sådan ved vi, at alt er normalt En god runbook er ikke litteratur. Den er en brandvejledning for træt software.\nMin praktiske tjekliste Hvis jeg skulle forbedre et DevOps-flow i morgen, ville jeg starte her:\nFind den mest smertefulde manuelle release-opgave. Gør den synlig i pipeline eller dokumentation. Tilføj en hurtig test, der fanger den mest pinlige fejl. Sørg for, at deployment efterlader spor: commit, version, miljø og tidspunkt. Lav et dashboard, der viser brugeroplevet sundhed, ikke kun CPU-fitness. Skriv en rollback-note, mens alt er roligt. Gentag uden at kalde det en transformation. Det sidste punkt er vigtigt.\nHvis hver forbedring kræver en transformation, bliver organisationen til sidst allergisk over for forbedringer.\nKonklusion DevOps handler ikke om at have flest tools.\nDet handler om at gøre ændringer mindre farlige.\nEn god pipeline hjælper. Kubernetes kan hjælpe. Azure DevOps kan hjælpe. Observability kan hjælpe. AI kan snart hjælpe endnu mere.\nMen kun hvis systemet omkring dem er forståeligt.\nFor DevOps er ikke en pipeline.\nDevOps er evnen til at ændre software uden at hele rummet instinktivt begynder at kigge på den samme stakkels person.\nLæs også:\nMit Obsidian-vault fik en lille forskningsafdeling Portfolio: DevOps, Platform Engineering og .NET Kilder Wikipedia: The Treachery of Images DORA: Continuous delivery Google SRE Book: Release Engineering OpenTelemetry: Observability primer ","permalink":"https://karpov.dk/posts/devops-er-ikke-en-pipeline/","summary":"DevOps er ikke bare en pipeline. Det er evnen til at få software sikkert fra ide til drift, opdage problemer hurtigt og rette dem uden panik.","title":"DevOps er ikke en pipeline"},{"content":"Jeg er software engineer med en stærk .NET/backend-baggrund og et nyere fokus på DevOps, platform engineering, CI/CD, infrastruktur, observability og produktionstroubleshooting.\nMin professionelle profil ligger i krydsfeltet mellem softwareudvikling og drift: jeg forstår både applikationskode, pipelines, cloud-infrastruktur, deployments, miljøer og de praktiske problemer, der opstår, når systemer skal fungere i produktion.\nKort overblik 6+ års professionel erfaring med softwareudvikling Kernestack: .NET, C#, Azure DevOps, SQL, REST APIs, Blazor DevOps/platform: CI/CD, Docker, Kubernetes, Helm, KEDA, Bicep, Terraform Drift: deployments, fejlsøgning, monitoring, logs, tracing, OpenTelemetry, OpenSearch Domæner: offentlig IT, lønsystemer, dokumentautomatisering, SAP-integration twoday / Arbejdstilsynet — DevOps og Infrastruktur Område: DevOps, infrastruktur, CI/CD, observability, offentlig IT\nTeknologier: Azure DevOps, Azure, Bicep, PowerShell DSC, IIS, OpenTelemetry, OpenSearch, C#/.NET\nHos twoday arbejdede jeg som DevOps- og infrastrukturkonsulent for Arbejdstilsynet på en større .NET- og Sitecore-baseret platform.\nMit bidrag Byggede og forbedrede CI/CD pipelines og deployment flows Var med til at etablere og konfigurere et nyt testmiljø Understøttede monitoring, fejlsøgning og dokumentation Arbejdede med infrastrukturautomatisering og miljøopsætning Var med til at bygge bro mellem udvikling, drift og platform Hvorfor det er relevant Erfaringen viser, at jeg kan arbejde i enterprise- og offentlig IT, hvor stabilitet, dokumentation, kontrollerede deployments og driftsforståelse er afgørende.\nMyPaperFlow — Cloud DevOps, Kubernetes og SAP-integration Område: DevOps, cloud-infrastruktur, dokumentautomatisering, SAP-integration\nTeknologier: Azure DevOps, Docker, Kubernetes, Helm, KEDA, Azure Service Bus, Azure, Bicep, Terraform, PostgreSQL, .NET\nMyPaperFlow var en cloud-baseret dokument- og fakturaplatform med integration til SAP Business One.\nMit bidrag Byggede og vedligeholdt Azure DevOps CI/CD-pipelines Arbejdede med Docker images, Kubernetes deployments og Helm-konfiguration Forbedrede autoskalering med KEDA baseret på Azure Service Bus queues Arbejdede med infrastructure as code i Bicep og Terraform Fejlsøgte deployments, identities, miljøer og cloud-komponenter Hvorfor det er relevant Projektet viser praktisk DevOps-erfaring med rigtige cloud-systemer. Ikke kun YAML, men arbejdet med at bygge, deploye, skalere og drifte services i rigtige miljøer.\nDCAB — Offentligt .NET-system Område: Backendudvikling, offentlig IT, data, registre\nTeknologier: .NET, C#, ASP.NET, Blazor, MSSQL, Azure DevOps, OpenShift, Elasticsearch\nDCAB var et centralt registersystem inden for den almene boligsektor. Projektet involverede kompleks domænelogik, datakvalitet, integrationer og strukturerede leveranceprocesser.\nMit bidrag Udviklede backend- og Blazor-features Arbejdede med REST APIs, domænelogik og datamodeller Understøttede releaseprocesser og Azure DevOps workflows Arbejdede med test, kvalitet og .NET-opgraderinger Bidrog til datamigrering og systemvedligeholdelse Hvorfor det er relevant Projektet viser erfaring med forretningskritisk software, komplekse domæner og samarbejde i et større udviklingsteam.\nVisma Enterprise — Lønsystemer og legacy-modernisering Område: Lønsystemer, forretningskritisk software, legacy-modernisering\nTeknologier: C#, ASP.NET, DB2, MSSQL, GitHub, TeamCity, Octopus Deploy, COBOL\nHos Visma Enterprise udviklede og vedligeholdt jeg funktionalitet til lønsystemer.\nMit bidrag Udviklede og vedligeholdt lønfunktionalitet i C# Arbejdede med implementering af den nye ferielov Arbejdede med eSkattekort-integration og lønrelateret forretningslogik Analyserede produktionsfejl og omskrev legacy COBOL-logik Understøttede systemer hvor korrekthed direkte påvirkede lønudbetalinger Hvorfor det er relevant Lønsystemer kræver præcision, ansvarlighed og forståelse for forretningskritisk software. Erfaringen viser, at jeg kan arbejde med legacy, komplekse regler og produktionsnær fejlsøgning.\nKarpov Blog — Teknisk formidling og personlig platform Område: Teknisk formidling, portfolio, SEO, statisk website\nTeknologier: Hugo, PaperMod, GitHub Pages, Markdown, GitHub Actions\nDenne hjemmeside er min personlige tekniske blog og portfolio. Jeg bruger den til at skrive om software engineering, DevOps, AI, digitalisering og teknologipolitik.\nMit bidrag Bygger og vedligeholder siden med Hugo og GitHub Pages Arbejder med indholdsstruktur, SEO metadata og deployment workflow Bruger siden som offentlig skriveplatform og professionel portfolio Skriver om tekniske emner på dansk med en praktisk engineering-vinkel Hvorfor det er relevant Klar teknisk formidling er en del af senior engineering-arbejde. Siden viser, at jeg kan forklare teknologi, dokumentere idéer og tænke ud over selve koden.\nVintønden — Lokal SEO, WordPress og AI-assisteret indholdsstruktur Område: Lokal SEO, website-struktur, WordPress, AI-assisteret research\nLink: vintonden.dk\nFor Vintønden på Frederiksberg har jeg arbejdet med en praktisk SEO- og websiteforbedring, hvor lokal søgeintention, informationsarkitektur og konkret WordPress-eksekvering blev samlet i en handlingsplan.\nArbejdet omfattede teknisk og indholdsmæssig SEO-gennemgang, forbedring af metadata, forslag til landingssider for events og selskabslokaler, multilingual content guidance samt genbrugelige AI-assisterede workflows til research, copy og implementeringsnoter.\nHvorfor det er relevant Projektet viser, at jeg kan omsætte teknisk analyse, AI-værktøjer og forretningsforståelse til konkrete forbedringer for en rigtig lokal virksomhed, uden at gøre løsningen unødigt akademisk.\nDet recruiters skal forstå Jeg er stærkest i roller, hvor backendudvikling, DevOps og platformarbejde mødes.\nJeg kan bidrage som:\nDevOps Engineer Platform Engineer Site Reliability Engineer Backend Developer med DevOps/platform-ansvar .NET Engineer tæt på infrastruktur og delivery Min værdi er, at jeg både forstår applikationskode og de systemer, der skal bygge, deploye, monitorere og drifte den.\n","permalink":"https://karpov.dk/projekter/","summary":"Udvalgte projekter og erfaringer inden for DevOps, platform engineering, .NET backend, cloud, CI/CD, observability og AI-assisteret softwareudvikling.","title":"DevOps, Platform Engineering og .NET Portfolio"},{"content":" Jeg hedder Evgeny Karpov og arbejder med softwareudvikling, DevOps og platform engineering i København.\nMin styrke ligger i krydsfeltet mellem backend-udvikling og driftbar software: jeg forstår både applikationskode, pipelines, cloud-infrastruktur, deployments og de praktiske problemer, der opstår, når systemer skal fungere i rigtige miljøer.\nProfessionel profil Jeg har erfaring med:\n.NET, C# og backend-udvikling Azure DevOps, CI/CD og release automation Kubernetes, Docker, Helm og KEDA Cloud-platforme og moderne deployment flows Observability, logs, metrics og tracing Dokumentation, debugging og teknisk formidling AI-assisteret softwareudvikling og automatisering Jeg interesserer mig især for, hvordan teams kan levere software hurtigere og mere stabilt uden at miste kvalitet, sikkerhed eller forståelse for systemet.\nHvad jeg gerne vil arbejde med Jeg søger især roller og opgaver inden for:\nDevOps Engineering Platform Engineering Site Reliability Engineering .NET backend og cloud-native systemer Azure DevOps og CI/CD-modernisering Observability og driftbarhed AI-understøttede engineering workflows Min tilgang Jeg tror på klare systemer, god dokumentation og praktisk automatisering. DevOps handler for mig ikke kun om tools, men om at gøre det lettere for udviklere at bygge, teste, deploye og forstå deres software.\nJeg arbejder bedst, når jeg kan kombinere teknisk fordybelse med konkret forbedring: færre manuelle processer, mere synlig drift, bedre pipelines og mere robuste leverancer.\nKontakt LinkedIn: linkedin.com/in/evgenykarpov91 GitHub: github.com/Nextoz E-mail: evgeny@karpov.dk ","permalink":"https://karpov.dk/om/","summary":"\u003cimg class=\"about-portrait\" src=\"/images/profile.png\" alt=\"Evgeny Karpov\" width=\"230\" height=\"230\"\u003e\n\u003cp\u003eJeg hedder \u003cstrong\u003eEvgeny Karpov\u003c/strong\u003e og arbejder med softwareudvikling, DevOps og platform engineering i København.\u003c/p\u003e\n\u003cp\u003eMin styrke ligger i krydsfeltet mellem backend-udvikling og driftbar software: jeg forstår både applikationskode, pipelines, cloud-infrastruktur, deployments og de praktiske problemer, der opstår, når systemer skal fungere i rigtige miljøer.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"professionel-profil\"\u003eProfessionel profil\u003c/h2\u003e\n\u003cp\u003eJeg har erfaring med:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e.NET, C# og backend-udvikling\u003c/li\u003e\n\u003cli\u003eAzure DevOps, CI/CD og release automation\u003c/li\u003e\n\u003cli\u003eKubernetes, Docker, Helm og KEDA\u003c/li\u003e\n\u003cli\u003eCloud-platforme og moderne deployment flows\u003c/li\u003e\n\u003cli\u003eObservability, logs, metrics og tracing\u003c/li\u003e\n\u003cli\u003eDokumentation, debugging og teknisk formidling\u003c/li\u003e\n\u003cli\u003eAI-assisteret softwareudvikling og automatisering\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eJeg interesserer mig især for, hvordan teams kan levere software hurtigere og mere stabilt uden at miste kvalitet, sikkerhed eller forståelse for systemet.\u003c/p\u003e","title":"Om Evgeny Karpov"}]