DEV Community: simba ji

Harness Engineering in Practice: How I Built Mine in 4-steps

simba ji — Tue, 31 Mar 2026 08:28:03 +0000

TL;DR: Harness engineering is the layer above context engineering — you build the system (documentation, standards, quality checks, tool configs) that lets AI run unattended. I built one over two days for my project book2skills and ended up with a fully automated book-to-skill publishing pipeline. This post walks through the four steps.

Harness engineering is a term that's been gaining traction recently. Like most emerging concepts, it's ahead of widespread adoption — we're still in the early days, and real-world examples are scarce. That's exactly why I want to share how I've been applying it in my own product.

What Is Harness Engineering?

Earlier this year, OpenAI published a write-up describing how their team built a production app with over a million lines of code — without a single line written by human hands. The engineers weren't writing code. They were building the system that allowed AI to write code reliably.

That system — the documentation, quality standards, constraints, and feedback loops — is the harness.

The word "harness" comes from horse tack: reins, saddle, bridle. A horse is powerful, but without that equipment it just goes wherever it wants. The AI is the horse. The harness is everything that channels its power in the right direction. You're the rider building it.

To put it in AI evolution timeline, here's how harness engineering fits into the broader arc of AI engineering:

Prompt + workflow: Single calls with rigid, hard-coded pipelines. Predictable, but inflexible.
Context engineering: Supports longer reasoning chains and more flexible orchestration — but the agent can drift mid-task, and someone usually needs to stay close.
Harness engineering: Unattended execution. You write the standards, principles, quality checks, and tool configurations — the "playbook" — upfront. When the agent hits a decision point, it consults the playbook. The better the playbook, the less you need to intervene.

Still abstract? Let me make it concrete.

My Case: Building a Harness for book2skills

book2skills is a skills factory — it takes classic non-fiction books and distills the frameworks and decision logic inside them into AI-ready skills, open source and free.

The full production pipeline looks like this:

Pick a book → Read it → Extract the skill → Publish to GitHub → Generate usage examples → Generate website content

I handle book selection myself — I enjoy it too much to hand it off. Everything else runs automatically.

The whole harness took me about two days to build, across four steps. None of it was generated in one shot — roughly 60% of my time went into iteration and refinement.

The Four Steps to Build Harness

Step 1: Write Thorough Requirements

Before building anything, I spent about two hours getting the brief right. I had the AI help me research competitors, understand what users actually want, map out implementation approaches, and find design inspiration. The goal was to turn vague instincts into explicit written standards.

Step 2: Build Skills at the Right Granularity

This took three to four hours and went through three phases:

first, get something working end-to-end — even if it's rough, even if the input is a simple PDF and the output is a basic skill;

then refine each skill individually;

then split any skill that grows too long into two. Skills shouldn't be too large or too small. Too large and the agent drifts. Too granular and you're essentially writing code. Finding the right size takes trial and error.

Finally I ended up with a fully automated publishing pipeline: One main skill book2skills-publisher, and then five subskills.

Each step has its own dedicated skill, all orchestrated by the main skill. But the orchestration isn't rigid like a Coze workflow — it's written in plain language, loosely structured. The agent can adapt as it goes. That flexibility is precisely what makes skills more powerful than hard-coded automation.

The pipeline goes like:

Pick a book → Read it → Extract the skill → Publish to GitHub → Generate usage examples → Generate website content

Here's what each skill does:

Book selection: The one step I do myself. Not because AI can't — I just genuinely love this part.

Reading (read-book-skill): Runs local Python scripts to extract the PDF chapter by chapter, then structures the content into markdown summaries. Claude Code's native PDF capabilities are the foundation here.

Skill extraction (book-skill-creator): Takes the chapter summaries and distills them into a SKILL.md — following Anthropic's skill-creator spec, covering skill dimensions, query-response frameworks, and output formats. This is the step that most determines skill quality, and the one most worth continuing to refine.

GitHub packaging (write-skill-repo): Takes the SKILL.md and generates a complete, spec-compliant GitHub folder — cleaned SKILL.md, README, LICENSE — zipped and committed to the local repo.

