<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
	<title>Knowing Better IT</title>
  <id>https://kb-it.net/</id>
  <updated>2026-02-23T12:00:00Z</updated>
  <link rel="self" href="https://kb-it.net/feed.xml"/>
  <link rel="alternate" href="https://kb-it.net/"/>
  <author>
    <name>Krzysztof Bardoński</name>
  </author>

  <entry>
		<title>Stop Adding AI to Your Architecture</title>
		<id>https://kb-it.net/stop-adding-ai-to-your-architecture/</id>
		<updated>2026-02-18T12:37:13Z</updated>
		<link rel="alternate" href="https://kb-it.net/stop-adding-ai-to-your-architecture/"/>
	<summary>Bolting AI onto existing systems rarely works. You must redesign around probabilistic components, economic constraints, and data gravity or pay for it in latency, fragility, and cloud bills.</summary>
  </entry>

  <entry>
		<title>5 Architectural Decisions That Will Make or Break Your AI Product</title>
		<id>https://kb-it.net/5-architectural-decisions-that-will-make-or-break-your-ai-product/</id>
		<updated>2026-02-16T18:13:41Z</updated>
		<link rel="alternate" href="https://kb-it.net/5-architectural-decisions-that-will-make-or-break-your-ai-product/"/>
	<summary>AI failures aren’t about algorithms, they’re about architecture. Discover five architectural decisions drawn from real-world experience revealing hidden traps, cost explosions, and potential pitfalls.</summary>
  </entry>

  <entry>
		<title>Why This Ransomware Attack Failed</title>
		<id>https://kb-it.net/why_this_ransomware_attack_failed/</id>
		<updated>2026-02-16T13:53:25Z</updated>
		<link rel="alternate" href="https://kb-it.net/why_this_ransomware_attack_failed/"/>
	<summary>A contractor’s compromised laptop begins encrypting a network share. In a flat network, this is the beginning of the end. But in this environment, the attack hit a “pressure-sealed” boundary. Two hours later, the incident was closed: one isolated VM, zero data loss, and critical systems unaffected. This wasn’t luck, itt was architectural engineering. Here is how to design for the inevitable breach and win.</summary>
  </entry>

  <entry>
		<title>When “More” Makes the System Worse</title>
		<id>https://kb-it.net/when_more_makes_the_system_worse/</id>
		<updated>2026-02-10T11:05:30Z</updated>
		<link rel="alternate" href="https://kb-it.net/when_more_makes_the_system_worse/"/>
	<summary>Adding features is the default response to almost every product or stakeholder request. It feels constructive, measurable, and safe. Yet in real-world systems, feature growth is one of the primary drivers of architectural stagnation.</summary>
  </entry>

</feed>