Vishwaraj Anand

Deleting autogenerated code

Mon, 22 Dec 2025 00:00:00 +0000

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

Tue, 02 Dec 2025 00:00:00 +0000

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

Sun, 02 Nov 2025 00:00:00 +0000

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

Fri, 11 Jul 2025 00:00:00 +0000

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

Thu, 15 May 2025 00:00:00 +0000

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

Thu, 24 Apr 2025 00:00:00 +0000

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

Thu, 08 Aug 2024 00:00:00 +0000

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

Sat, 22 Jun 2024 00:00:00 +0000

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:

Python, Python, dear Python

Wed, 08 May 2024 00:00:00 +0000

Python, a behemoth in the AI development world, has an undeniable dominance. Yet, a glaring omission has plagued it for years: native, seamless support for parallelism. In an era where hardware boasts multiple cores and users expect snappy responses, this limitation is increasingly conspicuous.

The Need for Speed (and Parallelism):

Past few months, I have been contemplating approaches that can give a performance boost to Google’s Python libraries, for example. I stumbled on issues with the GIL (global interpreter lock). I stumbled upon a problem that I cannot just accept is there in the world, the same as the one described in my earlier PHP’s lack of parallelism blog. We all know the famous stats on how Python is THE most common language in the world, but I am always amazed that it still lacks parallelism out of the box. It was so weird that I am thinking of switching teams internally within Google, rather than being optimistic about changing the state of affairs.

Tackling the Global Interpreter Lock:

The GIL, designed to simplify memory management, becomes a bottleneck in multi-threaded applications. This design choice impacts the performance of CPU-bound tasks, leaving developers to seek workarounds like multiprocessing or leveraging external libraries such as NumPy. While these solutions offer some relief, they don’t address the core issue.

So, as the news suggests, it appears Python version 3.13 (or possibly 3.14), will have no GIL versions. :revolving_hearts: :confetti_ball:

Exploring Alternatives:

Several solutions have been proposed to mitigate Python’s parallelism woes:

Multiprocessing: By spawning multiple processes, developers can bypass the GIL. However, this approach has its drawbacks, including increased memory usage and inter-process communication overhead.
Asyncio: Suitable for I/O-bound tasks, asyncio enables concurrency without parallelism, allowing developers to write asynchronous code that scales efficiently.
Cython: By compiling Python code to C, Cython can help achieve parallelism. It requires additional effort to convert and optimize code, but the performance gains can be significant.
Alternative Interpreters: PyPy, a just-in-time compiler, and Jython, which runs on the Java platform (really! but why?), offer performance improvements. Yet, they come with their own set of compatibility issues and limitations.

The Future of Python:

The Python community is actively exploring ways to overcome the GIL. Projects like PEP 554, which proposes multiple sub-interpreters to allow concurrent execution of Python code, are steps in the right direction. However, these changes will take time to mature and be widely adopted.

Python has tentacles too. I am following the pyscript project, which aims to run Python and its packages in a browser environment. Given so much community effort to have Python rule the world, I am sure it has an amazingly fast future. Just that it’s nowhere in sight yet!

Conclusion:

Python’s ease of use, readability, and extensive library support make it a favourite among developers for several years in a row, especially in the AI space. However, its struggle with parallelism remains a significant hurdle and nuisance for developers like me. While workarounds exist, they often complicate development and introduce new challenges. The hope is that ongoing efforts within the Python community will eventually address these issues, allowing Python to fully leverage modern hardware capabilities.

As developers, it’s crucial to stay informed about these developments and adapt our strategies accordingly. While Python’s parallelism problem is a current pain point, its potential solutions promise a brighter, more efficient future.

PHP and the lack of parallelism

Mon, 25 Dec 2023 00:00:00 +0000

PHP, a behemoth in the web development world, has an undeniable dominance. Yet, a glaring omission has plagued it for years: native, seamless support for parallelism. In an era where hardware boasts multiple cores and users expect snappy responses, this limitation is increasingly conspicuous.

The Need for Speed (and Parallelism):

Past few months, I was contemplating approaches that can give a performance boost to Google’s PHP libraries. Especially the handwritten ones which are for Spanner, Cloud Storage, BigQuery, Firestore, Datastore, to name a few. I stumbled on a problem that I cannot just accept is there in the world. We all know the famous stats on how PHP powers as much as 70% of the web, but I am always amazed that it still lacks parallelism out of the box. It was so weird that I am thinking of switching teams internally within Google, rather than being optimistic about changing the state of affairs.

PHP’s Parallelism Predicament:

So, How big is the impact? See PHP was created to support websites. And PHP considers each thread of execution as a single web request. While this may have been the case for pre-historic websites, even popular browsers allow parallelism nowadays. But PHP does NOT! It has developed a whole ecosystem without parallelism. PHP’s philosophy seems to be that if there’s anything which needs parallel execution (like downloading large files in chunks in non-blocking parallel scripts), do NOT do it using PHP.

