Built Scraper Agent (using Firecrawl) Day 2: built a scraper agent using Firecrawl MCP server to pull the latest 100 job listings from Naukri.com. The agent handles the scraping end-to-end and pushes the results straight into a structured sheet, ready to filter and act on.

Everyone's talking about loop engineering. Here's what it actually is. It's not the ReAct loop your agent already runs (reason, act, observe, repeat). That ships built in. You don't engineer that. Loop engineering is everything wrapped around the agent: what kicks it off, what feeds it work, what checks the output, what decides to run again or stop. The agent owns the inner loop. You design the outer one. Core idea: the prompt is no longer the unit of work, the loop is. Give it a goal and a success condition, and it keeps taking turns until that condition holds. Codex and Claude Code already ship this natively as /goal. It also sidesteps context rot. Instead of one long session piling up dead ends, each iteration starts fresh, reads state, does one unit of work, exits. The catch is tokens. Loops burn them on every retry and re-read, so cap it before trusting it to run overnight. Is anyone here already building with loops instead of turn by turn prompting?

Built Newsletter Automation Day 1: built my first newsletter using Claude Code. Not a tutorial. Not a template. Just me figuring it out as I went. Along the way I learned how Claude Code actually works under the hood, what it takes to build a newsletter from scratch, and where my current process still has gaps. It wasn't perfect. It wasn't fast. But it worked, and I learned more in this one session than I would have from a week of just reading docs. More hands-on builds coming. Day 2 next.

Every procurement or contracting team has the same problem: someone has to sit down and read a 60-page tender or contract just to find one deadline, one clause, one number. That takes hours. And once it's read, the knowledge just disappears — filed away in a PDF nobody wants to reopen. Ask the same question three weeks later, and someone's re-reading the whole thing again. I built a workflow that fixes this. Upload the document, and it automatically: → Pulls out key details — deadlines, insurance requirements, compliance terms — into a tracker → Becomes something you can message on WhatsApp or Telegram → Ask it anything — "what's the insurance requirement?" — and it replies with the answer, cited to the exact section Here's the part that almost didn't work: early on, the system would confidently say "this information isn't in the document" — even when it clearly was. The document was being processed in a way that split important details apart, so the system genuinely couldn't find the full answer. Fixing that one thing took accuracy from unreliable to 100% correct on every question I tested. Now it's 30 seconds instead of 3 hours. No app, no dashboard. Just a message. Happy to walk through how it's built if anyone wants to see it — drop a comment.

I just shipped my first n8n community node. I built it because workflows that ran perfectly on 10 items kept throwing API rate limit errors on 500. The only workaround most people know is the Wait node where you literally guess a delay and hope it's enough. So I built the Rate Limiter node to fix this properly. Here's how it works: 1️⃣ Check your API docs for the rate limit (Gemini 2.5 Flash = 10 req/min, Airtable = 5 req/sec) 2️⃣ Drop the Rate Limiter node before your API call or HTTP node 3️⃣ Set the exact number, requests per second or per minute 4️⃣ Run your workflow. The node automatically processes each item with the right delay in between, ensuring every single item goes through without hitting the API limit. No more guessing the delay time. Now live on n8n Cloud ✅ To install: Search "Rate Limiter" directly in your n8n canvas and drop it in. For more details, Here is the npm link 👇 https://www.npmjs.com/package/@divyanshu00