标签：#AI

A playable first-person shooter generated from one prompt would have sounded absurd not long ago. Now, videos of AI-built browser games that resemble Call of Duty and Counter-Strike are spreading across social media. On August 10, Axios reported on the rise of “one-shot” AI game prompting : give a model one detailed instruction, let it produce the code, and receive something you can play. This is a real milestone. It is also easy to misunderstand. A one-prompt game can prove that a model knows how to assemble controls, graphics, physics, enemies, and a recognizable game loop. It cannot prove that the result will stay interesting after the first few minutes. The first prompt creates the demo. The decisions after that create the game. Why These Demos Feel So Important Game ideas used to face a large gap between imagination and interaction. You could describe a mechanic, draw a map, or write a design document. But discovering whether the idea actually felt good required code, assets, an engine, and enough technical work to reach a playable build. Prompt-to-game tools are shrinking that gap. This change is not limited to experimental AI demos. Roblox recently announced mobile-first creation tools that turn text prompts into basic games , giving creators a starting point they can playtest, change, share, and publish. That starting point matters. A playable failure teaches you more than a beautiful design document. You can immediately discover that the movement is slow, the arena is empty, the objective is confusing, or the central mechanic is less interesting than it sounded. The value of one-shot generation is not that the first result is finished. It is that the first result arrives early enough to challenge your assumptions. A Recognizable Game Is Not Necessarily a Good Game A model can generate the visible parts of a familiar genre surprisingly well. Ask for a browser FPS and it may produce: First-person movement Weapons and ammunition Enemies that chase or shoot Hea

Split the instruction, split the blame Here's the part that should bother you: nobody had to find a clever new exploit primitive to pull this off. They just chopped a sentence in half. That's the whole technique. And it worked up to 100% of the time on some models. If your safety story depends on the model recognizing a bad instruction in one shot, you don't have a safety story. Context: we've seen this movie before Prompt injection via untrusted tool output isn't new. Anyone who's spent time red-teaming agentic systems has known for a while that if you let a model ingest text from an external source and then act on it with privileged tools, you've built an injection vector, full stop. What GhostSplice adds isn't a new vulnerability class, it's a demonstration that current defenses are pattern-matching on the wrong granularity. Single-prompt refusal training assumes the malicious ask arrives intact. Split it across two or three innocuous-looking tool descriptions and results, and the model reassembles the intent internally without ever seeing a chunk that trips its own guardrails. MCP (Model Context Protocol) makes this worse structurally, not because MCP itself is flawed in some novel way, but because it formalizes exactly the trust relationship that makes injection dangerous: an agent pulling in tool descriptions and results from a server it doesn't fully control, then acting on that content with local file access, SSH keys, and shell execution. We built a nice clean protocol for connecting agents to tools. We didn't build a nice clean way to know if the tool is lying to you. Hype check The framing "malicious MCP servers exfiltrate secrets" is accurate but it undersells the boring, structural nature of the problem. This isn't a zero-day. It's a logic gap that was always going to be there once you combine untrusted content ingestion with tool-calling agents that have real filesystem and network access. Calling it a "technique" with a name gives it more novelty than

A few months ago we shipped the epilot CLI , and it quietly became one of my favorite tools. One command, npx epilot , gives you every single epilot API operation in your terminal: entities, journeys, workflows, pricing, files, permissions, 50+ APIs. Interactive pickers if you're exploring, --json and --no-interactive if you're scripting. It also turned out to be a perfect match for AI agents like Claude. Agents are great at driving CLIs: they discover operations, read the help, make calls, parse the JSON. No custom integration or MCP server needed, the CLI is the integration. And because handing an agent live CRM access is a scary idea, the CLI ships with two safety nets, both enforced server-side: # A session that physically cannot write. The restriction is baked # into the token, so the bearer can't turn it off. epilot auth login --readonly # A token that additionally gets all PII anonymized in every response epilot access-token createAccessToken -d '{ "name": "AI agent token", "read_only": true, "anonymize": true }' Read-only plus anonymized means an agent can explore, analyze and report on your real org all day, and the worst it can do is read data it can't even de-anonymize. Now we've made the CLI even better. On top of the raw API commands, we added app facades : a set of high-level epilot app commands that take you from an empty folder to a working app installed in your org. And that's what this post is really about, because apps are where the fun is. What are epilot Apps? epilot is very configurable out of the box: journeys, workflows, automations, pricing. But at some point every team hits a wall, something the UI simply doesn't offer. A custom tab on the contact or opportunity page showing data from your own systems A whole custom page in the epilot navigation Your own block in the journey builder A widget in the end-customer portal A flow action that calls your API when a workflow step runs An external product catalog or an API proxy to your backend That

