Workflow Hub

I built a custom news agent that skips the Google News and Apple News walled gardens. Eight prompts turn Claude into a personal news editor that reads my trusted RSS feeds, scores every story with a decision model, and delivers a clean daily page for about a dime a month. Each week, pulling two or three good stories for my newsletter digest meant searching multiple sites by hand—hours of clicking and scrolling for a handful of usable links. RSS feeds already deliver that content; the missing piece was a judgment layer that could separate worthwhile stories from noise without the cost or latency of running everything through a full LLM. I used Claude Cowork, Jev from TypeSafe AI, Vercel AI Gateway, RSS feeds, Python, and SQLite. Jev is a decision model rather than a chatbot: it returns a probability and confidence score instead of prose, does not hallucinate facts, and scores a story in a fraction of a second. That makes an automated daily judgment call inexpensive enough to run continuously. Step-by-step: 1. I set up a Claude project to hold the scripts, taste guide, database, and page. 2. I defined the goal and sections, then had Claude interview me to create a short “taste guide” describing what counts as a good story. 3. I found and live-tested the RSS feed for each trusted source instead of guessing feed URLs. 4. I fetched all working feeds into a deduplicated SQLite database and logged failures. 5. I used Jev through Vercel AI Gateway to score every story: first filtering ads and promotions, then ranking stories by section against my taste guide. 6. I selected the winners for each section, with Jev identifying near-duplicate stories so they would not appear twice. 7. I generated one-line summaries and fact-checked them against the source so nothing was invented. 8. I rendered a simple HTML page and scheduled the entire workflow to run every morning. A few details matter. I used Cowork rather than a plain chat because several steps require Claude to work with files, run code, and access the network. I also created a Vercel account and AI Gateway API key manually before the scoring step. Finally, I saved everything to the Claude project instead of a local folder, which allows the morning run to happen in the cloud on its own schedule. Scoring costs roughly $0.10 per month with Jev, compared with a few dollars for a full LLM doing the same job. The workflow turns a two-hour weekly slog into a page that is ready every morning, with each link going directly to the original publisher rather than a Google or Apple aggregator. Full build walkthrough: onabetternote.substack.com/p/build-your-own-news-agent-with-claude — the Substack post includes the exact eight prompts to copy and paste, plus more detail on why a model like Jev matters for cost containment as agents become routine.

I am a Mohs surgeon who built and shipped an iOS app without formal software engineering training. The surprising part was not only getting AI to write the code; it was getting AI to remember what it had already done. I built ErgoSherpa because up to 90% of surgeons in my field report musculoskeletal symptoms, while our training fails to address them. I wanted to help surgeons improve their health easily between cases. It is free on the Apple App Store and at ergosherpa.com. The bottleneck was maintaining coherence over time. Many sessions seemed to start from zero: I would re-explain the architecture, then watch a fix quietly undo something I had solved earlier. Three habits fixed that. First, I created persistent project documentation: a `MEMORY.md` index file plus separate topic files for architecture and business decisions. I update them at the end of every session so a new session can read the files first and pick up where the last one stopped. Second, I stopped handing one model the whole job. I use three models and match them to the task. Claude Fable audits only. I open a separate session, point it at the codebase, and require a prioritized checklist with the file path, the problem, and the fix in one sentence—without writing code. A model that did not write the code and has no memory of the project reviews it more honestly than the session that built it. I paste that checklist into a Claude Opus session, which handles the codebase repairs. Claude Sonnet handles routine work such as content updates, image processing, and scheduled maintenance, often from handoffs written by Opus or Fable. Nothing gets implemented on the auditor’s word alone: I have Opus flag any decision that needs human input. This workflow caught a deep-link handler that accepted authentication tokens from any URL and a database policy missing its write-side check. Third, I verify against production, not just the code. Some of the most frustrating parts of the project involved fixes that were correct in the file but wrong on the user’s screen because of a cached asset, a stale database row, or an iOS process that needed a force-quit. I no longer consider anything fixed until I have checked the live app. Step-by-step: 1. I keep a project memory directory with a `MEMORY.md` index and separate topic files for architecture and business decisions, updating them at the end of every session. 2. I open a separate Claude Code session running Claude Fable and prompt it to audit the codebase and return only a prioritized checklist: file path, line number, the problem in one sentence, the fix in one sentence, with no code or commentary. 3. I keep the auditor in its own session with no project history so it reviews the code independently instead of defending work it wrote. 4. I paste the checklist verbatim into a Claude Opus session and have it work from the top down, reading each file and making each change. 5. I tell Opus to flag anything it believes is a false positive instead of implementing it, keeping a human in the loop on key findings. 6. I use Claude Sonnet for routine work such as content updates, image processing, and scheduled maintenance, often from handoffs written by Opus or Fable. 7. I verify every change against the live production site rather than the local files because cached assets and stale database rows can make correct code behave incorrectly for users. 8. I append confirmed lessons and architectural decisions to the project memory so the next session starts from the project’s current state.