Usage examples (book-skills-examples): Most skills ship with no real demonstration of what they actually do. I wanted to fix that. This skill has the AI genuinely invoke the skill, combined with web search, to produce real usage examples — two to three rounds of conversation, with real data references. Readers can see exactly what the skill does before deciding whether it's useful to them.

Website content (write-skills-page-content): Pulls everything together into a publishable page — skill description, examples, install instructions, download link — and deploys it to book2skills.

Step 3: Write an Anchoring Document

Once the pipeline was running and the project had a clear shape, I wrote a "What is book2skills" document before doing any further refinement. Its real purpose wasn't to explain the product to the outside world — it was to set a boundary for myself, to make sure the skills I was about to build wouldn't be over-engineered or scope-creep into something they weren't meant to be. I ended up publishing it as book2skills' first blog post.

Step 4: Let Skills Iterate on Themselves

This is where things get interesting. If I find a flaw in a skill, I just tell it: "add this rule." It updates its own file. The change takes effect on the next run. No developer needed.

Over time, each skill accumulates its own references and specs — like a master craftsman's handbook, full of standards and precedents for the apprentice to consult. The richer that handbook gets, the stronger the harness becomes.

What's Next

The book-to-skill pipeline is done. Next up: bringing operations, UI, and SEO into the harness as well, that's why you are seeing more skills as below. I'll keep sharing as that unfolds.

If any of this resonates, feel free to follow along.

How I earned first $500 from my AI product (continued)

simba ji — Mon, 02 Feb 2026 13:41:31 +0000

This is a continued part of our practice of user growth, as in previous post: Got First 500 Users for your AI product as an Indie, we grow our user base from 0-500. Now we are starting Monetization.

Considering Monetization: Version 1.0

First thing to do on Monetization was different from what I thought. It was SEO/GEO which is to attract a larger user base (because just posting ourselves has very limited reach)

This was the toughest month. The reason is: Beyond basic SEO work (adding backlinks, internal links, writing blogs, etc.), we needed to convert our frontend code to SSR to make pages more search-engine friendly.

Since my partner and I both lacked SEO experience, we initially used VUE as the frontend framework. But we discovered *the best practice for SEO-friendly SSR is React + Next.js. *

Initially, we tried Claude Code, Cursor, Antigravity to refactor the code to a different framework. However, none seemed to handle this well. We almost planned to start from scratch again.

Then, OpenAI Codex launched. We tried it and found Codex is ideal for refactoring. So our current AI tool stack is:

Codex — Refactoring god, perfect for framework migrations of existing code
Claude Code — Architecture god, perfect for greenfield projects
Antigravity — Aesthetic god, perfect for frontend with great visual design capabilities

Finally, by mid-January, we launched version 1.0.

