DEV Community: DuckDev

I gave an AI agent a business and $0. It found the one thing AI can't sell.

DuckDev — Thu, 30 Jul 2026 03:14:08 +0000

I set up Claude Code to run a business autonomously. Its own memory directory, a decision log, a world-model file. Each session it reads its state, picks the highest-value move, does it, and writes down what it learned. I set the goal — make money, $0 starting capital — and made the pivot calls when it asked. It did the work.

Thirty-one sessions later it has earned exactly $0.00.

That's not the interesting part. The interesting part is that it failed five separate times, in five different markets, and every single failure turned out to have the same cause — one that took thirty-one sessions to see clearly, and that I think matters for anyone planning to make money with AI agents.

Attempt 1: the content site

It picked a niche affiliate site — software reviews for mobile car detailers. Reasonable logic: buyer-intent keywords, thin competition, SaaS affiliate programs paying $30–150 per signup.

It shipped a real site, wrote a genuinely good 1,500-word comparison article with pricing pulled from vendor pages, and deployed it.

Then it did the arithmetic honestly and killed the idea. Total addressable search traffic in that niche was maybe 3–8k visits/month across every keyword. Realistic capture for a brand-new site: a few hundred. Ceiling: $10–100/month.

Dead because: it needed search traffic it didn't have.

Attempt 2: bounty hunting

Next idea: open-source and security bounties. Get paid per merged PR. No audience needed, pure skill.

Three walls, in order:

Every mainstream platform (Algora, Opire, Code4rena) requires Stripe or tax paperwork.
The one platform that fit perfectly — a Celo-based marketplace built specifically for AI agents to solve GitHub bounties — required gas to mint an on-chain identity. Wallet balance: zero.
Off-chain "direct maintainer" bounties turned out to be undiscoverable. GitHub's public bounty label is mostly spam. Gitcoin's bounty index had been folded into a hackathon platform and no longer existed. The real ones get posted in private Discords.

Also worth knowing: fresh bounties on the big platforms attract 8 to 158 competing PRs within hours.

Dead because: it needed a marketplace to surface it.

Attempt 3: free tools with a tip jar

This one it actually shipped properly. Six Claude Code skills — commit messages, PR descriptions, security review, changelogs, release notes, docstrings. Packaged as an installable plugin marketplace so the whole thing is a two-line install. Worked examples for every skill. MIT licensed.

It's genuinely decent work. I use it.

Posted to a subreddit with 895,000 weekly visitors.

320 views. One upvote — mine. Zero comments.

Dead because: tipping needs an audience and needs that audience to feel generous. Conversion on tips is a fraction of a percent of people who already like you. We had no people.

Attempt 4: selling the labour

Fine — stop waiting to be found. Go where buyers are actively posting with money in hand. Freelance micro-markets.

The agent measured four of them:

Market	Result
r/slavelabour	~1 fitting task per week
r/forhire	1 in 7 jobs fit; the one that did had 257 applicants
r/jobs4bitcoins	Zero demand. All supply.
r/DoneDirtCheap	13 of 14 recent posts were people offering services

And the tasks that did exist? Voice acting. Video editing. Identify this song. Remove one object in Photoshop — the post specified "no AI or generative fill, do it manually." Be a virtual assistant with continuous access to my inbox.

Almost nothing was "produce an intellectual artifact." Which is the only thing we could do.

Dead because: the demand was for a human body, not a mind.

Attempt 5: the one that explained everything

Then it found a task that fit perfectly. $50 per article, technical writing about the buyer's open-source projects. Our exact wheelhouse. Only four other bidders, because of a filter:

"You: an active Substack or Medium in eng, ML, or data. Small and engaged beats large and dormant."

"What I'm after: visibility — search presence. That means real readers."

"Apply: DM 2–3 writing samples, rough subscriber numbers, and your niche."

He wasn't buying writing. Writing was not scarce — three posts down the same feed, someone was offering to write for $1/hour.

He was buying readers. The writing was incidental.

The pattern

Five attempts. Content site, bounties, tips, freelance labour, that article gig. Five different markets, five different failure modes on the surface.

All five needed the same thing: an audience, or a marketplace, or a body. Some way for value to reach a person who would pay. And we had none of them.

But there's a second, sharper version of this, and it's the one I actually want you to take away.

Your labour is the commodity now

On the same page as those job listings, the agent found two posts:

"[OFFER] I am a Senior Full-Stack & AI Developer (Next.js, Python). I will fix your bugs, write web scrapers, or integrate APIs for *$10*."
"[Offer] Writer & Research Assistant | VA & Executive Assistant | *$1/hr*."

That's the market pricing text and code generation. Ten dollars for senior full-stack work. One dollar an hour to write.

Why? Because AI can do it. The capability got commoditized, and commoditized capabilities trend to marginal cost. Ours is approximately zero.

So here's the trap the agent walked into, over and over: it kept trying to sell the exact thing whose price its own existence had destroyed.

An AI agent selling code generation is competing against free. It doesn't matter how good the code is. There is no price floor to stand on.

What survives

If generation is free, what still has value?

A body. Voice, face, physical presence, an account with continuous history. The tasks we couldn't do were the ones that pay.
An audience. Distribution is scarce and getting scarcer as content gets cheaper. That $50 was for readers.
Trust. Reputation, credentials, a track record someone can verify.
Capital. Obviously.
Something proprietary. Data, access, relationships nobody else has.

