Open to systems, infrastructure & AI engineering roles

Systems software, built to be measured.

Four and a half years on both sides of the same problem. I evaluate AI models and the code they generate. I also build the C++, Python and Linux systems underneath them. The first half means designing adversarial problems and benchmark harnesses that decide whether generated code is actually correct. The second is Cerberus, an agent orchestration runtime I wrote from scratch in C, C++ and Python.

View selected work Download résumé
Arun Kumar
Thanjavur, Tamil Nadu
Software & AI engineering
4.5+ years
Engineering solutions reviewed
270+
Projects built end-to-end
7
01 - Selected work

Software I've designed, built and measured

Three software systems I own end to end, plus the embedded work that taught me how machines actually behave. Every performance number below came off a machine I ran it on. Method and caveats included.

Flagship · Open source 2026

Cerberus AI (formerly IronAgent)

Cross-language AI agent runtime - Python API over a C/C++ execution core

Most agent frameworks inherit the host language's memory behaviour: allocate freely, pause for GC, and pay for it in long sessions. Cerberus moves the hot path below that line. A Python API is bridged through Pybind11 into a C/C++ execution core that runs the Think → Plan → Act loop against a hand-written allocator, so a long-running agent session holds a flat, predictable memory profile instead of a sawtooth.

  • AVX2-aligned arena allocator. Bump allocation at roughly 2 ns per request. That removes per-object free-list traversal from the loop entirely.
  • O(1) context sliding window. A std::deque-backed window prunes agent context in under 0.5 ms, so pruning cost does not grow with session length.
  • Local-first execution. Native FastMCP tool routing and Ollama integration, so agents run sandboxed with no outbound cloud API dependency.
  • Measured against a baseline. Benchmarked versus LangChain on cold-start footprint and orchestration throughput.
C++17C11Python 3Pybind11pthreadsAVX2CMakeFastMCPOllama
Read the architecture & benchmarks Source on GitHub
Distributed systems

Distributed key-value store

Multithreaded in-memory storage engine in C++17

An in-memory KV engine built to survive sustained concurrent load. Reads and writes are served by a thread pool over TCP; durability comes from an atomic commit log; and a custom slab allocator keeps the heap from fragmenting the way a general-purpose allocator does under long-lived mixed-size workloads.

  • Thread-pooled TCP front end with explicit connection lifecycle handling.
  • Atomic commit log for crash-consistent write acknowledgement.
  • Slab allocation to bound fragmentation under heavy read/write mix.
C++17Linux socketsTCP/IPMultithreadingSlab allocator
Protocols & IPC

Zero-copy RPC & binary protocol engine

Compact wire format for cross-process messaging

A binary serialization framework for services that pay too much for JSON. Messages are laid out so the receiving side can read fields in place instead of parsing into intermediate objects. That is where the throughput difference comes from, on the message sizes I tested.

  • Fixed-layout binary framing designed for in-place field access.
  • Roughly an order of magnitude more messages/sec than JSON on my benchmark set.
  • C++ core with Python bindings for mixed-language service meshes.
C++PythonBinary wire protocolIPCSerialization
Concurrency

Multithreaded TCP server with a thread pool

Bounded-resource connection handling in C++17

The naive TCP server spawns a thread per client, which means a thousand clients cost roughly eight gigabytes of stack before any work happens. This one keeps a fixed pool of workers behind a mutex-guarded task queue, so resource usage is flat and predictable no matter how many connections arrive.

  • Thread-safe FIFO queue with condition variables. Workers sleep rather than spin.
  • RAII throughout: every worker joins cleanly on destruction, on any exit path.
  • std::optional as the shutdown signal, so teardown needs no exceptions.
C++17POSIX threadsLinux socketsCondition variablesRAII
Details Source on GitHub

Foundations - where the systems instincts came from

