Jakub Duniak

I started on the LTE Layer 3 protocol stack in C++, but most of my work was in Layer 2 baseband, written in an in-house C dialect for many-core DSP boards. Most of my impact was in the PDCP, RLC and RRCC sublayers, where I was a Product Guardian — the role responsible for code quality in sensitive areas (solution design, code reviews). I implemented and supported a number of 3GPP features in baseband: eDRX (in both LTE and NR), NB-IoT and CAT-M paging, ROHC header compression, MBMS, admission control, rate-control scheduling, and more.

I worked a lot in Erlang/OTP on the test side, including writing a complete ROHC compressor/decompressor simulator. I was a trainer too — I led multiple multi-day Erlang workshops for new developers, took part in the Tech Days and presented features to customers. I also served as Scrum Master (certified, scrum.org).

Over the years I developed several tools to save developers time and make their work easier. I created many (including the Review Tracker and AI code-review metrics described in separate sections); below are just a few simple examples I can share.

• eDRX paging-window diagram generator. A tool that visualises specific scenarios for a telecom feature — eDRX. For a given use case it draws an exact diagram of the scenario, with the relevant signal timing marked. Before this, engineers sketched these scenarios on whiteboards; it took a lot of time and effort each day for engineers to agree on exactly which scenario was being discussed, because this feature can have a huge number of edge cases. The tool made the diagram automatic and exact, and it was used across several teams.

• Test-launch GUI. I wrote many Tkinter front-ends for an OTP/Erlang test framework. They did a range of things: booking a hardware node automatically for a test run, launching stability and performance test runs, or letting you easily choose specific feature-related tests.

I made an internal tool for Product Guardians (frontend/backend). PGs own specific code areas, and some areas need a PG’s +1 RR score before a change can merge. I built a tool that tracks the lifecycle of a reviewed commit, so each PG can see what needs work now and what is waiting on the designers’ patches. The tool reads YAML files mapping code paths to a restricted set of reviewers, queries Gerrit for matching changes, and shows them in one table, with a separate slot per commit for the PGs in each of two time zones. The tool is live and in use; for the screenshot I lorem-ipsumed the sensitive data.

Each commit shows required-reviewer approvals as a row of squares — filled once a listed reviewer gives a +1, empty while one is still needed — plus an SLA column counting hours since the change appeared, measured against the agreed 16-hour response rule (the SLA for PGs).

The second part of the tool is a feature ↔ PG assignment page (not pictured), which uses an API to our internal feature tracker to get a feature’s status and helps PGs divide work among themselves across the different parts of a feature’s lifecycle. The app also grabs all the documents attached to a feature from the tracker API and links them in a convenient way, making it a one-stop shop for a PG supporting that feature.

The AI reviewer (a team project) targets 5G baseband scheduler code written in an in-house C dialect. It runs against commits, manually or in CI, checking each change against about 160 KB of domain-specific rules: bugs, fault slip-through, missing code, security, performance, style, naming, and test coverage. An orchestrator fetches the diff, searches around 13 semantic knowledge bases for relevant rules, and spawns three reviewer subagents in parallel: one specialises in critical faults, the second in quality and performance, the third in testing. The orchestrator aggregates and de-duplicates findings, grades the change (A+ to F), injects line numbers, and signs the review with a verifiable hash so CI can enforce that every commit was reviewed.

It is a great exercise in agentic AI development. We use kiro-cli at the company, which has some limitations — for example, subagents can’t use the same tools as the main orchestrator agent (the code or knowledge tool for semantic search). The challenge is to overcome those limitations: we try to do what we can in Python and pass only the relevant context to the subagents. There is still a lot of experimentation ongoing and different concepts being tested, such as whether it is better to give an agent access to the whole repository with RAG-indexed code, or to limit its context by providing just a lean diff file and a set of rules. Each approach has its trade-offs: the number of false positives, the ability to precisely recall rules, the time spent on the review (it needs to be quick to be useful), and token consumption.

To help with this, I built the metrics app on my own. Pre- and post-tool-call hooks record AI agent activity as JSON, served by a FastAPI backend and a React frontend. Developers can see the review metrics and A/B test prompt variants. You can clearly see the amount of Warnings/Critical faults found, how many tool calls, per-agent timing, CLI version, model version, etc.

If you click a row, it expands into a detailed report and a per-agent log of every tool call, including the reason for each call, its duration, and which file it interacted with.

Developers can clearly see each decision the LLM made, why it made it, how long it took and which files it affected.

The second part of the app is the Stability section. I set up nightly runs of a set of hand-picked commits, which are reviewed each time by the latest version of our review agent. It supports running stability loops on different branches, and has its own scheduler with queue support. You put the time and the branches into 1 config file, scheduler picks it up and queues it.

The runs are then evaluated against a set of criteria — is the report complete, how long did it take, is the grade consistent, are all agents producing review artifacts, and so on. It lets us make sure the review agent is stable and consistent, and that we can rely on it.

The non-deterministic nature of LLMs makes this challenging, and we are continuously experimenting with different approaches to mitigate it.

To catch inconsistencies and faults more easily, I set up an AI agent that runs on the CI side: if a stability run contains a fault, it triggers an AI investigation that checks all the review output artifacts, as well as the run history, to give the developer a short, precise explanation of what could have gone wrong, before they even begin to look into the logs themselves.