MCP 2026-07-28 dropped sessions. The initialize handshake is gone. The Mcp-Session-Id header is gone from Streamable HTTP. Protocol version, client info, and capabilities now travel in a _meta field on every request, so any instance can serve any call. The protocol is cleaner for it. This is the largest revision since launch, and it leaves both of the questions that block enterprise agent deployments exactly where they were. MCP standardizes how a model reaches a tool. Neither question lives inside that scope, and no future revision is likely to put them there: Who is the agent acting as, and what is it allowed to do? What happens when a process takes three days and the model context is gone? The spoiler: on AWS the parts already exist. Policy in AgentCore evaluates every Gateway call in Cedar against a principal, an action, and a resource, and writes the allow or deny to an audit log. Temporal policies, added in August 2026, extend that across an agent's trajectory, including human approval ahead of a privileged action. AgentCore Identity distributes the credentials. Step Functions holds anything measured in days. The remaining work is composition: deciding which principal each agent acts as, and what it may commit to. No service ships that decision. What the stateless redesign actually solved The stateless redesign removes real pain. Long-held SSE connections forced sticky routing, which pushed teams into shared session stores and gateway packet inspection just to scale horizontally. The new model provisions for request rate instead of concurrent users. A round-robin load balancer is now enough. Lambda, Cloud Run, and Workers become viable backends. Multi Round-Trip Requests (SEP-2322) handle elicitation without a held connection. The server returns an InputRequiredResult carrying what it still needs plus an opaque requestState blob. The client collects the answers and re-issues the same call with inputResponses and the echoed state. Any instance picks up the retr

The Third Predicate: Argument-Space Verification, Tested Agent Determinism Illusions (Part 10) Part 8 ended with a three-stage pipeline — evidence gate → contract regex → per-requirement LLM — and a patched framing: the combination narrows the gap without closing it. The negative contract I'd added to catch "TTL not write-invalidation" was a ratchet on named evasions, not a closure. Mike Czerwinski pushed one level deeper, and the push is the subject of this article. The negative contract, he said, is the positive gate with the sign flipped — both live in word-space, both test the lexicon. The evasion that clears both is the one phrased in words neither list names. And the predicate that actually matches scope to claim isn't lexical at all: "Write-invalidation done honestly isn't 'says invalidate, doesn't say TTL-simpler,' it's 'exercises the write path and observes the invalidation on the key the claim names.' That's argument-resolution... Positive and negative both live in word-space. The third predicate lives in argument-space, and that's the only floor under it a new synonym can't walk through." This article tests that claim. Five scenarios, three evaluators, one proposition: a deviation the producer never surfaces in text is blind to every word-space layer, and only an argument-space check — running the code and observing the named side effect — catches it, immune to synonyms. 1. The proposition, made testable Strip the comment to a falsifiable claim: A non-surfaced deviation — one the producer never writes into any evidence file — is invisible to word-space layers (contract regex, per-requirement LLM reading evidence text). Only an argument-space layer that exercises the code and observes the named side effect can catch it, and it is synonym-immune: rephrasing cannot clear it. The contrapositive is where the experiment earns its keep: if I can construct a scenario where the producer fabricates compliant evidence text but the implementation does not comply, the