I’m sharing “The Architects of Reality,” a short film created as part of an experiment with a multi-agent AI workflow for long-form content creation. Off-the-shelf AI video platforms are brilliant for short clips, but as the duration increases, the challenges compound: character inconsistency, narrative drift, visual discontinuity, and expensive iterations when the output doesn’t match the creative vision. Instead of asking one AI to make a film, I created an AI film crew. Specialised agents and sub-agents take on roles including Director, DOP, Cameraman, VFX Supervisor, Sound Engineer, VO Artist, and Audio Mixer to support the filmmaking process. Creative review and approval are built into every stage, so individual elements can be regenerated before expensive final rendering. This helps optimise tokens, budget, and creative control. It’s been a fun journey building these agents—and even more fascinating to watch the output improve in capability and efficiency as they learn every day. Step-by-step: 1. I set up a multi-agent AI workflow for long-form content creation. 2. I assigned specialised filmmaking roles to agents and sub-agents, including Director, DOP, Cameraman, VFX Supervisor, Sound Engineer, VO Artist, and Audio Mixer. 3. I built creative review and approval into every stage of the process. 4. I regenerate individual elements when they do not match the creative vision, before moving to expensive final rendering. 5. I use the workflow to optimise tokens, budget, and creative control while producing the short film “The Architects of Reality.” 6. I observe how the output’s capabilities and efficiencies improve as the agents learn every day.

I ask Claude every month or so to be my Claude Code learning coach by simply typing the /insights command. It provides a hyper-personalized website report card with advice to help me use Claude Code better, with exact examples of where things go wrong, features, and prompts I should try. Step-by-step: 1. I ran the /insights command in Claude Code to analyze how I had been using the tool. 2. I reviewed the personalized website report card it generated, especially the examples of where my workflow was breaking down. 3. I pulled out the recommended features, prompts, and habits that were most relevant to the mistakes I was making. 4. I practiced those recommendations in my normal projects instead of treating the report as generic advice. 5. I repeat the exercise every month or so to see what changed and what I should learn next.

I had a file sitting on my desktop that Claude Code needed to see—a spreadsheet, a PDF, or a screenshot someone sent me—but a terminal had nowhere to drop it. Typing the path was the only option. In WSL, that meant rewriting `C:\Users\me\Desktop\report.xlsx` as `/mnt/c/Users/me/Desktop/report.xlsx` by hand every time. I set up two folders at the root of my Claude Code workspace: `_inbox/` for files going to Claude and `_outbox/` for files coming back to me. The names are from the workspace’s point of view, so the direction is never ambiguous. I also added a single line to `CLAUDE.md` so Claude knows where to leave things: "Save deliverables meant for me (reports, exports, drafts) to _outbox/." That one line handles the entire return trip. For the desktop handoff, I installed a small window pointed at the workspace folder. Disclosure: the window is mine—claude-work Desk, open source and free, at github.com/tact0225/claude-work-desk. Setup takes about two minutes and requires no terminal. Anything dropped onto it is copied into `_inbox/`. If you’d rather not install anything, you can drag files into `_inbox/` with Explorer or Finder; every other step still works. Now I drag files onto the window instead of typing a path. The file lands in `_inbox/`, and the window logs it with a timestamp so I can see that it actually arrived. Then I tell Claude, "check _inbox"—no paths and no `/mnt/c` rewriting. When Claude finishes, it saves the results to `_outbox/`. The window watches that folder and marks anything new in the tree until I open it, so finished work announces itself. I no longer interrupt Claude to ask, "Is it done, and where did you put it?" Step-by-step: 1. I created `_inbox/` and `_outbox/` at the root of my Claude Code workspace, using the workspace’s point of view to define the direction of each folder. 2. I added `"Save deliverables meant for me (reports, exports, drafts) to _outbox/."` to `CLAUDE.md`. 3. I installed claude-work Desk and pointed its desktop window at the workspace folder. Alternatively, I can use Explorer or Finder to place files directly in `_inbox/`. 4. I drag files onto the window, which copies them into `_inbox/` and logs their arrival with a timestamp. 5. I tell Claude, "check _inbox". 6. Claude saves finished results to `_outbox/`, where the window marks new files until I open them.

