DEV Community: Valipireddy Kowshik

Your Index Isn't Being Used: A Senior Engineer's Guide to Database Indexing

Valipireddy Kowshik — Fri, 23 Oct 2026 05:29:00 +0000

Every slow query gets the same advice: "add an index." Sometimes that fixes it in seconds. Sometimes it does nothing, and sometimes it makes your writes twice as slow.

An index is a trade: faster reads in exchange for slower writes and more storage. The senior move is knowing exactly what you're buying.

Start with the query, not the table

Before you create anything, answer three things:

What does the query filter on, sort by, and return?
How selective is the filter? (1 row in a million, or half the table)
How often does this table get written to?

Indexes serve query patterns, not columns. "Index the user_id column" is a guess. "Index the query that fetches a user's latest orders" is a design.

How a B-tree actually helps

Without index:  scan every row            -> O(n)
With B-tree:    walk the tree to the row  -> O(log n)

                 [ 50 | 100 ]
                /     |      \
        [10|30]   [60|80]   [120|150]
         / | \     / | \      / |  \
       leaf pages with pointers to table rows

The tree keeps values sorted. That's why one index can serve equality (=), ranges (>, BETWEEN), and ORDER BY, but not arbitrary substring searches.

Composite indexes: order is everything

An index on (a, b, c) is sorted by a, then b within a, then c within b. It follows the leftmost prefix rule.

CREATE INDEX idx_orders_user_status_created
  ON orders (user_id, status, created_at);

Query filters on	Uses the index?
`user_id`	Yes
`user_id, status`	Yes
`user_id, status, created_at`	Yes (fully)
`status` only	No (skips the leading column)
`created_at` only	No

The ordering heuristic: equality columns first, then the range column, then the sort column.

-- Equality on user_id and status, sorted by created_at: one index walk, no sort step
SELECT * FROM orders
WHERE user_id = 42 AND status = 'paid'
ORDER BY created_at DESC
LIMIT 20;

Read the plan, don't guess

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders WHERE user_id = 42 AND status = 'paid'
ORDER BY created_at DESC LIMIT 20;

Seq Scan on orders          <- bad on a big table: reads everything
Index Scan using idx_...    <- good: walks the tree
Index Only Scan             <- best: never touches the table
Bitmap Heap Scan            <- fine: many matching rows

Look at actual time, rows removed by filter, and buffers read. A plan that reads 100k rows to return 20 is the problem, whatever scan type it uses.

Why your index isn't being used

1. A function wraps the column

-- Can't use an index on email
WHERE LOWER(email) = 'a@b.com'

-- Fix: index the expression
CREATE INDEX idx_users_email_lower ON users (LOWER(email));

2. Implicit type casts

-- phone is VARCHAR, but you compare to a number: cast on every row
WHERE phone = 5551234

Match your types, or the planner can't use the index.

3. Leading wildcard

WHERE name LIKE '%smith'   -- full scan
WHERE name LIKE 'smith%'   -- can use an index

For true substring or fuzzy search, use pg_trgm or full-text search.

4. Low selectivity

An index on a boolean is_active where 95% of rows are true is useless. The planner correctly decides scanning is cheaper. Which leads to a better tool.

Partial and covering indexes

Partial index: index only the rows you query.

CREATE INDEX idx_orders_pending
  ON orders (created_at)
  WHERE status = 'pending';

Smaller, faster, cheaper to maintain. Perfect for "the small hot slice" of a big table.

Covering index: include extra columns so the query never touches the table.

CREATE INDEX idx_orders_user_covering
  ON orders (user_id, created_at DESC)
  INCLUDE (total, status);

This enables an Index Only Scan, which is often the biggest single win for read-heavy endpoints.

The cost nobody puts in the tutorial

INSERT one row into a table with 8 indexes
 -> 1 table write + 8 index writes + WAL for all of them

Every index adds write amplification, slows UPDATEs that touch indexed columns, and eats memory that your hot data wanted.

Find the dead weight:

SELECT relname AS table, indexrelname AS index, idx_scan,
       pg_size_pretty(pg_relation_size(indexrelid)) AS size
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY pg_relation_size(indexrelid) DESC;

An index with idx_scan = 0 over a full business cycle is a candidate for removal (check replicas too, since stats are per node).

Ship it safely in production

A plain CREATE INDEX blocks writes to the table. On a live system, use:

CREATE INDEX CONCURRENTLY idx_orders_user_status_created
  ON orders (user_id, status, created_at);

It takes longer and can't run inside a transaction, but it doesn't lock out your writers. If it fails it leaves an invalid index behind, so check for it and drop it before retrying.

What to measure

p95/p99 latency of the specific query before and after
Rows examined vs rows returned (the ratio should be close to 1)
Write latency on the table after adding the index
Index size vs table size (an index bigger than the table is a smell)

Rules I follow

