initially the thought of this was pretty stressful, but being a good solutionist i proceeded with dicecting the issues one by one and presistent on finding a solition for them all.

The first thing is prioritizing platoforms, The stats were clear hence shared them with my manager, got iOS, Android prioritized in order and parked Windows for later as usage is extremly low. now the priority is set to the next thing.

The problem was not the workload. it was the cognitive overhead. i can barely understand my own code after a few months. here i am inheriting code from 6-7 people who clearly took shortcuts to ship fast. folder structure was a dump. files everywhere. and on top of reverse-engineering three codebases i had to track what is done, what is next, what is blocked: simultaneously, across all platforms this task alone without AI would be a real pain and would def take more than few months.

I opted to the $20 Claude subscription. so every session i was wasting the first chunk of context re-explaining the same codebase to Claude, re-orienting it to where i left off, re-answering questions it should already know. by lunch i was running out of tokens i had to use my colleague’s accounts to do whole thing again (Thanks Arun!)

out of this mess i needed a single place. one terminal. one browser tab. one AI session that already knows everything and picks up exactly where we left off, an interface for me and claude to read/update/learn about the project im working and it has to be highly structured, organized and prioritized.

so i built one. i call it the Command Center. if you have any other name to suggest, my inbox is open. this post is the full breakdown of what it is, how it works, and how you can shape it for your your own structure if you ever are in that spot, a little future pridction i think by the end of 2026 we all might have to work in this kind of set-up working on multiple projects simultaniously or atleast we will be capabble of that level of productivity.

What is this AI-Command Center

the idea is simple. instead of having our docs, tasks, changelogs in multiple apps and your terminal tabs scattered across screens for different platforms wokfing with different stages of the tasks or even totally different task altogether: and your daily runner claude-code has no means to know about all these instead you put a single shared operational layer above all your repos. not inside them. above them hence the term command center.

MyWorkspace/
├── ios/               ← own git repo, untouched
├── ios-dataKit/       ← own git repo, untouched
├── android/           ← own git repo, untouched
├── win/               ← own git repo, untouched
└── .ops/              ← Command Center (its own git repo)
    ├── docs/          ← documentation per project
    ├── todo/          ← task files per project + daily focus
    ├── memo/          ← decisions, KT notes, research
    ├── diagrams/      ← architecture diagrams + companion notes
    ├── changelog/     ← per-project ship history
    ├── scripts/       ← automation scripts
    └── dashboard/     ← local web dashboard

Don’t worry the project folders stay completely independent. git -C ios/ status never bleeds into git -C android/ status. you can add or remove a project folder without touching anything else, this is very important sepearation for corporate repositories where the restrictions are tight.

almost everything in .ops/ is a markdown, here is where it might looks like the WiKi pattern shared by the Andrej Karpathy. it is readable by me and the AI, diffs cleanly, and has zero dependencies you can stop here is you want a bare simple command-center but if you are like me this is not enough and there are many flaws here like doc’s going stale as we make changes so lets get to the text stage.

The scripts are the real MVP

As i said earlier i still use the 20$ subscription so for me tokens are really valuable running out of limit means one less productive day that might gift me a day of guilt so making use of scripts to save some routine commands that im sure will be helpful for claude to not be too dependent on remote calls, it might be confusting so here is example:

when i ask Claude “what is the git status across all my repos?” Claude tries to figure it out by calling tools one at a time burning tokens on reasoning and multiple tool calls to give me accurate and proper response

but if you have a script that does it:

# .ops/scripts/git_status_all.sh
for dir in android ios ios-dataKit ios-textEditor win; do
    branch=$(git -C "$ROOT/$dir" branch --show-current 2>/dev/null)
    changes=$(git -C "$ROOT/$dir" status --porcelain | wc -l | tr -d ' ')
    if [ "$changes" -gt 0 ]; then
        echo "● $dir — $branch ($changes uncommitted)"
    else
        echo "● $dir — $branch (clean)"
    fi
done

Claude runs the script. gets the answer in one shot. no reasoning, no guessing, no tool call loop you don’t have to write this manually you can just ask it to do, just make sure you get the code though.

the scripts i have accumulated up over time:

the pattern is always same: take something that would require Claude to do many tool calls or make assumptions, turn it into one script, let Claude just run it and read the output. you get a more reliable answer and you spend a fraction of the tokens.

the session_context.sh one is worth explaining. it runs as a session-start hook and injects the project context automatically before i type anything:

=== SESSION BRIEFING (2026-04-26) ===

REPOS
  ios          dev_eganathan   clean
  android      dev_eganathan   clean
  ios-dataKit  dev_eganathan   14 uncommitted  ← needs attention

HIGH PRIORITY (ios)
  - sessionId hardcoded as "" (TIBConverseInteractor.swift:83)
  - Localization migration uncommitted

LAST SESSION: 2026-04-22 — ios folder restructure, Settings flatten done
DOC SYNC: 8 stale docs — run /sync
=====================================

this replaces re-explaining the codebase every session. the entire briefing is generated from actual file state and costs about 100 tokens to inject i shared only a small portion of this but it basically added more relavant contexts that im sure will help claude so compare that to the 500–1000 tokens you’d spend manually orienting Claude each time.

Documentation that doesn’t go stale

the biggest problem with docs is they go stale the moment you stop actively maintaining them. and the honest truth is most people stop maintaining them pretty quickly.

so instead of relying on discipline, i wired it into the workflow. every doc has frontmatter that declares what code it describes:

---
project: ios
watches: ios/Features/Inbox/**, ios/Core/Network/**
lastVerified: a3f9c12
verifiedDate: 2026-04-20
---

watches is a glob pattern over source paths. lastVerified is the git commit hash when i last checked this doc.

doc_sync.js runs at session start: diffs lastVerified against HEAD per project, filtered by watches. if watched files changed, the doc is flagged stale. you get a list of exactly which docs need attention — not all of them, just the ones where the underlying code actually changed.

the workflow: read the diff, update the doc if needed, run --mark-current to stamp it with the new HEAD. stale docs are a session-start action item, not a quarterly effort.

one more thing worth building: a doc_sync_prompt.md template. when doc_sync.js flags a doc as stale, you need to give Claude a consistent prompt for reviewing it. the template fills in {{DOC_PATH}}, {{GIT_DIFF_STAT}}, {{CHANGED_FILES}}, and {{DOC_CONTENT}} — Claude reads the diff, decides what changed, updates only what is wrong or outdated, and preserves the frontmatter format. without a template you end up writing a different prompt every time and the quality of the review varies. one template file in scripts/, referenced whenever /sync runs.

Task management across platforms

one file per platform. ios_todos.md, android_todos.md, win_todos.md. same structure in all of them:

## High Priority
- [ ] Fix session ID bug in TIBConverseInteractor.swift:83

## Medium Priority
- [ ] Add unit test target

## Low Priority
- [ ] Refactor legacy auth flow

## Completed
- [x] 2026-04-20 — Migrated Localizable strings

there is also daily.md — today’s focus, separate from the long-running backlogs. daily_reset.sh resets it each morning, carries over anything incomplete from yesterday, and pulls the top items from each project’s High Priority section so you are never starting from blank. at end of day you move done items back to the project file and carry over the rest.

it is not rocket science but it works because everything is in one place and Claude can read all of it directly — no context switching, no “go check Linear”, no copy-pasting.

Memos, KT notes, and changelogs

these three are the most underrated parts of the system. they get skipped when people think about “what does an AI need to know” but they are exactly what the AI is missing when it gives you advice that misses context.

Memos (memo/) are for anything that does not fit in a doc or a todo. decision logs, architecture choices, research, migration plans, meeting outputs. the key thing about a memo is it captures the why. a doc says “the auth middleware works like this”. a memo says “we rewrote the auth middleware because legal flagged the session token storage in April”. without the memo Claude treats every piece of code as a deliberate, still-valid decision. with the memo it knows what is intentional and what is technical debt inherited from a compliance scramble.

KT notes (memo/kt/<platform>/YYYY-MM-DD_topic.md) are specifically for inheriting a codebase. when someone does a knowledge transfer session, you write it up here. when you figure out something non-obvious about how the code works, you write it up here. these are the things that would take a new person weeks to discover by reading code — undocumented conventions, “we don’t touch that file because”, quirks of the build system, context behind a weird architectural choice. writing them down once means Claude knows them forever.

Changelogs (changelog/<project>.md) are append-only per-project ship logs:

| 2026-04-15 | Migrated inbox to VIPER          | PR #441 |
| 2026-04-08 | Upgraded to AGP 8.3              | PR #438 |
| 2026-03-22 | Added push notification handling | PR #421 |

one row per notable change. the practical use: “did we ship X on all platforms yet?” — you check the changelog instead of grepping git history across five repos. also useful at standup when someone asks what shipped last week.

The local web dashboard

the dashboard is a local Node.js server. no framework, no build step, runs offline, starts in two seconds.

node .ops/dashboard/server.js
# opens at localhost:3000

File browser — tree sidebar over all docs, todos, memos. files render as Markdown. todo files have live checkboxes — clicking one calls POST /api/toggle and writes the change directly to disk.

Git status panel — polls all repos in parallel. branch, last commit, time ago, dirty file count.

Full-text search — index built at startup from every .md, .txt, .sh file. AND-matched with scoring. returns results with line-number snippets. useful when you remember something exists but can not remember which doc it is in.

Doc staleness indicators — green/yellow/red dots next to each doc in the sidebar based on doc_sync.js output. a resync button re-runs the script and refreshes the cache.

Task creation — a form on every page to add a todo at any priority level to any project. finds the right heading and inserts the item, updates the Last updated: stamp.

Shape it to your problems — the CMD tabs and RSS feeds

here is the thing: everyone’s pain is different. the folder structure and scripts above are the common base. but the reason this actually works day-to-day is that you can add whatever else you actually need on top.

for me, the two things i added that made the biggest difference:

CMD view — xterm.js + node-pty over WebSocket. a real terminal embedded in the browser, one tab per project. each tab opens a PTY session in that project’s directory. per-project quick-command buttons — you configure a label and a shell command, they appear as buttons above the terminal. so Build Debug runs ./gradlew assembleDebug in the Android tab. Sync Pods runs pod install in the iOS tab. i click once, watch it run. no switching windows, no remembering the exact command flags.

before this i was constantly switching terminal windows and losing track of which one was which. now everything is in one browser tab.

RSS feeds / newsletters — each platform has its own dev newsletter and release channel. iOS dev forum, Android releases, Kotlin blog. i added an RSS tab. feed URLs live in a feeds.json file, keyed by platform:

{
  "ios": [
    { "label": "iOS Dev Weekly", "url": "https://iosdevweekly.com/issues.rss" },
    { "label": "Swift Blog", "url": "https://swift.org/atom.xml" }
  ],
  "android": [
    { "label": "Android Developers Blog", "url": "https://feeds.feedburner.com/blogspot/hsDu" }
  ]
}

the server fetches them server-side (handles redirects, CDATA stripping), renders as cards per platform. i stop by when i want to catch up. no separate app, no subscriptions, no algorithm deciding what i see — just the feeds i actually want, inside the same tab i already have open.

neither of these exist in anyone else’s command center because they are solving my specific workflow pain. the point is the base layer gives you the foundation. the top layer is yours to build.

other ideas i have seen or thought about that i haven’t built yet: a meeting notes tab that auto-stamps today’s date, a platform-specific analytics panel, a PR review queue for when you work with a team.

The two-tier AI model

the local web dashboard has a built-in AI chat powered by Mistral 7B via Ollama — not Claude. this is the layer that routes cheap questions away from the cloud.

the RAG pipeline:

question
   │
   ▼
embed ──► LanceDB vector search ──► top-k doc chunks
                                          │
                                          ▼
                             Mistral 7B ◄── context + question
                                          │
                                          ▼
                                    streamed answer
                               (with source file citations)

at startup the server walks all docs, chunks them, embeds them and stores the index in LanceDB. conversation history (last 12 turns) is passed with each request. topics can be filtered per platform.

but here is the part that matters more — the local model is also wired directly into Claude as an MCP tool. not just the dashboard chat, but Claude itself can call it:

search_docs(query, project?)  — semantic search over the LanceDB index
ask_local(question, project?) — full RAG query to Mistral 7B

so when you ask Claude “where is the WebSocket manager?” Claude does not think about it, does not run three tool calls, does not burn tokens. it calls ask_local, gets the answer back from the local model as a tool response, and continues. the routing decision is encoded in CLAUDE.md as explicit rules so it happens automatically:

You
 │
 ├── Complex reasoning ──────────────────► Claude (API tokens)
 │    debugging, architecture,
 │    multi-file refactoring, codegen
 │
 └── Lookups + summaries ──► local MCP ──► Mistral 7B (free, local)
      "where is X?", todos,
      file summaries, templates

questions that go local: “where is ClassName defined”, “what files are in folder X”, “summarise this file”, “what todos are open for Android”, “what is the VIPER template for a new scene”, anything answerable by reading the existing docs.

questions that use Claude: multi-file refactoring, debugging across call chains, cross-platform analysis with real reasoning, writing new features.

in practice around 60–70% of session queries route to the local model. those run free on my machine. Claude gets the work that actually needs it.

Tracking what you saved

there is one more hook worth adding: a PostToolUse hook on the local MCP calls. every time Claude calls ask_local or search_docs, a small Python script logs the call to a token_savings.jsonl file with a timestamp, the tool used, and an estimated token count saved:

{"ts": "2026-04-26T10:32:11", "tool": "ask_local",    "estTokensSaved": 400}
{"ts": "2026-04-26T10:33:45", "tool": "search_docs",  "estTokensSaved": 250}

the same hook also outputs a reminder back into Claude’s context: “you just used the local model — append [tib-mcp-info] to the sentence in your response that came from this result.”

that [tib-mcp-info] tag in the response is how you know which parts Claude answered from local knowledge vs the local model. it is easy to skip but worth keeping — after a few weeks you can look at the JSONL and get a rough sense of how many tokens the routing saved. it also keeps you honest about whether the local model is actually being used or whether Claude is quietly doing everything itself.

The session cache — picking up exactly where you left off

the session briefing knows “what was worked on last session” because /callitaday writes a session_summary.json at the end of each day. the structure:

{
  "date": "2026-04-22",
  "platform": "ios",
  "done": [
    "Settings flatten complete — SettingsSUI/NewUI/Settings_base merged into Features/Settings",
    "Helpers restructured — Contacts moved to Features/Contacts"
  ],
  "carriedOver": [
    "Android: edge to edge mandate for Play Store — not checked yet"
  ],
  "decisions": [
    "Contacts gets Features/Contacts/ not buried in Helpers",
    "URLSchemeAnalyser lives in Core/DeepLinker/"
  ],
  "openQuestions": [
    "CustomContextMenu still needs to move to Features/Inbox/Actions/"
  ],
  "keyFiles": [
    "native/TeamInbox.xcodeproj/project.pbxproj",
    "native/TeamInbox/Features/Settings/"
  ]
}

next morning, session_context.sh reads this file and includes the done, carriedOver, decisions, and openQuestions fields in the briefing. Claude starts the session knowing exactly where things were left — no re-reading git log, no “what were we working on?”. the keyFiles field is useful if you want Claude to immediately orient to the relevant parts of the code.

/callitaday is the slash command that writes this. it wraps the session: moves done items from daily.md back to the project todo files, carries over incomplete items, writes the JSON. it is the last thing you run before closing the terminal.

Setting this up yourself

the minimum version of this is five files and an afternoon:

1. create a parent workspace folder above all your repos
2. add a .ops/ folder with docs/, todo/, memo/, scripts/
3. write a CLAUDE.md at the workspace root — folder layout, git command prefixes, working conventions, routing rules
4. write session_context.sh or a simple briefing script that runs git -C <project>/ status across all repos and prints a summary — hook it to session start
5. write one doc per project covering the folder structure and architecture, add the watches frontmatter

that is the base. that alone kills the “re-explain everything every session” problem and the “docs live in Notion somewhere” problem.

layer on top in order of payoff:

• daily_reset.sh and the daily.md workflow — probably adds the most to day-to-day sanity
• doc_sync.js — if you are writing docs and want them to stay honest
• the dashboard — once you want a visual layer over all of it
• the CMD tabs — if you are constantly switching terminal windows for the same commands
• the local model + MCP — when token pressure is real and your doc library is large enough to justify a RAG pipeline

do not build all of it at once. start with the folder structure and the CLAUDE.md. add the rest as you actually feel the pain they solve.

What changed

before: open the right repo in Xcode, find the right Notion page, check Slack for where i left off, re-explain the codebase to Claude, watch the first 30% of my context window fill with boilerplate before writing a single line of actual code.

after: one terminal, one browser tab, one Claude session. the Command Center has the state of every repo, every doc, every task, every recent decision — and the cheap questions never reach the cloud.

the whole system is about 1,500 lines of Node.js, a handful of shell scripts, and Markdown files. no heavy dependencies, no cloud services, runs entirely offline.

if you are managing more than two active repos and you are constantly re-orienting your AI every session — this pattern is worth trying. you do not have to build the whole thing. start with the folder structure and a CLAUDE.md. that alone will change how your sessions feel.

the rest you will figure out as you go, shaped around whatever is actually slowing you down. that is the point.

a note on this post — the ideas, the frustration, the architecture, the decisions are all mine. i used Claude to help structure and articulate things i already knew but was too lazy to write out properly. felt right to mention it given the whole post is about working with AI. use your tools.

after writing this i came across andrej karpathy’s wiki pattern — same instinct around plain files, single source of truth, readable by humans and machines. worth looking up if this resonated.

Presenting the Solutionist Mindset on stage

Standing on that stage at DevFest2025 in Chennai, looking out to you all, I asked a simple question: “How many of you are worried about AI taking over your job?”

The show of hands was overwhelming (some shared why they are confident too, I wish I was them). The anxiety in the room was palpable.

I get it. I’ve been there. In fact, I’m still navigating these waters myself. As an Android Developer at Zoho, I’ve watched AI tools evolve from curiosities to formidable coding partners. They’re impressive—spitting out code 10 to 100 times faster than we can. It’s almost unsettling, watching something produce in minutes what would take us hours or days.

The predictions are scary. The layoff numbers are even scarier. Tech Twitter is full of doom-scrolling material about how AI will replace developers, how junior positions are vanishing, how the barrier to entry is impossibly high now.

So I did what any rational person would do—I took a step back and contemplated this deeper.

What’s the worst thing that can happen to me?

And then I realized something profound: I’ve been through worse.

Rock Bottom: Varanasi, December 2017

Let me share something deeply personal with you. Something I don’t talk about often, but something that fundamentally changed how I approach adversity.

In December 2017, my life fell apart.

Not in the dramatic, movie-like way—but in the quiet, suffocating way that creeps up on you. Emotionally stuck, I watched as friends I believed would be with me forever just… disappeared. The community I had built my identity around crumbled. My entire belief system, everything I thought I knew about life and relationships, shattered.

Losing all hope, I set out on what I genuinely thought would be my final journey: to Varanasi.

The Ghats of Varanasi

I spent weeks alone at the ghats with almost nothing. It was the coldest winter I’ve ever experienced, and I wasn’t prepared—not physically, not mentally, not emotionally.

Surviving on just one meal a day at a nearby temple, I would spend my days sitting by the river, gazing into the Ganges in silence. The helplessness, the solitude—it was unlike anything I had ever known before. Even now, years later, I struggle to put that experience into words.

Imagine this: You’re standing at the crossroads of chaos. Motion swirls all around you—boats on the river, pilgrims performing rituals, the constant murmur of life and death existing side by side. Yet despite all this movement, you’re paralyzed. You can’t decide where to step next. Your mind feels numb. The whole experience is so overwhelming that language itself becomes inadequate.

But here’s what that experience taught me: Clarity doesn’t come from escaping pain. It comes from sitting with it, accepting it, and taking it in as a lesson from the universe.

When you’ve sat at the ghats of Varanasi, contemplating the impermanence of everything while watching funeral pyres burn and pilgrims bathe, the fear of losing a job to AI becomes… manageable. Not trivial—but definitely manageable.

Fast Forward: Finding Auroville

After a few more reality checks and life lessons (because apparently, Varanasi wasn’t enough), I came across Auroville and its unique philosophy around money and community living.

For those unfamiliar, Auroville is an experimental township in Tamil Nadu, founded on the principles of human unity, sustainable living, and spiritual evolution. Their approach to money and work fascinated me—the idea that work should be about contribution, not just compensation.

I felt drawn to it. It seemed like a place that resonated with what I was searching for—a new way of living, a new framework for understanding my place in the world.

Reality Meets Philosophy

When I arrived, I realized that while the philosophy was inspiring, it was still very much a work in progress—an idea in the process of becoming real. The gap between the ideal and the reality was significant. But you know what? That’s okay. That’s how all great experiments work.

Yet, amidst that gap, I found something invaluable: a warm, accepting community and my very first job at a busy guest house.

I started as a waiter. Then I worked my way up—biller, receptionist, whatever was needed. Each role taught me something new about human interaction, problem-solving, and the simple dignity of work.

It was genuinely educative in ways a classroom never could be. I learned about hospitality, about managing stress during rush hours, about the intricate dance of keeping customers happy while maintaining operational efficiency.

But there was one problem that bugged me daily, especially at the billing counter.

My First Solution: The Python Calculator

Restaurants in Auroville had unique discount structures that reflected their community-oriented values:

• 10% off for volunteers
• 20% off for Auroville residents
• Plus 5% GST for regular guests

Simple enough, right? Except during rush hours, when we had to calculate all this manually using a calculator.

Picture this: It’s lunch rush. The kitchen is yelling that orders are backing up. Customers are waiting, getting increasingly impatient. You’re trying to calculate percentages on a basic calculator while keeping track of multiple bills, and someone changes their mind about their order halfway through.

It was absolute chaos.

So, I did something I had never done before—I wrote a simple Python Tkinter app to simplify this process.

The Joy of Building Your First Solution

Now, to any experienced developer reading this, a Python Tkinter calculator probably sounds laughably simple. And it is. But back then, for someone with minimal programming experience, it was transformative.

It took me a couple of days and several iterations. The first version was buggy. The UI was ugly. But it worked. And during the next busy lunch rush, it saved my sanity.

This was my first real solution. Not a tutorial project. Not a homework assignment. A real problem, solved with real code, that helped real people.

Looking back now, it’s not sparkly or impressive. I wouldn’t put it in my portfolio. But it was a huge milestone in my journey. It empowered me to believe that I could build tools to solve problems.

The AI Comparison

Here’s the kicker: If I faced the same problem today, with access to Claude, GPT-4, or Copilot, it would take me 5 minutes or less to build the same thing. Probably better, with proper error handling and a cleaner UI.

That’s both amazing and terrifying. Amazing because of the productivity boost. Terrifying because if I were starting my journey today, would I have learned the same lessons? Would I have struggled enough to truly understand the fundamentals?

This is the paradox we’re living in.

The Bootcamp: Zoho Schools of Graduate Studies

After a while working at the restaurant, things were getting repetitive. I could do the job in my sleep. The initial learning curve had flattened out completely.

Then, I was given an opportunity to participate in the Zoho Schools of Graduate Studies (ZSGS)—a pilot 3-month fast-track program into software development.

There were interviews. There were coding tests. There were problem-solving assessments.

But you know what stood out during my interview? That custom calculator project I built to solve the billing problem.

It wasn’t the fanciest project. It wasn’t built with the latest framework or deploying cutting-edge architecture. But it demonstrated something crucial: I could identify a problem and build a solution.

The Underdog Journey

With a few more rounds of interviews and small projects, I was accepted into the program. But here’s the thing—acceptance didn’t guarantee employment at Zoho. It just meant you’d get direct interviews if there were openings afterward.

And I wasn’t under any illusion about my chances.

I was the only individual with just an SSLC (10th grade) certificate among some incredibly bright minds with degrees in Computer Science, Electronics, Mathematics, and various other technical streams. On paper, I was the least qualified person in that room.

But I knew one thing: I could give my absolute best and absorb everything like a sponge.

I was like a thirsty man stumbling upon an oasis—desperate to quench my thirst by learning everything I possibly could.

The Learning Environment

The program was intense. We learned data structures, algorithms, software design principles, databases, and practical software development. But more than the technical content, it was the mindset shift that mattered.

My mentors didn’t just teach me how to code—they taught me how to think. How to break down complex problems. How to ask the right questions. How to learn independently.

The other students, despite their impressive credentials, were incredibly supportive. We learned from each other, challenged each other, and grew together.

Thanks to my mentors and the collaborative environment, I managed to not just survive, but thrive.

The Interview

And the first team that interviewed me at the end of the program? They took me in.

Not because of my credentials (I had none). Not because of my degree (I had none). But because I demonstrated the ability to learn, adapt, and build solutions.

That’s how I became part of this wonderful tech world. Not through traditional credentials, but through small projects, relentless learning, and incredible mentors who saw potential where others might have seen only limitations.

A Glimpse of Tech Life

After joining a team at Zoho, I slowly started getting accustomed to this new life—realizing how incredibly fortunate I was to be on an autodidactic journey that felt like a dream.

Learning, growing, and getting paid for it? It seemed almost too good to be true.

The Difference from Previous Jobs

Unlike any job I’d had before—waiter, receptionist, biller—this one was fundamentally different. Everything I learned for work actually empowered me personally. It felt like one of those rare systems where the more you give, the more you grow.

It was like tending a bonsai tree—carefully shaped by external constraints and guidance, yet every bit of effort you put in feeds your own roots, strengthens your own foundation.

I was getting paid to:

• Learn new technologies
• Experiment with different approaches
• Build features that many would use
• Solve genuinely interesting problems

It felt unreal. It felt like the job I had dreamed about during those cold nights in Varanasi.

The Honeymoon Phase

For a couple of years, it was blissful. The learning curve was steep but manageable. Android development was evolving rapidly—Kotlin was gaining traction, Jetpack Compose was being introduced, and the ecosystem was thriving.

I threw myself into it. I learned Kotlin inside and out. I became proficient in Android architecture patterns. I contributed to significant features in our products.

For a while, I felt secure. I had carved out expertise. I had value.

And then… the AI wave hit.

Then AI Happened

ChatGPT launched in November 2022. At first, it was a curiosity. We played with it, asked it silly questions, marveled at its responses.

Then GitHub Copilot became mainstream. Then GPT-4 arrived. Then Claude. Then specialized coding models like Codex and Replit Ghostwriter.

Watching AI get better at coding, debugging, and doing things that used to be uniquely ours—suddenly, that old fear came back.

Not the fear of losing everything (I’d survived that in Varanasi). But the fear of becoming irrelevant was just as scary in a different way.

The Existential Questions

What happens when the skills we’ve painstakingly built over years suddenly don’t matter anymore?

What happens when a fresh graduate with AI assistance can be as productive as a senior developer?

What happens when companies realize they can maintain codebases with fewer people because AI handles the routine work?

These weren’t hypothetical questions anymore. They were becoming reality. The layoff announcements from major tech companies included explicit mentions of “productivity improvements through AI” as justification.

The Essay That Changed My Perspective

Around that time, in one of our team discussions about the future of software development, my manager shared an essay from 1932 by Bertrand Russell called “In Praise of Idleness.”

Has anyone here read it? If not, I highly recommend it.

Russell wrote this during the Great Depression, when millions were unemployed and the world was in economic turmoil. Yet his argument wasn’t about working harder to save the economy—it was about working smarter and questioning the entire premise of constant labor.

Russell’s Radical Idea

Russell argued that modern civilization had created a moral trap where we measure human worth by hours worked, not by problems solved or lives improved.

He believed that if machines could handle labor, we shouldn’t artificially create more meaningless work just to keep people busy. Instead, we should use that freedom for:

• Creativity
• Learning
• Art
• Philosophy
• Solving problems that actually matter

Think about that. Written in 1932, before:

• Computers
• The Internet
• Mobile phones
• Artificial Intelligence

Yet it feels like it was written specifically for us, right now, in 2025.

The Question Reframed

Russell’s essay helped me reframe the question entirely.

It’s not “Will AI replace us?”

It’s “What will we do with the freedom AI creates?”

Tasks that used to take weeks or months of research, development, and iteration now take hours or days thanks to AI assistance.

Yes, there will be side effects:

• Layoffs
• Reduced entry-level positions
• Increased pressure on individual productivity
• Market corrections

But these aren’t permanent states—they’re transition periods. And the question for each of us is: How do we position ourselves to thrive in this transition?

Breaking Out of the Box

For years, I had confined myself to what I call a “boxed developer” mindset.

Everything revolved around:

• Kotlin
• Android
• Jetpack Compose

I was good at it. I was comfortable. I could solve most Android problems thrown my way.

But I realized that comfort was becoming a cage.

The Title Trap

We do this to ourselves, don’t we? We accept titles and roles that become our entire identity:

• “I’m an Android Developer”
• “I’m a Frontend Engineer”
• “I’m a Backend Specialist”

These titles are useful for resumes and LinkedIn profiles. They help us find jobs. They give us a sense of expertise.

But they also limit our view. They keep us from looking beyond what our immediate work needs us to see.

Developer vs. Solutionist

Here’s the crucial distinction I’ve discovered:

A developer writes code to win bread. They learn what they need to stay employed. They specialize to remain valuable. It’s transactional.

A solutionist goes much deeper. They enjoy and learn every bit they can, like a magnet drawn to new knowledge. They’re driven by curiosity and the joy of solving problems, not just by paychecks.

The developer asks: “What do I need to know for my job?”

The solutionist asks: “What do I need to know to solve this problem effectively?”

See the difference?

Staying Relevant: Build Continuously

This distinction matters immensely because once the AI tsunami completes its first wave, the next one is already forming.

Quantum computing advancements. More sophisticated AI models. New paradigms we haven’t even conceived of yet.

Staying relevant through all of these requires constant adaptation and learning.

My proposition for navigating this? BUILD CONTINUOUSLY.

Why Build More?

Because what better way to learn than building projects?

Not theoretical knowledge. Not tutorial hell. Not certifications that gather dust.

Actual projects that solve real problems faced by real humans (even if that human is just you).

The Compounding Effect of Small Projects

Just like that simple billing calculator I mentioned earlier—you never know where a small project might lead.

After experiencing the joy of building that first solution, I built many more:

• A personal expense tracker (because existing ones didn’t fit my mental model)
• A community link-sharing platform (to solve coordination problems in my friend group)
• A personal task management system (because I needed something simpler than Notion but more structured than notes)
• Various automation scripts for repetitive tasks

All of these are available on my website. Are they perfect? Absolutely not. Do they have bugs? Definitely. Are they going to change the world? Probably not.

But they’ve changed my world.

What Building Teaches You

Building small things consistently transforms you:

1. You see problems differently - Instead of complaining about inefficiencies, you see opportunities to build solutions.

2. You stop feeling stuck - There’s always something you can build, always some small improvement you can make.

3. You develop taste - You understand what makes software feel good to use because you’re both the builder and the user.

4. You become resilient - When things break (and they will), you learn to fix them. When approaches don’t work, you pivot.

5. You evolve unexpectedly - You slowly become someone you didn’t know you could become. Skills compound. Confidence grows.

So, What Is a Solutionist?

After all these stories and reflections, let me give you a concrete definition:

A Solutionist isn’t defined by tools, but by problems solved.

They are:

• Language-agnostic
• Framework-flexible
• System-aware
• Problem-focused

The Four Traits of a Solutionist

Through my journey and observation of people I admire, I’ve identified four core traits:

1. Empathy — Understanding People, Not Just Specs

The best solutions come from understanding the human problem, not just the technical specification.

This means:

• Putting yourself in the user’s shoes
• Understanding their frustrations, not just their feature requests
• Recognizing that “make it faster” often means “I feel frustrated waiting”
• Seeing the emotional journey, not just the user journey

When I built that billing calculator, I wasn’t solving a math problem. I was solving the stress and anxiety of my colleagues during rush hours.

2. Systems Thinking — Seeing Ripple Effects

Nothing exists in isolation. One change ripples through everything.

Systems thinking means:

• Understanding dependencies and consequences
• Recognizing that “fixing” one thing might break another
• Seeing the whole forest, not just the tree you’re debugging
• Appreciating long-term implications of short-term decisions

In Android development, this might mean understanding how a seemingly innocent change in a shared ViewModel might affect multiple screens, or how a database migration could impact app startup time.

3. Lifelong Learning — Venturing Into the Unknown Without Fear

The moment you stop learning, you start becoming obsolete.

Lifelong learning means:

• Being comfortable with being a beginner again and again
• Exploring technologies outside your comfort zone
• Reading papers, essays, and documentation for things you don’t “need” yet
• Understanding that every new skill multiplies with every previous skill you’ve learned

From SSLC certificate to Android Developer to exploring AI/ML, backend systems, DevOps—each layer adds new dimensions to how you solve problems.

4. Communication — Bridging Technical and Non-Technical Minds

The best solution is useless if no one understands it.

Communication means:

• Explaining complex technical concepts to non-technical stakeholders
• Writing documentation that actually helps
• Listening actively to understand requirements beneath the surface
• Collaborating effectively across disciplines—design, product, business

I’ve seen brilliant solutions fail because they were explained poorly. And I’ve seen simple solutions succeed because they were communicated effectively.

AI as Freedom: Russell’s Prophecy Coming True

When AI arrived, many feared job loss. And yes, that’s happening in some sectors.

But what if Russell was right all along?

What AI Actually Removes

AI removes:

• Repetitive, mechanical work
• Boilerplate that makes our days feel routine
• The cognitive load of remembering syntax
• The tedium of debugging simple logic errors

It gives time back for:

• Creativity
• Empathy
• Real problem-solving
• Strategic thinking
• Learning deeply instead of superficially

Vibe Coding: Thanks to Andrej Karpathy

This is where ‘vibe coding’ comes in—a term popularized by Andrej Karpathy.

Let AI help you move faster. Let it handle the repetition, the boilerplate, the syntax you can never quite remember.

But—and this is crucial—understand what it’s changing.

Know the patterns. Understand the tweaks. Grasp the reasoning behind every line it suggests.

The Danger of Blind Coding

If you code blindly, just accepting whatever AI suggests without understanding:

• You lose the joy of building
• You become oblivious to your own vision
• You can’t debug effectively when things inevitably break
• You stop learning and start copy-pasting

AI should be your copilot, not your pilot. You’re still flying the plane.

How to Actually Start: Practical Steps

Enough philosophy. Let’s talk practically.

Want to build something? Here’s what I’ve learned through building multiple projects with AI assistance:

Step 1: Start with the Problem

Write it down. Not the solution—the problem.

Ask yourself:

• What are you trying to solve?
• Who are you solving it for?
• Why does this problem matter?
• What does success look like?

Be specific. “I want to build a todo app” is not a problem. “I keep forgetting to follow up on important emails, and existing todo apps don’t integrate well with my email workflow” is a problem.

Step 2: Document Your Vision First

Before you write a single line of code, create a clear vision of what you’re building and why.

Your first commit should be your vision, not your code.

This document becomes your North Star. When AI suggests clever solutions that drift from your vision, you can catch it. When scope creep tempts you, you can resist it.

Step 3: Use AI to Move Fast, But Understand Everything

This is the balance:

• Let AI generate boilerplate → But understand the structure it creates
• Let AI suggest solutions → But understand why those solutions work
• Let AI write tests → But understand what they’re testing and why

Know the patterns. Understand the tweaks. Grasp the reasoning behind every line.

If you find yourself accepting suggestions without understanding them, stop. Research. Learn. Only then proceed.

Step 4: Iterate Deliberately

Add features one at a time.

Track changes with Git. See what’s happening at each step.

This isn’t just about version control—it’s about understanding the evolution of your project. Each commit is a story. Each feature is a chapter.

Deliberate iteration means:

• Build one thing
• Test it thoroughly
• Document what you learned
• Commit it
• Move to the next thing

Step 5: The Tools Don’t Matter. The Mindset Does.

I cannot stress this enough.

The language doesn’t matter. The framework doesn’t matter. The cloud provider doesn’t matter.

What matters is:

• Do you understand the problem?
• Does your solution solve it effectively?
• Can you explain why you made the choices you made?
• Did you learn something building it?

That’s all that matters.

The Real Power: Wearing All the Hats

When you build your own projects, you’re not just a developer.

You’re everything:

• Visionary — Defining what should exist
• Product Manager — Prioritizing features
• Designer — Crafting the experience
• Developer — Building the solution
• QA — Testing and breaking things
• DevOps — Deploying and maintaining
• Support — Handling bugs and feedback

The Freedom This Gives You

Maybe you’ll build something the world uses. Maybe not.

Either way, it’s yours. It’s your journey.

In a typical software job, you might not get to wear all these hats due to company policies and defined roles. You’re the “backend developer” or the “mobile engineer” or the “frontend specialist.”

But here, on your own project, you are the boss. The founder. The everything.

This level of ownership is both daunting and incredibly empowering.

The Career Impact

I’m certain that this experience—building complete projects from vision to deployment—will help you solve day-to-day professional problems much faster.

Because you’ve seen the whole picture. You understand how the pieces fit together. You’ve debugged across the stack. You’ve made tradeoffs and lived with the consequences.

That holistic understanding is invaluable and increasingly rare in our specialized world.

Start Today: Your Action Items

Don’t wait. Don’t prepare. Don’t plan endlessly.

Start small. Start now.

Pick One Frustrating Problem

Look at your daily life. What frustrates you repeatedly?

• Tracking expenses?
• Managing reading lists?
• Coordinating with friends?
• Remembering to water plants?
• Finding recipes based on ingredients you have?

Pick one. Just one.

Don’t Chase Perfection. Chase Progress.

Your first version will be ugly. It will have bugs. It will be embarrassing to show others.

Build it anyway.

Because version 0.1 is infinitely better than the perfect app that exists only in your imagination.

Use Every Project as a Playground

Want to learn a new framework? Use it for your next project.

Curious about a new database? Try it.

Interested in a new deployment strategy? Experiment.

Every project is an opportunity to play, to experiment, to learn.

Every Problem Solved Is Progress

Each problem solved is one step closer to being a Solutionist.

Not because you’re accumulating credentials or certificates, but because you’re training yourself to see opportunities where others see obstacles.

Closing: Reclaiming Purpose

When my manager first sent me “In Praise of Idleness,” I thought it was ironic. Here we are, working in tech, and he’s sending me an essay about working less?

Now I see the wisdom.

It’s not about doing less. It’s about doing better.

It’s about focusing on work that matters, that challenges us, that makes us grow.

What AI Can’t Replace

We’ve built technology powerful enough to automate tasks, but not powerful enough to replace people who bring meaning to them.

AI can:

• Write code
• Debug programs
• Architect systems
• Generate tests
• Refactor codebases

But it can’t:

• Understand why we build
• Feel empathy for users
• Ask deeper questions about impact
• Navigate the human complexities of real projects
• Find purpose in the work

That’s still our job. Always will be.

The World Needs Solutionists

The world doesn’t just need coders. We have enough people who can write syntactically correct code.

The world needs people who:

• See problems and craft thoughtful solutions
• Combine empathy with engineering
• Explore fearlessly and learn relentlessly
• Ask “why” as often as they ask “how”
• Reclaim purpose in a world obsessed with productivity

Don’t Confine Yourself to a Box

So don’t confine yourself to a box labeled “Android Developer” or “Frontend Engineer” or “Data Scientist.”

Explore. Venture into the unknown.

Build. Create things that matter to you.

Reflect. Learn from what works and what doesn’t.

Be a Solutionist.

Because the world doesn’t just need more developers.

It needs you.

Thank You

First and foremost, a huge thank you to Google Developer Group Chennai for organizing DevFest2025 and giving me this incredible platform to share my journey and thoughts with the community.

To all the volunteers who worked tirelessly behind the scenes—setting up the venue, managing logistics, helping attendees, and ensuring everything ran smoothly—you are the unsung heroes who make events like this possible. Your dedication and energy created the welcoming atmosphere that made DevFest2025 special.

A special thanks to all the sponsors who believed in this event and invested in our developer community. Your support makes it possible for us to gather, learn, share, and grow together.

To the GDG Chennai organizers and core team members—thank you for building and nurturing this vibrant tech community in Chennai. Your consistent efforts to bring developers together, facilitate learning, and create opportunities for knowledge sharing are truly invaluable.

To everyone who attended the talk and engaged with these ideas—your questions, your reflections, your nodding heads, and even your skeptical looks made this talk so much more meaningful. The conversations we had afterward were some of the most enriching parts of the entire experience.

And to you, reading this now—whether you attended DevFest2025 or are discovering this for the first time—I hope something here resonates. I hope it sparks something in you.

Now let’s build something.

Sone of the feedbacks from Participants

Heartwarming feedback from the DevFest2025 participants

Event Highlights

Here are some moments from DevFest2025:

The announcement that started it all

Sharing the Solutionist Mindset with the DevFest2025 community

Presenting the Solutionist Mindset on stage

Engaging with the audience during the talk

A memorable moment from DevFest2025

All the amazing volunteers who made DevFest2025 possible - couldn’t have done it without you!

The speaker goodies bag - thanks GDG Chennai! For everyone who asked what’s inside: GDG swag, stickers, and some awesome tech goodies!

If you want to discuss any of these ideas further, or if you’re building something and want to share your journey, feel free to reach out. I’m always excited to connect with fellow solutionists.

All my projects are available on my website. They’re not perfect, but they’re mine, and they’re continuously evolving. Just like me. Just like you.

The Dawn: ENIAC and the Electronic Age (1940s)

Picture this: 1946, University of Pennsylvania. A machine the size of a smand adall house, weighing 30 tons, consuming 150 kilowatts of power. This was ENIAC – the Electronic Numerical Integrator and Computer.

ENIAC was a beast. It used 17,468 vacuum tubes, each the size of a light bulb, generating so much heat that the room needed industrial cooling. Programming it meant physically rewiring connections – imagine debugging by crawling around inside your computer with a soldering iron.

But here’s the magic: for the first time in human history, we had a machine that could perform calculations faster than any human mathematician. What took days by hand took minutes on ENIAC. The computing revolution had begun.

The Challenge: Vacuum tubes burned out constantly. ENIAC operators became experts at hunting down failed tubes in a machine that looked more like a power plant than what we’d recognize as a computer today.

The Revolution: Transistors Change Everything (1950s-1960s)

Then came 1947, and three guys at Bell Labs – Bardeen, Brattain, and Shockley – invented something that would change the world: the transistor.

Think of a vacuum tube as a traffic light that needs a massive power plant to operate. A transistor is like a tiny switch that runs on a battery. Suddenly, computers didn’t need to be room-sized monsters anymore.

The IBM 7090 in 1959 was a glimpse of the future. It was faster, more reliable, and – crucially – much smaller than its vacuum tube predecessors. But we were just getting started.

The Breakthrough: Transistors were not only smaller and more efficient, but they were also incredibly reliable. Where vacuum tubes lasted months, transistors lasted years.

The Acceleration: Integrated Circuits (1960s-1970s)

Here’s where things get interesting. Robert Noyce and Jack Kilby had the same brilliant idea around the same time: why put one transistor on a chip when you could put many?

The integrated circuit was born, and with it, Moore’s Law – the observation that computing power doubles roughly every two years. Suddenly, we weren’t just making computers smaller; we were making them exponentially more powerful.

Companies like Fairchild Semiconductor and later Intel began cramming more and more transistors onto single chips. The computer was shrinking from room-size to refrigerator-size to eventually… desk-size.

The Vision: Gordon Moore’s prediction wasn’t just about more transistors – it was about unleashing computing power that would eventually fit in our pockets while being more powerful than ENIAC ever dreamed of being.

The Personal Revolution: Microprocessors (1970s-1990s)

1971: Intel releases the 4004, the first commercial microprocessor. Four bits of processing power on a single chip smaller than your thumbnail. It sounds primitive now, but it was revolutionary.

The 4004 led to the 8008, then the 8080, and eventually to chips that powered the first personal computers. By the 1980s, companies like Apple, IBM, and Commodore were putting computers on desks in homes and offices worldwide.

This wasn’t just a technological shift – it was a philosophical one. Computers went from being tools for scientists and governments to being personal companions. The phrase “personal computer” captured something profound: computing power was becoming democratized.

The Transformation: The microprocessor didn’t just make computers smaller; it made them personal. For the first time, individuals could own the computational power that once belonged only to universities and corporations.

The Mobile Era: Systems on Chips (2000s-2010s)

Fast forward to the 2000s, and we faced a new challenge: how do you fit desktop-level performance into something that fits in your pocket and runs all day on a battery?

Enter systems-on-chip (SoCs) and mobile processors. Companies like ARM revolutionized computing by designing chips that sipped power rather than guzzling it. Apple’s A-series chips, Qualcomm’s Snapdragons, and Samsung’s Exynos processors brought desktop-class performance to devices we carry everywhere.

Suddenly, the computer in your pocket was more powerful than the room-sized machines of the 1960s. We’d come full circle – from massive power consumption to incredible efficiency.

The Paradigm Shift: Mobile computing didn’t just miniaturize computers; it reimagined what computing could be. Always-on, always-connected, always-in-your-pocket computing became the new normal.

The Quantum Leap: Quantum Computing (2010s-Present)

But even as traditional computing reached incredible heights, we began bumping against physical limits. Transistors can only get so small before quantum effects start interfering with their operation.

So we decided to embrace those quantum effects instead.

Quantum computing works on principles that seem to defy common sense. Where traditional computers use bits that are either 0 or 1, quantum computers use qubits that can be both 0 and 1 simultaneously – a property called superposition.

Companies like IBM, Google, and IonQ are building quantum computers that can solve certain problems exponentially faster than any classical computer. Google’s Sycamore processor achieved “quantum supremacy” in 2019, performing a calculation in 200 seconds that would take the world’s fastest supercomputer 10,000 years.

The Promise: Quantum computers won’t replace your laptop, but they could revolutionize drug discovery, financial modeling, and cryptography – problems that require exploring vast solution spaces simultaneously.

The Brain-Inspired Future: Neuromorphic Computing (Present-Future)

Here’s where it gets really interesting. What if, instead of making computers faster, we made them smarter? What if we designed chips that work more like brains than calculators?

Neuromorphic chips mimic the structure and function of biological neural networks. Companies like Intel with their Loihi processor and IBM with TrueNorth are creating chips that don’t just process information – they learn and adapt.

Traditional computers are incredibly fast but energy-hungry. Your brain, running on about 20 watts (less than a light bulb), can recognize faces, understand language, and make complex decisions in milliseconds. Neuromorphic chips aim to capture that efficiency.

The Vision: Imagine devices that learn your patterns, adapt to your needs, and operate for months on a single charge. Neuromorphic computing could enable truly intelligent edge devices – from smart prosthetics to autonomous robots that think more like humans.

The Pattern: Each Era’s Gift to the Next

Looking back, each era of computing didn’t just improve on the last – it enabled entirely new possibilities:

• ENIAC proved electronic computation was possible
• Transistors made it reliable and efficient
• Integrated circuits made it scalable
• Microprocessors made it personal
• Mobile chips made it ubiquitous
• Quantum computers make impossible problems solvable
• Neuromorphic chips make computers truly intelligent

What This Means for Us

We’re living through the most exciting period in computing history. The smartphone in your pocket contains billions of transistors working in harmony, capable of tasks that would have seemed like magic to ENIAC’s operators.

But we’re just getting started. The convergence of quantum computing, neuromorphic processing, and traditional silicon is creating possibilities we’re only beginning to imagine.

The next chapter is being written right now, in labs and garages and coffee shops around the world. And if history is any guide, it’s going to be more revolutionary than anything we’ve seen before.

The question isn’t what computers will be able to do – it’s what problems will we choose to solve with them.

Final Thoughts

From room-sized vacuum tube monsters to neuromorphic chips that think like brains, computing has been humanity’s greatest amplifier of intelligence. Each generation of technologists has stood on the shoulders of those who came before, pushing the boundaries of what’s possible.

The journey from ENIAC to quantum computers is really a story about human ambition – our relentless drive to build tools that make us more capable, more connected, and more creative. And if the past seven decades are any indication, we’re nowhere near finished.

The next breakthrough might come from a small team in a garage, just like Apple and HP did decades ago. Or it might emerge from a quantum lab pushing the boundaries of physics itself.

Either way, one thing is certain: the best is yet to come.

What aspect of computing history fascinates you most? Have you worked with any of these technologies, or are you building the next chapter yourself? I’d love to hear your thoughts.

For too long, we’ve confined ourselves to a title: “developer.” We write code, we fix bugs, we build features. We are the architects and construction workers of the digital world. And while that is a noble and essential craft, the label itself can become a box. It can narrow our focus to the how – the languages, the frameworks, the systems – and make us lose sight of the why.

We get caught up in debates about which programming language is superior, which framework is the most scalable, and which cloud provider is the most cost-effective. We specialize, we become experts in our niche, and in doing so, we sometimes build walls around ourselves. We become a “Java developer,” a “frontend engineer,” a “mobile expert.” These labels, while useful for a resume, can inadvertently limit our potential.

The Call of the Solutionist

But what if we shed these self-imposed boundaries? What if we saw ourselves not as developers, but as Solutionists?

A Solutionist is not defined by the tools they use, but by the problems they solve. A Solutionist is language-agnostic, framework-flexible, and system-aware. Their loyalty is not to a specific technology stack, but to the most elegant, efficient, and impactful solution.

Being a Solutionist means stepping back from the keyboard and looking at the bigger picture. It means asking the right questions before writing a single line of code:

• What is the real problem we are trying to solve?
• Who are we solving it for?
• What is the most direct path to a solution, even if it means not writing any code at all?

Beyond the Code

The journey from developer to Solutionist is a shift in mindset. It’s about embracing a broader skillset and a deeper curiosity. It’s about understanding that code is just one tool in our problem-solving arsenal.

Here’s what it means to be a Solutionist:

• Embrace Empathy: A Solutionist starts with the user. They strive to understand their needs, their frustrations, and their goals. They are part designer, part psychologist, part anthropologist.
• Think in Systems: A Solutionist sees the interconnectedness of things. They understand that a small change in one part of a system can have a ripple effect elsewhere. They think about scalability, maintainability, and the long-term impact of their decisions.
• Become a Perpetual Learner: A Solutionist is a voracious learner. They are not afraid to venture into unfamiliar territory, whether it’s a new programming language, a different cloud platform, or a completely new domain of knowledge. They know that the best solution might lie just outside their comfort zone.
• Master the Art of Communication: A Solutionist can articulate complex technical ideas to a non-technical audience. They can collaborate effectively with designers, product managers, and business stakeholders. They are storytellers, translators, and bridge-builders.

The Joy of Creation and the Age of AI

Do you remember the first time you built something that worked? That spark of joy when your code compiled, your app launched, or your script ran without a hitch? There’s an immense, selfless pleasure in creating something that can help you or others. It’s a feeling of pure creation, of bringing an idea to life.

But somewhere along the way, the industry seems to have lost some of that magic. The joy of creation can get buried under layers of process, tight deadlines, and the pressure to specialize. We become so focused on our small part of a massive machine that we forget the thrill of building something whole.

Now, with the rapid advancement of AI, we have a unique opportunity to reclaim that joy. AI is not here to replace us; it’s here to augment us. It can be our tireless coding partner, our creative collaborator, and our personal tutor. With AI handling the repetitive and mundane tasks, we are free to focus on what truly matters: the creative process of problem-solving.

This is the perfect moment to embrace the “Solutionist” mindset. With AI, a single person with a vision can now design, build, and deploy sophisticated applications. If you have a solid understanding of concepts like auto-scaling servers and security, you can create personal projects that can have a global reach. The barrier to entry has never been lower.

Of course, this doesn’t mean that large-scale, global applications will be built by a single person. Those will always require the expertise of a dedicated team, rigorous testing, and robust security measures. But for our personal projects, for the ideas that we are passionate about, the constraints are melting away.

The Future is for Solutionists

The world is facing a myriad of complex challenges, from climate change and healthcare to education and economic inequality. Solving these problems isn’t just the job of large corporations; it’s our responsibility too. A small project, a simple app, a clever script built by one of us could be the spark that inspires a breakthrough, pushing larger organizations to crack the code faster and deliver solutions to the masses. These problems will not be solved by developers who are content to stay within their boxes. They will be solved by Solutionists who are willing to think differently, to challenge the status quo, and to use technology as a force for good.

So, let’s break free from the “developer” label. Let’s embrace the identity of a Solutionist. Let’s go out and solve the problems that matter. The world is waiting.

What is Vibecoding?

The term “vibecoding,” recently popularized by Andrej Karpathy, describes a software development approach that is less about rigid plans and more about the “vibe” of the project. It’s about letting your intuition and the feel of the product guide the development process. Instead of detailed specs and roadmaps, you work with a general idea, a vision, and you let the project evolve organically.

It’s a dance between logic and intuition, a form of mindfulness where you are fully present with the code and the project, responding to its needs in the moment. This might sound chaotic, and in some ways it is. But it’s a controlled chaos. It’s about being in tune with the project’s needs, the user’s needs, and your own creative flow.

The Dhanika Project

Dhanika is a personal finance tracker I built for myself. I’ve tried many finance apps, but none of them felt quite right. They were either too complex or too simple. I wanted something that was tailored to my specific needs and my way of thinking about money.

The vision for Dhanika was simple: a clean, intuitive interface to track my income and expenses, with a focus on simplicity and mindfulness about my spending habits.

What started as a personal tool has since been shared with some of my friends, who have started using it to gain clarity on their own financial posture. They’ve found the ability to visualize their finances with graphs and charts particularly helpful. This has been incredibly rewarding and has reinforced the value of building something with a clear and simple vision.

The Vibecoding Journey with Dhanika

To be honest, the initial phase of this journey was daunting. I felt a profound sense of imposter syndrome. Was this “vibecoding” just an excuse for not having a proper plan? Was I doing things “the wrong way”? The feeling was akin to standing still while the world moved on. I had to have a serious talk with myself. I realized that the future of creation is fluid and intuitive, and clinging to old, rigid methods was like trying to carry heavy luggage onto a moving train. Once I broke free from that guilt and embraced the uncertainty, everything changed. The project took off, and I truly started to vibe with the code.

I started Dhanika with no grand design document. I had a single-sentence vision: “A beautiful and simple finance tracker that feels good to use.”

The first step was to create the most basic feature: adding an expense. I didn’t worry about the database schema or the overall architecture. I just wanted to get something on the screen that worked.

As I used the app myself, I started to get a feel for what was missing. I’d think, “It would be cool if I could see a chart of my spending this month.” So, I’d add a chart. Then I’d think, “I wish I could categorize my expenses.” So, I’d add categories.

The development process was a continuous conversation between me, the user, and the code. The “vibe” of the project guided my decisions. If a feature felt too complicated or didn’t align with the core vision of simplicity, I’d scrap it.

Git was a magic tool in this process. Before each commit, I had to make sure that none of the existing features would break and the design on web and mobile was not compromised. This also taught me how to incrementally build a basic working PWA, then focus on the UI, then the UX, and finally other details. This iterative process of building, testing, and committing was crucial to the project’s success.

Pros of Vibecoding:

• Creative Freedom: It’s incredibly liberating to not be constrained by a rigid plan. You can follow your creative instincts and explore new ideas as they come up.
• Organic Evolution: The product evolves in a very natural way, based on real usage and feedback.
• High Motivation: Working on what feels right at the moment is a great way to stay motivated and engaged.

Cons of Vibecoding:

• Lack of Predictability: It’s hard to estimate timelines or even what the final product will look like. This makes it unsuitable for projects with strict deadlines or multiple stakeholders.
• Risk of Scope Creep: Without a clear plan, it’s easy to keep adding features and never reach a “finished” state.
• Potential for Architectural Issues: Making design decisions on the fly can lead to a messy codebase if you’re not careful. It requires a good sense of when to refactor and clean up.
• Risk of Project Reset: The fluid nature of vibecoding can be dangerous. If you’re not careful, especially when using powerful CLIs, you might accept permissions that could reset your work. While Git is a lifesaver, it’s a critical point to be mindful of.

Tips for Successful Vibecoding

• Embrace Version Control: Use Git religiously and commit often. It’s your best friend and safety net in a fluid development process.
• Start with a Core Idea: You don’t need a detailed plan, but have a clear, simple vision for what you want to build.
• Listen to Your Gut: If a feature feels wrong or overly complicated, it probably is. Trust your intuition to guide you.
• Refactor Fearlessly: Vibecoding can get messy. Don’t be afraid to pause and clean up your code when things start to feel disorganized.
• Stay Mindful and Present: Focus on the task at hand and be fully engaged with the code. The best ideas often come when you’re in a state of flow.
• Keep Documentation Updated: Whether it’s a README.md or an agent.md for AI collaborators, keep documentation current. Since AI models have token limitations, this helps them clearly understand the project’s structure, philosophy, and goals, no matter which model you use.

Lessons Learned: The Philosophy of Vibecoding

Vibecoding is not for every project or every person. It’s best suited for personal projects, prototypes, or early-stage startups where the product vision is still evolving.

Whether a non-technical person can build complex systems with vibecoding is a valid doubt, and the reasons often go beyond the code itself. The building process might be manageable, but the technical hurdles of hosting, configuring domains, understanding DNS for services like GitHub Pages, and other deployment intricacies require a solid technical foundation. While there are excellent platforms that eliminate these complexities, they often come at a cost. This project, for instance, cost me nothing but my time, largely because I could navigate these technical challenges and utilize free tools like the Gemini CLI. This highlights a key aspect of vibecoding: the more technical skills you have, the more freedom and economic flexibility you have to bring your vision to life. It also reinforces the idea that in vibecoding, the developer is not just an engineer, but also a designer, a product manager, and a DevOps specialist, all rolled into one.

This approach challenges the traditional separation of roles and encourages a more holistic way of creating. It’s about embracing the uncertainty and imperfection of the creative process. It’s a reminder that sometimes, the most beautiful things are not planned, but discovered.

Another profound lesson is that when you are vibecoding, you are not just a coder; you are the manager. You have to know what model to use and when, how to order the tasks so they don’t break the entire codebase, and when to take control and enforce some structure, even in a fluid process. This includes the often-neglected task of documentation. In a typical software job, you might not get to wear all these hats due to company policies and defined roles. But here, on your own project, you are the boss. You are the founder, the manager, the coder, and so much more. This level of ownership and responsibility is both daunting and incredibly empowering.

I am certain that with this vibecoding experience, I will be able to solve day-to-day problems with technology much faster than before. It has honed my ability to quickly prototype and iterate on ideas, to trust my gut, and to listen to the voice of the project itself.

Conclusion

Building Dhanika with the vibecoding approach was a deeply rewarding experience. It allowed me to create a product that is not only functional but also has a personality, a “vibe” that is uniquely its own. It reminded me that software development can be as much an art as it is a science. It’s a journey of discovery, a conversation with the digital canvas, and a testament to the power of creative intuition.

Abstraction as Trust

At its core, every abstraction is built on trust. When we build or use a library, framework, API, or even a programming language, we trust the people or systems who designed it. We trust that these abstractors have already handled the intricate details—the “hows”—so that we don’t have to.

Just as currency enables transactions by guaranteeing value, abstraction enables development by guaranteeing that, if we use it correctly, it will do its part. Each layer of abstraction makes an implicit promise:

“I will handle this piece of complexity for you. You can rely on me.”

This trust extends even to our own past work. If you designed a library years ago with effective separation of concerns, you don’t need to recall its minute details to use it today. This promise allows developers to stand on the shoulders of those who came before, building ever more complex and capable systems without getting lost in the weeds of low-level implementation.

Abstraction Frees the Mind

The true beauty of abstraction lies in its ability to liberate the developer’s mind. Instead of worrying about how a particular task is implemented under the hood—how data is stored, how a network packet is transmitted, how a sorting algorithm works—we can focus on higher-level concerns:

• What problem am I solving?
• What is the best design for this situation?
• How can I create value for the user?

This mental freedom accelerates development time. By outsourcing the details to well-designed abstractions, we create space and set priority for creativity, strategy, and architectural thinking.

Examples All Around Us

Abstraction is everywhere in software:

• Operating systems abstract hardware complexities so we don’t write programs in assembly language for each device.
• The Retrofit HTTP client for Android takes away overhead complexities like opening and closing socket connections, formatting headers, handling encryption, and parsing responses.
• Database Object-Relational Mappers (ORMs) abstract SQL so we can think in terms of objects or models.

And abstraction exists beyond software:

• We trust that flipping a light switch will illuminate a room without understanding the engineering behind electrical circuits, springs, or materials.
• We drive cars without needing to know how combustion engines or electric motors work.
• We post letters following established protocols, and the rest is handled by the postal system; we need not worry about how it’s moved from one place to another, where it stops, or other intricacies.

The Developer’s Responsibility

Of course, with trust comes responsibility. Every time we use an abstraction, we are relying on someone else’s work to solve part of our problem—and that trust should not be blind. As developers, we must approach abstractions thoughtfully and skillfully.

Here’s what that means in practice:

• Choose abstractions wisely.
• Understand their limitations and guarantees.
• Respect the contract they offer and use them as intended.
• Know when to peek beneath the abstraction.

Sometimes, it is necessary to peek beneath an abstraction’s surface, especially when debugging or optimizing. But most of the time, abstraction serves as the foundation that allows us to build faster, smarter, and better.

Not all interfaces are abstractions — differentiating abstractions

When I first learned about abstraction, I assumed that every interface represented an abstraction. But over time, I realized that’s not always the case.

• An interface is simply a contract—a way to define what methods or properties should exist.
• Abstraction, on the other hand, goes beyond that. It hides internal complexity and provides a simpler way to achieve a goal.

For something to qualify as a meaningful abstraction, it must do more than just define methods. It must:

• Fulfill a purpose in the easiest way possible
• Hide unnecessary complexity
• Offer a clean and reliable interface that lets developers focus on what they want to achieve, not how it’s implemented

Take libraries like Retrofit or Ktor as examples. These libraries have been thoughtfully designed to abstract away the complexities of network communication—things like:

• Opening and managing connections
• Formatting HTTP requests and parsing responses
• Handling retries, timeouts, redirects, and errors
• Managing threading and background execution

As app developers, we don’t need to worry about these internal details. We simply declare what API we want to talk to, and the library takes care of the rest.

@GET("users")
suspend fun getUsers(): List<User>

That’s abstraction at work: you focus on what you need (the list of users) and trust that the library handles the how (HTTP calls, JSON parsing, etc.).

Not all interfaces are abstractions, but every good abstraction provides an interface—one that lets you work at a higher level of thinking, free from unnecessary details.

Conclusion

Abstraction is more than a coding technique—it is a profound enabler of progress. By trusting in the work of others and leveraging the abstractions they create, we free ourselves to focus on what truly matters: solving problems, creating value, and pushing the boundaries of what software can do.