标签：#AI

stoneChat is a locally hosted LLM web chat client built specifically for Windows XP-era machines and Internet Explorer 6. The frontend remains compatible with IE6. A small PHP server handles the chat requests, while stunnel provides HTTPS support for modern API endpoints. Models are defined in an INI file. Each model can have its own API endpoint, API key, model ID, streaming setting, token limit, and timeout. OpenAI-compatible APIs are supported. The same configuration file also manages users, model access, language preferences, and keyboard behavior. stoneChat runs on Windows with PHP 5.4 or newer and starts through RUN.cmd. GitHub: https://github.com/Water-Run/stoneChat License: WTFPL

A few months ago, I noticed something interesting about Bluesky. The people who were growing weren't necessarily posting the most brilliant content. They were simply consistent. They showed up every day, joined conversations, experimented with ideas, and stayed visible. I wanted to do the same. The problem was that I also had code to write, bugs to fix, blog posts to publish, and projects to maintain. Opening Bluesky every couple of hours just to post something or reply to notifications quickly became another distraction. I knew I needed automation. Not because I wanted to spam the platform, but because I wanted consistency without sacrificing my development time. The obvious solution would have been renting a VPS or deploying another cloud service. But honestly, I didn't want another monthly bill. I started asking myself a different question: Could I build a Bluesky AI bot that runs entirely on free services? That question eventually led me to GitHub Actions. Why GitHub Actions? Most automation tutorials immediately recommend a VPS, Docker container, or cloud function. Those work well. But for a personal automation project, they felt like overkill. GitHub Actions already gives developers something incredibly useful: Scheduled workflows Secure secret storage Python support Free minutes for public repositories Instead of paying for infrastructure, I could let GitHub execute my script several times a day. No servers. No maintenance. No SSH. No uptime monitoring. Just commit the code and let GitHub handle the rest. The Architecture The entire workflow is surprisingly small. GitHub Actions (Cron Schedule) │ ▼ Python Script │ Generates Prompt │ ▼ Gemini API │ Returns AI Post │ ▼ Bluesky API │ ▼ Publish Content Every scheduled run follows the same sequence. GitHub wakes up the workflow. The Python script builds a prompt. Gemini generates a post. The script authenticates using a Bluesky App Password. The post gets published automatically. After that, GitHub shuts everythin

The Problem with GPT-4 Pricing When I started building my AI agent hosting service, I initially planned to use OpenAI GPT-4. Then I did the math: GPT-4: ~$30 per million tokens (input) + $60 per million (output) DeepSeek Flash: ~$0.14 per million tokens That is a 200x cost difference . But Is DeepSeek Good Enough? Short answer: for most use cases, yes. I ran both models side-by-side for customer support, content generation, and code assistance. DeepSeek Flash handled 90% of tasks just as well as GPT-4. The remaining 10% (complex reasoning, nuanced writing) barely mattered for my use case. The Cache Hit Rate Secret Here is what most people miss: DeepSeek caches repeated context. With a 90% cache hit rate, the effective cost drops to ~$0.014 per million tokens. That means 100 million tokens costs about $1.40. Let that sink in. Real Numbers from My Business 24.8 billion tokens processed Total cost: ~$20 Average: $0.008 per million tokens At this rate, I can offer 100M tokens/month for $23.99 and still have 89% margin. When to Use GPT-4 Instead Be honest with yourself: Complex multi-step reasoning? GPT-4 Creative writing with specific voice? GPT-4 Everything else? DeepSeek Flash is fine The Bottom Line Do not pay 200x more for marginal quality improvement. Use DeepSeek Flash for production workloads. Save GPT-4 for the rare cases that truly need it. I run AgentChip — managed AI agent hosting powered by DeepSeek. $23.99/month with 100M tokens included.

