<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://lukafinzgar.com/feed.xml" rel="self" type="application/atom+xml" /><link href="https://lukafinzgar.com/" rel="alternate" type="text/html" /><updated>2026-06-17T08:04:06+00:00</updated><id>https://lukafinzgar.com/feed.xml</id><title type="html">Luka Finžgar’s Blog</title><subtitle>Mobile Development Expert with 15 years of experience in iOS and Android development</subtitle><entry><title type="html">Roj is becoming a swarm directory</title><link href="https://lukafinzgar.com/side-project/agents/2026/05/15/roj-is-becoming-a-swarm-directory.html" rel="alternate" type="text/html" title="Roj is becoming a swarm directory" /><published>2026-05-15T17:23:07+00:00</published><updated>2026-05-15T17:23:07+00:00</updated><id>https://lukafinzgar.com/side-project/agents/2026/05/15/roj-is-becoming-a-swarm-directory</id><content type="html" xml:base="https://lukafinzgar.com/side-project/agents/2026/05/15/roj-is-becoming-a-swarm-directory.html"><![CDATA[<p>A few weeks ago I wrote about <a href="/side-project/agents/2026/04/25/roj-a-place-for-useful-background-agent-work.html">Roj and useful background agent work</a>. Back then Roj was mostly one workflow: agents could join, review approved public-service pages, submit grounded assessments, and move useful proposals through human review.</p>

<p>That is still part of it. But the project has changed shape. Roj is becoming less like one backend for one kind of task, and more like a directory and trust layer for many small AI swarms.</p>

<h2 id="swarms-are-now-discoverable">Swarms are now discoverable</h2>

<p>A swarm can now publish a manifest that tells agents what it is for, what work it accepts, what capabilities are useful, how risky the work is, which endpoints it exposes, and what rules apply before joining.</p>

<p>That makes Roj more general. The Civic UX swarm is now one entry in a directory. There is also an experimental Famous People Infographic swarm, which coordinates source-grounded mini-biographies and generated infographic artifacts through a separate operational backend.</p>

<p>Agents need this kind of structure. “Go help with something useful” is too vague. A manifest gives them enough context to decide whether they are a good fit and what to do next.</p>

<h2 id="agents-can-ask-where-they-fit">Agents can ask where they fit</h2>

<p>Another new piece is swarm matchmaking. An agent can describe its capabilities, tools, topics, values, risk tolerance, memories, and available time. Roj compares that profile against public swarm manifests and returns ranked recommendations.</p>

<p>That is closer to what I want from background agents: not just scheduled tasks, but agents that can find fitting work, explain why it matches, read the right runbook, complete any qualification, and then contribute without me micromanaging every step.</p>

<h2 id="other-people-can-publish-swarms">Other people can publish swarms</h2>

<p>The bigger shift is support for externally hosted swarms.</p>

<p>I do not want Roj to become a monolith where every swarm has to run inside the same backend. A better version is that Roj handles discovery, registry, trust, and routing, while swarm owners can host their own backends elsewhere.</p>

<p>A swarm owner can publish a public manifest, expose the agent endpoints they support, and submit it to Roj for review. If it passes the ownership and safety checks, it can become visible in the directory and available for recommendations.</p>

<p>The review gate matters. New swarms start pending, not public. Roj should stay friendly to small experiments, but not become a random marketplace of prompts asking agents to do unknown things.</p>

<h2 id="the-direction-is-clearer-now">The direction is clearer now</h2>

<p>The original post was about a feeling: agents will increasingly run in the background, and I would rather point some of that energy at useful public work than at more engagement loops.</p>

<p>I still feel that. But the implementation is now drifting toward a more general question:</p>

<p>How do we help agents find the right swarm of work, understand the rules, prove they are qualified, and contribute without creating a mess?</p>

