Vishwaraj Anand

Phulwari Rent: A Family Bookkeeping App, Built by Conversation

2026-05-03T00:00:00+00:00

A few months ago I caught myself doing arithmetic on the back of a printed electricity bill — figuring out how much rent each tenant owed for that month across a multi-unit property. Few shops, flats, a couple of rooms, and a couple of unrented halls. Each unit has a different rent, a different electricity meter, sometimes a partial cash payment, sometimes a UPI transfer to the caretaker. A pen, a calculator and a register were just barely keeping up.

I’d been meaning to build a small app for this for a while. With Claude Code in my terminal these days, “for a while” finally became “this weekend.”

This is the story of Phulwari Rent — a tiny mobile-first bookkeeping app that runs entirely on Firebase’s free tier — and what I learned about building real software through conversation rather than typing.

The Problem: A Spreadsheet Wearing a Rent Register’s Costume

Concretely, I needed:

Per-unit dues that account for rent, an optional adjustment (the caretaker pays no rent — a -₹5,000 line item), and an electricity bill computed from the meter delta.
Three roles — owner (full access), caretaker (records this month’s payments and any month’s meter readings), and tenant (sees only their own unit, can self-report a payment).
Mobile-first because every actor in this story uses a phone, not a laptop.
Shareable summaries — a one-tap “send to WhatsApp” of this month’s bill.
Cheap to run — this is for one extended family, not a SaaS.

A spreadsheet would technically work. But spreadsheets don’t enforce roles, don’t compute “caretaker cash on hand to remit”, and are not pleasant to use on a thumb. So: a real app.

The Architecture That Won

I tried two architectures before landing on the third.

Attempt 1: Express + SQLite, the React frontend talking to a /api running on a tiny Cloud Function. Worked, but the SQLite-on-Functions story is bad — the filesystem is ephemeral, and I wanted writes to persist between cold starts.
Attempt 2: Express + Cloud SQL. Worked, but suddenly I was paying for a managed database and a Cloud Function for what is, fundamentally, a five-table CRUD app with three users.
Attempt 3 (winner): No backend at all. The browser talks directly to Firebase Auth and Cloud Firestore via the JS SDK. All access control lives in firestore.rules. The static site sits on Firebase Hosting. Total infrastructure: two Firebase services, both free at this scale.

The shape is delightfully small:

phulwari_rent/
├── client/         # React + Vite + Tailwind
├── scripts/seed.js # one-shot: creates Auth users, sets role claims
├── firestore.rules # the actual security model
└── firebase.json   # hosting + firestore + emulator config

There is no server-side code I have to deploy or monitor. The “backend” is a 117-line firestore.rules file.

Family members are not going to type owner@phulwari.app when they sign in. They want to type owner. They especially want to type their unit id, like room-7 or shop-3, not an email address.

Firebase Auth requires emails, so I cheated. The client builds a synthetic email under the hood:


const AUTH_EMAIL_DOMAIN = 'phulwari.app';
export const usernameToEmail = (u) =&gt;
  `${u.toLowerCase()}@${AUTH_EMAIL_DOMAIN}`;

// In LoginScreen:
await signInWithEmailAndPassword(auth, usernameToEmail(username), password);

The phulwari.app domain doesn’t even need to exist — Firebase Auth doesn’t care; it just treats the email as an opaque identifier. From the user’s perspective, it’s username + password.

The Real Security Model: Custom Claims + Rules

The actual access control sits in two places:

Each Auth user has custom claims — role (one of owner, caretaker, tenant) and, for tenants, unitId. A one-shot seed script sets these via the Firebase Admin SDK.
firestore.rules reads those claims from request.auth.token and gates every read and write.

Here’s a slice that captures the spirit:

match /payments/{paymentId} {
  allow read: if isSignedIn() && canSeeUnit(resource.data.unitId);

  // Owner: anytime. Caretaker: only current month, only if unlocked.
  // Tenant: can self-report ONLY for their own unit, current month,
  // while unlocked.
  allow create: if (
    isOwner() ||
    (isCaretaker()
      && request.resource.data.monthKey == currentMonthKey()
      && !monthLocked(request.resource.data.monthKey)) ||
    (isTenant()
      && request.resource.data.unitId == tenantUnitId()
      && request.resource.data.monthKey == currentMonthKey()
      && !monthLocked(request.resource.data.monthKey))
  );
}

What I love about this model is that there’s nowhere for a bug to hide. The rules are the contract. The UI mirrors them so it can hide irrelevant buttons, but if the UI is wrong, the rules still say no.

Building It by Conversation

I’ve written a lot of small webapps over the years. This is the first one I built almost entirely by talking — Claude Code wrote the bulk of every file, and I made decisions about architecture and reviewed diffs. Some patterns that made the loop work:

State the desired end state, not the next step. “I want a login screen with username + password” is a better prompt than “add a TextField for username.” Claude can chain three or four steps competently if it knows the destination.
Make the AI prove the work. After each meaningful change I’d say “now exercise this end-to-end” — boot the API, hit the endpoint, parse the result. Half of the bugs surfaced in this verification step, not in the writing step.
Iterate on architecture out loud. When I realised SQLite-on-Functions wouldn’t survive a cold start, the conversation moved up a level — should this even have a backend? That kind of zoom-out happens naturally when you’re thinking aloud with a partner who can also rewrite half the codebase in five minutes.
Treat hallucinations as design feedback. When the AI invented a caretakerUnlocked field that didn’t exist in my model, it was actually pointing at a real problem: the caretaker-password gate had nowhere to live in the new architecture. I deleted the prompt instead of inventing the field.

The final code review I did on the app surfaced a couple of real bugs (a stale addedBy field reference, a UTC-vs-IST month boundary edge case in currentMonthKey() inside the rules, a no-op admin password prompt). All things a careful pair of human eyes would catch — none of which the AI flagged on its own. The lesson, again: the AI writes; you decide.

The Bits I Was Surprised To Care About

A few things I didn’t expect to spend time on:

Bundle size. The Firebase JS SDK is hefty — around 165 KB gzipped after the migration, up from 58 KB when I had a hand-rolled API. For a once-loaded mobile app this is fine, but if I were chasing performance I’d reach for firebase/firestore/lite or split the SDK into its own chunk.
Indexes. Firestore composite indexes are declared in firestore.indexes.json and deployed alongside the rules. Forgetting one means a query throws at runtime in production but works fine in the emulator. Found that the hard way.
Time zones in security rules. request.time is in UTC. India is UTC+5:30. So currentMonthKey() evaluated server-side can lag the user’s IST clock by up to six hours around the month boundary, which is exactly when caretakers are scrambling to record last-minute payments. A 330-minute offset in the rules fixed it.
The “no backend” tradeoff. With no server, there’s also no place to run a periodic job, no place to enforce things that need a privileged context (re-authenticating a caretaker against a separate password before allowing a settings edit, for example). For Phulwari Rent these gaps are acceptable. For something with money flowing through it, I’d add a couple of Cloud Functions back.