Index for a known query, never "just in case."
Equality first, range second, sort last.
Prefer partial and covering indexes for hot paths.
Verify with EXPLAIN ANALYZE on production-sized data, since small tables lie.
Audit unused indexes on a schedule.
Always CONCURRENTLY on live tables.

Takeaway

A good index makes a query 1000x faster. A bad one is a tax on every write that you pay forever. Treat indexes as part of your schema design, measure them like any other dependency, and delete the ones that don't earn their keep.

What's the biggest speedup (or self-inflicted slowdown) an index ever gave you? Share it in the comments. 👇

Caching Is Easy. Cache Invalidation Is Where Systems Break: A Practical Guide

Valipireddy Kowshik — Thu, 22 Oct 2026 05:26:00 +0000

Adding a cache takes ten minutes. Debugging the bug it causes six months later takes a week.

Caching trades correctness for speed. The senior move is deciding how much correctness you're willing to give up, and making that decision explicit.

Start with the question, not the tool

Before you reach for Redis, answer three things:

How stale can this data be? (seconds, minutes, never)
What does a wrong answer cost? (a flicker, or a wrong invoice)
What's the read-to-write ratio? (caches pay off on read-heavy data)

If you can't answer #1, you're not ready to cache it.

The four patterns

CACHE-ASIDE (lazy)            WRITE-THROUGH
App -> Cache: hit? return     App -> Cache -> DB
      miss -> DB -> fill      (write both, in order)

WRITE-BEHIND                  READ-THROUGH
App -> Cache -> (async) DB    App -> Cache (cache loads DB itself)

Pattern	Good for	Risk
Cache-aside	Most apps, default choice	Stale reads, stampedes
Write-through	Data read right after write	Slower writes
Write-behind	Write-heavy, loss-tolerant	Data loss if cache dies
Read-through	Simplifying app code	Provider lock-in

My default: cache-aside with a TTL. It's simple, and failure is safe because the DB stays the source of truth.

Cache-aside in code

async function getUser(id) {
  const key = `user:${id}`;

  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const user = await db.users.findById(id);
  if (user) {
    // TTL + jitter so keys don't all expire together
    const ttl = 300 + Math.floor(Math.random() * 60);
    await redis.set(key, JSON.stringify(user), "EX", ttl);
  }
  return user;
}

async function updateUser(id, data) {
  await db.users.update(id, data);
  await redis.del(`user:${id}`); // invalidate, don't update
}

Delete on write, don't update. Updating the cache invites race conditions where an older write lands after a newer one.

The three failure modes

1. Cache stampede

A hot key expires and thousands of requests hit the database at once.

t=0   key expires
t=0+  [req][req][req][req][req] -> all miss -> all hit DB -> DB falls over

Fixes:

Request coalescing (single flight): one request rebuilds, the rest wait.
Lock on rebuild with a short timeout.
Stale-while-revalidate: serve the old value while one worker refreshes.
TTL jitter, as in the code above.

const inflight = new Map();

function singleFlight(key, loader) {
  if (inflight.has(key)) return inflight.get(key);
  const p = loader().finally(() => inflight.delete(key));
  inflight.set(key, p);
  return p;
}

2. Cache penetration

Requests for keys that don't exist always miss and always hit the DB (bots love this).

Fix: cache the negative result briefly (null with a 30-60s TTL), or put a Bloom filter in front.

3. Stale data after writes

Thread A: reads DB (old)  ............  writes cache (old)
Thread B:        updates DB (new), deletes cache
Result: cache now holds OLD data until TTL

Fixes: short TTLs as a safety net, versioned keys (user:42:v7), or event-driven invalidation from the write path.

Layers matter

Browser cache -> CDN -> API gateway -> App memory -> Redis -> DB
   (fastest, least control) ------------------> (slowest, most control)

Push caching as close to the user as correctness allows. For public, static-ish data, HTTP headers do more than any Redis cluster:

Cache-Control: public, max-age=60, stale-while-revalidate=300

What to measure

Hit ratio (below ~80% on a hot path means rethink the key design)
p99 latency with and without cache
Eviction rate and memory pressure
DB load during cold start: can you survive an empty cache?

That last one is the real test. If a cache flush takes you down, your cache isn't an optimization, it's a dependency.

Rules I follow

The database is the source of truth, always.
Every key has a TTL. No exceptions.
Invalidate by deleting, not by updating.
Design for a cold cache on day one.
Don't cache what you can't afford to be wrong.

Takeaway

There are only two hard things in computer science: cache invalidation and naming things. Treat invalidation as a design problem up front, and your cache stays a speed boost instead of becoming a source of mysterious bugs.

What's the nastiest caching bug you've shipped? Share it in the comments. 👇

Retries Are a Distributed Systems Bug Waiting to Happen: Designing Idempotent APIs

Valipireddy Kowshik — Wed, 21 Oct 2026 04:24:00 +0000

Every network call can fail in three ways: it fails, it succeeds, or it succeeds and you never find out. The third case is where most production incidents live.