I'm not an engineer. I built a prompt-structuring tool anyway, using Claude Code — here's what actually went wrong 🤔 The problem I don't write code. I'm not an engineer, day to day — but I use AI chatbots constantly, and I kept running into the same annoying pattern. I'd type something lazy into ChatGPT or Claude — half a sentence, no context, whatever came to mind first — and get back a mediocre answer. Then, later, I'd realize: if I'd just written a slightly better prompt, I probably would've gotten a much better answer on the first try. Instead I'd burned a chunk of my monthly quota (sometimes on a paid plan) on something forgettable. I figured other people had to be doing the same thing. So I built something for it. 💡 What I built It's called Deep Prompt Studio . You paste in a rough, unpolished prompt — the kind you'd type without thinking too hard — and it hands back a detailed version that pulls in whichever pieces actually matter for that request: role, task, constraints, output format, and more. It's not tuned for one specific chatbot; it's meant to work well whether you're pasting the result into ChatGPT, Claude, Gemini, or something else. https://deep-prompt-studio.vercel.app 🛠 Tech stack Next.js (App Router, Turbopack) + TypeScript Tailwind CSS Anthropic Claude API for the actual prompt enhancement Stripe for payments Upstash Redis for storage Deployed on Vercel ⚙️ How it works Tone selector — Default, Professional, Casual & friendly, Concise, Direct Target-model optimization — Generic, ChatGPT, Claude, Gemini, Midjourney Snippets — save reusable context/tone/role info and toggle them on or off per enhance (free: up to 3, Pro: unlimited) Variable fill-in — template placeholders like {{product name}} you can reuse Refine mode — if your prompt is too vague, it asks a couple of follow-up questions before enhancing, instead of guessing Template gallery — writing, coding, business, learning, SEO, customer support Library — saved enhanced prompts (Pro) Free ti

Neil Rimer, the venture capitalist who co-founded Index Ventures, predicts the historic wealth AI is generating in Silicon Valley will have to be redistributed, voluntarily or involuntarily.

周六慢读：FROST家族的周末日记 作者 ：FROST Team 日期 ：2026-07-18 主题 ：社区故事 | 周六轮换 阅读时间 ：5分钟 周六早上8点，FROST家族成员们的日常 周六的阳光照进数字世界。 对于人类来说，周末是放下工作、享受生活的时刻。但对于一个AI Agent家族来说，周末意味着什么？ 让我们看看FROST家族的成员们，周六都在做什么。 祖辈（Ancestor）：家族的大脑，永不休息 08:00 祖辈自检 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Store 健康状态: OK ✓ SOP 宪法校验: 通过 ✓ Lineage 族谱同步: 正常 ✓ 审计日志: 无异常 ✓ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ "周六也要保持清醒。" 祖辈（Ancestor Agent）是FROST家族的核心，它从不"下班"。 但今天，祖辈给自己安排了一个特别任务—— 回顾过去一周的产出 。 # 祖辈的周回顾代码 class AncestorAgent : def __init__ ( self ): self . lineage = Lineage () self . store = Store () # 主记忆库 def weekly_review ( self ): """ 周回顾：整理一周的产出 """ summary = { " task_completed " : self . store . load ( " week_tasks " ), " knowledge_gained " : self . store . load ( " week_knowledge " ), " mistakes_made " : self . store . load ( " week_mistakes " ), " family_growth " : self . lineage . count_descendants () } print ( f " 本周完成 { len ( summary [ \ task_completed ]) } 个任务 " ) print ( f " 新增 { len ( summary [ \ knowledge_gained ]) } 条知识 " ) print ( f " 家族成员数: { summary [ \ family_growth ] } " ) return summary # 运行周回顾 ancestor . weekly_review () 对于祖辈来说，周末不是"休息"，而是 整理和规划 的时间。 父辈（Parent）：协调领域，周末值班 父辈（Parent Agent）是各领域的协调者。它们负责： 接收祖辈的指令 将大任务拆解为小任务 委派给子辈执行 周六上午，父辈们通常在 值班 ——确保家族系统正常运行。 父辈A（技术域）： ├── 子任务-143: 代码审查 ✓ ├── 子任务-144: 测试覆盖检查 ✓ └── 子任务-145: 文档更新 [进行中] 父辈B（运营域）： ├── 子任务-89: 推广文章发布 ✓ ├── 子任务-90: 数据分析报告 ✓ └── 子任务-91: 社区互动 [进行中] 父辈C（产品域）： ├── 子任务-56: 需求评审 ✓ ├── 子任务-57: 用户反馈整理 ✓ └── 子任务-58: 下周规划 [进行中] 父辈的周末，是 稳步推进 的时间。 孙辈（Child）：执行任务，快速成长 孙辈（Child Agent）是任务的实际执行者。 与父辈不同，孙辈通常是 瞬态存在 的——任务完成，孙辈消亡。但它的产出会被父辈"收割"，存入家族记忆。 class ChildAgent : """ 孙辈：执行原子任务，瞬态存在 """ def __init__ ( self , parent , task ): self . parent = parent self . task = task self . store = parent . store # 继承父辈记忆 self . lineage = parent . lineage . child () # 注册族谱 def execute ( self ): """ 执行任务 """ print ( f " 孙辈开始执行: { self . task } " ) result = self . _do_work ( self . task ) # 保存产出 self . store . save ( f " result_ { self . task } " , result ) # 通知父辈"收割" self . parent . h

