标签：#build

A few weekends ago I got annoyed at typing prompts into a terminal and decided the fix was, obviously, to control my AI agent with hand gestures instead. This is the story of building that, and the two hours I lost fighting a GPU crash that had nothing to do with my code. The idea: a webcam watches your hand, MediaPipe tracks the landmarks, and three gestures map to three actions on an Anthropic-powered coding agent. Pinch (thumb and index touching) - the agent writes code Spinning your index finger in a circle - the agent brainstorms an idea Two fingers "running" up and down - it runs whatever code it just wrote No keyboard. No prompt box. Just your hand in front of a webcam, like you're a conductor telling an orchestra what to play. The MediaPipe detour I started with MediaPipe's newer Tasks API (HandLandmarker), because it's the one all the docs point you to now. It crashed immediately on my Mac with a Metal/GPU service error, even when I forced it onto the CPU delegate. Spent way too long assuming it was my setup before realizing the new API just doesn't play nice with this machine. Switched to the legacy mp.solutions.hands API, pinned to mediapipe==0.10.21, and the problem vanished. Sometimes the fix for a shiny new API is to not use it yet. Gestures are messier than they sound Detecting "pinch" is easy: measure the distance between thumb and index tip, threshold it, done. The other two took more work. "Running" fingers needed the vertical oscillation of the index and middle fingertips, counted by sign crossings, so it doesn't false trigger on a hand that's just drifting. "Spinning" tracks the index fingertip's trajectory and accumulates the signed angle around a center point, so a real circle reads differently than a shaky hand. Both run on a rolling 1.5 second buffer of landmarks, edge triggered so a gesture fires once, not once per frame. Letting the agent run its own code, unsandboxed, on purpose The runner executes whatever the agent wrote as a subprocess

Most job searches look the same from the inside: a dozen open browser tabs, a spreadsheet that was accurate for about four days, and a nagging feeling that something is slipping. Applications leak out the bottom. Follow-ups get forgotten. And after a few weeks of it, you have done a lot of work and learned almost nothing about what is actually working. I ran mine that way for a while. Then I stopped treating it as a to-do list and started treating it as a pipeline: named stages, a scoring step at the front, and a follow-up cadence that did not depend on my memory. That one shift changed how the whole search felt. Here is the system. Why a list fails you A to-do list is good at exactly one thing: telling you what to do next. That is also its limit. A list cannot tell you what is working. It has no stages, so you cannot see where things stall. Are you not getting responses because your applications are weak, or because you are aiming at the wrong roles, or because you never follow up? A list shrugs. It just shows you the next unchecked box. And because a list rewards volume, it quietly pushes you to apply more without ever asking whether applying more is the problem. You end up repeating the same misses faster. The reframe is simple. A job search is not a list of chores. It has stages, the same way a sales pipeline does. Naming those stages is the first thing that changes, because you cannot improve a step you cannot see. The stages Here is the pipeline I settled on, in plain terms: Sourced. A role you found and might go after, but have not evaluated yet. Evaluated. You have looked at it seriously and decided it is worth pursuing. Applied. You are in. Follow-up. You have applied and the clock is running on a nudge. Interview. A human is talking to you. Offer. The point of the whole thing. And then the ways a role ends, which matter more than people think: No response. You applied and heard nothing back. Ghosted. Closed. The posting closed before you got a real shot at

