How Small Teams Can Use AI to Achieve High Delivery Rates: The Engineering Methodology Behind 270,000 Lines of Code

Over the past three months, I worked alongside multiple AI coding tools to produce roughly 270,000 lines of code and complete nearly 3,000 commits, while keeping annual subscription costs across AI tools at around $2,400. That number may sound extreme, but if you treat a one-person company as a legitimate business delivery model, it is reproducible—provided you treat AI as a component within an engineering system, not as a wish-granting machine.

In this delivery system, I evaluate models based on two accounts only: token billing cost and delivery rate in real engineering troubleshooting. The former determines the marginal cost per unit of output. The latter determines whether you can actually get paid on time. This article unpacks both accounts, walks through the hardest part of engineering practice—locating and fixing stubborn bugs—and provides reusable methods for context organization, validation checklists, and cost control.

Why “Can Write Code” Is Not the Same as “Can Deliver”

Many teams evaluate AI coding tools by looking at generation speed, completion hit rate, or unit test pass rate. These metrics have meaning, but they are still far from commercial delivery. The real dividing line appears in three types of scenarios:

1. Implicit coupling across modules: The symptom shows up in one module, the root cause lives in another, with state caching, asynchronous timing, or configuration injection in between.
2. Hard-to-reproduce intermittent issues: The problem never reproduces locally after ten attempts, and production logs contain only scattered clues.
3. Legacy baggage: The codebase was assembled months ago by different tools and different styles, without a unified abstraction.

These three scenarios share one common trait: incomplete information. A model’s capability ceiling depends heavily on whether you can feed in “sufficient but not redundant” information within a limited context window. That is why I eventually changed my evaluation criterion from “generation quality” to “troubleshooting delivery rate”—the ability to independently close the loop from reproduction, root-cause analysis, and fix to verification within a given time box.

Two Accounts: How to Calculate Cost and Delivery Rate

Token Cost: Cost per Deliverable, Not Unit Price

Looking at the price per million tokens alone is not very meaningful, because different tasks have very different token consumption structures. A more useful metric is cost per deliverable:

Cost per deliverable = Total token cost for the period / Number of valid deliverables for the period

A “valid deliverable” means a change that passed acceptance, entered the main branch, and was not rolled back within two weeks. This definition naturally penalizes workflows that look fast but involve repeated rework. In practice, I have observed two patterns:

• Context waste is the biggest cost item. Dumping the entire repository into a conversation may feel convenient, but it sharply reduces the density of useful information in each interaction. Tokens get spent on code the model does not need.
• Rework costs far more than first-pass generation. If an incorrect change gets merged, the downstream cost of investigation, rollback, and re-verification is usually several times the cost of the original generation. Spending a bit more in tokens upfront to clarify requirements is worth it.

Delivery Rate: Measure It with a Time Box

I set an explicit time box for troubleshooting tasks, such as “a verifiable root-cause hypothesis must be produced within 30 minutes.” The delivery rate is the success rate of closing the loop within that time box. This metric is closer to business reality than “how many bugs were fixed,” because it constrains both quality and pace.

A Complete Workflow: Fixing a Stubborn Bug in 9 Minutes

Here is a real troubleshooting session. The system is a content distribution tool I built myself, and one long-standing bug kept reappearing: under certain conditions, a content distribution task would fail silently. There was no exception stack trace in the logs, and the task status stayed stuck at “processing.” Several previous attempts had failed to reproduce it reliably.

Step 1: Turn the “Symptom” into an Executable Reproduction Contract (About 2 Minutes)

The key is not describing the symptom, but converting it into an executable minimal reproduction path. What I provide to the model is not “I have a bug, can you take a look,” but structured input:

[Environment] Runtime version, dependency versions, deployment form
[Trigger conditions] Specific input combinations, concurrency level, call sequence
[Observed results] Expected state vs. actual state, relevant log excerpts (sanitized)
[Ruled-out items] Directions that have already been verified as ineffective
[Constraints] Public interfaces that must not change, new dependencies that must not be introduced

This step pays off immediately: the model does not need to guess the environment, and it does not waste reasoning power on already ruled-out directions. The “ruled-out items” section is the most easily overlooked but most valuable piece of information—it directly shrinks the search space.

Step 2: Ask the Model to Output Hypotheses First, Not a Patch (About 3 Minutes)

I explicitly require the model to produce a list of root-cause hypotheses first, each with a corresponding verification method, and to hold off on code changes. The reason is practical: if the model gives you a patch right away, you will unconsciously look for reasons to justify that patch, leading to confirmation bias.

