How to make $15,000 a month — Why the Harness Changes Everything

The model is not the agent. The harness is.

You can give the strongest coding model on the planet your entire repo and still get confident nonsense, broken tests, and a model that drifts off task by step 40. Take that same model, put it inside the right scaffolding, and it will profile a slow endpoint, try fixes, run the tests, revert what failed, and hand you a clean diff plus a log of what it tried.

Same model. Completely different outcome.
The difference is the harness.

A harness is the loop + tools + permissions + memory + rules that turns a chatbot into something that actually does work. Moonshot (the lab behind Kimi K3) is explicit about this: the harness is part of the product. K3 was built to live inside one.

This is a practical, beginner-friendly guide to understanding and using that harness — focused on Kimi Code + Kimi K3 (as of early September 2026).

What a Harness Actually Is

A plain language model:

• Takes text → returns text
• Forgets everything between calls
• Cannot open files, run commands, or check its own work

A harness wraps the model in a continuous loop:

1. Plan — look at the goal and decide the next step
2. Act — use a tool (read/edit file, run shell command, search, etc.)
3. Observe — feed the real result (test output, error, file contents) back to the model
4. Repeat until the job is done or a limit is hit

Around that loop sit four more critical pieces:

• The tools it is allowed to use
• The permissions that stop it from doing damage
• The memory / context that carries information across steps
• A clear success condition so it knows when to stop

Get these five things right and you have a real agent instead of a fancy autocomplete.

Why Kimi K3 Fits This Job

Kimi K3 (released July 2026) is a 2.8-trillion-parameter MoE model with a 1-million-token context window and native vision. It was explicitly designed for long-horizon coding — sustained engineering sessions, large repositories, and terminal tool use with minimal babysitting.

What this gives you in practice:

• You can put a real, large codebase in front of it
• Strong repository navigation (the unglamorous skill that actually matters)
• Good cache economics on long, repetitive agent loops (important for cost)
• Strong results on frontend and many agentic coding benchmarks

Honest limits:

• It defaults to maximum reasoning effort → slower and more verbose than lighter models
• It is not the absolute top closed model on every single hard one-shot task
• You are not running the full 2.8T weights on a laptop. Almost everyone uses the hosted API or Kimi Code

Use it for the work a harness is good at: long, context-heavy, multi-step engineering jobs where cost and sustained reasoning matter more than winning a benchmark by half a point.

Fastest Way to Start: Kimi Code CLI

Kimi Code is Moonshot’s own terminal coding agent. It already is a complete harness — it can read/write files, run shell commands, search, and drive full sessions.

Updated setup (September 2026):

# macOS / Linux
curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash

# Windows (PowerShell) — install Git for Windows first
irm https://code.kimi.com/kimi-code/install.ps1 | iex

Then:

1. cd into your project
2. Run kimi
3. Authenticate with /login (Kimi account or platform API key)
4. Select the model (prefer K3 for serious work). Avoid switching models mid-session if you care about cache hits.

Give it a clear task in plain English and it will plan → act → observe → repeat.

The Anatomy of a Task That Actually Works

Vague goals produce drift. Measurable goals produce results.

Use this shape every time:

• Measurable outcome (e.g. “reduce p95 latency of /api/search by ≥30% without changing the response shape”)
• Profile / investigate first
• Run the tests after every meaningful change
• Revert if the change makes things worse
• Report what you tried that didn’t work

If you cannot state how you would check whether the agent succeeded, it will wander. This single habit solves more problems than almost any other change.

Shaping Behavior: AGENTS.md + Custom Agents

Drop an AGENTS.md (or equivalent) in the project root. Kimi Code reads it and treats it as standing instructions. This is where you put the rules that should never change:

• Coding standards
• “Never touch production credentials”
• Preferred test commands
• Architecture constraints
• “Always run the full test suite before claiming done”

You can also define specialized agents (reviewer, test-writer, refactorer, etc.) as Markdown files and call the right one for the job.

Permissions & Safety (The Part Most People Skip)

You are about to let an autonomous system edit files and run shell commands, possibly for a long time. Treat this seriously.

Recommended defaults (steal these from how serious evaluation harnesses are run):

• Always start from a clean git commit so you can roll back in one command
• Restrict the agent to the project workspace
• Deny network access and real secrets by default (use synthetic values)
• Never allow autonomous deploys — keep a human approval gate
• Set hard budgets: max steps, wall-clock time, and dollar cost

These constraints do not make the agent weaker. They make it something you can actually leave running while you sleep.

Subagents: One Agent Is Good, a Team Is Better

Once a single agent works, split roles:

• One agent implements
• A separate agent reviews against a fixed standard

A reviewer that did not do the work catches far more mistakes than an agent grading itself. K3’s large context makes this practical.

The Loop That Runs Itself

Combine everything above:

• Clear, testable goal
• Solid AGENTS.md
• Sane permissions + budgets
• Success condition the agent can check itself

Then insist on audit artifacts: tool trace, final diff, test results, and cost breakdown. You keep the judgment about what ships. The harness owns the volume of work.

Cost Hygiene

K3 runs at max reasoning effort by default. Do not point it at one-line formatting fixes. Route small/mechanical work to lighter models and promote only the expensive, long-horizon jobs to K3. Reasoning tokens count as output tokens — budget for them.

Quick Troubleshooting

| Symptom | Most common cause | Fix | |---------|-------------------|-----| | Drifts on long runs | Vague goal | Make the success condition measurable and self-checkable | | Context fills up | Dumping the entire monorepo | Point it at the relevant directories | | Slow + verbose | Max reasoning effort | Accept it on hard tasks; route trivial work elsewhere | | Unexpected bill | Reasoning tokens or wrong model choice | Route + cost caps | | Want to run fully local | 2.8T parameters | Use the hosted API / Kimi Code (what almost everyone does) |

The Real Shift

For a long time, “using AI to code” meant you were the loop: you planned, ran the code, checked results, and fed them back. The model was just a fast intern.

A good harness moves the connective work onto the machine. You keep the judgment (what the goal is, which diff is acceptable, what the system should become). The harness handles the planning, the edits, the test runs, the retries, and the hundred small steps in between.

And the harness outlives any single model. When a better model appears, you drop it into the same scaffolding — your rules, subagent patterns, budgets, and success conditions — and everything gets sharper immediately.

Start simple:

1. Install Kimi Code
2. Write a real AGENTS.md
3. Give it a measurable goal on a real repo
4. Lock down permissions
5. Let it run

The people who pull ahead will not be the ones who always have the single best model. They will be the ones who built the best harness around whatever model is strongest this month.

Open a terminal, point it at something you’d never have time to do yourself, and try it.