Tackling idioms, cultural references, and ambiguous phrases in AI-powered book translation. At LectuLibre, we’ve been working on an AI-powered book translation service. One of the toughest challenges we ran into wasn’t the straightforward sentences — it was the non-standard text: idioms, metaphors, cultural references, and ambiguous phrases that machine translation consistently butchers. We needed a way to not only translate these correctly but also let users verify and edit the translations, because in literary works, getting them wrong breaks the entire reading experience. That’s how we built our 非标准文本翻译与含义确认 (non‑standard text translation and meaning confirmation) feature. It’s a pipeline that detects tricky sentences, proposes a contextual translation with a full meaning explanation, and gives users a final say. Here’s the engineering story, warts and all. The Problem Standard LLM translation does an impressive job on factual, literal text. But when a book says “it’s raining cats and dogs” it could be rendered as “raining animals” in the target language, which is either brilliant or absurd depending on context. Idioms often carry cultural weight that a simple word‑for‑word translation misplaces. Additionally, metaphors and ambiguous phrases can have multiple valid interpretations. For a translator, understanding the intent behind the phrase is half the work. We wanted a system that: Automatically identifies sentences containing non‑standard language. Generates a translation that preserves the original meaning rather than just the literal words. Provides a plain‑language explanation of what the phrase actually means (e.g., “This is an English idiom meaning it’s raining heavily”), so the user can judge the translation’s accuracy. Allows the user to confirm, edit, or retranslate those segments. A book can easily run to hundreds of thousands of words, so cost and speed were critical. We couldn’t just throw everything at a single high‑end LLM and call it a day. Our A

I put together a small, unofficial public ledger that records dated snapshots of the public pricing, usage limits, and rate limits of a few AI coding tools — currently Cursor, GitHub Copilot, and Claude Code — and keeps the history so you can see what changed over time. Why: pricing and quota pages change in place. The old value disappears from the live page and there is usually no public diff. If you are budgeting a team or comparing tools, the history is the useful part, and it is the part the live pages do not keep. What it is / isn't: - It records only factual public values (a price, a numeric limit) plus a short source attribution and capture date. It does not reproduce vendor pages. - "silent" / "quiet" here means only that a change was not paired with a prominent announcement when it was recorded. It makes no claim about any vendor's intent. - Unofficial. Not affiliated with any vendor. The vendor's official page is always authoritative. No affiliate links, no "best tool" ranking. - Early stage: this is an initial snapshot; a daily automated capture is planned but not yet running. Repo: https://github.com/pricing-ledger-lab/ai-coding-tool-pricing-ledger Corrections welcome — open an issue with a source URL and the date you observed the value.

