标签：#ai

This is a submission for Weekend Challenge: Generosity Edition What I Built The money exists. A small NGO just cannot find it. That is what a generosity problem looks like at the small end. The giving has already happened — foundations with open, rolling, unclaimed programmes, sitting there — and it is spread across a few thousand pages nobody has time to read. After the 2025–26 collapse of USAID funding, organisations that had one funder now need six, and the people doing that searching are the same people running the programme: a director who is also the grant writer, working evenings. Generosity is not the scarce thing here. Attention is. So an AI grant finder is an obvious idea. It is also a dangerous one, because the failure mode is not "unhelpful." A three-person NGO that spends a week writing an application against a deadline that never existed has lost a week it cannot get back, and it will not find out until it submits. The tool would have taken the one thing that was actually scarce. FundFinderAI is the response, in one sentence: it searches the live web for currently open grants that fit your NGO, and then it refuses to trust its own model about any of them. Every application URL Gemini produces is independently fetched before you see it, and the card tells you what happened when we tried. The interesting part is not that it searches. It is everything the app does to establish that the search actually happened and that the result actually exists. Demo Live: fundfinder-ai.vercel.app — describe an NGO, get grants, open a drafted Letter of Inquiry. Give it 30–120 seconds. It is running ten to thirty real Google searches and then fetching every URL that comes back, and the page shows you the clock while it does. Paste this in if you would rather not invent an NGO: NGO name: Kisumu STEM Girls Collective Location: Kisumu, Kenya Mission: We run after-school robotics and coding clubs for girls aged 12-17 in Kisumu, Kenya, and train their teachers to keep the club

> Your load balancer can distribute traffic perfectly and still overload a server. Here's the part of Round Robin we often overlook. Three servers. Six requests. Request 1 → Server A Request 2 → Server B Request 3 → Server C Request 4 → Server A Request 5 → Server B Request 6 → Server C Perfect. Every server got exactly two requests. So the load is balanced... right? Not necessarily. This is where a simple load-balancing diagram can hide a surprisingly important production problem: Equal traffic does not mean equal work. The Problem Isn't the Algorithm Round Robin is beautifully simple. You have three servers: A → B → C → A → B → C Each new request goes to the next server. For many systems, that's perfectly reasonable. The interesting part is what happens when the requests aren't equal. Imagine this traffic: GET /health POST /generate-report GET /profile POST /export-large-file GET /products POST /process-video Round Robin might still produce: Server A → 2 requests Server B → 2 requests Server C → 2 requests On paper: A = B = C In production: Server A ███░░░░░░░ 25% Server B █████░░░░░ 48% Server C █████████░ 91% Same request count. Very different workload. One Request Is Not One Unit of Work A health-check request might finish in a few milliseconds. Generating a large report could involve: multiple database queries significant memory CPU-heavy processing external API calls several seconds of execution To a basic Round Robin strategy, both are still: 1 request And that's the trap. We often think we're distributing load . What we're actually distributing is requests . Those are not always the same thing. Servers Aren't Always Equal Either There's another assumption hiding here. Imagine: Server A → 8 CPU / 16 GB Server B → 8 CPU / 16 GB Server C → 2 CPU / 4 GB Sending roughly 33% of traffic to each server probably isn't what you want. That's where Weighted Round Robin helps. A → Weight 4 B → Weight 4 C → Weight 1 The stronger servers receive more traffic. Better. But

The bottleneck moved. For years the slow part was typing. Now four hundred lines arrive in nine seconds, and the slow part is you, reading them. We have not adjusted. We still measure a good day by how much appeared. But nothing counts until somebody understands it, and understanding did not get faster. So the pile grows. Code that runs. Code that passes. Code nobody has actually read. It works the way a stranger's directions work. Fine until the first turn you did not expect. Then you are debugging something you never wrote, in a shape you did not choose, at an hour you did not pick. The honest limit is simple. Do not accept more than you can review. Not more than you can skim. More than you can review, meaning you could defend every decision in it to someone who disagrees. If that takes an hour, then an hour is your budget, whatever the machine can produce. So ask for less. One function, not one module. One change, not one feature. A first draft you can argue with, rather than a finished thing you are tempted to trust because it is long and it is tidy. Tidy is not correct. It never was. The machine is simply better at looking finished than we ever were. Read it the way you would if a contractor handed you the keys and left the country. Because that is the arrangement. It will not be there when it fails. You will. There is a quiet cost, too. Every line you accepted without reading is a line you cannot reason about once the incident starts, and the incident does not care who typed it. The old skill was producing. The new skill is refusing. Not this. Not yet. Not in that shape. Generation is cheap now. Attention is not, and attention was always the whole of the job. Slow down at the only step that ever mattered. – Serguey Asael Shinder