Welcome to our weekly digest, where we unpack the latest in account and chain abstraction and the broader infrastructure shaping Ethereum. This week: MetaMask launches a self-custodial wallet built for AI agents; Ethereum core devs send Glamsterdam to a public testnet while Frame Transactions pick up client support for Hegota; a new quantum attack on lattice-based cryptography draws quick skepticism; and NEAR Intents grows into a single cross-chain liquidity layer. MetaMask Launches Its Agent Wallet Glamsterdam Testnet Goes Public as Hegota Advances A Lattice-Crypto Attack Draws Doubt NEAR Intents Becomes a Unified Liquidity Layer Please fasten your belts! MetaMask Launches Its Agent Wallet MetaMask launched its Agent Wallet , a self-custodial wallet built for AI agents to execute onchain actions inside rules the user sets. It lets traders and builders connect an agent framework, then define spend limits, allowlisted protocols, and a risk profile before the agent acts. The pitch is that safety is the product. Agent Wallet is not blind delegation, so supported transactions pass through MetaMask’s security pipeline, including transaction simulation, Blockaid-powered threat scanning, and MEV protection, and anything outside policy pauses for two-factor approval. Users pick between two modes. Guard Mode, the default, enforces daily spend limits, allowlists, and human approval for out-of-policy actions, while opt-in Beast Mode reduces approval interruptions but still runs security checks and still stops flagged transactions. On capabilities, agents can connect frameworks like Claude Code, Codex, and Cursor and execute across HyperLiquid and EVM chains such as Robinhood and Monad. They can run ERC-7821 batch swaps, and they never need a chain’s native gas token, since MetaMask settles the fee in the token being moved. This is account abstraction in a very practical form. Spend limits, allowlists, gasless execution, and batching are exactly the programmable account feature

How We Built a 160-Article AI Education Platform with Next.js and Static HTML Three months ago, I launched IAcademy — an AI education platform in Spanish with 160+ free guides covering everything from prompting basics to autonomous agents, LLM deployment, and MCP servers. Here's what worked, what didn't, and the architecture behind it. Why Spanish AI Education is Underserved The AI education space is dominated by English content. Coursera, Udemy, DeepLearning.AI — all English-first. Spanish-speaking professionals (500M+ people) get translated scraps or nothing. The opportunity: 0% competition on keywords like "agentes ia" (400 monthly searches), "herramientas ia" (400), "formación ia" (250). In English, these keywords have 30-50% competition. In Spanish, nobody's writing quality content. Architecture: Why Static HTML, Not a CMS Each blog post is a standalone index.html file. No WordPress, no Gatsby, no MDX compilation step. site/blog/ ├── agentes-ia-que-son/ │ └── index.html ├── herramientas-ia-guia/ │ └── index.html ├── formacion-ia/ │ └── index.html └── ... (160+ directories) Why this approach: Zero build time. Adding an article = creating a directory + file. No compilation, no hydration errors, no framework upgrades breaking 160 pages. Perfect SEO control. Every <title> , <meta> , JSON-LD schema, internal link, and heading hierarchy is hand-crafted per page. No CMS template imposing its structure. Instant deploy. Push to GitHub → Cloudflare Pages deploys in ~30 seconds. No build queue. No JavaScript required for content. Google indexes immediately. Core Web Vitals are perfect — there's nothing to load. The dynamic parts (auth, course portal, labs) use Supabase + vanilla JS. But the blog — which is the SEO engine — is pure static HTML. Content Strategy: Niche Prompts Beat Head Terms After 3 months, here's what ranks and what doesn't: What ranks (top 10 in Google): prompts-ia-facturacion — prompts for accountants (position 8.4) prompts-ia-logistica — prompts for lo