Before the software work, I spent years on hardware that gives you no abstractions to hide behind. It's the reason I reach for a debugger and a measurement before a rewrite.

  1. 2024Vector India

    Body control module - CAN bus distributed system

    Multi-node real-time control architecture in Embedded C/C++ handling bus arbitration, message scheduling and fault behaviour under concurrent load and RTOS timing constraints.

    Embedded CCANRTOSState machines
    Details
  2. 2025STM32F429I

    Bare-metal game engine with a predictive opponent

    An FSM-driven engine on ARM Cortex-M4 with no RTOS, middleware or HAL. That includes hand-written SPI/I2C drivers for the ILI9341 display and STMPE811 touch controller, and a hunt-and-target opponent seeded from the hardware RNG.

    Embedded CCortex-M4SPI / I2CLTDCSDRAM
    Details Source
  3. 2024STM32F429I

    Clock tree & peripherals from first principles

    RCC/PLL configuration written from the reference manual to drive the core at its maximum rated frequency, with register-level peripheral drivers and SysTick-based millisecond scheduling, verified on ST-Link and a logic analyser.

    Embedded CRCC / PLLSysTickST-Link
    Details
  4. 2022Raspberry Pi

    Assistive doorbell with on-device inference

    An object-detection pipeline running on edge hardware, built specifically for deaf users. Alerts go out as visual and push notifications over IFTTT webhooks. Never audio.

    PythonObject detectionNumPyWebhooks
    Details
02 - Evaluation practice

Finding where code - and models - actually fail

The other half of my work. I design problems engineered to break frontier models, run them in sandboxed harnesses, and review the output at volume against production engineering standards. Building systems and judging them turn out to need the same instincts.

  1. 01

    Design the adversarial problem

    Multi-step Python problems and edge-case scenarios built to expose failures in reasoning, context-window management and logic execution. Not trivia. Work a competent engineer would still have to stop and think about.

    PythonEdge casesLong context
  2. 02

    Sandbox the runtime

    Test environments and execution runtimes containerised in Docker, so model-generated code runs isolated and reproducibly against strict unit-test suites that decide pass or fail without a human in the loop.

    DockerLinuxUnit tests
  3. 03

    Evaluate and rank

    Output in Python, C++ and C debugged and ranked on time/space complexity, memory leaks and production coding standards. Chain-of-thought traces get audited too, for logical fallacies and improper library usage.

    C++CCoT auditingComplexity
  4. 04

    Automate the regression

    Local Python drivers inside those containers automate prompt evaluation, regression testing and hallucination detection across model checkpoints. A behaviour fixed in one release should not quietly regress in the next.

    HarnessesRegressionCheckpoints

Coding agents, compared

Benchmarked head-to-head on complex systems tasks.

  • Claude Code
  • Gemini CLI
  • Cursor
  • GitHub Copilot
  • ChatGPT / Codex

The question is never which one feels faster. It is which one still holds up when the task has concurrency, memory ownership or protocol state in it. That only shows up in correctness and scalability numbers.

Review at volume

What 270+ reviewed solutions looks like in practice.

270+ Solutions reviewed 150+ at Ecademic Tube, 120+ at Outlier
5 Coding agents benchmarked Measured on the same systems tasks
6 Languages assessed Python, C++, C, MATLAB, Verilog, Embedded C

Concurrency bugs, race conditions, memory-management defects and architectural tradeoffs across OS, networking and infrastructure code. Plus written documentation on the debugging workflows behind the findings.

03 - Under the hood

How Cerberus AI is put together

One deep dive. The architecture, the numbers, the method behind them, and what is still wrong with it.

Execution path

A single agent step, from Python call to arena write.

Python agent API define tools · run(task) Pybind11 FFI bridge GIL release · marshalling C++17 orchestrator Think → Plan → Act loop scheduler · retry · dispatch FastMCP tool routing C11 memory core AVX2-aligned bump arena O(1) context sliding window Ollama local LLM state returned

The GIL is released across the bridge, so the C++ loop and Python callers do not serialise on each other. Everything below the bridge allocates out of the arena. No per-step malloc traffic. No garbage collector to pause the session.

Measurements

Cold-start resident memory, Cerberus versus LangChain on the same task.

Cerberus AI
208 MB
LangChain
424 MB

Cold-start RSS, lower is better. Same task, same machine, measured at process steady state after first agent step.

