<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://www.yogendra-jaiswal.xyz/</id><title>Yogendra Jaiswal</title><subtitle>Yogendra Jaiswal is a software engineer at Incubyte and ex-Amazon SDE. He builds AI workflow platforms and writes about backend reliability, SQL, and AI coding agents.</subtitle> <updated>2026-10-02T22:20:37+05:30</updated> <author> <name>Yogendra Jaiswal</name> <uri>https://www.yogendra-jaiswal.xyz/</uri> </author><link rel="self" type="application/atom+xml" href="https://www.yogendra-jaiswal.xyz/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://www.yogendra-jaiswal.xyz/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Yogendra Jaiswal </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>AI Coding Agent Verification: Batch E2E Screenshots, Not Browsers</title><link href="https://www.yogendra-jaiswal.xyz/posts/the-verification-loop-that-actually-scales/" rel="alternate" type="text/html" title="AI Coding Agent Verification: Batch E2E Screenshots, Not Browsers" /><published>2026-03-30T00:00:00+05:30</published> <updated>2026-10-02T13:22:18+05:30</updated> <id>https://www.yogendra-jaiswal.xyz/posts/the-verification-loop-that-actually-scales/</id> <content src="https://www.yogendra-jaiswal.xyz/posts/the-verification-loop-that-actually-scales/" /> <author> <name>Yogendra Jaiswal</name> </author> <category term="ai" /> <category term="developer-tools" /> <summary> TL;DR: When an agent makes dozens of frontend edits per session, verification becomes the bottleneck, not code generation. I stopped having the model drive a browser after each edit. Instead, the full Playwright suite writes a screenshot per step, CI diffs them against committed baselines with zero tolerance, and a human scans the images before merge. Pixel diffs catch rendering regressions.... </summary> </entry> <entry><title>Building an Agent Orchestrator for OpenCode and Claude Code</title><link href="https://www.yogendra-jaiswal.xyz/posts/Building-an-Agent-Orchestrator-for-OpenCode/" rel="alternate" type="text/html" title="Building an Agent Orchestrator for OpenCode and Claude Code" /><published>2026-03-26T00:00:00+05:30</published> <updated>2026-10-02T13:22:18+05:30</updated> <id>https://www.yogendra-jaiswal.xyz/posts/Building-an-Agent-Orchestrator-for-OpenCode/</id> <content src="https://www.yogendra-jaiswal.xyz/posts/Building-an-Agent-Orchestrator-for-OpenCode/" /> <author> <name>Yogendra Jaiswal</name> </author> <category term="ai" /> <category term="developer-tools" /> <summary> This post walks through claude-opencode-subagents, an OpenCode plugin I built that lets one manager agent delegate work to five persistent Claude Code sessions. You will see how roles map to tool permissions, how read-only exploration is enforced in the SDK callback, how state survives restarts, and which parts of the first design I removed and why. The source is private. The numbers below com... </summary> </entry> <entry><title>Redis Caching Patterns: Stampedes, Invalidation, and Hot Keys</title><link href="https://www.yogendra-jaiswal.xyz/posts/Redis-Caching-Patterns-I-Actually-Use/" rel="alternate" type="text/html" title="Redis Caching Patterns: Stampedes, Invalidation, and Hot Keys" /><published>2026-03-21T00:00:00+05:30</published> <updated>2026-10-02T21:27:44+05:30</updated> <id>https://www.yogendra-jaiswal.xyz/posts/Redis-Caching-Patterns-I-Actually-Use/</id> <content src="https://www.yogendra-jaiswal.xyz/posts/Redis-Caching-Patterns-I-Actually-Use/" /> <author> <name>Yogendra Jaiswal</name> </author> <category term="backend" /> <category term="caching" /> <summary> TL;DR: Default to cache-aside with a TTL, and invalidate by deleting the key after the database commit, never before. Protect hot keys from stampedes by letting one caller rebuild while the rest serve the stale value, and add jitter so keys do not expire together. Most caching incidents come from ordering races, synchronized expiry, a single overloaded key, or an eviction policy nobody set. 1.... </summary> </entry> <entry><title>Idempotency Keys: Designing APIs That Survive Retries</title><link href="https://www.yogendra-jaiswal.xyz/posts/Designing-Idempotent-APIs-for-Reliable-Backends/" rel="alternate" type="text/html" title="Idempotency Keys: Designing APIs That Survive Retries" /><published>2026-03-21T00:00:00+05:30</published> <updated>2026-10-02T21:27:44+05:30</updated> <id>https://www.yogendra-jaiswal.xyz/posts/Designing-Idempotent-APIs-for-Reliable-Backends/</id> <content src="https://www.yogendra-jaiswal.xyz/posts/Designing-Idempotent-APIs-for-Reliable-Backends/" /> <author> <name>Yogendra Jaiswal</name> </author> <category term="backend" /> <category term="system-design" /> <summary> TL;DR: Make the client send an Idempotency-Key, and let a unique constraint on (client_id, key) decide which request runs. Store a hash of the request and the final response, then replay that response on retries, return 409 while the first request is still running, and return 422 if the same key arrives with a different payload. Commit the side effect and the stored response in one transaction,... </summary> </entry> <entry><title>MySQL vs PostgreSQL Isolation Levels: What Actually Differs</title><link href="https://www.yogendra-jaiswal.xyz/posts/Database-Isolation-Levels-MySQL-vs-PgSQL/" rel="alternate" type="text/html" title="MySQL vs PostgreSQL Isolation Levels: What Actually Differs" /><published>2024-05-26T00:00:00+05:30</published> <updated>2026-10-02T21:27:44+05:30</updated> <id>https://www.yogendra-jaiswal.xyz/posts/Database-Isolation-Levels-MySQL-vs-PgSQL/</id> <content src="https://www.yogendra-jaiswal.xyz/posts/Database-Isolation-Levels-MySQL-vs-PgSQL/" /> <author> <name>Yogendra Jaiswal</name> </author> <category term="databases" /> <category term="sql" /> <summary> TL;DR: MySQL (InnoDB) defaults to Repeatable Read, PostgreSQL to Read Committed, but the names hide the real difference. At Repeatable Read, InnoDB lets a concurrent write overwrite another committed write without an error, while PostgreSQL aborts the second transaction with a serialization failure. Neither database’s Repeatable Read prevents write skew, so invariants that span rows need Serial... </summary> </entry> </feed>
