DEV Community: Lokesh

Docker, Node, and Electron Walked Into My Terminal. So I Built a 3.5MB App to Kick Them All Out.

Lokesh — Tue, 02 Jun 2026 10:05:53 +0000

2 AM, 4 GB of Docker, and a Very Simple Question

I just wanted to ask Llama 3.2 about a regex.

That's it. One prompt. One answer. 30 seconds of work.

Here's what actually happened:

Open Docker Desktop
Wait for the Open WebUI container to wake up
Watch it silently consume 500 MB of RAM
Open a browser tab pointed at localhost:3000
Finally type the question
Get my answer
Notice the container is still running, eating my battery at 3 AM

For a chat window. A chat window for a local model.

I closed my laptop, stared at the ceiling, and decided: this is no longer acceptable.

The State of Ollama UIs on Linux (It's Not Great)

If you've tried to put a UI on Ollama on Linux, you've hit this wall. Your options are basically:

Tool	Installed Size	What You Need	Reality
Open WebUI	500MB+	Docker daemon + container runtime	Heavy, always-on background process
Lobe Chat / Hollama	100MB+	Node.js + `npm install`	A web server you have to start and stop
Msty / Jan	200–400MB	Bundled Electron runtime	A whole Chromium browser to send text
Browser extensions	N/A	A specific browser	Limited, can't do file uploads properly
Just use the CLI	0MB	Memorize every flag	Writing JSON by hand just to send an image

None of these feel like software. They feel like workarounds. And the worst part? Ollama itself is fantastic on Linux — fast, lean, runs anywhere. The problem was never the model. It was everything wrapped around it.

So I Did the Only Sane Thing: Built My Own

Meet Ollama Chat — a native Linux desktop app for Ollama that weighs 3.5MB installed, uses ~50MB of RAM, and ships as a proper .deb package.

itslokeshx / ollama-chat

Native Linux desktop chat app for Ollama with real-time streaming, model switching, and file/image uploads—no Docker or Node.js required.

Ollama Chat

A native Linux desktop UI for Ollama — ~3.5MB, no Docker, no Node.js, no nonsense.

🚀 Get Started Now

v1.0.0 • ~3.5MB • Linux (amd64) • Free & Open Source

📋 Table of Contents

🤔 Why I built this

If you use Ollama on Linux, you already know the pain.

You install Ollama, pull a model, and then... you're stuck in a terminal forever. Want to switch models? Type a command. Want to use a different model mid-chat? Stop, remember the command, switch, start again. Want to upload an image? Hope you know the exact syntax. Want a chat interface like Claude or ChatGPT? Linux users are left behind — Ollama has a beautiful native UI for macOS, but Linux gets nothing.

…

View on GitHub

It's not a web server. It's not a Docker container. It's not an Electron app. It's a real native window with native titlebar controls, sitting in your application menu like any other app you actually use.

The Stack (And Why Tauri Is the Real Hero)

Layer	Tech	Why
Runtime	Tauri 2.0	Rust + system WebKit, no bundled Chromium
UI	React 18 + TypeScript	Type-safe, component-driven
Styling	Tailwind v4 + Radix UI	Accessible, themeable, fast
State	Zustand	No boilerplate, no Redux
Build	Vite 5	Fast dev, tiny production output
Packaging	`.deb` + `.AppImage`	Real Linux install methods

Tauri is the architectural decision that makes this whole thing possible. Electron apps ship a full Chromium + Node.js runtime — that's why they're 150–300MB. Tauri uses the system's existing WebKit renderer plus a thin Rust backend. Result: a real native app, 1/50th the size.

The Features That Actually Matter

I'm not going to give you a feature checklist. Here's what I use every day:

Real-time streaming — token by token, the way LLMs are meant to feel
Smart model picker with tier grouping (Frontier 70B+, Balanced 7–34B, Efficient <7B) and capability badges (vision, tools, thinking)
Drag & drop images into the chat — works with LLaVA, Qwen2-VL, LLaMA3.2-Vision
System prompt presets — Engineer, Writer, Analyst, Terminal, Concise
Pull and delete models from inside the app, with a live progress bar
Full model info — parameters, context length, quantization, size
Export conversations as Markdown or JSON
Light / Dark / System themes

The detail I'm proudest of: model switching is a dropdown, not a command. Sounds obvious. Try it after midnight and you'll understand.

3-Minute Setup

\`bash

1. Install Ollama (skip if you already have it)

curl -fsSL https://ollama.com/install.sh | sh

2. Pull a model

ollama pull llama3.2

3. Install Ollama Chat

wget https://github.com/itslokeshx/ollama-chat/releases/download/v1.0.0/Ollama.Chat_1.0.0_amd64.deb
sudo dpkg -i Ollama.Chat_1.0.0_amd64.deb

4. Start Ollama and launch

ollama serve &
ollama-chat
`\

That's it. No Docker, no Node, no web server, no localhost:3000.

The Numbers Don't Lie

App	Installed	RAM	Cold Launch
Open WebUI (Docker)	500MB+	~400MB	5–10s
Lobe Chat (npm)	100MB+	~200MB	2–4s
Msty (Electron)	250MB+	~300MB	2–3s
Ollama Chat	3.5MB	~50MB	<1s

3.5MB. I had to double-check. Then I triple-checked. Then I checked the .deb file size on disk and laughed.

Build It Yourself

It's MIT licensed, open source, and about 200 lines away from working:

\bash git clone https://github.com/itslokeshx/ollama-chat cd ollama-chat npm install npm run tauri dev \\

If you want a real .deb:

\bash npm run tauri build sudo dpkg -i src-tauri/target/release/bundle/deb/Ollama.Chat_1.0.0_amd64.deb \\

If You Try It

⭐ If this scratches an itch, a star on GitHub means a lot. And if something breaks — open an issue, I'll fix it.

I'm building this in the open. Roadmap lives on the repo: cloud model support, conversation sync, plugin system. If you want a feature, open an issue. If you want to build it, open a PR.

Now I want to hear from you: what's the most absurd dependency you've installed just to do something simple? I just want to feel less alone in this.

I Built My Own Spotify Because Every Music App Failed Me (Web App + Android APK, Solo)

Lokesh — Sat, 07 Mar 2026 10:07:14 +0000

I Rage-Quit a Music App at 1am. Then Built My Own Spotify. (React + Node + Capacitor + Groq AI)

Full-stack music streaming platform — web app + real native Android APK — built solo, shipped free. Here's every technical decision, every mistake, and every architecture choice that made it work.

🌐 Live: soul-sync-beta.vercel.app
📱 APK: Download SoulSync.apk
⭐ GitHub: itslokeshx/SoulSync

The Night That Started Everything

It was 1am.

I had 60 songs I wanted in one playlist. Tamil classics, Anirudh hits, a few AR Rahman deep cuts. The kind of playlist that takes you back somewhere.

So I opened the app and started:

Song 1.  Search → find → add. ✅
Song 2.  Search → wrong version → search again → add. ✅
Song 3.  Search → add. ✅
...
Song 48. 45 minutes in. 12 songs left.

I closed the app.
Put my phone down.
Went to sleep.

Woke up the next morning — still annoyed.

That annoyance built SoulSync.

Not inspiration. Not a market gap. Not a YouTube tutorial that said "build a music app." Pure, unfiltered frustration at 1am.

What Is SoulSync?

A full-stack music streaming platform that ships as both a web app and a real native Android APK — from a single React codebase.

Here's what it does that Spotify doesn't (or charges for):

Feature	SoulSync	Spotify Premium (₹119/mo)
AI playlist from song list	✅ Free	❌ Doesn't exist
Listen together + live chat	✅ Free	⚠️ Paid, no chat
Unlimited downloads	✅ Free	⚠️ Paid only
Offline without account	✅ APK only	❌ Never
Intelligent NLP search	✅ Free	❌ Literal only
Open source	✅ MIT	❌
Price	₹0. Forever.	₹119/month

The Full Stack

Frontend  → React 18 + TypeScript + Vite + Tailwind + Zustand
Backend   → Node.js + Express + MongoDB Atlas
Realtime  → Socket.io
AI        → Groq SDK + LLaMA 3.3 70B
Mobile    → Capacitor 6 (web → native Android APK)
Search    → JioSaavn API + 7-layer caching
Cache     → Upstash Redis
Deploy    → Vercel (frontend) + Render (backend)

One backend. One database. One auth system. Serves both the web app and APK.

Feature 1: The AI Playlist Builder (The Feature That Started Everything)

That 45-minute nightmare is now 10 seconds.

How it works

User pastes 100 song names
         ↓
Groq AI (LLaMA 3.3 70B) parses the list
         ↓
Generates optimized search query per song
         ↓
Parallel JioSaavn search (Promise.all — 10 concurrent)
         ↓
Confidence scoring: exact / partial / not found
         ↓
Named playlist handed back to user

The chunking problem

LLaMA has a context window limit. 100 songs in one shot causes hallucinations and timeouts. The solution: chunked processing.

const CHUNK_SIZE = 20
const MAX_CONCURRENT_GROQ = 3  // rate limit safe
const BATCH_DELAY = 500         // ms between batches

async function buildPlaylist(songs: string[]) {
  const chunks = chunkArray(songs, CHUNK_SIZE)
  const results: Song[] = []

  for (let i = 0; i < chunks.length; i += MAX_CONCURRENT_GROQ) {
    const batch = chunks.slice(i, i + MAX_CONCURRENT_GROQ)

    const batchResults = await Promise.all(
      batch.map(chunk => processChunkWithGroq(chunk))
    )

    results.push(...batchResults.flat())

    // SSE progress event to frontend
    emitProgress({
      processed: Math.min((i + MAX_CONCURRENT_GROQ) * CHUNK_SIZE, songs.length),
      total: songs.length,
      found: results.length
    })

    if (i + MAX_CONCURRENT_GROQ < chunks.length) {
      await delay(BATCH_DELAY)
    }
  }

  return results
}

SSE streaming so user sees progress in real time

Instead of a spinner for 30 seconds, users see a live progress bar:

// Backend — stream results as they come in
router.get('/build-playlist/stream', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream')
  res.setHeader('Cache-Control', 'no-cache')

  const send = (event: string, data: any) => {
    res.write(`event: ${event}\ndata: ${JSON.stringify(data)}\n\n`)
  }

  buildPlaylist(songs, {
    onProgress: (p) => send('progress', p),
    onChunk: (songs) => send('chunk_complete', { songs }),
    onComplete: (all) => {
      send('complete', { songs: all })
      res.end()
    }
  })
})