~2 ns Arena allocation Bump pointer, AVX2-aligned
< 0.5 ms Context prune O(1), independent of history length
272k+ Hot-loop ops/sec Core state machine, single thread
Method & caveats

Numbers were taken on my own Linux workstation, not a controlled lab. RSS was sampled after the first completed agent step so that lazy imports and model client initialisation are included on both sides. Allocation and prune timings are medians over repeated runs inside a warmed process. They are directionally reliable and I can reproduce them on request. But they are single-machine figures, and I would not present them as vendor benchmarks.

What's still wrong with it

The roadmap, stated plainly.

Known bottleneck

The FFI boundary is the ceiling

Pybind11 copies at the Python↔C++ boundary. Once the core got fast, that copy became the dominant cost in the hot path. The arena wins are partly spent crossing back out. Profiling shows it clearly, and it is documented rather than hidden.

In progress

Zero-copy buffers for v1.1

Moving the boundary to the Python buffer protocol so large tensors and context blocks are viewed rather than copied. The arena is already aligned for it; the work is in lifetime management across the boundary.

Scope

Single-node by design, for now

Cerberus orchestrates on one machine. Distributing the loop means solving state handoff and partial failure. That is real distributed-systems work, not something to bolt on to claim a feature.

04 - How I work

Engineering principles I actually apply

01

Measure before you optimise, and publish the method

A number without a method is marketing. I benchmark against a named baseline on a stated machine, keep the harness in the repo, and say plainly when a result is single-machine rather than rigorous.

02

Own the memory story

Most latency tails I have chased came from allocation behaviour, not algorithms. Arenas, slabs and explicit lifetimes make performance predictable. They also make ASan and Valgrind output meaningful instead of noisy.

03

Concurrency is a design decision, not a keyword

Threads, mutexes and lock-free structures each buy something and cost something. I pick based on contention shape and failure mode, and I have debugged enough races to respect the ones I cannot see.

04

Read code the way a reviewer reads it

270+ reviewed solutions taught me to look for edge cases and architectural cost before style. That habit changes how I write: smaller surfaces, explicit failure paths, and comments that explain the constraint rather than the syntax.

05 - Track record

Experience

Four and a half years of building software, and reviewing a great deal more of it.

  1. Jun 2026 - PresentRemote · Freelance

    Software Engineer

    HandShake AI

    Building the adversarial test surface used to find where frontier models break on real engineering work.

    • Design multi-step Python problems and edge-case scenarios engineered to expose failures in model reasoning, context handling and logic execution.
    • Containerise test environments and execution runtimes in Docker to isolate, reproduce and benchmark model-generated code against strict unit-test suites.
    • Evaluate, debug and rank model output in Python, C++ and C for time/space complexity, memory leaks and production coding standards.
    • Build local Python drivers inside Linux containers to automate prompt evaluation, regression testing and hallucination detection across model checkpoints.
    • Audit chain-of-thought traces for subtle logical fallacies, edge-case failures and improper library usage.
    PythonC++DockerLinuxBenchmarking
    What I do at Handshake AI
  2. Jun 2025 - Aug 2026Remote

    Software Engineering Consultant & SME - Code Review, Architecture & Benchmarking

    Ecademic Tube

    Reviewing systems-level software at volume, and writing down what separates the correct implementations from the merely working ones.

    • Reviewed 150+ engineering solutions in C++, Python and Linux systems: correctness, edge cases, performance bottlenecks and implementation quality against professional standards.
    • Assessed systems code for concurrency bugs, race conditions, memory-management defects and architectural tradeoffs across OS, networking and infrastructure domains.
    • Benchmarked coding-agent output (Claude Code, Gemini CLI, Cursor, GitHub Copilot, Codex) to quantify differences in correctness and scalability on complex systems tasks.
    • Authored technical documentation on Linux programming patterns, concurrency debugging workflows and systems-level problem solving.
    • Reviewed and annotated embedded code in MATLAB, Verilog and Embedded C for functional and logical correctness.
    Code reviewC++PythonConcurrencyArchitecture
    The review & benchmarking work
  3. Jan 2025 - May 2025Remote · Freelance

    AI Training Contributor

    Outlier.ai

    Code review at volume for a model-training pipeline. This is where reviewing first became a measurement discipline rather than an opinion.

    • Reviewed and debugged 120+ C++ submissions for an AI model training platform, judging correctness, logic and adherence to coding standards.
    • Fed structured technical assessments into fine-tuning and evaluation datasets, supporting model reasoning and response-quality improvements.
    • Took on generalist evaluation tasks beyond code as part of a distributed contributor pool, contributing to broader training-data quality.
    C++Code reviewModel trainingEvaluation
    What I did at Outlier
  4. May 2024 - Dec 2024Chennai

    Embedded Systems Engineer - Training & Project

    Vector India

    A full-time professional programme in embedded systems, Linux programming, RTOS, C++ and TCP/IP networking, ending in a distributed control project.

    • Studied the TCP/IP stack from socket programming through transport-layer behaviour and connection management.
    • Designed and implemented a distributed real-time control system with multi-node CAN communication: bus arbitration, message scheduling and fault handling under concurrent load.
    • Developed state-machine control logic in Embedded C/C++ coordinating node behaviour under RTOS scheduling constraints.
    LinuxRTOSTCP/IPCANC++
    Programme, syllabus & certificate
  5. May 2022 - May 2024Remote / on-site

    Hardware & Firmware Specialist

    Self-employed

    Chip-level diagnostics and firmware recovery. The work that built my instinct for hardware-software interfaces.

    • Component-level failure analysis on laptop and desktop hardware, tracing faults through power delivery, memory subsystems and peripheral interfaces with multimeter and oscilloscope.
    • BIOS firmware programming and optimisation: flashing images and resolving boot-sequence failures from corrupted or misconfigured firmware.
    • Data recovery and functional restoration through structured fault isolation.
    FirmwareBIOSDiagnosticsSignal debuggingIntelAMDApple
    What I did in this period
