DEV Community: GJV PAVANSAI

https://www.linkedin.com/posts/gjv44_softwareengineer-aiengineer-fullstackdeveloper-ugcPost-7492873611960049664-zbr-/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAGgdKOsBtm4MF_SaHMHk69gmVrhAJZbcPo0

GJV PAVANSAI — Tue, 11 Aug 2026 09:35:57 +0000

Aug 11

I Built a Cinematic Developer Portfolio Instead of a Traditional One — Here’s What I Learned

#showdev #frontend #portfolio #webdev

3 min read

#softwareengineer #aiengineer #fullstackdeveloper #artificialintelligence #softwaredevelopment #webdevelopment #reactjs #typescript #portfolio #opentowork | Pavan Sai

🚀 I didn’t want to build another developer portfolio. I wanted to build an experience. Please see the portfolio and comment me what are changes i should do and find any bugs or errors in my portfolio so that will help me to imporve myself After weeks of designing, coding, debugging, rebuilding, and polishing… my new Software Engineering & AI portfolio is officially LIVE. What started as a simple portfolio idea gradually became one of the most interesting projects I’ve worked on. I wanted someone visiting it to experience my journey — not just scroll through a list of technologies and projects. So I experimented with: 🎬 A cinematic opening experience 🎵 Custom soundtrack and audio transitions ⚡ Interactive animations and scene transitions 🤖 AI & Software Engineering project showcases 🧩 Detailed project case studies 📱 Responsive experiences across devices 🎨 A custom cinematic visual system But the coolest part wasn’t getting everything working. It was finding everything that wasn’t working. 😅 Broken navigation. Routing issues. Blurry text. Video positioning. Audio levels. Responsive layouts. Animation timing. Deployment problems. Tiny UI inconsistencies that somehow took hours to solve. That process became the real lesson behind this project: Build. Test. Break. Debug. Improve. Repeat. That’s software engineering. And after many iterations, I’m finally happy to share the result. 🌐 Portfolio: https://lnkd.in/gcJghPgF I’d love for you to experience it rather than just look at it. And developers — if you find a bug, tell me. 👀 There’s always one hiding somewhere. 😂 I’m currently exploring opportunities in Software Engineering, AI Development, and Full-Stack Engineering, and I’d love to connect with people building interesting technology. Feedback, connections, and opportunities are always welcome. 🚀 #SoftwareEngineer #AIEngineer #FullStackDeveloper #ArtificialIntelligence #SoftwareDevelopment #WebDevelopment #ReactJS #TypeScript #Portfolio #OpenToWork

linkedin.com

I Built a Cinematic Developer Portfolio Instead of a Traditional One — Here’s What I Learned

GJV PAVANSAI — Tue, 11 Aug 2026 09:35:22 +0000

I Built a Cinematic Developer Portfolio Instead of a Traditional One — Here’s What I Learned

Most developer portfolios follow the same structure:

About.

Skills.

Projects.

Contact.

There is nothing wrong with that.

But when I started rebuilding mine, I wanted it to feel less like a collection of sections and more like an experience.

So what started as a simple portfolio redesign slowly turned into a cinematic, interactive developer portfolio built around my journey as a Software Engineer and AI Developer.

🌐 Live Portfolio:

https://pavan-sai-portfolio-xi.vercel.app

The Idea

I wanted the visitor to feel like they were entering a story rather than opening another resume website.

The final experience includes:

A cinematic opening sequence
A custom soundtrack
Full-screen scene-based navigation
Animated video backgrounds
Project showcases and case studies
A personal journey timeline
Responsive mobile layouts
A cinematic closing scene
Smooth transitions between sections

The overall visual direction is built around:

Black + Champagne Gold + Cinematic Lighting

The Portfolio Flow

The experience follows a sequence:

Intro

→ Pavan Sai

→ Hero

→ About

→ Skills

→ Projects

→ Journey

→ Contact

→ Closing Credits

Instead of normal vertical scrolling, the main portfolio behaves more like a sequence of scenes.

Visitors move through the experience using navigation controls.

Project case studies are separate and can scroll normally because they contain more detailed technical information.

The Projects

Some of the projects featured in the portfolio include:

DevPilot AI

An AI-powered DevOps incident recovery platform focused on detecting failures, diagnosing issues and helping recover production systems.

ROCmPorter Agent

An AI-assisted CUDA-to-AMD ROCm migration tool that analyzes repositories, identifies CUDA dependencies and helps generate migration changes.

HunarHub

A local skilled-worker discovery and service marketplace platform.

I also showcase other engineering, AI and full-stack projects throughout the portfolio.

The Part Nobody Sees 😅

Building the visuals was actually not the hardest part.

The difficult part was making everything work together.

I ran into issues with:

Route transitions
Wrong scene navigation
Video cropping
Blurry typography
Responsive layouts
Audio autoplay restrictions
Music volume
Duplicate video playback
Project route mapping
Text baked into generated visuals
Mobile viewport sizing
Video preloading
Deployment
Broken Git repository objects
Production asset paths

Some bugs looked tiny but took much longer than expected.

One of the biggest lessons from this project was:

Build. Test. Break. Debug. Improve. Repeat.

That cycle ended up defining the entire project.

Readable UI vs Cinematic Artwork

One interesting problem came from using cinematic generated artwork.

