[{"content":"I think many people make job search harder than it has to be.\nNot because it is easy. It is not. Job search is a strange mix of research, sales, self-awareness, timing, randomness and tiny forms that all want your CV in a slightly different way.\nBut because it quickly becomes an emotion-driven activity:\nDo I feel like doing it today? Does this role feel right? Is my CV good enough? Why has nobody replied? Should I change my whole profile at 23:41? That is understandable.\nIt is just not a very good operating model.\nSo I started treating my job search more like a small delivery system.\nNot coldly. Not cynically. Just with more structure.\nFirst Problem: Too Many Open Loops A job search creates more open loops than you expect.\nThere are roles to evaluate. CVs to tailor. Applications to send. Recruiters to contact. LinkedIn profiles to update. Interviews to prepare for. Follow-ups that must not be forgotten. Rejections that need to be handled without redesigning your whole personality every time.\nIf all of that lives in your head, it quickly becomes noise.\nAnd noise feels like poor confidence, even when the real problem is missing system design.\nI know that from software work:\nWhen nobody knows what is deployed, what is failing, who owns what, and which change comes next, the system feels chaotic.\nJob search is not that different.\nI Made A Backlog The first useful step was making the roles concrete.\nNot just:\nI am looking for something in DevOps.\nBut:\nWhich roles are strongest? Which are platform/DevOps roles? Which are senior backend roles with platform responsibility? Which are backup volume? What is the status? What is the next action? When should I follow up? It sounds basic.\nThat is the point.\nA good job search does not have to begin with polished personal branding. It can begin with a table.\nI ended up splitting roles into tracks:\nplatform and DevOps senior backend with operations and reliability SRE and observability AI/platform-adjacent roles lower-priority backup roles That made it easier to say no to roles that were only interesting because they existed.\nIt also made the CV work more honest. I did not need to invent a new person for every application. I only needed to highlight the part of my profile that actually fit.\nPositioning Is Not Decoration I have a senior software engineering background and have recently worked closer to DevOps, infrastructure, CI/CD, test environments, monitoring, troubleshooting and documentation.\nThat combination can be explained in many ways.\nBad version:\nI can do a bit of everything.\nBetter version:\nI can build software, but I also think about deployment, operations, observability, documentation and developer experience.\nThat is the difference between a skill list and a direction.\nFor me, the public version became something like:\nSenior software engineer with practical DevOps and platform experience who wants to work on systems teams can actually operate.\nIt is not a perfect slogan. Thankfully.\nBut it is useful because it helps filter:\nRoles with platform responsibility fit. Senior backend roles with reliability fit. Pure frontend product roles without operations fit less well. Pure management roles without hands-on technical work fit less well. Positioning is not decoration. It is a filter.\nEach Role Got A Small Playbook The next step was to stop starting from scratch every time.\nFor the most relevant roles, I made a short note with:\nwhy the role fits which part of the CV should be emphasized which application text can be reused which interview questions are likely which questions I should ask when to follow up That is very close to what I would do for a technical system:\nWhat is the context? What are the dependencies? What is the next safe action? What should we be able to explain afterwards? It does not remove uncertainty.\nBut it makes the uncertainty less foggy.\nInterview Stories Should Be Reusable One of the most important things was building a small story bank.\nNot a novel.\nJust short, usable stories:\none about production troubleshooting and observability one about test environments and deployment workflows one about senior review and security thinking one about AI-assisted documentation and knowledge management one about a mistake and what I learned from it That helps because interviews rarely reward the person who has the most experience stored in their head.\nThey reward the person who can find the right experience quickly and explain it clearly.\nThat is also a DevOps thing:\nIf the runbook has to be written during the incident, it is already late.\nIf the interview story has to be discovered while someone asks \u0026ldquo;can you give an example?\u0026rdquo;, the answer often becomes longer, more nervous and less precise.\nFollow-Up Is Part Of The System I do not particularly enjoy follow-ups.\nThey can quickly feel like knocking on a door when you do not know whether anyone is home, or whether the house exists.\nBut without follow-up, job search becomes strangely passive.\nSo I set a simple rule:\nAfter about five business days without a reply, a short polite follow-up is reasonable, unless the process clearly says otherwise.\nNot a novel.\nNot:\nI am writing for the third time to reaffirm my deep passion for your transformative journey.\nJust:\nI just wanted to briefly follow up on my application. The role fits well with my experience in senior software engineering, DevOps, CI/CD, observability and platform work. I would be happy to have a short conversation if my profile is relevant.\nThat is enough.\nAI Helped, But It Was Not Allowed To Take Over I used AI a lot in the process.\nNot to invent myself.\nTo structure the work.\nAI was useful for:\ncomparing job ads with my profile creating first drafts of CV variants making application text shorter finding gaps in positioning building interview questions turning loose notes into STAR stories keeping track of follow-ups But there is an important boundary.\nAI may help with the shape. It must not remove ownership.\nIf I cannot defend a sentence in an interview, it should not be in my CV.\nIf I do not want to explain a technology during an interview, it should not be highlighted as a core skill.\nIf AI makes the text sound like someone who has been \u0026ldquo;passionate about scalable solutions\u0026rdquo; since kindergarten, the text needs to come back down to earth.\nThat may be the most important rule:\nUse AI to become clearer.\nNot smoother.\nThe Blog Became Part Of The Proof One of the most useful moves was connecting the job search with my blog.\nNot as a grand personal brand project.\nMore as practical documentation:\nHere is how I think about DevOps. Here is how I think about AI in production. Here is how I think about observability, governance and platform work. Here are concrete examples that I can write clearly about technical systems. That gives a different kind of proof than a CV.\nA CV says:\nI have worked with this.\nA good technical blog says:\nThis is how I think when I work with this.\nBoth are useful.\nBut in senior roles, the second one often matters just as much.\nThe Most Useful Result Was Calm The biggest effect of the system was not that everything became perfect.\nIt did not.\nThere was still waiting. Still uncertainty. Still roles that fit better on paper than in reality. Still days where it felt a little like sending small bottles into an ATS system with poor lighting.\nBut the system made the work calmer.\nWhen something stalled, I could ask:\nWhat is the next concrete action? Which role matters most right now? Is this CV work, outreach, interview prep or follow-up? Do I have a good story ready? Should I adjust the strategy, or simply continue? That is much better than:\nWhat is wrong with me?\nSometimes the answer is not deep existential analysis.\nSometimes you just need a tracker.\nMy Small Checklist If I had to give my job-search system to another developer, it would be this:\nMake a prioritized list of roles. Split them into tracks so you do not change identity for every application. Write one clear positioning sentence. Make a small playbook for each strong role. Save each CV version you send. Prepare 4-5 short interview stories. Follow up after a few business days if the process is silent. Use AI for structure, not polish. Use portfolio, blog or projects as proof. Review weekly, not after every individual rejection. Job search will never become completely rational.\nIt is about people, timing, needs, chemistry, budgets and many things you cannot see from the outside.\nBut you can make your own part more operable.\nFor me, that has been the most useful way to think about it:\nJob search is not only a series of applications.\nIt is a small system.\nAnd small systems get better when you give them structure, feedback and a little observability.\nRead Also DevOps Is Not a Pipeline AI Agents Need Memory From Prompt to Prototype: AI Helped Me Kill the Idea Faster Portfolio: DevOps, Platform Engineering and .NET Note This post is based on my own job-search notes, CV iterations, interview preparation and workflow experiments from 2026. I have left out concrete company details, live hiring processes and private contact information.\n","permalink":"https://karpov.dk/en/posts/job-search-is-also-a-system/","summary":"When I started treating job search as a system instead of a pile of individual applications, the work became calmer, sharper and more honest.","title":"Job Search Is Also a System"},{"content":"I recently wrote that AI agents need APIs.\nI still think so.\nBut APIs are only half the problem.\nAn agent that can call an API can do something in the world. It can fetch data, create a pull request, change configuration, write a comment or start a process.\nThat is useful.\nIt is also where the problems begin.\nIf the agent cannot remember why it did something, which sources it used, which checks failed, which decisions a human already made and where the boundary of the task is, you have not gained a colleague.\nYou have gained a very fast intern with amnesia and production access.\nThat sounds like a joke.\nMostly, it is an incident waiting to happen.\nMemory Is Not Chat History Many people still think of AI memory as a longer conversation.\nThat is too narrow.\nFor real AI agents, memory is not only about remembering what the user wrote five minutes ago. It is about working with state over time.\nA useful agent needs to remember:\nthe goal of the task which files, systems and sources it used which assumptions it made which checks were run what failed what it has already tried which decisions a human approved which parts of the work are still uncertain That is not romantic AI.\nIt is ordinary software engineering.\nAnd that is exactly why it matters.\nUnstructured Context Quickly Becomes Noise A large context window can feel like a solution.\nJust give the model more text. More files. More notes. More logs. The whole repository. The whole documentation set. The entire organization’s collective guilty conscience in Markdown.\nThe problem is that more context does not automatically create more understanding.\nSometimes it just gives the agent more opportunities to find the wrong detail and sound confident while doing it.\nThat is why I think agent memory is a system problem, not only a model problem.\nMemory needs structure:\nWhat is a fact? What is a decision? What is a temporary assumption? What is an old note? What is a source? What is a validated change? What still needs review? If everything is just text in one large pile, the agent does not necessarily become smarter. It becomes better fed.\nAnd anyone who has worked with old documentation folders knows that well-fed confusion is still confusion.\nMy Small Version: Obsidian As Agent Memory I have used my own Obsidian vault as a small laboratory for this.\nNot as a grand product. More as a practical experiment:\nCan notes, research, tasks, skills and links become useful for AI agents over time?\nThe short answer is yes.\nBut only if the notes are written to be used again.\nA note that is just a text dump helps less. A note with a short conclusion, frontmatter, sources, status, related notes and a clear link to a hub is much more valuable.\nThat sounds small.\nIt is not.\nWhen an agent starts a task, it needs to find the right context without reading my whole digital attic first.\nSo I have started treating notes as small memory objects:\ntype: research, guide, skill, dashboard or reference status: active, draft, archived or superseded memory: semantic knowledge, procedure or episodic log confidence: how reliable the note is source: where the information came from related notes: where it belongs in the graph YAML is not magic.\nThe point is that the agent needs to sort.\nRemembering And Proving An agent should not only remember.\nIt should be able to show why it believes something.\nThis is where software engineering and AI governance meet naturally.\nIf an agent changes code, we should be able to see:\nwhat it changed why it changed it which tests were run which tests were not run which files it touched which requirement it tried to satisfy which risks remain That is very close to ordinary pull request discipline.\nMaybe that is the point.\nThe best agent memory is not a mysterious AI ability. It is a combination of good notes, good logs, clear tasks, tests, review and a little humility.\nIn other words: all the boring things that usually save software projects once the demo is over.\nLonger-Running Agents Need Operations OpenAI, Microsoft and GitHub are all moving toward agents that work longer and closer to real workflows.\nThat may be coding agents in GitHub, agentic development in Warp, enterprise context in Microsoft 365, or background tasks that do not just answer in a chat but actually try to complete work.\nThat changes the risk picture.\nA chatbot that answers incorrectly is annoying.\nAn agent that works incorrectly for hours with access to tools, repositories and internal data is something else.\nSo the old DevOps questions become very modern again:\nWhat may run automatically? What requires review? Where are the logs? How do we detect errors? How do we stop the process? Who owns the change? What happens when the agent meets an unclear instruction? It is not enough for the agent to be intelligent.\nIt also needs to be operable.\nAgent-Ready Means Memory-Ready Many teams will talk about whether their systems are agent-ready.\nThat is a good question.\nBut it should not only be about APIs.\nAn agent-ready system also needs to be memory-ready:\nDocumentation must be current enough to use. Decisions must be visible. System boundaries must be clear. Tests and checks must run without drama. Logs must explain both human and agent-driven actions. Tasks must have clear stop conditions. Important knowledge must be findable again. If that sounds like good platform engineering work, it is because it is.\nAI does not make old discipline problems less important.\nIt makes them more visible.\nConclusion AI agents need APIs.\nBut they also need memory.\nNot just as a long chat log, but as structured working memory with sources, decisions, status, validation and review.\nOtherwise we get agents that can act without being able to explain themselves.\nThat is a bad combination.\nThe next big AI task inside companies will not only be buying more agents.\nIt will be building environments where agents can work without making the systems more unclear.\nIt is about context.\nIt is about operations.\nIt is about memory.\nAnd yes, unfortunately, it means documentation still matters.\nSorry.\nRead also:\nDevOps Is Not a Pipeline My Obsidian Vault Got a Small Research Department Sources 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/en/posts/ai-agents-need-memory/","summary":"APIs give AI agents access to systems. Memory determines whether they can work responsibly over time without repeating mistakes, losing context or inventing a beautiful explanation afterwards.","title":"AI Agents Need Memory"},{"content":"\nI originally just wanted to find a good app idea.\nThat sounds harmless.\nIt is not.\nA \u0026ldquo;good app idea\u0026rdquo; is a bit like \u0026ldquo;a simple integration\u0026rdquo;, \u0026ldquo;a quick MVP\u0026rdquo; or \u0026ldquo;we just need to sort out deployment\u0026rdquo;. It starts as a small thought and often ends with three dashboards, an auth solution, a pricing model, a pitch deck and a feeling that you should probably open YouTube to get your brain back.\nI wanted to avoid that trap.\nSo I used AI as a sparring partner.\nNot just to spit out 20 ideas.\nEvery model can do that now. It is not impressive anymore. It is just a very polite brainstorm with turbo.\nThe interesting question was different:\nCould I use AI to sort, criticize, cut away and arrive at an idea that could actually be tested?\nThe result was a prototype for Vært: a discreet Danish concierge for private dinners, hosting, culture, summer-house life and trusted services.\nNot \u0026ldquo;ChatGPT for rich people\u0026rdquo;.\nThankfully.\nThe Problem Was Not A Lack Of Ideas When you ask AI for app ideas, you quickly get a buffet.\nAnd as with most buffets, the problem is not that there is too little food. The problem is that you end up with a little of everything and afterwards you are not quite sure why you took the pasta salad.\nAI suggested all sorts of things:\nlocal AI assistant personal productivity coach app for young professionals social planning app summer-house app dining club private network digital concierge something with events something with premium access something with AI, because apparently everything needs AI in the name now Some of it was good.\nMuch of it lived on the middle shelf of product development: not bad enough to discard immediately, but not sharp enough to build on either.\nThat is a dangerous zone.\nBad ideas die quickly. Mediocre ideas can live for a long time, especially if they have a nice name and a landing page.\nThe first lesson was simple:\nAI is not most valuable as an idea machine. AI is most valuable as a filter.\nThe important question was not:\nCan we invent more ideas?\nOf course we could. A model can do that faster than a consultant can open a Miro template.\nThe important question was:\nWhich idea has a clear audience, a real problem, willingness to pay and a first version that can be tested without building an entire IT empire?\nThat is where the process became interesting.\nThe Broad AI App Died First Many AI products start with the same sentence:\nPeople need a personal assistant.\nThat is not wrong.\nIt is just too broad.\nIf everyone is the target group, nobody is the target group.\nSo I started pressing the ideas:\nWho has a problem that actually costs money? Who pays for quality and time, not just features? Where can Denmark be an advantage instead of a limitation? What can start manually? What becomes better with network, trust and local context? What should not be another chatbot subscription? The last question matters.\nWe already have enough products where the concept is basically:\nChatGPT, but with our logo.\nThat can be an interface.\nIt is rarely a strong business by itself.\nSlowly, one idea stood out:\nA private Danish concierge.\nNot a luxury app with gold UI, VIP language and desperate premium energy. More a calm service for people who can pay for time, discretion, taste and coordination.\nThe working title became:\nVært\nShort. Danish. Calm.\nNot Silicon Valley. Not Dubai. More Copenhagen, North Zealand and a summer house with the flowers somewhat under control.\nThe Better The Idea Got, The Less It Was About AI The most interesting part of the process was that the idea became less and less \u0026ldquo;AI\u0026rdquo; as it became better.\nAt first, the easy pitch would have been:\nAn AI concierge for wealthy Danes.\nThat sounds like something from a pitch deck with gradients, stock photos and the word \u0026ldquo;seamless\u0026rdquo; too many times.\nBut the more I worked with it, the clearer it became:\nThe product is not AI.\nThe product is trust.\nThe product is access.\nThe product is saving time.\nThe product is being able to write:\nWe have six guests on Friday. It should be good, but not stiff. Find a solution.\nAnd then receive an answer that actually fits.\nNot a generic restaurant list.\nNot a hallucinated wine menu.\nNot a chatbot saying \u0026ldquo;that sounds like a wonderful evening!\u0026rdquo; before suggesting something that feels like Tripadvisor with confidence.\nA real solution.\nThat also changed the role of AI.\nAI does not need to be the front page.\nAI can be the engine room.\nIt can help with:\nstructuring requests summarizing preferences writing concierge briefs suggesting vendors drafting polite replies remembering what a member dislikes creating event checklists helping with research and partner outreach But the experience itself should feel human, local and discreet.\nThat is a product lesson I think many teams will learn:\nThe more premium the experience, the less the AI should shout \u0026ldquo;look at me\u0026rdquo;.\nIteration Is The Real AI Work There is a strange misunderstanding about AI: that the value is in the first answer.\nIt almost never is.\nThe first answer is raw material.\nThe good work comes in the loop afterwards.\nI could keep challenging the model:\n\u0026ldquo;This is too generic.\u0026rdquo; \u0026ldquo;Find a narrower niche.\u0026rdquo; \u0026ldquo;Who actually pays for this?\u0026rdquo; \u0026ldquo;What is the first wedge?\u0026rdquo; \u0026ldquo;Why would it work in Denmark?\u0026rdquo; \u0026ldquo;What should we not build?\u0026rdquo; \u0026ldquo;Make it more exclusive, but not cringe.\u0026rdquo; \u0026ldquo;It should feel Danish, not American.\u0026rdquo; \u0026ldquo;Make a prototype without a backend.\u0026rdquo; \u0026ldquo;Cut anything that smells like a LinkedIn case.\u0026rdquo; That is where AI becomes practical.\nNot because it has perfect judgment. It does not.\nBut because it helps keep momentum in a thought process.\nMany ideas normally die in the gray space between:\nThat could be fun.\nand\nWhat is version zero?\nAI helps bridge that space.\nBut only if you stay critical.\nOtherwise you just get a very well-written bad idea.\nPrototype Before Platform As a developer, you quickly want to build.\nIt is almost a reflex.\nYou see an idea and think:\nlogin database admin panel request system partner portal payments notifications maybe a little Kubernetes, because character flaws exist But for Vært, that did not make sense yet.\nThe right first version was not a finished SaaS platform.\nThe right first version was a prototype that could explain the feeling:\nWhat is Vært? Who is it for? How do you send a request? What types of requests does it handle? What does the member experience feel like? Would anyone pay for this? So the first prototype became static.\nNo backend. No database. No login. No paid AI API.\nJust a showcase with:\nprivate member dashboard concierge request flow curated access partner and service network member preferences founding membership It is not that backend will never matter.\nIt is that backend should be built when you know what it needs to support.\nOtherwise you are building a very polished system for an assumption.\nThe Manual MVP Is Not Cheating For developers, one of the hardest things is accepting that the best MVP might not be software.\nIt hurts a little.\nYou want a repo. A pipeline. An environment. A README. Maybe a small badge showing that something is green.\nBut Vært should be tested manually first.\nVersion zero can be:\na landing page an invite-only form an email address a simple request process a spreadsheet with members and preferences a handpicked partner list manual coordination That sounds primitive.\nIt is not.\nIt is product discipline.\nIf nobody will send requests manually, building an app will not help.\nIf nobody will pay for access, optimizing onboarding will not help.\nIf the requests turn out to be about something entirely different than expected, it is better to learn that in a spreadsheet than after three weeks of frontend work and a discussion about which toast library is most elegant.\nWhat AI Actually Helped With AI did not \u0026ldquo;invent\u0026rdquo; Vært from nothing.\nThat would be too neat a story.\nAI helped make the process faster and more brutal.\nIt helped me:\nExpand the field of possibilities. Compare ideas against each other. Find weaknesses in the most charming ideas. Sharpen the audience. Turn a vague need into concrete use cases. Formulate a prototype. Hold on to MVP discipline. Say no to features that were mostly developer dopamine. The last one is underrated.\nAI can very easily give you more things to build.\nThe important use is getting it to help you build less.\nThe Next Test Is Reality Vært is still only a prototype.\nThat is important.\nA prototype is not a company.\nA landing page is not traction.\nA good idea is not proof.\nAnd an AI-generated analysis is not willingness to pay.\nThe next test is much more practical:\nCan I talk to 10 relevant people? Will anyone say \u0026ldquo;I would actually use this\u0026rdquo;? Can I get founding members or strong verbal yeses? Can I log real concierge requests? Can I find reliable partners? Can the idea survive contact with reality? That is where the project either becomes interesting or becomes another nice note in Obsidian.\nAnd that is fair.\nObsidian can handle more notes.\nThe market is less sentimental.\nConclusion AI is not a magical founder.\nAI does not automatically make an idea good.\nAI can absolutely help you build a bad idea faster, prettier and with more persuasive language.\nBut used well, AI can be a strong product partner.\nNot because it knows everything.\nBut because it makes it easier to think in loops:\nidea -\u0026gt; critique -\u0026gt; research -\u0026gt; structure -\u0026gt; prototype -\u0026gt; test\nFor me, the process did not end with another chatbot.\nIt ended with a sharper thought:\nWealthy Danes do not need more software. They need better access, less friction and someone who can make things happen tastefully.\nThat may become an app.\nIt may become a service.\nIt may first be only an email address and a good list of people you can trust.\nBut it is a better start than a generic AI assistant with a subscription.\nSometimes that is the point of AI:\nNot getting it to build more.\nGetting it to help you cut away until the idea becomes clear enough to test.\nRead also:\nMy Obsidian Vault Got a Small Research Department DevOps Is Not a Pipeline ","permalink":"https://karpov.dk/en/posts/from-prompt-to-prototype-vaert/","summary":"I used AI as a product partner to test, reject and sharpen app ideas. The result was not another chatbot, but a prototype for Vært: a discreet Danish concierge for hosting, dining, culture and trusted services.","title":"From Prompt to Prototype: AI Helped Me Kill the Bad Ideas"},{"content":"I went to AI4Diversity at Danske Bank.\nThere was a lot of sensible talk about AI, inclusion, skills and responsibility. Events like that can sometimes become a long panel version of a LinkedIn post, but this one actually had something to take home.\nOne sentence stayed with me:\nAI is an equalizer.\nI both agree and disagree.\nThat is usually a good sign. The best sentences are often the ones you cannot simply nod at and move on from.\nI Was Vibe Coding During the Talks I was listening to people from Danske Bank talk about AI, governance and broader perspectives, while also doing a little vibe coding on my own machine.\nThat feels very 2026:\nYou sit at an event about responsible AI in a bank and continue building your own small AI workflows on the side.\nIt did not feel like a contradiction. It felt like the point.\nAI has already become part of work. Not only as a chatbot you ask about commas, but as an extra hand for research, notes, code, structure and small decisions along the way.\nWhen it works, it is an equalizer.\nOne person with a laptop can suddenly work like a small team. A non-native speaker can write more clearly. A developer can get feedback on code, notes and architecture without waiting for mercy from the calendar.\nThat is powerful.\nThen comes the bank.\nBanks Are Not a Neutral Place To Test Optimism In a bank, AI is not just a productivity tool.\nIt can affect credit, fraud control, customer service, risk assessment, compliance, identity, advice and access to ordinary financial services.\nSo \u0026ldquo;AI as an equalizer\u0026rdquo; quickly becomes more complicated.\nIf a model helps more people understand money, apply for loans or get faster help, that is positive.\nIf a model learns old patterns from biased data and wraps them in a modern interface, you have not created equality. You have automated discrimination with better UX.\nThat is why Danske Bank is actually an interesting place to have the conversation.\nThe Obvious, Slightly Too Easy Joke Danske Bank has its history with money laundering.\nThat sentence almost writes itself, which is why you should be careful with it. But it is also relevant.\nIf anyone knows that pattern recognition in banking is not only an academic exercise, Danske Bank probably does.\nAI can help with anti-money-laundering work. Not as a magical \u0026ldquo;find all the bad people\u0026rdquo; button, but as a tool for seeing patterns, prioritizing cases, detecting anomalies and helping humans spend their time better.\nIn other words, AI might help the bank with money laundering.\nHopefully meaning against it.\nThat is a small linguistic detail. In banking, small details apparently matter.\nThe Boring Part Is The Important Part The interesting angle from Danske Bank was not that AI can be clever.\nEveryone knows that by now.\nThe interesting idea was that better AI requires broader perspectives. That sounds polite, but it is also technically true.\nIf an AI system is used in a large organization, there needs to be control over:\nwhich data it learns from who it works badly for how errors are discovered who may use it what gets logged how decisions are explained how humans can take over how people complain, correct and roll back That is not only diversity. It is system quality.\nIt is not only law either. It is product development, DevOps, UX, data governance and responsible operations.\nConclusion AI can be an equalizer.\nBut only if people actually get access to it, learn to use it and can challenge the decisions it affects.\nOtherwise it becomes another filter between people and opportunities.\nAt best, AI makes capable people stronger and opens the door for more people.\nAt worst, it becomes a very efficient way to repeat old mistakes.\nJust faster, cleaner and with a better demo.\nRead also:\nDevOps Is Not a Pipeline Job Search Is Also a System Sources AI4Diversity: Diversity Charter Denmark\u0026rsquo;s Signing Event 2026 Diversity Charter Denmark on LinkedIn 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/en/posts/ai-is-an-equalizer-until-it-reaches-the-bank/","summary":"AI can be an equalizer. But in banking it quickly becomes a risk machine too, if data, governance, explanations and control do not follow.","title":"AI Is an Equalizer, Until It Reaches the Bank"},{"content":"\nI have done something that sounds slightly dangerous on paper:\nI gave my Obsidian vault a small AI agent.\nNot an agent with access to buy stocks, delete production or send emails to former managers at 02:13. That would be a different blog post. Possibly a different life.\nThis agent has a more practical job:\nIt helps me keep track of knowledge.\nMore precisely, I built two things on top of my Obsidian vault:\nA self-improving graph memory that scans my notes and finds holes in the graph. A daily research scout that looks for new research and relevant AI/tech news, creates a briefing, creates candidate notes and suggests blog drafts. That may sound like something from a pitch deck with too many gradients.\nThe idea is more humble:\nI do not want AI to think for me.\nI want a workbench that makes it easier to think.\nThe Problem With Notes Is Not Writing Them I have many notes.\nDevOps notes. Job-search notes. AI research. Blog ideas. Guides. Projects. Half-finished thoughts. Good thoughts. Notes that were once good thoughts and are now mostly digital compost.\nObsidian is excellent for that because everything is Markdown, links and local control.\nBut a vault can slowly become a basement.\nNot a cozy wine cellar.\nMore the kind of basement with a box labeled \u0026ldquo;important cables\u0026rdquo; from 2011 that you are afraid to throw out because it might contain the mini-USB cable that one day saves civilization.\nThe problem with a personal knowledge base is rarely that you cannot write more.\nThe problem is:\nWhat is still relevant? What is outdated? What connects? What lacks links? Which notes are just noise? Which new things on the internet are actually worth keeping? That is where the graph becomes interesting.\nGraph Memory: Notes That Point Obsidian already has a graph view. It is visually satisfying in the way a science-fiction control room is satisfying.\nYou see nodes, connections, clusters and lonely dots in the dark that clearly need either love or archiving.\nBut a graph is only useful if it is more than decoration.\nSo I made a small scanner that reads my Markdown files and builds local graph memory:\ntitle file path frontmatter tags aliases wikilinks incoming and outgoing connections missing metadata possible related notes It writes the result to JSON and creates a human review note in Obsidian.\nThe important part is what it does not do:\nIt does not automatically rewrite the whole vault.\nIt does not delete notes.\nIt does not move things around with administrator rights and enthusiasm.\nIt just says:\nHere are 25 notes without good connections. Here are possible duplicates. Here are large notes without a hub link. Maybe have a look at them.\nThat is not full autonomy.\nIt is better than full autonomy.\nIt is an assistant with situational awareness.\nSelf-Improving Does Not Mean Self-Glorifying \u0026ldquo;Self-improving graph\u0026rdquo; can sound as if the system gets smarter at night while I sleep.\nIt does not.\nAnd that is probably good.\nWhat I mean is more sober:\nThe system scans the graph. It finds weak spots. It suggests improvements. I or an AI session make small changes. The next scan shows whether the graph improved. It is a feedback loop.\nNot magic.\nJust a fairly grown-up way to use AI.\nWe know the same idea from software engineering:\nrun tests read the failures make a small fix run again I use the same principle on my knowledge.\nIf a note matters, it should be findable. If a research conclusion matters, it should be linked from a hub. If an old note has been replaced, it should be marked as superseded instead of whispering outdated advice from 2023.\nThe Daily Research Scout The second part is my daily research scout.\nIt scans sources such as:\narXiv OpenAI GitHub Blog Microsoft Research Google Research Google News RSS searches around AI agents, computer science and quantum computing It looks for topics I actually care about:\nAI agents coding agents MCP RAG and GraphRAG agent memory software engineering benchmarks DevOps and platform engineering security quantum computing AI governance It creates three outputs:\nA daily research briefing in Obsidian. Candidate notes for things that look important. Blog drafts if something has a public angle. Again: it does not publish anything.\nIf an agent starts publishing your blog posts automatically, you are only a few prompts away from becoming a thought leader against your will.\nAnd we do not want that.\nOr maybe a little.\nBut not like that.\nHow It Decides What Matters The hard part is not finding news.\nThe internet is made of news. Most of it is repetition, product announcements wearing a tie, or \u0026ldquo;breakthroughs\u0026rdquo; that turn out to be a dropdown with AI in the name.\nThe hard part is filtering.\nMy scout uses a simple decision model:\nDoes the topic match my core areas? Does it come from a reasonably credible source? Is it research, tooling or practice that can change how I work? Is it relevant to DevOps, platform engineering, AI agents or the blog’s technical profile? Is it merely interesting, or is it actually useful? If something is lightly interesting, it goes into the briefing.\nIf it looks important, it creates a research intake note with status: candidate.\nThat word matters: candidate.\nIt means:\nThis may be important. An adult still needs to look at it.\nThe Blog As A Byproduct Of Learning I want to write more.\nBut I do not want to write just to feed the algorithm another text about \u0026ldquo;5 ways AI changes everything\u0026rdquo;.\nMy blog should come from actual work:\nsomething I built something I learned something I observed something that changed how I think about software, operations or AI So the blog part of the scout is not a text machine.\nIt is an idea machine.\nWhen it finds something relevant, it creates a draft with:\nsource short angle possible structure relation to existing posts reminder to add my own judgment It is a starting block, not the full race.\nAI can help retrieve the ball.\nIt should not play the whole match and later explain that it has always been passionate about Danish technology policy.\nWhy This Is Actually DevOps This may sound like a personal productivity project.\nIt is.\nBut underneath, it is also very DevOps-like:\nclear input sources configuration automated daily run output as files review before promotion no automatic publishing small feedback loops clear guardrails local control It is not enough to say: \u0026ldquo;AI, keep me updated.\u0026rdquo;\nThat is a feeling, not a system.\nA system requires answers:\nwhere should it look? what counts as relevant? what may it change? what must it not change? how do I see the result? how do I correct course? Those are the same questions we should ask about any automation allowed to touch something important.\nAnd notes are important.\nNot because every note is brilliant.\nSome of mine definitely are not.\nBut together they are context.\nAnd context has become one of the most important resources in AI work.\nThe Humble Use Of AI There is a temptation to talk about AI as something enormous.\nA new intelligence. A revolution. A machine that can do everything, right after the next release and with slightly better prompting.\nMy experience is more practical:\nAI becomes most useful when you give it a small, clear job.\nNot:\nUnderstand my whole life.\nBut:\nFind notes without links.\nNot:\nMake me an AI expert.\nBut:\nScan these sources every morning and show me the three things that might matter.\nNot:\nWrite my blog.\nBut:\nMake a draft with sources and an angle so I can write better and faster.\nThat is less spectacular.\nIt works.\nAnd in software, \u0026ldquo;it works\u0026rdquo; is still an underrated feature.\nConclusion I increasingly believe in personal AI systems built as small platforms.\nNot one giant chatbot.\nBut a collection of:\nnotes scripts graph memory daily scouts review notes candidates blog drafts clear rules for what may happen automatically It is not perfect.\nIt is not a replacement for reading, thinking and writing myself.\nBut it is a good scaffold.\nMaybe that is how AI becomes most useful for ordinary developers:\nNot as an all-knowing colleague with too much confidence.\nBut as a patient assistant that shows up every morning and says:\nI cleaned up the graph a little, found three papers and made a blog draft. You still have to make the coffee.\nI can live with that.\nHow The System Is Built It is not a heavy platform. It is a set of small habits and files that make it easier to continue:\nObsidian as a local knowledge base. Markdown notes with frontmatter, links and short answers at the top. Daily research scouts that create drafts instead of finished articles. Blog drafts that must be verified and given a human angle before publishing. Git and Hugo as the public publishing channel. The most important thing is not the tool. The most important thing is that research, notes, job search and blog do not live in separate mental drawers. They can point to each other.\nRead also:\nDevOps Is Not a Pipeline Job Search Is Also a System ","permalink":"https://karpov.dk/en/posts/my-obsidian-vault-got-a-small-research-department/","summary":"A look inside my Obsidian vault: graph memory, daily research scout, candidate notes and blog drafts. AI as a workbench, not a magic wand.","title":"My Obsidian Vault Got a Small Research Department"},{"content":"\nThere is a special kind of optimism that appears when someone says:\n\u0026ldquo;We have DevOps. We have a pipeline.\u0026rdquo;\nThat is a little like saying you have a kitchen because you own a spoon.\nA pipeline is good. I love a pipeline that builds, tests and deploys without requiring incense, tribal knowledge and one specific developer named Brian.\nBut DevOps is not just YAML with confidence.\nDevOps is the work that makes software deliverable, operable and understandable.\nThe Short Version A good DevOps flow answers five questions:\nCan we build the same artifact again? Can we test the change fast enough to dare merging it? Can we deploy without manual ceremony? Can we see whether the system is healthy afterwards? Can we roll back when reality gets creative? If the answer is no, you do not have one DevOps problem.\nYou have five DevOps problems in a trench coat.\nStart With Feedback The most important property of a pipeline is not that it looks nice.\nIt is that it gives feedback quickly enough for someone to still remember what they were doing.\nBuild. Test. Security scan. Package. Deploy to an environment that resembles reality enough not to be theater.\nIf feedback arrives two days later, it is not feedback. It is archaeology.\nDORA points to the same basics again and again: small changes, automated tests, deployment automation, version control and observability. Not because they sound modern, but because they reduce the risk of changing software.\nMake Deployment Boring The best deployment is not the heroic deployment.\nThe best deployment is the one where nobody has to write \u0026ldquo;just five minutes, I am deploying\u0026rdquo; in Slack with the kind of energy that makes everyone hold their breath.\nBoring deployments require:\nthe same build artifact through environments configuration without secret manual clicks migrations that have been thought through feature flags or another way to control risk a rollback plan before rollback becomes poetry Release engineering is about reproducibility, automation and traceability. It sounds dry. That is the point. Production rarely rewards drama.\nObservability Is Not Decoration Logs, metrics and traces are not something you sprinkle onto the system afterwards.\nThey are part of the design.\nWhen something fails, the team should be able to answer:\nWhat happened? Which version is running? Which dependencies are failing? Where did latency increase? Which users or jobs are affected? If the answer is \u0026ldquo;we will check three portals and ask Anders\u0026rdquo;, the system is not observable. It is just socially distributed logging.\nOpenTelemetry’s basic idea is to collect signals such as traces, metrics and logs so we can understand system behavior across boundaries. It is not magic. It is better breadcrumbs.\nDocumentation Is Operations Too The most underrated DevOps discipline is documentation.\nNot 80 pages in Confluence that nobody has touched since Java 8 was young and hopeful.\nShort notes:\nhow we deploy how we troubleshoot how we rotate secrets how we read the dashboard how we roll back how we know everything is normal A good runbook is not literature. It is a fire instruction for tired software.\nMy Practical Checklist If I had to improve a DevOps flow tomorrow, I would start here:\nFind the most painful manual release task. Make it visible in the pipeline or documentation. Add a quick test that catches the most embarrassing failure. Make deployments leave a trace: commit, version, environment and time. Create a dashboard that shows user-perceived health, not only CPU fitness. Write a rollback note while everything is calm. Repeat without calling it a transformation. The last point matters.\nIf every improvement requires a transformation, the organization eventually becomes allergic to improvement.\nConclusion DevOps is not about having the most tools.\nIt is about making change less dangerous.\nA good pipeline helps. Kubernetes can help. Azure DevOps can help. Observability can help. AI will probably help even more.\nBut only if the system around the tools is understandable.\nDevOps is not a pipeline.\nDevOps is the ability to change software without everyone in the room instinctively looking at the same poor person.\nRead also:\nMy Obsidian Vault Got a Small Research Department Portfolio: DevOps, Platform Engineering and .NET Sources Wikipedia: The Treachery of Images DORA: Continuous delivery Google SRE Book: Release Engineering OpenTelemetry: Observability primer ","permalink":"https://karpov.dk/en/posts/devops-is-not-a-pipeline/","summary":"DevOps is not just a pipeline. It is the ability to move software safely from idea to operations, detect problems quickly and fix them without panic.","title":"DevOps Is Not a Pipeline"},{"content":"The English About page is available here:\nGo to About\n","permalink":"https://karpov.dk/en/om/","summary":"This page has moved to /en/about/.","title":"About"},{"content":" I am a software engineer based in Copenhagen, working across .NET backend development, DevOps, CI/CD, infrastructure and platform engineering.\nMy background is in software development, but over time I have moved closer to the full delivery chain: how systems are built, deployed, configured, monitored and kept stable in real environments.\nI like work where I can combine structured engineering with practical troubleshooting. I am especially interested in Azure DevOps, Kubernetes, infrastructure as code, observability and systems that are complex enough to require real technical ownership.\nWhat I work with .NET and C# Backend development and REST APIs Azure DevOps and CI/CD pipelines Docker, Kubernetes and Helm Infrastructure as code with Bicep and Terraform SQL databases and data-heavy systems Observability, logging and production troubleshooting Public-sector and business-critical systems How I work I try to be pragmatic, reliable and clear. I care about understanding the system before changing it, documenting what matters, and making delivery smoother for the whole team.\nI also write about technology, AI, DevOps and digitalization on this blog. Partly to share ideas, partly to force myself to think more clearly.\nOutside work Outside software, I am interested in reading, swimming, salsa, photography, drones, and trying to understand why every small technical fix somehow becomes an infrastructure project.\nContact LinkedIn: linkedin.com/in/evgenykarpov91 GitHub: github.com/Nextoz Email: evgeny@karpov.dk ","permalink":"https://karpov.dk/en/about/","summary":"Software engineer based in Copenhagen with experience across .NET, DevOps, Azure DevOps, infrastructure and platform engineering.","title":"About"},{"content":"I am a software engineer with a strong .NET/backend background and a growing focus on DevOps, platform engineering, CI/CD, infrastructure, observability and production troubleshooting.\nMy professional profile sits between software development and operations: I understand application code, pipelines, cloud infrastructure, deployments, environments and the practical problems that appear when systems need to work reliably in production.\nShort overview 6+ years of professional software development experience Core stack: .NET, C#, Azure DevOps, SQL, REST APIs, Blazor DevOps/platform: CI/CD, Docker, Kubernetes, Helm, KEDA, Bicep, Terraform Operations: deployments, troubleshooting, monitoring, logs, tracing, OpenTelemetry, OpenSearch Domains: public-sector IT, payroll systems, document automation, SAP integration Selected experience and projects twoday / Arbejdstilsynet — DevOps and Infrastructure Area: DevOps, infrastructure, CI/CD, observability, public-sector IT\nTechnologies: Azure DevOps, Azure, Bicep, PowerShell DSC, IIS, OpenTelemetry, OpenSearch, C#/.NET\nAt twoday, I worked as a DevOps and infrastructure consultant for Arbejdstilsynet on a large .NET and Sitecore-based platform.\nMy contribution Built and improved CI/CD pipelines and deployment flows Helped establish and configure a new test environment Supported monitoring, troubleshooting and documentation Worked with infrastructure automation and environment setup Helped bridge development, operations and platform concerns Why it matters This experience shows my ability to work in an enterprise/public-sector environment where stability, documentation, controlled deployments and operational understanding matter.\nMyPaperFlow — Cloud DevOps, Kubernetes and SAP integration Area: DevOps, cloud infrastructure, document automation, SAP integration\nTechnologies: Azure DevOps, Docker, Kubernetes, Helm, KEDA, Azure Service Bus, Azure, Bicep, Terraform, PostgreSQL, .NET\nMyPaperFlow was a cloud-based document and invoice platform with integration to SAP Business One.\nMy contribution Built and maintained Azure DevOps CI/CD pipelines Worked with Docker images, Kubernetes deployments and Helm configuration Improved autoscaling with KEDA based on Azure Service Bus queues Worked with infrastructure as code using Bicep and Terraform Troubleshot deployments, identities, environments and cloud components Why it matters This project demonstrates practical DevOps work beyond writing YAML: building, deploying, scaling and operating real cloud services.\nDCAB — Public-sector .NET system Area: Backend development, public-sector systems, data, registers\nTechnologies: .NET, C#, ASP.NET, Blazor, MSSQL, Azure DevOps, OpenShift, Elasticsearch\nDCAB was a central register system within the Danish public housing sector. The project involved complex domain logic, data quality, integrations and structured delivery processes.\nMy contribution Developed backend and Blazor features Worked with REST APIs, domain logic and data models Supported release processes and Azure DevOps workflows Worked with testing, quality and .NET upgrades Contributed to data migration and system maintenance work Why it matters This project shows experience with serious business-critical software, domain complexity and collaboration in a larger development team.\nVisma Enterprise — Payroll systems and legacy modernization Area: Payroll systems, business-critical software, legacy modernization\nTechnologies: C#, ASP.NET, DB2, MSSQL, GitHub, TeamCity, Octopus Deploy, COBOL\nAt Visma Enterprise, I developed and maintained functionality for payroll systems.\nMy contribution Developed and maintained payroll functionality in C# Worked on implementation of the new Danish holiday act Worked with tax-card integration and salary-related business logic Analyzed production issues and rewrote legacy COBOL logic Supported systems where correctness directly affected salary payments Why it matters Payroll systems require precision, responsibility and understanding of business-critical software. This experience shows that I can work with legacy systems, complex rules and high-stakes production logic.\nKarpov Blog — Technical writing and personal platform Area: Technical communication, portfolio, SEO, static site\nTechnologies: Hugo, PaperMod, GitHub Pages, Markdown, GitHub Actions\nThis website is my personal technical blog and portfolio. I use it to write about software engineering, DevOps, AI, digitalization and technology policy.\nMy contribution Built and maintain the site with Hugo and GitHub Pages Set up content structure, SEO metadata and deployment workflow Use the site as a public writing platform and professional portfolio Write about technical topics in Danish and English with a practical engineering angle Why it matters Clear technical communication is part of senior engineering work. This site shows that I can explain technology, document ideas and think beyond code.\nVintønden — Local SEO, WordPress and AI-assisted content structure Area: Local SEO, website structure, WordPress, AI-assisted research\nLink: vintonden.dk\nFor Vintønden in Frederiksberg, I worked on a practical SEO and website improvement effort that connected local search intent, information architecture and concrete WordPress execution into an actionable plan.\nThe work covered technical and content SEO review, metadata improvements, landing-page ideas for events and private-room bookings, multilingual content guidance, and reusable AI-assisted workflows for research, copywriting and implementation notes.\nWhy it matters This project shows that I can translate technical analysis, AI tooling and business context into concrete improvements for a real local business without turning the solution into unnecessary theory.\nWhat recruiters should understand I am strongest in roles where backend development, DevOps and platform work meet.\nI can contribute as:\nDevOps Engineer Platform Engineer Site Reliability Engineer Backend Developer with DevOps/platform responsibility .NET Engineer close to infrastructure and delivery My value is that I understand both application code and the systems that build, deploy, monitor and operate it.\n","permalink":"https://karpov.dk/en/projects/","summary":"Selected experience across DevOps, platform engineering, .NET backend, cloud, CI/CD, observability and AI-assisted software development.","title":"DevOps, Platform Engineering and .NET Portfolio"}]