DEV Community: Pavel Polívka

I got tired of Google Discover, so I built my own news feed in a day

Pavel Polívka — Wed, 11 Nov 2026 21:58:10 +0000

I love the swipe left on my phone's home screen. Coffee in one hand, thumb swipes left, and I see what is going on in the world. It is one of the few phone habits I actually like.

What I don't like is what I see there. So I built my own feed, called it Samizdat, and put it exactly where Google Discover used to be.

In this post, I'll walk you through:

why Google Discover and Samsung News drove me crazy
the small hack to get my own widget on the left page of a Samsung phone
the Cloudflare setup behind it, and the one query that blew my free plan

The problem

I have a Samsung Galaxy S24 Ultra. On One UI the page left of your home screen can show exactly three things: Google Discover, Samsung Free (now Samsung News), or nothing. That's it.

I tried both. Both are bad in the same ways:

Paywalls everywhere. Every third story is a site I don't pay for. I tap, I get a "subscribe to continue" box. Why show it to me then?
Junk. Celebrity gossip, sports I don't follow, "you won't believe what this actor did". I never clicked on any of it and it keeps coming.
The same story five times. One press release, five sites, five cards.
No control. You can tap "not interested" all day long. A week later it is back. There's no place to say "no sports, nothing older than two days, I like long articles more than breaking news".

I read Czech news, tech and dev stuff, and a bunch of hobby niches: RTS games, space, Linux on Apple Silicon, Home Assistant, Blender, electronics. Discover kind of knows that, but it mixes it with whatever pays the bills.

So the idea was simple. I pick the sources, RSS like in the old days. An LLM reads every new article, throws out the junk and paywalls, merges duplicates and writes a short summary. My phone shows the top 30.

The left page hack

The first question was where to show it. I didn't want another app I have to open. The whole point is the swipe.

You can't put your own app on that left page on stock One UI. Custom launchers like Lawnchair, Neo Launcher or Nova with HomeFeeder can host a real feed page, but I didn't want to leave Samsung's launcher just for this.

The trick is a widget:

Turn off the Discover page (long press the home screen, swipe left, switch it off).
Add a new home screen page on the left of your main one.
Put a widget on it and stretch it to full size.
Keep your normal page set as home.

Now when I unlock the phone I land on my usual home screen, swipe left, and there is my feed. Same gesture, my content. You can't really tell it is not a "real" feed page.

The widget is built with Jetpack Glance, the Compose-style API for Android widgets. Every row is a small thumbnail, headline, source, age and "+3 sources" when a story got merged. The top story gets a bigger hero card. Tap opens the app on the AI summary first, then the clean full text, or the original if I really want it. Thumbs up, thumbs down, mute source, mute topic, read later.