The model produced three hypotheses, ranked by likelihood:

1. The completion callback of an asynchronous task swallows the exception branch, so the state machine never reaches a terminal state.
2. A shared cache key design has collisions, causing different tasks to overwrite each other’s intermediate state.
3. The retry mechanism and idempotency check run in the wrong order, causing the state to be rolled back after duplicate consumption.

Each hypothesis mapped to an observable point. I added two log probes accordingly and triggered the reproduction again.

Step 3: Verify the Root Cause with a Minimal Change (About 2 Minutes)

The principle in the verification phase is change only one variable at a time. Following hypothesis 1, I added a fallback log for terminal state transitions. After reproducing the issue, it was immediately confirmed that the exception branch was indeed not persisting the state. Once the root cause was confirmed, the fix itself was simple—complete the terminal state write at the unified exit point of the async callback, and explicitly catch the exception path.

Illustrative code (generic pattern, not tied to a specific API):

def on_task_finish(task_id, result, error=None):
    try:
        if error is not None:
            # Explicitly persist the terminal state to avoid silently swallowed exception branches
            state_store.mark_failed(task_id, reason=str(error))
            return
        state_store.mark_succeeded(task_id, payload=result)
    except Exception as exc:
        # Fallback: terminal state write failures must be observable
        logger.error("finalize failed task_id=%s err=%s", task_id, exc)
        state_store.mark_failed(task_id, reason="finalize_error")
    finally:
        cache.invalidate(task_key(task_id))

Step 4: Use a Validation Checklist, Not “Let Me Try It and See” (About 2 Minutes)

After the fix, I always run through a fixed four-item checklist:

• Original reproduction path: Confirm the symptom is gone.
• Adjacent path regression: Run the success branch, retry branch, and timeout branch once each.
• Concurrency and duplicate consumption: Simulate duplicate callbacks and confirm idempotency.
• Observability check: Confirm that the newly added log actually fires on the exception path.

All four items must pass before I consider the loop closed. The entire process took about nine minutes from start to finish. I did not write a single line of business code by hand—but I was deciding throughout what to look at, what to verify, and what to trust. That judgment is the real source of the delivery rate.

Context Engineering: Turning a Repository into Retrievable Knowledge

Coordinating 270,000 lines of code does not depend on a bigger context window. It depends on a layered approach to organizing information:

1. Convention layer: Interface specifications, error codes, and state machine definitions. Keep these concise and stable, and include them in every conversation.
2. Module layer: Generate summary indexes by directory, including responsibilities, public interfaces, and dependencies. Retrieve them on demand.
3. Task layer: The reproduction contract, ruled-out items, and validation checklist for the current task. Accumulate these per task.
4. Evidence layer: Sanitized log excerpts and key call chains, limited to what is relevant to the current hypothesis.

The core idea of this structure is simple: let the model see the summary of conclusions, not the raw whole. As information density goes up, token cost comes down, and reasoning quality becomes more stable.

Hard Rules for Cost Control

• Choose the model tier by task type: Use lower-cost tiers for mechanical refactoring and boilerplate code; use higher-capability tiers for root-cause analysis and architecture review. Do not use a high-end tier for formatting.
• Set a conversation lifecycle: One task per conversation. Archive the conversation when the task is done. Historical noise in long conversations continuously drives up cost and dilutes attention.
• Clarify before generating: For ambiguous requirements, ask the model to restate its understanding and list open questions first. Enter generation only after confirmation. This significantly reduces rework.
• Turn repetitive work into scripts: Log aggregation, diff comparison, and regression triggers are fixed actions. Writing them as scripts is cheaper and more reliable than repeating them in conversations.

Who This Method Is For—and Who It Is Not For

It suits scenarios with clear acceptance criteria, relatively focused requirements, small team size, and heavy delivery pressure: independent developers, small delivery teams, and internal tooling projects. It does not suit teams with constantly shifting requirements, no verifiable standards, or the belief that AI can replace human judgment—because every verification step in this workflow requires a person to define what counts as “correct.”

Back to the two accounts: token cost determines how fast you can move. Troubleshooting delivery rate determines whether you can reach the finish line. The 270,000 lines of code and 3,000 commits are just outcomes. What is actually reusable is the closed loop of “reproduction contract—hypothesis ranking—single-variable verification—fixed checklist.” Make it a habit, and you will find that stubborn bugs are less stubborn, and the budget is less tight.