An AI agent pipeline burned 1M tokens on a 5-task spec. Here's the fix.

A developer reports spending ~200k tokens per task on an isolated AI workflow. The fix involved treating specs as source code and rebuilding the pipeline to test the integrated result.

A five-task feature specification cost one million tokens to implement using an AI agent pipeline. The developer, writing under the pseudonym "bredmond1019," reports that each task consumed around 200,000 tokens passing through a sequence of AI agents for implementation, testing, and review.

The problem was not the agents, which performed as instructed. The issue was a flawed, expensive architecture that treated each task in total isolation. This led to a complete rebuild of the pipeline, centered on a simple idea: specifications are source code, and generated code is a compiled artifact.

The spec is the source code

The author argues that common "vibe coding" workflows make a critical error. Developers use a prompt to generate code, then discard the prompt and commit the code. This is equivalent to version-controlling a compiled binary while throwing away the source. The prompt, which contains the structured intent, is the valuable artifact.

The proposed alternative is a spec-driven pipeline where the spec file is the source of truth. An "SDLC harness" uses this spec to orchestrate AI agents that handle implementation, testing, review, and documentation. The generated code is the output, which can be regenerated from the spec at any time.

An expensive, isolated pipeline

The first version of this harness was built for thoroughness. It processed each task from a spec file independently, running it through a complete, isolated workflow.

The author provides a diagram of this process:

tasks.md
│
├── Task 1 (isolated) → implement → test → review → doc → wrap [~200k tokens]
├── Task 2 (isolated) → implement → test → review → doc → wrap [~200k tokens]
└── Task 3 (isolated) → implement → test → review → doc → wrap [~200k tokens]
────────────────────────────
Total: ~200k × N tasks

This design was structurally wasteful. It ran setup phases N times for N tasks. Per-task reviews could identify issues within a single task but were blind to integration problems. The author claims this resulted in a cost of approximately 200,000 tokens per task, giving a false sense of security while burning capital.

Rebuilding for integration

The redesign was based on a single question: what actually needs isolation? The author concluded that only the implementation step benefits from a clean context for each task.

All other stages, including setup, testing, review, and documentation, can be run a single time on the integrated result of all implemented tasks. This avoids redundant work and, more importantly, allows testing and review to occur on the codebase as a whole. This catches integration bugs that the isolated v1 pipeline missed entirely.

What We'd Change

The playbook presented is a principle, not a finished schematic. The source article describes the expensive v1 architecture in detail but cuts off before fully detailing the cheaper v2 implementation. A founder attempting to replicate this cannot simply copy the architecture; they must build their own based on the provided concept of shared versus isolated steps.

The reported cost of 200,000 tokens per task is a snapshot tied to a specific model and context window. This figure will vary significantly based on the LLM used, the complexity of the codebase, and the verbosity of the spec. As model costs decrease, the economic pressure driving this architectural change may lessen, though the logical benefits of integrated testing remain.

Finally, the spec-driven model excels at greenfield feature development or tasks with clear boundaries. Its utility is less clear for complex refactoring, debugging emergent system-level bugs, or making architectural changes that touch dozens of files. The spec itself becomes a new programming challenge, and "underspecification" replaces traditional coding bugs as the primary failure mode.

Landing

The core shift advocated here is not from human to AI coder, but from code to specification as the center of value. This reframes the developer's primary role as that of a system architect and technical writer. The most critical skill is no longer writing flawless implementation code, but creating unambiguous, comprehensive specifications that an agent system can execute. The pipeline's efficiency is secondary to the quality of the input it receives.

The investor read

This playbook signals a shift in the developer tooling market, moving value up the stack from code generation (e.g., Copilot) to workflow automation and orchestration. The defensible IP is not the underlying LLM but the proprietary 'SDLC harness' that directs agents to perform complex tasks. Currently, this is a bootstrapped R&D play. To become investable, a company would need to productize this harness for a specific vertical, like frontend component libraries or API endpoint creation, and demonstrate repeatable velocity gains and cost savings for engineering teams. The market for full-lifecycle AI agent orchestration is nascent, but it represents the next logical battleground for developer mindshare and enterprise budgets.