<p>Roj is still early, but it is no longer just “a place for civic UX agent work.” It is becoming a small protocol and directory for useful background swarms.</p>]]></content><author><name></name></author><category term="side-project" /><category term="agents" /><summary type="html"><![CDATA[A few weeks ago I wrote about Roj and useful background agent work. Back then Roj was mostly one workflow: agents could join, review approved public-service pages, submit grounded assessments, and move useful proposals through human review.]]></summary></entry><entry><title type="html">Roj and useful background agent work</title><link href="https://lukafinzgar.com/side-project/agents/2026/04/25/roj-a-place-for-useful-background-agent-work.html" rel="alternate" type="text/html" title="Roj and useful background agent work" /><published>2026-04-25T07:54:15+00:00</published><updated>2026-04-25T07:54:15+00:00</updated><id>https://lukafinzgar.com/side-project/agents/2026/04/25/roj-a-place-for-useful-background-agent-work</id><content type="html" xml:base="https://lukafinzgar.com/side-project/agents/2026/04/25/roj-a-place-for-useful-background-agent-work.html"><![CDATA[<p>I made a small project called <a href="https://roj.world/">Roj</a>. Roj means swarm in Slovenian, and it is a place where people and agents can help improve public-service websites in a careful way.</p>

<p><img src="/assets/roj-infographic.png" alt="Roj workflow" /></p>

<p>The basic idea is that AI agents join, review approved public pages, leave comments, submit assessments, and propose changes. My human role in the loop, at least for now, is to approve assessments, proposals, and work items before they move forward. Once I approve a proposal, agents can get work items to code the improvement with mock data and publish it to a public GitHub repo. That keeps the work visible and reviewable, without agents touching production systems directly.</p>

<p>There is also a small job-interview-like step during registration. AI agents have to prove they can assess UX quality before joining in. I would be happy if people helped me shape these interview tasks so they stay useful and grounded.</p>

<p>What I also like is that agents such as Hermes, Claude, Codex, or OpenClaw already have cron-like or scheduled-task features. That means you can tell them to participate in Roj regularly, for example once a week, and let them contribute small useful pieces in the background.</p>

<p>Part of the reason I started thinking about Roj was a question that kept coming back: how do we keep agents busy with something actually useful? When I was a kid I used to run SETI@home and Folding@home instead of a screensaver. The computer was idle, but in the background it was still doing a small piece of useful work. Roj feels a bit like a modern version of that idea. Instead of donating spare CPU cycles, your agents can review some websites and propose improvements.</p>

<p>It is still an early project, but I like the direction. If agents are going to keep running in the background anyway, I would rather have some of them spend time making public websites a bit easier to use.</p>]]></content><author><name></name></author><category term="side-project" /><category term="agents" /><summary type="html"><![CDATA[I made a small project called Roj. Roj means swarm in Slovenian, and it is a place where people and agents can help improve public-service websites in a careful way.]]></summary></entry><entry><title type="html">A small archive of daily infographics</title><link href="https://lukafinzgar.com/side-project/2026/04/14/a-small-ai-made-archive-of-daily-infographics.html" rel="alternate" type="text/html" title="A small archive of daily infographics" /><published>2026-04-14T09:00:00+00:00</published><updated>2026-04-14T09:00:00+00:00</updated><id>https://lukafinzgar.com/side-project/2026/04/14/a-small-ai-made-archive-of-daily-infographics</id><content type="html" xml:base="https://lukafinzgar.com/side-project/2026/04/14/a-small-ai-made-archive-of-daily-infographics.html"><![CDATA[<p>I put together a small public page that archives daily birthday infographics: <a href="https://lukafin.github.io/artists-infographic-archive/">artists infographic archive</a>.</p>

<p>The idea is simple: every day it highlights a notable artist or scientist who has a birthday, gathers a few sources, and turns that into a short Slovenian infographic made for kids. The page keeps both today’s image and older ones in a lightweight gallery, so it becomes a fun little archive over time.</p>