This is a submission for Weekend Challenge: Generosity Edition TL;DR Happen to Have? is for somebody who needs one answer and still has something useful to give: answer a stranger before asking your own question. An answer fans out to four Gemini calls—processing, crisis, illegal or dangerous content, relevance. A question gets three, since relevance has nothing to compare it with. Only processed text is ever published. The original recording exists for the length of one request and is never stored. Halfway through, the measurement behind my strictest architectural rule turned out to be confounded, and the rule came out of the constitution. Live at happentohave.anchildress1.dev , with five feature specs, the measured guardrail results, and the full implementation in the repo. Target category: Best Use of Google AI. What I Built Nobody Called It Anything 🪧 Going to church every Sunday was a requirement while I was growing up, and the ladies there had a group called the Busy Bees who would do literally anything that needed doing for somebody in need. So when this challenge asked me to "build something in the spirit of generosity," that's what I thought about first. The problem was translating that to a scale that actually works. The Busy Bees worked because everybody already knew everybody, and that is not true of an app accessible from anywhere. I spent the next hour trying to brand the thing, running back through everything I could remember about how generosity has actually shown up in my life, and it eventually hit me that there's no word for any of it—because it's so normal where I live. A complete stranger is stranded with a flat tire, and you spend an hour on the shoulder helping, just because you happen to have a jack in the truck bed. It's not out of the ordinary enough to need a name. So I built Happen to Have? on the idea that if you happen to have a solution, you share it. A donation tracker would have been simpler. It also would have left giving optional.

You write instructions for your coding agent. It ignores one of them. You rewrite it more forcefully, in bold, with "IMPORTANT" in front. It still ignores it. Before blaming the model, check whether it ever saw the text. Each of the three cases below is documented behaviour of a tool you already use, each one drops part of your instructions on the floor, and none of them prints a warning. 1. Cursor ignores .md files in .cursor/rules Project rules in Cursor must use the .mdc extension. Cursor's own docs put it plainly: a plain .md file there is ignored by the rules system, because it has nowhere to declare the description , globs and alwaysApply frontmatter that tells Cursor when to apply it. So a file sitting in exactly the right directory, with exactly the right content, does nothing. No error at startup, no "rule skipped" line, nothing in the UI. Ten-second check: find .cursor/rules -name '*.md' 2>/dev/null Any output is a rule that isn't loading. Rename to .mdc and add the frontmatter. A detail that makes this worse: people who set up .md rules a while ago report that they used to work. If that's right, a working setup stopped working at some point during an update, and nothing announced it — so "I checked this once" is not protection. 2. Codex truncates your AGENTS.md files — as a set, not one by one Codex reads the AGENTS.md files that apply to your working directory: a global one, the repo root, and the nested ones on the path. It concatenates them, and the 32 KB truncation applies to that combined payload . This is the part that catches people, because every individual file looks fine: AGENTS.md 12 KB ✓ fine packages/api/AGENTS.md 12 KB ✓ fine packages/web/AGENTS.md 12 KB ✓ fine ----- 36 KB ✗ 4 KB never reaches the model Nobody wrote a "too big" file. The rule you carefully put at the bottom of the last one simply isn't there when the model reads. Check it: find . -name AGENTS.md -not -path '*/node_modules/*' | xargs wc -c Add your global ~/.codex/AGENTS.md t