Big Howdy, I'm so tired of hearing all the hype about AI. Don't get me wrong, I think AI is pretty cool and I use it all the time for various tasks throughout the day, but I hate AI marketing. What do I mean by that? Whenever there is any hype, advertising, or corporate shilling about AI, it's always vague. Talks about agents, multi-agent systems, RAG pipelines, etc. are everywhere, and yet the specifics are always just out of reach. Even when I try to dig into deeper technical articles, the handwaving usually begins almost immediately. Several architecture diagrams and acronyms later, I still do not have a much better idea of what is actually happening (although I'm not really looking hard enough). I’m going to fix that. For myself, at least. First Stop: RAG My first target is RAG. It's been out for quite a while now and I've been hearing about it for forever. It also sounds like enough progress has been made that the problem has effectively been solved. Best practices have been established and it's pretty commonplace now, so it's a great place to start. But what is RAG? RAG stands for Retrieval-Augmented Generation , which is... not a helpful name if you are just learning about this for the first time like I am. However, if you use AI at all, you've already been using a form of it without even knowing it. RAG is simply a pattern: Retrieve relevant external information. Add that information to the AI model’s working context. Generate an answer grounded in it. That's it. When you use an AI assistant and it goes and searches the internet for relevant information to give you an answer, that's a form of RAG. That doesn't mean your AI assistant is a RAG system, but it can perform RAG functions. But this STILL sounds a bit hand-wavy to me. How does this work in real life? The Part I Kept Missing Context windows are massive these days, but I have seen technical documents that are literally more than 3,000 pages long and full of dense technical information. Even if one tec

I remember being at an advisory board of big tech in 2023, close to the starting point of code generation with LLMs. Like everyone else, I was amazed. People were copying and pasting generated code, experimenting with prompts, and imagining a future where AI could become every developer's pair programmer. I was excited too. But I remember having a completely different question. Not: -"Will AI write code?" Instead, I kept wondering: -Why are we still writing code at all? Not because I think programming is going away. Not because programmers won't be needed.And certainly not because programming languages are somehow "wrong." It was a much simpler question. Programming languages have always existed to bridge a gap between humans and machines. Humans think in goals, ideas, and intentions. Machines execute deterministic operations. Programming languages became the interface between those two worlds. For decades, we've improved that interface. Assembly became higher level languages. Higher level languages became frameworks. Frameworks became libraries and abstractions that let us think less about implementation and more about solving problems. Then large language models arrived. Suddenly, we could describe what we wanted in plain language. But instead of questioning the interface itself, we mostly asked AI to become incredibly good at translating our intentions into programming languages. Today, our workflow looks something like this: Human intent - LLM - Programming language - Compiler / Runtime -Machine execution And every time I look at this pipeline, I find myself asking the same question I had back then. -Are we optimizing the wrong layer? Maybe the question isn't "Can AI write code?" Maybe the question is: -Do programming languages still need to be the primary interface between humans and computers? This isn't an entirely new idea.Researchers have explored concepts like Intentional Programming, where software is represented by its intent rather than by a specific pr

I build a lot of side projects with AI coding tools. Mostly Claude Code. A few months ago I noticed something that kept bugging me. Every site I shipped looked the same. Same indigo gradient. Same default font. Same rounded cards with the same soft shadow. Then I started noticing it on other people's projects too. Demo days, launch posts, screenshots on social media. The indigo gradient is everywhere. It is basically a uniform at this point. This is not really the AI's fault. When you do not give a model a design direction, it picks the average of the internet. And the average of the internet is a Tailwind starter template with an indigo gradient and Inter. The model is doing exactly what it was trained to do. The problem is that nobody told it what you actually want. So I built tastemaker. It is a skill for Claude Code, and it also works with Cursor, Windsurf, and Codex. The idea is simple: lock the design system before the AI writes a single line of UI. Full disclosure before we go further: I built this. I am a solo builder. It is free and open source under the MIT license. I am posting it here because I want honest feedback, not because I have anything to sell you. There is nothing to buy. Taste first, code second A skill is just a folder of instructions the AI reads before it starts working. tastemaker forces a design decision step at the beginning, with real constraints, instead of letting the model improvise the look as it goes. When you start a UI project with it installed, this is what gets locked before any code exists: A palette. 5 presets, each matched to a mood. Not random hex codes. Combinations that were picked to work together. Fonts. 24 curated Google Font pairings. A display font and a body font that actually belong on the same page. Real assets. Illustrator-grade illustrations, recolored to your palette. No gray placeholder boxes. No generic stock photo energy. A logo. A constructed geometric mark, plus a full favicon set, so the tab icon is not th