Glance has its limits (you can't just load an image URL, you have to download it and turn it into a bitmap yourself), but for a list of 30 items it is fine.

The infrastructure

I wanted this to cost almost nothing and to need zero babysitting. Everything runs on Cloudflare:

Workers with Hono. One Worker serves the API (/api/*) and the settings web app as static assets. No separate Pages project.
Cron Triggers. At :00 and :30 it fetches about 70 feeds (with ETag and Last-Modified, so most fetches are cheap). At :15 and :45 it rebuilds the ranked feed. Once a night it cleans up anything older than 14 days.
Queues. Every new article goes to a queue and gets scored in batches of 10.
The scoring itself is one Claude Haiku call per article. It returns strict JSON: relevance against my rules, paywall verdict, topics, and a 2 to 3 sentence summary in the article's own language. Czech stays Czech. If Haiku is not available it falls back to Mistral Small on Workers AI and switches back on its own. (Fun fact: the fallback was the first thing that ran in production, because I forgot to top up my Anthropic credit.)
Workers AI + Vectorize. Every article gets a bge-m3 embedding (it is multilingual, which matters with Czech). That is how the same story from five sites becomes one item, and how "more like the stuff I thumbed up" works.
D1 for sources, articles, scores and my signals.
Cloudflare Access in front of everything. I log in with a one-time PIN to my email, the Android app uses a service token.

Ranking is nothing fancy: LLM score × freshness decay × my signals × source weight × similarity to what I liked. Rules are plain sentences like "no celebrity gossip" or "prefer in-depth over breaking", and they go straight into the prompt.

The settings app is a small Preact SPA where I manage feeds, import OPML, switch on curated packs (Czech news, Czech tech, AI, games, space, Linux, home automation and so on) and write the rules.

The query that ate my free plan

One lesson I want to share, because it can happen to you too.

To check if a feed item is new, I had this:

SELECT id FROM articles
WHERE user_id = ? AND (url = ? OR (source_id = ? AND guid = ?))

Looks innocent. But an OR across different columns can't use an index in SQLite, so every check scanned the whole table. And D1 bills every scanned row as a row read. Run that for every item in every feed every few minutes and you get 8.9 million rows read in a day. The free plan has 5 million, per account. So it also took down my other app on the same account until midnight UTC.

The fix was an indexed lookup on the URL and skipping items older than the last fetch before touching the database at all. Two tips:

Run EXPLAIN QUERY PLAN on your hot queries. SCAN is bad, SEARCH ... USING INDEX is what you want.
wrangler d1 insights shows which query eats your reads.

I also added a daily budget in code. Every D1 result has meta.rows_read, so the Worker sums it and stops background jobs when it gets too high. And I moved to Workers Paid for $5 a month, which is a fair price for not thinking about it again.

How it was built

Honestly, most of the code was written by Claude Code. I did a brainstorm and a technical interview with it one evening, wrote down the decisions, and let it build the whole thing the next day: the Worker, the feed packs, the settings app, the Android app and the GitHub Actions pipeline that builds the APK (and now uploads to Google Play internal testing). My job was making decisions, unblocking things and reviewing.

From idea to a widget on my phone took about a day. A few years ago this would be a month of weekends, and I would give up somewhere around the Android widget part.

Wrap up

The real test is simple: do I stop opening Google Discover? Ask me in a month.

If you have a Samsung and you hate the left page too, the widget trick works with any feed reader widget, you don't need to build your own. But if you like building things, an LLM sitting between you and RSS is a really nice filter.

How do you read news on your phone? Drop a comment, I'm curious.

I review my AI agent's code like a merge request

Pavel Polívka — Tue, 10 Nov 2026 07:32:09 +0000

These days most of the code in my side projects is written by Claude Code. I describe what I want, it writes, I review. My job moved from writing code to reviewing it.

And reviewing in a terminal is bad. You get a wall of diff, scroll up, scroll down, and then type something like "in server.ts, around line 40, the host should be configurable" into the chat. It works, but it's nothing like a real code review. So I built a small tool for it. It's called Feedbacker, and it gives the agent a merge request page it can open for me.

In this post, I'll walk you through:

what Feedbacker does
how the agent asks for a review
what I changed after the first real reviews
the decisions and gotchas along the way

The itch

A few years ago I wrote about how to be good at code reviews. Most of it still holds when the author is an AI. What doesn't hold is the tooling. GitHub and GitLab are great for reviewing, but I don't want to push every half-done change to a branch and open an MR just to tell the agent it named something wrong.

Two more things made it worse for me:

Several repos at once. One task often touches more than one repo, and I want to see the whole change together.
Git worktrees. I sometimes run more than one agent in parallel, each in its own worktree. Reviewing that in a terminal is no fun at all.

What I wanted: the agent finishes, opens a page in my browser with the diffs of everything it changed, I comment on lines like in an MR, click a button, and my comments go back to the agent.

What it does

All repos on one page. The agent passes a list of repo paths, anywhere on disk, each with its own base. With --worktrees it pulls in every worktree of a repo, labelled with its branch.
Line comments. Click a line number to comment, shift-click to cover a range. A comment is either Comment (change something) or Ask (a question the agent has to answer).
Approve or Request changes. That sends everything back to the agent and closes the page.
Where to look. The agent writes a short summary and points me to the places it thinks matter most.
Sorted by kind. Code first, then tests, config, docs and generated files (lock files, build output). Only code starts expanded.
Local only. It runs on 127.0.0.1 with a random token in the URL, only reads git, and nothing leaves my machine.

How the agent asks

The easiest way is the Claude Code plugin:

claude plugin marketplace add PavlikPolivka/feedbacker
claude plugin install feedbacker@feedbacker

Then I just say "let me review it". The plugin gives Claude an MCP tool, request_review, and a skill that tells it when to use it. The tool call blocks until I submit, and the result is markdown the agent can act on:

# Review feedback

Verdict: **changes requested**

## Comments

### /home/me/Projects/api

**src/server.ts:6** (new side)

```diff
+  server.listen(port, "127.0.0.1");
```

Make the host configurable too.

Every comment carries the code it refers to. If the lines move, the agent still knows what I meant.

It also works without Claude Code. Any agent that speaks MCP can run it with npx -y agent-feedbacker mcp, and anything with a shell can use the CLI:

feedbacker ~/Projects/api ~/Projects/web@main -m "Bind the API to localhost"

It blocks, and when I submit it prints the feedback and exits.

Feedback on the feedback tool

The first real review was Feedbacker reviewing itself. I had the agent rewrite the review page in React in a separate worktree, and then I reviewed that change in the old page. It worked, which was a nice moment.

Then I used it for a few more changes and wrote down what annoyed me:

The agent's questions felt random. I had made it possible for the agent to ask me questions. In practice it asked things just to ask something. What I actually wanted was the other way around: to ask it about a line. That's where Ask came from. The agent can still ask, but only about a decision it can't make alone.
The summary was unreadable. The agent wrote a long paragraph and the page showed it as one huge heading. Now it's short markdown: one lead sentence and a list.
I don't want to review everything. Lock files, CLAUDE.md, build output. Now files are grouped by kind and the boring ones are collapsed. Tests are detected by path in most languages (*.spec.ts, *_test.go, test_*.py, FooTest.java).
Tell me where to look. A good MR description points the reviewer at the tricky parts. The agent should do the same, so now it can.

Funny thing. Most of this is the same advice I'd give a human developer opening an MR. Write a short description, point at what matters, don't make the reviewer read generated files.

Decisions

No runtime dependencies. Plain Node with a hand-written minimal MCP server (it's just JSON-RPC over stdio) instead of the SDK. The page is a small React app, but the bundle is committed, so using it needs no install or build.
Own diff table. I wanted to use diff2html, but it has no inline comments. The table is small and makes anchoring comments easy. Syntax highlighting is highlight.js.
One blocking tool call. I expected timeouts and planned two tools, one to start a review and one to wait for it. Claude Code kept the call open for over three minutes without complaining, so one tool it is.

Gotchas

The agent commits along the way. Then "diff against HEAD" is empty and the review shows nothing. The plugin now uses hooks to record where each repo stood when the session first touched it, and the review shows exactly what changed in this session. Uncommitted work is snapshotted with git stash create, which touches neither your working tree nor your stash list.

You can't see the URL. Claude Code doesn't show an MCP server's output, so if the browser doesn't open, the link is lost. feedbacker list prints the reviews waiting for you.

The name was taken. feedbacker on npm belongs to someone else. The package is agent-feedbacker, the command is still feedbacker.

CI hung forever. The end-to-end test runs the page in headless Chrome, and Chrome's sandbox doesn't start on GitHub's Ubuntu 24.04 runners. It didn't fail, it just hung.

Other tools

I'm not the first one with this idea. When I looked, there were already several: Plannotator, difit, claude-diff-review and more. Plannotator is the closest. It can even review several repos, if they all sit under one parent folder.

I looked at them, but they felt too complex for what I wanted. And I wanted any repos from anywhere and parallel worktrees side by side in one review. So I built my own small one. If one of those fits you better, use it. The idea matters more than the tool.

Is it worth it?

For me, yes. It's still early and the roadmap is long (replies to comments, showing only what changed since the last round), but reviewing in a browser is so much nicer than typing line numbers into a chat. And the agent gets better feedback, because I actually read the diff.

The code is on GitHub and the package is agent-feedbacker on npm.

How do you review what your agent writes? Drop a comment, I'm curious.

Google Sheets is my favourite free backend

Pavel Polívka — Tue, 03 Nov 2026 20:21:50 +0000

I made a small game for my daughter. It's called Počítadlo ("counter" in Czech), and it's a simple counting game that helps her learn the basics of math: adding and subtracting up to 20, ten questions, a timer and a trophy when she beats her record. It runs as a PWA on her iPad.

After a few days I wanted to know how she actually uses it. How often does she play, which levels, how long does it take her, where does she make mistakes? And I wanted it as an email to me and my wife every evening, because nobody is going to open a dashboard.

The obvious answer is a database, an API and some email service. For a kids' game that's way too much. So I used a Google Sheet and Apps Script. It costs nothing, there's no server, and it took one evening, most of which was me fighting Google's settings.

In this post, I'll walk you through:

how the app sends data to a Google Sheet
how the Sheet sends a daily email
the gotchas that cost me most of that evening

The idea

Every Google Sheet can have an Apps Script attached to it (Extensions → Apps Script). Apps Script is just JavaScript running on Google's servers, and it can do two things that matter here:

Be deployed as a web app: you get a URL, and doPost(e) runs every time someone POSTs to it.
Run functions on a schedule and send email with MailApp.

So the Sheet is the database, the script is the API, and Gmail is the email service. All free.

Receiving data

The script side is tiny. Parse the JSON, append rows:

function doPost(e) {
  const events = JSON.parse(e.postData.contents);
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("events");
  const rows = events.map((ev) => [new Date(), new Date(ev.ts), ev.type, ev.level, ev.seconds, ev.mistakes]);
  sheet.getRange(sheet.getLastRow() + 1, 1, rows.length, rows[0].length).setValues(rows);
  return ContentService.createTextOutput("ok");
}

Then Deploy → New deployment → Web app, Execute as: Me, Who has access: Anyone. You get a URL ending with /exec.

In the app, I send events like "app opened", "level started", "level finished in 53 seconds with one mistake". The call looks like this:

await fetch(URL, {
  method: "POST",
  mode: "no-cors",
  headers: { "Content-Type": "text/plain" },
  body: JSON.stringify(events),
});

Two things here are important:

text/plain, not application/json. A JSON content type makes the browser send a CORS preflight, and Apps Script can't answer it. With text/plain there's no preflight, and you still JSON.parse it on the other side.
no-cors means you can't read the response. A resolved fetch only tells you the request reached Google. Not that the script worked. Keep that in mind, it bit me later.

The iPad is not always online, so events go to a queue in localStorage first and get sent when there's a connection. Nothing gets lost when she plays in the car.

Sending the email

The report is a normal function. It reads the rows, counts games, best and average times per level, and lists the wrong answers. Then:

MailApp.sendEmail({ to: EMAILS, name: "Počítadlo", subject, htmlBody: html });

The name matters more than you'd think. Without it the email comes "from you", Gmail files it under Sent, and you think it never arrived. Ask me how I know.

For the schedule, you create a trigger:

function setup() {
  ScriptApp.newTrigger("check").timeBased().everyMinutes(15).create();
}

check does nothing before 19:00. After that, it sends the report once and remembers the date in PropertiesService. Why not just a daily trigger at 19:00? Read on.

The gotchas

This is where my evening went.

The trigger doesn't exist until you run setup by hand. Obvious in hindsight. Pasting the code creates nothing. You have to pick setup in the function dropdown and press Run. My first evening email never came because there was no trigger at all.

"At 19:00" means "sometime between 19:00 and 20:00". Google runs time triggers at any minute inside the window. A 15-minute check that sends on its first run after 19:00 gets you within 15 minutes, and if one run fails, the next one catches up.

403 "access denied" with access set to Anyone. The web app returned Google Drive's "you need access" page to everyone, even though the settings were right. It went away after I ran a function in the editor and approved the permissions. The script had simply never been authorized.

"Sorry, unable to open the file at this time." That's Apps Script telling you that you're logged into more than one Google account. Use a private window with only the account that owns the Sheet.

New deployment vs. new version. Deploy → New deployment gives you a new URL. To update the code and keep the URL, go to Manage deployments → Edit → Version: New version. The scheduled functions always run the latest saved code, so changes to the email need only a save.

Make it tell you it's alive. Since no-cors hides everything, I added a doGet that lists the triggers and when the last report went out. Opening the URL in a browser shows me whether the schedule exists.

Your hosting will play your game. The same evening there were app opens with no games in them. It was Vercel, opening every new deploy in a headless browser to take a screenshot for the dashboard. Now everything not running as the installed app gets a web- prefix on its session ID, and the email skips those. I don't drop them, just mark them. If the detection is ever wrong on the iPad, I still have the data.

Limits

This is not a real backend and I wouldn't pretend it is.

The web app URL is in your JavaScript, so anyone can POST to it. Validate what comes in. Worst case for me is junk rows in a spreadsheet.
A free Gmail account can send 100 emails a day with MailApp. For one report a day, fine.
It's slow and has quotas. For a few hundred rows a day from one iPad, I'll never notice. For your startup, use a real database.

Was it worth it?

Yes. For something like this, it's perfect. The whole thing is one script file, a spreadsheet I can open on my phone, and an email at 19:00. I already know she gets stuck on 20 − 7, and that she beat her Level 1 record in her second game of the evening.

If you have a small personal project that needs to store a bit of data or send you a summary, try a Sheet before you spin up a server. The code is on GitHub in the tracking folder.

What's your favourite "free backend" hack? Drop a comment.

My Obsidian vault, written by Claude Code, in my pocket

Pavel Polívka — Fri, 30 Oct 2026 13:16:39 +0000

These days I do most of my side-project work with Claude Code in a terminal. A few days ago I gave it access to my Obsidian vault and told it to write things down: every fix, every setup decision, every project. It turned out to be the best habit we built. The vault fills itself while I work.

There was one problem. All of it lived on my laptop, and my best questions come when I'm away from it. In the car, on the couch, in a queue. So I put Claude Code on my home server next to a synced copy of the vault and now I talk to it from the Claude app on my phone.

In this article, I'll walk you through:

how the vault is organised so an AI agent can find things
the setup on the server: Obsidian headless Sync and Claude Code Remote Control
how I locked it down
what broke on the way

A vault that agents can read

If you let an agent write into your notes without rules, you get a mess in a week. So the first note in my vault is Vault Rules.md. It says where things go and what Claude may and may not do:

Folders: Inbox/, Daily/, Projects/, Knowledge/, Archive/, Templates/, Attachments/.
Frontmatter on every note: created, updated, type, tags, author. The author field says if I wrote it, Claude did, or both.
Never delete or rewrite my text. Claude adds below it or in a callout. To get rid of something, move it to Archive/.
Log work in the daily note under a ## Claude heading, one line per item, with links.
No secrets. Passwords live in Bitwarden.

My global CLAUDE.md points to this note, so every Claude Code session reads it before writing anything.

Two more notes help agents find their way around without reading the whole vault:

Me.md is a profile: what I work on, my devices, how I like answers. Claude wrote it from my notes and a short interview, and anything it guessed is marked (inferred). I correct it when it is wrong.
Vault Map.md lists every note in one line, explains my own terms and says how to search. When a note is added or moved, Claude updates the map in the same change.

This sounds like a lot of overhead. It isn't, because I don't do it. I just read it.

The plan

I had three options for the phone part:

Build my own small chat web app on top of the Claude Agent SDK.
Write a Telegram bot.
Use Claude Code's Remote Control.

Remote Control won. You run claude remote-control in a folder on any machine, and the session shows up in the Claude app under Code. The server only makes outgoing connections, so there's nothing to expose to the internet, no reverse proxy and no login page to maintain. It runs on my normal Claude subscription.

The vault also has to be on the server. I use Obsidian Sync between my devices, and Obsidian now has an official headless client for it. The server becomes just another synced device. When Claude edits a note there, I see it on my phone a few seconds later.

Obsidian headless Sync

The client is the obsidian-headless package on npm, and the command is ob:

npm install -g --prefix ~/.local obsidian-headless
ob login
ob sync-setup --vault Pavel --path ~/vault/Pavel --device-name home

One thing to be careful about. Obsidian Sync syncs deletions too. An empty folder that pushes its "state" to your other devices is the nightmare scenario. So the first sync only downloads, and I switched it to two-way after I checked the file count:

ob sync-config --path ~/vault/Pavel --mode pull-only
ob sync --path ~/vault/Pavel
find ~/vault/Pavel -type f -not -path '*/.obsidian/*' | wc -l   # same as on the laptop?
ob sync-config --path ~/vault/Pavel --mode bidirectional

After that, a systemd user service keeps it running:

# ~/.config/systemd/user/obsidian-sync.service
[Service]
ExecStart=/home/pavel/.local/bin/ob sync --continuous --path /home/pavel/vault/Pavel
Restart=always
RestartSec=30

[Install]
WantedBy=default.target

Don't forget loginctl enable-linger for your user, or user services stop when you log out.

Claude Code next to the vault

I did not want Claude's config inside the vault, because everything in there syncs to all my devices. So Claude gets its own folder, ~/obsidian-agent, with two files:

CLAUDE.md: read Vault Rules.md first, then a few rules for this server. There's no Obsidian app here, so no Obsidian CLI; it edits the Markdown files directly. And keep answers short, because I read them on a phone.
.claude/settings.json: what it is allowed to do.

The vault itself is added as an extra directory. Then another user service runs Remote Control:

# ~/.config/systemd/user/claude-vault.service
[Service]
WorkingDirectory=/home/pavel/obsidian-agent
ExecStart=/usr/bin/claude remote-control --name Vault --permission-mode acceptEdits --spawn same-dir
Restart=always
RestartSec=30

acceptEdits means it can edit files in the vault without asking me each time. On a phone, approving every edit gets old fast.

Locking it down

Remote Control is reachable from anywhere I'm logged in to my Claude account. That's the point, but it also means the session should not be able to do much more than I need. My rule: read and write the vault, search the web, nothing else. No shell.

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "additionalDirectories": ["/home/pavel/vault/Pavel"],
    "allow": [
      "Read(//home/pavel/vault/Pavel/**)",
      "Edit(//home/pavel/vault/Pavel/**)",
      "Glob", "Grep", "WebSearch", "WebFetch"
    ],
    "deny": [
      "Bash",
      "Read(//home/pavel/.ssh/**)",
      "Read(//home/pavel/.config/**)",
      "Read(//home/pavel/.claude/**)",
      "Read(//etc/**)",
      "Edit(//home/pavel/obsidian-agent/**)",
      "Edit(//home/pavel/vault/Pavel/.obsidian/**)"
    ]
  }
}

Notice the double slash. That one bit us. In Claude Code permission rules, /home/pavel/.ssh/** does not mean an absolute path. A single leading slash is relative to the settings file. For an absolute path you need //, or ~/ for your home. With one slash, my deny rules matched nothing, and nothing warned me. We only caught it because we tested: we asked the agent to read ~/.ssh/config and the error said "you haven't granted it yet" instead of "denied". With the fix, it says denied.

So test your sandbox. Ask the agent to run a command, read a secret file and edit its own rules. All three should fail.

The last line of defense is a backup that doesn't depend on Sync. Every night at 03:30 a timer tars the vault and copies it to my NAS, and the last 14 copies are kept. The vault is under a megabyte, so it costs nothing.

What broke

It was not all smooth.

ob: command not found. I installed it into ~/.local/bin, and on the server that wasn't on my zsh PATH. The services use the full path, so only my shell was affected.
Login failed. ob login said "please double check your email and password". Check that you can log in on the Obsidian website with the same details, and try typing the password instead of pasting it into the hidden prompt over SSH.
"Remote Control is not yet enabled for your account." The server had a Claude Code from half a year ago. I updated it with sudo npm install -g, and claude --version still said the old version. Turns out there were two installs: an old one in /usr/local that came first on the PATH, and the new one in /usr. The service was running the old one.
"Enable Remote Control? (y/n)". The new version asks this once, and a systemd service has no keyboard. Run claude remote-control once by hand, answer y, then start the service.

What I use it for

Mostly small things:

"What did I decide about X?" It searches the project notes and the daily log and answers with links.
"Put this in my inbox." An idea, a link, a bug I just noticed while playing my own game.
"How did I fix Y on my laptop?" The answer is usually in a Knowledge/ note that Claude wrote while fixing it.

It is the same agent and the same rules as on my laptop, so the notes look the same no matter where they were written. That's the part I like the most.

What it can't do

No Obsidian CLI on the server. The CLI talks to a running Obsidian app, and there is none. The agent uses grep and file search instead. For a vault my size that finds everything; it does miss backlinks through aliases.
No shell. On purpose. If I want it to do something on the server, I do that from my laptop.

Working with Claude Code

Same as last time, I want to be honest about who did the work. Claude Code planned this, checked what was already on the server, wrote all the config and found most of the problems above. It also made the permission-path mistake, and it was Claude that caught it, by testing instead of trusting its own config.

There were things it was not allowed to do. The auto mode stopped it from installing the services that keep running on my server, so I did that myself. The logins, with passwords and 2FA, were also mine. I think that is the right split.

Was it worth it?

It's new, so ask me again in a month. But one evening of setup, no custom code and nothing open to the internet, and my notes now answer me from my pocket. If you already let an agent write your notes, this is a small step.

If you have your own setup for talking to your notes from your phone, I'd love to see it. Drop a comment.

You can follow me here on dev.to for more.

Omarchy on an M1 MacBook Air: what works, what broke and how I fixed it

Pavel Polívka — Thu, 29 Oct 2026 20:48:55 +0000

I had an M1 MacBook Air and an itch to try Omarchy, DHH's opinionated Arch Linux setup with Hyprland. Omarchy runs on Apple Silicon through Asahi Linux and a community build for Macs. Installing it was the easy part. Making it my daily driver took two days.

I did most of the setup in a terminal with Claude Code, and I kept notes of everything that broke. In this article, I want to go over the problems I hit and how I solved them, so you don't have to:

an update that left me with a blank desktop
external monitors through a DisplayLink dock
apps that don't ship for ARM Linux
Netflix and DRM
making a Mac keyboard behave
a custom theme to finish it off

The setup

The hardware is a MacBook Air M1. Asahi Linux gives you the kernel and drivers, and the community Mac build of Omarchy puts the whole Omarchy desktop on top. The GPU works and sleep works.

One thing to know before you start copying configs from the internet: the Hyprland version Omarchy ships (0.56) uses Lua for configuration. Most tutorials you will find are for the old format. Even hyprctl dispatch takes Lua now:

# old syntax, fails
hyprctl dispatch workspace 8

# new syntax
hyprctl dispatch "hl.dsp.focus({ workspace = '8' })"

Always look at the output. The old syntax just prints an error, and if you pipe it to /dev/null you will wonder why nothing happens.

The first hour was the easy stuff. Zen as the default browser on Super + B, the browser always opening on workspace 1, the terminal on workspace 2, smaller gaps between windows:

-- ~/.config/hypr/hyprland.lua
o.window("^(zen)$", { workspace = "1" })
o.window("^(foot|Alacritty|kitty|com.mitchellh.ghostty)$", { workspace = "2" })

The update that broke my desktop

This one cost me the most time, and it was my own fault.

I installed KDE Connect after refreshing the package database, but without a full system upgrade. On Arch that is a partial upgrade, and you should never do it. KDE Connect pulled in a newer Qt. I fixed it with a full omarchy update, rebooted, pressed Super + Space and got an empty screen. The menu, the launcher and parts of the top bar were all blank.

The first guess was a mismatch between Qt and the shell binary, so we rebuilt the shell from the AUR. It did not help. The real cause was more interesting: Qt 6.12 added a built-in type called Color, and Omarchy's shell has its own Color object. The new built-in one won, and every colour in the shell came back empty. Upstream Omarchy had already fixed it by importing the shell's version under a name (Commons.Color). The Mac build had not shipped that fix yet.

The fix: a patched copy of the shell, and pointing Omarchy at it. Omarchy reads its install path from /etc/omarchy.conf, so the copy can live in your home folder:

# /etc/omarchy.conf
OMARCHY_PATH=/home/pavel/.local/share/omarchy-patched

The copy symlinks everything from /usr/share/omarchy except the shell/ folder, which has the upstream fix applied. Once the Mac build catches up, I delete the file and reboot. I also added a small post-update hook that warns me when Qt is newer than the shell, so I see it before the desktop does.

Lessons:

Never pacman -Sy without -u.
When everything breaks after an update, look at which libraries changed before rebuilding things.
Community plugins can have the same bug. I had to patch two of them the same way.

External monitors

My desk has a Dell monitor in portrait and a Samsung 4K. On this MacBook I could not get video out through the USB-C ports, so I used a DisplayLink dock. On Arch that needs the evdi-dkms and displaylink packages from the AUR. After a reboot, both monitors came up.

Getting them arranged had three small traps:

The Dell needs a rotation. transform = 1 in the monitor config.
The screens must touch. If there is even a small gap between them in the layout, the mouse cannot move from one screen to the other.
nwg-displays is handy, but its Save overwrites your whole monitors.lua. Use it to drag screens around, then copy the positions into your own file.

This is what I ended up with. Matching monitors by description instead of connector name keeps it stable, because DisplayLink connector names can change:

-- ~/.config/hypr/monitors.lua
local dell = "desc:Dell Inc. DELL P2419HC 9N7BL03"
local samsung = "desc:Samsung Electric Company SAMSUNG"

hl.monitor({ output = dell, mode = "1920x1080@60", position = "424x2448", scale = 1, transform = 1 })
hl.monitor({ output = samsung, mode = "3840x2160@60", position = "1504x2448", scale = 1.6 })
hl.monitor({ output = "eDP-1", mode = "2560x1600@60", position = "3904x3209", scale = 2 })

-- Workspaces 1-7 on the Samsung, 8 on the Dell, 9-10 on the laptop
for ws = 1, 7 do
  hl.workspace_rule({ workspace = tostring(ws), monitor = samsung, default = ws == 1 })
end
hl.workspace_rule({ workspace = "8", monitor = dell, default = true })

Without the dock, all workspaces simply fall back to the laptop screen.

ARM apps: the long tail

Most things are in the Arch Linux ARM repos. The ones that are not were the most work.

App	Problem	What worked
Bitwarden	The bar plugin ships helper binaries only for Intel	Built the three helpers with Rust (`cargo build --locked`) and allowed ARM in the plugin's architecture check
WhatsApp	The web app works, but I wanted the native OmaWhatsApp plugin	Built its privacy-patched `wacli` from source with Go
Zed	Not in the ARM repos	The official installer has ARM builds. Added a `zeditor` alias so Omarchy's menu sees it
Blender	No ARM Linux build from Blender, Flathub or Arch	Fedora builds it for ARM, so it runs in a Fedora container with distrobox, GPU included
Obsidian	In the repos	Turned on its command line tool, so Claude Code can read and write my notes

A few notes from this:

Zed is my IntelliJ replacement. It has a JetBrains keymap, and one setting turns off all AI features: "disable_ai": true. I also hid the sign-in button, because I don't want an account.
Blender from Fedora had one bug: its colour config is newer than its colour library, so it silently fell back to basic colours. Changing the version line in config.ocio from 2.5 to 2.4 fixed it.
Check what an installer does before you run it. Some, like Zed's, just unpack into ~/.local. Some want root. Reading 170 lines of shell script takes two minutes.

Netflix

Netflix needs Google's Widevine DRM. Google makes ARM Linux Widevine only for Chromebooks, so Netflix only accepts it from a browser that says it is a Chromebook. I went through three error codes before it worked:

Error	Cause
F7701-1003 in Zen	Widevine installed but not enabled in the browser
E100	Widevine works, but the browser doesn't say it is ChromeOS
C7701-1003 in Chromium	Fresh profile, Widevine downloaded but not loaded until restart

What works is a separate Netflix web app in Chromium with:

its own profile (--user-data-dir), so the flags apply even when another Chromium window is already running
a ChromeOS user agent
the ChromeOS-based Widevine from Asahi's widevine package
--disable-component-update, so Chromium doesn't replace that Widevine with its own download

Quality is capped at 720p, like on any Linux browser. Good enough for the couch.

Making the Mac keyboard behave

After years on macOS, my fingers expect Cmd shortcuts. Omarchy already maps Super + C/V/X to copy and paste. I added Super + A for select all. It sends Ctrl + A, except in terminals, where Ctrl + A means "go to the start of the line".

The F-row needed the most changes:

Media keys by default. The Apple keyboard driver has a setting for this: options hid_apple fnmode=1 in /etc/modprobe.d/hid_apple.conf. Brightness, media and volume work without Fn; F1–F12 need Fn.
F5 is dictation. On the Mac it is the dictation key; here it sends "mic mute". Omarchy ships Voxtype, a local speech-to-text tool, so F5 now does push-to-talk dictation.
F4 opens the app launcher, like Spotlight.
F3 opens the screenshot menu. Omarchy has no Mission Control, and Super + Space already opens the menu.
F6 toggles Do Not Disturb. By default it put the laptop to sleep, because systemd handles that key before Hyprland sees it. One line fixes that: HandleSuspendKey=ignore in a drop-in under /etc/systemd/logind.conf.d/.

Smaller things: I added the Czech QWERTY layout (Left Alt + Right Alt switches, and Omarchy's bar shows a layout indicator as soon as there are two), and I set the calendar to start weeks on Monday.

What doesn't work

To be fair, not everything is solved:

Touch ID. The fingerprint sensor is tied to Apple's Secure Enclave, and Asahi doesn't support it.
Automatic keyboard backlight. There is no ambient light sensor support, so the backlight only turns off when the screen locks.
Netflix in my normal browser. Only the Chromebook-pretending web app plays it.
Some defaults assume a bigger screen. The screenshot editor opened larger than the laptop display, with its toolbar off-screen. A window rule capping it at 85% of the screen fixed that.

A theme to finish it off

Once everything worked, I made it look the way I wanted. Golden Record is my own Omarchy theme: deep-space blue-black, warm text, gold accents, and NASA and Webb images as backgrounds. The background follows the time of day: Earthrise in the morning, the Sun during the day, the golden Cosmic Cliffs in the evening, a deep field full of galaxies at night.

You can install it with:

omarchy theme install https://github.com/PavlikPolivka/golden-record

Omarchy themes the terminal, bar, editor and Chromium from one colors.toml, but not Firefox-based browsers like Zen. So I wrote that part too, and sent it upstream as a pull request to Omarchy.

Working with Claude Code

I want to be honest about how this went, because I didn't type most of these commands myself.

Claude Code did the research, read the source when something broke and wrote the configs. It was fast and it was thorough. It also made mistakes: it blamed the blank desktop on the wrong thing at first, it once killed its own shell with a too-wide pkill -f, and it claimed a tool wouldn't touch my config when it did. Each time, the fix was the same: check the actual output instead of assuming.

Some things it was not allowed to do: build AUR packages, install services that keep running, publish anything under my account. I ran those myself, and I think that is the right split.

The best habit we built was writing everything down. Every fix went into my Obsidian notes as it happened. That is also why this article exists.

Was it worth it?

Yes. Two days in, the M1 Air runs Omarchy as my daily machine: three monitors, a keyboard that feels like a Mac, the apps I need and a desktop I like looking at. Expect to fix things yourself, especially anything that doesn't ship for ARM. If you're fine with that, it's a great second life for an M1.

If you run Omarchy or Asahi on a Mac, I'd love to hear what you had to fix. Drop a comment.

You can follow me here on dev.to for more.

The Industry Quietly Killed Junior Developer Jobs

Pavel Polívka — Fri, 24 Apr 2026 19:47:12 +0000

The Path That Used to Exist

A few years ago, the path into tech felt almost predictable. You learned how to code, landed a junior position, and slowly grew into a senior developer. It wasn’t easy, but it was clear.

That path still exists on paper. In practice, it’s quietly breaking down.

What Changed Inside Teams

I lead a development team in a high-pressure environment, and over the past couple of years, something shifted. We didn’t make a big announcement. There was no strategic decision titled “Stop Hiring Juniors.” But when you look at what’s actually happening, the result is the same: we’re hiring fewer junior developers.

Not because we don’t want to help people grow. But because the system we operate in stopped supporting it.

At one point, we even had a discussion about shortening onboarding and training for new joiners. Not to improve the experience or make it more efficient in a meaningful way, but simply to spend less time on it. That alone says a lot. Training used to be an expected part of building a team. Now it’s something we actively try to minimize.

AI Didn’t Replace Developers — It Reshaped the Work

Part of the shift comes from tools. AI didn’t replace developers, but it changed the distribution of work inside teams. Tasks that used to be perfect for juniors—writing boilerplate, digging through bugs, documenting messy legacy systems—are now handled by more experienced developers using AI assistance.

The work didn’t disappear, but it became faster, more predictable, and easier to absorb without adding another person to the team.

That changes the hiring equation in a very real way. When a senior developer can pick up a task and complete it quickly with the help of AI, the need to bring in someone junior to learn on that task becomes harder to justify.

The Real Cost of Juniors

The harder truth, though, has less to do with tools and more to do with time.

Juniors don’t just cost salary. They cost attention. Explaining a task properly takes time. Providing context takes time. Reviewing code carefully takes time. And all of that happens while the rest of the team is under constant pressure to deliver.

In theory, mentoring is an investment. In practice, it often feels like a delay.

There’s a moment most lead developers recognize. You’re halfway through explaining a task, juggling deadlines, and thinking to yourself that you could probably just do it faster on your own—or now, with the help of AI tools.

That moment doesn’t make you a bad mentor. It reflects the environment you’re operating in.

Why Mentorship Is Breaking Down

Mentoring requires space to slow down, and most teams don’t have that space anymore. Deadlines are tighter, expectations are higher, and teams are expected to deliver more with fewer people.

In that kind of environment, juniors aren’t seen as future assets—they’re seen as immediate risk.

Not because they lack potential, but because the system doesn’t allow them to be unproductive for long enough to grow.

The Pipeline Problem Nobody Solves

This creates a deeper problem that the industry isn’t really addressing. Everyone wants senior developers, but senior developers don’t just appear. They come from junior roles, from time spent learning on the job, from being allowed to make mistakes and gradually improve.

If we reduce those opportunities, we shrink the future pool of experienced developers.

You can already see early signs of this shift. Job postings labeled as “junior” often require years of experience. True entry-level roles are harder to find. More companies expect candidates to arrive already capable of contributing almost immediately.

The expectations didn’t just increase. The entry point moved.

What Replaces Junior Roles

What replaces the old junior path isn’t a single alternative, but a mix of changes. People spend longer learning on their own before landing their first job. Personal projects and real-world experience become essential just to be considered. AI tools act as a kind of substitute for entry-level work inside teams. And the number of opportunities to learn while being paid decreases.

What This Means for New Developers

For someone trying to break into the industry, that changes the advice we should be giving.

“Learn to code and get a job” no longer reflects reality. A more honest version would focus on becoming useful before being hired—learning how to navigate real codebases, building things that actually work, and developing the ability to solve problems that aren’t clearly defined.

Closing

None of this means junior developers are gone. But the version of the role that many people still imagine—the one where you join a team, get mentored, and gradually grow into the job—is fading.

The industry didn’t make a big decision to remove it. It just optimized for speed, efficiency, and output.

And quietly, that was enough.

Building a Multi-Agent Content Management System with AI

Pavel Polívka — Mon, 13 Apr 2026 21:03:59 +0000

I recently built something that would have sounded like science fiction a year ago: an AI system that helps manage parts of my content workflow—from discovery to publishing—across LinkedIn, BlueSky, and DEV.to.

Not a chatbot. Not a simple automation script. A multi-agent orchestration system where different AI agents coordinate to handle different parts of the content pipeline.

Here's what I learned building it.

The Problem: Context Switching is Killing Productivity

Before this system, my content workflow looked like this:

Manually browse Hacker News, Reddit, and tech blogs for topics
Take notes in a doc somewhere
Write drafts when I find time
Edit and format for each platform separately
Remember to actually post them
Track what performed well

Each step required context switching. Each context switch killed momentum. And worst of all, the coordination overhead meant I was spending more time managing content than creating it.

Sound familiar?

The Solution: Agents That Actually Coordinate

Instead of building one monolithic AI assistant, I built a team of specialized agents:

Discovery Agent: Scans web sources, identifies trending topics relevant to my audience
Content Writer: Takes approved topics and drafts initial content (which I then refine and personalize)
Content Manager: Orchestrates publishing schedules, handles cross-platform posting
Brand Strategist: Reviews content for brand voice and decides what's worth publishing

Each agent has a specific job. Each agent can create tasks, update status, escalate when blocked, and hand off work to other agents.

The key insight: agents don't just execute tasks—they coordinate around tasks.

Important note: The AI agents handle the boring coordination work—scheduling, formatting, API calls. The creative work, strategic decisions, and final writing? That's still me. Think of this as automation for the parts of content creation that don't require human creativity.

Architecture: Tasks as the Coordination Primitive

The core of the system is a task queue, but not like you're thinking.

┌─────────────────────────────────────────────────┐
│           Task Management Layer                 │
│  (Issues, Status, Assignments, Dependencies)    │
└─────────────────────────────────────────────────┘
         ↑              ↑              ↑
         │              │              │
    ┌────┴───┐     ┌───┴────┐    ┌───┴─────┐
    │Discovery│     │Content │    │Content  │
    │ Agent   │────>│Writer  │───>│Manager  │
    └─────────┘     └────────┘    └─────────┘
         │              │              │
         ↓              ↓              ↓
    ┌─────────────────────────────────────────┐
    │       External APIs (Web, LLM, Social)  │
    └─────────────────────────────────────────┘

Every piece of work is an issue (think GitHub issue, JIRA ticket, Linear task). Issues have:

Status: todo, in_progress, in_review, done, blocked
Assignee: which agent owns this work right now
Parent/child relationships: for breaking down complex work
Dependencies: explicit "blocked by" relationships between tasks

When an agent picks up work:

It checks out the issue (atomic lock, prevents conflicts)
Does the work
Updates status and adds a comment explaining what changed
Either marks it done or reassigns to another agent

This isn't novel in human project management. What's novel is that AI agents can now participate in the same workflow.

Real Code: Publishing to BlueSky

Here's what the Content Manager agent actually does when asked to publish a post:

# 1. Authenticate with BlueSky
AUTH=$(curl -s -X POST "https://bsky.social/xrpc/com.atproto.server.createSession" \
  -H "Content-Type: application/json" \
  -d "{\"identifier\": \"$BSKY_IDENTIFIER\", \"password\": \"$BSKY_APP_PASSWORD\"}")

ACCESS_JWT=$(echo "$AUTH" | python3 -c "import sys,json; print(json.load(sys.stdin)['accessJwt'])")
DID=$(echo "$AUTH" | python3 -c "import sys,json; print(json.load(sys.stdin)['did'])")

# 2. Create the post
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%S.000Z")

curl -s -X POST "https://bsky.social/xrpc/com.atproto.repo.createRecord" \
  -H "Authorization: Bearer $ACCESS_JWT" \
  -H "Content-Type: application/json" \
  -d "{
    \"repo\": \"$DID\",
    \"collection\": \"app.bsky.feed.post\",
    \"record\": {
      \"\\$type\": \"app.bsky.feed.post\",
      \"text\": \"$POST_TEXT\",
      \"createdAt\": \"$TIMESTAMP\"
    }
  }"

Nothing fancy. Standard REST API calls. The magic isn't in the API integration—it's in the orchestration layer that knows:

When to post
What content to use
How to handle failures
Who to notify when done

Real Code: The Heartbeat Pattern

Agents don't run continuously. They run in heartbeats—short execution windows triggered by events.

Each heartbeat follows this pattern:

# 1. Check what's assigned to me
INBOX=$(curl -s -H "Authorization: Bearer $API_KEY" \
  "$API_URL/api/agents/me/inbox-lite")

# 2. Pick highest priority work (in_progress → todo → blocked if I can unblock)
ISSUE_ID=$(echo "$INBOX" | jq -r '.[0].id')

# 3. Checkout (atomic lock)
curl -s -X POST -H "Authorization: Bearer $API_KEY" \
  -H "X-Run-Id: $RUN_ID" \
  "$API_URL/api/issues/$ISSUE_ID/checkout"

# 4. Do the work
# ... agent-specific logic here ...

# 5. Update status
curl -s -X PATCH -H "Authorization: Bearer $API_KEY" \
  -H "X-Run-Id: $RUN_ID" \
  -d '{"status": "done", "comment": "Published to BlueSky: https://..."}' \
  "$API_URL/api/issues/$ISSUE_ID"

This heartbeat pattern means:

Agents don't fight over the same work (checkout is atomic)
Every action is traced (run ID links actions to heartbeat executions)
Failures are isolated (one agent crashing doesn't affect others)
The system is naturally resumable (agents pick up where they left off)

The Hard Parts Nobody Talks About

1. Error Recovery

LLMs fail. APIs rate-limit. Networks drop. Your agents will encounter errors.

The first version of my system would just retry infinitely or silently fail. Neither is acceptable.

Now, agents follow this escalation pattern:

Transient errors (network, rate limit): retry with exponential backoff
Validation errors (bad input): mark issue blocked, comment with specific error, reassign to creator
Permanent errors (auth expired): mark blocked, escalate to me

if [ $HTTP_STATUS -eq 401 ]; then
  curl -X PATCH -d '{
    "status": "blocked",
    "comment": "Authentication expired. Please refresh access token"
  }' "$API_URL/issues/$ISSUE_ID"
  exit 0
fi

2. Content Length Limits

BlueSky has a 300 grapheme limit (not characters, not bytes—graphemes). An emoji counts as one grapheme, but é might count as one or two depending on normalization.

I learned this the hard way when a post with 280 characters got rejected for being 340 graphemes.

Solution: validate before posting.

import unicodedata
text = "your post text"
grapheme_count = len(list(text))  # Simplified; use grapheme library for production
if grapheme_count > 300:
    # Truncate or split into thread

3. Daily Routines That Don't Spam

I wanted daily publishing reminders, but I didn't want 7 separate tasks clogging my inbox.

Solution: routines with concurrency policies.

{
  "title": "Daily content reminder",
  "cronExpression": "30 8 * * *",
  "concurrencyPolicy": "skip_if_active"
}

skip_if_active means: if yesterday's reminder is still open, don't create today's. This prevents reminder spam while ensuring I don't lose track.

What This Enables

With this system running:

Discovery Agent scans Hacker News daily, creates issues for trending topics
Brand Strategist reviews those issues, approves the ones worth writing about
Content Writer drafts initial content based on approved topics (I refine and add my personal insights)
Content Manager schedules and publishes across BlueSky, LinkedIn, DEV.to

My involvement: strategic decisions, creative refinement, and final approval. The boring coordination work runs autonomously.

Time saved per week: ~10 hours of coordination overhead.

Key Lessons

1. Agents Are APIs for Work

Just like you wouldn't build an API that accepts ambiguous parameters, don't give agents ambiguous tasks.

Bad: "Handle the deployment"
Good: "Deploy branch release/v2.3 to production, run smoke tests, rollback if health checks fail after 5 min"

2. Visibility > Autonomy

Early on, I optimized for "how much can agents do without me?"

Wrong question.

Better question: "how quickly can I understand what agents did and why?"

Now every agent action includes:

What changed
Why it changed
What happens next
Links to relevant resources

3. Start With Boring Tech

The orchestration layer is PostgreSQL + REST APIs. No vector DB, no RAG, no fancy AI frameworks.

Why? Because the hard part isn't the AI—it's the coordination. And coordination is a solved problem in distributed systems.

Use LLMs for what they're good at (writing, reasoning, API calls). Use boring databases for what they're good at (consistency, transactions, queries).

Try It Yourself

You don't need to build the whole system at once. Start small:

Pick one recurring task (e.g., posting to social media)
Create a simple task queue (even a JSON file works)
Build one agent that reads from the queue, does the work, updates status
Add a second agent that creates tasks for the first agent

Once you see two agents coordinating, you'll understand why this pattern scales.

What's Next

I'm working on:

Approval workflows: some tasks need human review before publishing
Budget controls: LLM costs add up fast; agents need spending limits
Analytics integration: track what content performs, feed that back to the Discovery Agent

The goal isn't to remove humans from the loop—it's to remove humans from the boring parts of the loop. The creative thinking, strategic decisions, and personal touch? That's still all human.

Questions? Drop them in the comments. I'm especially curious if you've built similar multi-agent systems and what patterns worked (or didn't) for you.

AI #Automation #Agents #ContentStrategy #Productivity

The Review Revolution: Why Code Review Is Now the Most Important Skill You Have

Pavel Polívka — Thu, 09 Apr 2026 10:54:23 +0000

The PR came in on a Tuesday. Clean diff. All CI checks green. GitLab Duo had already run its pass — no obvious security anti-patterns, no style violations. The author was a solid mid-level developer, two years on the team.

Then I asked: "Why did you choose this approach for the concurrency handling here?"

Pause.

"I think Claude Code suggested it and it seemed right."

That was not the author lying or cutting corners. They had reviewed the output, it looked correct, and they shipped it. The code was correct — at least for the happy path. What neither of us could answer in that moment: what happens when the lock acquisition times out? What is the failure mode if the downstream call is slow? Why this implementation over the simpler one?

That is not a junior developer problem. That is a 2026 code review problem. And most teams are running their last checkpoint with 2019-era habits.

What Changed

Before AI coding tools, the reviewer's job was well-defined: check the logic, catch edge cases, flag style violations, enforce team conventions. It was a hard job, but it had a reasonable assumption built in — the author understood what they wrote, because they wrote it.

That assumption is gone.

With Claude Code, GitHub Copilot, and similar tools in daily use, the reviewer now does two jobs:

Check the code itself
Check whether the author understands the code

These are different skills. The second is harder. And most review processes were not designed for it.

The failure mode looks like this: a developer gets a requirement, pastes it into Claude Code, gets working code, reviews the output for obvious issues, and ships it. The PR reviewer checks the diff, finds nothing wrong, approves it. Neither person can articulate the performance characteristics, the failure modes, or the security implications of what was just merged.

The data confirms this is not edge-case behavior. Veracode's 2026 analysis found that AI-generated code introduces security vulnerabilities in 45% of cases — in Java specifically, 72% of AI-generated code has at least one CWE hit. The Harness 2026 report found that organizations that adopted AI coding tools without updating their review processes saw a 34% increase in production incidents in 2025.

This is not an argument against AI tools. It is an argument that the bar for code review just moved, and most teams have not moved with it.

What Good Review Looks Like Now

1. The New PR Description Standard

The fastest way to know if a developer understood what they shipped is to make them explain it — in their own words, before anyone reviews the code.

Add this to your team's PR template:

## What does this do?
[Explain the intent — not the code, the problem being solved]

## How was this implemented?
[Explain the approach. If AI-generated, say so and explain why you accepted it.]

## Edge cases considered
- [ ] [At least 3. Be specific.]

## How was this tested?
[If AI-generated tests were included, note which assertions were written by hand]

When a developer cannot fill in "edge cases considered," they do not understand what they shipped. That is the signal — and it surfaces before the reviewer has read a single line of code.

The best-performing engineering teams in 2026 are now requiring AI-generated PRs to include this explicitly: what the approach is, what edge cases were considered, and at least one self-generated test per non-trivial function. Not as bureaucracy — as a forcing function for comprehension.

2. The Three Review Questions for AI-Generated Code

When reviewing a PR that includes AI-generated sections — Claude Code output, GitLab Duo suggestions, Copilot completions — ask these three questions. Direct them at the code, not the author.

Question 1: What is this code optimizing for?

AI-generated code is optimized for "solves the stated problem" and "compiles." It is not optimized for your specific performance SLAs, your team's error-handling conventions, or your domain's threat model.

Look at the implementation choices. Is this optimized for throughput? For readability? For minimal memory allocation? Often the answer is: it's optimized for none of those, because the prompt didn't specify any of them. That is where the mismatch lives.

Ask the author: "What constraint was this generated to solve?" If they cannot answer, the review should not proceed.

Question 2: What happens when this fails?

AI tends to generate happy-path code. Exception handling, circuit breakers, timeouts, and retry logic are frequently omitted or wrong.

Look specifically at: what exceptions are caught and swallowed? What happens if the external call is slow or returns a 503? Is the failure mode recoverable or catastrophic? If a pod restarts mid-operation, what is the state of in-flight transactions?

These are not exotic scenarios. These are Tuesday morning incidents. And they are the exact kind of thing AI code generation consistently misses, because the prompt that generated the code did not mention them.

Question 3: Would a junior on this team be able to maintain this in 18 months?

AI-generated code can be locally clever and globally incomprehensible. If the implementation relies on a pattern that is not in your team's standard vocabulary — and the PR description does not explain it — that is a code smell, even if the code is technically correct.

Maintainability is not just about readability. It's about whether the next developer who touches this file will understand the intent well enough to make safe changes. AI-generated code often optimizes for correctness at the cost of clarity.

3. GitLab Duo in the Review Flow

GitLab Duo Code Review integrates at the merge request level and is genuinely useful — it catches style violations, obvious logic errors, and common security anti-patterns quickly.

The key is using it correctly: treat Duo's pass as the mechanical layer, not the full review. It handles the things a linter and a static analyzer would catch, at the speed of a bot.

The human reviewer's job starts where Duo's ends: does the author understand what they shipped? Is the failure handling correct for this domain? Does the implementation reflect team conventions that are not captured in any linter rule?

Duo is not a substitute for the three questions above. It is a first pass that frees you to ask better questions.

Code Review as a Career Signal

AI coding tools have done something unexpected to engineering career ladders: they made junior and mid-level code syntactically indistinguishable from senior code.

A developer with 18 months of experience can now generate a working microservice — clean, organized, passing all automated checks — that looks like something a staff engineer would write. The output is impressive. The signal it sends about the developer's ability is... unclear.

What AI cannot do is teach you to catch what it missed.

Recognizing silent exception swallowing that will cause a service to fail silently under load — that requires having seen it happen. Noticing a data access pattern that will cause N+1 queries as the dataset grows — that requires understanding how your ORM generates SQL. Catching retry logic with no jitter that will thundering-herd your downstream service at exactly the moment you least want it to — that requires having been on-call when it happened to someone else.

These instincts come from production experience. They come from reading incident reviews. They come from having opinions that are more specific than "this looks right."

In 2026, the clearest seniority signal is not what you can generate — it is what you can review.

If you are a mid-level developer trying to reach senior: become exceptional at code review. Not just at finding bugs, but at teaching through review. The comment that explains why a pattern is dangerous, not just that it is. The question that forces the author to reason through failure modes they had not considered. That is senior engineering. AI cannot fake it.

The Checklist

Before approving any PR that includes AI-generated code:

Comprehension checks:

[ ] Author can explain the approach in their own words
[ ] PR description lists at least 3 edge cases, with specifics
[ ] Implementation choice is justified (why this approach over alternatives)

Failure mode checks:

[ ] Exception handling is explicit — no empty catch blocks, no silent swallowing
[ ] External calls have timeout and retry logic appropriate for the failure profile
[ ] Failure modes are recoverable (or the PR explicitly notes they are not)

Quality checks:

[ ] At least one non-trivial test was written by the author, not generated
[ ] Logging is present at failure points, not just on the happy path
[ ] Any new DB query has been analyzed for N+1 risk

Red flags that should pause approval:

"I'm not sure why this works, but it does"
100% test coverage where all tests are generated and assert the obvious
An exception handler that logs and swallows without alerting
An implementation that is clever in a way that is not explained anywhere

The code review is the last checkpoint before production. For most of engineering history, it was also a reasonable proxy for whether the author understood what they wrote.

That proxy is gone. The checkpoint remains.

The teams that figure out how to update their review process — not abandon AI tools, not pretend nothing changed, but update the actual process — will have fewer incidents, faster onboarding, and a clearer signal for who is actually senior.

The code review did not get less important. It got harder. And that is exactly the kind of harder that separates good engineers from the rest.

What does your team's current process look like for reviewing AI-generated code? I'm curious what's working — share it in the comments.

How to create simple email form in your NodeJS website

Pavel Polívka — Sun, 10 Jul 2022 18:30:22 +0000

Most webpages have some contact form, usually not very fancy and the backend behind it can be SalesForce, any other variation of lead generation software but usually it just sends email.

Sending emails is not trivial, you need to have an SMTP server and that alone will add to your costs. Fortunately, we live in an age where everything is a service and API. There are tons of services that can send emails to you. My goal was to do it as cheaply as possible (preferably for free). I was expecting at most about 5 emails per day.

After some research, I decided to use Send In Blue. Their free plan has 300 emails per day (more than enough for me), you do not need a credit card to sign up, no DNS shenanigans and their API is very straightforward.

API endpoint in NextJS

NextJS offers a friendly and easy way to create API endpoints from where you can call any external APIs without actually exposing your secret keys to the browser.

I got the API key from Send in Blue with the help of this awesome help page, and add the key into my .env.local file.

NEXT_PUBLIC_SEND_IN_BLUE_KEY=xxxxapikeyxxxx

I also put the key into the Vercel Environment variables manager with the same name.

I created a new file api/email.js from where I will send the email via Send In Blue API.

const sendInBlueKey = process.env.NEXT_PUBLIC_SEND_IN_BLUE_KEY

export default async function handler(req, res) {

    const body = req.body

    const resp = await fetch('https://api.sendinblue.com/v3/smtp/email', {
        method: 'POST',
        headers: {
          'Accept': 'application/json',
          'Content-Type': 'application/json',
          'api-key': sendInBlueKey
        },
        body: JSON.stringify({
            "sender":{  
                "name": body.name,
                "email": body.email
             },
             "to":[  
                {  
                   "email": "myemail@ppolivka.com",
                   "name": "Pavel Polivka"
                }
             ],
             "subject":`Contact Form Eamil From ${body.name}`,
             "htmlContent":`
                <html>
                    <head></head>
                    <body>
                        From: ${body.name} <br/>
                        Message: ${body.message} <br/>
                    </body>
                </html>
            `
        })
    });

    res.status(200).end()
}

From the form, I am getting the name and email of the sender and a message. I am sending that (the sender is the email from the form) to my email address so that I can reply to my email client.

Contact Form

Then I created a contact form component. It's a simple form with three fields and the submit button. All the sending magic is happening in the handleSubmit function.

import TextField from '@mui/material/TextField';
import Button from '@mui/material/Button';
import {useState} from 'react';

export default function Contact() {

    const [send, setSend] = useState(false);

    async function handleSubmit(event) {
        event.preventDefault()
        const data = {
            email: event.target.email.value,
            name: event.target.name.value,
            message: event.target.message.value,
        }

        const JSONdata = JSON.stringify(data)

        const endpoint = '/api/email'

        const options = {
            method: 'POST',
            headers: {
              'Content-Type': 'application/json',
            },
            body: JSONdata,
        }

        const response = await fetch(endpoint, options)

        setSend(true)
    }

    let content;

    if (send) {
        content = <>
            <p>Thank you for contacting me!</p>
        </>
    } else {
        content = <>
            <form onSubmit={handleSubmit}>
                <TextField id="email" label="Email" variant="outlined" required />
                <TextField id="name" label="Name" variant="outlined" required />
                <TextField id="message" label="Message" variant="outlined" required multiline rows={4} />

                <Button variant="contained" type="submit">Send</Button>
            </form>
        </>
    }

    return (
        <>
            {content}
        </>
        );
}

I am using React Material UI, but you can use any UI or just normal inputs.

This is all you need. Simple and elegant. It was done in an hour.

Good luck coding.

Do you really need fancy productivity apps?

Pavel Polívka — Thu, 23 Jun 2022 19:40:09 +0000

If you look at Medium, Twitter, or any other platform where many developers hang out you will see an obsession with productivity tools, apps, etc... Everybody is praising the latest shiny apps that will make you a productivity god.

Did we ever stop and asked do we really need all of these apps? I have a busy work schedule and trying to manage that and still have some quality time with my family. So I naturally tried to be as much productive as I can. I downloaded almost all the apps that are in the talks. Tried them in the belief that they will help me with all my issues with time management, not enough time, and joggling all the tasks I need to complete.

Well, I am here to report that it does not work. You actually lose a lot of time trying to use the tools.

Take Obsidian for example. In theory, it's a very cool idea. Have all the notes in one place, interconnected with links between each other. Your second digital brain. Did somebody actually manage to keep a decent size library of all their notes with the links in all the places? When I am writing down a note I actually need to know what are my other existing notes to create a link to them. That seems stupid. Like really, really stupid. The chart showing the relationship between the notes looks impressive in the demos and videos but is it useful? What do you actually gain with it? Maybe just maybe, it's all just a bunch of fluff that will get you nothing.

For me, the best solution for note-taking is basically a bunch of text files and an easy solution in full-text search in those. Wau, that sounds great and useful. What app does that? That is the beauty of this. You do not really need an app for this. It's part of your OS. You just put a bunch of text files in a folder and use Windows search or Apple Spotlight.

Sure it's low tech. Sure it does not really work on phones. Do you really need all your work notes on the go? What is all the obsession with having everything synced and on the go? Do you really need your notes on how to restart a production server when you are grocery shopping? Do you need them on your phone at all? For productivity's sake, you should not really look at your phone when you work anyway. For the notes you need to have on the go you can use your phone notes app. What kind of notes do you need on the go? Maybe a list for your shopping, some measurements, etc... The notes app on your phone is more than capable of doing that.

Another productivity giant is Notion. I never figured out what people really see on it. It's a bunch of templates for markdown files and kanban boards. Plus it's really sluggish and slow to use. Not to mention finicky. It's the most over-engineered solution for your notes and todos. What is the real need for kanban outside of some specific work use cases (and even there it's more or less questionable)? Do you really need to know that your window cleaning is not in progress? What is wrong with just a normal to-do list? If you have that many to-dos that you need to have them organized in some other way than just a plain list, you have a problem with delivering or overcommitting, not with the organization of your tasks.

I tried a lot of different to-do list apps. Some better some worse. I always came back to just writing my todos down on paper. It forces you to keep the list small and manageable. Plus you know, it feels fancy.

In the end, you use what you are comfortable with I will stick with my pile of text files, simple notes app, and paper.

What is in your bag?

Pavel Polívka — Thu, 06 Jan 2022 19:25:40 +0000

As a new year article, I decided to write up some words about what are the daily drivers I have in my bag.

Bag

I use a top-loaded HP bag for 15-inch laptops. My 17 inch Mac Book fits it well and it's pretty nice. But nothing special.

Laptops

I have multiple laptops. For my work, I mostly use Macbook Pro 17" - 16GB RAM, 2019 model. I also have Macbook Air 13" M1 model I use for my personal projects. I also got a few Windows and Linux machines but those are rarely used.

Other electronics

I carry Kindle Whitepaper 4 with me almost everywhere. I love reading.
I also carry Jabra Evolve 75 I use it for work meetings. It's a really great headset. I also have Marshall Mode II true wireless for music and or audiobooks on the go. I love the Marshall sound.

I also have some USB/USB-C cables and some USB-C dongles. Fully embracing that Mac dongle life.

Drug store

I have deodorant in spray, hand sanitizer, mouth deodorant, and glass cleaning gel. Nothing special.

Various

I have my Moleskin notebook, Parker pen, FFP2 respirator, chopsticks, and set of lockpicks. I have lockpicking as one of my hobbies I rarely use those but saved me calling locksmith more than once.

If you like this article you can follow me on Twitter.

React Componenets in Markdown articles

Pavel Polívka — Wed, 15 Dec 2021 19:51:27 +0000

As I decided to create my blog I choose Next.js as my framework of choice, as a backend I use markdown files stored in a git repo.

To render my files I use React Markdown. It's an awesome component that can render markdown files without any config.

After a few posts, I figured out that I need some custom components rendered with my posts. One was for images, to make them zoomable for phones and the second one was a syntax highlighter for code snippets.

React has a huge amount of components that can help us with both of these. I decided to use react-zoom-pan-pinch for image zoom and react-syntax-highlighter for syntax highlight.

Ok. I have my components, not how to render them from our markdown files. Fortunately, React Markdown has us covered. It allows us to do a custom rendering of some tags.

We can do something like this:

import ReactMarkdown from 'react-markdown';
import { Prism as SyntaxHighlighter } from "react-syntax-highlighter";
import { materialDark } from "react-syntax-highlighter/dist/cjs/styles/prism";
import { TransformWrapper, TransformComponent } from "react-zoom-pan-pinch";

<ReactMarkdown
    components={{
        p: ({ node, children }) => {
            if (node.children[0].tagName === "img") {
                const image = node.children[0];
                return (
                    <TransformWrapper>
                        <TransformComponent>
                            <img
                                alt={image.properties.alt}
                                src={`${image.properties.src}`}
                            />
                        </TransformComponent>
                    </TransformWrapper>
                );
            }
            // Return default child if it's not an image
            return <p>{children}</p>;
        },
        code({ className, children }) {
            // Removing "language-" because React-Markdown already added "language-"
            let language = "";
            if (className) {
                language = className.replace("language-", "");
            }
            return (
                <SyntaxHighlighter
                    style={materialDark}
                    language={language}
                    children={children[0]}
                />
            );
        },
    }}
>
    {postData.contentMarkdown}
</ReactMarkdown>

For images, we must hook into

tag, as ReactMarkdown is wrapping images in paragraphs. So with a simple if we decide if the first child of the paragraph is an image. If so we replace the whole thing.

For code, we are just replacing the whole code tag.

If you like this article you can follow me on Twitter.