Junior instinct: "Request timed out, retry it."
Senior question: "What if the first one actually went through?"

The core problem

Client                 Server                  DB
  | --- POST /charge --> |                      |
  |                      | --- INSERT charge -> |
  |                      | <------- OK -------- |
  |   X (response lost)  |                      |
  | --- POST /charge --> |   (retry)            |
  |                      | --- INSERT charge -> |   <- duplicate

The client can't tell "never arrived" from "arrived, reply lost." Retrying blindly means double charges, duplicate orders, double emails.

Fix 1: Idempotency keys

The client generates a unique key per logical operation and sends it on every attempt. The server stores the result and replays it.

Client                       Server
  | POST /charge                |
  | Idempotency-Key: abc-123 -> | not seen: process, store result
  |  X (response lost)          |
  | POST /charge                |
  | Idempotency-Key: abc-123 -> | seen: return stored result, no new charge

app.post("/charge", async (req, res) => {
  const key = req.get("Idempotency-Key");
  if (!key) return res.status(400).json({ error: "Idempotency-Key required" });

  // Atomic claim: unique constraint on key
  const claimed = await db.idempotency.insertIfAbsent({
    key, status: "in_progress", requestHash: hash(req.body),
  });

  if (!claimed) {
    const existing = await db.idempotency.get(key);
    if (existing.requestHash !== hash(req.body))
      return res.status(422).json({ error: "Key reused with different payload" });
    if (existing.status === "in_progress")
      return res.status(409).json({ error: "Request in progress" });
    return res.status(existing.code).json(existing.response); // replay
  }

  const result = await chargeCard(req.body);
  await db.idempotency.complete(key, 200, result);
  res.json(result);
});

Details that matter:

Make the claim atomic (unique constraint, not check-then-insert).
Hash the payload. Same key with a different body is a client bug, so reject it.
Handle the in-progress state so concurrent retries don't race.
Set a TTL (24-72h is common).

Fix 2: Retry correctly

Retries without backoff turn a blip into an outage (the retry storm).

Attempt:  1    2      3         4              5
Wait:     0 -> 1s -> 2s ------> 4s -----------> 8s   (exponential)
               +-jitter: random within each window

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

async function retry(fn, { retries = 5, base = 200, cap = 10_000 } = {}) {
  for (let i = 0; ; i++) {
    try { return await fn(); }
    catch (err) {
      if (i >= retries || !isRetryable(err)) throw err;
      const backoff = Math.min(cap, base * 2 ** i);
      await sleep(Math.random() * backoff); // full jitter
    }
  }
}

Jitter is not optional. Without it, every client retries in lockstep.
Only retry transient errors (timeouts, 429, 503), never 400/401/404.
Respect Retry-After. Put a retry budget at the service level.

Fix 3: The dual-write problem

await db.save(order);        // succeeds
await queue.publish(event);  // crashes here -> DB and queue disagree

You can't make two systems commit atomically. Use the transactional outbox:

+---------- one DB transaction ----------+
|  INSERT order       INSERT outbox_event |
+-----------------------------------------+
              |
     relay polls outbox -> publishes to queue -> marks sent

This gives at-least-once delivery, so consumers must be idempotent too (dedupe by event ID).

What I'd standardize on

Layer	Rule
Write endpoints	Require `Idempotency-Key`
Clients	Exponential backoff + full jitter + cap
Messaging	Outbox + idempotent consumers
Semantics	Assume at-least-once, design for it

Takeaway

"Exactly-once" is mostly a myth. What you actually build is at-least-once delivery plus idempotent processing, which behaves like exactly-once from the outside.

Design every write as if it will be sent twice, because eventually it will be.

How does your team handle idempotency? Keys, natural dedupe, or hope? Let me know in the comments. 👇

5 Git Mistakes Every Developer Makes (and the One-Line Fixes)

Valipireddy Kowshik — Tue, 20 Oct 2026 03:23:00 +0000

Git is easy until it isn't. Here are five mistakes everyone makes, and how to fix each in one line.

1. "I committed to the wrong branch"

git switch correct-branch
git cherry-pick <commit-hash>
git switch wrong-branch
git reset --hard HEAD~1

Copy the commit over, then remove it from the wrong branch.

2. "I need to undo my last commit"

Pick based on what you want to keep:

Command	Commit	Staged	Files
`git reset --soft HEAD~1`	removed	kept	kept
`git reset --mixed HEAD~1`	removed	removed	kept
`git reset --hard HEAD~1`	removed	removed	deleted

Source: DataCamp (credit the original)

Already pushed? Use git revert <hash>. It adds a new commit instead of rewriting history.

3. "I lost my work after a bad reset"

You probably didn't. Git remembers where HEAD has been:

git reflog
git reset --hard <hash-from-reflog>

4. Merge or rebase?

Source: ByteByteGo (credit the original)

