HN user

varshith17

30 karma

Data Engineer @GS, Researcher working on Deterministic AI Memory. Author of Valori.

Posts7
Comments30
View on HN

"Best place to work" awards are marketing, not data. No company that's actually great needs to advertise it their employees do that for them. When you see these plastered everywhere, it usually means they're compensating for something (turnover, bad Glassdoor reviews, competitive market). At the end of the day, trust employee retention rates over PR campaigns.

2 days is nothing, VCs move slower than founders think. Demo review usually takes 1-2 weeks: partner watches it, discusses in Monday meeting, maybe loops in domain expert, then decides next steps. Silence for a week is normal. Silence for 3+ weeks without follow-up means soft pass. If you haven't heard anything in 10 days, polite check-in is fine.

Not just you, widespread reports on /r/gmail and Twitter since ~12 hours ago. Likely a bad model push on Google's end. Workaround: check spam folder for legit mail, mark as "not spam" + star important senders to retrain your filter faster. Usually resolves in 24-48h when they rollback.

Google's spam filter is having a moment. Even emails with perfect auth records are getting flagged - clearly a broken model deployment. Mark legitimate emails as "not spam" aggressively. They'll either rollback or your local filter will adapt. This happens every 6-12 months with Gmail.

Build validation layers, not trust. For structured outputs (invoices, emails), use JSON schemas + fact-checking prompts where a second AI call verifies critical fields against source data before you see it. Real pattern: AI generates → automated validation catches type/format errors → second LLM does adversarial review ("check for hallucinated numbers/dates") → you review only flagged items + random samples. Turns "check everything" into "check exceptions," cuts review time 80%.

Concrete setup: (1) All secrets in 1Password/Bitwarden with CLI, (2) Agent sandbox with no env var access, (3) Wrapper scripts that fetch secrets on-demand and inject at runtime, (4) Context scrubbers that strip secrets before LLM sees logs. Key insight: don't prevent agent access to secrets, prevent secrets from entering agent context/logs. Different problem, solvable with tooling.

Anthropic's prompt engineering docs (docs.claude.com) are secretly the best AI coding guide teaches you how to structure requests that actually work. For tactics: search "AI coding workflows" on HN/Reddit, filter for comments with war stories not marketing. The people complaining about what broke have better insights than the people hyping what shipped.

Hardware company LARPing as infrastructure provider. Their wafer-scale chips can't multi-tenant like GPUs, so "enterprise" means "first in line for deprecation" apparently. Cool tech, zero operational maturity. Stick to providers who understand that "enterprise" means contracts, not vibes.

"Agentic coding works" and "ship without review" are two different claims. The first is true for constrained tasks, the second is Silicon Valley brain rot. I use Claude Code daily for DevOps automation and data migrations. Every output gets reviewed. It saves me hours, not judgment.

Bulletproofing from AI is like bulletproofing from Stack Overflow in 2010. Wrong question. The real edge is taste, knowing when the AI's boilerplate is wrong, which shortcuts will bite you at scale, and what "working" actually means in production. LLMs don't have 3am pager duty PTSD yet.

Made a 20-line bash script that wraps SSH, regex whitelist for safe commands, instant reject for dangerous ones(rm, mv, chmod). Claude Code doesn't even know it's restricted. Production-tested for 6 months. The autonomy is chef's kiss, the audit logs saved me twice.

'Debugging turns into archaeology rather than engineering', this is the exact realization that forced me to stop building agents and start building a database kernel.

I spent 6 months chasing 'ghosts' in my backtests that turned out to be floating-point drift between my Mac and the production Linux server. I realized exactly what you said: if state isn't replayable bit-for-bit, it's not engineering.

I actually ended up rewriting HNSW using Q16.16 fixed-point math just to force 'reality to line up' again. It’s painful to lose the raw speed of AVX floats, but getting 'Engineering' back was worth it. check it out(https://github.com/varshith-Git/Valori-Kernel)

Async stack traces are a nightmare. You lose the causality chain completely.

We ran into a similar issue with 'Shared Context.' We tried to sync the context between an x86 server and an ARM edge node, but because of the floating-point drift, the 'Context' itself was slightly different on each machine.

Step-level visibility is great, but did you have to implement any strict serialization for that shared context to keep it consistent?

Switching GPUs to integer (Quantization) is happening, yes. But that only fixes the inference step.

The problem Valori solves is downstream: Memory State.

We can accept 'Approximate Computing' for generating a probability distribution (the model's thought). We cannot accept it for storing and retrieving that state (the system's memory).

If I 'resign myself' to approximate memory, I can't build consensus, I can't audit decisions, and I can't sync state between nodes.

'Approximate Nearest Neighbor' (ANN) refers to the algorithm's recall trade-off, not an excuse for hardware-dependent non-determinism. Valori proves you can have approximate search that is still bit-perfectly reproducible. Correctness shouldn't be a casualty of the AI age.

You are absolutely right. GPU parallelism (especially reduction ops) combined with floating-point non-associativity means the same model can produce slightly different embeddings on different hardware.

However, that makes deterministic memory more critical, not less.

Right now, we have 'Double Non-Determinism':

The Model produces drifting floats.

The Vector DB (using f32) introduces more drift during indexing and search (different HNSW graph structures on different CPUs).

Valori acts as a Stabilization Boundary. We can't fix the GPU (yet), but once that vector hits our kernel, we normalize it to Q16.16 and freeze it. This guarantees that Input A + Database State B = Result C every single time, regardless of whether the server is x86 or ARM.

Without this boundary, you can't even audit where the drift came from.

"You might be the only one expecting a reliable 'AI' agent period."

That is a defeatist take.

Just because the driver (the LLM) is unpredictable doesn't mean the car (the infrastructure) should have loose wheels.

We accept that models are probabilistic. We shouldn't accept that our databases are.

If the "brain" is fuzzy, the "notebook" it reads from shouldn't be rewriting itself based on which CPU it's running on. Adding system-level drift to model level hallucinations is just bad engineering.

If we ever want to graduate from "Chatbot Toys" to "Agentic Systems," we have to lock down the variables we actually control. The storage layer is one of them.

"You seem to have higher expectations of reliability than would be reasonable."

If sqlite returned slightly different rows depending on whether the server was running an Intel or AMD chip, we wouldn't call that "an observation of how things work." We would call it data corruption.

We have normalized this "unreliability" in AI because we treat embeddings as fuzzy probabilistic magic. But at the storage layer, they are just numbers.

If I am building a search bar? Sure, 0.99 vs 0.98 doesn't matter.

But if I am building a decentralized consensus network where 100 nodes need to sign a state root, or a regulatory audit trail for a financial agent, "memory drift" isn't a quirk, it's a system failure.

My "proof" isn't just that it breaks; it's that it doesn't have to. I replaced the f32 math with a fixed-point kernel (Valori) and got bit-perfect stability across architectures.

Non-determinism is not a law of physics. It’s just a tradeoff we got lazy about.

Love this kind of feedback, thank you. You nailed it on optional deps and config sprawl; I’m trimming both. CI cross is just coverage noise, and I’ll add uv setup notes it really cleans up the PyTorch mess. Glad the API felt right — that was the hardest part to get “just enough abstraction” right.

It’s definitely dense, but not as wild as it looks. The mental model was: take the core building blocks from FAISS and Milvus, make them composable in Python, and expose everything clearly.

The “vibe” part came from trying to make it feel like a system that could run in production, not just a toy. So yeah, it’s a little heavy, but it earned the vibe honestly.