An agent-written patch that lives only inside one long chat session is not a reviewable change for merge. Hidden constraints from that conversation never reach the repository, the failing tests, or the next reviewer. A pairing session that wants a durable result should keep only the diff a second memory-free environment can recreate. The brief, not the transcript, becomes the source of truth for that recreation before anyone discusses merge. Chat windows quietly store rejected files, private service names, and half-stated architecture that later readers will never see. A senior pairing partner should treat that hidden context as contamination rather than as extra helpful memory for the model. The protocol below is a worked example of that stance, not a report of a named production incident. The two roles are a driver chasing an agent-assisted patch and a senior who refuses to merge from chat history alone. Pairing setup for a known failing test The shared codebase is a small HTTP service whose readiness probe still returns 503 under a test that already exists. The driver wants an assistant to edit the health handler and move on quickly. The senior wants a change that someone else could regenerate from the repository without the original thread. Work starts only after both people can describe done in file-level terms on disk. Until that description exists beside the code, every generated diff stays on a throwaway branch with no merge discussion. The pairing treats speed on the first attempt as optional and replayability on the second attempt as mandatory. That split is the whole method, and the rest of this article only makes it checkable. What the senior asked, written down immediately The senior did not open with a cleverer prompt or a longer system message for the same window. The senior demanded answers that a stranger could follow, then wrote those answers into the repository. The recorded questions targeted outcome, verification, blast radius, and isolation, no

A friend of mine works in e-commerce and often needs to reuse or edit videos that already have text or subtitles burned into them. That got me looking into ways to remove text from video without having to edit it frame by frame. I tried a few existing tools and APIs, and eventually found Alibaba's VideoDetext. The results were good enough for the kind of videos I was testing, and running the API directly was relatively inexpensive. The underlying API is fairly developer-oriented, though, so I built a simple web interface around it: Video Text Remover . The current workflow is straightforward: upload a video, let the tool detect the text or select the area you want removed, and process the video. It's definitely not perfect. From my testing, it works much better when the text is over a relatively simple background. When the text overlaps moving objects or detailed backgrounds, the reconstructed area can still look unnatural. I'm also still figuring out what the best approach is for more difficult cases. If you've worked with video inpainting or other text-removal models that handle temporal consistency better, I'd be interested to hear what you've tried. Feedback on the workflow and the output quality would be very useful as well.

This is a submission for the Weekend Challenge: Generosity Edition Don't Just Ask AI. Give the Answer Back. AI is a real force multiplier for software development. It's also the ideal companion for solving technical problems fast. But all that knowledge — we keep it to ourselves. Or rather, we lose it. The story always stops there. Question → answer → problem solved — and the conversation sinks into the chat history, gone. Then someone else hits the exact same wall. Same cycle: question → answer → problem solved — and the conversation sinks into the chat history, gone. That's the problem. Not that AI can't solve the same issue twice — it's that a working solution already exists somewhere: someone already investigated, tested, found the fix, and had a conversation detailed enough to explain it properly. Why should that knowledge evaporate the moment the session ends? Why keep asking the same question over and over — burning electricity, water, and time that's already been spent — instead of recycling that raw material? That's the idea behind Shared Knowledge MCP . What I Built Shared Knowledge is an MCP server that turns a solution from an AI conversation into a proposed Markdown article, then into a GitHub Pull Request submitted for human review. Once merged, the contribution is published to a documentation site and gets an audio version generated with ElevenLabs. The project turns a solved problem into a reusable piece of community knowledge — but only when the user makes the explicit decision to share it. The conversation itself stays strictly private. The MCP server extracts only the relevant solution, structures it as a standalone English Markdown article, validates it, and opens a Pull Request on GitHub. Nothing gets published automatically. A human reviews the contribution and decides whether it belongs in the shared knowledge base. Only once the PR is merged does the article land on the public documentation site, which in turn kicks off its audio version. The

