I build intelligent systems.
Most of them are useful. This one is just honest about how it works.
I'm Charan — an AI & automation engineer in Bangalore. I ship production LLM systems: document pipelines that run themselves, a Springer-published model that reads chest X-rays well enough for a radiologist to take seriously, and the unglamorous plumbing that keeps both alive after the demo is over.
Before any of that, I wrote real-time control code for jet engines at DRDO — where a millisecond of lag isn't a bug, it's a flameout. That job rewired how I think about software: it should be correct first, fast second, and never quietly wrong. NeuroForge carries that same bias. Most "neural network demos" are a thin UI over a library doing all the real work. This one is the opposite — the learning algorithm is the project. No TensorFlow, no autograd. The math is right there in 250 lines you can read in one sitting.
What I learned building this
Five honest takeaways
Backprop is gentler on paper than on a whiteboard
Once you commit to "a layer is just a = act(W·a + b)," the backward pass is the same loop run in reverse. Writing it without autograd forced me to actually understand the chain rule instead of nodding along to it.
Trust nothing — gradient-check everything
My first decision boundary refused to bend. The bug wasn't in the clever part; it was an averaging-over-the-batch slip. A numerical gradient check (central differences vs. the analytic gradients) caught it, and now the two agree to a relative error of ~2e-10 — basically machine precision.
Rendering is a feature, not decoration
A network that trains in the console teaches no one. The boundary heatmap — a grid of forward passes recomputed and upscaled each frame — is the difference between "it works" and "oh, that's what overfitting looks like."
Performance is a UX decision
6,400 forward passes per frame in plain JavaScript is not free. Caching the field and recomputing it only when the weights actually change is what keeps the whole thing at 60fps. Old habit from the jet-engine days: budget the milliseconds before you spend them.
Constraints make better work
Banning every dependency sounds like a stunt. It was the best decision in the project: nowhere to hide, nothing to "just import," and a repo anyone can read top to bottom in an afternoon. The human lesson — the limits I picked taught me more than the freedom would have.
This is one project. There are 18 more — plus a published X-ray model and a couple of jet engines — over at charanreddy.dev. Consider this the door, not the billboard.
See the rest →Find me
Want to build something — or break something interesting? Let's talk.
Have an idea? Let's talk.
Hiring, collaborating, or just want to argue about whether you really need a framework — the inbox is open.