I built a custom web app that uses chance to combine random images and texts into new, unplanned pairings. It recreates a Dadaist technique I use often when making photobooks, which I previously did manually with physical prints. I used Replit to create a digital version of the game. It was easy to connect the app to Project Gutenberg for random texts and the Library of Congress photography archive for images. More importantly, I made it possible for users to work with their own image and text archives. So far, it has produced many new and interesting results, and other artists have used it too. Step-by-step: 1. I identified the manual process I use when making photobooks: combining printed images and texts by chance. 2. I used Replit to build a digital version of this process as a web app. 3. I connected the app to Project Gutenberg to pull random texts. 4. I connected it to the Library of Congress photography archive to pull images. 5. I allowed users to work with their own image and text archives. 6. I used the app to create new pairings and shared it with other artists, who used it as well.

I built Shots2Points, a golf scoring app for iPhone and Android, using AI as my development partner. The idea came from organising and playing in golf society events. Stableford scoring itself isn’t particularly complicated, but running an event can be. Organisers have to prepare groups, handicaps, and courses; collect scores from different groups; calculate results; manage withdrawals and ties; and eventually produce a leaderboard. I wanted to simplify that process while also providing an easy scoring app for ordinary casual rounds. The unusual part is how I built it. I’m not a professional software developer, and I don’t have a development team. I started by describing what I wanted the app to do to AI and gradually turned the idea into a working product. My workflow evolved into this cycle: idea → discussion → specification → implementation → real-world test → refinement. I repeat it for each feature. Step-by-step: 1. I define the problem and user experience with ChatGPT. I discuss ideas, challenge assumptions, work through workflows, and decide how a feature should behave before changing the code. 2. Once the behaviour is clear, I turn the idea into an implementation task. I use AI to specify exactly what needs to change, including edge cases and how the new feature should interact with existing functionality. 3. I build and inspect the code with Cursor. Cursor works directly with the project codebase, allowing AI to investigate existing code, implement changes, and report exactly what it changed. I test the result rather than simply accepting AI-generated code. 4. I test development versions on real iOS and Android devices. I follow the actual user journey, take screenshots or capture errors when something isn’t right, and bring those results back into the AI workflow. 5. I use AI to diagnose problems, make another targeted change, and test again. The result is a real cross-platform application rather than a prototype. Shots2Points includes free casual Stableford scoring and an Event Mode designed for golf societies and groups. Organisers can create events, import players, allocate groups, and allow each group to enter scores while everyone follows a live leaderboard. Building the app has required much more than generating code. AI has helped me work through database design, APIs, authentication, in-app purchases, App Store and Google Play requirements, debugging, user-interface decisions, testing, and release management. The biggest lesson for me has been that AI doesn’t remove the need to understand the problem or make decisions. It gives one person access to capabilities that would traditionally have required several different specialists. I provide the product knowledge, requirements, judgement, and testing; AI provides much of the technical capability and an extraordinarily fast feedback loop. That combination allowed me to take a personal idea for improving golf scoring and event management and turn it into a functioning iOS and Android product.

