There's a boundary in software engineering where the abstractions stop working. It's the place where your process management code hits the Linux kernel's scheduler, where your provider routing hits a real rate limit, where your FUSE mount hits the filesystem's actual behavior. Most software is written above this boundary, relying on abstractions that usually hold. I choose to work at the boundary itself.
What the boundary looks like
When I built ShareCLI — a Rust runtime for observing and coordinating hundreds of concurrent AI coding agents — the boundary was everywhere. Process observation required understanding how the kernel reports process state. FUSE-backed views required understanding how the filesystem actually behaves under concurrent access. Thermal pressure monitoring required understanding how hardware throttling affects user-visible performance.
The abstractions don't hide these details. They expose them. The engineering challenge is deciding which details matter for the user-visible behavior and which are noise.
Why systems work is different
Application-level engineering is about features, UX, and business logic. Systems engineering is about constraints, failure modes, and observable behavior under load. The skill set overlaps but the mindset is different.
When I built Substrate's provider routing layer — an OpenAI-compatible dispatch gateway with SSE streaming, token-bucket rate limiting, full-jitter retry, circuit breakers, and budget enforcement — every design decision was shaped by real provider behavior. Anthropic's TPM behavior differs from OpenAI's RPM behavior, which differs from Groq's burst handling. The system had to be correct under all of these behaviors simultaneously.
This isn't a theoretical exercise. When a provider fails at 3 AM, the system needs to degrade gracefully, route around the failure, and maintain latency budgets — all without human intervention. The engineering that makes that work lives at the boundary between your routing logic and the provider's actual behavior.
The verification problem
The hardest part of systems work isn't building the system — it's verifying it works. Application code can be tested with unit tests and integration tests. Systems code needs to be tested against real hardware, real providers, real concurrent load, and real failure modes.
When I built phenotype-omlx — an Apple Silicon inference research fork with Rust performance cores and multi-backend routing — the verification required running actual inference workloads across MLX, Metal, C, Rust, Zig, Mojo, and Nim backends. Each backend had different memory bandwidth characteristics, different quantization behaviors, and different concurrency limits. The evaluation harness had to measure real performance, not synthetic benchmarks.
This is why I value evidence-led engineering. Every claim about system behavior needs to be backed by observable evidence. The evidence ledger approach — documenting what was observed, when, and under what conditions — isn't bureaucracy. It's the only reliable way to verify that a systems-level claim is true.
Why I choose this work
Working at the boundary is harder than working above it. The failure modes are more complex. The verification is more difficult. The debugging requires understanding multiple layers of the stack simultaneously.
But the work is more interesting, and the decisions are more consequential. A well-designed routing layer affects every request that passes through it. A well-designed process observer affects every agent that runs on the system. Decisions there carry further, and the lessons transfer across projects.
That's where I build. At the boundary. Where the abstractions stop and the real behavior begins.