(If you want to study our SEO implementation, just open our website and right click any page and copy the html source code, send it to any AI tools to teach you. Of course, we're still constantly improving.)

As our user base grew, so did our API token consumption, reaching a level we couldn't sustain.

We started Buy Me a Coffee on our website, and we promised 10x credit toward future paid tiers.

With this approach, we gradually received dozens of "coffee", totally $495. This was our biggest encouragement.

Payment System Coming Soon

After receiving these small tips, we confirmed: people are willing to pay for this.

We're currently debugging and testing the payment flow. While waiting for Stripe approval, I'm writing this to document our journey, hoping it helps others.

Yes, after almost 6 months, we finally came to monetization. Here I will summarize as blow. Hope it helps for all of you who wanted to start your own business.

What We Learned

1. Real needs matter more than imagination

AlphaWiseWin wasn't something I dreamed up — it was something a friend asked for. This ensured from day one we were solving real problems, not chasing technical concepts.

2. MVP isn't just "functional"

You need to make the core value immediately visible on top of functionality. Going from pure text reports to visual dashboards changed everything.

3. Ride the wave

That AI crypto trading experiment had nothing to do with us, but it educated the market for us. Learning to launch at the right moment saves enormous effort.

4. Don't chase flexibility for its own sake

Not all flexibility is good. Sometimes making choices for users is more valuable than giving them a bunch of options. Users want answers, not questionnaires.

What's Next

1,000 users is just the beginning. We have many ideas:

Like AI stock backtesting — seeing what returns would actually be if people followed our recommendations. That's the most hardcore validation.

Like deep financial and research report analysis — having AI truly understand those technical documents and provide analysis regular people can grasp.

Like having AI self-reflect based on historical data — constantly optimizing its analysis framework and judgment criteria.

One feature I'm really excited about: Investment Masters Roundtable. Building different AI personas like AI Warren Buffett, AI George Soros with different investment styles, having them debate the same stock. That'll be interesting.

Final Thoughts

0 to 1,000 users in less than six months. This journey isn't a huge success, but it's not a failure either.

As an indie developer, seeing something you built being used and needed — that feeling is solid. While 1,000+ users is insignificant on the internet's scale, to me, each one is real.

Our next goal is to build a better product and achieve healthier monetization.

We'll keep going. If you're doing something similar, or interested in AI investment analysis, come try our stock analysis tool or just reach out to chat.

Got First 500 Users for your AI product as an Indie-（To be continued)

simba ji — Mon, 02 Feb 2026 10:08:57 +0000

Today I checked our user data.
select count(*) from users

returned a single number:541.

You might not think that's much, but for my first indie project, it's a number I'm proud of. And since launching on October 10, 2024, this number has been growing steadily and organically — we haven't done much active promotion.

After reading this post, you may see:

Ideation: How we turned a friend's casual request into an AI stock analysis product.
0 to 10 users: how we validate ideas with minimal cost, and even without put our product online
10 to 100 users: How to ride market momentum and media buzz for organic growth
100 to 500 users: how good user experience drive our user growth.
monetization: Key points and how to start

It's a bit too long and I may need to split into 2 posts.
Here is the continued post: How I earned first $500 from my AI product

1. How It Started

Last July, an open-source project called Trading Agents suddenly blew up on GitHub. Its social media performance was equally dramatic — typical of their style. While I'm not a fan of this kind of hype-driven marketing, I have to admit it does make technical concepts accessible to the masses.

A friend of mine, a fund manager, asked if I could get this open-source project running and he wanted to utilize it for stock analysis .

You might think: just fork it, deploy it, run it — should be easy, right?

Yeah, I thought so too at first.

But I discovered the hardest part was data acquisition — you need real-time stock quotes, company financials, news data, and more. I spent a couple days figuring it all out and finally generated the reports.

After that, my friend asked me every few days to run analysis on different stocks.

That's when I realized there was a real gap: the technology to analyze stocks with AI exists, but regular investors can't access it. If I could package this capability into a product where people just open a webpage and use it, there should be demand.

In fact, I'm increasingly realizing:
technology only creates commercial value when it's properly packaged into good products.

The things tech nerds often disdain are exactly where the commercial value lies. I didn't realize this early on — I'm still in the process of this mental shift.

2. Decide to try

I discussed it with my partner. (Yes, we're a two-person indie dev team. My partner focuses more on technical architecture and back-end development, I focus more on product design and front-end development, but we don't have strict role divisions. How to find a co-founder is a topic for another time.)

After a short talk, we decided to start with the simplest version. We run some popular stocks daily and post them to stock forums to gauge reactions. Our reports back then were pure text as below:

We posted for over ten days straight. No traction. We started thinking about what was wrong.

3. The Pivot

Then we decided to change the format — converting numbers into visual dashboards.

Just that one change made a huge difference. People started paying attention, discussions picked up, and people began asking: "Bro, where did you get this chart?"

Yes, just that one change. For tech developers, it's trivially easy to implement, but from a user perspective, it created a completely different reaction.

This validated what I said earlier: "The things tech nerds often disdain are exactly where the commercial value lies."

So we moved into formal development.

4. Build V0.1