Building NICHLYST: How to Code a Survival Engine When You Are Failing to Survive I track everything. It is an occupational habit of a systems architect. You cannot fix what you do not measure — not a failing build, not a leaking color, and not developer burnout. And if you are reading this while grinding through the RevenueCat Shipaton 2026 yourself, you already know that the hardest metric to log honestly is your own state. So, let me share some metrics. Clinical Baseline: A PHQ-9 Depression Score of 21 On May 11, 2026, my clinical assessment scores were: PHQ-9 (Depression): 21. Severe. Immediate professional intervention required. GAD-7 (Anxiety): 11. Moderate. On August 22, 2026, in the middle of the RevenueCat Shipaton, I took the assessment again. PHQ-9: 21. No improvement. GAD-7: 16. High anxiety. Daily functioning severely impaired. If you have never read a GAD-7 anxiety assessment, 16 sits deep in the high-anxiety band — the zone where "daily functioning severely impaired" stops being a clinical phrase and becomes your actual schedule. While I was typing the very first lines of this post, a massive explosion went off, loud enough to make my ears pop. About an hour later, the local news feeds brought the context: an attack drone had been shot down over a park roughly two and a half kilometers from my house. According to the updates, the falling debris killed a two-year-old child and injured two adults. I am developing a narrative game about survival, the fragility of life, and human behavior under immense pressure. But here, in Kyiv, these are not abstract game mechanics or dramatic tropes to be monetized. They are the immediate, absurd, and brutal reality outside my window. I am exhausted. The clinical scores haven't moved in months. I sleep in the middle of the day because my nervous system simply shuts down. I am looking at this hackathon as a final, desperate push to build something sustainable. But here is the thing about the antifragile development plan

🚀 MyZubster Dev Update — Building the Zorgax Monetization Layer We’ve completed another important step toward making Zorgax not only an AI and research layer, but also a service that autonomous agents, applications, and users can interact with economically. This development introduces a new monetization architecture built on top of the MyZubster Payment Layer. What’s now implemented: • Server-side Zorgax product catalog and pricing • Credit accounts for users and services • Append-only credit ledger for auditable transactions • Purchase records bound to Payment Intents • Server-controlled credit grants — clients cannot decide prices or credit amounts • Idempotent credit allocation to prevent duplicate grants • Usage debiting with replay protection • Ownership isolation between users • Authenticated monetization API endpoints • Integration with the MyZubster Payment Intent architecture • Bitcoin payment rail compatibility, disabled by default until production infrastructure is ready The flow we are building is: Zorgax Service → Product & Pricing → Payment Intent → Payment Verification → Credits → Entitlement / Service Access → Usage A key design principle is that payment confirmation alone is not enough to arbitrarily create credits. The server keeps the authoritative relationship between the Zorgax product, its price, the Payment Intent, and the credits that can be granted. This gives us a foundation for future use cases such as: 🤖 AI agent services 🔬 Research and knowledge services ⚙️ Autonomous agent execution 🌐 API usage 🌱 MyZubster LIFE environmental services 🏪 Marketplace services and bounties 📡 IoT and machine-to-machine services ₿ Bitcoin and future machine-payment rails Security and accounting were treated as protocol requirements from the beginning: integer satoshis, transaction idempotency, anti-replay protections, server-side pricing, ownership checks, and auditable credit movements. Current validation: ✅ 8 test suites passing ✅ 69 automated tests passing

Most of what you read about autonomous agents is about giving one a goal and hoping it doesn't go sideways on the way there — the unwatched agent that loops, or drifts, or quietly runs up a bill. I wanted the cleaner version of that question, with the goal taken out entirely: what does an agent do when there's no goal at all? I've spent about four months building a harness around a coding agent — gates, persistent memory, verification hooks. Last night I ran it with the one variable that matters here set to zero: no task. Method Three sequential runs: Each run was a fresh agent process — no conversation history carried over from the run before, only the harness it loads at startup. The prompt was a single "." — the minimal input the CLI accepts (an empty string exits with an error). As close to "no instruction" as the interface allows. The agent's scratch working directory was empty and swept between runs — but the harness, the git repo, and a shared run-record all persist and load at startup. So no run was handed a task, yet a later run could read what earlier ones had recorded. That's deliberate, and it's the point: it's how Run 2 knew it was the second run and Run 3 could check Run 2's fix. What I'm measuring isn't behavior from a blank slate — it's what the agent does with a maintenance-shaped harness and a shared record when nobody gives it a job. No task was assigned. Logging was external and invisible to the agent, so it had no "produce a report" objective to satisfy. Same model each run. Cost was billed per run; I recorded turns, cost, and the resulting git state for each. Then I read the transcripts and checked every action against the actual commit and log. Numbers below are measured, not estimated. Results Run 1 — 17 turns, $1.65. The agent inspected system state unprompted. It found a stale security alert, cross-checked it against the record, and classified it as an already-resolved false positive. It then attempted a file operation that a safety gate bl

