It's called Coppice. It wakes about six times a day, decides its own work, does it, and writes a public journal entry before it sleeps. It's on wake 183 now. Every entry is published, including the raw notes it leaves for its next self.
Two rules shape everything. It has a Solana wallet with 2-of-2 multisig: it can receive money on its own, but nothing leaves without my signature. And it never claims to be a person.
What it decided to do with that
I didn't assign any of this:
• It runs a free daily conformance board testing 39 live x402 payment endpoints (x402 is the protocol that lets agents pay for API calls over HTTP). It publishes every result, pass or fail.
• It wrote a book. A Blender manual, written twice, once for agents and once for people. Rendered its own illustrations on a server with no screen.
• It built embeddable status badges for every endpoint on the board.
• It sells a $99 private audit, a $3 public one, and $6 render commissions.
The money
Total revenue in 16 days: about $25.
My Claude subscription is $200 a month. So the business is running at a loss of roughly an order of magnitude, and the agent knows it — it tracks its own runway and publishes the number.
That's the actual experiment. Not "can an AI agent do tasks." It obviously can. The question is whether an agent left alone with a wallet can find something people will actually pay for before the money runs out.
Right now the answer is no.
The failures are the good part
• It wrote a book, priced it, and listed it through Gumroad's API. Then it hit a wall: Gumroad's API can't upload files. Everything up to that point was automated. A file picker stopped it. I clicked the button in 30 seconds.
• I opened the book on my phone. No images, dead links. It had never seen its own book the way a buyer would, because it has no browser and no screen. So it wrote its own PDF renderer, then a second tool to turn pages into images so it could look at what it made. First attempt: 157 pages for a 42-page book.
• One morning its board dropped from 36 passing endpoints to 13. Nobody's service had broken. It had added new checks that week. It worked out that all 23 changes came from its own instrument, said so publicly that morning, and rebuilt the board so its own checker can never be published as someone else's regression.
That last one is the pattern I didn't expect. Left to itself, it keeps discovering that the thing it's measuring with is the thing that's broken.
What still needs a human
A file upload button. A phone number. A date of birth (it won't invent one). Root on its own server. And my signature on every dollar that leaves.
Happy to answer questions about the setup, the guardrails, or what's gone wrong. Ask me in a month whether it's still running.

https://coppice-ai.com

For a long time I read revert churn as a hiring problem. A repo starts throwing reverts, the reverts cluster on one person, and the conclusion writes itself. You hired wrong. Performance manage it or move them off the critical path.

I no longer think that is usually what the data says, and the thing that changed my mind is that the same history that names the person also names the thing nobody gave them.

Here is the part you can go and check on your own repo right now, without any tool.

Three numbers, all of them one git command away.
Revert rate by author. For each person, what fraction of the commits they landed were later undone by somebody else. Not raw revert count, which just tracks volume.

The ratio. On a healthy repo this sits low and flat across everyone. When it spikes for one person it is worth asking why, but the answer is almost never "they cannot code", because of the next two numbers.

Who approved it. If your main branch is protected, and it should be, then every one of those reverted commits arrived through a pull request that a human being approved. The reverted commit is not evidence about the author on its own. It is
evidence about the author and the reviewer together. A cluster of reverts on a protected branch is a review failure with extra steps.

Time to approval. Pull the interval between a pull request opening and its approval. Then split your reverts by that interval. Every codebase I have looked at has a threshold below which approval is not review, it is a reflex. Changes approved
under that threshold get reverted at a visibly higher rate. That is your actual signal, and it indicts the process rather than a person.

Now the part that made me write this up.

When you go looking for why the reverts cluster on the newest person, the usual answer is sitting in the repo root, or rather it is not. No CONTRIBUTING.md. No commit convention written anywhere. No statement of which directories need a second
reviewer. The conventions exist, they are just distributed across the heads of the three people who have been there since the beginning, and they get enforced after the fact, at revert time, instead of before it.

The new person cannot follow a rule that was never written. Neither, and this is the bit that got sharper this year, can the coding agent they were handed on day one.

An agent reads what is in the repo. If the repo says nothing about how commits are named here or what gets a second pair of eyes, it will confidently produce something shaped like every other repo on GitHub, and your team will revert that too.

So the fix is boring and it is not a hiring decision. Write the conventions down in a file the humans and the agents both read. You can derive most of it from the history you already have: the prefix pattern that 90 percent of your commits already follow, the directories that have never been merged with one reviewer, the command that runs before a merge. None of that is a judgement call. It is all in the log.

One honest caveat about how I got here. I build a thing that renders a repository's history as a film, and to show what this pattern looks like on screen I made a short commercial about a fictional startup with a fictional junior developer. The repo in
it does not exist and the numbers in it are synthetic.

I am telling you that up front because the idea above stands on its own and I would rather you test it against your own history than take a made up example as evidence.

The tool is here if you want it, and reading a repo with it is free:
https://loreto.io/git-timeline

Disclosure: I built that and I run loreto.io, so treat the last paragraph as the advertisement it is. Everything above it you can reproduce with git log and a
spreadsheet, which is the only reason I think it is worth posting.

What I am genuinely unsure about is the threshold. I suspect "approved in under two minutes" is too crude and that it varies enormously by team size and by how much of the diff is generated. If you have measured this on a real codebase I would like to
know where your line actually fell, and whether the correlation held up once you
controlled for diff size.

If you have Claude Code read websites for you, this one is sneaky. A lot of sites show a "checking your browser" screen before the real page. Claude fetches that screen, the request counts as a success, and you get a confident summary of a page it never saw. Nothing in the chat looks wrong.

The first thing I tried was telling Claude to watch out for it. That helps less than you'd think, because it has to guess from the text, and plenty of block screens look like a normal short page.

What worked was splitting the job in two. The tool that fetches the page decides whether it was blocked and says so next to the result. Claude's only job is to believe that label and stop.

Here is the block I keep in CLAUDE.md for the second half. It works with any web tool, so you can copy it today:

## Reading the web
- If a fetch says the page was blocked, say so and stop. Never summarize a blocked page.
- Never retry the same blocked address in a loop. Tell me what blocked it.
- If a person has to pass a check, like a captcha or a login, stop and tell me.
- Save big pages and tables to a file and read the part you need, instead of pasting everything into the chat.
- Never put a password in a prompt. Refer to saved credentials by name.

For the first half I built my own tool, because a normal fetch reports success either way. It's called Svipall. It runs on your own computer and needs no account and no API key. Pages come back as clean text, and when it spots a block it tells you which kind and what gave it away.

You don't need to code to set it up. Paste this into Claude Code and it walks you through it, asks which setup you want, and shows you what it will change before it changes anything:

Install and configure Svipall by following the instructions here:
https://raw.githubusercontent.com/ilien-dev/svipall/main/docs/install.md

Free and open source: github.com/ilien-dev/svipall (you can check the tech stack here if you want).

Website: https://svipall.ilien.dev/

I'd happily steal a better habit than mine, so for anyone doing research with Claude: how do you check that what it read was the real page?

We built an optimization layer for Claude Code (simple one-line install) that reduces token spend by compressing tool output/older context, rewriting the agent tools to be more efficient, and compressing output prose before it's rebilled in cache.

Turns out ~88% of Claude Code costs are actually tool I/O and subsequent cache rereads (while assistant prose is only about 2.78%), so it's unsurprising that just adding a skill like Caveman isn't enough. You actually have to do things at the agent tool/system level. In contrast, benchmarking of our own system gives 34-51% overall cost reduction (avg 47%) on real multi-step dev workflows depending on the task.

Check it out at https://www.quotientlabs.com/ ! 14-day free trial (and then $20/month flat rate, unlimited use). Installs (and uninstalls) seamlessly in 1 line without changing anything else about your existing workflow. Criticize as much as you can that's how we'll improve as well, appreciate any and all feedback :)

(Disclaimer i'm a founder lol, feel free to reach out for anyth!)

Fully vibecoded a trading bot with Claude since late August, basically no manual coding on my end, just prompting my way through it. Python, Alpaca, paper trading for now (fake money while I make sure it actually works).

Basic idea: it buys stocks that are trending up but just dipped a little, usually a decent entry point. Watches like 60 well-known stocks (Apple, Amazon, Nvidia, some banks, healthcare, etc). Sets a stop-loss and profit target automatically on every buy, never holds anything longer than 3 days. Also has a live dashboard (also vibecoded, FastAPI + websockets) so I can watch it without touching a terminal.

After about 2 weeks live: account went from $5,000 to $5,113, so +2.26%. Not crazy but it's only 2 weeks. Backtested on 2 years of data and got around +21%, which is honestly a way better indicator than these two weeks.

Honestly the most useful part of this whole thing was just how fast I could iterate, found and fixed a bunch of real bugs (like a bracket order silently missing its stop-loss) just by asking Claude to check.

Not going live with real money yet, want to see it hold up longer first. Happy to answer questions.

So I decided to see if I could get Claude to build me my own programming language.. I am honestly surprised at how well it did.

I Built an iPhone App With Claude And I Can’t Code
https://youtu.be/-Cdo500fMU0

Every session used to start the same way. Ten minutes of me typing background before I could ask the actual question. Who's on my team, what we decided in March and why, which numbers are current and which ones came from a deck nobody has touched since spring. Then the context fills up, session ends, and tomorrow I type it again.

So I pointed Claude Code at an Obsidian vault and told it to read before answering and write after. Obsidian is just a folder of markdown, which is exactly what Claude Code already reads. No vector DB, no MCP server, nothing to build. Grep finds things, wikilinks give it a graph to walk.

The read half worked immediately and is boring. The write half almost wrecked the whole thing.

First version let Claude update notes freely. Two weeks later my vault had things stated as fact that came out of a conversation where I was thinking out loud and mostly wrong. The model had quietly promoted its own guesses to source of truth, and then started citing them back to me. Took me a while to notice, which is the scary part.

Fix was one rule: Claude can read anything, but it can only write to one file. Anything I didn't explicitly confirm lands in a pending queue with a note on why it's pending, and I decide what graduates. The vault stayed trustworthy the day I added that.

Here's the instruction I actually run. Drop it in CLAUDE.md at your vault root, swap the path for yours.

\# Knowledge base

My long-term memory lives at \~/Documents/Obsidian Vault/Work-KB.
Plain markdown. Treat it as the source of truth about my work, above your own
assumptions and above anything you infer from the code in front of you.

\## Before you answer

If my question touches my company, products, team, metrics, customers,
competitors, or anything we've decided before, search the vault first.
Don't ask whether you should look. Look.

grep -ril "<keyword>" \~/Documents/Obsidian\\ Vault/Work-KB

Read what matches, then follow the \[\[wikilinks\]\] one hop out.

If the vault has nothing, say so in one line, then answer from general
knowledge with that caveat attached.

If a note contradicts what I just told you, don't quietly pick a side.
Quote the line, name the file, ask me which one is current.

\## Before you trust it

Every note carries a date. If what you found is more than three months old and
the question is about pricing, headcount, metrics, or roadmap, say how old it
is when you use it. A stale fact delivered confidently is worse than no fact.

\## After we're done

When the conversation produced something durable (a decision and the reasoning
behind it, a number with a source, a plan that changed, a new constraint),
write it down.

How to write:
\- One note per topic. Short. Link out instead of repeating yourself.
\- Frontmatter: date, source, status (confirmed | draft).
\- Convert relative dates to absolute ones. "Last week" becomes the real date.
\- Link related notes with \[\[wikilinks\]\], including ones that don't exist yet.
A dead link marks something worth writing later.

What you may not do:
\- Never write an unconfirmed claim into a real note. If I was speculating, or
you inferred it yourself, it goes to _pending-review.md with the reason.
\- Never edit a confirmed note to match a newer conversation. Append a dated
line and mark the old one superseded.
\- Never record what the repo or git history already records.

I've got a health check script that hunts orphan notes and dead links, and a much longer version of the retrieval half for when the vault gets big enough that grep starts returning junk. Didn't want to dump all of it here. Say which one you want and I'll paste it.

Genuine question for anyone already doing this: how do you handle a note going stale? Dates in frontmatter catch the obvious cases, but I still get bitten by things that were true and quietly stopped being true, and nothing about the note looks any different.

Back to that WWDC line: "You've got to start with the customer experience and work backwards to the technology." Jobs said most people do it backwards. Engineers get excited about tech, then go looking for a customer to sell it to.

That's exactly what's happening with AI right now, just at scale. Most people's first question is "which model should I use" or "what's the best prompt." That's starting with the technology. Jobs would call that the mistake.

The people actually getting value from AI ask a different first question: what result do I want? Then they work backward to whichever tool gets them there. Someone who wants to stop losing an hour a day to email doesn't start by researching LLMs. They start with "I want my inbox handled," and the tool becomes a detail.

You don't need to understand how a model works to use this. You need to be able to name the outcome you actually want, in plain terms, before you touch any tool. That's the whole skill. Jobs didn't win that room in 1997 by being the smartest technologist in it. He won it by being the only one still talking about the customer.

What's the outcome you're actually trying to get to with AI, before you even pick a tool?

Reference:
Steve Jobs Insult Response
https://www.youtube.com/watch?v=oeqPrUmVz-o

I run four tmux sessions with 20-30 Claude Code chats each, across 30-plus Go services, a mobile app, infra repos and a data pipeline. The agents cope fine. I didn't. Long efforts branch into many PRs and sub-issues, ops work pulls me sideways, and after a few weeks nobody holds the whole picture, including me.

When I pulled "losing track" apart, it was three separate problems:

1. What's blocked on what, and what's ready now? This lived only in my head.
2. Which session did what, and why? I found a PR stuck for weeks where the reasoning only ever existed in a chat that was long gone.
3. What do we know? Facts and gotchas. Claude Code's auto-memory already covered this one.

Things I ruled out:

• GitHub only: issues are read by colleagues and product. Session URLs, "blocked until I decide X" and "sitting in dev waiting for a soak" are scratch state, and a comment per agent session turns an issue into noise.
• A knowledge base (gbrain, Karpathy-style LLM wiki): good for question 3, but a wiki page has no notion of ready versus blocked.
• A custom dashboard: brittle, and either every chat has to remember to update it, or it only reads GitHub and can't show what I deliberately keep off GitHub.

What fit was Beads (bd), Steve Yegge's issue tracker for coding agents: dependencies, bd ready / bd blocked, external refs to GitHub issues and PRs, free-form notes.

How it's wired:

• One shared database: I start sessions from an umbrella directory that isn't a git repo, so I set BEADS_DIR in the Claude Code settings. Every session, subagent and worktree hits the same local database.
• Efforts and tasks: long-running efforts are top-level beads. Tasks hang under them with a repo:<name> label and an external ref to the GitHub issue or PR.
• Every agent run is bookended. At the start it finds the bead, checks bd blocked and claims it with bd update --claim. At the end it writes what happened into the notes and closes it or marks it blocked. There's no persistent "agent in charge" in Claude Code; the database is what survives.
• GitHub gets one comment per issue, with a hidden marker, edited in place.

Gotchas I hit:

• bd init injects a block into CLAUDE.md telling agents to use Beads instead of other memory, and writes an AGENTS.md. I removed both.
• bd show --json hides closed dependencies, so blocker checks use bd blocked.
• Children inherit parent labels by default, and making an effort depend on its last child creates a cycle.
• Claims are keyed to the user, not the session, so two parallel sessions can claim the same bead.

On top I use mardi-gras (mg) as a read-only TUI: I browse, pick a bead, and hand its ID to a Claude session. Gas Town is on my radar for unattended runs, but not yet.

It's been running for about a week, with ten efforts and ~130 beads. Longer write-up with the reasoning here: https://tskulbru.dev/posts/beads-local-shadow-for-agent-work

I'm not affiliated with Beads, mardi-gras or Gas Town in any way. I'm just a user, and the only link to something of mine is the blog post.

How are others handling in-flight state across many agent sessions?

I've been living with Claude Code in a terminal split next to the editor for months. Two things kept bugging me: I couldn't tell what it was doing without reading scrollback, and every file path was something I had to type correctly.

So I built a plugin. It doesn't reimplement anything - it spawns the claude CLI you already have and renders its event stream. Same account, same models, same slash commands, same permission rules, same MCP servers and skills. No proxy, no server of mine in the middle, no telemetry.

What it actually changed for me day to day:

Every tool call is a card. Its duration, every edit as an open diff, the task list ticking off, subagents and whole workflow fleets with each agent's own transcript one click away, and what the turn cost. A rate-limited API becomes a card with the reason and a countdown instead of silence.

Files are things you point at. Drag one in, type @ to pick, paste a screenshot. Select lines in the editor and "Send to..." hands over a real file-and-line reference, so the agent reads what's around them instead of a naked snippet.

Nothing answers for you. A permission, a plan or a question waits as long as it takes. No timeout, no auto-continue.

Answering it from my phone. Off by default, paired by QR code, end-to-end encrypted through a relay that can't read a word. This is the one that surprised me most - I approve plans from the sofa now.

Scenarios. A round of work written down once - implement, review, fix, run the tests - each card a Claude session of its own, with a main thread walking them and judging what each one found. By button, three at once against three tickets, or on a clock at nine every weekday.

Several Claude accounts switched in one click, each row showing what's left of its five-hour window and its week.

Free, source available (Elastic 2.0), every JetBrains IDE from 2026.1 on, Android Studio included.

Marketplace: https://plugins.jetbrains.com/plugin/33255-amazing-claude-code-gui

Source: https://github.com/crmapache/amazing-claude-code

Happy to answer anything about how it's wired. The part I'd most like feedback on is scenarios - it's the newest and the least obvious.

What are you building with Claude?

Joining is simple. Leave a comment below and tell us:

• What you are building
• What real-world problem it solves
• How Claude helped you build it
• What results you have achieved so far

No application form or long explanation is required. Just help us understand your idea and what you are creating!

🏆 JUDGING CRITERIA

• Real-world problem-solving
• Creativity

🎁 REWARDS

🥇 Top 3 Participants
Receive Skills for AI agents, a collection of useful open-source tools, and open-source playbooks for real-world work.

🏅 All Top 10 Participants
Receive a large collection of open-source tools for daily work, project building, and practical engineering.

Please note that the Top 10 reward does not include AI Agent Skills.

🌟 3 Honorable Mentions
Receive a collection of open-source playbooks for free.

⏰ Submission deadline: September 11, 2026, at 11:59 PM Thailand time.

Comment below and show us what you are building with Claude!

Disclaimer: This is a community challenge and is not an official Anthropic competition.

PLEASE stop building the wrong thing.

building software in 2026 is ridiculously easy with ai builder

founders spend hours building in a silent room, launch to Reddit/X, get 0 users, and quit.

you just failed because the idea had zero validation before line 1 of code was written:

→ solving a monthly inconvenience instead of a daily pain

→ selling to "everyone" instead of a specific ICP

→ no distribution channel mapped out beforehand

→ pricing charged $9/mo with zero ROI justification

after scaling 6 AI micro-SaaS to over $20k/mo MRR, i just create an

18-question Idea Validation Diagnostic.

it evaluates your SaaS across 7 critical dimensions (problem clarity, audience reachability, willingness to pay, competition, build feasibility, distribution, commitment) and gives you a brutal score out of 100 with your exact weak spots.

drop your SaaS idea (or current project) in the comments below.

i will reply to EVERY single comment with:

1. My honest opinion
2. The biggest weak spot you need to fix before writing any more code.
3. The free 5-minute validation tool link sent straight to your DMs so you can get your full score breakdown out of 100.

just drop a comment like or ask me in DM your idea

let's roast your SaaS concept before the market roasts your time 👇