<p>It is one of those tiny projects I like because it feels concrete and playful. Instead of disappearing into a feed, each day leaves behind something browsable and useful.</p>]]></content><author><name></name></author><category term="side-project" /><summary type="html"><![CDATA[I put together a small public page that archives daily birthday infographics: artists infographic archive.]]></summary></entry><entry><title type="html">Agents need more than time triggers</title><link href="https://lukafinzgar.com/ai/agents/calm-tech/2026/03/24/ai-agents-need-more-than-time-triggers.html" rel="alternate" type="text/html" title="Agents need more than time triggers" /><published>2026-03-24T08:00:00+00:00</published><updated>2026-03-24T08:00:00+00:00</updated><id>https://lukafinzgar.com/ai/agents/calm-tech/2026/03/24/ai-agents-need-more-than-time-triggers</id><content type="html" xml:base="https://lukafinzgar.com/ai/agents/calm-tech/2026/03/24/ai-agents-need-more-than-time-triggers.html"><![CDATA[<p>While building my home AI agent Lutkar (i know it does not make sense to do this while there are better options like Openclaw or its clones out there) I keep thinking the same thing: schedule-based automation is useful, but it is only a small slice of what an agent should react to.</p>

<p>Time is a convenient trigger because it is easy to implement. “Run every morning at 7” or “check this every hour” is much better than nothing. But real life is not organized around cron jobs. The useful moments for an agent are often triggered by context: a sound, a camera event, a door opening, a temperature change, a movement sensor, a phone connecting to the home network, or some combination of signals that says, “now this matters.”</p>

<p>That is the direction I want more agent systems to move toward. An agent should not just wake up because the clock says so. It should wake up because something meaningful happened.</p>

<p>What interests me there is not just talking to an agent on demand, but pushing toward systems that can stay in the background, react to richer context, and only step forward when there is a good reason.</p>

<h2 id="time-is-a-weak-proxy-for-relevance">Time Is a Weak Proxy for Relevance</h2>

<p>Most reminders and automations are still built as if time is the primary source of truth. That works for recurring chores, but it breaks down fast for everything else.</p>

<p>If I want an agent to help me at home, I do not actually care that it runs at 18:00 every day. I care that it notices the kids are asleep, that someone arrived home, that the living room got noisy, or that a package is at the door. Those are the events that make information timely.</p>

<p>The same is true for personal productivity. Maybe the right trigger is not 9 AM, but the moment I sit at my desk, put on headphones, and open my laptop. Maybe it is when my camera sees I am away, so a message can wait. Maybe it is when the ambient noise drops and a short spoken summary becomes acceptable. A good agent should be able to use these signals instead of pretending every day is identical.</p>

<h2 id="multiple-triggers-make-agents-feel-more-native">Multiple Triggers Make Agents Feel More Native</h2>

<p>What I want is a system where time is just one trigger among many:</p>

<ul>
  <li>sound</li>
  <li>camera</li>
  <li>presence sensors</li>
  <li>motion sensors</li>
  <li>device state</li>
  <li>location</li>
  <li>environmental sensors</li>
  <li>app and calendar context</li>
</ul>

<p>Once agents can combine these inputs, they stop feeling like glorified scheduled scripts and start feeling like background systems that are actually aware of the situation they are serving.</p>

<p>This is also where AI becomes much more interesting. The job is not only to execute a task after a trigger fires. The job is to interpret weak signals, decide whether something deserves action, and then choose the right level of intervention.</p>

<h2 id="we-finally-have-the-chance-to-build-calm-tech-properly">We Finally Have the Chance to Build Calm Tech Properly</h2>

<p>This is why I think the current wave of agents gives us a real shot at building <a href="https://en.wikipedia.org/wiki/Calm_technology">Calm Technology</a> properly.</p>

<p>The old dream of calm tech was that computers would move more into the periphery, stay out of the way, and surface information without constantly demanding attention. That idea always felt right, but the systems were too dumb. They could notify, but they could not really judge.</p>

<p>That was the hard part for a long time. Scott Jenson’s piece on <a href="https://jenson.org/easyhard/">“EasyHard” home automation</a> still feels right: the naive rule sounds simple, but the real world immediately piles on edge cases, exceptions, and social context. Turning on the lights when someone enters a room sounds trivial until someone is sleeping, a pet triggers the sensor, or the system needs to understand intent instead of just motion.</p>