What I’d Build Next

In order of how much family value they’d unlock:

WhatsApp deep-link share of the monthly summary, pre-formatted for one tap.
Forgot-password via Firebase’s built-in email reset (the synthetic email domain makes this nontrivial — I’d switch to real-ish emails or a custom callable function).
Per-tenant running balance across past months, not just the current one.
PWA manifest so the app installs to the home screen and feels native.
Audit log — an append-only auditLog collection so I can answer “who deleted that ₹3,300 payment?” six months from now.

Final Thoughts

The most surprising thing about this project wasn’t the AI. It was how small the app turned out to be once I committed to “no backend.” Five Firestore collections. One rules file. One seed script. A static React bundle. The whole thing fits on Firebase’s free tier and will probably stay there for years.

Building it through conversation made the architectural pivots cheap. When attempt #2 wasn’t working, I didn’t sunk-cost myself into making it work — I described the third architecture, watched the AI rewrite the layer that needed rewriting, and we kept moving. That’s the part I’m still adjusting to: the cost of changing my mind about architecture has dropped by an order of magnitude. It changes how willing I am to entertain the right shape, not just the shape I’ve already half-built.

If you’ve got a tiny app that’s been sitting in your “someday” pile, this might be its weekend. Drop into the repo and have a look — and if you’ve built something similar in this AI-pair-programming style, I’d love to hear what worked.

Modernizing a 7-Year-Old Android App with Gemini

2026-05-02T00:00:00+00:00

It’s been over 6 years since I first released the Clouds of Thought app. At the time, I built it as a simple Java-based WebView wrapper because I wanted a “mobile presence” without the overhead of maintaining a separate codebase for every blog post.

Fast forward to 2026, and the app was in a sad state. It was broken on latest Android versions, the code was legacy (Java, old Gradle, ancient SDK targets), and honestly, it wasn’t easy to even get it to run on a modern machine, let alone maintain it.

Below is a story of how I took an almost non-functional Android app in Java and migrated it to the latest Kotlin Android stack to give it a new life of its own!

The Problem: Legacy Debt

Broken on New Androids: The app would crash or behave weirdly on newer devices because it wasn’t respecting modern permissions or SDK requirements.
Maintenance Nightmare: Every time I tried to open the project, I’d face a wall of Gradle errors and deprecated library warnings.
Strategic Opportunity: Having focused on other domains recently, I saw this as a chance to explore modern Android tooling and AI-assisted development in unfamiliar codebases.

Despite all this, there’s a certain personal satisfaction in keeping your own creations alive. It’s a low-cost, high-reward project for the soul.

The Solution: Agentic AI (Gemini)

Instead of manually fighting with build.gradle files and converting Java to Kotlin by hand, I decided to use Gemini (integrated into Android Studio) as my “lead engineer.”

What followed wasn’t a “one-shot” magic trick. It was a series of iterative prompts where I acted as the project manager and validator, guiding the AI through each step like directing a skilled team.

My Strategy:

Desired State First: I always told the AI exactly what I wanted the final state to look like (e.g., “Migrate this to Kotlin,” “Update to SDK 35,” “Use Material 3”).
Verification Loop: After every change, I’d ask how to check the progress. “How do I build this?”, “How do I run the release build?”, “Where is the output?”
Iterate, Don’t Revert: If a build failed, I didn’t panic and revert. I gave the error back to the AI and we fixed it together.

My Learnings: Handling the “Deep” Gradle Issues

The most interesting part was when the basic migration was done, but the build was still “bleeding” warnings. I saw errors like: API 'unitTestVariants' is obsolete and has been replaced with 'AndroidComponentsExtension'.

In the past, I would have spent hours on StackOverflow. With Gemini, I learned about the Built-in Kotlin support introduced in Android Gradle Plugin 9.0.

The Technical Shift:

Removing Legacy Plugins: I had to remove the org.jetbrains.kotlin.android plugin entirely. AGP 9.0+ now handles Kotlin natively.
Cleaning gradle.properties: Modern AGP versions are much more opinionated. I had to strip away a lot of legacy flags like android.newDsl=false and android.builtInKotlin=false which were actually hindering the migration.
Kotlin DSL Updates: Migrating from kotlinOptions to the newer kotlin.compilerOptions or simply letting AGP handle it via compileOptions was a key step in silencing those stubborn warnings.

This experience reinforced how staying attuned to platform evolution is crucial for senior engineers.

The Results

In a single afternoon, the transformation was complete:

Kotlin Everywhere: The legacy Java code is gone. Everything from MainActivity to the WebViewClient is now clean, modern Kotlin.
Modern UI: Switched to Jetpack Compose and Material 3.
Build Success: All warnings resolved, compileSdk updated to 35, and the build is finally “green.”
Release Ready: I’ve successfully generated signed .aab and .apk files for version 17.0, ready for the Play Store.

This not only revived the app but also highlighted scalable approaches for modernizing enterprise legacy systems.

Code Snippets: Then vs. Now

Old Java WebView Setup:


siteWebview = (WebView) findViewById(R.id.siteWebview);
siteWebviewSettings.setJavaScriptEnabled(true);
siteWebview.loadUrl("https://vishwarajanand.com/blog/");

New Kotlin + Compose Setup:

AndroidView(
    factory = { context ->
        WebView(context).apply {
            settings.javaScriptEnabled = true
            webViewClient = CotWebviewClient()
            loadUrl("https://vishwarajanand.com/blog/")
        }
    },
    modifier = Modifier.fillMaxSize()
)

Final Thoughts

You don’t need to be an expert in the latest framework to keep your old projects running. With tools like Gemini, the barrier to “modernization” has never been lower. It’s not about the AI doing everything for you; it’s about having a partner that knows the syntax so you can focus on the architecture and the “why.”

The app is back. It’s fast, it’s modern, and most importantly, it’s alive. If you have an old project gathering dust, maybe it’s time to let an AI agent help you blow the dust off. And for fellow engineers, consider how AI can empower your modernization efforts—share your stories below!

Deleting autogenerated code

2025-12-22T00:00:00+00:00

Throughout my career, I’ve found that some of my most impactful work involved deleting code rather than writing it. Systems often run faster and become easier to maintain when we remove unnecessary complexity.

This contradicts everything I learned early in my career. Fresh out of school, I believed shipping features meant success. More code, more functionality, more value—right? The industry reinforced this: sprint velocity, commit counts, feature flags.