Merge: keeps full history, safe for shared branches.
Rebase: gives a clean linear history, but never rebase a branch others are using.

5. "I committed a secret or a huge file"

git rm --cached .env
echo ".env" >> .gitignore
git commit -m "Stop tracking .env"

If it was pushed, rotate the key and scrub history with git filter-repo.

Cheat sheet

git stash            # save work temporarily
git stash pop        # bring it back
git commit --amend   # fix the last commit message
git restore <file>   # discard changes to a file
git log --oneline --graph   # see history visually

TL;DR

Wrong branch? cherry-pick + reset
Undo locally? reset. Undo pushed? revert
Lost something? git reflog
Shared branch? Merge, don't rebase

What's your worst Git horror story? Tell me in the comments. 👇

7 Developer Bugs That Waste Hours and How to Fix Them Fast

Valipireddy Kowshik — Mon, 19 Oct 2026 02:18:09 +0000

Every developer has lost an afternoon to a bug that turned out to be a one-line fix. This post covers seven common ones across frontend, backend, and DevOps, with the fix for each.

1. CORS errors: "No 'Access-Control-Allow-Origin' header"

The problem: Your frontend calls your API and the browser blocks it.

Why it happens: CORS is enforced by the browser, and the server has to opt in. Changing frontend code won't fix it.

The fix (Express):

import cors from "cors";

app.use(cors({
  origin: ["http://localhost:3000", "https://yourapp.com"],
  methods: ["GET", "POST", "PUT", "DELETE"],
  credentials: true,
}));
```



**Gotcha:** If you use `credentials: true`, you can't use `origin: "*"`. List your origins explicitly. Also check that your server handles `OPTIONS` preflight requests.

## 2. The N+1 query problem

**The problem:** Your API is slow, and the logs show hundreds of near-identical queries.



```javascript
// Bad: 1 query for posts + N queries for authors
const posts = await Post.findAll();
for (const post of posts) {
  post.author = await User.findByPk(post.authorId);
}
```



**The fix:** Use eager loading or a join.



```javascript
// Good: 1-2 queries total
const posts = await Post.findAll({ include: [User] });
```



**Tip:** Turn on query logging in development. N+1 problems are easy to spot once you can see the SQL.

## 3. Forgetting `await` (and unhandled promise rejections)

**The problem:** Your function "works" but returns `Promise { <pending> }`, or crashes Node with an unhandled rejection.



```javascript
// Bug: errors are swallowed, order isn't guaranteed
items.forEach(async (item) => {
  await saveItem(item);
});
```



**The fix:** `forEach` doesn't wait for async callbacks. Use `for...of` for sequential work or `Promise.all` for parallel work.



```javascript
// Sequential
for (const item of items) await saveItem(item);

