<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Home on Mikolaj Karebski - Engineering Notes</title><link>https://blog.karebski.dev/</link><description>Recent content in Home on Mikolaj Karebski - Engineering Notes</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Wed, 05 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.karebski.dev/index.xml" rel="self" type="application/rss+xml"/><item><title>My Linux Setup (2026)</title><link>https://blog.karebski.dev/posts/my-linux-setup-2026/</link><pubDate>Wed, 05 Aug 2026 00:00:00 +0000</pubDate><guid>https://blog.karebski.dev/posts/my-linux-setup-2026/</guid><description>NOTE: I plan to write similar posts whenever my setup changes, while keeping previous versions for reference.
I have been using Linux as my main development environment for the last nine years, and over time I have built a setup that feels simple, practical, and hard to move away from.
For the past few years, Pop!_OS has been my primary system. I keep coming back to it for a few boring but important reasons: it has been reliable, NVIDIA drivers are available out of the box, and its battery management has been good enough that I do not feel like I am constantly fighting my machine.</description></item><item><title>Why we need IDLC</title><link>https://blog.karebski.dev/posts/why-we-need-idlc/</link><pubDate>Mon, 27 Jul 2026 00:00:00 +0000</pubDate><guid>https://blog.karebski.dev/posts/why-we-need-idlc/</guid><description>One of the first important concepts many software engineers learn is the Software Development Life Cycle (SDLC).
SDLC breaks down the process of building software through planning, design, implementation, testing, deployment, and maintenance. The exact stages may differ depending on the definition, but the core idea is always similar.
Why does SDLC matter? Because it gives teams a shared way to think about how software moves from an idea to production and later maintenance.</description></item><item><title>SRE Starts When Metrics Influence Decisions</title><link>https://blog.karebski.dev/posts/sre-starts-when-metrics-influence-decisions/</link><pubDate>Fri, 05 Jun 2026 00:00:00 +0000</pubDate><guid>https://blog.karebski.dev/posts/sre-starts-when-metrics-influence-decisions/</guid><description>I&amp;rsquo;m currently rereading Google&amp;rsquo;s Site Reliability Engineering book, and it made me think about how companies adopt SRE in practice.
Many companies naturally adopt parts of SRE as their systems grow. They add monitoring, alerting, dashboards, incident reviews, and postmortems because at some point operating without them becomes too painful.
But there is an important step that is easier to miss: connecting those signals back to business decisions.
Reliability metrics should not live only in engineering dashboards.</description></item><item><title>Please Do Not Send AI Slop To Your Coworkers</title><link>https://blog.karebski.dev/posts/please-do-not-send-ai-slop-to-your-coworkers/</link><pubDate>Fri, 29 May 2026 00:00:00 +0000</pubDate><guid>https://blog.karebski.dev/posts/please-do-not-send-ai-slop-to-your-coworkers/</guid><description>On our helpdesk, we recently received a message like this. I obfuscated the details from the original message, but the structure is unchanged.
Message from the developer &amp;mdash;&amp;mdash; START OF THE MESSAGE &amp;mdash;&amp;ndash;
Summary
The @acme/ui CDN buckets serve manifest.json without an Access-Control-Allow-Origin header, so the @acme/ui dev harness cannot read it cross-origin and shows every environment as &amp;ldquo;unreachable&amp;rdquo;. We need CORS enabled on the buckets cdnstaging (staging) and cdnprod (production).</description></item><item><title>How I use AI</title><link>https://blog.karebski.dev/posts/how-i-use-ai/</link><pubDate>Mon, 11 May 2026 00:00:00 +0000</pubDate><guid>https://blog.karebski.dev/posts/how-i-use-ai/</guid><description>Colleagues often ask me if I&amp;rsquo;m worried about the growth of AI and if it will take my job away. Honestly, not really. What worries me is not that AI is capable of writing code or even complete solutions, but how quickly people are willing to hand over responsibility to it.
I&amp;rsquo;ve worked with people who treat AI agents like servants that do everything for them. One agent writes code, another reviews it, then yet another posts on Slack that it&amp;rsquo;s done, so the first one can deploy the change to production.</description></item><item><title>What this blog is and what it is not?</title><link>https://blog.karebski.dev/about/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.karebski.dev/about/</guid><description>When I attended my first IT conference, Confitura in Warsaw, I noticed that many of the people I looked up to had blogs of their own. It left me with the feeling that if I wanted to grow into a more complete professional, I should probably have one too.
Whether that was true or not, over more than ten years in IT I’ve come across many ideas, practices, and solutions that seem worth writing down and sharing.</description></item></channel></rss>