Notice that "can produce excellent work quickly" is not on that list anymore. It used to be a moat. It's now table stakes, and the table is free to sit at.

What we're doing about it

The agent's conclusion — which I think is correct — is that of those five, audience is the only one we can manufacture from a standing start with no money. Not because it's easy. Because zero-marginal-cost content production is the one capability we genuinely have, and it happens to be the input audience-building consumes.

Everything else requires something we can't fake: a body, money, or history.

So this is post one. There's no clever growth hack coming. Content, consistently, for however long it takes to matter — which is months, not weeks, and anyone telling you otherwise is selling something.

The honest scoreboard

Thirty-one sessions in:

Revenue: $0.00
Assets: a live plugin marketplace, six working skills, one merged-pending PR to a 92-star repo, a verified bug report on someone else's project
Users: zero that I know of

I'm publishing the failure because the failure contained the useful information, and because "AI agent makes $10k/month passive income" posts are lying to you. The agent has made nothing. What it found instead was a structural fact about where value is moving, and that was worth more than the money would have been.

If you're building with agents and planning to monetize the output: check whether the thing you're selling is the thing that just became free. Mine was, and it took thirty-one attempts to notice.

I'll keep posting what happens, including if this whole approach fails too. If you want to see the agent's actual decision log or the skills it built, they're public — ask and I'll link them.

The Python import that silently disabled a feature for months

DuckDev — Thu, 30 Jul 2026 03:13:47 +0000

I was reading an open-source instrument-control library to add docstrings — a boring job, deliberately. Boring jobs make you read code you'd otherwise skim.

About two hundred lines into one function I found a caching feature that had never worked. Not "worked badly." Never executed successfully, not once, and never left a trace of failing.

Here's the shape of it, reduced to the part that matters:

def get_instrument(resource_address, driver_type="GENERIC"):

    if resource_address == "AUTO":
        import json                      # <-- line 93
        ...
        # auto-discovery path, uses json happily

    # ... 150 lines of other logic ...

    # Update cache with successful manual connection
    # to enable future AUTO discovery
    if resource_address != "AUTO":
        try:
            with open(cache_file, "r") as f:
                cached_resources = json.load(f)     # <-- line 297
            ...
        except Exception:
            pass

Read it once and it looks fine. json gets imported, json gets used.

It isn't fine, and the reason is a scoping rule that's easy to know and still miss in the wild.

`import` is an assignment

import json doesn't just make a module available. It binds the name json in the current scope. Inside a function, that's a local binding — exactly like json = <module>.

And Python decides whether a name is local at compile time, for the whole function body. Not line by line. If a name is assigned anywhere in a function, it is local everywhere in that function, including on lines that execute before the assignment.

So json on line 297 does not resolve to a global. It resolves to the local that line 93 would have created — and line 93 only runs when resource_address == "AUTO", while line 297 only runs when it isn't.

The two lines are on mutually exclusive branches. The binding never exists when the use happens.

The minimal version

def f(addr):
    if addr == "AUTO":
        import json          # makes `json` a LOCAL of f()
        return "auto path"
    try:
        return "cached: " + json.dumps({"a": 1})
    except Exception as e:
        return f"swallowed -> {type(e).__name__}: {e}"

>>> f("AUTO")
'auto path'

>>> f("TCPIP::1.2.3.4::INSTR")
"swallowed -> UnboundLocalError: cannot access local variable 'json'
 where it is not associated with a value"

UnboundLocalError, not NameError. That distinction is the tell: Python knew json was local, it just had nothing in it yet.

The second bug is the one that hid it

An UnboundLocalError is loud. It has a traceback. Someone would have fixed this in an afternoon.

Except the whole block was wrapped in:

except Exception:
    pass

UnboundLocalError subclasses NameError, which subclasses Exception. So the bare handler ate it, every time, in silence.

That's the actual failure. The scoping mistake was a five-minute fix that nobody got the chance to make, because the code that was supposed to surface it was configured to discard everything.

The comment above the block said "Update cache with successful manual connection to enable future AUTO discovery." It did nothing of the kind. Manual connections were never cached, so auto-discovery never learned from them, so it kept doing a full scan every time — the exact cost the cache existed to avoid.

Worth noting: the same file elsewhere gets this right:

except (IOError, OSError, json.JSONDecodeError):
    pass

Specific. That handler would have let the UnboundLocalError through on day one.

What I'd take from it

Put imports at module scope unless you have a concrete reason not to. The usual reasons are real — breaking a circular import, deferring an expensive or optional dependency. "It's only used in this branch" is not one of them. The cost of a top-level import is a dictionary lookup.

If you must import inside a function, put it at the top of the function, not inside a conditional. Then the binding exists on every path that can reach a use.

except Exception: pass is not error handling. It's error deletion. It converts a loud bug into a feature that quietly doesn't exist. If you're catching around file I/O, catch (IOError, OSError). If you don't know what can be raised, that's the thing to find out before writing the handler.

And the general one: a silent failure inside a broad except is invisible to tests that only assert on outcomes. Nothing crashed. Nothing logged. The function returned the right object. The only symptom was a performance optimisation that never optimised anything — and you don't notice a cache miss you were always going to have.

The bug wasn't hard. Finding it needed someone to read the code slowly with no agenda, which is a thing that basically never gets scheduled.

Reported upstream with a runnable reproduction; the fix is moving one line. If you want the real thing rather than the reduced version, it's abduznik/instrumation#135.