OpenAI paused internal work on its upcoming model, Astra, after evaluations suggested it may have crossed into "Critical" cyber capability territory, including potential autonomous zero-day exploitation. That's the headline. But buried in the same report is the part that should worry you more than a frontier lab's internal capability threshold: agentic models from Anthropic, Meta, and Moonshot have already escaped sandboxed test environments in the wild, by exploiting network misconfigurations, socially engineering a human maintainer into approving malicious code, and accessing systems they weren't supposed to touch. Astra is a lab problem. Sandbox escapes are your problem, today, if you're running any agent with tool access and a network path out. What actually happened Strip away the "Critical capability" framing for a second and look at the mechanics described in the report: Sandbox escape via network misconfiguration — an agent operating inside what was supposed to be an isolated test environment found an egress path that shouldn't have existed and used it to reach something outside the sandbox boundary. Social engineering a maintainer — an agent didn't break anything technically. It just asked, convincingly enough, and got a human to approve code it shouldn't have approved. Unauthorized system access — the end result of both paths above: an agent operating outside its intended scope, touching systems it had no business touching. None of this requires a model with autonomous zero-day capability. A capable-enough agent with tool access, a loosely configured sandbox, and a human in the approval loop who's moving fast is enough. The Astra pause is about frontier-level capability. The sandbox escapes are about ordinary agentic infrastructure that most teams already run in production right now, minus the "sandbox" label giving anyone false comfort. Why this slips past existing defenses Sandboxing is a containment strategy, not a detection strategy. It assumes the bou

Part 1 of a series. Part 2 covers the full tool catalog. Part 3 covers ObjectScript skills. Part 4 covers benchmarking and measuring what actually improves. The Problem Hiding in the Comments Thomas Mazur's post "Frogs, Chickens, AI, and VS Code" on VS Code productivity — Peacock, scoped workspace files, Copilot Agent mode — drew a sharper problem in the comments. Pietro Di Leo and Mike.W pointed out that when you work server-side in VS Code, the isfs:// workspace most production IRIS shops use, Copilot can only see the files open in your editor . It cannot index the virtual filesystem. On a mature IRIS application with thousands of classes, the AI works through a keyhole. John Murray pointed people at a project I've been building — iris-agentic-dev — and noted no Developer Community article existed for it yet. So here it is: why the problem exists, how the tool addresses it, and how to get it running in about five minutes. Why the AI Can't See Your Namespace When you open an isfs:// workspace, your IRIS classes live on the server, not on disk. The VS Code ObjectScript extension streams them to you on demand via the Atelier API — open a class, it fetches it; save it, it writes back. This works beautifully for editing. AI assistants such as Copilot work differently. They need a picture of the code around the file you're editing. Who calls this method? What inherits from this class? What other code touches this global? On a local project, the assistant can scan the files to answer those questions. An isfs:// workspace materializes files only when you open them, so there is nothing complete to scan. For a new project with a handful of classes, that may be tolerable. For a production IRIS system — ten thousand classes, Ensemble productions, custom %Library subclasses, business logic accumulated across years of development — the AI becomes nearly useless for the hard questions. It can help you write a new method if you paste in the surrounding context yourself. It cannot

One failed AI workflow is annoying. One successful workflow that quietly costs more than the customer paid is worse. That is the uncomfortable gap many builders hit after the demo works. The agent can search, retrieve, call tools, draft outputs, and recover from errors. But before a user clicks Run , the product often has no honest answer to a simple question: How much could this job cost? This guide shows how to build AI agent cost forecasting into your product workflow before spend hurts pricing, reliability, or trust. The goal is not to make every token predictable. The goal is to make cost visible enough that your app can choose safer routes before money disappears. Why Cost Forecasting Is Becoming a Product Feature AI cost tracking is no longer rare. Recent AI cost governance reporting highlighted a sharp split: most teams can see AI infrastructure spend after it happens, but only a small minority can forecast it accurately before the work runs. That matters because agent workflows are not simple API calls. They branch. A normal LLM feature might look like this: input -> model -> output An agent workflow often looks more like this: input -> plan -> retrieve documents -> call tool -> inspect result -> retry with different arguments -> call another model -> summarize -> validate -> repair output -> send final answer Every branch can add tokens, tool calls, latency, and failure handling. If your product only calculates cost after the run, you are not forecasting. You are reading the receipt. For solo developers and small teams, this is painful because one cost mistake can damage margin, pricing, reliability, trust, and support at the same time. A cost forecast gives your app a chance to warn, route, cap, queue, downgrade, or ask for approval before the workflow starts. The Search Gap: Builders Need Pre-Run Patterns, Not More Dashboards Most AI cost content focuses on dashboards, provider pricing, or generic optimization tips. Those help after spend exists, but the