// Frontend — consume the stream
const source = new EventSource(`${BACKEND}/api/ai/build-playlist/stream?sessionId=${id}`)

source.addEventListener('progress', (e) => {
  const { processed, total, found } = JSON.parse(e.data)
  setProgress(Math.round((processed / total) * 100))
  setMatchCount(found)
})

source.addEventListener('chunk_complete', (e) => {
  const { songs } = JSON.parse(e.data)
  setSongs(prev => [...prev, ...songs])  // live list grows as songs are found
})

Result: User sees songs appearing one batch at a time, with a real progress bar. Not a fake loading animation.

Feature 2: SoulLink — Listen Together

Create a room → share a 6-character code → friend joins → everything syncs live.

The sync architecture

Host device                  Server                  Guest device
     │                          │                          │
     │──── duo:join ───────────▶│                          │
     │                          │◀─── duo:join ────────────│
     │                          │                          │
     │──── duo:sync-play ──────▶│──── duo:sync-play ──────▶│
     │                          │                          │
     │◀─── duo:message ─────────│◀─── duo:message ─────────│
     │                          │                          │
     │──── duo:heartbeat ──────▶│◀─── duo:heartbeat ────── │

The hardest problem: seek sync

When the host seeks to 2:34, the guest needs to jump to 2:34 + network latency. Without compensation, they're always slightly out of sync.

