DEV Community: TROJAN

Why Every Developer Should Build at Least One AI Project in 2026

TROJAN — Wed, 25 Mar 2026 16:39:53 +0000

AI is no longer “the future.”
It is already part of everyday development.
And yet, many developers are still watching from the sidelines.
Reading about it.
Liking posts about it.
Maybe generating a few lines of code with it.
Feeling productive… without actually building anything.
We have all been there.

The Shift Happening Right Now

We have moved from asking:

“Should I learn AI?”

to:

“How quickly can I apply it without breaking everything?”

Companies are not looking for AI researchers in most roles.
They are looking for developers who can use AI to solve real
problems.

That is a very different skill.

Why This Matters

Building even one AI project teaches you things that tutorials never will:

How to handle unpredictable outputs
How to design systems around uncertainty
How to integrate APIs with real-world logic
When AI is useful, and when it quietly creates chaos

You stop seeing AI as something magical.

And start seeing it as a tool that occasionally needs supervision.

You Do Not Need Something Complex

Your project does not need to be groundbreaking.

It just needs to work.

Some simple ideas:

A chatbot that solves a specific use case
A tool that summarizes or analyzes content
A small assistant for daily tasks
Adding an AI feature to an existing project

Simple and functional beats complex and unfinished every time.

(Yes, even if the UI is a little ugly. We can fix that later. Probably.)

What You Actually Learn

Once you build something, a few things become very clear:

AI outputs are not always reliable
Prompting is not “set it and forget it”
Debugging AI feels like arguing with a very confident intern
User experience matters more than model complexity

This is where real understanding begins.

A Common Mistake

Do not rely entirely on AI to build your project.
Use it, but understand what it is doing.
If you cannot explain your own system clearly, then you have not really built it.

You have just supervised it.

Final Thought

You do not need to become an AI expert.
You just need to stop being an observer.
Build one project.
That is enough to change how you think, build, and learn.

And if nothing else, you will finally have something better to show than

“experimented with AI tools” on your resume.

I Built a Desktop App That Starts My Entire Dev Environment With One Click (Using Tauri + Rust + React)

TROJAN — Thu, 12 Mar 2026 19:33:08 +0000

Every morning I would open 4 terminal tabs, cd into different folders, and run some combination of npm run dev and cargo run. Then I'd forget which terminal crashed. Then I'd do it again.

So I built Chronicle to kill that habit.

What Is Chronicle?

Chronicle is a desktop app (built with Tauri) that does two things:

One-click workspace launcher — press a button, fire up all your dev servers simultaneously, watch their output stream into a tabbed terminal dashboard in real-time
Git history explorer — visualize your commit graph, click commits to read diffs, and use an AI (Gemini) to summarize what changed

The Stack

Layer	Technology
App Shell	Tauri v2
Frontend	React 19 + Vite 7 + TypeScript
Backend	Rust (async, via Tokio)
Styling	Tailwind CSS v4
Animations	Framer Motion
AI	Google Gemini

Why Tauri?

Tauri lets you write your UI in whatever web framework you want, then wraps it in a native OS window using Rust. The result is a .exe that's tiny, fast, and has full access to the OS. No Electron 300MB bloat. No compromises.

The Rust backend part is what made the launcher feature possible. Here's the core of how it works:

#[tauri::command]
async fn start_all_processes(
  app: AppHandle,
  state: tauri::State<'_, Arc<AppState>>,
  project_path: String
) -> Result<(), String> {
  // Spawn each process asynchronously
  spawn_and_stream(app.clone(), state.clone(), "buildforge", 
    "npm", &["run", "dev"], &format!("{}\\BuildForge", project_path)).await?;

  spawn_and_stream(app.clone(), state.clone(), "airwebreathe", 
    "npm", &["run", "dev"], &format!("{}\\AirWeBreathe", project_path)).await?;

  Ok(())
}

The spawn_and_stream function uses Tokio to spawn processes async, reads their stdout/stderr line by line, and emits each line to the React frontend using Tauri's event system.

On the React side, listening for those events looks like:

const unlistenOutput = await listen<LogPayload>('process-output', (event) => {
  setLogs(prev => ({
    ...prev,
    [event.payload.id]: [...(prev[event.payload.id] || []), event.payload.line]
  }));
});

That's it. Real-time streaming terminal output from Rust to React in so few lines.

The UI

