DEV Community: Sanu Sharma

I Just Wanted to Build a Terminal With Custom Commands. It Somehow Became an AI Developer Shell.

Sanu Sharma — Wed, 02 Sep 2026 18:42:56 +0000

It started with a very simple thought:
Why not build my own terminal?
There wasn't some huge plan behind it.
I wasn't trying to replace PowerShell.

I wasn't trying to build an AI coding agent.
I definitely wasn't planning to create a workspace-aware automation system.
I just thought building my own terminal sounded cool.
So I tried.

And...
It didn't work. 😭
The First Version Was Barely a Terminal

My first attempts were pretty rough.
Eventually, though, I managed to get a basic version working.
It could accept commands, execute some things, and most importantly, I could define my own custom commands.

And that was basically the entire philosophy of the project at the time:
Custom commands.

That was it.
I loved the idea that instead of adapting myself to an existing terminal, I could slowly build a terminal around the way I worked.

Want a command for checking system information?

Add one.

Want a command for navigating files differently?

Add one.

Want some weird command that only makes sense in my workflow?

Why not?

I was genuinely happy with that little version.
So, naturally, I posted it on LinkedIn.
And surprisingly, people reacted pretty well to it.
But one interaction in particular changed how I looked at the project.

Then a C Developer Found the Project

One of the developers who came across the post worked with C.

Now, if someone spends their time writing C, there's a pretty good chance they know a lot more about low-level systems than I did when I started building this thing.

And he started commenting on RiftShell.
Not just:

"Nice project!"

It was more like:
This is good, but there's a problem here.

Then another issue.

Then another limitation.
And another thing that could have been designed differently.
😂

But strangely, I liked those comments.
They weren't random criticism. They made me think about what I was actually building.
At one point I explained:

I mainly built it because I wanted custom commands.
He mentioned aliases and some existing shell functionality that could already solve parts of what I was trying to achieve.
At the time, I didn't completely understand what he meant.

But it planted an interesting question in my head.
If existing terminals can already do custom shortcuts...

why should RiftShell exist?

That's a dangerous question to ask about your own project.
Because there are only two possible answers:
Either the project doesn't need to exist...
or you give it a reason to exist.

I chose the second one.

RiftShell Stopped Being About Custom Commands

I kept building.
One feature became another. The architecture changed, plugins appeared, the UI became more serious, and eventually AI entered the picture.
Somewhere along the way, my little custom-command terminal became RiftShell Orbit — a Windows-first AI developer shell and automation

workspace.
The philosophy changed too.

Originally:
Let me create my own commands.

Now:
Let the terminal understand what I'm working on — but never take control away from me.

From a custom shell to a developer workspace

RiftShell is still a terminal. It has multiple terminal sessions, command history, fuzzy search, tab completion, a command palette, background execution, Git commands, plugins, and more.
But now it also has Orbit, its integrated AI layer.

Orbit can inspect your workspace, understand project structures, read and review files, explain code, and propose changes.

Orbit proposing a real file modification. RiftShell shows the diff before the change is approved.
There are additional protections behind this: approvals are tied to the reviewed file state, overwritten files can be backed up under .ai_backups/, and multi-file operations can attempt rollback if something fails midway.

The idea is simple:
The terminal learned to think. You still hold the keys.

Local AI, Plugins, and Even Remote Control

Orbit currently supports Gemini, Groq, and local Ollama models, including configurable provider fallback.

RiftShell also has a plugin architecture, so functionality can grow without stuffing everything into the shell core.
And because apparently building an AI terminal wasn't complicated enough 😭, I eventually added an optional Telegram remote-control layer too.

The important part is that all of these features still go through RiftShell's controlled execution model.

Looking Back at Version One Is Kinda Funny

There was never some master roadmap saying:
Custom Shell → Plugins → Developer Workspace → AI → Safe Execution → Local Models → Remote Automation

The original plan was basically:
"It would be cool if I could make my own commands."
That's it. 😂

Then someone questioned why the project needed to exist when existing shells already had things like aliases.
That question ended up being surprisingly useful.

Instead of abandoning RiftShell, I kept asking:

Okay... then what should this become?

And that's how my tiny custom-command terminal slowly became RiftShell Orbit.
It's still evolving, and I genuinely don't know what it will look like several versions from now.
That's probably the fun part.

If you're into terminals, developer tools, local AI, automation, or agent safety, RiftShell is open source — and criticism is welcome.
Apparently, that's how this project gets new features. 😭

GitHub: Check out RiftShell Orbit on GitHub

I Built a Space Debris Collision Assessment Engine in Python

Sanu Sharma — Mon, 16 Mar 2026 03:42:59 +0000

Space around Earth is getting crowded.
Thousands of active satellites share orbit with millions of debris fragments — some no bigger than a bolt, yet moving at 7–8 km/s. At those speeds, even a small collision can destroy a satellite.
That reality is what pushed me to build a Space Debris Conjunction Assessment Engine.
Not as a theoretical exercise — but as a computational system that analyzes orbital data and evaluates potential close approaches between objects in orbit.

