Just a regular chat with Yahia from my student org one day, about how important and rare it is to see someone getting to the fundamentals of engineering masterpieces. being chronically into AI, we thought about the natural intersection where llms and swe meet -- vector databases, and their beautiful challenge of retrieval + indexing.
That little curiosity and ambition to explore the fine arts of engineering is what really kicked me into rust.
One of my coworkers at work told me to read this book and really emphasized it. I'm glad he did, because without that push I probably wouldn't have gone down this rabbit hole.
After a lot of web dev and AI work, I finally picked up Designing Data-Intensive Applications.
This book was honestly like a bible of data-intensive applications. it genuinely opened my eyes to how beautiful engineering gets the harder the problem goes. it made me see how non-deterministic systems are in practice, and how deep the field gets once you care about reliability, consistency, and scale.
This book and learning rust at the same time is just chef's kiss.
That's where I really fell in love with lower-level engineering work.
Rust
I didn't have low-level language experience, so after some research I picked Rust cuz it sounded cool and it's new. that ended up being one of my best decisions. rust taught me how much tiny implementation details matter when performance and safety both matter. the learning curve was steep, and honestly still is. I'm still learning new Rust concepts almost every day. there are often multiple valid ways to solve the same problem, which is exciting but also confusing when you're trying to choose the best approach.
I started with smaller projects, just to warm up before working on a bigger one -- an ecommerce backend, CLI tools, and some memory-mapped storage experiments. those helped me get comfortable with the syntax and with Rust's way of thinking across different use cases.
Learning Rust felt like learning a different programming world. ownership, borrowing, lifetimes, and memory models forced me to think differently.
I also found Rustfinity, which helped a lot with hands-on learning. I've always liked practical platforms like boot.dev, and Rustfinity gave me that same "learn by doing" feeling.
Ownership and lifetimes were the hardest part for me. I spent a lot of time repeating tutorials and exercises until it finally clicked. once it did, I started appreciating how clever Rust's safety model is.
Databases
I knew vector databases long before this project. I had used them a lot in Python projects, especially for hackathon slops.
Over time I worked on more than just basic retrieval. I dealt with ranking quality, hybrid search routing, pipeline integrations, and different retrieval strategies. but all of that was from the user side, not from the "build the engine" side.
One thing I found beautiful about databases is how differently people use them. one person calls them through a Python client, another through npm, another through direct APIs in production systems. the same core engine has to serve very different needs, workloads, and expectations.
I read a lot from qdrant, chroma, pgvector, and helix. each one has a different design focus and tradeoff profile. Helix in particular seemed very focused on agentic and MCP-heavy workflows, which moved me toward understanding how agentic memory works.
Seeing how differently these systems approached similar problems was super useful. it made me realize there's no single "perfect" design, only designs that are good for specific constraints.
Even though many of these products solve real problems, I wasn't thinking about differentiation in startup terms. I just wanted to build systems because I genuinely enjoy the engineering side.
At some point I kept thinking about retrieval latency in real products. even if each component is fast individually, the end-to-end flow can still feel slow: database lookup, network round-trips, and application logic all add up.
So I went deep into the internals of memory management, storage layouts, index behavior, and search mechanics. that rabbit hole was intense and honestly addictive.
I also got confused by the word "kernel" because it means different things in different contexts. in deep learning classes it can mean convolution kernels, in OS it means the operating system kernel, and in systems programming it means code executed on a compute unit. once I separated those meanings, things got clearer.
I didn't want to jump fully into CUDA while still getting comfortable with Rust, so I started exploring Rust-friendly paths, just to build intuition first.
Most people go from theory to applications, then build something with them. I went the opposite direction. I started building AI agents, which pulled me into RAG systems, which pulled me into embeddings and transformers. each layer dragged me deeper into the one below it.
By the time I was studying transformer architectures in DAT 494 (Advanced Deep Learning) at ASU and learning about language models from scratch, a lot of these systems ideas finally started clicking into place.
Can't stress this enough: professor Steffen Eikenberry has to be the GOAT professor for this class, which only existed for a semester. it has to be the most challenging class i've done so far, with so much knowledge that maps to real-life application.
I was jotting things down on Excalidraw, thinking through architecture, data flow, storage layout, indexing strategies, search paths, API shape, CLI flow, caching, collection lifecycle, consistency, durability, backup/restore, observability, deployment, and scaling. at every step I noticed how sequential it was.
I'm still building this, and i think it'll exist for a while and i'll keep building on it.
so far i've shifted from a vector-database-centric solution to the attention core of the LLM side, such as a fusion kernel in CUDA.