But production systems don’t care about your velocity. They care about reliability, debuggability, and operational simplicity.

The Wake-Up Call: When Complexity Becomes the Enemy

My perspective shifted during various debugging sessions over the years. Often, performance issues stem from outdated optimizations—caching layers built for use cases that no longer exist, or defensive code that adds overhead without benefit.

Removing such cruft often improves performance significantly.

This pattern repeated itself across the codebase. Defensive logging that generated gigabytes of noise. Retry logic layered on retry logic. Configuration toggles for features that never launched. Each addition had seemed reasonable in isolation, but together they formed a maze.

Here’s what AI coding assistants have made worse: generating plausible-looking code is now trivial. Need a helper function? LLM provides five implementations. Need a config parser? Here’s a robust solution with validation, caching, and extensibility.

The hard part isn’t generating code anymore. It’s deciding what deserves to exist.

Archaeology in Production: Unearthing Dead Code

When I joined my current team at Meta, I inherited a service with several dependencies. Each dependency carried weight: security patches to track, breaking changes to monitor, mental overhead for new engineers trying to understand “why do we have three ways to make HTTP calls?”

The trickiest part wasn’t identifying what to remove—we ran dependency analysis and found dozens of unused imports. The challenge was building confidence that deletion was safe. Legacy systems accumulate defensive code: “I don’t know what this does, but I’m afraid to remove it.”

This fear is valid. I’ve seen production incidents caused by removing “dead” code that turned out to have one obscure caller. The solution isn’t reckless deletion—it’s systematic verification.

Building instrumentation to track which code paths actually execute in production is invaluable. You’d be surprised how much code exists that never runs—legacy paths from migrated features or defensive logic for scenarios that can’t occur anymore.

The Deletion Sprint: Making It Real Work

Here’s where most cleanup initiatives die: they get prioritized behind feature work, forever postponed as “technical debt we’ll address later.”

I took a different approach. I framed dependency cleanup not as technical debt, but as production risk reduction. The pitch to leadership was simple:

“Every unused dependency is a potential CVE waiting to happen. Every obsolete code path is a debugging session that takes 3x longer. This isn’t about code cleanliness—it’s about operational efficiency and security posture.”

That language resonated. We got a dedicated sprint.

My approach:

Instrumentation First: Added telemetry to confirm zero usage in production
Incremental Removal: One dependency per PR with full regression testing
Rollback Plan: Feature flags for deletions affecting critical paths
Documentation: Updated docs to explain what we removed and why

The benefits of aggressive pruning often exceed expectations. Fewer dependencies mean faster builds, smaller deployment artifacts, and reduced security surface area. You might be patching CVEs in libraries you’re not even using.

Incident response becomes more straightforward too. When you have multiple ways to do the same thing, every error requires checking multiple implementations. Consolidation makes diagnosis deterministic.

AI Amplifies the Problem

Generative AI has transformed how we write code, but it’s made the accumulation problem exponentially worse. LLMs are trained on massive codebases and optimize for completeness, not minimalism.

Ask ChatGPT to “implement user authentication” and you’ll get a full OAuth flow with JWT refresh tokens, role-based access control, and database migrations. Maybe you just needed to check an API key.

I’ve reviewed pull requests where engineers used AI to generate solutions that duplicate existing functionality—reinventing utilities that already exist in the codebase or standard library, or building complex abstractions for simple problems.

The code works. It’s even well-commented. But it’s unnecessary weight.

My code review filter now includes:

“Can we use stdlib instead?” Modern languages have rich standard libraries. We don’t need lodash for array manipulation.
“Does this solve a real problem?” Premature abstraction is worse than no abstraction. Build it when you need it.
“What’s the maintenance cost?” Custom code means custom debugging, custom documentation, custom onboarding.

When AI suggests adding a dependency, I ask the engineer: “Have you checked if we already do this somewhere?” The answer is often yes.

The Senior Engineer’s Real Job

Early in your career, you prove yourself by shipping. You write features, fix bugs, close tickets. Your impact is measured in output.

But seniority isn’t about writing more code—it’s about making better decisions about what code should exist. Sometimes the most impactful contributions aren’t new features, but strategic removals:

Merging redundant services to reduce operational overhead
Deprecating configuration systems that have grown beyond their usefulness
Consolidating similar utilities scattered across the codebase

These changes don’t show up in GitHub contribution graphs. They don’t make good demos. But they compound over time: faster CI/CD, easier onboarding, fewer production mysteries.

Here’s my framework for sustainable engineering:

Addition requires justification. New code must prove its value.
Deletion requires verification. Remove safely, but remove aggressively.
Consolidation beats proliferation. One excellent solution beats five good ones.

AI has made creation trivial. The competitive advantage now belongs to engineers who can look at a sprawling system and know exactly what to remove to make it stronger.

Your legacy isn’t the code you wrote—it’s the maintainability you left behind.

Cracking AI-Based SWE Interviews

2025-12-02T00:00:00+00:00

Recently, a candidate asked me:

“How do I prepare for coding interviews where the editor itself is powered by AI? What’s different, and what do interviewers care about?”

This is a timely question. As Agentic AI tools become standard in technical interviews, the expectations and evaluation criteria are shifting. Here’s my advice—tailored for the Agentic AI era—on how to excel in these new-style SWE interviews.

1. Understand the Interview Format

Agentic AI coding rounds use editors like VS Code, Cursor, or custom platforms with built-in AI agents.
You’ll get real-time code suggestions, error detection, and sometimes even hints or documentation from the AI.

2. What Interviewers Rate Upon

Technical fundamentals: Your grasp of algorithms, data structures, and problem-solving remains crucial.
AI collaboration: Interviewers watch how you interact with the AI agent. Do you use its suggestions wisely? Can you spot and correct its mistakes?
Critical thinking: Are you evaluating AI-generated code, or just accepting it blindly?
Communication: Can you explain your reasoning, especially when you accept or reject AI help?
Adaptability: How smoothly do you switch between manual coding and leveraging AI features?

3. How These Interviews Differ from Traditional Rounds

AI is your coding partner: Instead of a static editor, you’re working with a tool that can suggest, complete, and even debug code.
Process over product: Interviewers care about how you solve problems, not just the final answer.
Real-time feedback: Expect questions about your choices—why you used (or ignored) an AI suggestion, how you debugged, etc.
Less focus on memorization: The ability to use tools effectively is valued over rote recall.

4. Tips to Excel in Agentic AI Coding Interviews