Simple goals in life:

My goal was to upgrade MultipartUploader to somehow do parallel calls. There were several approaches I considered before jumping off the ship and not doing anything in this domain:

1. PHP implementation based on curl-multi (promising)

Curl multi is already available in PHP, but requires a redesign of MultipartUploader to achieve results. Currently, Google’s libraries create a multipart guzzle stream and send it over to network requests.

I was hopeful that if I initialize several curl_multi_* handles and assigns each part of the network request to a handle, it can theoretically parallelize the uploads. But it actually just uses concurrency.

// create both cURL resources
$ch1 = curl_init();
$ch2 = curl_init();

// set URL and other appropriate options
curl_setopt($ch1, CURLOPT_URL, "http://example.com/");
curl_setopt($ch1, CURLOPT_HEADER, 0);
curl_setopt($ch2, CURLOPT_URL, "http://www.php.net/");
curl_setopt($ch2, CURLOPT_HEADER, 0);

//create the multiple cURL handle
$mh = curl_multi_init();

//add the two handles
curl_multi_add_handle($mh,$ch1);
curl_multi_add_handle($mh,$ch2);

//execute the multi handle
do {
    $status = curl_multi_exec($mh, $active);
    if ($active) {
        // Wait a short time for more activity
        curl_multi_select($mh);
    }
} while ($active && $status == CURLM_OK);

2. Redesigning MultipartUploader with Fibers

PHP recently released Fibers as of PHP8.1, which offers controlled concurrency to PHP. Though the min php version currently supported by Google is php8.0, once it’s upgraded to php8.1, (already reached end-of-life EOL) I saw merits in this approach for consurrency. But once I read about it, I was disappointed with Fibers being just a lollipop and not much else to PHP developers. It’s CONCURRENT. After all these years, Fibers was released and it proved to be such a dud for my use case.

3. Writing my own extension

At one point, I did really consider my own zend extension (GRPC is also a zend extension) to allow parallelism. I learnt that even though PHP extensions are written in C, it becomes a part of the php-fpm process and the code lives in the same address space. So, it seemed like adding a pthread would be magical. But I was met with surprises even here. I would have to handle all the resources across threads, which means synchronization problems, memory leaks and what not! It’s really not easy to do this. I realized I am drifting towards re-inventing pThreads, which is only available via PHP CLI.

4. Inspiration from `Aws\CommandPool`

I observed that Aws\CommandPool does a lot of magic to achieve my requirements. AWS libraries employ an async pool to achieve concurrency. Frankly, I was not at all happy with the state of affairs even with AWS libs.

5. External Libraries (ReactPHP, Spatie, Parallel)

As a library developer, I cannot afford to have a dependency on these packages, especially those whose maintenance is not guaranteed and ours have to be because of Enterprise agreements. But it was really heartening that there are so many people who echo my pain and go as deep as creating their own libraries. :salute:

What Does This Mean for Developers?

I realized that some developer (me) users might be happier using other language libraries, their code and system utilization might be more optimal given they use any other language library.
Embrace Asynchronous Programming to work with limitations. But this also means adding software development costs (think of higher debugging time as costs).
Really consider ReactPHP, AmpPHP, or similar libraries to work with limitations. Otherwise, you will waste a lot of your time.
Consider running a performance sensitive workload via a more promising language. Say, Go or Node.js. However, you might be paying for serializing and de-serializing the data.

Conclusion

So, who’s to blame? IMHO, it’s the PHP maintainers who should take a call to modernize the language. The historical design of PHP prioritized simplicity and ease of use, which has contributed to its widespread adoption. However, modern web applications require more advanced concurrency and parallelism capabilities.

Parallelism was one key reason Facebook was forced to fork their own programming language called Hacklang based on PHP. And believe it or not, it’s much more performant than PHP itself. Take a bow, Mr. Zuckerberg.

The PHP community and maintainers are aware of these limitations and are making incremental improvements (Ex Fibers). As developers, we should push for these changes while also exploring existing tools and libraries that can help us bridge the gap in the meantime.

Vishwaraj Anand

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

Python, Python, dear Python

The Need for Speed (and Parallelism):

Tackling the Global Interpreter Lock:

Exploring Alternatives:

The Future of Python:

Conclusion:

PHP and the lack of parallelism

The Need for Speed (and Parallelism):

PHP’s Parallelism Predicament:

Simple goals in life:

1. PHP implementation based on curl-multi (promising)

2. Redesigning MultipartUploader with Fibers

3. Writing my own extension

4. Inspiration from Aws\CommandPool

5. External Libraries (ReactPHP, Spatie, Parallel)

What Does This Mean for Developers?

Conclusion

4. Inspiration from `Aws\CommandPool`