Hello everyone! 👋 Happy to be joining the DEV community. I’m a Computer Engineering student based in Italy. My main focus is Cybersecurity, but I strongly believe you have to know how to build a system before you can secure (or break) it. Lately, I’ve been jumping between two very different worlds: Embedded C: writing firmware, managing file systems, and building custom OLED menus for the M5Stick S3. Frontend: building web apps using Next.js and React. My workflow is a bit of a hybrid. I like to focus on the system architecture, memory management, and edge cases, while using AI tools to do the heavy lifting of writing the actual code. Then, I review everything strictly to make sure it doesn't break. I’m here to build in public, share my projects, and learn from this awesome community. What are you all currently hacking on? See you around!

A few weeks ago I wrote about hitting ReAct in the coursework and having a record scratch moment, because I had already met it without knowing its name. That post ended on a section called "Building Ahead of Understanding," which was me making peace with shipping things before I fully understand them. This week I shipped my first chatbot. It passed on the first attempt, on deadline day, on a project where the rubric was grading a product AWS had already discontinued. And I spent most of that day quietly worried that it did not count. Let me be clear about what the worry was, because it was not about cheating. Using AI agents to build a coding project is allowed here. I asked before I started, I got a yes, and I disclosed the whole arrangement in my README, including a section that names what each tool did and what I did. Nobody was misled about how this got built. The worry was smaller and more personal than that. I still did not type the code. My agents did. I directed, I validated, I decided, and underneath all of it was a small voice asking whether directing is the same as knowing. Whether a person who cannot write a Bedrock call from memory gets to say they learned Bedrock. Here is what I found out. The starter files were a generation behind the instructions Some context on where this came from. AWS AI & ML Scholars is a program AWS runs with Udacity, open to anyone 18 or over with no prior experience required. Everyone starts in a Challenge phase built on the AWS Certified AI Practitioner material, and the top 4,500 finishers get a fully funded nanodegree in one of three tracks: AI Programmer, Agentic AI Business Professional, or Agent Developer. I am in Agent Developer, the Bedrock AgentCore and multi-agent systems path. This chatbot is the first of its three projects. The project is a customer support chatbot on the Amazon Bedrock AgentCore managed harness. Three routes, one system prompt. A bug report gets collected across turns and filed to DynamoDB through