// Host sends seek with timestamp
socket.emit('duo:seek', {
  position: audio.currentTime,
  sentAt: Date.now()  // ping compensation
})

// Guest receives and compensates
socket.on('duo:seek', ({ position, sentAt }) => {
  const latency = (Date.now() - sentAt) / 1000  // seconds
  audio.currentTime = position + latency
})

It's not perfect — but it's imperceptibly close on good connections.

Feature 3: The Search That Went From 10s to 150ms

This was the biggest engineering challenge.

Why it was slow

Old flow (sequential):
  Query 1 → JioSaavn → wait 1200ms
  Query 2 → JioSaavn → wait 1200ms
  Query 3 → JioSaavn → wait 1200ms
  Query 4 → JioSaavn → wait 1200ms
  Total: ~4800ms minimum + debounce + Render cold start = 10s+

The 7-layer fix

Layer 0 — Startup warmup     → top 100 queries pre-cached at boot
Layer 1 — Client-side cache  → Map<query, result>, 5min TTL, ~0ms
Layer 2 — Debounce + Abort   → 150ms (was 400ms) + cancel inflight
Layer 3 — Redis smart cache  → normalized keys, ~5ms
Layer 4 — Parallel fetch     → Promise.allSettled, all queries at once
Layer 5 — SSE streaming      → first results visible at ~200ms TTFB
Layer 6 — Intent parser      → 5 targeted queries instead of 1 vague one
Layer 7 — Static index       → top 100 artists return instantly