Practice with AI-powered editors: Get comfortable with Copilot, Cursor, or similar tools. Learn their strengths and limitations.
Be skeptical, not cynical: Review every AI suggestion. Accept what’s correct, modify what’s close, and reject what’s wrong.
Narrate your process: Explain your approach out loud, especially your interactions with the AI.
Use AI for speed, not shortcuts: Let the agent handle boilerplate, but do the core logic yourself.
Test thoroughly: Use the editor’s instant feedback to run edge cases and validate your solution.
Stay calm under feedback: If the interviewer challenges your choices, respond thoughtfully and show your reasoning.

5. Common Pitfalls in Agentic AI Coding Interviews

Mistakes candidates often make:

Over-reliance on AI: Accepting AI-generated code without understanding or verifying it.
Ignoring AI errors: Failing to spot hallucinations, security risks, or incorrect logic in AI suggestions.
Poor communication: Not explaining their reasoning, choices, or why they accepted/rejected AI help.
Lack of testing: Relying on walkthroughs instead of thorough in-code verification and edge case testing.
Not asking clarifying questions: Jumping into coding without fully understanding the problem or constraints.

How to avoid these pitfalls:

Use AI as a tool, not a crutch—always review and test its output.
Communicate your thought process, especially when using or modifying AI suggestions.
Ask clarifying questions before starting, and narrate your approach as you go.
Test your code thoroughly, including edge cases.
If the AI makes a mistake, point it out and explain your correction to the interviewer.

6. Real-World Examples: Good vs. Bad Approaches

Example 1: “Implement a function to merge two sorted linked lists.”

Bad Approach:
- Accepts AI-generated code without reading it.
- Doesn’t test for edge cases (e.g., one list is empty).
- Fails to explain why the AI’s approach works or doesn’t.
Good Approach:
- Uses AI to generate a function stub, then manually implements the merge logic.
- Tests with multiple cases (both lists empty, one empty, both non-empty).
- Explains the merging process and why each step is necessary.

Example 2: “Find the longest substring without repeating characters.”

Bad Approach:
- Asks AI for a solution, copy-pastes it, and runs without understanding.
- Misses off-by-one errors or fails to handle Unicode/edge cases.
Good Approach:
- Discusses possible algorithms (sliding window, hash set).
- Uses AI for boilerplate, but writes and explains the core logic.
- Tests with strings like “abcabcbb”, “bbbbb”, and “pwwkew”.
- Explains why the chosen approach is optimal.

7. Sample Scenario: Agentic AI in Action

Prompt: “Find the longest palindrome in a string. You have access to an AI agent in the code editor.”

Strong approach:

Use AI to generate a function stub.
Discuss possible algorithms (expand around center, dynamic programming).
Ask the AI for documentation or hints if needed.
Review and test AI-generated code.
Explain your reasoning and choices to the interviewer.

8. Final Thoughts

Agentic AI coding interviews are not just about writing code—they’re about collaborating with intelligent tools. The best candidates:

Use AI to enhance productivity, not replace their own thinking.
Communicate clearly and justify their decisions.
Demonstrate adaptability and critical thinking.

Embrace the new format, practice with AI tools, and focus on your problem-solving fundamentals.

If you have more questions or want to discuss your interview prep, feel free to reach out!

Relevant CS career building advice

2025-11-02T00:00:00+00:00

Recently, a CS undergraduate student (pre-final year) approached me with a question that’s on the minds of many undergraduates:

“What should I do to excel in my career, especially now that LLMs & AI seem to be changing everything? I’m worried about jobs disappearing.”

This is a valid concern. The rise of LLMs and generative AI is transforming the tech landscape, automating some tasks while creating new opportunities—though the nature and number of these opportunities are still evolving. Here’s my advice—updated for the LLM era—on how to build a resilient, future-proof career in computer science.

1. Understand the Evolving Tech Landscape

Learn the basics, but stay curious about AI:
Master core CS concepts (DSA, OOP, OS, DBMS, Networking), but also understand how LLMs and generative AI are being integrated into products and workflows.
Explore new domains:
LLMs are not just for chatbots—they’re used in code generation, data analysis, content creation, and more. Stay updated on how different fields (healthcare, finance, education, etc.) are adopting AI.

2. Build a Strong Foundation—With an AI Twist

Core skills still matter:
Algorithms, data structures, and system design are the backbone of any tech role.
Add AI/ML fundamentals:
Take introductory courses in machine learning, NLP, and deep learning. Understand how LLMs work at a high level (transformers, embeddings, prompt engineering).
Learn to use LLMs as tools:
Practice using APIs like OpenAI, Meta Llama, or open-source models to solve real problems.

3. Project-Based Learning: Build with LLMs

Work on projects that leverage LLMs:
Instead of a generic to-do app, try building a smart assistant, a code review bot, or a content summarizer using LLM APIs.
Showcase your ability to integrate AI:
Employers value candidates who can use LLMs to automate tasks, enhance user experience, or create new products.
Document your process:
Write about your projects, challenges, and learnings—especially how you used LLMs creatively.

4. Internships and Real-World Experience

Target companies and teams working with AI:
Look for internships where you can contribute to or learn from projects involving LLMs, data pipelines, or AI-powered products.
Be proactive:
If your internship isn’t AI-focused, find ways to suggest or prototype LLM integrations for existing workflows.

5. Resume and LinkedIn Optimization for the AI Era

Highlight AI/LLM experience:
List projects, hackathons, or coursework involving LLMs, prompt engineering, or AI APIs.
Show adaptability:
Emphasize your ability to learn new tools and adapt to fast-changing tech.

6. Technical Interview Preparation: Beyond DSA

DSA is still important, but…
Some interviews now include questions on AI concepts, prompt design, or even using LLMs to solve problems.
Practice with AI tools:
Use LLMs to help you debug, generate code, or explain concepts as part of your prep—but don’t rely on them blindly.

7. Soft Skills and Communication in the Age of AI

Human skills are more valuable than ever:
LLMs can generate text, but they can’t replace empathy, leadership, or creative problem-solving.
Learn to collaborate with AI:
Treat LLMs as teammates—know when to trust their output and when to question it.

8. Networking and Mentorship

Connect with AI practitioners:
Join AI/ML communities, attend webinars, and participate in hackathons focused on generative AI.
Find mentors who understand the new landscape:
Seek guidance from professionals who are actively working with LLMs.

9. Continuous Learning: Stay Ahead of the Curve

Follow AI trends:
Subscribe to newsletters, blogs, and podcasts about LLMs and generative AI.
Experiment with new tools:
Try out the latest open-source models, prompt libraries, and AI platforms.

10. Explore Career Pathways Beyond Coding

LLMs are creating new roles:
Consider careers in prompt engineering, AI product management, AI ethics, or technical writing for AI products.
Interdisciplinary skills are in demand:
Combine your CS knowledge with domain expertise (e.g., healthcare + AI).

11. Dealing with Rejection and Exploring options