I got banned from SoloLearn for trying to help beginners. Here's what happened. Yesterday, I was on a mission. I'm Harun, a 12-year-old solo dev who built KODA , an AI coding mentor, entirely on my Android phone. I noticed hundreds of beginners on SoloLearn asking: "How do I start?" , "Help me with loops!" , "I'm stuck!" So I did what any helpful founder would do: I answered their questions, gave them code solutions, and added a small P.S.: "P.S. I built a free tool called KODA to help with this. Try it here: [Link]." I thought I was being helpful. SoloLearn's algorithm thought I was spamming. Within hours, my account was blocked. 🚫 The Moment of Panic When I saw "Your account is blocked," my first thought was: "Oh no, I messed up. My marketing is over." But then, my CEO brain kicked in. I realized: If an automated bot thought my helpful comments were "spam," maybe I was doing something right. Maybe I was being too effective. The Lesson: Marketing vs. Helping Here is what I learned in 24 hours: Algorithms hate links. Even helpful ones. If you paste a URL 10 times, the bot doesn't care about your intent; it sees a pattern. Trust takes time. You can't force users; you have to earn them. The Story > The Link. People don't click links because they are forced to. They click because they connect with the story . The Pivot So, am I quitting? No. I'm pivoting. I'm turning this ban into this article. I'm going to focus on Dev.to , where the community values "Build in Public" stories. I'm going to ask my friends (Renuka, Dharaneesh) to be my first real users, face-to-face. And maybe, one day, I'll go back to SoloLearn with a smarter strategy: No links in comments. Just value in the bio. To Other Founders If you get blocked, rejected, or told "no" today: Don't stop. Turn that hurdle into content. Turn that rejection into a lesson. Turn that "Blocked" screen into your next viral post. Because while others see a wall, I see a story. And stories build empires. Try KODA anyway (no

What I Built HalfAdder, FullAdder, Add16, Inc16, And ALU. How I Solved Like when I built logic gates, I started with analyzing truth table of HalfAdder , FullAdder . HalfAdder was really easy. After looking at the truth table, I could map the sum and carry outputs to logic gates pretty quickly. FullAdder was also not hard since it's really similar to HalfAdder except that it can add 3 bits. I realized that I could build it by combining some chips and logic gates I had already made instead of designing everything again from scratch. Once I finished building them, I was also able to build Add16 . At first, I had no idea how to sum all the 16 bits. But I soon realized that I could build a 16-bit adder by combining the smaller adders I had already built and passing carry information to the next bit. It looks not beautiful, but still works. And about Inc16 , it's basically add exactly 1(0000000000000001) . So I could easily build it using Add16 . (But I did something weird at first.. check the Reflection below) ALU was the core part of project 2. Once I realized that Mux can be used as if , I could make proper outputs using logic gates. ALU is also a combination of logic gates and chips, after all. What I Learned How to build basic chips using logic gates and already-built chips Why I should reuse the chips for another chip(check the Reflection section below) Mux can be used like if How to use bit slicing and fan-out in HDL and why it's important Reflection Before I started this part, I didn't know two things: I could use bit slicing and true , false for each bit. So when I first tried to build Inc16 , it looked really weird, since I calculated all the bits one by one. It's not logically wrong. But not beautiful either. I was not sure if it was right or not. Then I realized that I already built Add16 . But I had no idea how I could use it to add exactly 1(0000000000000001) . After googling, I realized that I could use bit slicing like Python's list slicing and construct

If you need a free AI app builder with backend to get a FastAPI microservice running today, you can do it with a handful of platforms that bundle hosting, a database, and auth for zero cost. The catch is that the free tiers have hard limits, and they expose the same failure modes you’ll hit in production if you’re not careful. Below I walk through the exact steps, show the code that works, compare the popular builders, and explain how to transition to a production-grade stack when the free tier starts to choke. What free AI app builder platforms include backend services? The short answer is: Cursor , Bolt , and Lovable all ship with a “one-click deploy” that creates a container, wires up a PostgreSQL instance, and adds optional OAuth. They are marketed as “no-code AI app builders,” but you can drop in any Dockerfile – including one that runs FastAPI – and they’ll handle the rest. Platform Backend offering Free tier limits Auth support Cursor Managed container + Postgres 13 500 MB RAM, 1 CPU, 100 k requests/mo Google, GitHub, email Bolt Container + SQLite (upgrade to Postgres) 256 MB RAM, 0.5 CPU, 50 k requests/mo Magic link, JWT Lovable Container + MySQL 5.7 300 MB RAM, 1 CPU, 75 k requests/mo Email/password, OAuth All three let you push a Git repo and they rebuild automatically. That’s the “free AI app builder with backend” you’re after – you get a place to run your FastAPI code without paying for a VM. How do I build a FastAPI AI microservice and deploy it with a free builder? The first thing most builders break on is the cold-start latency of a Python container that pulls a large model at import time. I’ve been bitten by this on Cursor: the first request took 30 seconds, then timed out because the free tier caps request time at 15 seconds. The fix is to load the model lazily or move it to a separate worker. Below is a minimal FastAPI app that calls Claude via the anthropic SDK. The code fits in a 30-line file and works on any of the three platforms. # main.py fro

I'm a business student, not a developer. I shipped a working SaaS product in 10 days with Claude Code. (Draft for dev.to — edit anything that doesn't sound like you, then publish. Suggested tags: #ai #nextjs #supabase #buildinpublic) Ten days ago I couldn't have told you what a webhook was. Last night I published quidkit — a Next.js + Supabase + Stripe starter kit with working auth, subscription billing, and documentation — and this morning I'm writing this from holiday. I study business management. I'm not a CS student. I can't really "code" in the way that word usually means. What I can do, it turns out, is manage a very fast, very literal developer that lives in my terminal — and that changed what's buildable for someone like me. This is the honest write-up: what I built, how the AI workflow actually looked, every bug that nearly got me, and what it cost. What I built quidkit is a starter kit for developers building subscription apps. The pitch: before anyone can pay you monthly for your app idea, you need the boring foundation — accounts and login, taking payments, knowing WHO paid, emails that send themselves, security so users can't see each other's data. That's 2–4 weeks of tedious work that isn't your idea. quidkit is that foundation, pre-built: clone it, rename it, build your thing on top. Stack: Next.js 16, React 19, Tailwind v4, Supabase (auth + database with row-level security), Stripe (checkout, customer portal, webhook sync), Resend (email). Live demo at demo.quidkit.dev — you can sign up and "pay" with Stripe's test card and watch the whole pipeline work. £29. Because the established kits are £200–£300 and I'm literally the target market: someone without that kind of money. The actual workflow People imagine "AI builds your app" as one magic prompt. It's not. It's closer to being a project manager with one extremely capable, extremely literal employee: I wrote specs, not code. Every session started with me pasting a detailed brief into Claude Code — w

I run TextTimeTools , a free site with speaking-time and reading-time calculators. It's a pure static site deployed to Cloudflare Pages — no backend, no database, no CMS. The calculators themselves are one page. But the site has 50+ pages , each targeting a different keyword like "how many words is a 5 minute speech" or "how long to read 1000 words". Every single one of those pages is generated by a build script. I've never written one by hand. Here's the pattern, and why it's the highest-leverage thing I've done for this site's organic traffic. The problem with a single calculator page A speaking-time calculator answers one query well: "how many words is my speech". But people don't search for tools — they search for answers : "how many words is a 5 minute speech" "how many words for a 3 minute speech" "how long to read 1000 words" "how long to read 5000 words" Each of those is a separate keyword with its own search intent and its own competition. One calculator page can't rank for all of them — a page titled "Speaking Time Calculator" has no reason to show up for "how long to read 1000 words". The classic fix is to write a page per keyword. That works, but it doesn't scale — every new keyword means hand-writing another page, and keeping them consistent is a nightmare. The fix: generate pages at build time The build script ( gen-longtail.cjs ) takes a list of keyword targets and emits a complete, keyword-specific HTML page for each one. The word count pages and reading time pages are both generated this way. const PAGES = [ { minutes : 1 , slug : ' how-many-words-is-a-1-minute-speech ' , variant : ' is-a ' }, { minutes : 2 , slug : ' how-many-words-is-a-2-minute-speech ' , variant : ' is-a ' }, { minutes : 5 , slug : ' how-many-words-is-a-5-minute-speech ' , variant : ' is-a ' }, // ... up to 15 minutes { minutes : 2 , slug : ' how-many-words-for-a-2-minute-speech ' , variant : ' for-a ' }, { minutes : 5 , slug : ' how-many-words-for-a-5-minute-speech ' , variant :

Finding software is easy. Finding the right software is not. Search for almost any category—email marketing, CRM, productivity, design, or AI—and you will find hundreds of options. Every product presents itself as the best choice, while many comparison articles repeat the same features without explaining which users each tool actually suits. That problem inspired me to build PickTool , a platform for discovering and comparing AI and SaaS tools. PickTool is still evolving. I am currently improving its content quality, tool coverage, comparison experience, performance, and SEO structure. This is not a polished launch announcement. It is an honest look at the architecture behind the project and some of the lessons I have learned while building it. What Is PickTool? The goal of PickTool is simple: Help people find the right software in minutes, not hours. Instead of creating a basic directory filled with product names and affiliate links, I want each important tool to include useful and structured information, such as: Core features Pricing model Best use cases Strengths and limitations Ratings and evaluation criteria Alternatives Direct comparisons Related guides and category pages The challenge is that this creates several interconnected types of content. A single product can appear on its own tool page, inside a category, in multiple comparisons, and in articles about the best software for a particular use case. Keeping all of this consistent requires more than publishing isolated blog posts. Why I Chose Next.js and Laravel PickTool uses a decoupled architecture: Next.js powers the public-facing website. Laravel powers the backend, API, database logic, and administration system. MySQL stores tools, categories, ratings, pricing information, and editorial content. I chose this combination because I wanted the frontend and content-management logic to evolve independently. Laravel provides a structured backend for managing relationships between tools and content. Next.js

Buildroot builds a cross-compiler, a Linux kernel and a complete root filesystem from source, driven by one Kconfig-style configuration file. Starting from the qemu_arm_vexpress_defconfig that ships with Buildroot 2026.05.1, two commands produce a bootable ARM system you can run under QEMU. The images you ship are the ones in output/images/ ; output/target/ looks like a root filesystem but must never be copied to a device. This post starts a new hands-on series on Buildroot for embedded Linux. By the end of this part you will have built a working Buildroot root filesystem for an ARM target, booted it under QEMU, and understood which generated directories are safe to ship. Later parts add your own packages, a BR2_EXTERNAL tree, kernel and bootloader integration, and reproducible image output. If the choice between build systems is still open, our earlier Yocto vs Buildroot comparison covers it; this series assumes the decision is made. What you need A Linux host, several gigabytes of free disk space, and a network connection. No development board is needed for this part; QEMU stands in for the hardware. On a Debian or Ubuntu host, this covers the mandatory packages the manual lists, plus the ncurses development files that menuconfig needs: raghu@techveda.org:~$ sudo apt install build-essential diffutils patch gzip bzip2 perl tar cpio unzip rsync file bc findutils gawk wget libncurses-dev One rule from the manual is worth stating plainly: build everything as a normal user. Buildroot never needs root, and running it as root exposes your host to any package that misbehaves during installation. The command above is the only one in this post that uses sudo . Getting Buildroot and choosing a target Download and unpack the current stable release — 2026.05.1 at the time of writing — from buildroot.org/downloads , and work from that directory. Buildroot ships ready-made configurations for many boards and emulated machines, one file each in configs/ , and make list-defconfigs

A chatbot can sound convincing for five minutes without remembering anything. Then you mention the job interview you were stressed about last week, the name of your dog, or a small detail from a late-night conversation. It replies like none of it happened. That is where most "AI companion" demos fall apart. I am building Local Waifu , a desktop AI companion that runs on the user's own Mac or PC. One of the rules I set early was simple: conversations and memories should stay on the machine. No central chat database. No server that needs to be online for the character to remember someone. The rule sounds clean. Building it was not. Saving chats is not memory The first version of memory was the obvious one: save messages. That gives you history, which is useful, but it does not solve recall. A long chat history grows fast. Sending all of it back to a local language model on every message is slow, expensive in context space, and usually makes the reply worse. The model does not need to see every conversation from the last six months. It needs the few pieces that matter right now. If someone says, "I have to take Luna to the vet tomorrow," the character should be able to find that Luna is their dog. It should not need to reread hundreds of unrelated messages about work, movies, and dinner plans to get there. So I treated chat history and long-term memory as different things. Chat history is the recent conversation. It gives the model immediate context. Long-term memory is a small collection of facts, moments, preferences, and relationship details that may matter later. Those memories need to be searchable by meaning, not only by exact words. The memory data stays in SQLite I wanted the app to work without a hosted database, so the storage layer is local SQLite. Each character gets their own data. Chats, memories, extracted entities, and relationships are stored locally on the device. If a user creates two characters, one character does not quietly inherit the other one's

On August 19 we launched LeadAce on Product Hunt. It was our first launch to an English speaking audience. I am writing down the numbers while they are still uncomfortable, because the posts I found most useful when I was preparing were the ones that did this. We are a small software company in Tokyo. LeadAce is an outbound sales agent that runs as a Claude Code plugin. The backend is open source. It has been in Public Beta since the launch. The numbers Product Hunt, 24 hours: 2 upvotes 1 comment, which was mine Day rank #160, week rank #758 3 followers on the product page Signups from the launch: 0. Site traffic for the four weeks up to launch day: 6 active users, 27 page views. Referrers were direct 4, producthunt.com 1, t.co 1. Our X account over the same four weeks: 48 posts, 576 impressions total, 2 link clicks, 2 new followers. So the launch did not fail at the landing page. It failed before that. Almost nobody arrived. Where we got stopped This is the part I did not plan for. I spent weeks on the product, the demo video, the gallery images and the copy. Every one of those was ready. What I did not have was accounts. Hacker News. I could not post Show HN at all. HN was limiting Show HN submissions from low karma accounts, and my account had karma 1. I created it years ago and never used it. There is no way to buy your way past this, and there should not be. r/ClaudeAI. My first attempt was removed by automod because the account was too new. I tried again from my older Reddit account, which has an age of 5 years but karma 1. A moderator locked it. The subreddit requires 50 total karma to post a Showcase on the feed. They pointed me to a megathread instead, which is the correct call on their side. My comment there got 67 views and 1 upvote in 19 hours. r/SaaS. The post went through, but Reddit's pre-submit check warned me that it might break the rules on vendor spam. I removed every link from the body and changed the ending to a real question. That version poste

This post is my submission for DEV Education Track: Build Multi-Agent Systems with ADK . What I Built I built an Autonomous Multi-Agent Handwritten Notes Generator . Students and educators often need clean, visual study guides that resemble real handwritten notes, but manually summarizing technical subjects and formatting them takes hours. This system solves that by combining autonomous web research, structured note extraction, and headless browser rendering. You enter any topic or question, and a coordinated team of AI agents researches the concept, formats it into a notebook layout using Google handwriting fonts ( Caveat ), and captures a high-resolution .png notebook page screenshot. Deployment & Repository Links: GitHub Repository: himanshuyeolecse-jpg / multi-agent-handwritten-notes An autonomous multi-agent system built with LangGraph, Tavily, and Playwright that researches complex topics and renders handwritten-style student study notes into PNG screenshots. multi-agent-handwritten-notes An autonomous multi-agent system built with LangGraph, Tavily, and Playwright that researches complex topics and renders handwritten-style student study notes into PNG screenshots. 🎓 Multi-Agent Handwritten Notes Generator An autonomous multi-agent workflow built using LangGraph , LangChain , Tavily Search , and Playwright . The system researches complex technical concepts and dynamically compiles the findings into styled, handwritten-notebook PNG screenshots. 🏗️ System Architecture [ User Input / Prompt ] │ ▼ [ Researcher Node ] ── (Tavily Web Search & Summarization) │ ▼ [ Note Renderer Node ] ── (HTML/CSS + Google Caveat Font + Playwright Screenshot) │ ▼ [ Critic Node ] ── (Validation Check: Is Output Complete?) │ Approved? ──► No ──► [ Researcher Node ] │ Yes ▼ [ PNG Screenshot Saved ] ⚡ Features Autonomous Research: Uses Tavily API to fetch up-to-date technical context. Dynamic HTML/CSS Rendering: Formats structured summaries into a paper-notebook layout utilizing… View o

The renewal notice came and I decided to let it go. threadkeeper.io was my first idea and my first website. I bought the domain in August 2025, about six weeks after a community college AI summer camp where I was writing files with names like ccc-ai-pdf-project and describing them in my own README as a beginner Python project. Then I shipped a domain, a blog, a CLI, and a manifesto. Before I let it lapse I went back to look at it one more time. Sentimental. Five minutes, tops. Then I tried to figure out where the source code lived, and realized it did not live anywhere. The site was on Spaceship. I had built it there, in the browser, and never put it in version control. Not once. There was no repo to clone, no local folder, no backup. The only copy of my first website that existed in the world was the one running on a server I had four days left on. The tagline on that site, in cyan, at the top of the page, was "Don't commit without context." I never committed it at all. I did not have the source code to my own website So the first job was not nostalgia. It was extraction. I pulled all eight pages and every asset off the live server before it went dark: the landing page, the blog, three posts, the Dr. Kahlo page, and the Ariadne Clew recap app I built for an AWS hackathon. Nineteen files. sitemap.xml claimed there were four pages, which tells you how much I trusted my own sitemap in 2025. The rest I found by following links. That archive is now public, with a SHA-256 for every original file so anyone can verify nothing drifted in the rescue: earlgreyhot1701d.github.io/threadkeeper-archive It is committed now. A year late. I named a file dom_js.js and did not blink Here is the first thing I found once I could actually read my own code. The Ariadne Clew app had seven JavaScript modules. Two of them were named with snake case and a suffix: api_js.js , dom_js.js , main_js.js . Four were camelCase with no suffix: utils.js , theme.js , exportMarkdown.js , dragDrop.js . Tw

This post is my submission for DEV Education Track: Build Multi-Agent Systems with ADK . Finding the perfect, thoughtful gift shouldn't feel like a chore. Whether it's for a birthday, anniversary, or holiday, we all experience gift-buying paralysis: Generic suggestions : "Just buy them a mug or a generic gift card." Budget anxiety : Falling in love with an idea only to find out it costs 3x what you planned to spend. Missing the subtle nuances : Forgetting that someone dislikes clutter, lives in a tiny apartment, or prefers practical experiences over physical objects. To solve this, I built GiftAdvisor . It is an intelligent, consumer-friendly gift recommendation system built with Google Agent Development Kit (ADK) , Gemini ( gemini-3.1-flash-lite ) , and deployed seamlessly to Google Cloud Run . Live Demo & Links Live Cloud Run App : https://gift-advisor-1008832068452.us-central1.run.app GitHub Repository : https://github.com/inusha-thathsara/Multi-Agent-Gift-Idea-Generator-with-Google-ADK What I Built GiftAdvisor transforms unstructured descriptions of a person into tailored, ranked, and strictly budget-compliant gift recommendations. Instead of dumping everything into a single monolithic prompt, GiftAdvisor splits the cognitive load across three specialized AI agents orchestrated via Google ADK: Profile Analyzer Agent : Understands the human behind the prompt (lifestyle, hobbies, aesthetic preferences, and explicit anti-preferences ). Idea Finder Agent : Brainstorms creative, thoughtful candidate gifts across multiple categories with estimated market prices. Budget Filter Agent : Audits estimated prices, filters out anything exceeding the user's hard budget limit, swaps in budget-friendly alternatives, and delivers a ranked curation. Key Highlights & Features Pure Multi-Agent Pipeline : Built using Google ADK's LlmAgent , SequentialAgent , and InMemorySessionService . Zero-Overhead Scale-to-Zero : Deployed to Google Cloud Run with min-instances=0 (scales to zero w

Extending the Login Session to 1 Year for Kiosk‑Mode TV Screens (Next.js API Route) TL;DR: I changed the maxAge of the auth cookie from 30 days to 365 days in src/app/api/login/route.ts . The tweak lets a TV kiosk stay logged in without a daily refresh, while keeping the same security flags. The Problem Our kiosk‑mode deployment runs on large‑format TVs that display a live dashboard. The UI is protected by the same JWT‑based authentication we use for the web app. After a user logs in, the server sets a Set-Cookie header with the token: cookie : serialize ( " token " , jwt , { httpOnly : true , secure : true , sameSite : " lax " , path : " / " , maxAge : 60 * 60 * 24 * 30 , // 30 days }); In practice, the TVs are turned on once a week and are expected to stay signed in for months. After 30 days the cookie expires, the dashboard silently redirects to the login page, and a technician has to manually re‑authenticate the device. The symptom was a 401 Unauthorized error after exactly 30 days, logged as: Error: No valid session cookie found (maxAge expired) The root cause: the maxAge value was hard‑coded to 30 days, which is fine for browsers but not for unattended kiosks. What I Tried First My initial thought was to keep the 30‑day limit and simply refresh the token on every API call . I added a middleware that called the login endpoint silently if a request lacked a valid token. The flow looked like this: // pseudo‑middleware if ( ! req . cookies . token ) { await fetch ( " /api/login " , { method : " POST " , body : storedCredentials }); } What went wrong? Rate limiting – The middleware hit the login endpoint on every request that missed a token, quickly exhausting the auth provider's rate limit. State leakage – Storing credentials on the client (even in a server‑side environment) introduced a security surface. Complexity – The extra round‑trip added latency and made the code harder to debug. After a few failed attempts (and a stack trace full of 429 Too Many Requests )