The real fix: NLP Intent Parser

Speed alone wasn't enough. The search also needed to be intelligent.

The problem: "ranjini 173" is a Tamil movie. The old search sent "ranjini 173" to JioSaavn as a song name — 0 results.

The fix: an intent parser that classifies every query before searching:

type IntentType =
  | 'movie_songs'     // "ranjini 173", "leo songs", "kgf 2"
  | 'artist_recent'   // "latest anirudh", "new vijay songs"
  | 'artist_all'      // "arijit singh songs"
  | 'mood_search'     // "sad songs", "lofi tamil night"
  | 'bgm_search'      // "harris jayaraj bgm"
  | 'language_hits'   // "tamil hits 2025"
  | 'song_direct'     // exact song name

function parseIntent(query: string): ParsedIntent {
  // 1. Movie database check (500+ movies including "ranjini 173")
  const movieMatch = findMovieMatch(query)
  if (movieMatch) return { intent: 'movie_songs', movie: movieMatch }

  // 2. Artist dictionary (500+ aliases)
  // "arr" → "A.R. Rahman", "thalapathy" → "Vijay"
  const artist = findArtistMatch(query)
  if (artist) return buildArtistIntent(artist, query)

  // 3. Mood detection
  // "sad lofi" → expands to 5 mood variants
  const mood = detectMood(query)
  if (mood) return buildMoodIntent(mood, query)

  // 4. Language + era detection
  // "90s tamil hits" → year range + language filter
  return buildDirectIntent(query)
}

For "ranjini 173":

Intent: movie_songs
Expanded queries (all fired in parallel):
  1. "Ranjini 173 songs"          weight: 1.0
  2. "Ranjini 173 movie songs"    weight: 0.95
  3. "Ranjini 173 audio jukebox"  weight: 0.90
  4. "songs from Ranjini 173"     weight: 0.85
  5. (album search via separate endpoint)

Movie songs appear. Not a song titled "ranjini 173".

For "sad anirudh 2024":

Intent: artist_recent + mood
Artist: "Anirudh Ravichander"
Year: 2024
Mood: sad

Queries:
  1. "Anirudh Ravichander songs 2024"  weight: 1.0
  2. "sad Anirudh songs 2024"          weight: 0.95
  3. "Anirudh 2024 hits"               weight: 0.90
  4. "emotional Anirudh 2024"          weight: 0.85

Result timings

Client cache hit:     ~0ms   (repeat search same session)
Redis cache hit:      ~5ms   (server cached)
Cold query (TTFB):  ~200ms   (first results streamed)
Cold query (full):  ~600ms   (all results scored + ranked)
Before:           10,000ms+

Feature 4: One Codebase → Web App + Native Android APK

This was the decision that changed the whole project.

Why not React Native?

React Native would have meant:

Separate component library
Separate navigation (React Navigation vs React Router)
Separate state management patterns
Essentially rebuilding the entire app

Why Capacitor won

Capacitor wraps your existing web app in a native shell. Same React components. Same Zustand stores. Same backend calls. Native capabilities added via plugins.

React App (web)
     ↓
npx cap add android
     ↓
npx cap sync
     ↓
Android Studio → assembleRelease
     ↓
SoulSync.apk ✅

What native capabilities I added