// Parallel
await Promise.all(items.map(saveItem));
```



Always wrap the top-level call in `try/catch`, or attach `.catch()`.

## 4. Secrets committed to Git

**The problem:** An API key or {% raw %}`.env`{% endraw %} file ends up in your repo. Bots scan public GitHub constantly, so a leaked key can be abused within minutes.

**The fix:**

1. **Rotate the key immediately.** Deleting the commit isn't enough, because the key is still in history.
2. Add `.env` to `.gitignore`.
3. Scrub history with `git filter-repo` or BFG Repo-Cleaner.
4. Add a pre-commit scanner like `gitleaks` or `trufflehog`.



```bash
# .gitignore
.env
.env.*
!.env.example
```



Commit a `.env.example` with fake values so teammates know what's required.

## 5. Docker builds that never use the cache

**The problem:** Every {% raw %}`docker build`{% endraw %} reinstalls all your dependencies.


{% raw %}
```dockerfile
# Bad: any code change invalidates the npm install layer
COPY . .
RUN npm install
```
{% endraw %}


**The fix:** Order layers from least to most frequently changed.


{% raw %}
```dockerfile
# Good: dependencies are cached until package files change
COPY package*.json ./
RUN npm ci
COPY . .
```
{% endraw %}


Add a {% raw %}`.dockerignore`{% endraw %} (with {% raw %}`node_modules`{% endraw %}, {% raw %}`.git`{% endraw %}, and {% raw %}`dist`{% endraw %}) to keep the build context small.

## 6. React: infinite re-renders and stale state

**The problem:** {% raw %}`Too many re-renders`{% endraw %}, or a {% raw %}`useEffect`{% endraw %} that runs forever.


{% raw %}
```javascript
// Bug: new object every render, so the effect re-fires every time
useEffect(() => {
  fetchData(options);
}, [options]); // options = { page: 1 } defined inline
```
{% endraw %}


**The fix:** Memoize objects and functions used in dependency arrays, or depend on primitives.


{% raw %}
```javascript
const options = useMemo(() => ({ page }), [page]);
useEffect(() => { fetchData(options); }, [options]);
```
{% endraw %}


If state looks stale inside a callback, use the functional update form: {% raw %}`setCount(c => c + 1)`{% endraw %}.

## 7. Memory leaks in long-running Node.js services

**The problem:** Memory climbs until the process crashes with {% raw %}`JavaScript heap out of memory`{% endraw %}.

**Common causes:**
- Event listeners added but never removed
- Unbounded in-memory caches (a plain {% raw %}`Map`{% endraw %} that only grows)
- Timers ({% raw %}`setInterval`{% endraw %}) that are never cleared
- Closures holding references to large objects

**How to find it:**


{% raw %}
```bash
node --inspect app.js
# Open chrome://inspect, take heap snapshots, compare them
```
{% endraw %}


Take one snapshot at startup and another after load, then look at what's growing. For caches, use an LRU cache with a max size instead of a bare `Map`.

## Debugging checklist

When you're stuck, run through this:

- [ ] Can I reproduce it reliably?
- [ ] What changed since it last worked? ({% raw %}`git bisect`{% endraw %} helps)
- [ ] Am I reading the *actual* error message and stack trace?
- [ ] Have I checked the network tab, logs, and environment variables?
- [ ] Can I shrink it to a minimal reproducible example?

## Wrapping up

Most of these bugs come from a handful of root causes: misunderstanding where a rule is enforced (CORS), hidden cost (N+1), async behavior, and configuration hygiene. Learning to recognize the *category* of a problem speeds up debugging a lot.

**Which of these has cost you the most time? Share your worst debugging story in the comments.** 👇

Why I Walked Away From "Just" Full-Stack Dev to Build AI Agents

Valipireddy Kowshik — Wed, 16 Sep 2026 09:05:32 +0000

The moment I realized I'd already built one

A few months ago I was deep in the architecture of a voice-first AI technical interviewer — a platform that speaks to a candidate out loud, watches their keystrokes live over a WebSocket connection, nudges them with a hint when they're stuck, and at the end, outputs a structured hiring scorecard instead of a vague "went okay" note for a recruiter to guess at.

I wasn't building a chatbot. I was building something that observed, decided, and acted, on its own, inside a real workflow that used to require a human sitting in the room. Somewhere in the middle of wiring up the WebSocket editor deltas and the finite state machine that decided when to intervene, it hit me: this is an AI agent. I just hadn't been calling it that.

That realization is the reason I now spend most of my time building AI agents for businesses, not because I abandoned web development, but because I finally had a name for the kind of engineering I'd already drifted toward.

Where I actually started

For the last three-plus years I've been a full-stack and React Native engineer, not an "AI person." My days looked like:

Shipping patient health flows at Tap Health — glucose tracking, meal logging, multi-step onboarding — in React, Next.js, and React Native, and chasing down the unglamorous bugs that actually break trust: timezone mismatches, state sync issues, navigation deadlocks.
Building doctor portals, HR platforms, and admin dashboards from scratch at ZarvisGenix, wiring up role-based access control, real-time data sync, and secure APIs with Prisma and PostgreSQL.
Sitting in rooms with investors and clinicians, translating what they actually needed into software that had to work correctly the first time, because in health tech, "close enough" isn't a shippable standard. None of that reads like an AI career on paper. But there's a thread running through all of it: I was always the person who got handed the workflow nobody had automated yet, and asked to make it disappear into software.

The pattern I couldn't unsee

At ZarvisGenix, I also built and integrated AI-powered speech-to-text pipelines, intelligent voice transcription that fed straight into automated workflows. It wasn't the headline feature of the project. It was infrastructure. But it was the first time I noticed something: the AI part of the system was never the hard part. The hard part was everything around it, the authentication, the rate limiting, the data schema, the error handling for when a transcription came back malformed, the part where the "smart" feature actually had to survive contact with real users and real edge cases.

That's a pattern I kept seeing repeat, project after project. Everyone wanted "AI" bolted onto their product. Almost nobody had thought through what happens when the AI is wrong, or slow, or needs to talk to four other systems to do its job. The gap wasn't a model problem. It was an engineering problem. And engineering problems are exactly what three years of production full-stack work had trained me to solve.

Why most "AI agents" on the market fall apart

Once I started paying attention, I noticed the same failure mode everywhere, on Fiverr, in client requests, in demos I got shown by other teams: someone wraps a system prompt around GPT or Claude, calls it an "agent," and ships it. It works beautifully in the demo. It falls over the moment a real user asks something slightly off-script, or the business needs it to actually do something instead of just reply, like check a calendar, update a CRM record, or hand off to a human at the right moment.

That's not an agent. That's a chatbot wearing an agent's name tag.

The AI Technical Interviewer project is the clearest proof I have that the difference is real. It didn't just generate text, it had to synthesize speech in under 300ms to feel human, track state deterministically so it never lost context mid-interview, evaluate code in a live sandbox, and produce a structured decision a hiring manager could actually act on. Every one of those requirements is a systems engineering problem wearing an AI costume. Get the engineering wrong and it doesn't matter how good the underlying model is.

Why I think this makes me a better fit than most agent builders

Here's the honest version, not the sales pitch version: a lot of people entered the "AI agent developer" space over the last year with no software engineering background at all. They learned a no-code automation tool, connected a couple of APIs, and started calling themselves AI agent specialists. Some of that work is genuinely fine for simple use cases. But it tends to break exactly where it matters most, at scale, under load, or when a client's business actually depends on the thing not failing silently at 2am.

I came at this from the opposite direction. I didn't start with prompts and work backward into engineering. I started as a production engineer, obsessive about frame budgets, latency, and deterministic state, and only later started pointing that discipline at AI systems. That means when I build an agent for a business, it's not a demo wearing a business's logo. It's:

Connected to real tools, CRMs, calendars, databases, not just answering in a vacuum
Built with proper error handling for the moment the model gets something wrong, because it will
Documented and handed off cleanly, so a client isn't permanently dependent on me to keep it running
Designed around the actual workflow a business has, not a generic template I resell to everyone ## What I actually build now

These days, most of my client work falls into one of these buckets:

Lead qualification and booking agents that engage a lead the moment they message, ask the right questions, and book directly into a calendar
Knowledge-base agents trained on a business's actual PDFs, docs, or website content, so answers are accurate instead of generic
Multi-channel agents that work across a website, WhatsApp, and voice, from one underlying system
Workflow automation using n8n to connect the agent into the tools a business already runs on None of this replaces the full-stack work. If anything, it's the same skill set pointed at a newer kind of problem. The React Native apps, the Next.js dashboards, the Prisma schemas, all of that is still the foundation. The agents just sit on top of it now.

If you're weighing the same move

If you're a web or full-stack developer looking at the AI agent space and wondering whether it's a real shift or just a rebrand, here's what I'd tell you: it's real, but only if you bring the engineering discipline with you. The market is already full of people who can wire up a chatbot in an afternoon. It is not full of people who can make that chatbot survive a real business's actual workflow. That gap is where the work is.

I build custom AI agents for businesses using GPT and Claude, you can see exactly what that looks like on my Fiverr gig. If you're trying to figure out whether your business actually needs one, or you're a fellow developer thinking about making the same jump, I'm happy to talk through it in the comments.

Why I Moved Us Off Microservices Back to a Monolith (And What the Original Decision Got Wrong)

Valipireddy Kowshik — Tue, 15 Sep 2026 08:47:09 +0000

We split a perfectly working app into eight microservices because it was 2023 and that's what "scalable" teams did. Eighteen months later, I was the one writing the RFC to put most of it back together.

Nobody likes admitting that. It feels like undoing someone else's work, or worse, undoing your own. But I'd rather write an honest postmortem than keep pretending the architecture was fine while three engineers spent half their week just keeping services talking to each other.

Why we split it up in the first place

The reasoning at the time sounded solid on paper. Independent deployability. Teams owning their own services. The ability to scale the busy parts of the app without scaling the whole thing. Every blog post about companies at our stage said some version of the same thing, and it was easy to believe we were behind if we hadn't already made the jump.

What none of those blog posts mentioned, or maybe just assumed was obvious, was the size of team those benefits actually require. We had twelve engineers. Splitting the app into eight services meant most services had one, maybe one and a half people who actually understood them end to end. The "independent teams owning independent services" model doesn't work when the teams don't exist yet. We built the architecture for a company we hoped to become, not the one we were.

What actually broke

The failures weren't dramatic. There was no single outage that made everyone say "okay, this was a mistake." It was slower and more corrosive than that.

Debugging turned into archaeology. A bug that used to mean stepping through one codebase now meant tracing a request across four services, three of which had inconsistent logging, to find out where the data actually went wrong. What used to take twenty minutes started taking half a day, and that was on a good day.

Local development got painful. Spinning up the full stack locally meant running eight services, each with its own environment variables, its own database, its own quirks about what port it wanted. New engineers took two weeks just to get a working local setup instead of two hours.

Deployments needed careful choreography. Services depended on each other in ways that weren't always obvious until deploy day. We'd ship a change to one service, break another, and spend the next hour figuring out which one actually needed to go out first. The "independent deployability" we split up for became its own coordination problem.

We were paying an infrastructure tax with no matching benefit. Eight services meant eight sets of CI pipelines, eight sets of monitoring dashboards, eight things that could each fail independently at 2am. We were paying operational complexity for scale problems we didn't have yet. Our actual traffic could have run comfortably on a single well built service.

Nobody could hold the whole system in their head. This one mattered more than any single technical issue. When something went wrong, there was no longer one person who could reason about the entire request path. Every incident started with a scramble to figure out who even understood the piece that broke.

The decision to go back

I didn't propose the monolith because microservices are bad. They're not. They solve real problems for teams at a certain scale with certain organizational boundaries already in place. I proposed it because we'd adopted the pattern before we had the problem it solves, and we were paying the cost of that mismatch every single week.

The RFC was blunt about it. We are not Amazon. We do not have twelve teams that each own a service end to end. We have twelve engineers who spend more time on service boundaries than on the product. Here is what a single, well organized codebase with clear internal module boundaries buys us back.

It wasn't a popular conversation at first. Some of that split had taken real effort, and nobody wants to hear that effort didn't pay off. But once we framed it as "what does our actual team, at our actual size, need right now" instead of "what did we lose face on," it got easier to agree on.

What I'd tell myself eighteen months earlier

Architecture decisions should follow the shape of your team and your actual traffic, not the shape of the team and traffic you're hoping to have in two years. If you can't clearly name which team owns which service, and mean it, you probably don't need separate services yet. You can build a monolith with clean internal boundaries, module by module, and split it later when a specific piece genuinely needs to scale or deploy independently. That split will be easier to do later, with real evidence behind it, than it is to undo now.

We didn't fail because microservices are wrong for us forever. We failed because we borrowed an architecture built for a different sized team and assumed the benefits would show up automatically. They don't. They show up when the organizational structure that justifies them already exists.

If your team is mid split right now and it's starting to feel heavier than it should, that feeling is worth listening to. It was for us, even if it took longer than I'd like to admit before I said it out loud.

What a Bad Project Taught Me (That No Great Project Ever Could)

Valipireddy Kowshik — Tue, 15 Sep 2026 08:33:54 +0000

Nobody writes a retrospective about the sprint that went smoothly. We move on, ship the next feature, and forget the details. But the project that hurt? That one stays with you line by line. It becomes the mental checklist you run every time someone says "let's just build it."

I recently came off a project like that. It wasn't a technical disaster the code shipped, the app worked, the demo looked fine. What broke it was process: no real user research, no design principles anyone could point to, and a growing habit of treating AI-generated "research" as a substitute for actually talking to users. Here's what I took away from it.

The pattern I kept seeing

In the AI era, it's tempting for product managers to skip the slow, expensive parts of building a product. Why run five user interviews when you can ask an LLM to "research user needs for a fintech onboarding flow" and get a confident, well-formatted answer in ten seconds?

The problem isn't that AI research is useless it's a decent starting point for hypotheses. The problem is when it quietly replaces the step where you validate those hypotheses against real humans. On this project, feature decisions increasingly traced back to "the research says users want X," where "the research" meant a chat transcript, not a single user conversation. Nobody could tell me who "users" actually referred to.

That's not research. That's a plausible-sounding guess wearing research's clothes.

What actually went wrong

A few concrete anti-patterns emerged, and I think they're worth naming plainly:

AI output was treated as ground truth, not a hypothesis. Nobody followed up an AI-generated persona or use case with an actual interview, survey, or usability test. It went straight into the backlog as a requirement.
UI decisions had no design principles behind them. There was no consistent spacing system, no defined interaction patterns, no accessibility baseline. Every screen was designed in isolation, so the app felt like five different products stitched together.
Feedback loops were one-directional. Features shipped, nobody measured whether they solved the problem they claimed to solve, and the team moved on to the next AI-suggested feature.
Speed was the only metric that mattered. "We shipped it fast" became the substitute for "we shipped the right thing." Velocity was celebrated; outcomes were rarely discussed.
Engineers were kept out of the "why." We were handed tickets, not problems. When you don't understand the user problem you're solving, you can't push back when the solution doesn't fit it you just build what's written. None of this was one dramatic failure. It was a hundred small shortcuts that compounded until the product felt directionless, even though everyone individually was working hard.

Why bad projects teach you more than good ones

On a healthy project, good decisions look invisible. Nobody points at the moment someone insisted on a usability test before committing to a flow it just happens, and the project is better for it, quietly, forever.

On a bad project, every missing safeguard becomes visible because you feel its absence. You don't need someone to explain why user research matters when you watch a feature ship, confuse every real user who touches it, and get silently reworked three sprints later. The lesson isn't taught to you it's demonstrated, at cost, in real time.

That's the uncomfortable value of a bad project: it turns abstract principles ("talk to your users," "have a design system," "measure outcomes, not output") into concrete, felt memories. You stop treating them as things senior engineers say in blog posts and start treating them as things you personally never want to relearn.

What I'm doing differently now

AI research is a first draft, not a final answer. If a PM shares an AI-generated set of user needs, my question is always: "Who did we validate this with?" If the answer is nobody, that's the next step, not a nice-to-have.
I ask for the "why" before I estimate the "how." A ticket without a user problem attached doesn't get pointed. This isn't about gatekeeping it's about being able to catch a bad idea before I've built it.
Design principles get written down, even informally. A shared doc of spacing, states, and interaction patterns saves so much rework it's not optional anymore.
I treat shipped ≠ solved. After launch, I want to know if the feature actually moved the metric it was meant to move. If nobody's tracking it, I flag that as a gap, not a footnote.
I push back on speed as the only success metric. Fast and wrong isn't a win it's the same failure with better PR. ### The takeaway

Good projects give you confidence. Bad projects give you conviction. Working on something that skipped user research and leaned on AI-generated assumptions instead didn't just teach me what not to do it taught me how expensive it is to skip the boring, human parts of product development, even when the tools make skipping them feel effortless.

AI can accelerate research. It can't replace the moment where a real user tells you your assumption was wrong. If your team is using AI to speed up thinking, make sure you're still checking that thinking against reality because the app I worked on didn't have a technology problem. It had a "we stopped listening to users" problem, and no model can fix that for you.

Have you worked on a project where AI-generated research quietly replaced real user research? I'd love to hear how your team caught it or didn't.

Why I Ditched "Just Let the LLM Handle It" for a State Machine (And Slept Better at Night)

Valipireddy Kowshik — Tue, 15 Sep 2026 02:56:27 +0000

When I started building my AI technical interviewer, I did what most people do: I threw a big system prompt at the LLM and told it to "act like an interviewer, ask coding questions, give hints when the candidate is stuck, and score them at the end."

It worked... about 80% of the time.

The other 20% is what this post is about.

The problem with trusting an LLM to run your whole flow

Here's what kept happening. Mid-interview, the model would:

Randomly decide the interview was "done" after one question
Give away the answer while trying to give a "gentle hint"
Forget it already asked a question and ask it again
Jump straight to scoring before the candidate even submitted code

None of this was a prompting skill issue. I rewrote that system prompt probably fifteen times. The real issue is structural: an LLM generating the next thing to say has no actual memory of "what phase are we in," unless you spoon-feed it that context perfectly, every single turn, forever. And even then, it can just... decide to do something else. It's a language model, not a state tracker. Treating it like one is where things fall apart.

For a casual chatbot, that's fine — mild chaos is charming. For a product where someone's actual hiring decision depends on the interview going through every stage correctly, "mild chaos" is a support ticket and an angry candidate.

What I did instead

I pulled the structure of the interview out of the LLM entirely and put it into a plain old finite state machine.

Something like:

SETUP → GREETING → QUESTION_ASKED → CANDIDATE_CODING →
HINT_CHECK → EVALUATING → SCORING → DONE

The state machine — not the model — decides what phase we're in and what's allowed to happen next. The LLM only gets called inside a state, to do the one thing that state needs: generate a question, generate a hint, or generate a scorecard. It never gets to decide "we're done now" or "let's skip to scoring." That's not its job anymore.

Practically, this meant:

The LLM can't hallucinate a phase transition because it doesn't control phase transitions
Hints only trigger off a real signal — 35+ seconds of no keystroke activity — not the model deciding "the candidate seems stuck"
Scoring only fires after code is actually submitted and executed in the sandbox, not whenever the model feels like wrapping up

The LLM still does all the hard, "actually intelligent" work — writing a good question, phrasing a helpful hint, writing a fair evaluation. It's just not allowed to drive the car anymore. It's a really good passenger with really good opinions.

A simplified look at the transition logic

class InterviewState(Enum):
    GREETING = "greeting"
    QUESTION_ASKED = "question_asked"
    CANDIDATE_CODING = "candidate_coding"
    HINT_CHECK = "hint_check"
    EVALUATING = "evaluating"
    SCORING = "scoring"
    DONE = "done"

def transition(current_state, event):
    # The FSM owns "what happens next" —
    # the LLM only fills in content within a state
    if current_state == InterviewState.CANDIDATE_CODING:
        if event == "idle_35s":
            return InterviewState.HINT_CHECK
        if event == "code_submitted":
            return InterviewState.EVALUATING
    # ...deterministic, testable, no hallucinated jumps

Compare that to letting the model implicitly track state through conversation history alone — there's no guarantee, no test coverage, and no way to catch a bad transition before it reaches the user.

The part that surprised me

I expected this to make the product feel more robotic. It did the opposite.

Because the structure is now guaranteed, I could actually let the LLM be more creative and natural within each state, without worrying about it going off the rails. Constraining the skeleton let me loosen up the muscle. Counterintuitive, but it checks out — a lot of "unpredictable AI" complaints aren't really about the model being too creative, they're about the model having too much control over things it was never designed to control.

The takeaway

If you're building something where an LLM is orchestrating a multi-step process — not just answering one-off questions — ask yourself: does the model actually need to decide what happens next, or does it just need to generate good content within a step someone else decides?

Most of the time, in my experience, it's the second one. And the moment I stopped asking the LLM to be both the actor and the director, my "why did the interview just end after one question" bugs basically disappeared overnight.

I write about the messier, more practical side of building AI products — the stuff that doesn't make it into the demo. If you're curious, I built this exact system as a live product: AI Technical Interviewer. Happy to talk through the architecture more in the comments.