The landscape is competitive and changing:
Not every application will succeed, and that’s okay. Use feedback to improve and adapt.
Embrace lifelong learning:
The best way to future-proof your career is to keep learning and evolving.
AI is borderless:
Many AI/LLM projects are open-source and global. Contribute to international projects and consider remote roles.

12. Work-Life Balance and Mental Health

Don’t let AI hype overwhelm you:
Focus on your growth, not just the headlines. Take breaks, pursue hobbies, and maintain a healthy balance.

Final Thoughts

The rise of LLMs is not the end of tech jobs—it’s the beginning of a new era.
Those who learn to work with AI, adapt quickly, and focus on human strengths will thrive.
If you’re a student today, you have a unique opportunity to shape the future. Start building, keep learning, and don’t be afraid to ask questions—just like the student who inspired this post.

At this point in your career friend, you’ve have selected your domain: CS Tech. I encourage and challenge you to have a growth mindset and break boundaries. If I can do it, you can too.

No one has ever started untill they did.

If you have more questions or want to discuss your career path, feel free to reach out!

Leaving Google

2025-07-11T00:00:00+00:00

Leaving Google wasn’t an easy decision, and it’s one that many might not fully understand. After much deliberation, I’ve officially joined Meta (formerly Facebook) as a Software Engineer in their Bangalore office. I’m incredibly pumped and inspired to build new things, leaving behind the questions and thoughts that once kept me anchored at Google.

The transition was a mix of emotions. I genuinely admired my team, peers in India/US and organization at Google. However, my professional compass was pointing elsewhere. For over a year, I’d been immersed in the AI ecosystem, working with various libraries and database tools. While my work was very valuable, I found myself craving to build actual products that solve real-world problems directly.

The Journey to Meta: Rigorous and Rewarding

My journey to Meta began with a recruiter’s outreach. After explaining my current role, I dedicated extra time daily to an exhaustive and extensive preparation process. This involved a recruiter screen, two coding rounds, a system design interview, and a behavioral interview – about five rounds in total. Honestly, after all that, I wasn’t even sure if I’d made it!

But the good news eventually arrived: I had a team assigned in Bangalore. This was a crucial point for me, as I specifically requested to remain in India to avoid any visa issues.

Diving into AI-Powered Recruiting Tools

My new team, as publicly known, is focused on building AI-powered recruiting tools. I’ve spent a lot of time discussing with AI what all such a team could achieve. It’s clear that a primary goal would be to enhance the efficiency of the recruiting staff while significantly improving the experience for everyone involved in the hiring process.

Here are some of the exciting possibilities for how Meta can leverage AI in recruiting:

1: Enhanced Candidate Sourcing and Screening:

A. Automated Resume Analysis: AI can quickly scan and analyze vast numbers of resumes, identifying keywords, skills, and experiences that align with job requirements. This significantly reduces the manual effort for recruiters and helps them focus on the most promising candidates.

B. Predictive Matching: AI algorithms can match candidates with suitable job roles based on skills, experience, and even potential cultural fit, going beyond simple keyword matching. This can lead to more accurate and efficient shortlisting.

C. Passive Candidate Identification: AI-powered sourcing tools can scour various online platforms (e.g., LinkedIn, GitHub, academic papers) to identify individuals who may not be actively job searching but possess the desired skills and expertise.

D. Bias Mitigation: While not foolproof, AI can be designed to reduce unconscious bias in the initial screening process by focusing on objective criteria and minimizing human subjective judgment.

2: Streamlined Interview Processes:

A. AI-Assisted Interview Assessment: Meta is reportedly deploying an AI system to assess coding skills and suggest tailored interview questions. This system can also evaluate human interviewers, flagging inappropriate questions and analyzing feedback quality, aiming for consistency and fairness.

B. Virtual Assistants and Chatbots: AI-powered chatbots can handle initial candidate queries, provide information about open positions, guide applicants through the application process, and even conduct pre-screening assessments. They can also assist with scheduling interviews.

C. Video Interview Analysis: AI can analyze video interviews for speech patterns, facial expressions, and body language to provide insights that might be missed by human interviewers. Some AI tools can also detect if answers are original or AI-generated.

3. Personalized Candidate Experience:

A. Customized Job Postings: AI can help generate multiple versions of job descriptions tailored to different demographics, ensuring inclusive language and appealing to a diverse range of candidates.

B. Personalized Recommendations: AI systems can provide job recommendations to candidates based on in-depth profile analysis and tracked behaviors, making the job search more efficient for applicants.

4. Strategic Workforce Planning and Operational Efficiency:

A. Predictive Analytics: AI can analyze historical hiring data, market trends, and employee performance to forecast future talent needs. This allows HR teams to proactively source and nurture candidates for critical roles.

B. Skills Forecasting: AI can anticipate which skills and qualifications will be valuable in the future, helping Meta identify and develop talent pipelines accordingly.

C. Automating Administrative Tasks: AI can automate repetitive and time-consuming tasks like data entry, scheduling, email communications, and generating initial interview questions, freeing up recruiters to focus on more strategic aspects.

D. Onboarding Support: AI can streamline onboarding by automating tasks like document management, training scheduling, and providing responses to common new hire questions.

And it is indeed true and exciting that Meta is heavily investing in attracting top AI researchers and engineers by offering substantial compensation packages and the opportunity to work on ambitious projects like “superintelligence” in their Superintelligence Labs. This directly impacts internal recruitment of highly specialized AI talent. I hope to get the most through my work in the new role.

A wise man had once said, when you see a good opportunity, give it your all.

So, net-net I happily went through this job change. Now, I have so many good friends in Google, the folks with whom I worked and all the friends with whom I shared laughs, I feel the need to go visit the legendary Google offices back just to stay in touch. :relaxed: :relieved:

Needless to say, if you have ideas or thoughts to share about my new work domain (AI in SWE Recruiting), please do reach out! My team might want to expand soon ~~

Enabling Enterprise-Grade RAG

2025-05-15T00:00:00+00:00

While the world is betting & debating, big on agents and higher level use cases, me and my team were building lower level components for AI systems. This is almost all of past 6 months for me at Google. The rise of Generative AI has triggered a profound shift in how developers build intelligent applications. Among the most critical design patterns emerged is Retrieval-Augmented Generation (RAG), which bridges the limitations of large language models (LLMs) by grounding them in external, factual data sources. As this architecture matures, one challenge has become clear: infrastructure for vector search and document retrieval must meet enterprise-grade standards — secure, scalable, compliant, and battle-tested.

This is where the integrations of LangChain and LlamaIndex with Google’s managed Postgres solutions — AlloyDB and Cloud SQL — play transformative role. These open-source repositories:

…are not just bindings. They are composable primitives that bring AI-native capabilities to the world’s most trusted relational database system — PostgreSQL — backed by Google’s cloud infrastructure.

This essay explores their architecture, use cases, and long-term implications on enterprise AI adoption, developer workflows, and the future of in-database machine learning.

I. Background: From LLMs to RAG

When OpenAI released GPT-3 in 2020, developers quickly realized its power — and its constraints. Despite billions of parameters, the model was static and prone to hallucination. The Retrieval-Augmented Generation (RAG) paradigm emerged to fix this. Instead of asking the LLM to “know everything,” RAG retrieves relevant documents from an external store and feeds them as context to the model.

Two open-source frameworks crystallized this approach:

LangChain: Designed for LLM orchestration and agents, LangChain provides tools to build complex workflows involving memory, tools, and structured reasoning.
LlamaIndex: Focused on data ingestion and indexing, it excels at connecting unstructured data (PDFs, databases, websites) to LLMs for retrieval and summarization.

However, both requires reliable backend for storing and querying documents and embeddings. While vector databases like Pinecone, Weaviate, and Qdrant emerged to serve this role, enterprises — especially those in regulated industries — demanded something more familiar, observable, and integrated with their existing stack.

Enter PostgreSQL.

II. Why Postgres? Why Google?

Postgres is the most trusted open-source RDBMS globally. With decades of reliability, an extensive ecosystem, and rich extensions (e.g., pgvector), it’s uniquely positioned to support modern GenAI workloads.

Google Cloud offers two managed Postgres solutions:

Cloud SQL for PostgreSQL
- Fully managed Postgres
- Ideal for teams looking for convenience, backups, HA
- Now supports pgvector for embedding search
AlloyDB for PostgreSQL
- Google’s next-gen Postgres-compatible DB
- Superior performance (up to 100x faster analytical queries)
- Native vector search
- Ideal for low-latency, high-throughput RAG pipelines

By integrating LangChain and LlamaIndex with these services, developers can build retrieval systems that are:

Scalable (via Google infrastructure)
Secure (IAM, VPC-SC, customer-managed encryption)
Compliant (with HIPAA, FedRAMP, GDPR frameworks)
Unified (no need for separate vector DBs)

III. Architecture of the Integration

A. LangChain Integration

The langchain-google-alloydb-pg-python and langchain-google-cloud-sql-pg-python repositories implement:

A custom VectorStore class extending LangChain’s base
Automatic embedding storage, metadata management, and vector indexing
Integration with Google’s IAM Auth, pgvector extension, and standard SQL connectors

Key design decisions:

Batching: Inserts and queries are optimized to run in bulk, improving throughput.
Resiliency: Leveraging Google Cloud’s retry/backoff policies.
Hybrid Search Support: Embeddings + metadata filters and TSV based filtering, all in a single SQL query.

Example workflow:

from langchain_google_alloydb_pg import AlloyDBVectorStore
store = AlloyDBVectorStore.from_texts(
    ["LLMs are great", "AlloyDB supports vector search"],
    embedding=OpenAIEmbeddings(),
    collection_name="rag_docs"
)
retriever = store.as_retriever()

B. LlamaIndex Integration

These repositories expose:

A PGVectorStore implementation
A DocumentLoader optimized for loading AlloyDB/Cloud SQL query results
Integration with StorageContext, VectorStoreIndex, and metadata filtering

Key highlights:

Index persistence with doc_id tracking
In-DB schema design tailored for vector workloads
Streaming query support for large datasets (planned)

Example usage:

from llama_index.vector_stores import PGVectorStore
from llama_index import VectorStoreIndex, SimpleDirectoryReader, StorageContext

pg_store = PGVectorStore.from_params(...)
docs = SimpleDirectoryReader("./data").load_data()
index = VectorStoreIndex.from_documents(
    docs,
    storage_context=StorageContext.from_defaults(vector_store=pg_store)
)

IV. Use Cases: From Prototypes to Production

1. Enterprise RAG Apps

Many large companies already use Cloud SQL or AlloyDB as part of their backend. With these integrations, they can now:

Ingest internal documentation
Run hybrid search (embedding + metadata)
Answer queries via LLMs with traceability

Example: An insurance company builds a chatbot to answer policy-specific questions based on documents stored in their AlloyDB instance — without exporting sensitive data to external vector DBs.

2. In-Database Agent Workflows

LangChain’s agents can be extended to run SQL queries against AlloyDB and then re-ingest the results into vector stores. This enables self-improving agents that learn from operational data.

Example: A customer support bot retrieves prior resolved tickets from Cloud SQL, summarizes resolution patterns, and offers improved answers.

3. AI-Powered BI and Analytics

Using LlamaIndex with AlloyDB enables natural language interfaces over structured and semi-structured data. It supports:

Document loaders for SQL results
Vectorization of analytical outputs
Multi-hop reasoning over relational data

Example: A sales team queries past quarterly data using plain English and receives auto-generated insights powered by RAG and LLM summarization.

4. Multilingual Search Across Documents

Thanks to OpenAI/BGE embeddings and in-DB filtering, developers can build multilingual search portals on top of these integrations without any proprietary hosting infrastructure.

V. Implications

A. For Enterprises

These integrations remove key blockers for AI adoption: data gravity. Enterprises no longer need to move data to an unfamiliar stack. Instead, AI apps now run close to the data, respecting existing access policies and governance frameworks.

Security: IAM-based connections, encryption at rest, and VPC access ensure compliance.
Observability: Postgres-native logging and metrics simplify debugging.
Cost-efficiency: No need to pay for expensive third-party vector DBs.

B. For Developers

Rapid prototyping: Use the same infra for dev and prod.
Unified stack: One database, multiple modalities — structured, vector, metadata.
Better tooling: These open-source repos provide idiomatic APIs, CI/CD support, and reference examples.

C. For the Open-Source Ecosystem

This sets precedent for composable, cloud-native GenAI integrations. Instead of vendor lock-in, these repos embrace standard interfaces (LangChain/LlamaIndex APIs, SQL dialects) and contribute upstream improvements.

It also encourages other cloud providers and database vendors to follow suit — building GenAI-ready, open integrations with LLM frameworks.

VI. Future Directions

While these repositories already cover core functionality, several advanced features are planned or possible:

Streaming document ingestion with support for COPY FROM STDIN
Embedding index maintenance via background jobs or triggers
Temporal document versioning and time-aware retrieval
LLM cost tracking per query
Integrated caching for repeat queries
Hybrid search optimizers using learned ranking functions

VII. Conclusion

The LangChain and LlamaIndex integrations for Google AlloyDB and Cloud SQL for Postgres are more than just connectors — they are foundational building blocks for secure, scalable, and performant RAG applications. By combining the flexibility of Postgres, the scalability of Google Cloud, and the composability of GenAI frameworks, these repos unlock new frontiers: AI-native databases that serve both structured and unstructured workloads.