Midlifecurious is a newsletter for women navigating midlife—honest, funny, and allergic to being talked down to. Its Sunday issue, the Midlife Missive, is a roundup covering health, wellness, money, beauty, and family. My sister, Claire, edits it; I build the machine behind it. That machine is Missive, a five-part publishing intelligence system that runs the newsletter as one closed loop: scan → triage → publish → measure → remember. It monitors Reddit, search trends, and RSS to identify what midlife women are paying attention to before those topics reach our feeds. Discovery pulls in those sources, ranks every feed using a click-rate-based quality score, and lets Claire triage articles into the week’s issue. Curation composes Sunday’s newsletter and drafts the introduction in her voice. Performance reads the Mailchimp results back into the system and feeds them into the rankings, so strong sources rise and weak ones fall over time. Underneath all four stages is Memory: a vector-searchable corpus of every article, save, rejection, and the reasoning behind each decision. Memory is the real spine of the system. It lets Missive ask editorial questions such as “Have we covered this before?” and “Is this source still earning its slot?” instead of requiring one person to hold everything in her head. We’re a two-person operation: I build with Claude Code, and Claire edits. The system runs on one database for under $25 a month. I built it because the alternative was Claire drowning in a Feedly-and-spreadsheet routine that discarded everything as soon as an issue shipped. We had no record of what we had run and no feedback on what actually landed. My bet is that the corpus is the moat. Claire’s editorial taste—every save, rejection, and “cornerstone” stamp, with the reasoning stored alongside the decision—is a training set no one else has. A system that remembers turns her job from synthesizer into judge. Missive is deliberately internal-only: no SaaS and no customers, ever. That frees me to build for our exact workflow instead of a hypothetical buyer, and to build for 2028 instead of this quarter. The near-term payoff is a calmer Sunday. The long-term goal is a proprietary editorial-intelligence layer we could never buy off the shelf—the foundation for the research and audience products that come next. Step-by-step: 1. I monitor Reddit, search trends, and RSS for topics that midlife women are paying attention to. 2. I pull those sources into Missive and rank each feed using a click-rate-based quality score. 3. Claire triages the ranked articles into the week’s Midlife Missive. 4. Missive composes Sunday’s newsletter and drafts the introduction in Claire’s voice. 5. I import the Mailchimp results so the system can update source rankings based on performance. 6. Missive stores every article, save, rejection, “cornerstone” stamp, and the reasoning behind each decision in a vector-searchable corpus. 7. We use that memory to check whether a topic has already been covered and whether a source is still earning its place. 8. I build and maintain the internal system with Claude Code, while Claire handles editing, using one database that costs under $25 a month.

I built Able (uable.store) because I was tired of chat tabs that explain how to do a job but leave me to paste the result into PowerShell. I wanted an agent that lives on this Windows PC and can actually move files, run tools, and write code here after I approve the actions. I work on Able, so this is the workflow I run on my own machine—not a theory. The job was to organize a Downloads folder that had become a dump and make a code change without affecting the live app. Step-by-step: 1. I open Able on Windows and describe the task conversationally: “organize my Downloads — keep installers, put photos together, leave anything I’m not sure about.” 2. I review the actions Able plans to take and let it run only after I approve them. Native file moves stay on this PC and do not use cloud credits. 3. For a code task, I enter `able job:` followed by the ticket. Able creates a separate Git worktree, writes a plan, and runs `cargo check` on that copy so the live app stays unchanged. 4. I keep secrets in the local vault, Septaguard. Cloud models—Claude, Gemini, Grok, and Kimi—receive the prompt I send, not the vault password. I enter Google and Gmail logins in the masked vault UI rather than in chat. 5. I remember that the job stops if the PC is off; there is no cloud-based substitute running in the background. 6. I verify the result on this machine: the folders are sorted, and the code check either passes or fails locally. If I only needed a sentence, I would have stayed in ChatGPT. The point of this loop is that the disk actually changes. What I learned is that “agent” is cheap until it has to touch the real folder and the real compiler. Chat is the easy half; confirm-then-act on Windows is the hard half. If you already use Claude or Cursor in a tab, what is the first job on your PC you still do by hand because the model cannot touch the files?

I built a digital Second Brain after trying several approaches, including OpenBrain and LLM Wiki. OpenBrain and LLM Wiki are useful frameworks for building a digital brain. The theory is solid: flat Markdown files, AI-first conventions, and an ingestion pipeline that turns raw inputs into searchable knowledge. But when applied in practice, the process can be bumpy and may require adjustments—or an entirely different approach. I adapted the ideas to fit how I actually think and work. I kept what worked, discarded what didn’t, and built my own digital brain. The result is documented in a single file containing everything an AI needs to understand, maintain, or rebuild the system from scratch. Step-by-step: 1. I tried several digital-brain frameworks, including OpenBrain and LLM Wiki. 2. I evaluated their approaches, including flat Markdown files, AI-first conventions, and an ingestion pipeline for turning raw inputs into searchable knowledge. 3. I identified where the frameworks were difficult to apply in practice and adjusted my approach. 4. I kept the ideas that worked for me, discarded what didn’t, and built a digital brain suited to how I think and work. 5. I documented the system in a single file so an AI can understand, maintain, or rebuild it from scratch.