import { Haptics, ImpactStyle } from '@capacitor/haptics'
import { Filesystem, Directory } from '@capacitor/filesystem'
import { Network } from '@capacitor/network'
import { LocalNotifications } from '@capacitor/local-notifications'

// Haptic on every song tap
await Haptics.impact({ style: ImpactStyle.Light })

// Download song to native filesystem
await Filesystem.writeFile({
  path: `songs/${song.id}.mp3`,
  data: base64Audio,
  directory: Directory.Data
})

// Network-aware offline mode
const status = await Network.getStatus()
if (!status.connected) setOfflineMode(true)

// Lock screen media controls
await LocalNotifications.schedule({
  notifications: [{
    title: song.name,
    body: song.artist,
    id: 1,
    extra: { type: 'now_playing' }
  }]
})

Platform detection pattern

import { Capacitor } from '@capacitor/core'

const isAPK = Capacitor.isNativePlatform()
const platform = Capacitor.getPlatform() // 'android' | 'ios' | 'web'

// Different storage per platform
const storage = isAPK
  ? new NativeFileStorage()    // Capacitor Filesystem
  : new WebStorage()           // IndexedDB

// Different audio URL handling
function getPlayableUrl(song: Song): string {
  if (isAPK && song.filePath) {
    return Capacitor.convertFileSrc(song.filePath)  // file:// → capacitor://
  }
  return song.streamUrl
}

Feature 5: Personalized Dashboard

Every session rebuilds from:

Your listening history (last 90 days, MongoDB TTL index)
Your language preferences (set at onboarding)
Time of day (morning = energetic, night = chill)

async function buildDashboard(userId: string): Promise<Section[]> {
  const [history, prefs, trending] = await Promise.all([
    getListeningHistory(userId, 90),  // days
    getUserPreferences(userId),
    getTrendingByLanguage(prefs.languages)
  ])

  const hour = new Date().getHours()
  const timeContext = hour < 12 ? 'morning'
                    : hour < 18 ? 'afternoon'
                    : hour < 22 ? 'evening'
                    : 'late_night'

  return [
    buildTimeSection(timeContext, history),         // "Morning Fresh"
    buildArtistSpotlight(history),                  // "Because You Listened"
    buildLanguageSection(prefs.languages, trending), // "Trending Tamil"
    buildRecentlyPlayed(history),
    buildRecommended(history, prefs),
  ]
}

The 5 Hardest Problems I Solved

1. Background audio on Android APK dying when screen locks

The web audio API pauses when the screen locks on Android. Fix: Capacitor's @capacitor-community/background-runner + a MediaSession API registration.

navigator.mediaSession.metadata = new MediaMetadata({
  title: song.name,
  artist: song.primaryArtists,
  artwork: [{ src: song.image, sizes: '512x512' }]
})

navigator.mediaSession.setActionHandler('play', () => audioRef.current?.play())
navigator.mediaSession.setActionHandler('pause', () => audioRef.current?.pause())
navigator.mediaSession.setActionHandler('nexttrack', () => playNext())
navigator.mediaSession.setActionHandler('previoustrack', () => playPrev())

2. Offline playback notification not working

The original code had this guard:

// Bug: this silently killed offline notifications
if (!song.streamUrl) return
showNowPlayingNotification(song)

Offline songs have filePath, not streamUrl. Removing that guard and using getPlayableUrl() fixed it.

3. Search cache key collision

"sad arijit" and "arijit sad" should hit the same cache. The fix: normalize by sorting words alphabetically.

function normalizeKey(query: string): string {
  return query
    .toLowerCase()
    .trim()
    .replace(/[^\w\s]/g, '')
    .split(' ')
    .filter(Boolean)
    .sort()           // ← the critical line
    .join('_')
}

// "sad arijit"  → "arijit_sad"
// "arijit sad"  → "arijit_sad"  ✅ same key

4. Groq rate limits with 100 songs

5 API keys in rotation, checked before each request:

const GROQ_KEYS = [
  process.env.GROQ_KEY_1,
  process.env.GROQ_KEY_2,
  // ...
]
let keyIndex = 0

function getGroqClient() {
  const key = GROQ_KEYS[keyIndex % GROQ_KEYS.length]
  keyIndex++
  return new Groq({ apiKey: key })
}

5. Socket.io rooms leaking memory