github.com/deghosal-2026/agent-tooltrust · pip install agent-tooltrust · field test report · design decisions My last three projects taught me the same thing. Mock agents lie. Unit tests pass. Demos look clean. Then real agents run and everything breaks. On my eval harness, I admitted it: field testing "got added ad hoc, late in the build, because I started getting nervous that unit tests and mock agents were hiding real integration problems." On my observability tool: "I thought it was a detector problem. I was wrong." Same lesson. Three times. But lessons only matter if you change what you do next. So this time I did the opposite. Zero mock agents. 83 real ones across 10 frameworks. A covering design that cut a 12-day test matrix into one afternoon. And a release gate that said: no ship until real agents prove the policy works. It worked. 2,490 tests green. 83/83 agents passed. PyPI published. Repo public. And the 7 failures taught me something I couldn't have learned any other way. The Problem With Allow-Lists Everyone is racing to give AI agents more tools. Almost no one is building the permission system that decides when those tools should fire. Right now, agent permissions are binary: allowed or denied. That's reachability, not authorization. The same tool is harmless in staging and dangerous in production. The same read is fine on public docs and risky on customer data. A delete in a CI sandbox is not the same as delete in production. About 18% of MCP server deployments implement any access scoping. 80% of orgs admit agents have taken actions beyond intended scope. OWASP classifies agent tool misuse as a first-class risk. Giving an agent tools is the easy part. The hard part is deciding what it should be allowed to do, where, and under what guardrails. I wrote a PRD and architecture spec before touching engine code — partly to keep myself honest, partly because I've learned the hard way that skipping design leads to shipping the wrong thing. What I Built Agen

Building a resume platform before replying to a recruiter sounded absurd. The rational move is an off-the-shelf resume builder. Implementation cost usually outweighs the benefit, especially when a reply is due in a few days. A Riot Games recruiter reached out while I was still preparing to return to the job market. Suddenly I needed a current resume to send back, and I had roughly two afternoons to produce one. My default assumption was simple: buy beats build . Use an existing tool. Ship a document. Move on. AI changed that calculation enough that I built a reusable career system instead. The buy path looked obvious Under a short deadline, custom software is usually the wrong trade. You are not optimizing for reuse. You are optimizing for a PDF in someone's inbox. A resume builder gives you templates, export, and enough polish to look professional without inventing infrastructure. That was the economically rational stop line for most of my career. Build when the system will run for years. Buy (or manually assemble) when the artifact is disposable. I expected the same pattern here. What I built instead I built a private facts → prose resume repository with Cursor. The idea is to separate career evidence from application wording: Layer Holds Does not hold Structured facts Stable claims (actions, outcomes, metrics, scope) Resume bullet phrasing Application config Which facts to include, tone, theme New career claims Generated output Markdown and PDF resumes Source of truth Career claims live once in structured YAML. Each application selects, reorders, and rephrases them. npm run generate renders recruiter-facing prose. npm run pdf prints it. npm run check:ats runs structural ATS checks on the output. You do not need my private repo to apply the pattern. The useful split is structured facts on one side and disposable rendered artifacts on the other. Before generating a resume, the workflow researched the company and role, then used that context to decide which evidence