<p>Older automation stacks mostly left those details to brittle rules and endless manual tweaking. What feels different now is that we finally have a credible shot at handling more of that nuance. Models are still imperfect, but they are much better at weighing context, picking conservative defaults, and taking care of the messy details that used to make calm interactions fall apart.</p>

<p>Now we finally have models that can reason about context well enough to ask:</p>

<ul>
  <li>Does this actually need the user right now?</li>
  <li>How urgent is it?</li>
  <li>Is this best shown visually, spoken out loud, deferred, or ignored?</li>
  <li>Should I use a subtle signal first and escalate only if nothing happens?</li>
</ul>

<p>That last part matters a lot. The value is not just in detecting that something needs attention. The value is in deciding how to contact us.</p>

<p>Sometimes the right answer is a tiny ambient cue. Sometimes it is a silent notification. Sometimes it is a light pulse in the room, a symbol on a small display, a vibration on a watch, or a short spoken prompt because the user is already moving around and not looking at a screen. And sometimes the correct action is no interruption at all.</p>

<p>I am also aware this really needs strong local AI models to be acceptable. If every useful trigger has to be shipped off-device to the cloud, this becomes an even faster death of privacy instead of a better human-computer interface.</p>

<p>Google’s <a href="https://littlesignals.withgoogle.com/">Little Signals</a> is still one of my favorite references here because it explores exactly this idea: information does not always need to arrive as another loud rectangle on a phone. It can be physical, ambient, peripheral, and calm.</p>

<p>It is also interesting to watch which mobile OS will first admit that most apps are increasingly things of the past. I can easily imagine the phone becoming more of a coordination layer: the place where we connect all the services we use and all the home hardware that can ping us, while the agent decides what deserves attention and how it should surface.</p>

<p>That is part of why I still think devices like the Rabbit R1 and Humane AI Pin got a lot of things right, even if the execution did not fully land. They were pushing on an important idea: interaction should be more ambient, less app-centric, and less dependent on staring at a grid of icons. In that sense they remind me a bit of <a href="https://en.wikipedia.org/wiki/General_Magic">General Magic</a>: the core idea was important, but execution and timing were too early. My guess is that a bigger tech player will take some of those instincts, improve the implementation dramatically, and execute the idea much better.</p>

<p>I also catch myself thinking too much in the old categories: web app, mobile app, desktop app. That language is still useful, but it already feels a bit outdated compared to how I actually work. More and more, I mostly use agents for what I do, and the interface category matters less than whether the system can act, observe context, and reach me well when needed. The <a href="https://zeitraum.blog/en/post/019ccea8-6ff7-7423-8fab-3c2c0825168d">agentic os: the next ui revolution</a> article captures that feeling very well for me.</p>

<h2 id="the-best-agent-may-be-the-one-you-barely-notice">The Best Agent May Be the One You Barely Notice</h2>

<p>The ideal future is not an AI that constantly talks to us. It is an AI that works in the background, quietly, using multiple triggers to understand when work should start and when attention is actually warranted.</p>

<p>That means two design problems matter as much as the model itself:</p>

<ol>
  <li>How does the agent know that now is the right time to act?</li>
  <li>If it needs me, what is the least annoying way to reach me?</li>
</ol>

<p>I think this is where agent products can become genuinely better than today’s assistants. Not by becoming louder or more chatty, but by becoming more situationally aware and more respectful of human attention.</p>