Rooms weren't being cleaned up when users disconnected. After 48 hours the server would slow to a crawl.

socket.on('disconnect', () => {
  const room = getRoomForSocket(socket.id)
  if (!room) return

  room.members.delete(socket.id)

  if (room.members.size === 0) {
    // Last person left — clean up completely
    activeRooms.delete(room.code)
    console.log(`Room ${room.code} cleaned up`)
  } else {
    // Notify remaining members
    socket.to(room.code).emit('duo:member-left', { socketId: socket.id })
  }
})

What I'd Do Differently

1. Redis from day one, not an afterthought.
I added caching after the search was already "working" at 10 seconds. If I'd designed the cache layer first, the search would have been fast from the start.

2. Intent parser before building the search UI.
I built the search UI for a simple text match, then had to refactor it when I realized literal string matching was useless for natural language queries.

3. Capacitor from day one.
I built the entire web app first, then added Capacitor. It worked, but there were 2-3 days of fixing things that broke in the native context (audio, storage, network detection). Designing with Capacitor in mind from the start would have been cleaner.

4. SSE instead of polling for playlist building.
I used polling for the first version of the AI playlist builder (setInterval every 2 seconds checking if it was done). SSE was a 2-hour rewrite that made the experience 10x better.

Performance Numbers

Search (cold, intent-matched):    ~600ms  (was 10,000ms+)
Search (Redis cache hit):           ~5ms
Search (client cache hit):           ~0ms
AI Playlist (100 songs):           ~18s   (streamed, first results at ~3s)
SoulLink room creation:            ~120ms
Page load (Vercel edge):           ~800ms
APK cold start:                    ~1.2s

What's Next

[ ] Play Store submission (APK is signed and ready)
[ ] Lyrics sync display
[ ] iOS build (Capacitor makes this straightforward)
[ ] Audio visualizer on the full player
[ ] Push notifications for new releases from followed artists

Try It

🌐 Web app: soul-sync-beta.vercel.app

📱 Android APK (best experience, direct install):
SoulSync.apk

⭐ Star on GitHub:
github.com/itslokeshx/SoulSync

The Takeaway

The best product you'll build isn't the one with the best market research.

It's the one where you woke up the next morning still annoyed.

That's your signal.

Questions about any part of the architecture? Drop them in the comments — happy to go deep on anything. 🎧

I Built a "Second Brain" That Actually Thinks 🧠 — with GitHub Copilot CLI

Lokesh — Sat, 14 Feb 2026 15:17:26 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

🛑 The Problem: I Was Drowning in "Productivity"

It was 2 AM. My desk was a mess.

I had 14 browser tabs open. A Notion doc I hadn't touched in weeks. A Todoist list that was mocking me. A goal I set in January that was already dying quietly.

I was drowning in tools that were supposed to save me. I realized I didn't need another "to-do list." I didn't need a static database.

I needed a brain.

So, I opened my terminal, cleared the screen, and typed:

gh copilot suggest "How do I build a life operating system where tasks, habits, and goals share a single consciousness?"

7 days later, I shipped CorteXia.

🚀 What is CorteXia?

CorteXia isn't just an app; it is an AI-Powered Life Operating System. It combines the flexibility of Notion, the visual beauty of Linear, and the intelligence of a personal assistant into one unified workspace.

But here is the killer feature: It talks back.

💎 The "Superpowers"

🗣️ Voice-First Control: I used the Web Speech API so you can talk to your dashboard. "Hey, I just spent $15 on coffee." Boom. Budget updated.
🧠 Persistent AI Memory: It doesn't just answer; it remembers. It knows your name, your deadlines, and that you're trying to quit sugar.
🔥 The "GitHub" for Habits: A 365-day contribution graph for your life habits. Because if it's not green, did it even happen?
🕸️ The Neural Network: Tasks are linked to Goals. Expenses are linked to Budgets. Moods are linked to Productivity. Everything is connected.

👇 Give it a Try!

I poured my heart (and a lot of coffee) into this.

🚀 Try the Live Demo
⭐ Star the Repository on GitHub

(P.S. Try the Voice Mode. It feels like magic. ✨)

My Experience with GitHub Copilot CLI