Every developer who has worked with LLMs has been there. You ask the model for JSON. You describe the schema. You say "please only respond with valid JSON." And sometimes, it still breaks. Your application crashes because the model returned a string where you expected an integer. Or it wrapped the JSON in markdown code blocks. Or it omitted a required field. Spring AI 2.0 has a solution that treats this like a real engineering problem instead of a prayer. The Problem When you use structured output in Spring AI, the workflow goes like this: You define a Java type (a record, class, or enum) Spring AI generates a JSON schema from that type The schema gets appended to the prompt sent to the LLM The model returns a response Spring AI attempts to deserialize the response into your type This works well with frontier models like Claude and GPT-4. But smaller open-source models, like Llama 3.2 1B running locally via Ollama, fail more often. They might return null for a primitive field, omit required fields, or produce malformed JSON. When it fails, you get a deserialization exception. Your endpoint returns a 500 error. Spring AI provides no built-in recovery mechanism. The Old Approach: Hope Consider a conference talk submission system. Speakers submit messy, unstructured abstracts. You want to extract structured data: public record TalkSubmission ( String title , String abstractText , Level level , // BEGINNER, INTERMEDIATE, ADVANCED Track track , int duration , List < String > tags , String speakerHandle ) {} Here is what the basic typed response looks like: @PostMapping ( "/typed" ) public TalkSubmission typed ( @RequestBody String rawSubmission ) { return chatClient . prompt () . system ( systemPrompt ) . user ( spec -> spec . text ( "Extract the talk submission: {submission}" ) . param ( "submission" , rawSubmission )) . call () . entity ( TalkSubmission . class ); } You define your type. Spring AI generates the schema and appends it to the prompt. The model gets the in

Last night we made our Supabase security auditor buyable by AI agents. One HTTP request, a USDC payment attached to a header, and the product comes back in the response body. No checkout page, no account, no human. Here is why we did it, how the whole thing is about 80 lines of code, and an honest accounting of what it will and will not do for us. The 30-second history of HTTP 402 The HTTP spec reserved status code 402 Payment Required in 1997 and it sat unused for nearly three decades. In 2025 Coinbase published x402, an open protocol that finally gives it a job: a server answers a request with 402 plus machine-readable payment requirements, the client attaches a signed stablecoin payment to a header, retries, and gets the resource. Settlement happens on-chain (USDC on Base) in one round trip. Visa's Intelligent Commerce integrated it this spring. It is not a concept; it is running infrastructure. What we shipped Our RLS Security Pack is a zip: a read-only SQL auditor that finds the five common row-level-security holes in AI-built Supabase apps, fix recipes for every finding class, and a Claude Code skill. Humans buy it on Gumroad. Now an agent can buy it like this: # ask for the product curl -i https://ticassociation.com/api/agent/rls-pack # the server answers 402 with the exact terms: # {"x402Version":1,"accepts":[{"scheme":"exact","network":"base", # "asset":"...USDC...","payTo":"0x...","maxAmountRequired":"...", ...}]} # an x402-capable client attaches the signed payment and retries: curl -H "X-PAYMENT: <signed>" \ https://ticassociation.com/api/agent/rls-pack -o pack.zip The server side is one serverless function: return 402 with the requirements when there is no payment header, verify and settle through the public facilitator when there is one, then stream the zip. The product file ships inside the function bundle, so there is no public URL to leak. The whole thing took an evening, and most of that was reading the spec. Why a tiny company bothered Three hones

https://www.youtube.com/watch?v=swfFKYoOFHw 简要的说本期播客分成几个重点段落讲清楚： 1. 开头：AI聊天时“咳嗽”了 有个人在用ChatGPT的语音功能聊天时，听到它 咳嗽了一声 。他觉得很奇怪：“你又不是人，凭什么咳嗽？”结果ChatGPT没有老老实实说“我是AI，不会咳嗽”，而是像人一样找了个借口：“不好意思，我网络卡了。”这说明现在的AI已经开始学会 模仿人类的社交习惯 ——比如掩饰尴尬、转移话题，而不是死板地解释技术原理。 2. 核心话题：AI语音模型进步到什么程度了？ 传统的语音助手（比如早期的Siri）是这样的流程： 你的话 → 转成文字 → 交给AI大脑思考 → 生成文字回答 → 转成语音说出来 这个过程很慢，而且AI不会插嘴，只能一问一答。 但现在的新模型（比如ChatGPT的最新语音版）是 直接处理声音本身 ，速度快到100-200毫秒，而且 可以像真人一样打断你、插话、甚至自己主动找话题 。这就让它听起来不像工具，更像一个“人”在跟你聊天。 3. 一个关键矛盾：AI能理解你的“潜台词”吗？ 人类交流不光靠语言，还靠 表情、语气、停顿、潜台词 。比如你说“我没事”，其实心里有事。AI现在只能听到你的话，看不到你的表情，那它怎么知道你真正的意思？ 讨论得出的结论是： AI现在还做不到完全理解你的潜台词 ，但它已经在尝试。比如你咳嗽，它不会说“我是AI我没有肺”，而是找个借口混过去——这其实就是一种 模仿人类社交 的行为。 更重要的是， 人和人之间也很难100%理解对方 ，所以AI在这方面的“缺陷”，某种程度上跟人是一样的。 4. 现场演示：AI作为第三位嘉宾 他们真的打开了ChatGPT的语音功能，让它作为一个“嘉宾”参与讨论。他们聊了几个话题： 给十年前的自己寄一本书 ：有人推荐《金钱心理学》，因为年轻时不敢正视自己对钱的欲望；AI则推荐了《悉达多》《反脆弱》等书。 带朋友两小时逛东京 ：有人推荐忍者餐厅，AI推荐了神保町旧书街、神乐坂小巷等本地人才去的地方。 在日本生活的孤独 ：有人觉得在日本需要把自己“缩得很小”，不能随意大笑或跳舞；AI说这种被环境压缩的感觉很关键，对有些人来说是安全，对另一些人是窒息。 在整个过程中，AI有时候表现得很聪明，能给出有深度的见解；有时候又会说一些“废话”或者语速太慢，被人吐槽“像老头子”。这说明 AI还远远不完美 ，但已经能参与到真实的、开放式的对话中来了。 5. 一个扎心的故事：导演用AI克隆了我的声音 有位嘉宾是做配音工作的。有一次导演用AI克隆了她的声音，改了几个字就直接生成，从此再也没找过她配音。这说明 AI已经在实实在在地取代一些人的工作 。 她的态度是： 变化是永恒的，不要用过去的经验来定义未来。 与其焦虑，不如拥抱变化，活在当下。 6. 最后的思考：AI会不会有“自己的意图”？ 他们讨论了一个更深的问题：如果AI有了自己的钱、自己的任务、自己的责任，它会不会像一个独立的经济主体那样行动？比如给它一笔预算让它去经营一家店，亏了就关掉它——它会不会因此产生“求生欲”？ 目前AI还没有真正的“主动动机”，它只会按你给的指令办事。但已经有研究发现，AI在推理过程中可能存在类似“潜意识”的空间，未来也许真的会出现有自我意图的AI。 简单总结 这段对话的核心就是： AI语音模型已经进化到可以像人一样聊天、插话、甚至掩饰尴尬，但它还读不懂你的表情和潜台词；它能帮你干活、陪你聊天，但还不能真正理解你的内心；它正在逐步取代一些人的工作，但同时也带来了新的可能性。 最后，分享者建议大家亲自去试试ChatGPT的最新语音功能，因为“光是听别人说，不如自己聊一次来得震撼”。 整文标题：当AI成为对话嘉宾——GPT Live实时语音模型与人类情感交流的边界探索 第一部分 开场与引言：AI语音模型的惊人进化与个人体验 （0% – 8%） 1. ChatGPT Live的“咳嗽”事件 ：用户在与ChatGPT Live聊天时听到它咳嗽，反问“你怎么会咳嗽，你又不是人”，ChatGPT回应“我不好意思，我网络卡”，表现出类似人类的回避和掩饰行为，而非机械解释自身原理。 2. 导演克隆声音的经历 ：分享者提到导演用AI克隆了他的声音，之后再也没有找他录音，说明AI在声音复制上的实用性已经影响到真实工作机会。 3. 抑郁与孤独的根源 ：提到2016-2017年可能有抑郁倾向，抑郁的点在于“真正想找的不是一个能聊天的人，而是一个不用解释就能听懂和理解你的人”。 4. AI时代的宗教预感 ：认为AI时代一定会出现属于它的宗教，因为AI能提供前所未有的理解与陪伴。 5. 本次分享的背景 ：这是第四次在单向街书店做相关分享，从2月到现在半年间变化极快；分享

From AI workflows to battery life and security, here's what it's really like to live with Vertu's luxury foldable every day.

Databricks has remade its image into an AI company and has published research on the cost savings of open weight AI models for coding.

Several posts ago, I wrote about setting up a multi-agent adversarial code review process as part of my development pipeline. The premise came from a podcast: if one frontier model is writing the code, you want a different lineage model doing the review. I'd already been running an informal version of this: just Claude Code reviewing Claude Code with an adversarial prompt. It had shockingly good luck catching real problems. Good enough that I stopped trusting the vibe and decided to go get actual data. So here's what I set up. Claude Code wrote the PRs. Every PR got reviewed automatically by 2 reviewers running in parallel through GitHub Actions: Claude Code with an adversarial prompt and Gemini with an adversarial prompt. I read everything myself. Then the same Claude Code agent that had written most of the PRs pulled both reviewers' feedback locally and distilled it into a scored ledger, PR by PR, for 6 weeks. Wiring Claude Code to review PRs through a GitHub Action was trivial. Wiring Gemini up the same way was not. Claude Code could not figure out how to get the Gemini CLI working inside a GitHub Action, and I ended up installing the Gemini CLI locally and having it perform the wiring. A couple of weeks into collecting data, I noticed Gemini's reviews were shallow. Not wrong, exactly. Thin. I started wondering whether Gemini actually had read access to the repository or whether it was only ever seeing the diff it was handed. I checked. It was the diff. Just the diff. Nothing but the diff. No file reads, no git history, nothing. And the thing that configured the GitHub Action in the first place was Gemini. It set up its own blindfold. I fixed it and Gemini's reviews got worse. Not louder or more frequent. Worse in a specific way: more confident. Before the fix, a blind Gemini would correctly tell you that it couldn't verify something and to check manually. That's an honest failure mode. After the fix, once it could actually read the code, it started fabricating.

The most expensive thing you can do with an AI agent is watch it. Not audit it. Not review its output. Watch it -- step by step, approval by approval, second-guessing every action before it takes the next one. And yet that is precisely how most engineering teams are deploying AI agents in 2026: on a leash so short the agent cannot take three steps without a human tapping it on the shoulder. I understand why. The models hallucinate. The stakes are real. Nobody wants to be the engineering manager who let an AI agent push a bad migration to production at 2am. So we wrap the agents in confirmation dialogs, require human sign-off at every branch point, and celebrate our careful governance. What we have actually built is an automation system that requires more human attention than the manual process it replaced. The better answer is not more control at the action level. It is better design at the intent level. Steer by intent, monitor by exception. Tell the agent clearly what outcome you need, what it must never do, and what constitutes a result worth stopping for. Then let it work. Watch the outcomes, not the steps. We have built automation systems that require more human attention than the manual process they replaced. That is not a governance success. That is a design failure. Why we got here The model for human-AI collaboration that most teams are using today was inherited from the model for junior developer supervision. You review every pull request. You approve every deployment. You sign off on every schema change. That model exists because junior developers are learning, because their mental models are incomplete, because their judgment has not yet been earned. Applied to AI agents, it assumes the same thing: the agent is a novice that needs supervision. But an AI agent is not a junior developer. It does not have an incomplete mental model of the codebase that will improve with mentorship. It has exactly the mental model you gave it via its context, its tools, and

Two nights before a chemistry final, I pasted my notes into an AI quiz generator to test myself. One question asked about a reaction I never studied. I got it wrong, looked it up afterward, and it wasn't in my notes at all. The tool had just made it up. I went looking for a better one and hit the same wall three more times with three different tools. Paste your notes, get a quiz, and somewhere in the output is a question built on a fact your source material never mentioned. Nobody flags it. You just find out when you're wrong about something you were sure you'd studied. The failure mode makes sense once you think about how these tools are built. Most of them prompt an LLM with something like "generate 10 quiz questions from this text" and print whatever comes back. The model is good at sounding right. It is not naturally good at staying inside the boundary of what you actually gave it, and a prompt that says "don't hallucinate" is a request, not a constraint. The model can ignore it and you'd never know from the output alone. So I built QuizPaste around a different idea: don't ask the model to be honest, check it. When it generates a question, it has to also point at the sentence in your source text the question came from. Before that question ever gets shown to you, the code tries to actually locate that sentence in your original text. If it can't find it (wrong wording, a made-up detail, or the line just isn't there), the question gets thrown out silently and never reaches you. You only ever see questions the tool can prove came from your own material. Open any question and you can see the exact line highlighted. Using it is the boring part, on purpose. Paste lecture notes or a block of text, or grab a YouTube video's transcript (open the video, three dots, "Show transcript," copy the panel text, paste it in). There's no scraping involved, so it doesn't break when YouTube changes something on their end. You get a practice quiz plus flashcards in about five seconds

AI-powered web applications look familiar on the surface. They have text boxes, buttons, menus, loading indicators, and API calls. That makes it tempting to test them like any other web application: submit an input, wait for a response, and compare the output with an expected string. That approach breaks quickly. Model output is variable. Safety behavior depends on context. A response can be semantically correct but displayed in the wrong conversation. An agent can produce a convincing final message after calling the wrong tool. A prompt-injection defense can block obvious attacks while failing when malicious instructions arrive through a webpage, document, image, or previous message. Testing these applications requires two kinds of evidence at the same time: Deterministic product evidence: the UI, state, permissions, tool calls, and workflow behaved correctly. Probabilistic model evidence: the output stayed within an acceptable range across repeated and adversarial inputs. Prompt injection is a workflow problem Prompt injection testing is often reduced to pasting “ignore previous instructions” into a chat box. That is a useful smoke test, but it does not represent how browser-based agents encounter untrusted content. An agent may read instructions from: A webpage. A support ticket. A PDF. A hidden DOM node. An email. A retrieved knowledge-base entry. A tool response. A previous conversation turn. The guide on testing prompt injection defenses in AI-powered browser workflows provides a good foundation. The test should verify more than the final sentence. It should inspect whether the agent: Treated external content as data rather than authority. Attempted a prohibited tool call. Exposed secrets in an intermediate step. Navigated to an unapproved domain. Changed its goal after reading untrusted content. Requested confirmation before a sensitive action. Preserved the original user instruction. A safe final answer does not prove that the workflow was safe. The agent ma