// SYSTEM_PROFILE :: ROBERT_SENENKO
I bridge hardware and software: from hardware repair and testing to the infrastructure that runs on top. Along the way I build my own AI-powered tools and automation.
// Where I have worked
// Profile Overview
// The bench
For over 25 years I've repaired electronics at component level, including in the MSI, GIGABYTE and Acer service centres. Laptops and graphics cards: from power circuits and motherboard electronics to VRAM diagnostics and performance testing. Here AI helps me analyse schematics and test repaired hardware.
// Code and DevOps
I write mostly in Python, plus Bash and PowerShell scripts. I build infrastructure from code: Proxmox installed from an answer file, servers hardened with Ansible, monitoring on Prometheus and Grafana, CI pipelines run locally.
// My own projects
Beyond service work I run my own projects, and that is where I learn fastest. I build tools with AI, but I check the result myself before I call anything working.
// Hardware → DevOps
I check power rails and signals methodically, from VRAM to GPU. I debug systems the same way, from the physical layer to application logs.
BGA rework gives you no second try, so my tools would rather refuse than do half the job: bios-builder will not flash a partial repair, and the playbook will not lock down SSH without a key in place.
On the bench the verdict comes from the scope, not a hunch. I check infrastructure changes the same way, in numbers: hardening a server raised its Lynis score from 66 to 78, and an alert follows a failure in 2 min 18 s to 2 min 37 s (five measured runs).
// Experience
2018–present
Hardware specialist at Pro-Syl, where code and automation became part of the job. Today I design my own AI-assisted tools that cut the daily work down: automated hardware tests that end in a PASS / WARN / FAIL verdict, answer files and install media, automated server hardening, monitoring that measures its own reaction time, and CI pipelines run locally.
2010–2018
Component-level service engineering: Acer Central Service EMEA (L3/L4 board diagnostics), then automotive electronics (Preh Car Connect).
2004–2010
Authorized MSI Service and leading GIGABYTE graphics-card repair: advanced BGA/SMD, QA stress-testing, SLA and throughput optimization.
1992–2002
The foundation: electronics technician, first years in electronics (Micromax) and engineering studies in Wrocław.
click a knob · Shift + click: back
// bench → production
bench-scope liveThe same signal at both ends of the same job: from a probe on the board to a graph in Grafana.
// Skill Set
Three areas: from the physical layer, through infrastructure, to AI tools and automation.
S/N: HW-2N04
// physical layer
Diagnostics
Repair
Measurements
Software
S/N: DEVOPS-1X
// digital layer
Infrastructure
Containers and CI/CD
Config automation
Monitoring and security
S/N: AI-07
// digital layer
My own tools
Models, agents and RAG
AI security
// CI run
Not a simulation. Most projects here ship their own GitHub Actions pipeline, and I run all of them locally in act before anything reaches a remote. Below is the real run, together with how the same pipelines did the first time.
14 of 15 jobs green, none failed, and 1 act limit: lap-diag-tool's windows-latest job, which act does not run at all. 3 min 33 s in total: act runs the jobs one after another, while on GitHub these pipelines are independent of each other.
act, catthehacker/ubuntu:act-latest with 7-Zip and sqlite3 added · durations straight from the run log
// What I work with
// the same four layers as the diagram up top, broken down into components, from physical to AI
L1
L2
L3
L4
// Projects and deployments
// Firmware
Firmware recovery from a dead BIOS chip. From a damaged chip I rebuild a working image, correct for that specific board and structurally consistent, on Intel as well as AMD. The tool also drives the SPI programmer, so reading the chip and writing the finished image happen in one window. The feature set is closed, only the number of supported models keeps growing.
// Boot media
I build bootable GPU test media. On the NVIDIA side four partitions chainloaded by GRUB4DOS, from GTX 10xx and older up to RTX 50xx, each carrying TinyCore, the driver build for that card, and NVIDIA's own factory diagnostics (MATS, MODS, NVMT) that exercise memory, L2 cache, GPC/TPC and the video engine. On the AMD side a whole-disk image with my own menu, narrowed to AMD cards, RX4XX through RX7XXX and Vega. I don't write the tests, they are the vendors' tools. What is mine is the craft around them, the partition layout, the bootloader, the menus, and booting every image in QEMU before it touches a stick.
// Board repair
Asked about a part no board has, it does not ask the model, it refuses and says what it did not find. When the model does answer, every name and every source the catalogue facts did not contain gets a red banner. Underneath, a private database of schematics, boardviews and datasheets for board repair, with a board view linked to the chat, pins from the manufacturer's tables, and similar bench cases sent from a phone through a gateway that can only append. The whole RAG stack runs locally, Ollama on my own GPU, no vector database, just SQLite and numpy. No schematic ever leaves the machine.
// Laptop QA
Laptop diagnostics from scan to document: the configuration read automatically, functional tests (USB, camera, audio, keyboard, screen, disk and battery, GPU stress), a PASS/WARN/FAIL verdict and a printable service sheet. The record lands in a registry, a SQLite database in a container on Proxmox, searchable by serial, so you can tell whether a machine has been here before.
// Boot media
I build WinPE images on Ubuntu Server and pick .inf drivers by the target machine’s real PCI hardware IDs, read from lspci. Injection goes through wimlib straight into boot.wim, no ISO remastering, and the machine boots over the network through iPXE and wimboot. The PXE server works alongside the router already handing out addresses instead of replacing it. Before the server starts, the tool checks what already answers on the network.
// Boot media
A config-driven engine that assembles bootable service media: adding a tool is a JSON entry, not a code change. It builds my diagnostic USB: TinyCore, Memtest86+, FreeDOS for vendor flashers and Bench-Live, my own test menu: PCIe AER counters, bpftrace, CPU stress, memtester, temperatures, SMART. It writes the image straight to a disk or onto a Ventoy stick.
The estate
← swipe the map →
// Comms Channel
Looking for someone who knows electronics, servers and AI-driven automation? Write about a job, a project, or just with a question. I answer plainly.
Status: open to work. E-mail address: kontakt@robisolutionsit.com.
kontakt@robisolutionsit.com