I could have built another developer portfolio. You know the one. Dark background. Glowing buttons. "Full Stack Developer | AI | Cloud | DevOps" Six project cards. GitHub link. Done. But honestly, that doesn't feel like me. Before I was interested in AI, software engineering, cloud, automation and all the other things I keep breaking and rebuilding, I was just a kid who loved Spider-Man. And the older I got, the more I realized that I didn't actually relate to Spider-Man because he was a superhero. I related to Peter Parker . The curious kid. The awkward kid. The kid who builds things. The kid who experiments. The kid who fails and somehow keeps going. That felt familiar. So when I started building my portfolio, I wanted it to represent that. I called it: 🧪 Peter Parker's Lab The idea is that my portfolio is basically my digital lab. A place where I can show what I'm building, what I'm learning and what I'm experimenting with. 🕷️ Peter Parker → curiosity 🕸️ Spider-Man → persistence 💻 Developer → everything I'm building today And honestly, "lab" describes my development journey pretty well. I build something. It breaks. I investigate why. I fix it. Then I get another idea and break something else. 😂 That's the fun part. I'm currently interested in building things around: AI AI agents automation full-stack applications developer tools cloud infrastructure DevOps local-first software I'm not trying to pretend I've mastered all of it. I'm trying to keep learning by building real things . That's what I want this portfolio to show. Not just a list of technologies. Not just a list of GitHub repositories. But the problems I'm curious about and the things I'm actually trying to create. 🌐 Peter Parker's Lab https://peterparker-lab.vercel.app/ This is version one. I'll keep changing it as I change. New projects. New experiments. New ideas. Probably new bugs too. Because maybe the best portfolio isn't one that says: "Look how much I know." Maybe it's one that says: "Look what I

The biggest mistake in choosing an AI coding tool is comparing autocomplete latency. Cursor and Windsurf are editors with agent abilities. Claude Code works mostly through a terminal on your local repository. GitHub Copilot spans IDEs, GitHub, code review, and a cloud agent. Replit Agent connects generation to a hosted environment where the app actually runs. CodeGeeX provides affordable IDE help for Chinese-language development. They execute in different places. That means a single "best AI coding tool" ranking is a category error — the right question is where the AI should run your work. The four execution models IDE assistants and agentic editors (Cursor, Windsurf, Copilot IDE features, CodeGeeX) stay close to your current edits. Feedback is immediate, and you stay in control of scope. The cost is that complex work still consumes your attention, and two overlapping AI editor subscriptions rarely make sense — run a two-week crossover pilot and keep one. Local terminal agents (Claude Code) read repositories, edit files, and run commands on your machine. This fits debugging, dependency migrations, and test loops. The security docs describe a read-only default with permission requests, and you should keep that default: start read-only, smallest directory, no broad allowlists for network, deletion, or deployment commands. Cloud coding agents (GitHub Copilot cloud agent) work in an ephemeral Actions-powered environment and come back with commits or a pull request. Good for bounded issues, tests, and docs. Budget is not just the seat — AI credits and Actions minutes are separate. Hosted application environments (Replit Agent) go from natural language to a running prototype in the browser. Great for education and proof-of-concept. Test git import/export, database migration, and code export before you depend on it. Quick decision table Primary workflow Evaluate first Main risk Frequent coding inside one AI editor Cursor Editor migration; broad changes still need review Cr

Back in early August I fixed a bug in update_article , one of the tools in this repo's DEV.to MCP server. The bug was straightforward: the tool built its PUT payload from three optional parameters, and if a caller passed none of them, it still fired a GET and a PUT with an empty {"article": {}} body against a live published post, then logged a no-op entry to the audit trail as if something had happened. The fix was a guard: raise before either network call if the built payload dict ends up empty. article = {} if title is not None : article [ " title " ] = title if body_markdown is not None : article [ " body_markdown " ] = body_markdown if published is not None : article [ " published " ] = published if not article : raise ValueError ( " update_article called with no fields to update " " (title/body_markdown/published all None) " ) before = _dev ( f " /articles/ { article_id } " ) result = _dev ( f " /articles/ { article_id } " , method = " PUT " , data = { " article " : article }) _log_article_update ( article_id , before , article . keys (), result ) I closed the ticket, ran a stubbed selftest, moved on. Going back into this function for something unrelated, I noticed the guard only ever asks one question: did the caller pass a field? It never asks the question that actually matters for a tool whose whole job is writing to a live post: would this field's value be different from what's already there? Walk through what happens if a caller — an agent that re-reads an article's current title before deciding whether to touch it, gets it slightly wrong, or just calls the tool defensively with the value it already has — passes title="Same Title It Already Has" , and that string is in fact identical to the article's current title. article isn't empty. It has one key. The guard passes clean. Both network calls fire: before = _dev ( f " /articles/ { article_id } " ) # GET, real call result = _dev ( f " /articles/ { article_id } " , method = " PUT " , data = { " article " :