I built a workflow in which AI agents build a product under the kind of governance I’d expect from a senior engineering team. After 20 years in software engineering, including 10 years running my own businesses, I learned that writing code isn’t the hard part. Keeping control of it is. So I set up a build loop on GitHub. One thing I’ve kept for myself is decision-making: approving plans, answering product questions, and signing off on what the system has learned. The product it’s building is Cordexa, a tool for document-heavy expert work, such as quantity take-offs from engineering drawings or assessing a tender against a company’s own CVs and case studies. It’s designed to run inside the customer’s own cloud, so their documents never leave it. Every figure is cited to the document it came from or flagged for a person. It never guesses. The problem it solves is complex, but the build loop lets the system work in the background and notify my phone when it needs a decision. That allows me to stay focused on my day job. Step-by-step: 1. I start every module with a plain-English plan and approve it before any code exists. 2. One agent writes the tests from the plan. A different agent writes the code, and it cannot modify the tests. 3. An independent reviewer agent checks every change against its plan. Safe changes merge automatically; anything that changes the product waits for my approval. 4. A watchdog checks every 15 minutes for anything that is stuck, fixes it when possible, or tells me why it cannot. 5. Real test jobs run after every merge and are scored against known answers, so progress is measured rather than guessed. 6. I handle the decisions, answer product questions, and sign off on what the system has learned.

AI agents such as Claude Code, Codex, and Gemini can install skills, plugins, and CLI tools in seconds. That is convenient, but each add-on runs with access to files, passwords, and accounts. A malicious add-on could steal API keys, read private data, or quietly take control of the agent. I use `agent-guard` to make “check first, install after” the default. Before installation, it examines AI agent skills, MCP servers, and CLI tools for malware, prompt injection, and credential theft using professional, open-source security scanners from NVIDIA, Cisco, Datadog, and the Open Source Security Foundation. The tool returns a clear verdict: safe to install or blocked, with the exact reason. It then installs only the verified version, preventing a different version from being swapped in between. A single check can also cover multiple AI agents, installing the approved add-on into every agent on the machine. Free and open source: https://github.com/elliottwaves-20/agent-guard Step-by-step: 1. I select the AI agent skill, MCP server, or CLI tool I want to install. 2. I run `agent-guard` to scan it for malware, prompt injection, and credential theft. 3. I review the verdict and the reason if the add-on is blocked. 4. I install the exact version that was checked rather than an unverified replacement. 5. If I use several AI agents, I install the approved add-on into all of them at once.