We decided V 0.1 would have only the core function: enter a stock ticker, wait a few minutes, read the report. No complex parameter settings, no fancy UI, not even a user system.

With AI coding tools, we estimated: one week to launch. (There are plenty of articles about using AI coding tools, so I won't elaborate here.)

However, even this simple version took us a month.

Why? Because while the features were simple, we spent considerable effort on data scraping and prompt engineering. Simply put: context engineering — sounds simple, actually quite tedious. We had three core tasks:

Stable data acquisition. Initially we used APIs to fetch data in real-time, but discovered it severely impacted performance. We switched to storing data, making performance more controllable. You can use web scraping or purchase data feeds.

Prompt optimization. We found issues in the original open-source project's prompts and made targeted improvements.

Landing page polish. The homepage is your first impression — you have 3 seconds to get users to click.

Time allocation for these three tasks was roughly: 60:20:30

On October 9, we finally launched our product online. Just posted it on our social media, telling friends: "Built something, give it a try."

5. First 10 Users

First week, 10+ people registered. Mostly friends or friends of friends.

I obsessed over the backend data — how long they stayed, how many stocks they looked up, which pages they lingered on.

The data looked good. Average 10 minutes stay per person, 7 stocks(at that time one page was for one stock) queried. This meant they weren't just clicking in and bouncing — they were actually using it, exploring.

6. First 100 Users

Second week after launch, a hot event happened on social media: the Alpha-arena ran an experiment where they gave several LLMs real $10,000 to trade Bitcoin and showed live results.

This experiment made "AI investing" blow up. Many people started believing, or at least getting curious: can AI really help with investment decisions?

We seized this moment.

We rode this wave and published a deep-dive article titled:

When AI Can Trade Crypto, How Should We Use AI for Stocks?

This wasn't just clout-chasing. We spent two full days writing this piece, took several stocks(APPL, CEG, KO), and backtested AlphaWiseWin's recommendations — meaning, what would our returns have been if we'd followed AlphaWiseWin's advice?

While we admittedly didn't have much data at the time, we objectively used about ten days' worth and found our returns still beat the market.

This article did get some attention. By early November, we crossed 100 registered users. You may see the 2 spikes are all due to our post on Alpha-arena's event.

Feedback and Iteration

With 100 users, we started getting feedback. Good and bad, via email.

Good feedback:

Reports are genuinely useful, comprehensive angles, more reliable than randomly reading news
Someone said they only realized how many risk factors their stock had after seeing our analysis

Bad feedback:

Too slow — reports take several minutes to generate
Sometimes the AI analysis is too academic and hard to understand
Want to see more data, like financial metrics, valuation comparisons, etc.

We decided to tackle "too slow" first, compressing generation time from an average 10 minutes to around 4 minutes. Methods included:

Workflow optimization, changing serial nodes to parallel
Testing different LLM API response speeds
Leveraging caching

These methods aren't hard, just require repeated refinement.

Note: up to this point, we didn't even have a user system, let alone commercial charging. That was our next consideration.

We entered November, we think there are more to improve in visualization, that's how we decide the coming version should be the real Version 1.0

7. Version 1.0

Version 1.0, we decided, should have one core principle: let users understand a stock at a glance.

We noticed many products give users tons of options, requiring them to ask questions:

Include technical analysis?
Deep dive into financials?
Focus on short-term or long-term?

Sounds flexible, but it's actually creating friction. Because:

Most users don't know how to comprehensively analyze a stock
Multiple interactions are needed to build complete understanding

So our approach: let users get a complete report with one click. Two keywords:

One click
Comprehensive

This change had immediate impact. New user engagement clearly improved, returning user frequency increased. By mid December, we approached registered users with stable 20% weekly retention.

Till now, we think we have gone through the so-called MVP stage, we started to consider monetization. I will continue in next post.

What I learnt:

looking back, the most important learning is:

MAKE THE TECHNICALS EASY TO USE IS MORE IMPORTANT THAN I THOUGHT.

in next post， I will post more on monetization, although we are still on the way to monetization, but still there is something to share.