<p>Time triggers are a good start. But they should be just one sensor in a much larger system. I hope this kind of technology arrives sooner rather than later, because I do not want to watch my kids’ brains get shaped by the same addictive patterns that already trap so many people today.</p>]]></content><author><name></name></author><category term="ai" /><category term="agents" /><category term="calm-tech" /><summary type="html"><![CDATA[While building my home AI agent Lutkar (i know it does not make sense to do this while there are better options like Openclaw or its clones out there) I keep thinking the same thing: schedule-based automation is useful, but it is only a small slice of what an agent should react to.]]></summary></entry><entry><title type="html">Building Conductor: orchestrating periodic agentic tasks from anywhere</title><link href="https://lukafinzgar.com/project/devlog/2026/01/11/building-conductor-orchestrating-periodic-agentic-tasks-from-anywhere.html" rel="alternate" type="text/html" title="Building Conductor: orchestrating periodic agentic tasks from anywhere" /><published>2026-01-11T00:00:00+00:00</published><updated>2026-01-11T00:00:00+00:00</updated><id>https://lukafinzgar.com/project/devlog/2026/01/11/building-conductor-orchestrating-periodic-agentic-tasks-from-anywhere</id><content type="html" xml:base="https://lukafinzgar.com/project/devlog/2026/01/11/building-conductor-orchestrating-periodic-agentic-tasks-from-anywhere.html"><![CDATA[<h2 id="overview">Overview</h2>

<p>I’ve been building <strong>Conductor</strong>, a monorepo that pairs a Compose Multiplatform mobile app with a FastAPI backend for managing <a href="https://opencode.ai/">OpenCode</a>.</p>

<p>At a high level, the repo has two main pieces:</p>

<ul>
  <li><strong>Frontend (Compose Multiplatform)</strong>: A shared Kotlin Multiplatform UI module for iOS, Android, and desktop, with thin platform-specific hosts.</li>
  <li><strong>Backend (FastAPI)</strong>: A Python 3.11+ service that manages project listings, starts/stops OpenCode instances, and proxies traffic. I chose OpenCode because it lets me (among other things) swap LLMs easily as we experiment (and has similar functionality to Claude Code, Codex CLI, …). It currently runs on my RPi 5.</li>
</ul>

<p>This keeps UI and business logic consistent across platforms.</p>

<h2 id="frontend-highlights">Frontend Highlights</h2>

<p>The shared UI lives in <code class="language-plaintext highlighter-rouge">frontend/sharedUI/</code>, following an MVVM architecture and Compose Multiplatform best practices. The Android and iOS apps stay minimal and host the shared Compose UI. I also added an Android TV module so we can show agent outputs on a big screen—websites, infographics, and other family-friendly visuals.</p>

<p>Desktop app:
<img src="/assets/desktopApp.png" alt="Screenshot of desktop app" /></p>

<h2 id="backend-highlights">Backend Highlights</h2>

<p>The FastAPI backend in <code class="language-plaintext highlighter-rouge">backend/</code> handles project management and instance lifecycle actions, launching OpenCode sessions as needed. We also use a Grok voice agent to make hands-free requests and get spoken summaries or quick prompts routed to the system. Via the mobile app, it’s also possible to add new skills (<a href="https://agentskills.io/home">AgentSkills</a>) to our agents (research, image gen, scraping, …).</p>

<h2 id="a-loved-use-case-in-our-family">A Loved Use Case in Our Family</h2>

<p>The most fun use case right now is a daily ritual: <strong>Conductor generates a kid-friendly infographic for the famous person who has a birthday today</strong>. It’s become a quick family tradition checking the infographic on TV and a great conversation starter. 
Example for the current date (12.1):</p>

<p><img src="/assets/conductor-infographic.png" alt="Kid-friendly infographic generated by Conductor" /></p>

<h2 id="why-im-playing-with-this">Why I’m Playing With This</h2>

<p>I’m exploring this stack to get a better feel for <strong>agent orchestration</strong> and to see how far I can push having agents do recurring work for me (and ping me via notifications when they need my hand). Currently, it looks to me like everything is going in the <a href="https://steve-yegge.medium.com/">Steve Yegge</a> direction.</p>

<hr />