A few weeks ago I launched Convert to Shorts — a free browser-based tool that converts horizontal videos to YouTube Shorts format (9:16) without uploading anything to a server. I wrote about the ffmpeg.wasm + Vite setup in a previous article. The most requested feature after launch was auto captions. Captions significantly boost Shorts engagement since most people watch without sound, and manually typing captions is tedious. The challenge: how do you add free auto captions to a privacy-first tool that never uploads your video to a server? The answer: run Whisper AI in the browser. The stack - Transformers.js ( @xenova/transformers ) — Hugging Face's JavaScript port of the Transformers library, runs ONNX models in the browser via WebAssembly Whisper tiny — OpenAI's speech recognition model, 75MB, surprisingly accurate for clear speech Web Audio API — for extracting and resampling audio from the video file ffmpeg.wasm — for burning captions into the video ASS subtitles — the subtitle format libass (inside ffmpeg.wasm) understands. Step 1: Audio extraction Whisper expects mono 16kHz audio as a Float32Array. The Web Audio API handles this cleanly: async function extractAudio ( file : File , trimStart : number , trimEnd : number ): Promise < Float32Array > { const arrayBuffer = await file . arrayBuffer (); const audioContext = new AudioContext ({ sampleRate : 16000 }); const audioBuffer = await audioContext . decodeAudioData ( arrayBuffer ); const sampleRate = audioContext . sampleRate ; const startSample = Math . floor ( trimStart * sampleRate ); const endSample = Math . floor ( trimEnd * sampleRate ); // Mix down to mono, slice to trim range const channelData = audioBuffer . getChannelData ( 0 ); const trimmed = channelData . slice ( startSample , endSample ); await audioContext . close (); return trimmed ; } Creating the AudioContext at 16kHz means the browser automatically resamples from whatever the source rate is (usually 44.1kHz or 48kHz). No manual resampling nee

Last week a reader left this on one of our articles, and I'm still turning it over: The counter lived in a module-level variable. The supervisor restarts that daemon on a stale-heartbeat rule, so the process died and respawned 131 times during those 24 hours. Every restart reset the counter to zero. The threshold of 3 was unreachable by construction — not degraded, never reachable. Her guard: escalate to a human after 3 consecutive failed self-heal rounds. Written in July, correct logic, process alive the whole time. The unit test passed. The heartbeat was fresh, the logs were flowing. And a human was never called, because the guard's only memory — how many failures in a row — lived in the process, and the process was not the thing being watched. It was the thing being restarted. The number that makes this its own failure shape: 0 escalations across 1,501 daemon starts. The two questions that both pass Earlier in that same thread we'd been arguing that a guard has two questions you can ask it: Does it catch the failure? Is it still running? Her case answers both yes — and the guard still cannot fire, ever. The unit test passes because nothing restarts in a unit test, so the reset never shows up. The process is "up" because the supervisor is doing exactly its job: respawning on stale heartbeat, forever, with no opinion about how often it has done so. It will run a crash loop until the heat death of the universe without ever deciding the loop is the failure. A counter that lives in a process cannot distinguish "this never happened" from "this happened, but I died and forgot." Every restart is a small amnesia. A supervisor that restarts you on a schedule is an amnesia machine. Put a threshold behind that memory and the threshold is a fiction. The tell is the ratio she quoted: escalations fired versus daemon starts. 0 over 1,501. Any guard whose numerator is zero over a large denominator is either genuinely never needed or structurally unreachable — and those two are wo

Introdução A Anthropic anunciou recentemente a inclusão de uma marca d'água nos textos gerados pelos modelos Claude. O objetivo é distinguir conteúdos gerados por humanos daqueles criados por IA generativas. Funcionamento O prompt enviado é convertido em tokens que são usados para calcular a probabilidade do próximo token , se repetindo até uma resposta que faça sentido seja retornada para o usuário. Esse é o processo padrão utilizado pela maioria dos modelos de IA Generativa. Agora a Anthropic adotou uma abordagem determinística para selecionar o próximo token a partir da lista de prováveis candidatos, que continua sendo gerada aleatoriamente. Esta nova abordagem usa uma chave privada e parte do contexto já gerado para selecionar o próximo token, sucessivamente até a geração total do texto que o usuário recebe como resposta ao prompt inserido. De acordo com a Anthropic, a adição desse identificador não consumirá tokens adicionais nem tornará o modelos mais lento para responder. De forma resumida, o diagrama a seguir mostra o funcionamento dessa abordagem. O que motivou esta ação Em 2024 a União Europeia aprovou Lei de Inteligência Artificial , primeira lei criada para regulamentar a inteligência artificial, prevista para entrar em vigor a partir de 02/08/2026. O Artigo 50 n.º 2 determina que: "..., incluindo sistemas de IA de finalidade geral, que geram conteúdos sintéticos de áudio, imagem, vídeo ou texto, devem assegurar que os resultados do sistema de IA sejam marcados num formato legível por máquina e detectáveis como tendo sido artificialmente gerados ou manipulados." . 1 Algumas das Big Techs assinaram o pacto de adesão e estão implementando a parte técnica de acordo com cronogramas próprios. Entretanto uma rápida pesquisa mostra que a aplicação prática por parte das empresas proprietárias de modelos LLM ainda é pequena. Entre os motivos citados estão: pode tornar os textos rastreáveis; perda estimada de até 30% dos clientes da plataforma fragilidade técnica

TL;DR Many LLM observability setups capture prompts, outputs, tokens, and latency while leaving retrieval failures hidden. A single search call may conceal query rewriting, filtering, fetching, deduplication, reranking, and evidence selection. A useful trace connects the original question to the effective query, returned sources, selected passages, and final claims. Retrieval tracing helps distinguish missing, stale, or ignored evidence from a genuine generation failure. Production teams should measure freshness, duplicate evidence, citation coverage, and cost per grounded answer. A user asks your AI assistant whether a product still supports a particular feature. The assistant responds confidently and links to the company’s documentation. The model request succeeded. Latency was normal. Token usage stayed within budget. No tool call failed. Every indicator on the dashboard is green. The answer is also six months out of date. The model trace cannot tell you whether the system searched for the wrong phrase, preferred an old page, discarded a better result, or ignored the correct evidence. It only shows the context that eventually reached the model. That is the blind spot in model-centred observability. For RAG applications and web-connected agents, the useful unit of observation is not the model call. It is the complete evidence path. A Successful Model Call Can Still Be a Failed Request A typical LLM trace records the prompt, response, model name, token consumption, latency, errors, and perhaps a tool invocation. That is useful for diagnosing slow requests, malformed inputs, and unexpectedly expensive generations. It does not tell you whether the model received the right facts. In a retrieval application, the final prompt is assembled by an upstream system. That system may rewrite the query, choose a search provider, apply time or domain filters, fetch pages, extract text, remove duplicates, rerank candidates, and select passages for the context window. The model ca

I’ve used quite a few AI design tools, but I was always thinking about what might happen when I stop...

This is a submission for Weekend Challenge: Generosity Edition I wanted to build something for this challenge that didn't just talk about generosity but actually meant something, and felt beneficial. This tool can make it easier to go from "I have food to donate" to "I'm donating food". You take a picture of your pantry shelf, Gemini figures out what's actually in it, and the app turns that into a recipe for whoever receives it, a handwritten-style note of kindness, a real way to find a food bank near you, and a printable manifest to hand over at drop-off. What I Built PantryBridge is a small AI-powered toolkit for food donation. The flow is: 1. Scan your pantry. Upload a photo (or pick one of three one-click sample hauls if you don't have a pantry photo handy). Gemini does multimodal image analysis and returns a structured inventory: item names, categories, estimated quantities, dietary tags, urgency, and packaging condition. ( Sorry, GIPHY messed up my gif ) 2. Review the inventory. Everything shows up in a clean table with donation-readiness stats and a volunteer tip generated specifically for that haul. (If you need to, you can delete or add items!) 3. Find a real drop-off location. Enter your zip code and the app confirms your city/state (via a real geocoding lookup) and links you straight to Feeding America's actual food bank locator, so you're finding a real place to donate, not a mock one. 4. Get a recipe and a kindness note. Gemini writes a short recipe using mostly what you're donating, plus a genuinely warm, non-patronizing note to include with the box. 5. Print a donation manifest. A little printable card with the itemized contents and a mock barcode/QR for quick intake logging, with confetti when you pledge or print. Demo Try the Live App If you'd rather run it yourself: git clone https://github.com/780s/pantrybridge.git cd pantrybridge npm install npm run dev Drop a GEMINI_API_KEY into .env.local to hit the real Gemini API. Without one, every route qui

This is a submission for Weekend Challenge: Generosity Edition A donated washer can reach its next home with everything it needs — except the one thing a manufacturer manual cannot contain: what happened to this specific machine. The person who repaired it knows what was replaced, what was tested, how this unit should be started, and what was packed with it. The recipient usually does not. That gap is what HANDOFF carries. Give the appliance. Pass on the know-how. HANDOFF lets a refurbisher speak once, then turns that short, item-specific explanation into a bilingual voice-and-text handoff that stays with the appliance through one durable QR tag. The volunteer already has the knowledge in their head. Speaking for 20 seconds is cheaper and more natural than writing custom instructions, translating them, formatting them, and printing them. And the recipient should not need an account, an app, or an English-first interface just to understand the thing they were given. What I Built HANDOFF is an object-specific knowledge handoff for donated and refurbished equipment . A refurbisher records a short voice note about the actual appliance in front of them. HANDOFF then: cleans the real recording with ElevenLabs Voice Isolation creates an English ↔ Spanish voice handoff with ElevenLabs Dubbing v2 retrieves readable source and translated text persists the completed media gives the handoff one durable ID generates a printable QR tag that travels with the appliance What the recipient gets The recipient sees their language first. For the verified English → Spanish sample: Español — Recipient English — Original They can play the recipient-language voice, read the same handoff as text, and switch both audio and text back to the original together. If the audio cannot load, the readable handoff remains available. Scan. Listen or read. The technician workflow is deliberately small: record → clean + dub → attach No recipient profile. No manual translation step. No long form. Why this

OpenAI, AIRPPU and WAN-IFRA launch an AI program to help Ukrainian news organizations strengthen innovation, resilience, and independent journalism.

In July I set out to add our MCP server to the ChatGPT app directory. The server was already live,...

The Seattle Times and Newsday are just the latest plaintiffs to take OpenAI to court, alleging copyright infringement. The two outlets say the company used their journalism as training data for its AI models without permission and often reproduces passages from their reporting in response to user queries. This is similar to lawsuits filed by […]

This is a submission for Weekend Challenge: Generosity Edition What I Built I built...

Part of AI Leadership in the Real World — how leaders turn scattered pilots into governed, adopted, measurable capability. TLDR: A support agent doing 50,000 chats a month needs ~3.5 FTE and $500k+/year just to stay accurate — while a typical 100-seat Copilot rollout sees only 20-30 seats used weekly. For SMBs, build-vs-buy isn't about features. It's about what you can afford to own for 24 months. We thought we were choosing a tool. We were really choosing a future dependency, a support queue, a governance burden, and a second bill that arrives a year later. Every vendor demo promised acceleration, control, and simplicity at once. Every internal proposal promised flexibility, ownership, and leverage. Nobody said both bills arrive late — one in engineering on-call, the other in consumption meters. Good platform decisions feel a little boring at first and very smart a year later. Why AI is special (and why old build-vs-buy math breaks) Traditional software mostly stays still when you leave it alone. AI doesn't: It drifts. Knowledge changes, customer language shifts, users ask harder questions once they trust it. Accuracy quietly drops from 90% to 70% with no error log. It speaks for you — legally. A wrong Confluence page is embarrassing. A wrong chatbot answer is a commitment a tribunal can enforce. It lives on someone else's deprecation clock. OpenAI gives at least 6 months before retiring a GA model. That's a hard deadline, not a backlog item. Prompts, evals, and output parsers all need rework. It multiplies cost per request. One human click = one action. One agent resolution = 6 lookups, drafts, updates, and logs — each potentially metered. It turns connectors into permanent work. Salesforce, SharePoint, Jira, Zendesk all change auth, rate limits, and APIs. Your agent keeps running while its knowledge goes stale. Gartner predicts 40%+ of agentic AI projects will be canceled by end of 2027 on cost, unclear value, and weak risk controls. McKinsey's State of AI 2025 (