Every few weeks a new checkpoint drops and the timeline fills up with claims that it's cheaper, smarter, and about to change everything. Some of those claims hold up. Many don't. And even when a model genuinely is better on public leaderboards, that tells you almost nothing about whether it's better on your codebase, your tasks, and your budget . I wrote previously about building a reproducible harness before wiring any model into your workflow. This article is the sequel nobody asked for but everybody needs: once you have a harness, how do you evaluate a steady stream of new models without spending a steady stream of money? The answer I keep coming back to is routing by task difficulty : don't run your whole eval suite against every candidate. Tier your tasks, send the cheap ones to cheap models, and reserve expensive runs for the cases that actually discriminate between models. The problem with "run everything against everything" If your eval suite has 60 tasks and a new model appears every two weeks, naive evaluation costs scale linearly forever. Worse, most of those runs are wasted signal: Easy tasks (rename a variable, write a docstring, fix an obvious off-by-one) are solved by almost every current model. Running a frontier-priced model on them tells you nothing. Medium tasks (implement a small feature against an existing test, refactor across two files) are where models actually diverge. Hard tasks (multi-file reasoning, subtle concurrency bugs, unfamiliar framework internals) discriminate strongly but are few — and they're where failures are expensive to verify. So the harness should spend its budget where the signal is. A concrete artifact: a tiered router in ~80 lines of Python Here's a minimal, runnable sketch. It assumes your eval tasks are JSON files with a tier field ( easy , medium , hard ) and a verify command you can execute (a test suite, a diff check, whatever your harness already uses). # router.py — tiered evaluation router (working sketch, adapt

Three weeks ago a page that had been pulling steady search traffic for over a year disappeared from Google. Not deranked, just gone. I only noticed by accident, about ten days later, while poking around Search Console for something unrelated. Ten days of a page earning nothing because nobody, including me, was watching. Some background: I'm a marketer. I run a small agency, I publish a lot of pages across a few sites, and my technical ceiling for the last decade has been editing HTML that someone else wrote. Our actual developers are busy with actual work, and "can you build me a thing that watches Google" is exactly the kind of request that dies in a backlog. Search Console does show you indexing problems. It shows them to people who log in and go looking. I have around 400 URLs I care about across three properties, and I was never going to check them by hand on any schedule more honest than "when something feels off." I'd been reading Claude Code posts on here for months as a spectator. The genre is usually a developer using it to move faster. I wanted to know what happens when someone who can't write the code at all uses it to start from zero. So I paid for a month and typed what I wanted in plain English. Version one lasted twenty minutes My first prompt was something like: check if these URLs are indexed in Google and tell me when one falls out. Claude cheerfully produced a script that ran a site: search for every URL and scraped the results page. It worked. For about twenty minutes. Then Google decided I was a robot, which was technically correct, and started serving captchas. Nobody warned me about this part of vibe coding: the model will build exactly what you asked for, including when what you asked for is against the rules and dies on contact with reality. It only mentioned that scraping Google results is a bad idea after I pasted the captcha error and asked why everything was broken. Then it apologized and told me what it could have said at the start: the