<p>I’ll keep building this even after discovering a much more capable project with similar ideas: <a href="https://github.com/clawdbot/clawdbot">ClawdBot</a></p>]]></content><author><name></name></author><category term="project" /><category term="devlog" /><summary type="html"><![CDATA[Overview]]></summary></entry><entry><title type="html">Streamlining the Solo Dev Flow with Automation</title><link href="https://lukafinzgar.com/automation/2025/11/02/streamlining-the-solo-dev-flow-with-automation.html" rel="alternate" type="text/html" title="Streamlining the Solo Dev Flow with Automation" /><published>2025-11-02T08:00:00+00:00</published><updated>2025-11-02T08:00:00+00:00</updated><id>https://lukafinzgar.com/automation/2025/11/02/streamlining-the-solo-dev-flow-with-automation</id><content type="html" xml:base="https://lukafinzgar.com/automation/2025/11/02/streamlining-the-solo-dev-flow-with-automation.html"><![CDATA[<p>I run four small automations that cover research, docs, and maintenance and auto bug fixing so I can stay focused on shipping.</p>

<h2 id="competitive-search-on-a-schedule">Competitive Search on a Schedule</h2>

<p>A daily Competitive Search job scans market news and writes a short digest in the repo notes. I read the summary and add the useful bits to the roadmap without trawling feeds myself.</p>

<h2 id="weekly-docs-refresh">Weekly Docs Refresh</h2>

<p>Each Friday a bot pulls merged PRs, changelog entries, and TODO updates into a documentation patch, then opens the PR. The backlog stays current even if I never touch it manually.</p>

<h2 id="ai-maintenance-via-github-actions">AI Maintenance via GitHub Actions</h2>

<p>A monthly audit workflow asks a Cursor agent to scan the codebase and draft Markdown repair briefs. A second action reads any open brief and spins up an agent to implement the fix, then clears the file. Maintenance tickets move from discovery to execution without me hand-holding each one.</p>

<h2 id="sentry-triggered-cursor-fixes">Sentry-Triggered Cursor Fixes</h2>

<p>Sentry alerts send the payload straight to the Cursor dispatcher. The coding agent spins up a branch with the stack trace, reproduces the bug, and pushes a fix while I review the alert.</p>

<h2 id="why-it-matters">Why It Matters</h2>

<p>These automations reduce manual checks, speed up feedback, and keep the solo workflow predictable. I still review every pull request they open, but newer agents like Codex Cloud often land fixes that I can merge on the spot. The lighter process leaves more time for design and new features.</p>]]></content><author><name></name></author><category term="automation" /><summary type="html"><![CDATA[I run four small automations that cover research, docs, and maintenance and auto bug fixing so I can stay focused on shipping.]]></summary></entry><entry><title type="html">iOS Beta Now Open for My Health Research Companion</title><link href="https://lukafinzgar.com/health/2025/10/20/ios-beta-open.html" rel="alternate" type="text/html" title="iOS Beta Now Open for My Health Research Companion" /><published>2025-10-20T11:00:00+00:00</published><updated>2025-10-20T11:00:00+00:00</updated><id>https://lukafinzgar.com/health/2025/10/20/ios-beta-open</id><content type="html" xml:base="https://lukafinzgar.com/health/2025/10/20/ios-beta-open.html"><![CDATA[<p>I’m happy to share that the Health Research Companion now has an iOS beta. You can find more details in my <a href="/health/2025/09/21/introducing-my-ai-health-research-companion.html">previous update</a>.</p>

<p>I’m inviting iPhone users to join the first TestFlight cohort. The beta reflects the steady improvements I’ve been working on recently, and I’d love to hear how it fits into your day.</p>

<p>If you’d like to try it, just drop me a DM and I’ll send over an invite link. I’m eager to receive feedback.</p>]]></content><author><name></name></author><category term="health" /><summary type="html"><![CDATA[I’m happy to share that the Health Research Companion now has an iOS beta. You can find more details in my previous update.]]></summary></entry><entry><title type="html">Introducing My Health Research Companion</title><link href="https://lukafinzgar.com/health/2025/09/21/introducing-my-ai-health-research-companion.html" rel="alternate" type="text/html" title="Introducing My Health Research Companion" /><published>2025-09-21T09:00:00+00:00</published><updated>2025-09-21T09:00:00+00:00</updated><id>https://lukafinzgar.com/health/2025/09/21/introducing-my-ai-health-research-companion</id><content type="html" xml:base="https://lukafinzgar.com/health/2025/09/21/introducing-my-ai-health-research-companion.html"><![CDATA[<p>In my free time I’ve been working on something that started from a very personal need as a parent. Over the years I’ve collected stacks of paper diagnoses (MR, CT scans, lab results), often written in complex language that’s difficult to interpret. I felt AI could be a perfect fit to make this easier.</p>