The Idea

The goal of the project was simple in concept but complex in implementation:
Given two orbital objects, estimate the risk of collision.
To do that, the system needs to:
Process orbital parameters from satellite datasets
Compute relative motion between objects
Estimate Time of Closest Approach (TCA)
Evaluate minimum separation distance
Flag potential conjunction events
What sounds straightforward quickly turns into a computational physics problem.

Architecture of the Engine

The engine evolved into a two-stage assessment pipeline.
Stage 1 — Fast Screening
The first stage acts as a filter.
Instead of running heavy physics calculations on every pair of objects, the system quickly identifies possible conjunction candidates using simplified approximations.
This dramatically reduces the computational load.
Stage 2 — Detailed Assessment
Once potential close approaches are detected, the second stage performs deeper analysis:
Relative position calculations
Time of closest approach estimation
Distance minimization between orbital paths
This stage is more computationally expensive but far more accurate.

Where Physics Meets Code

One thing this project reinforced for me:
Understanding physics and implementing physics are two different challenges.
Orbital mechanics equations may look clean on paper, but translating them into reliable Python code requires careful handling of:
numerical stability
coordinate frames
floating-point precision
algorithmic performance
There were many moments where the math was correct but the code still produced unexpected results.
Debugging those cases meant stepping back and thinking physically, not just computationally.

Challenges Along the Way

Numerical edge cases One of the trickiest parts was handling negative TCA values. At first it looked like a bug. But after digging deeper, it became clear that it represented a physical interpretation problem — not a mathematical one. Understanding what the numbers meant in the real orbital context was key.
Hardware limitations Running orbital calculations across many objects quickly becomes expensive. On limited hardware, even Python can become a bottleneck. This forced me to rethink: algorithm structure data flow optimization trade-offs Ironically, constraints made the system better designed.
Research depth This project pushed me back into topics I hadn’t revisited in a while: orbital mechanics conjunction analysis numerical methods Some equations were completely new to me, and implementing them correctly took time. But that process turned out to be the most rewarding part.

Tools Used

The system was built primarily with:
Python
numerical computation libraries
orbital data processing
custom conjunction assessment logic
Tools like ChatGPT and Grok were surprisingly useful during development — especially for exploring optimization ideas and debugging complex calculations.

Project Repository

If you’re curious about the implementation, the full project is available here:
👉 https://github.com/sanusharma-ui/space-debris-engine

From Writing Code in a Notebook to Building AI Projects

Sanu Sharma — Wed, 18 Feb 2026 19:56:30 +0000

Hi, I’m Sanu Sharma
I’m from the IT field, and I mainly work on coding and software development. I’m also interested in hardware, but hardware projects can be expensive, so most of the time I focus on software.

This is my first post on DEV, and I’m really excited to start sharing my journey here.

On this platform, I’ll share my real experiences —
what I build, why I build it, how I build it, and everything I learn along the way.

How My Coding Journey Started (2022)

I started my coding journey after my 10th exams in 2022.

To be honest, I didn’t start coding because I was a genius or because I had some big plan.
I started because my friends were trying to learn coding, and I didn’t want to be left behind.

I never joined any paid coaching.
I learned everything from YouTube and free resources.

At the beginning, I was confused.
I would start learning Python, then switch to Java, then C… and it kept repeating.
I didn’t know what to learn or where to focus.

But during that time, I successfully learned HTML, CSS, and JavaScript.

And the most interesting part is — I didn’t even have a laptop back then.

I used to write code in a notebook, imagining how it would run.
Sometimes I used online compilers, and even though they weren’t perfect, they were enough for me.

A Long Break (11th & 12th)

After that, I spent almost 2 years without coding, because I was in Class 11 and 12.
Academics took over, and I lost touch with programming completely.

College Restart (2024)

At the end of 2024, I joined college.

We had C++ in our syllabus. I tried learning it, but honestly, I found it very difficult and couldn’t really master it.

But then I met my old friends again —
HTML, CSS, and JavaScript.

This time, I didn’t just learn them… I tried to master them properly.
And along with that, I also learned React.

That’s when I started feeling confident in web development.

The Real Game Started (2025)

The real turning point of my journey came in the beginning of 2025.

Because I met Python again — and this time, Python felt different.

This time, Python felt easy.
Simple. Powerful. And fun.

I started building seriously, experimenting more, and using different AI tools to improve my learning and productivity.

And the result was real projects like:

1) Multi-persona AI

2) AI Cardiologist

3) A fully working messaging app

4) Space debris project

And many more..........

These projects were not just random ideas — they were real builds that helped me learn faster and think better.

What’s Next?

This is just the beginning.

In the coming days, I’ll be sharing my stories and projects here —
the things I build, the mistakes I make, and the lessons I learn.

All my projects are also available on my portfolio website, so you can check them out if you want.
Portfolio: https://www.sanusharma.dev/

I’m not here to impress anyone.
I’m here to improve, build, and grow.

Thanks for reading ❤️‍🔥