Degree

B.E., Electronics & Communication Engineering

Kings College of Engineering (Autonomous), Punalkulam - affiliated to Anna University, Chennai

Jul 2018 - Mar 2022 · CGPA 8.26 · First Class

College, batch & grades
Certification

Advanced Course in Embedded Systems

Vector India, Chennai - Perungudi centre, full-time programme

May 2024 - Dec 2024 · Certified

Programme & certificate
06 - Capability

Technical skills

Ordered by how central each area is to the software I build day to day.

Languages

Core
  • C++ 17 / 20 / 23
  • C C11
  • Python 3
  • Embedded C
  • CUDA C++

AI & agent infrastructure

Core
  • Pybind11 cross-language bridges
  • FastMCP tool orchestration
  • Local LLM runtimes Ollama
  • Think-Plan-Act architectures
  • Claude Code · Cursor · Copilot · Gemini CLI

Systems & OS

Core
  • Linux system programming
  • OS internals
  • POSIX API
  • Memory management arena, slab
  • System debugging

Concurrency

Core
  • Multithreading
  • pthreads
  • Mutexes & semaphores
  • Race & deadlock debugging
  • RTOS scheduling

Networking

Applied
  • TCP/IP networking
  • Socket programming
  • Protocol stack internals
  • Binary wire protocols
  • IPC & RPC

Performance

Applied
  • AVX2 SIMD vectorisation
  • CUDA GPU acceleration
  • Cache-aware data layout
  • Profiling & benchmarking
  • Complexity analysis

Tooling & infrastructure

Daily
  • GCC toolchain · GDB
  • CMake
  • Valgrind · AddressSanitizer
  • Docker
  • Git & CI/CD pipelines

Testing & quality

Daily
  • Software testing & validation
  • Unit & regression suites
  • Code review at scale
  • Architecture assessment
  • NumPy · Pandas for analysis

Embedded & hardware

Foundation
  • ARM Cortex-M4 · STM32
  • Bare-metal register programming
  • SPI · I2C · LTDC · SDRAM
  • CAN protocol
  • BIOS firmware · chip-level diagnostics
07 - Contact

Let's talk about systems worth building

I'm open to systems, backend and AI-infrastructure roles. Happy to walk through any benchmark on this page, including the parts that aren't finished.