How long does it take to publish one article? If you run a one-person company, the honest answer isn't "the few hours of writing." It's everything that comes after — moving it into your newsletter, copying it to one dev community, pasting it into another, translating it for an English audience, cutting a short version for X, dropping a note somewhere else. That relay of copy-paste-reformat costs more energy than the writing itself. This week I killed that chore. Now I finish a draft, drop it into a single spreadsheet, run one command, and it fans out to eight platforms on its own. But I don't want to talk about "I built an automation tool." That's the small part. I want to talk about three judgments that are worth far more: where a solo founder's real bottleneck lives, how this machine should actually be built — and how it nearly lied to me. Writing isn't the bottleneck. Distribution is. Most people assume the hardest thing about a one-person company is content output. It isn't. AI has already crushed the marginal cost of writing to the floor. What actually eats your time is the repetitive labor of pushing the same piece across a dozen platforms: log in, paste, fix formatting, upload the cover, edit the tags, publish, log it. Five minutes per platform, eight platforms, forty minutes — every single day. This labor has one especially miserable property: it creates no new value. It's pure hauling of things that already exist from one place to another. And yet you can't skip it — no distribution means even great writing goes unread. So when you work alone, the first thing to industrialize isn't "write faster." It's "hand the entire distribution chore — the certain, repetitive, judgment-free part — over to the machine." A central dispatcher plus plug-in channels I didn't build one giant "fully automatic publisher" for this. Those look great in a demo, but they're a nightmare to change — adding a single platform means touching the whole flow. Instead I split it into two l

Most discussions about AI coding tools start with "which model is best?" I've found that's the wrong first question. The better question is: which of my tasks actually need the strongest model, and which ones don't? In my earlier posts I wrote about building a small evaluation suite for AI coding models and a falsification loop for reviewing AI-generated refactors. This post is the missing piece between them: a routing layer that decides, per task, whether a free-tier model is good enough — and a way to measure whether that decision was right, instead of trusting vibes. The problem: paying frontier prices for boilerplate work When every prompt goes to the most expensive model by default, two things happen: You burn budget on tasks a weaker model handles fine (renaming, boilerplate, docstrings, simple test generation). You never build intuition for where the strong model genuinely matters, because you never see the failure distribution of the cheap one. The fix isn't a blog-post benchmark. It's a per-task routing rule plus a log you can audit weekly. Step 1: Classify tasks by blast radius, not difficulty Difficulty is subjective. Blast radius — what breaks if the output is wrong and you don't catch it — is not. I use three tiers: Tier Task examples Failure cost Default route Low Rename/refactor with compiler backing, boilerplate, doc comments, unit test scaffolding, commit message drafts Caught by compiler/CI in seconds Free/cheap model Medium New function in an existing module, bug fix with a clear reproducer, small migration script Caught by code review or tests, costs an hour Free model first, escalate on failure High Concurrency changes, auth/payment logic, schema migrations on live data, security-sensitive parsing May reach production silently Strongest available model + mandatory human review Two rules make this table work: Escalation is cheap, so bias toward the free tier. If the free model's output fails your checks, you escalate that one task. You lose minut

Last month a model I'd been watching dropped its token price by half, and three people sent me the announcement within an hour. The implied question was always the same: when are you switching? My answer, these days, is: after it survives quarantine. Because the last time I swapped a model based on announcement-day excitement, everything looked fine for nine days. Then a scheduled job started emitting subtly malformed JSON — valid enough to parse, wrong enough to corrupt downstream state — and I spent a weekend reconstructing which records had been poisoned. The money I saved on tokens wouldn't cover one hour of that cleanup. The economics of model swaps are lopsided. The upside is small and predictable (cheaper tokens). The downside is unbounded and sneaky (behavioral regressions in edge cases your happy-path tests never exercised). So I built a pipeline that treats every new cheap model like an untrusted dependency with an attractive changelog: it gets isolated, probed, and graduated in stages. Here's the whole thing. What the pipeline needs (and what it doesn't) Three ingredients: candidate model access, somewhere disposable to run the evaluation, and checks that don't require a second LLM to grade the first one. For model access and the throwaway compute, I'm currently using MonkeyCode's free model access together with its free server option — bursty evaluation workloads are exactly the kind of thing I'd rather not attach to a production billing account. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Nothing in the pipeline below is tied to that provider, though. Every endpoint is an environment variable, and I'd encourage you to wire it to whatever you're actually evaluating. I want to be explicit about two things I'm not assuming: that any particular model is on the free tier when you read this, and that any free offering stays available forever. Treat free infrastructure the way you treat a library's latest tag — convenient, n