The systems builder for hard problems.
AI infrastructure, graph systems, developer tools, and software worth shipping.
▲ Projects, agents, graphs, caching, systems, security, and developer tools.
📜 WORLD MAP · TABLE OF CONTENTS
| 🌲 Spawn Point | 🎒 Inventory | ⚒️ Crafting Table |
| ⛏️ How I Build | 🧱 Projects | 🧰 Tech Stack |
| 🟩 Quest Log | 🏆 Achievements | 📊 World Stats |
| 🧪 Rules of the World | 🗺️ Current Coordinates | ✉️ Connect |
|
I'm Rohit Maruri — a CS student and obsessive builder who likes taking difficult engineering problems and turning them into systems that actually run. I'm especially interested in the layer underneath the UI: data models, graph traversal, retrieval, agents, caching, testing, observability, security, and failure modes. The projects I build tend to start with a question that sounds deceptively simple:
Then I disappear into the cave for a while. |
Current biome: AI × infrastructure |
I love the moment where something that was only an idea becomes a working system — especially when the system has enough depth that you can keep pulling on the thread and discover another interesting problem underneath it.
No fake demos. No hand-wavy architecture. No hiding the hard parts.
Everything currently sitting in the hotbar — the systems I have built, broken, rebuilt, and learned from.
| 💎 RARE ITEM · BLAST RADIUS | 🧠 EPIC ITEM · VIVEDLY AI |
|---|---|
|
Dependency intelligence for security teams. A graph-based system for answering the question that matters after a dependency compromise: what is actually exposed? It traverses transitive dependencies, resolves semver ranges, checks OSV, and turns the resulting graph into actionable remediation paths.
|
A proactive AI desktop coworker. Instead of waiting for a prompt, Vivedly watches the work context and tries to surface the next useful action — with layered memory, MCP tools, streaming voice, and native desktop control.
|
| 📈 EPIC ITEM · MERIDIAN | ⚡ UNCOMMON ITEM · SEMANTIC OUTPUT CACHE |
|
An AI-native financial terminal. Fifteen views, options priced with Black-Scholes, and tax lots represented individually because financial software should preserve the information required to make correct decisions.
|
Caching for the way humans actually talk to LLMs. Exact-match caching assumes users phrase the same request twice. They don't. Semantic similarity turns repeated intent into a cache hit.
|
AI agents · MCP tooling · developer infrastructure · security systems · graph data · semantic retrieval · financial systems · desktop applications · performance experiments
Ideas are cheap. The interesting part is what happens between the idea and the shipped system.
| 🪵 RAW MATERIAL Find the real problem. Talk to the constraints. Remove assumptions. |
🧱 BUILD PLAN Choose the data model. Define boundaries. Make failure explicit. |
⚙️ REDSTONE Wire the system. Instrument it. Test the ugly paths. |
💎 DIAMOND Measure the result. Polish the rough edges. Ship it to reality. |
Model first. Build second. Measure always.
If the architecture cannot answer the important question, it doesn't matter how good the UI looks.
If the benchmark isn't measured, it's a claim.
If the failure mode isn't tested, it isn't finished.
I try to get underneath the first formulation of the problem. The best engineering work usually appears when the obvious implementation is questioned.
Data model, interfaces, invariants, boundaries, failure modes. Before the code gets large, I want to know what the system means.
Connect the components. Add instrumentation. Build the smallest useful path. Then intentionally stress it.
Benchmark it. Remove unnecessary work. Improve the developer experience. Add the boring safeguards that become invaluable later.
Ship. Get real feedback. Learn what was wrong. Return to the crafting table.
┌───────────────┐
│ PROBLEM │
└───────┬───────┘
↓
┌───────────────┐
│ MODEL │
└───────┬───────┘
↓
┌───────────────┐
│ BUILD │
└───────┬───────┘
↓
┌───────────────┐
│ TEST │
└───────┬───────┘
↓
┌───────────────┐
│ MEASURE │
└───────┬───────┘
↓
┌───────────────┐
│ SHIP │
└───────┬───────┘
│
└──────→ LEARN → back to PROBLEM
Four builds from the world: civic intelligence, supply-chain security, autonomous software repair, and safe agentic change control.
|
The problem: neighborhood information is scattered across city-hall packets, news sites, emergency feeds, maps, and group chats. The build: a neighborhood operating system for Fremont. Two Strands agents on Amazon Bedrock AgentCore crawl and retrieve public records, generate short updates with numbered citations, power context-aware chat, and refuse to publish claims that fail evidence checks. The engineering loot: Next.js, React, TypeScript, Python, FastAPI, Aurora DSQL, S3 Vectors, BM25, Google Maps, Rekognition, AWS Amplify. What I learned: useful AI is not a chat box. It is retrieval, provenance, verification, trust boundaries, and a product people can actually use. |
The problem: when an npm package is compromised, a dependency list cannot answer who is actually exposed—or which semver ranges would have pulled the poisoned version. The build: a graph-based supply-chain incident console that traverses transitive dependencies five levels deep, evaluates every declared range, checks live OSV data, draws the blast radius, and generates concrete remediation paths. The engineering loot: Python, FastAPI, HydraDB, OpenCypher, SQLite, Docker, OSV, SSE, and a no-build-step frontend. What I learned: the data model decides which security questions are cheap to answer. Graph shape is not an implementation detail; it is the product. |
|
The problem: AI can ship a page in seconds, then leave behind missing security headers, open admin routes, leaked keys, inaccessible images, and nobody responsible for fixing them. The build: a software factory that keeps checking the applications it creates. FORGE discovers security and quality findings, classifies whether a fix is safe, writes the code and its test, re-checks the result, and opens a pull request for a human to approve. The engineering loot: Python 3.14, FastAPI, Bright Data Scraper Studio, SigNoz, OpenTelemetry, traced workflows, and a verified test loop. What I learned: autonomous repair needs a loop, not a one-shot prompt: inspect → reason → write → prove → ask. |
The problem: asking a human to approve an agent's production change before showing whether it is reversible turns approval into a trust ritual. The build: a change-control system that executes proposed changes against a throwaway copy of real data, rolls them back, checksums before/after/after-rollback state, measures blast radius, and only then asks for human approval. The agent can propose, but it has no tool that writes to production. The engineering loot: TypeScript, React, Next.js, Node.js, Postgres, MCP, TrueForge, policy-as-code, shadow verification, tamper-evident receipts, and 347 passing tests. What I learned: safety is strongest when it is a gate enforced by evidence—not a sentence in a prompt and not a button rendered too early. |
Each build asks the same question in a different biome:
Can the system prove what it knows, what it changed, and why a human should trust the next step?
Python · TypeScript · JavaScript · SQL · Cypher · React · Next.js · Electron · FastAPI · Node.js · PostgreSQL · pgvector · SQLite · Redis · Docker · MCP · LLMs
╔══════════════════════════════════════════════════════════════════════╗
║ QUEST LOG ║
╠══════════════════════════════════════════════════════════════════════╣
║ ║
║ [✓] Build systems that solve real problems ║
║ [✓] Learn by shipping ║
║ [✓] Break things → understand them → rebuild them better ║
║ [✓] Build with AI without treating AI as magic ║
║ ║
║ [→] Go deeper on agent infrastructure ║
║ [→] Build stranger, harder developer tools ║
║ [→] Explore distributed systems and reliability ║
║ [→] Make security tooling easier to use ║
║ [→] Keep finding problems worth obsessing over ║
║ ║
╚══════════════════════════════════════════════════════════════════════╝
Agentic systems · Graph databases · AI infrastructure · Developer experience · Semantic retrieval · Distributed systems · Security tooling · Human-computer interaction
| 🟩 BUILD FIRST Learn by making the thing. |
💎 MODEL THE HARD PART Make the system reflect reality. |
🔥 BREAK YOUR OWN CODE Find the failure before users do. |
| 01 · Real data beats pretty demos. If the number came from nowhere, the number is lying. | 02 · Architecture should answer questions. A diagram is useful only when the system can actually support it. |
| 03 · Tests are part of the feature. The boring edge case is usually the one waiting in production. | 04 · Security starts in the model. Trust boundaries and failure paths belong in design. |
| 05 · Measure before claiming. Fast, scalable, reliable — each deserves evidence. | 06 · Curiosity is a technical skill. Getting stuck is fine. Staying stuck because you stopped digging isn't. |
╔══════════════════════════════════════════════════════════════╗
║ WORLD SOFTWARE ║
║ BIOME AI / INFRASTRUCTURE ║
║ X developer tools ║
║ Y systems depth ║
║ Z somewhere between "this should work" and ║
║ "why is the database doing THAT?" ║
║ ║
║ WEATHER ☀ curious ║
║ DIFFICULTY hard ║
║ INVENTORY full ║
║ NEXT MOVE build ║
╚══════════════════════════════════════════════════════════════╝
- How agents become genuinely useful software rather than chat wrappers.
- How graph structures can make security and dependency reasoning easier.
- How semantic systems can make AI infrastructure cheaper and faster.
- How to design developer tools that feel obvious once they exist.
- How to keep ambitious systems understandable as they grow.
