AI Coding in Practice: A Solo Developer's Cost Ledger and Delivery Rate

1. The Baseline: Where the System Stands

Over the past three months, working solo with multiple AI coding assistants, I produced roughly 270,000 lines of code and made nearly 3,000 commits, while keeping my annual subscription spending across AI tools to around ¥17,000 CNY (roughly US$2,400). Those numbers aren’t worth bragging about on their own — what deserves dissection is the set of decision rules behind them. In this one-person-company delivery system, I keep only two yardsticks for model selection:

• Token billing cost: it determines whether the system can keep running long-term on a limited budget.
• Delivery rate on real engineering troubleshooting: it determines whether the AI is actually doing my work or manufacturing new rework.

Why not benchmark scores? Because leaderboards measure a model’s “average ability,” while a solo developer’s daily work is heavily skewed: reading code across long contexts, debugging in the terminal, and editing frontends under tight constraints matter far more than an overall rank. A leaderboard can help you draw up a shortlist, but the final call has to come from hands-on testing on your own tasks.

2. Ledger #1: Account for Token Costs at Per-Task Granularity

2.1 Understand the three-tier pricing structure

Most mainstream LLM APIs split pricing into three tiers: input tokens, output tokens, and cache hits. Two facts to internalize:

• Output tokens are usually priced several times higher than input tokens, because “generating” consumes more compute than “understanding.”
• Cache-hit pricing is significantly lower than regular input pricing — in some cases by an order of magnitude. Always check each provider’s published rates.

2.2 The real hidden cost is context bloat

In multi-round debugging, the conversation history is re-sent with every turn; input volume grows linearly, sometimes super-linearly, and the bill doubles without you noticing. Three countermeasures:

• Start new sessions promptly and distill confirmed conclusions into a summary, instead of dragging the full history along.
• Feed slices, not the whole repo: attach only the file fragments relevant to the task, each annotated with its responsibility.
• Enable context caching for repeated prefixes so multi-turn conversations hit the cheaper tier.

2.3 A formula you can actually compute with

Per-task cost ≈ Σ(per-round input tokens × input price + per-round output tokens × output price) − cache savings.

A toy example (numbers are illustrative for easy math): assume input at $0.50 per million tokens and output at $2.00 per million. A debugging session runs 6 rounds, each with roughly 30,000 input tokens and 2,000 output tokens; the total comes to about $0.11. If most of the historical prefix hits the cache, the input portion drops even further. Run this calculation over each of your typical tasks and you’ll find that what burns money is usually not “the model is too expensive” but “you’re feeding too much.”

2.4 Mixing subscriptions with pay-as-you-go

For high-frequency, lightweight work such as interactive development and brainstorming, subscriptions are more economical. For batch automation tasks — bulk unit-test generation, bulk code migration, overnight batch runs — go through the API and pay as you go, which lets you attribute costs precisely to individual tasks. Mixing the two is the single most effective lever for keeping the annual budget in check.

3. Ledger #2: Replace Benchmark Worship with a Debugging Delivery Rate

3.1 Beyond overall leaderboards, watch three specialist families

Coding-related evaluations fall broadly into three families:

• Long-horizon continuous coding: tests whether a model can “keep writing correctly” across multi-file, multi-step tasks — the real workload behind “implement a whole feature in one pass.”
• Agentic autonomous work: tests the rate at which a model completes tasks end-to-end with minimal human intervention — the “give it a goal and it decomposes and executes” usage pattern.
• Constrained terminal environments: tests the ability to locate and resolve problems in a real command line — the everyday reality of server-side debugging and build-failure repair.

When choosing a model, look first at the specialist scores in the family that matches your workload, then at the overall score.

3.2 Three architecture-level facts

• Mixture-of-Experts (MoE) architectures are now mainstream: total parameter count caps the knowledge capacity, while the parameters actually activated per inference matter more for speed and per-call cost — don’t judge by total parameters alone.
• The context window determines how much code fits in one read: a longer window lets you feed a complete module or even a mid-sized repository at once, sharply reducing the guesswork patches caused by never seeing the full picture.
• Whether the weights are open determines whether private deployment is viable: for data-sensitive teams, this directly affects long-term cost and the compliance path.

3.3 Your own eval set is the final arbiter

My approach: pick 10–20 already-fixed historical bugs from my own repositories, strip out the fix records and keep only the reproduction information, standardize the prompt template and the maximum number of rounds, then record four metrics — one-shot pass rate, pass rate within the round limit, average rounds, and average cost. Every time a new model ships, rerun the same eval and compare “solve rate per unit of cost.” What this set measures is your code, your stack, your problems — no leaderboard can substitute for it.

4. Case Study #1: The Full Chain of a Nine-Minute Bug Fix

4.1 Task background

In a content-distribution tool I built, an old problem had been sitting there: under certain conditions, one distribution path behaved abnormally. I had cycled through several models trying to fix it — all failed — and it had nearly been written off as “a bug AI can’t fix.” This time, I prepared the context against a standard checklist and handed the task to the model. From pressing Enter to completed reproduction, modification, and verification, the whole thing took about nine minutes — and honestly, I did not write a single line of code in the process.

4.2 The key is the feed, not magic