The whole thing is themed after GitHub dark mode (#0d1117, subtle borders, green accents). The launcher screen has one big green button. The dashboard that opens shows tabbed terminal output for each running process, auto-scrolling, color-coded (green = success, red = error).

What I Learned

1. Tauri is genuinely underrated. The developer experience is excellent, the apps are fast, and the security model is much more sensible than Electron.

2. Tokio makes async process spawning a joy. tokio::process::Command + BufReader + lines() is all you need to stream terminal output.

3. Tauri's event system is a perfect bridge. app.emit("event-name", payload) from Rust, listen("event-name", handler) from TypeScript. Clean and simple.

Try It

git clone https://github.com/TROJANmocX/Chronicle.git
npm install
npm run tauri dev

If you're building dev tooling or have ever thought "I should automate my terminal workflow" — Tauri + Rust is a genuinely great choice. Feel free to drop questions in the comments.

Happy building! 🗡️

I Performed an Autopsy on My LeetCode Streak (It Didn’t Die Peacefully)

TROJAN — Fri, 30 Jan 2026 15:26:32 +0000

My LeetCode streak didn’t “break.”
It died.

Not heroically.
Not after a hard problem.

It died on a random weekday because I got tired and lied to myself.

So I stopped tracking streaks like a motivational influencer
and started treating them like crime scenes.

Everyone Tracks Wins. Nobody Tracks Failure.

We love dashboards that say “X days strong”.
We don’t talk about how those streaks actually end.

When I analyzed my submissions, I noticed something uncomfortable:

My streaks don’t die randomly — they die on the same days
Most of them collapse between day 7–10 (fake discipline window)
My “longest streak” is a flex My average streak is the truth — and it’s embarrassing

Discipline wasn’t the problem.
Predictable burnout was.

So I Built a Streak Autopsy Tool

Instead of promising myself I’d “do better next time,”
I built something that performs a post-mortem.

You enter your LeetCode username.
It tells you:

how many streaks you’ve started
how many you’ve killed
how long they usually survive
the exact day you’re most likely to quit
and gives you a streak reality check instead of motivation porn

No quotes.
No fake encouragement.
Just data quietly judging you.

Why I Built This

Tracking wins was lying to me.
Losses don’t lie — they repeat.

If you know how your streak dies,
you can stop pretending it was an accident.

Repo:
👉 https://github.com/TROJANmocX/GrindGuard-2.0

Live demo:
👉 https://grindguard.vercel.app/

Final Thought

If your streak ever “mysteriously” vanished,
this will tell you why.
And if you don’t like the result good. Neither did I.

PLEASE TELL ME HOW CAN I IMPROVE IT AND WHAT PROBLEM ARE YOU ALL FACING.

I tried tracking my LeetCode streak honestly. The API fought me. I won.

TROJAN — Sun, 25 Jan 2026 17:16:21 +0000

Most LeetCode trackers fail at the one thing that matters most: trust.

If I solve a problem, I expect the app to:

mark it as solved
remove it from recommendations
update my progress immediately

No refresh. No manual ticking. No lies.

That frustration is exactly why I built GrindGuard 2.0.

Live app: https://grindguard.vercel.app/
GitHub repo: https://github.com/TROJANmocX/GrindGuard-2.0

What is GrindGuard 2.0?

GrindGuard 2.0 is a LeetCode accountability and focus system that turns your accepted submissions into:

Automatic progress tracking
Smart daily missions
Topic-wise analytics
Zero manual work

If LeetCode says you solved it, GrindGuard believes it. Period.

Core Philosophy

One source of truth. Everything else is derived.

No duplicated state.
No stale UI.
No “why didn’t this update?” moments.

Key Features

1. Automatic Progress Tracking

Solved problems are fetched directly from LeetCode accepted submissions and normalized into a single solvedProblems state.

If a problem is solved:

it is instantly marked as done
it never appears again in focus or suggestions

No manual input required.

2. No Repeat Questions

Daily Mission and recommendations strictly filter out solved problems using a normalized identifier (slug).

Once a question is done, it’s gone for good.

3. Real-Time Progress Analytics

Progress bars recompute every time solved data changes.

Topic-wise completion
Smooth count-up animations
Visual feedback that feels alive

If bars don’t move, users don’t trust the app. This fixes that.

4. Smart Focus System

Instead of showing everything, GrindGuard answers one question:

“What should I solve next?”

The algorithm:

Detects weakest topics (<40% completion)
Selects high-impact unsolved problems
Uses seeded randomness so missions stay consistent for 24 hours

No noise. Just focus.

5. One-Click Sync

A single Sync button:

fetches LeetCode data
updates progress, focus, and analytics together
shows freshness (“Synced 2 mins ago”)

Explicit feedback builds trust.

6. Zero Manual Work

The happy path is fully automated.

Manual overrides exist only as a fallback — never as the primary flow.

Architecture Overview

GrindGuard uses a simple but strict data flow:

LeetCode API
↓
fetchSolvedProblems()
↓
Dashboard (single source of truth)
↓
Derived UI

Progress
Daily Mission
Analytics

All components are reactive and render-only.
No component fetches data on its own.

Tech Stack

React 18 + TypeScript
Vite
TailwindCSS
Alfa LeetCode API (accepted submissions)
Striver SDE Sheet (curated problems)
LocalStorage fallback for resilience

What I Learned

Trust beats features
Reactive derivation beats stored state
If UI doesn’t update instantly, users assume it’s broken
One clear recommendation beats ten options

GrindGuard is not a dashboard. It’s a coach.

Try It Out

Live: https://grindguard.vercel.app/
Code: https://github.com/TROJANmocX/GrindGuard-2.0

If you’re grinding LeetCode and want accountability without friction,this one’s for you.

Happy grinding.

My Diary 2.0 — A Digital Journal

TROJAN — Fri, 16 Jan 2026 08:18:38 +0000

Some thoughts deserve a journal.
Some thoughts deserve therapy.
This app handles both.

Welcome to My Diary 2.0 — a personal web diary that feels like writing in an old notebook, but without the risk of your sibling finding it.

Live Demo: https://my-diary-snowy.vercel.app/
GitHub Repo: https://github.com/TROJANmocX/My-Diary

What Is My Diary 2.0?

My Diary 2.0 is a React + TypeScript diary app with a vintage aesthetic, mood tracking, and a writing experience that actually makes you want to journal.

Think:

Typewriter vibes
Candlelight drama
Nostalgic paper textures
Mild emotional chaos

Features That Deserve Respect

Vintage Writing Experience

Feels like:
“Dear Diary, today was… a lot.”

Includes:

Typewriter-style fonts
Paper-like background
Auto-expanding text area
Zero judgment

Mood Tracking

Because “fine” is not a real emotion.

Choose from:

Happy
Sad
Moody
Chaotic
Existential

Aesthetic Themes

Switch between:

Vintage – classy, nostalgic
Candle – dramatic, low-light, main-character energy

Secure Storage (Supabase)

Your secrets stay secret.
Unless you forget your password. Then… character development.

Custom Signatures

End entries like:

“— Trojan, still figuring things out.”

Tech Stack (The Sensible Kind)

React + TypeScript
Supabase (auth + storage)
Tailwind CSS
Custom Vintage UI
Vercel Deployment

No unnecessary frameworks. Just vibes and functionality.

Why I Built This

Most diary apps feel like filling out an emotional tax form.

I wanted something that:

Feels personal
Looks nostalgic
Makes writing fun
Doesn’t judge my 2 AM thoughts

So I built it.

Try It Before Your Thoughts Escape

Live Website:
https://my-diary-snowy.vercel.app/

Source Code:
https://github.com/TROJANmocX/My-Diary

Fork it. Customize it. Make it your own emotional support app.

What’s Next?

Planned upgrades:

Entry analytics
Mood history charts
Cloud backups
More themes
Possibly AI reflections (no promises)

Final Words

If your brain never shuts up
and your thoughts need somewhere safe to scream —

My Diary 2.0 is ready.

Now go write something unhinged.

— Trojan

I Built a Gesture Controlled Fluid Simulation (And Accidentally Fought GitHub)

TROJAN — Sat, 10 Jan 2026 16:12:31 +0000

So I had a simple idea:
“Let’s control a fluid simulation with hand gestures.”

Now I have:

10,000 particles
A racing mode
Audio reactivity
A physics engine
And emotional damage from GitHub’s 100MB file limit

Worth it.

What Is HydraFlow?

HydraFlow is a real-time, gesture-controlled fluid simulation where your hands literally control physics.

Open palm?
Particles fly away.
Pinch?
Black hole.
Fist?
Time stops.
Two hands?
Magnetic chaos.

It’s like Doctor Strange, but with Python and worse life choices.

The Cool Stuff

10,000 particles moving at 60 FPS
MediaPipe hand tracking
Multiple visual modes (Matrix, Heatmap, Disco, etc.)
Audio-reactive effects (yes, it vibes to music)
Racing mode where you steer with your hands
Glow, trails, chaos mode because subtlety is overrated

Your webcam becomes a controller.
Your hands become an API.

The GitHub Villain Arc

Everything was going great until I tried to push my repo.

GitHub saw my .exe file and said:

“That’s cute. Now delete it.”

Turns out GitHub has a 100MB file limit, and my build files were built DIFFERENT.

So I:

Nuked big files from git history
Added a proper .gitignore
Force-pushed like a responsible menace

Now the repo is clean, lean, and judgment-free.

What I Learned

GitHub is not your USB drive
Build files are not source code
.gitignore is not optional
Physics + hand tracking = dopamine
Debugging at 2AM builds character

Why I Built This

Because:

Mouse control is boring
Gestures feel futuristic
Physics is fun
And I like watching particles suffer

Also, it looks cool on my portfolio.

Try It Yourself

Repo:
https://github.com/TROJANmocX/HydraFlow

Wave your hands.
Break physics.
Feel powerful.

Final Thoughts

HydraFlow started as a fun experiment.
It became a full-blown chaos simulator.
And GitHub tried to humble me.

But we move.

If you’re building something weird, ambitious, and slightly unhinged
you’re doing it right.

I Built a Desktop App That Commits to GitHub So I Don’t Have To Lie About Consistency

TROJAN — Mon, 05 Jan 2026 05:56:07 +0000

Let’s be honest for a second.
GitHub contribution graphs are not a productivity metric.

They are a vibe metric.

I got tired of pretending otherwise, so I built a desktop app that automates commits for me. Not to fake work, but to remove the mental overhead of “oh no I forgot to commit today.”

This app runs locally, schedules commits, and pushes them directly to your repository. No browser tabs. No cron jobs duct taped together. Just open the app, configure it once, and let it handle the boring part.

Why build this instead of just committing manually?
Because consistency is not discipline. It is systems.
I noticed I was writing code regularly, but committing inconsistently. That gap was pure friction. So I removed it.

This project taught me more than expected
how to package a desktop app
how to handle Git authentication cleanly
how to build something people will immediately argue about

And honestly, that last part is the fun one.
You can judge the idea, but the app works. It ships. It solves a real annoyance.

Here is the repo
https://github.com/TROJANmocX/-Auto-Commit-Desktop-App.git

Curious question for you
Do tools like this reduce discipline or reveal how fake our productivity metrics already are

Most Developers Aren’t Bad. They’re Just Invisible.

TROJAN — Mon, 05 Jan 2026 05:46:36 +0000

Hot take skill is not the bottleneck anymore.
There are incredibly capable developers with clean code strong fundamentals and real curiosity and nobody knows they exist. Not because they are unlucky but because they do not show their work.
I was stuck in that loop for a long time. Building quietly improving privately waiting for the moment where everything felt ready.

That moment never comes.

Things changed when I started shipping publicly. Not perfect projects and not groundbreaking ideas. Just things that worked existed and could be seen.
Feedback replaced guessing. Real problems replaced imaginary ones. Learning sped up because reality does not care about plans.
Here is the part we do not say often enough.
The internet rewards visibility before brilliance.

That does not mean lowering standards. It means unfinished and shipped beats perfect and hidden every time.

If you want opportunities do not wait to be impressive.
Be visible. Improve in public. Let the work speak even if it stutters at first.

What is something you have built that deserves to exist outside your local machine

Five Projects, Carefully Unhinged and Fully Deployed

TROJAN — Sat, 03 Jan 2026 09:55:43 +0000

I recently reviewed my Vercel dashboard and came to an unexpected conclusion: I appear to be speedrunning side projects as if it were a professional obligation.

There’s Digital Guilt Trap, a minimalist experiment in user interaction that applies light emotional pressure via buttons.
The Checker, which attempts to analyze personality traits and then politely passes judgment.
Quantum Weather, where forecasts are technically accurate but emotionally questionable.
A deliberately Useless Website that does almost nothing, yet still managed to require mobile bug fixes.
And my Portfolio, now tasked with explaining how all of the above are connected.

None of these projects were built to chase virality. They were built to ship, deploy, and expose the realities of production environments rather than hypothetical perfection. Each one reinforced a familiar lesson: user experience is deceptive, mobile layouts are unforgiving, and committing code is more productive than overthinking it.

If you are waiting for the perfect idea, consider not doing that. Build the imperfect one instead. Deploy it, improve it, and move forward. Momentum remains undefeated.

Projects shipped. Lessons learned. Dashboard remains quietly judgmental.
If you had one hour to improve any of these projects, where would you spend it?

I Know My Code Is Bad Because I Start Defending It

TROJAN — Sun, 28 Dec 2025 09:47:45 +0000

There’s a moment when I know my code is bad. Not when tests fail. Not when something breaks. It’s when someone asks a simple question and I start explaining instead of pointing.

That’s the smell.

Good code doesn’t need a defense. Bad code comes with context, history, and a quiet “don’t touch that part.” At that point, you’re not documenting. You’re apologizing.

I’ve noticed when code is clear, I’m calm. When it’s messy, I get defensive. I say things like “it works” or “we’ll clean it later.” Those aren’t explanations. They’re excuses.

Now I use one test. If I came back to this code in a few months, would I trust myself touching it without fear? If not, it’s not done. It’s just shipped.

What’s the best excuse you’ve ever made for bad code?

I Follow Web Dev Trends So Recruiters Don’t Have To

TROJAN — Sun, 28 Dec 2025 09:42:24 +0000

Every few months, the web dev world collectively decides we’re all doing things wrong again.
Right now it’s:
AI everywhere
Rust everywhere
WebAssembly everywhere
Low-code “replacing developers” everywhere

Recruiters see these words on resumes all day.
So instead of listing them, I tried something radical.
I asked: What did these trends actually teach me as an engineer?

AI Didn’t Turn Me Into a 10x Dev

It Turned Me Into a Better Reviewer

AI can write code faster than I can.
That’s fine.
What it can’t do is explain why the code is shaped the way it is.

Using AI taught me three things fast:

If I can’t review it, I shouldn’t ship it
“It works” is not a quality bar
Bad systems + AI = faster disasters

AI didn’t replace my job.

It made thinking non-optional.

Rust and WebAssembly Taught Me Humility

Rust promised safety.

The compiler delivered emotional damage first.
WebAssembly promised performance.

Tooling reminded me reality exists.

What I learned:

Performance is useless if users don’t feel it
Safety is great once you understand the cost
Shiny tech doesn’t save unclear design

Trends are fun.

Shipping is sobering.

Low-Code Didn’t Kill My Skills

It Killed My Excuses

Low-code removed the boring parts.
Which meant I couldn’t hide behind boilerplate anymore.

What was left?

Architecture decisions
Data flow
Edge cases
Things breaking at 2 AM Low-code didn’t reduce my value. It raised the bar.

What I Actually Optimize For Now

Instead of chasing tools, I optimize for:

Code someone else can understand
Systems that survive change
Decisions that age well
Fewer “we’ll fix it later” moments

I still learn new tech.
I just don’t confuse novelty with progress.

For Recruiters (HEYYYYYYY)

Anyone can list stacks.

What teams really need are engineers who:

Learn fast without breaking things
Ask annoying but important questions
Think in systems, not snippets
Can explain their code without sweating

That’s the kind of engineer I’m trying to be.

If that sounds useful, we’ll probably get along.

My Code Worked. The System Didn’t

TROJAN — Sun, 28 Dec 2025 09:38:23 +0000

My code ran.The tests passed. The demo looked clean.
And yet the project felt wrong.
Not broken.

Not buggy.

Just heavy. Like every new change was dragging a growing pile of invisible debt behind it .At first, I ignored the feeling. That’s what we do. If it compiles, it ships. If it ships, it’s fine. Right?
Wrong. Quietly wrong.

The Lie We Tell Ourselves

We tell ourselves that working code is success.
But “working” is a low bar. A suspiciously low bar.

Code can work and still:

Be hard to reason about
Fight you every time you touch it
Punish you for adding one small feature

That’s exactly what happened.Every new feature took longer than the last. Every fix created two new problems.Refactors felt scary instead of satisfying.The system wasn’t broken.It was fragile.

The Moment It Clicked

The realization didn’t come during a big failure.It came during a tiny change.Something that should’ve taken an hour.Instead, I spent the entire evening asking myself one question.“If I change this… what else explodes?”. That’s when it clicked.If you’re afraid to touch your own code, the problem isn’t the code.It’s the system.

Features Aren’t the Villain

Here’s the uncomfortable truth.
I wasn’t really building features.

I was stacking decisions I didn’t fully understand.
I optimized for:

Speed
Shipping
Momentum
“I’ll clean this later”

Every choice made sense in the moment.But systems remember.They remember every shortcut, every assumption, every temporary hack that quietly became permanent.

The Real Bug

The bug wasn’t technical. It was mental.I treated architecture like something you do after the product exists.

Like a luxury.Like premature optimization. Turns out architecture isn’t about perfection.

It’s about:

Making the next change cheaper
Making failure predictable
Making understanding possible And I didn’t do that.

What I’m Learning Now

Good systems don’t feel clever. They feel calm.

You don’t ask:

“Will this break everything?”

You ask:

“Where does this belong?”

When that question is hard to answer, you’re already in trouble.

I’m still unlearning bad instincts.I’m still fixing things I shipped too fast.But I don’t measure success by “it works” anymore.I measure it by this.Does this system fight me, or does it work with me?

Your turn.
At what point does “just ship it” turn into self-sabotage?