I’m Lokesh A, a third-year Computer Science Engineering student focused on full-stack development.Building real time projects!

This wasn’t just CRUD. It was a Next.js 16 + MongoDB (12 Collections) + AI-powered system with deeply connected logic.

GitHub Copilot CLI became my force multiplier.

Architecture

Designing a high-performance, bidirectional schema for Tasks, Goals, and Habits required system-level thinking.

gh copilot suggest "Design a Mongoose schema optimized for dashboard-heavy reads with bidirectional references"

It didn’t just generate code — it explained embedding vs referencing trade-offs and helped me make better architectural decisions.

AI Context Strategy

To avoid token overflow while injecting live user data into the LLM:

gh copilot explain "Inject relevant user data into an LLM without exceeding token limits"

It guided me toward a selective context strategy (today’s tasks + active goals only), which shaped the AI design.

Debugging

When optimistic UI updates caused duplicate entries:

gh copilot explain "React optimistic update causing duplicate keys when toggling quickly"

It identified the need for debouncing and helped structure a clean solution.

Copilot CLI didn’t replace my learning.
It accelerated it.

It helped me think bigger, ship faster, and build with more confidence.

🛠️ The Tech Stack (Vibe Coding Edition)

Framework: Next.js 16 (App Router + Turbopack)
Language: TypeScript 5 (Strict Mode)
Database: MongoDB Atlas (12 Collections)
Styling: Tailwind CSS + Framer Motion (for those buttery smooth 60fps animations)
AI: Multi-LLM Fallback System (Groq + OpenAI)
Voice: Native Web Speech API

🔮 The Bigger Picture

We talk a lot about AI replacing developers. After building CorteXia, I believe the opposite.

Copilot CLI didn't replace my creativity; it accelerated it. It handled the boilerplate, the schema validation, and the obscure regex patterns, so I could focus on User Experience and Logic.

CorteXia went from a "weekend idea" to a production-grade application in record time.

That's not AI replacing a developer.

That's a developer with a superpower.

I Built a Portfolio Like a System, Not a Résumé!

Lokesh — Wed, 21 Jan 2026 16:48:13 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

Hi, I’m Lokesh — a frontend-focused web developer with growing full-stack experience.

I don’t learn best by memorizing theory or following tutorials blindly. I learn by building, testing, breaking, and refining real systems.

Over time, I realized that a traditional portfolio page doesn’t truly represent how I think or how I grow as a developer. So instead of creating another résumé-style website, I treated this portfolio as a living system — one that reflects my workflow, my decisions, and my evolution.

This project isn’t about perfection. It’s about process, intention, and progress.

Portfolio

🔗 Live Portfolio (copy-friendly link):
https://itslokeshx.vercel.app/

📂 Source Code — GitHub Repository

Explore the full source code of this portfolio, including components, styles, and deployment configuration:

👉 https://github.com/itslokeshx/portfolio

How I Built It

This portfolio was planned first, designed with AI, and developed with AI as a collaborator — not as a shortcut.

🎨 Design (Google Stitch AI)

Used Google Stitch AI to explore layout direction, hierarchy, and interaction tone.
Focused on clarity over decoration.
The system-style interface mirrors how I naturally reason through problems.

🧩 Development (Google Antigravity)

Built using Google Antigravity as an AI-assisted development environment.
AI helped with architecture thinking, component structuring, and refactoring.
Every final decision — layout, logic, and behavior — was intentional and human-driven.

⚙️ Stack & Infrastructure

React / Next.js
Framer Motion for subtle interaction feedback
Docker for containerization
Google Cloud Run for deployment:
- Containerized build
- Scale-to-zero when idle
- Free-tier safe configuration
- Production-ready setup

Instead of using many tools, I focused on using fewer tools well.

What I'm Most Proud Of

Treating a portfolio as a system that explains how I think, not just what I’ve built.
Designing with restraint instead of visual overload.
Successfully containerizing and deploying on Google Cloud Run.
Keeping performance, simplicity, and cost under control.
Being honest about my current level while clearly showing growth.

This portfolio reflects how I want to build software going forward:

Thoughtfully. Iteratively. With intention.

🙏 Thanks to the DEV Community and Google AI team for creating a challenge that encourages experimentation, reflection, and responsible use of AI.