In a big company with hundreds of products and services, keeping track of compatibilities between versions and the possible upgrade paths for a given set of products is a challenge. I built the entire backend and handled all DevOps for an internal compatibility-matrix app used by around a 2k employees — it tracks products, versions, compatibility details and upgrade steps, and supports a role-based approval workflow, with editor, approver and admin roles across many configured areas. The React frontend was the responsibility of other devs; everything server-side and on the CI/CD side was mine, built from scratch — setting up the image registry, GitLab pipelines, Kubernetes cluster, observability, backups and data-retention policies.

Three FastAPI services:

I created GitLab CI/CD pipelines across staging and production environments in the Kubernetes cluster. Reviewed and verified merge requests deploy to staging automatically, with manually triggered releases from release branches. Backup jobs from the Postgres PVC (pg_dump, gzipped and GPG-encrypted) run before every migration. A Prometheus / Grafana / Loki stack provides metrics, log shipping and an audit trail.

MR PIPELINE  ·  every merge request
+------------+      +-----------------+     +--------------------+
| lint       |      | test            |     | build              |
| ruff check | -->  | per service,    | --> | 4 images,          |
| + format   |      | only if changed |     | validate (no push) |
+------------+      +-----------------+     +--------------------+

DEPLOY PIPELINE  ·  main ▶ staging (auto)  ·  release/* ▶ production (manual ▷)
+-------------+     +------------+     +---------+     +------------------+     +-------------+
| push images | --> | pg_dump    | --> | alembic | --> | k8s apply        | --> | integration |
| to registry |     | backup     |     | migrate |     | deploy           |     | smoke-test  |
|             |     | gzip + GPG |     | upgrade |     | rollout + health |     | pytest      |
+------------+      +------------+     +---------+     +------------------+     +-------------+

The IK Multimedia Tonex One is an amp-modelling pedal with no display. I wrote firmware for an ESP32-S3 board that connects to the pedal over USB, decodes its protocol, and drives a custom UI I built in C on a 240×280 LCD. It displays live values of the potentiometer and pedal settings — gain, EQ, volume, BPM, active preset, effect chain and tuner. It also has a persistent settings menu. The work sits on top of an open-source project that handles USB enumeration and most of the protocol; my code is layered onto it at build time, and upstream is restored to a pristine state afterwards.

I designed the whole product around it, including a production-grade multi-material 3D-printed enclosure: a carbon-fibre-reinforced PLA shell, a soft TPU lock that makes the lid snap on to cover the USB cable, and a soft TPU pad that holds the Tonex pedal in place without scratching it.

I run a smart-home system on an Orange Pi. The devices each speak a different MQTT protocol dialect: Shelly and Tasmota send JSON, plain ESP relays send strings, and some sensors split readings across per-attribute topics.

I wrote a Python bridge that acts as an MQTT client and translator. It subscribes to every device’s status topic, normalises the vendor payloads into one state schema, holds live state in memory, and exposes it over a REST API.

This makes things easy for the frontend — it uses the unified API and doesn’t care about the device protocols. I add the device to one config file, specifying the MQTT topic it uses, and it’s done.

It currently supports:

• lights / brightness / color
• temperature sensors, humidity, lux meters
• thermostatic radiator valves
• door/window sensors

The frontend is a simple app with a main dashboard and a details page with a room layout and charts for selected sensor values.

In addition to off-the-shelf devices, I have a few in my home that I modified to connect to my smart-home system — like the old coffee maker pictured here, which I can turn on and off remotely and whose parameters I can monitor, helping to create an automated recipe for good coffee.

I built a self-hosted code editor that runs in the browser. It has syntax highlighting and a built-in terminal.

I use this app a lot at work — it lets me easily make a to-do list for my tasks, and I can mark them done/not done with the ctrl+space shortcut. When the file has a *.todo extension, it automatically converts any “-“ dash at the start of a line into a visual checkbox.

The editor uses CodeMirror 6 with syntax highlighting for JS/TS, Python, HTML, CSS, JSON and Markdown, and has line numbers, word wrap, live Markdown preview, and themes. The terminal uses xterm.js over a real PTY, with up to two split-pane sessions, full ANSI colour and clickable links. All panels are drag-resizable. A three-pane desktop layout collapses to a stacked mobile view. The terminal panel can be set to full screen, or you can have 2 terminal tabs side by side or split top-and-bottom.

I rebuilt an old VFD-display alarm clock around a Raspberry Pi Zero. The original case holds a 5″ LCD behind the front glass, a display driver, a relay board, and a 5 V power supply, all mounted on a 3D-printed “mainboard”. I added a doppler radar movement sensor and a light sensor behind the factory slots. These drive power saving: display brightness follows the light level, and the screen powers down after a few hours with no movement detected. I designed a 3D-printed panel holding four clicky switches. I wrote the software in Python and drew all the graphics with ASCII characters; the screens include a clock, weather, and a coffee mode to turn on the coffee machine described above.

I have a lot of experience with 3D modeling and printing. I can easily make high-quality mechanical parts — adapters, mounts, brackets, and so on. I also enjoy building enclosures for electronics, or designing more decorative pieces like lamps. For example, I designed and printed most of the structural and mechanical parts of this sim racing rig, including the wheel adapters, TPU pedal springs, LCD dashboard enclosure, paddle shifters and the whole handbrake assembly, which uses a real oil-filled shock/damper to emulate a genuine rally handbrake feel.

I am passionate about bikes, especially the older ones on steel frames. I have restored or built many bikes from scratch; I enjoy working on them and paying attention to the smallest details.