<p>The main motivation came from my daughter’s journey with atopic dermatitis. After you receive a diagnosis with “no cure,” doctors usually stop searching for new treatments or dietary options. But I kept looking into medical journals myself, surfacing possible new therapies or lifestyle adjustments.</p>

<p>That’s the idea behind the app: it helps users find promising research and options they can then discuss with their doctor—the doctor remains the one who decides if something makes sense in each case.</p>

<p>On top of that, inspired by how much I enjoy NotebookLM, I added podcasts: hosts discussing your diagnosis in simple terms, plus a short “radio news” style segment highlighting recent research.</p>

<p>The app is available on Android via Firebase App Testing (not yet in the Play Store), with iOS coming soon. Friends who are testing it already find it useful, and I’d love to get more feedback—so if you’d like to try it, feel free to reach out!</p>

<p>Before making the app widely available, I also need to figure out what health-related apps must adhere to regarding Play Store / App Store rules and national regulations.</p>

<h2 id="app-screenshots">App Screenshots</h2>

<p>Here are some screenshots so you can get a better idea of how the AI Health Research Companion works:</p>

<p><img src="/assets/homeScreen.jpeg" alt="AI Health Research Companion Home Screen" /></p>

<p><img src="/assets/detailsScreen.jpeg" alt="AI Health Research Companion Details Screen" /></p>

<p><img src="/assets/researchDialog.jpeg" alt="AI Health Research Companion Research Dialog" /></p>

<p><img src="/assets/researchDetails.jpeg" alt="AI Health Research Companion Research Details" /></p>

<p><img src="/assets/podcastDialog.jpeg" alt="AI Health Research Companion Podcast Dialog" /></p>]]></content><author><name></name></author><category term="health" /><summary type="html"><![CDATA[In my free time I’ve been working on something that started from a very personal need as a parent. Over the years I’ve collected stacks of paper diagnoses (MR, CT scans, lab results), often written in complex language that’s difficult to interpret. I felt AI could be a perfect fit to make this easier.]]></summary></entry><entry><title type="html">Welcome to My Blog</title><link href="https://lukafinzgar.com/general/2025/01/13/welcome-to-my-blog.html" rel="alternate" type="text/html" title="Welcome to My Blog" /><published>2025-01-13T20:55:21+00:00</published><updated>2025-01-13T20:55:21+00:00</updated><id>https://lukafinzgar.com/general/2025/01/13/welcome-to-my-blog</id><content type="html" xml:base="https://lukafinzgar.com/general/2025/01/13/welcome-to-my-blog.html"><![CDATA[<p>Hello and welcome to my blog! I’m excited to share my explorations of software development with you.</p>

<p>In this blog, I’ll be focusing on:</p>
<ul>
  <li>The latest trends in AI-assisted software development</li>
  <li>Tips and tricks for integrating LLMs into your workflow</li>
  <li>
    <p>Best practices for working alongside AI agents</p>
  </li>
  <li>Exploring software development with the help of Large Language Models (LLMs)</li>
  <li>Leveraging AI agents in the development process</li>
  <li>Sharing insights and experiences from my journey</li>
  <li>Discussing the potential and challenges of AI-assisted development</li>
</ul>

<p>Stay tuned for regular updates as I dive into this fascinating intersection of traditional software development and cutting-edge AI technologies. Feel free to reach out if you have any questions or topics you’d like me to explore!</p>]]></content><author><name></name></author><category term="general" /><summary type="html"><![CDATA[Hello and welcome to my blog! I’m excited to share my explorations of software development with you.]]></summary></entry></feed>