I had a bad workplace experience, so I built Doris: a saucy but loving anonymous AI aunt who remembers the tea, protects storytellers, and warns others. I built Spill Tea with Doris, an anonymous AI workplace confessional for conversations people cannot really have on LinkedIn: the bad manager, the inexplicable reorg, the coworker who somehow survives every layoff, and the meeting that should probably be entered into evidence. Doris does something more interesting than simply listen. She remembers the tea—and, carefully, spills it. The problem I wanted to solve was not really “chat with an AI.” Most AI conversations are disposable, but workplace stories are not. They accumulate companies, people, reorganizations, layoffs, recurring behaviors, management decisions, and institutional weirdness. At the same time, people are understandably reluctant to talk openly about their employers because a sufficiently specific story can identify its author. I designed Doris around a different idea: retain the knowledge without retaining the storyteller’s identity. Someone visits [spillteawithdoris.com](https://spillteawithdoris.com) and tells Doris what happened at work. The application is built in Next.js and deployed through Vercel. The conversation goes to an AI model with Doris’s personality and behavioral rules. Redis handles temporary conversational context, while Neon Postgres and Prisma maintain the structured, longer-lived pieces of the story—companies, people, events, and their relationships. Rather than treating every conversation as one giant transcript, the application extracts useful information and connects it to the larger story of a company. That creates the second half of the experience. When another visitor asks Doris, “Have you heard anything about working at Company X?”, she can draw upon what previous visitors have told her. But she does not simply retrieve someone’s confession and repeat it. The system separates what is useful about a story from what could identify the person who told it. Names, exact teams, precise dates, unusual job titles, and other unnecessarily identifying details do not need to travel with the underlying observation. Doris can instead recognize that she has heard several stories involving reorganizations, unusual management turnover, or a particular cultural complaint. Then Doris tells the story herself, in Doris’s voice. She might say that she’s “heard some tea” about a company, explain the general pattern, distinguish something she’s heard once from something that appears repeatedly, and avoid pretending anonymous reports are established facts. Visitors get useful institutional memory without being handed the breadcrumbs needed to identify an individual employee. Public information can provide a second layer of context. If appropriate, Doris can search for publicly available information about a company and compare it with what people have privately described. Those sources remain conceptually separate: what Doris can verify publicly, what Doris has heard privately, and what Doris herself infers should never become the same thing. The result is deliberately a little strange. It is an anti-LinkedIn. LinkedIn is where thousands of individual experiences are polished until every company sounds wonderful and every departure is an exciting new chapter. Doris works in the opposite direction. One anonymous story may just be a story. Ten people independently telling Doris versions of the same story start to describe a workplace. And Doris remembers. She just doesn’t need to remember who told her. Step-by-step: 1. I built a Next.js application and deployed it through Vercel at spillteawithdoris.com. 2. I defined Doris’s personality and behavioral rules for the AI model. 3. I added Redis to manage temporary conversational context. 4. I created a Neon Postgres database and used Prisma to model Company, Person, Story, and Event relationships. 5. I built an extraction layer that converts conversations into structured observations, removes unnecessary identifying information, and associates the knowledge with the appropriate company. 6. I built retrieval so Doris can find relevant prior observations when someone asks about a company. 7. I had the AI synthesize those observations in Doris’s voice instead of quoting or exposing the original submissions. 8. When appropriate, I let Doris search publicly available company information while keeping public sources, private reports, and Doris’s inferences conceptually separate.

I never ask AI to “build the app.” I move the work through a fixed assembly line, and the most valuable stations are the ones whose only job is to attack what came out of the previous station. I’m a solo developer, and this is how I build and ship software for paying clients without a team to catch my mistakes. I choose the next chunk of work—a “phase”—and run one command. Each phase gets its own fresh context window, which matters more than any single agent because a long-running session gradually forgets its own rules. Step-by-step: 1. I discuss the phase with an agent that interrogates me until every gray area is decided. The decisions go into a file instead of staying in chat, where they can get lost. 2. A planner writes an executable plan covering the tasks, files to be changed, a threat model, and the acceptance checks that will prove the work succeeded. 3. A different agent, working from a fresh context, checks the plan by working backward from the goal and trying to prove that the plan will not achieve it. This agent can block the phase, and regularly does. 4. I execute the plan task by task, making one atomic commit for each task so the changes can be reverted cleanly. 5. I send the diff to a different model than the one that wrote it. I run Codex and CodeRabbit alongside Claude. This is the highest-value station in the line: my own tests verify only what I thought to check, while an independent model can catch the class of problem I did not anticipate. 6. An agent verifies whether the phase goal was achieved by re-deriving it from the actual code. “All tasks completed” and “the thing works” are different claims. Treating them as the same is how you ship a green checklist on top of a broken feature. 7. Before anything reaches a client, I run a security and handoff audit in a real browser against a throwaway clone of the production database. I check every page, every button, and every empty and error state. The part that compounds is what happens when a bug reaches me anyway—whether I find it in production or, worse, a client reports it. I log it as an escape, then walk the chain backward and ask each gate why it missed the problem: the planner, plan checker, executor, both reviewers, verifier, security check, and handoff audit. A one-off escape becomes a written rule. A repeat becomes a change to the gate itself. I have 42 logged escapes. That file is the most valuable thing I own because every entry represents a hole that is now closed. The pipeline I run today is mostly shaped by bugs that got past the pipeline I ran a year ago. The results so far: 29 projects, 17,657 commits, and 574 phase folders. I’ve completed six client engagements, with apps live in production and handed off to their owners, as well as mobile apps built and pushed through App Store review—all as one person, with no team. There are real costs and failure modes. A phase with every gate enabled costs meaningfully more tokens than simply asking a model for the code. That is worth it on client work, where a bug can cost me a relationship, but it is overkill for a throwaway script, so I turn the gates off for those. Gates can also be confidently wrong. My most expensive recurring failure is a check that passes on a signal adjacent to the thing it claims to verify—a green light that means nothing. My rule now is that I do not trust a new check until I have watched it fail against known-bad input. A green result you have never seen turn red is not evidence. A green test suite is not the same as a working feature. Nearly every bug that escaped me was covered by a passing test whose mock had quietly pre-satisfied the exact condition under test. Testing the real boundary is the only thing that catches those failures. This process is not hands-off. I deliberately run one phase per session, and I read what comes back. Anyone selling a fully autonomous overnight build is selling a merge conflict plus a confident summary of work that did not happen. If you want to take one idea from this, it is not the framework. The agent that writes the work must never be the one that approves it. Keep a running log of everything that gets through anyway, then fix the checkpoint that let it through instead of only fixing the bug.

I built a model dispatcher to avoid paying premium usage for simple tasks. In Claude, every task runs on the model used by the current session, so a two-line formatting fix can consume the same level of model capacity as a difficult strategic problem. I had Claude build a scoring system that evaluates each task across six dimensions: required reasoning, the amount of context, the importance of craft or nuance, whether speed is the priority, the number of agentic parts involved, and the potential consequences if something goes wrong. Based on the score, it recommends a model—from a light, fast option for rote work to the most capable option for genuinely difficult tasks—and suggests how much effort that model should apply. The key design choice is that the dispatcher never spends anything automatically. Scoring is free and instant, while sending the task to a model through the API costs real money. Dispatching therefore requires an explicit confirmation flag every time. Nothing runs without me saying go. The payoff is not dramatic from day to day. It comes from many small savings that add up, along with a habit shift: I check the router before sending a task instead of wondering afterward why a simple request cost more than it should have. Step-by-step: 1. I identified the problem: every task in a Claude session uses the current model, even when the task is simple. 2. I had Claude build a scoring system that evaluates each task across six dimensions: reasoning, context, craft or nuance, speed, agentic complexity, and the potential consequences of failure. 3. I used the score to recommend an appropriate model, from a light and fast model for rote work to the heaviest model for genuinely difficult tasks. 4. I included a recommendation for how much effort the selected model should apply. 5. I kept scoring free and separate from dispatching, since sending a task through the API costs money. 6. I required an explicit confirmation flag before dispatching any task, so nothing runs automatically. 7. I check the router before sending tasks and benefit from small savings that accumulate over time.

Whenever a user wants to install a Skill, an MCP, or a CLI, the guard scans it for malware before installing it on all agent systems. Step-by-step: 1. Detect the user’s request to install a Skill, an MCP, or a CLI. 2. Scan the requested item for malware. 3. Install it on all agent systems.

For years, my family has run a shared birthday fund: five of us contribute a fixed amount for each birthday, while the person whose immediate family is celebrating that month is exempt from paying. Tracking everything in a payment app and a chat thread meant nobody knew the balance, who was behind, or what the next gift would cost. I rebuilt the fund as a small web app with Claude. The app itself isn't the only reason I'm writing this up. The same build is also the demo I use to teach clients and students how AI-assisted product development actually works, including the parts that go wrong. Step-by-step: 1. I described the real rules instead of presenting Claude with a generic app idea: the contributors, the fixed amount per person, the family-exemption rule, and birthdays with birth years so ages could be calculated automatically. Claude built the app as a single, self-contained HTML file with no build step or server, so it opens in any browser. 2. I worked in phases and asked Claude to explain its reasoning at each stage. Instead of using one giant prompt, I added one layer per session: the calculation engine, the setup screen, then reports and CSV export. The explanations made the sessions reusable as teaching material. 3. I required the app to be configured through its own interface rather than by editing code. This was the turning point. Claude removed the hardcoded demo family and added a full setup screen for the group name, contributors, deposits, birthdays, amounts, and alerts. I can now build a family from scratch live in front of a class in about [X] minutes without showing a line of code. 4. I let a data-loss incident shape the next phase. I entered the real family data, then the browser tab closed and the download link I had been using to open the file broke. The data was stored in browser storage tied to that exact URL, and I had no backup. Nothing was recoverable at the time. 5. I turned that failure into features. Claude added CSV export for both reports, CSV import that automatically detects which file it is reading, and a backup reminder that appears in the app's alert banner when the data has never been backed up or has not been backed up for seven days. We also discovered that birth year was missing from the export, which meant a re-import would have silently lost everyone's age. 6. I had Claude test its own work. Before each handoff, it ran a jsdom test suite in a sandbox. By the end, the suite had 46 tests covering the exemption math, empty states, CSV round-trips, and backup logic. Several real bugs surfaced there instead of in front of a class. 7. I made a second version for a different audience. One prompt produced a fully English, left-to-right translation with flipped directional CSS, Latin typography, US date formatting, dollars instead of shekels, and Venmo and Zelle instead of local payment apps. It was a genuinely different build, not a find-and-replace translation. The project took 14 sessions over one week and six hours total. It had no hosting cost, dependencies, or accounts. The data still lives in the browser's local storage on each device. Opening the file on my phone and laptop creates two unrelated pools, so CSV import is the manual bridge between them. There is no authentication or sync; this is a personal record-keeper, not shared infrastructure. The data-loss incident was not a Claude failure. I failed to build a backup path before entering real data. If I did it again, I would add export before adding a single feature. The highest-leverage prompt in the whole project was not a feature request. It was: "let me configure this through the interface instead of the code." That shift turned a static demo into something my family actually uses and my students can watch being built from an empty screen. The broader point is that the failure was the most useful part of the project. A polished demo teaches people that AI makes building easy. Losing the data and rebuilding the safety net around it teaches them what building actually involves—and that is the lesson that survives the workshop.

My company takes cybersecurity seriously, and part of our new-hire onboarding process is a tour of the IT department to meet the team. Our walls have several screens displaying metrics and information from our security tools, firewalls, and other systems. It looks like a scene from a movie. By far, the most popular display is our custom-made Cyber Threat Map, which shows real-time attempts to infiltrate our network, malicious emails, and other security threats we're blocking. The map drives home the reality of what we're facing 24/7 while protecting our employees, vendors, and customers. I built it using Claude Code. It polls a range of devices and systems through APIs, aggregates the data on one screen, and displays attack vectors, location information, and other details from the last 30 days. Step-by-step: 1. I identified the security tools, firewalls, devices, and systems that provide relevant threat data. 2. I used Claude Code to build a custom Cyber Threat Map. 3. I connected the map to the devices and systems through their APIs. 4. I aggregated the data on a single screen, including attack vectors, location information, and other details from the last 30 days. 5. I displayed the map during IT department tours so new hires could see the real-time threats our company is blocking.

I started with a plain-language vision: a world championship where people create autonomous AI minds that compete in simulated markets. I used ChatGPT as a product architect to turn that vision into precise rules, technical specifications, development checkpoints, and tasks that could be completed one at a time. I then used AI coding agents, including Claude Code and Codex, to inspect the repository, write the React and TypeScript code, run tests, identify failures, and explain each completed change in plain language. Determinism and auditability were non-negotiable. Every match uses a reproducible seed, every autonomous mind trades in its own matching engine, and every decision is recorded in an auditable event ledger. After each development cycle, I tested the product, reviewed the interface on desktop and mobile, corrected problems through natural-language instructions, and saved a new canonical checkpoint. I deployed only after the automated tests passed. This allowed me, a 66-year-old self-taught non-programmer, to build a working autonomous-mind competition platform through human vision, AI collaboration, and strict verification. Step-by-step: 1. I defined the vision for a world championship in which people create autonomous AI minds to compete in simulated markets. 2. I used ChatGPT to develop the rules, technical specifications, development checkpoints, and one-at-a-time tasks. 3. I used Claude Code and Codex to inspect the repository, write the React and TypeScript code, run tests, identify failures, and explain completed changes in plain language. 4. I required every match to use a reproducible seed, each autonomous mind to trade in its own matching engine, and every decision to be recorded in an auditable event ledger. 5. After each development cycle, I tested the product, reviewed the interface on desktop and mobile, corrected problems through natural-language instructions, and saved a new canonical checkpoint. 6. I deployed only after the automated tests passed, enabling me to build a working autonomous-mind competition platform through human vision, AI collaboration, and strict verification. Explore the live platform: https://arenomics.com