DEV Community

Wilson Xu
Wilson Xu

Posted on

Building in Public: 53 Tools, 81 Articles, and 165 AI Agents in One Session

#webdev #productivity #career #opensource

Building in Public: 53 Tools, 81 Articles, and 165 AI Agents in One Session

The most honest post-mortem of an AI-powered autonomous development marathon you'll ever read.

I spent two consecutive sessions -- roughly 20 hours of wall-clock time -- running an autonomous AI agent pipeline that built, published, pitched, and submitted at industrial scale. The numbers look impressive on paper: 53 CLI tools compiled, 81 articles written, 24 npm packages published, 40+ publication pitches submitted, 52 Dev.to posts published, and over 165 parallel AI agents spawned.

The revenue generated? Zero dollars.

This is the story of what happened, what I learned, and why I'm sharing it with radical transparency. If you're a developer thinking about AI-powered productivity, autonomous agents, or building in public, this post is meant to save you months of experimentation.

The Setup: Claude Code as an Autonomous Factory

The architecture is straightforward in concept, deranged in execution.

I use Claude Code -- Anthropic's CLI tool for Claude -- as the orchestration layer. The system is configured to maintain six parallel agents at all times, each assigned a role:

  1. Bounty Hunter -- Scans GitHub for open-source bounties on Expensify, Cal.com, AsyncAPI, tscircuit, Twenty CRM, and other projects. Reads issues, writes proposals, submits them via the gh CLI.
  2. Article Factory -- Writes technical articles in the 2,000-4,000 word range, targeting paid publications.
  3. Tool Publisher -- Scaffolds TypeScript CLI tools, writes the code, runs tests, publishes to npm.
  4. PR Checker -- Monitors open pull requests, responds to reviewer comments, pushes fixes.
  5. Revenue Tracker -- Maintains a revenue.json file tracking every submission, every proposal, every status update.
  6. Article Submitter -- Takes completed articles and submits them to publications via API calls, form submissions, and browser automation (Playwright MCP).

When any agent completes its task, a replacement spawns immediately. The system never sleeps. It just keeps building.

The agents share a filesystem (~/.openclaw/) where everything lands: articles as markdown files, tools as npm project directories, revenue tracking as JSON, submission logs as plaintext. It's crude. It works. It scales.

The Scale Achieved

Let me break down the raw numbers across the two sessions (March 19-20, 2026):

Tools Built:

  • 53 CLI tools scaffolded and compiled in TypeScript
  • 24 successfully published to npm under the chengyixu account
  • 8 stuck in npm rate-limit purgatory (turns out publishing 16 packages in one hour triggers rate limiting that persists for hours)
  • 4 listed on Gumroad at $10-$15 each

Articles Written:

  • 81 technical articles, totaling approximately 200,000 words
  • Topics spanning CLI development, Node.js patterns, TypeScript tips, npm publishing, DevOps tooling, AI integration, and open-source monetization
  • Average article length: ~2,500 words

Articles Published:

  • 52 articles published to Dev.to (up from 12 to 52 in a single session)
  • 12 articles published to Hashnode

Publication Pitches:

  • 40 pitches submitted to Smashing Magazine ($250-400/article if accepted)
  • 14 pitches submitted to SitePoint
  • 1 pitch to CSS-Tricks
  • 1 application to freeCodeCamp
  • 1 paid article proposal to Galaxy Community Writers ($60)

Bounty Proposals:

  • 12 Expensify proposals (all lost -- too slow or duplicate)
  • 5 Cal.com proposals ($25-$200 each)
  • 3 Twenty CRM proposals
  • 4 tscircuit/Algora proposals ($30-$300 each)
  • 3 Databuddy proposals ($15 each)
  • 2 AsyncAPI contributions (PRs open, CI passing)
  • 1 OpenUI proposal (Svelte renderer)
  • 1 Formbricks PR (blocked on CLA signing)

Agent Activity:

  • 165+ agents spawned across both sessions
  • Peak concurrency: 19 agents running simultaneously
  • Agent roles: bounty-hunter, article-factory, tool-publisher, pr-checker, revenue-tracker, article-submitter

The Agent Architecture: How 165 Parallel Agents Worked

The system uses Claude Code's sub-agent capability. Each agent is a sandboxed Claude instance with access to the filesystem, the gh CLI, npm, and Playwright for browser automation.

The good parts:

Agents are genuinely parallel. While one agent writes an article about Node.js streams, another is scaffolding a CLI tool, a third is submitting a bounty proposal, and a fourth is checking PR statuses. The throughput multiplication is real.

Each agent has context isolation. The bounty hunter doesn't need to know about articles. The tool publisher doesn't care about bounties. They share the filesystem but not conversation state.

The bad parts:

Browser contention is brutal. Multiple agents fighting for the same Playwright browser tab creates chaos -- one agent navigates to Dev.to while another tries to submit a Smashing Magazine pitch. The browser just thrashes. The fix? Serialize all browser-dependent agents. Only one touches the browser at a time. This was learned the hard way.

Rate limiting compounds. When you have 6 agents all trying to publish npm packages simultaneously, you hit rate limits faster than any human would. Same with Dev.to's API -- roughly 2 articles per 5-minute window, and failed attempts reset the cooldown timer.

Error recovery is fragile. When an agent fails (API timeout, rate limit, form validation error), it often can't recover gracefully. It either retries blindly or gives up. There's no sophisticated retry-with-backoff built into the agent architecture.

The ugly truth:

Most of the 165 agents did marginal work. The real value came from maybe 20-30 agents that produced genuinely useful output. The rest were doing things like "check if npm rate limit has cleared" (it hadn't) or "try another Expensify bounty" (already assigned) or "pitch another article to Smashing Magazine" (the 37th pitch is not 37x more likely to convert than the 3rd).

Tool Highlights: The 5 Most Genuinely Useful Tools

Out of 53 tools built, here are the ones I'd actually recommend to other developers:

1. websnap-reader -- Takes a URL and returns clean, readable text content. Strips HTML, handles JavaScript-rendered pages, outputs markdown. Published as v1.0.1 on npm. Genuinely useful for LLM pipelines that need to ingest web content.

2. depcheck-ai (@chengyixu/depcheck-ai) -- Scans a project's dependencies and flags outdated packages, security vulnerabilities, and unused dependencies. Wraps npm-audit with better formatting and actionable output. The AI-generated code here was surprisingly clean.

3. gitpulse (@chengyixu/gitpulse) -- Analyzes a git repository's commit history and generates contribution statistics, activity heatmaps, and contributor breakdowns. Useful for open-source maintainers writing annual reports.

4. envcheck-cli (@chengyixu/envcheck-cli) -- Scans a project for required environment variables, cross-references them against .env files, and reports what's missing. Solves the "it works on my machine" problem for onboarding.

5. repocard-cli -- Generates beautiful README badges and repository summary cards from a GitHub repo URL. One command, instant repo card. Scratches a real itch for open-source maintainers.

The other 48 tools range from "marginally useful" to "why does this exist." That's the honest assessment. When you're building at speed, most of what you produce is filler.

Article Highlights: The 5 Most Publishable Pieces

Out of 81 articles, these are the ones with genuine editorial value:

1. "How I Built an AI-Powered Bounty Hunting System" -- A 3,000-word deep dive into using autonomous agents to find and solve GitHub bounties. Published on Dev.to with solid engagement. This one has narrative tension because the system mostly failed, which makes it interesting.

2. "Building a Web Performance Monitoring CLI with Node.js and Lighthouse" -- Step-by-step tutorial with real code. Published on Dev.to and pitched to Smashing Magazine. The kind of article that actually teaches something.

3. "Building a Zero-Config Development Environment Scanner with Node.js" -- Practical problem, practical solution. The code examples are clean and the use case resonates with anyone who's onboarded onto a new project.

4. "The Ultimate Guide to Publishing npm Packages in 2026" -- Born from real experience (publishing 24 packages in two days gives you opinions). Covers scoped vs. unscoped packages, README optimization, versioning strategies.

5. "50 npm CLI Tools I Built in One Weekend" -- Pure building-in-public content. Lists every tool with descriptions, lessons learned, and honest assessments of what worked. Meta-article about the process itself.

The remaining 76 articles are competent but generic. They cover CLI development patterns that have been written about thousands of times. When you're generating articles at scale, originality suffers. The articles that work best are the ones grounded in specific, real experience -- not abstract tutorials about topics the agent learned from training data.

Revenue Reality: $0

Let me be completely transparent about the financial outcome.

Total revenue from these two sessions: $0.00

Potential pipeline value: $1,340 - $1,940 (if every pending submission converts, which they won't)

Here's where every revenue channel stands:

Bounties: $0 earned

  • 12 Expensify proposals: all lost. Expensify bounties get assigned within 30 minutes of issue creation. By the time an agent finds an issue, reads the codebase, writes a proposal, and submits it, someone else has already been assigned. The competitive window is brutally narrow.
  • AsyncAPI PRs: 2 open, CI passing, no reviewer assigned. Could convert eventually.
  • Cal.com proposals: 5 submitted, $475 total potential. No responses yet.
  • tscircuit/Algora: 2 attempts submitted, $350 potential. 12+ competing attempts on the biggest one.

Articles: $0 earned

  • 40 Smashing Magazine pitches: no responses. Smashing pays $250-400/article but their editorial pipeline moves slowly.
  • 14 SitePoint pitches: SitePoint has paused paid articles entirely.
  • DigitalOcean, LogRocket, Auth0: all paused paid contributor programs.
  • Dev.to: 52 articles published, generating views but Dev.to doesn't pay authors.
  • Galaxy Community Writers: $60 potential, proposal submitted.

Tools: $0 earned

  • 4 Gumroad listings at $10-$15 each. Zero sales. Gumroad payment processing isn't even fully connected (bank details need manual entry).
  • 24 npm packages published. npm doesn't generate revenue directly.

Upwork: $0 earned

  • 2 proposals submitted. Upwork has aggressive anti-bot protections that make browser automation unreliable.

The Gap Between Production and Conversion

This is the core lesson: production and conversion are completely different skills, and scaling production does nothing for conversion.

Publishing 52 articles on Dev.to doesn't matter if nobody reads them. Pitching 40 times to Smashing Magazine doesn't help if the pitches are generic. Submitting 12 bounty proposals doesn't work if you're consistently 31 minutes late.

The AI pipeline is phenomenal at production:

  • It can scaffold a TypeScript CLI tool in 2 minutes
  • It can write a 2,500-word technical article in 3 minutes
  • It can format and submit a bounty proposal in 5 minutes
  • It can publish to npm in 1 minute

But none of that addresses:

  • Why would someone buy your tool when npm install is free?
  • Why would an editor pick your pitch over 200 others?
  • Why would a maintainer assign you a bounty when 15 people applied?
  • Why would anyone read your 52nd Dev.to article?

These are marketing problems, positioning problems, timing problems. They require taste, reputation, relationships, and patience. None of which can be parallelized across 165 agents.

What Actually Converts: A Hierarchy

After two days of maximum-effort experimentation, here's my honest ranking of revenue channels from most to least likely to convert for a solo developer using AI tools:

  1. Upwork -- Still the most reliable path. Clients post jobs, you apply, you get hired. The competition is fierce but the conversion rate for quality proposals is measurable. AI can help you write better proposals and deliver faster. The problem: Upwork's platform resists automation.

  2. Bounties -- Can work if you're fast enough and choose the right projects. The key insight: Expensify is a trap (30-minute assignment window). Cal.com and tscircuit are better bets. AsyncAPI has a structured bounty program with real funding. The problem: most bounties are $15-$50, not $250.

  3. Paid Articles -- The market has contracted dramatically. SitePoint, DigitalOcean, LogRocket, and Auth0 have all paused paid programs. Smashing Magazine remains viable but competitive. freeCodeCamp and Galaxy are options for smaller amounts. The problem: editorial response times are weeks, not hours.

  4. npm Tools -- Publishing tools builds credibility and can drive indirect revenue (consulting, sponsorships) but direct monetization is nearly impossible. Nobody pays for CLI tools when the npm ecosystem is built on free. The problem: discoverability is zero without marketing.

  5. Gumroad -- The worst conversion rate of anything I tried. Listing developer tools on Gumroad when the same tools are free on npm is asking people to pay for something they can already get for free. The problem: the product-market fit doesn't exist.

The Lesson: 5 Great Things > 50 Mediocre Things

If I could rewind these two sessions, here's what I'd do differently:

Instead of 53 tools, I'd build 3 tools. I'd spend the time making them genuinely excellent -- with polished READMEs, demo GIFs, comprehensive tests, beautiful CLI output, and actual marketing. I'd post them on Hacker News, Reddit, Twitter, and relevant Discord servers. I'd write one excellent article about each one.

Instead of 81 articles, I'd write 5 articles. Each would be 4,000+ words, deeply researched, with original insights that no AI could produce from training data alone. I'd pitch each one to exactly one publication with a personalized pitch that shows I understand their editorial voice.

Instead of 12 bounty proposals, I'd pick one bounty with a $500+ reward, fork the repository, read the codebase thoroughly, and submit a working PR within 2 hours of the issue being created.

Instead of 165 agents, I'd run 3 agents: one building, one writing, one submitting. With clear instructions and quality gates instead of "produce maximum volume."

The fundamental mistake was treating AI-powered development as a numbers game. It's not. The AI removes the bottleneck of production speed, but the bottleneck was never production speed. The bottleneck is taste, timing, and human connection.

What Worked

Let me give credit where it's due. Some things genuinely worked well:

TypeScript scaffolding is nearly perfect. AI-generated TypeScript CLI tools compile and run correctly about 90% of the time on the first attempt. The pattern is well-established: commander for argument parsing, chalk for colors, ora for spinners. The agent produces clean, idiomatic code.

npm publishing is fully automatable. Once you have an npm token configured, the agent can create a package, write the code, compile it, and publish it without human intervention. The entire flow from idea to npm install my-tool takes about 3 minutes.

Dev.to publishing via API is smooth. The Dev.to API is well-designed for programmatic publishing. Articles go live immediately and start accumulating views. The API key integration just works.

Bounty proposal quality is surprisingly good. The AI reads actual source code, identifies root causes, and proposes specific fixes with file paths and code changes. The proposals are often more detailed than human-written ones. The problem is speed, not quality.

Revenue tracking as JSON is underrated. Having a machine-readable file that tracks every submission, every status, and every outcome makes it trivial to understand your pipeline. I can grep for "LOST" and see every failed bounty. I can filter for "SUBMITTED" and see what's pending. Simple, powerful.

What Didn't Work

Gumroad is the wrong platform for developer tools. Developer tools should be open-source and monetized through sponsorships, consulting, or premium features -- not $15 Gumroad listings. The conversion rate was exactly 0%.

Bounty competition is intense. Expensify bounties are the most competitive in the ecosystem. ProposalPolice (their automated moderation bot) removes duplicate proposals within minutes. By the time you've read the issue and written a proposal, 3 other people have already submitted. The 30-minute window is not a suggestion; it's a hard deadline.

Paid article programs are contracting. The 2024-2026 era of companies paying $200-400 for developer articles is ending. Most programs have paused or closed. The remaining ones (Smashing Magazine) have long editorial cycles and high rejection rates.

Browser automation at scale is fragile. Playwright works well for single-agent scenarios but falls apart when multiple agents need the browser. Session state conflicts, tab focus issues, and race conditions make it unreliable for parallel workloads.

Volume doesn't equal value. This is the big one. 52 Dev.to articles generate less engagement than 1 viral article. 24 npm packages attract less attention than 1 package with 1,000 stars. Scale without quality is noise.

Actionable Takeaways for Developers

If you're a developer considering AI-powered productivity tools, here's what I'd recommend based on this experiment:

1. Use AI for speed, not for volume. Build one thing faster, not fifty things simultaneously. The AI should make your best work better, not replace your judgment about what to build.

2. The production-conversion gap is real. AI can produce at 100x speed but cannot convert at 100x speed. Marketing, reputation, relationships, and timing are human problems that require human solutions.

3. Pick your revenue channel before you build. Don't build 53 tools and then figure out how to monetize them. Identify a paying customer (Upwork client, bounty program, publication) and then build what they need.

4. Bounties require speed, not quality. The best bounty proposal means nothing if you submit it after assignment. Set up notifications, fork repos in advance, and have your development environment pre-configured for target projects.

5. Serialize browser automation. If you're using Playwright or any browser automation tool with multiple agents, run them one at a time. Browser state is global and doesn't handle concurrent access well.

6. npm rate limits are aggressive. If you're publishing multiple packages, space them out. 16 packages in one hour triggers rate limiting that can persist for hours.

7. Track everything in machine-readable format. A revenue.json file that logs every submission, every status change, and every outcome is more valuable than any dashboard. You can query it, diff it, and trend it.

8. The best articles come from real failure. My most engaging article was about the bounty hunting system that mostly didn't work. Nobody wants to read "I built 50 tools and they're all great." People want to read "I tried something ambitious, it mostly failed, and here's what I learned."

9. Open source is a long game. npm packages don't generate revenue in week one. They build credibility over months. If you need money now, do freelance work. If you're building for the future, publish tools and write about them.

10. AI agents are spectacular assistants but terrible strategists. Let the AI write the code, draft the article, and format the pitch. But decide what to build, what to write about, and where to pitch it yourself. That's where all the value is.

The Honest Assessment

I ran the most aggressive AI-powered development sprint I've ever attempted. The raw output is staggering by any historical measure. Two years ago, producing 53 tools and 81 articles in two sessions would have been physically impossible for a team of ten people.

But output isn't outcome. I generated approximately 200,000 words of content, 53 compiled TypeScript projects, and 30+ proposals and submissions. The result was zero dollars in new revenue and a pipeline of maybes.

The experiment was worth running because it mapped the boundaries. I now know exactly where AI-powered development excels (scaffolding, drafting, formatting, publishing) and where it falls short (strategy, marketing, timing, taste). I know which revenue channels are viable and which are dead ends. I know that 5 excellent things beat 50 mediocre things every time.

The next session will look very different. Fewer agents. Fewer tools. Fewer articles. More focus. More quality. More human judgment about what deserves to exist.

That's the real lesson of building in public: the most valuable thing you can share isn't your success. It's the gap between what you expected and what actually happened. The gap is where the learning lives.

This article was written in March 2026 based on two real production sessions using Claude Code with autonomous agent orchestration. All numbers are from actual logs in revenue.json and session memory files. Nothing has been rounded up or exaggerated. The $0 revenue figure is real.

If you're experimenting with AI-powered development, I'd love to hear your results. The honest ones, not the highlight reel.

Top comments (0)