Some images looked beautiful, but small text embedded inside them became blurry when displayed as video or scaled across different resolutions.

The solution was simple in theory:

Treat the video as artwork.

Treat important information as HTML.

So the final architecture separates:

Cinematic media
Atmospheric effects
Readability gradients
Real HTML content

This made the text much sharper while keeping the cinematic look.

Video Performance

Another challenge was having multiple cinematic sections without destroying performance.

I avoided playing every video simultaneously.

The experience instead tries to:

Play only relevant media
Pause hidden videos
Avoid aggressive preloading
Use static posters as fallbacks
Respect prefers-reduced-motion
Keep project preview videos lightweight

This was especially important on mobile.

Audio

The portfolio also has its own cinematic soundtrack.

But browsers do not allow websites to freely autoplay audio.

So the soundtrack starts only after user interaction.

The flow became:

Enter Experience

→ soundtrack begins

→ cinematic intro starts

→ music continues through the portfolio

There is also a persistent sound control so visitors can disable it anytime.

What I Learned

This project reminded me that frontend development is not only about making something look good.

A polished experience requires thinking about:

UX
Accessibility
Responsive design
Performance
Navigation
Media loading
State management
Browser behavior
Production deployment

And sometimes the final 10% of polish takes as much effort as the first 90%.

Tech

The portfolio uses technologies including:

React
TypeScript
Vite
CSS
HTML5 video
Client-side routing
Responsive design
Custom media handling
Vercel deployment

It also showcases my broader work across:

Python, FastAPI, Node.js, Express.js, Next.js, Docker, AI systems, RAG, Elasticsearch and more.

Final Result

The portfolio is now live:

👉 https://pavan-sai-portfolio-xi.vercel.app

I would love feedback from other developers.

Especially:

How does the intro feel?
Is the navigation intuitive?
How does it perform on your device?
Which project catches your attention first?

And of course...

If you find a bug, tell me. 👀

There is always one hiding somewhere.

Thanks for checking it out.

A huge amount of GPU code is locked to NVIDIA CUDA — `nvcc` in the build, `cudaMalloc` in the kernels, `torch.cuda` everywhere. Moving it to AMD ROCm (often cheaper and more available hardware) usually means reading the whole codebase by hand and rewriting

GJV PAVANSAI — Wed, 22 Jul 2026 11:06:23 +0000

GJV PAVANSAI

Jul 22

I built a tool that migrates CUDA code to AMD ROCm — and made the AI do less, not more

#showdev #opensource #ai #cpp

2 min read

I built a tool that migrates CUDA code to AMD ROCm — and made the AI do less, not more

GJV PAVANSAI — Wed, 22 Jul 2026 11:05:34 +0000

A huge amount of GPU code is locked to NVIDIA CUDA — nvcc in the build, cudaMalloc in the kernels, torch.cuda everywhere. Moving it to AMD ROCm (often cheaper and more available hardware) usually means reading the whole codebase by hand and rewriting every NVIDIA-specific line. Most teams never do it.

So I built ROCmPorter. Point it at any GitHub repo and it flags every CUDA dependency with file+line evidence, scores the repo's ROCm readiness 0–100, and can open a pull request that migrates the code to HIP.

Live (free, no signup): https://rocmporter-agent.vercel.app
Source (MIT): https://github.com/pavansai20052004-hue/rocmporter-agent

The one design decision I care about: make the AI do less

The obvious way to build this is "throw the file at an LLM and ask for HIP." I didn't do that, because most of a CUDA→HIP migration isn't a judgment call — it's a lookup. cudaMalloc → hipMalloc. <cuda_runtime.h> → <hip/hip_runtime.h>. cudaStream_t → hipStream_t. Asking a model to do that is slow, non-deterministic, and occasionally wrong on things that have exactly one correct answer.

So the engine is deterministic-first:

A curated hipify pass (~90 CUDA→HIP API/header/library mappings) runs first and converts the mechanical majority with zero AI. Files it fully converts never touch a model.
Only the semantic remainder goes to an LLM — and that prompt is grounded in a small curated knowledge base of ROCm facts (warp size is 64 on CDNA, cuDNN→MIOpen isn't a rename, don't rewrite torch.cuda device strings on ROCm builds of PyTorch, etc.).
Every migrated file reports provenance: what was mechanical vs. AI-assisted.

The result is that patches are mostly deterministic with a small, clearly-labeled AI remainder — which is exactly what you want when a human has to review the diff.

Compile-verified, not vibes

A migration tool that emits code that doesn't compile is worse than useless. So generated HIP is compile-checked with hipcc inside AMD's official rocm/dev-ubuntu-22.04 container in CI on every push. The example in the repo (examples/vector_add) is machine-generated by the engine and compile-validated continuously — the badge on the README is a real build, not a claim.

Being honest about the limit

It's compile-verified, not execution-verified. I don't have AMD GPU access yet, so I can't run migrated test suites on real hardware. That's the next thing I want to add, and I'd rather say it plainly than imply otherwise.

Stack

FastAPI backend (static analysis + hybrid engine), React frontend, and it also ships as a GitHub Action (readiness comments on PRs) and a VS Code extension (inline CUDA lock-in + one-click hipify).

If you've got a CUDA repo you've been meaning to port, paste it in and tell me where the output is wrong — that feedback is exactly what improves the mapping. And if it's useful, a GitHub star helps other people find it. 🙏