<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Knowledge | Andreas Ahoniemi</title>
    <link>https://ahoniemi.se/en/knowledge/</link>
    <description>Guides, checklists and walkthroughs on AI automation, AI in the product, digital development and AI visibility. Written by Andreas Ahoniemi.</description>
    <language>en</language>
    <atom:link href="https://ahoniemi.se/en/rss.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>AI automation 101: what it is and when it pays off</title>
      <link>https://ahoniemi.se/en/knowledge/ai-automation-101/</link>
      <guid isPermaLink="true">https://ahoniemi.se/en/knowledge/ai-automation-101/</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <description>What AI automation actually is, where the line sits against ordinary automation, and how to decide whether a process is worth building.</description>
      <content:encoded><![CDATA[<p>AI automation is a workflow executed by software instead of a person, where a language model handles the steps that require interpretation. What separates it from ordinary automation is that the input is allowed to vary: an email phrased three ways, an invoice in five layouts, a ticket with no clear category. If the input is already structured you do not need AI, and it will be both cheaper and more reliable without it.</p>]]></content:encoded>
    </item>
    <item>
      <title>Seven processes that are almost always worth automating</title>
      <link>https://ahoniemi.se/en/knowledge/processes-worth-automating/</link>
      <guid isPermaLink="true">https://ahoniemi.se/en/knowledge/processes-worth-automating/</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <description>Concrete workflows where AI automation tends to pay off, and what makes those particular ones suitable.</description>
      <content:encoded><![CDATA[<p>Processes worth automating with AI share three traits: they run often, the input varies in format but not in meaning, and the decision is rule-driven even when the text is not. Below are seven flows where that combination almost always holds, drawn from client work rather than a vendor brochure.</p>]]></content:encoded>
    </item>
    <item>
      <title>How to cost an automation before you build it</title>
      <link>https://ahoniemi.se/en/knowledge/costing-an-automation/</link>
      <guid isPermaLink="true">https://ahoniemi.se/en/knowledge/costing-an-automation/</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <description>A concrete method for deciding whether an automation project carries, including the costs people routinely forget.</description>
      <content:encoded><![CDATA[<p>To cost an automation you need four numbers: how often the process runs, how long it takes, what that time costs, and what building plus maintaining it costs. The first three you can measure in an afternoon by asking whoever does the work. The fourth is where most business cases fall apart, because maintenance is almost always left out.</p>]]></content:encoded>
    </item>
    <item>
      <title>RAG explained: making AI answer from your own documents</title>
      <link>https://ahoniemi.se/en/knowledge/rag-explained/</link>
      <guid isPermaLink="true">https://ahoniemi.se/en/knowledge/rag-explained/</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <description>How retrieval augmented generation works in practice, and why retrieval decides the quality rather than the model.</description>
      <content:encoded><![CDATA[<p>RAG stands for retrieval augmented generation and means the model retrieves relevant passages from your own documents before composing an answer, rather than answering from memory. It is the single most important technique for making an assistant usable in production, because every claim can then be traced to a document that actually exists.</p>]]></content:encoded>
    </item>
    <item>
      <title>Before you build an AI assistant: seven questions to answer</title>
      <link>https://ahoniemi.se/en/knowledge/before-you-build-an-ai-assistant/</link>
      <guid isPermaLink="true">https://ahoniemi.se/en/knowledge/before-you-build-an-ai-assistant/</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <description>The questions that decide whether the project becomes useful or becomes a demo nobody opens twice.</description>
      <content:encoded><![CDATA[<p>Most AI assistants that get built never get used, and it is rarely the technology. It is that nobody decided who it is for, what it is allowed to say, and how anyone would tell whether it works. Seven questions to answer before anyone writes code, in this order.</p>]]></content:encoded>
    </item>
    <item>
      <title>How to measure whether AI search actually got better</title>
      <link>https://ahoniemi.se/en/knowledge/measuring-ai-search/</link>
      <guid isPermaLink="true">https://ahoniemi.se/en/knowledge/measuring-ai-search/</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <description>A method for evaluating search quality with numbers instead of opinion, and why hybrid search almost always wins.</description>
      <content:encoded><![CDATA[<p>To know whether a search improvement actually helped you need an evaluation set: real queries from your own search logs, each with the result that should rank first. Run the set before and after every change. Without it, every discussion about search quality becomes a discussion about how it feels, and whoever speaks loudest wins.</p>]]></content:encoded>
    </item>
    <item>
      <title>Core Web Vitals 101: what actually affects load time</title>
      <link>https://ahoniemi.se/en/knowledge/core-web-vitals-101/</link>
      <guid isPermaLink="true">https://ahoniemi.se/en/knowledge/core-web-vitals-101/</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <description>The three metrics explained, what causes poor scores in practice, and why a caching plugin rarely helps.</description>
      <content:encoded><![CDATA[<p>Core Web Vitals are Google’s three measures of how a page is experienced: LCP for when the main content appears, INP for how quickly the page responds to input, and CLS for how much the layout shifts. They are measured on real visitors rather than in a test tool, and it is the 75th percentile that decides whether you clear the threshold. A score of 95 in a lab test therefore says almost nothing about what your visitors experience.</p>]]></content:encoded>
    </item>
    <item>
      <title>Replatforming without losing traffic: a checklist</title>
      <link>https://ahoniemi.se/en/knowledge/replatforming-without-losing-traffic/</link>
      <guid isPermaLink="true">https://ahoniemi.se/en/knowledge/replatforming-without-losing-traffic/</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <description>What actually decides whether traffic survives a rebuild, in the order the work should happen.</description>
      <content:encoded><![CDATA[<p>Traffic loss during a replatform is almost never caused by the new platform. It is caused by addresses changing without redirects, content disappearing along the way, or the new site not being indexable. All three are predictable and therefore avoidable, but only if the work happens before launch rather than after.</p>]]></content:encoded>
    </item>
    <item>
      <title>API integrations: six mistakes that cost money</title>
      <link>https://ahoniemi.se/en/knowledge/api-integration-mistakes/</link>
      <guid isPermaLink="true">https://ahoniemi.se/en/knowledge/api-integration-mistakes/</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <description>The errors that make an integration work in testing and then create duplicates, lose orders, or need daily babysitting.</description>
      <content:encoded><![CDATA[<p>An integration that works in testing and misbehaves in production almost always has one of six faults. None of them are about which API you use; they are about how the system behaves when something goes wrong: when the receiver is down, when the same message arrives twice, or when a field means different things in the two systems.</p>]]></content:encoded>
    </item>
    <item>
      <title>How to get cited by ChatGPT and Perplexity</title>
      <link>https://ahoniemi.se/en/knowledge/getting-cited-by-chatgpt-and-perplexity/</link>
      <guid isPermaLink="true">https://ahoniemi.se/en/knowledge/getting-cited-by-chatgpt-and-perplexity/</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <description>What actually decides whether a language model uses your page as a source, and what you can do about it.</description>
      <content:encoded><![CDATA[<p>To be cited by a language model, three things have to hold: the content must be in the server response without requiring JavaScript, the crawler must be admitted in robots.txt, and the passage must survive being lifted out of the page. The third is what separates most sites, because a model rarely cites a whole page, it cites a single paragraph.</p>]]></content:encoded>
    </item>
    <item>
      <title>GEO vs SEO: what is the same and what actually differs</title>
      <link>https://ahoniemi.se/en/knowledge/geo-vs-seo/</link>
      <guid isPermaLink="true">https://ahoniemi.se/en/knowledge/geo-vs-seo/</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <description>Where the two overlap, where they genuinely diverge, and what is pure marketing.</description>
      <content:encoded><![CDATA[<p>GEO, generative engine optimization, is the work of getting cited in answers from language models. SEO is the work of ranking in a list of links. They share roughly eighty percent of their foundation: content has to be fetchable, readable and understandable. The difference is the goal. SEO wants a position, GEO wants a sentence inside somebody else’s answer, and that rewards different things in how the text is written.</p>]]></content:encoded>
    </item>
    <item>
      <title>A technical checklist for AI visibility</title>
      <link>https://ahoniemi.se/en/knowledge/technical-checklist-ai-visibility/</link>
      <guid isPermaLink="true">https://ahoniemi.se/en/knowledge/technical-checklist-ai-visibility/</guid>
      <pubDate>Wed, 16 Sep 2026 09:00:00 GMT</pubDate>
      <description>Concrete checks you can run yourself today, with the command or tool for each one.</description>
      <content:encoded><![CDATA[<p>A technical review for AI visibility comes down to three questions: can the crawler fetch the page, can it read the content without executing JavaScript, and does it understand what the page is about. Below are the checks for each, in the order worth doing them, and most take under a minute.</p>]]></content:encoded>
    </item>
  </channel>
</rss>
