My work has gradually shifted my attention from individual models toward the architecture of complete AI systems. I am interested in how data and context move through them, how components communicate, where latency accumulates, how they behave under failure, and which choices separate a promising prototype from a reliable product.
One level above
I want to understand how to build systems that scale: distributed systems, infrastructure, reliability, observability, data movement, and the decisions required to serve real users.
A model can be impressive in isolation while the surrounding product remains unreliable. Retrieval can become stale. Context can be assembled incorrectly. A downstream dependency can dominate latency. A retry can multiply cost. Without observability, all of this can be invisible until a user encounters it.
One level below
At the same time, I want to move below my current abstraction—to understand CPUs and GPUs, memory hierarchies, inference engines, kernels, compilers, and the optimizations that determine how efficiently a model runs.
At this level, “the model is slow” stops being an explanation. The question becomes more concrete: is the workload compute-bound or memory-bound? Which operations dominate? What is moved, cached, fused, quantized, or recomputed? What does the hardware make cheap, and what does it punish?
I want to follow an AI system from how a model learns, through the architecture surrounding it, down to how its operations execute on hardware.
Then upward again
The point of going downward is not only intellectual completeness. It is to return upward with better engineering judgment—to build a dependable product used by real people, with a clearer understanding of the trade-offs hidden at each layer.
This is the map I will use to organize much of my learning: model, inference, hardware, infrastructure, product, and user. Each layer changes the constraints of the one above it.