The retrospective made me certain: earlier attempts failed not because the model wasn’t smart enough, but because the context I fed it was unqualified — without a stable reproduction path, the model could only guess, and guesswork patches naturally fail over and over. This time I prepared three things: a minimal reproduction path (a few steps that trigger the bug reliably), an evidence chain (key log snippets and the error stack), and suspect code slices (the key sections of two or three relevant files, each annotated with its responsibility).

4.3 The four-step process

1. Reproduce: have the model organize reproduction steps from the description and confirm the bug triggers reliably — avoid “fixing a bug that doesn’t exist.”
2. Locate: require the model to produce no more than three root-cause hypotheses, ranked by likelihood, and verify them one by one instead of throwing out a patch immediately.
3. Modify: small commits — change one thing at a time, each with a stated rationale, for easy human review and rollback.
4. Verify: add a regression test to lock the behavior down and keep the same problem from recurring.

Illustrative prompt structure:

[Task] Fix <anomaly> in <module> under <scenario>
[Environment] Runtime version / key dependency versions
[Reproduction] 1) ... 2) ... Expected: ... Actual: ...
[Evidence] Key logs: ... Error stack: ...
[Related code] File A, lines x–y (responsibility: ...); File B, lines x–y (responsibility: ...)
[Requirements] First give ≤3 root-cause hypotheses, ranked; change only one spot at a time and explain why; provide an executable verification method

Illustrative regression test:

def test_dispatch_should_not_duplicate_on_retry():
    event = build_event(id="evt-001")
    dispatcher.dispatch(event, retry=2)
    assert consumer.received_count("evt-001") == 1

4.4 What those nine minutes were made of

Within the nine minutes, reproduction and localization took the bulk; the actual code change occupied only a small slice. It illustrates a plain truth: the speed ceiling of AI debugging is set by the precision of what you feed it, not by the model’s leaderboard rank. The time spent preparing context amortizes across every similar problem that follows — that is the compounding return behind the “nine minutes.”

5. Case Study #2: Engineering-Grade Landing Page Generation

5.1 Don’t just say “make it look nice”

The main cause of failed frontend generation is vague requirements. Before you start, hand over a constraint checklist: a design spec (primary/secondary colors, type hierarchy, spacing and radius base values), layout (grid system plus three breakpoints — mobile, tablet, desktop), a component list (navigation, hero, features section, FAQ, footer — item by item), accessibility (contrast, semantic tags, keyboard reachability, image alt text), and basic SEO (heading hierarchy, meta description, semantic structure).

5.2 Three-stage generation with acceptance checks

Proceed in three stages — structure → style → interaction: first produce the semantic structure and confirm the information architecture; then add responsive styles and check them breakpoint by breakpoint; finally add interactions such as form validation and submit states. Each stage has acceptance criteria: no horizontal scrolling at any of the three breakpoints, forms have validation and feedback, semantic tags are complete, and above-the-fold asset weight stays under control.

5.3 Converge with feedback loops, not full-page regeneration

For parts you’re unhappy with, send back a screenshot with annotations and ask the model to “change only the annotated areas.” Regenerating the whole page destroys the parts already confirmed; local edits converge reliably. Under this process, an ordinary marketing landing page goes from empty file to launch-ready within half a day — and the output is a maintainable, componentized structure rather than an unmanageable pile of inline styles.

6. Budget and Process: Make Every Cent Land on Delivery

6.1 Tiered model assignment

Classify your tasks: hand thorny debugging and architecture design to the models with the higher capability ceiling; hand routine completion, comments, unit-test generation, and copy polish to lightweight models. The two tiers often differ in unit price by an order of magnitude, while routine tasks make up the bulk of call volume — tiering alone can cut spending by more than half.

6.2 Small commits and human final review

Nearly 3,000 commits means every change is small enough to review, revert, and attribute. Every AI-generated change still passes through a human code review — the AI owns throughput and first-pass screening; the human owns correctness and accountability. Regression tests are the system’s fuse: without a test net underneath, the higher the degree of automation, the faster things blow up.

6.3 A cost dashboard and weekly retrospectives

Log every call’s model, task type, token consumption, and cost, then aggregate them into “average cost and pass rate per task type.” A dashboard like this can be assembled from general-purpose cloud products: object storage to archive raw logs, a logging service for aggregation queries, plus one monitoring-and-alerting rule — most major cloud platforms offer these off the shelf, so there’s no need to self-host. Review once a week and ruthlessly retire any usage pattern that is “expensive with a low delivery rate.”

6.4 Security red lines

Keys never go into prompts. Private code is sanitized before it leaves your machine. Generated code is never auto-deployed to production. The smoother the efficiency system runs, the more firmly you must hold these lines.

7. Closing: Methodology Outlives Models

The biggest lesson of these three months: model versions refresh every few weeks and leaderboard rankings reshuffle with them, but three things stay effective long-term — accounting for costs down to per-task granularity, verifying delivery rates against an eval set built from your own repositories, and feeding accurate context before you hit run. Fixing a years-old bug in nine minutes looks, on the surface, like a showcase of model capability; in essence it is the product of preparation × process × model. Get the first two right, and nearly any shortlisted model reproduces most of the gains. For solo developers, the real point of leverage is shifting from “which model to pick” to “how to organize a measurable AI collaboration process.”