In a world where every app becomes an AI app, developers need primitives they can trust, at scale, with clarity. These integrations offer exactly that.

Postgres with Gen AI

2025-04-24T00:00:00+00:00

I’ve been working in the Gen AI space, especially for Postgres Databases enterprise customers, and I really love the optimism. Although the earlier hype was a little overwhelming, I see shoots to productionize AI in various industries. I met engineers from a couple of companies and attended a couple of companies’ conference calls around APAC. In this blog, I will cover what I’ve been doing in the space of AI/LLMs and what areas still need further clarity. All the contents written here are already announced as part of Google’s public developer summits and events, so please don’t expect any leaks here. :smile:

I took a closer look at how prevalent Postgres databases are in terms of the number of deployments across various industry verticals and are still growing. For example, a recent StackOverflow survey of 2023 and 2024 both claims that Postgres is used by 49% of developers, with the popularity only growing in recent years. Professional developers use Postgres more than any other database, and it is the most admired as well as desired database for enterprises. In the overall databases market, Postgres stands at roughly 20% share, if we include the on-premise database and local databases like Sqlite or NoSQL databases.

Based on its popularity and robust features, particularly with extensions like pgvector, PostgreSQL is increasingly used in various AI and Large Language Model (LLM) applications. PgVector defines the embedding datatype in PG and allows for various indexing (HNSW, IVFFlat) and querying methods on top of dense or sparse vectors. Google has actively contributed to PgVector.

Some customers with a larger corpus of data experience issues with index build time (hours for billions of records) and high memory usage (1M vectors is ~6GB); others need fast, real-time index updates or better vector query performance. Google has its proprietary indexing called Scann, which is the most advanced leading to faster vector queries on PG databases since it uses Approximate Nearest Neighbour (ANN) vector queries. This gives Google a significant edge over all other PG providers for AI / LLM use cases. But PG itself is a little laggard compared to vector-first databases such as Pinecone, Milvus, ChromaDB, Qdrant, and Weaviate, to name a few.

Currently, PG enterprise customers are hosting the data in PG but for experimentation, they dump some parts of the data (a few records/tables as samples) into some vector-first database assuming that PG won’t scale at their requirements, either in terms of long indexing time or slow query performance. Another problem is that the LLM prototypes are not being productionized because data migrations are hard and AI applications are only good if they can see a sizeable volume of data!

As part of “AI first Databases” strategy, Google released AI and LLM integrations for Alloy DB and Cloud SQL PG database, such as Model Endpoint Management, LangChain integrations and Llama-Index integration. These initiatives promise the PG developers that Google is in the “AI/LLM for Databases” game and it is in there for a long term.

Let’s look at the road ahead. There are no clear winners in the PG world for AI/LLM, but there are only initiatives to unlock use cases and efforts to win market share. I have already written about the current issues with Gen AI and they are still unsolved problems. But for certain enterprises who want to experiment and find their market fit, the AI/LLM ground is an open game. To them, AI is costly, but not impossible and potentially a cost-saving investment for automation in the long term.

I see following areas where AI and LLM deployments would contonue to shine:

Non-business critical systems that require big human time investment

Think of having an LLM application look into past issues and summarize the past fixes done. Example, IT dev tools, customer supports executive support, etc. I saw an example of this being developed for a US automaker OEM’s service centres too, for car technicians to chat before starting to work on an issue.
Cost of AI can be directly passed onto customers

The recurring infrastructure (servers) cost of running Gen AI applications is often more than the users’ subscription fees. Think of having an admin query, which traditionally requires a data analyst to pull sales reports and crunch data for a management report. Those premium tasks can use a paid AI.
Using a locally hosted AI

I don’t know about others but I do suffer from Model Fatigue (the challenge of constantly evaluating and choosing from a vast, rapidly evolving landscape of open-source models) and I often find myself unable to select the best open source models for my usecase. For low volume usecases (example for my own local usage) I can deploy a specific model until it critically suffers from hallucinations and accuracy issues.
LLMs for efficient querying

Usually powered by vector or embedding search over the data stored in PG, developers can create much more powerful applications. Vector search operations are more compute-intensive than traditional word-based search, so a query can define the degree of AI to be used for DB querying. For example, I worked on a LangChain integration with AlloyDB that used Postgres vector stores for embeddings. The performance gains were significant, but optimizing for latency required careful batching and indexing strategies.
Agentic workflows are catching up

MCP by Anthropic these days has emerged as a critical way to solve agent-to-agent communication. With MCP, atleast LLMs are quite accurate to call one layer of tools. It’s not yet very good when tools need to call other tools though. Google has released Gen AI Toolbox which aims to resolve issues with scaling and updating tools. This space is exciting and very promising. A lot can be done here and I am also interested in how this space unfolds.

In essence, while the Gen AI landscape is still rapidly evolving with its share of unsolved challenges, its integration with a steadfast and popular database like PostgreSQL is undeniably a game-changer. The strategic initiatives by Google, focusing on enhancing vector capabilities with innovations like Scann and streamlining development through comprehensive Gen AI Toolbox, underscore a strong commitment to making AI more accessible and powerful within the database itself. For enterprises and developers ready to navigate the costs and complexities, the potential to unlock significant efficiencies and build truly intelligent applications by leveraging their existing Postgres data is immense, paving the way for a future where AI and data are more deeply and seamlessly intertwined.

Current issues with gen ai

2024-08-08T00:00:00+00:00

I’ve recently started working in the Gen AI space and am really loving the optimism. But to some degree, I find the hype a little overwhelming. I attended several Google Developer Network events, AWS events, startup events, and a host of other conference calls around Asia. It was surprising to me that AI brings out very polarizing opinions from several well-known speakers. Some call it the end of the world, while others see it as a productivity boon that will usher in an age of prosperity and sufficiency.

I took a closer look at the large language models (LLMs) of today and noted some key facts and issues that organizations and their engineering teams often overlook while talking about the much-touted productivity:

LLMs are just tools to predict the next word and require significant manual effort to engineer into usable applications. There is no superhuman intelligence underneath. For example, embedding an LLM in a customer support workflow often requires custom logic for context retention, handling out-of-scope queries, and escalation paths.
LLMs are generally embedded into very data-intensive and sensitive applications. These applications need careful tuning with a huge amount of clean and relevant data, which is always a challenge to procure and maintain. A key challenge I encountered was integrating sensitive healthcare data into an AI chatbot, where compliance with HIPAA and GDPR required extensive anonymization and redaction processes.
AI applications need a lot of GPUs to function, and they are very costly to purchase and run. Not a lot of companies can afford them, so they survive on APIs provided by cloud providers or OpenAI. At Google, I’ve seen small startups rely heavily on Vertex AI for GPU access, often limiting their scale due to rising API costs. This creates an ecosystem where only well-funded companies can afford to innovate at scale.
The recurring infrastructure (servers) cost of running Gen AI applications is often more than the users’ subscription fees. Even when companies want to subsidize Gen AI feature development, it often ends up being unaffordable for users. For instance, a Gen AI-powered analytics platform I worked with spent 70% of its revenue on infrastructure costs, forcing them to redesign their pricing and architecture.
Despite being around for several years, LLMs still critically suffer from hallucinations and accuracy issues. In one case, an LLM incorrectly summarized a financial report, leading to misinformation being propagated in decision-making.
Any specialized Gen AI use case needs grounding with business data, usually powered by vector or embedding search over the data stored somewhere (preferably a database). Vector search operations are more compute-intensive than traditional word-based search. For example, I worked on a LangChain integration with AlloyDB that used Postgres vector stores for embeddings. The performance gains were significant, but optimizing for latency required careful batching and indexing strategies.
Agentic workflows are slow and unreliable. Often, key issues remain within discussions among agents. Developers feel like fixing one last issue will get the tool working end-to-end, but new users often break the entire flow. In a recent demo, I showcased an agent-based system for automating customer onboarding. While the agents performed well in controlled scenarios, unexpected user inputs frequently caused breakdowns, necessitating fallback mechanisms.
As of today, AI tools need AI engineers to function. AutoML solutions are bridging the gap for non-technical users, but deploying robust, scalable AI systems still demands expertise in data pipelines, model optimization, and monitoring.

While these challenges are significant, they also represent opportunities for innovation and collaboration in the developer community. By addressing these issues—through better tools, cost optimization, and improved reliability—we can unlock AI’s full potential to drive meaningful change.

Google and its reorgs

2024-06-22T00:00:00+00:00

Just when I felt settled, Google decided to move me from Cloud SWE to GCS SWE (Google Cloud Storage). The transition was bittersweet…

The process to move was mired with mixed feelings. I really admired my new manager and the new org, but I had my destination set elsewhere. I want to talk about what’s happening professionally and what I am doing to accommodate it.

I’ve already talked about my training in Microsoft about Embracing Change. But this time, I needed some extra dose of motivation. I was sort of pushed out of my org into another one. No human can stay motivated after this. For the first time, my optimism dipped to the core. This re-org was not about any tech adoption/deprecation or process improvement, it was about structure, Lol what!! One cannot do anything about re-org obviously, coz the answer to every question is “talk to your manager”. The only good thing was I met many great new people in the GCS org, but that was it.

The weirdness engulfed me, and I found myself constantly complaining about work and feeling disconnected. So, I applied internally to other roles and got into Databases org which is making ecosystem libraries for Gen AI. My decision point was, at least this sounds cool and comes out as closer to AI. Maybe I believed that everyone needs to be an AI engineer soon so better late than never. I was thinking about the levels and expectations as well and it seemed promising. On the surface, it looks optimistic, do work, travel to conferences, seek ideas externally, and spread ideas internally. But ultimately, my career now hinges upon the AI’s growth. Some customers have no idea why they want to do AI, others want god knows what level of intelligence with LLMs. But the sweet spot is with those who understand the space and are struggling with minute details. I hope to help atleast one such company through my work in the new role.

A wise man had once said, when you see a good opportunity, give it your all.

So, net-net I happily went through this re-org with no mixed feelings, because I had to change teams and any country move took a backside. I am putting little to no emphasis on customer engagement, but I do need to fetch feedback from them. So, I am friends with benefits with Database customers. With all the saved time, I am investing it into learning something new every day. Maybe I will need to re-read the book - DBMS. :smile:

Vishwaraj Anand

Phulwari Rent: A Family Bookkeeping App, Built by Conversation

The Problem: A Spreadsheet Wearing a Rent Register’s Costume

The Architecture That Won

The Login UX: Usernames, Not Emails

The Real Security Model: Custom Claims + Rules

Building It by Conversation

The Bits I Was Surprised To Care About

What I’d Build Next

Final Thoughts

Modernizing a 7-Year-Old Android App with Gemini

The Problem: Legacy Debt

The Solution: Agentic AI (Gemini)

My Strategy:

My Learnings: Handling the “Deep” Gradle Issues

The Technical Shift:

The Results

Code Snippets: Then vs. Now

Final Thoughts

Deleting autogenerated code

The Wake-Up Call: When Complexity Becomes the Enemy

Archaeology in Production: Unearthing Dead Code

The Deletion Sprint: Making It Real Work

AI Amplifies the Problem

The Senior Engineer’s Real Job

Cracking AI-Based SWE Interviews

1. Understand the Interview Format

2. What Interviewers Rate Upon

3. How These Interviews Differ from Traditional Rounds

4. Tips to Excel in Agentic AI Coding Interviews

5. Common Pitfalls in Agentic AI Coding Interviews

6. Real-World Examples: Good vs. Bad Approaches

7. Sample Scenario: Agentic AI in Action

8. Final Thoughts

Relevant CS career building advice

1. Understand the Evolving Tech Landscape

2. Build a Strong Foundation—With an AI Twist

3. Project-Based Learning: Build with LLMs

4. Internships and Real-World Experience

5. Resume and LinkedIn Optimization for the AI Era

6. Technical Interview Preparation: Beyond DSA

7. Soft Skills and Communication in the Age of AI

8. Networking and Mentorship

9. Continuous Learning: Stay Ahead of the Curve

10. Explore Career Pathways Beyond Coding

11. Dealing with Rejection and Exploring options

12. Work-Life Balance and Mental Health

Final Thoughts

Leaving Google

The Journey to Meta: Rigorous and Rewarding

Diving into AI-Powered Recruiting Tools

1: Enhanced Candidate Sourcing and Screening:

2: Streamlined Interview Processes:

3. Personalized Candidate Experience:

4. Strategic Workforce Planning and Operational Efficiency:

Enabling Enterprise-Grade RAG

I. Background: From LLMs to RAG

II. Why Postgres? Why Google?

III. Architecture of the Integration

A. LangChain Integration

B. LlamaIndex Integration

IV. Use Cases: From Prototypes to Production

1. Enterprise RAG Apps

2. In-Database Agent Workflows

3. AI-Powered BI and Analytics

4. Multilingual Search Across Documents

V. Implications

A. For Enterprises

B. For Developers

C. For the Open-Source Ecosystem

VI. Future Directions

VII. Conclusion

Postgres with Gen AI

Current issues with gen ai

Google and its reorgs