Why AI Agents Can't Build Million-Line Software From a Single Prompt: The Engineering Methods That Make It Possible

Why a Single “Advanced Prompt” Can’t Build Large Software

A tempting idea has been circulating in the developer community: give a coding tool one sufficiently “advanced” instruction, and it will autonomously deliver an entire, large-scale software product on its own. One frontier team put this idea to the test in an internal experiment. They asked a coding agent to clone a mature full-stack application. The results were disappointing. Even the most capable models available could not reliably deliver an entire application from a single prompt.

At first glance, the result may seem surprising. In practice, it exposes the core issue: building large software is never just the act of writing code. It is an entire engineering process. A prompt can describe a goal, but it cannot replace planning, state management, validation, and iteration. Understanding why agents fail is the first step toward learning how to make them succeed.

Three Typical Failure Modes

In experiments and real projects, large-scale work driven by a single long instruction tends to break down in one of three ways. Each one is worth examining on its own.

1. Context window exhaustion leaves tasks half-finished

A coding agent that tries to “write the whole application in one go” keeps stuffing files, code, and reasoning into its context. When the context window fills up, the architecture constraints and interface contracts established early on are pushed out of the model’s attention. At that point, the agent is forced to truncate its work, or to keep guessing with missing information. Either way, the output drifts further and further from the original goal.

Root cause: Context is a finite resource, and the amount of context a large project requires far exceeds the capacity of any single context window.

2. Broken session handoffs leave the next session working blind

When a task runs across multiple sessions, a new session often knows only that the project “needs to be continued.” It has no idea what has already been done, what is still missing, or what intermediate state the code is in. Without a structured handoff, the agent can only probe at half-finished work again and again. It may reimplement features that already exist, or overwrite results that were previously correct.

Root cause: Models are inherently stateless. Memory across sessions must come from external mechanisms, not from a few scattered remarks in a prompt.

3. “Feeling good about it”: false completion

A subtler failure occurs when an agent finishes a few features and declares the task “complete.” It never checks its output against the original requirements list. It simply makes an optimistic judgment based on local progress. Many items in the requirements document are still unimplemented, yet a single “done” waves them away.

Root cause: There is no enforced validation loop. The agent has no objective standard for telling “complete” apart from “looks complete.”

Why a Single Prompt Is Doomed to Fall Short

Abstrated one level up, these symptoms share a common cause. Building large software is a long-running, stateful, decomposable process that requires validation. A single prompt is a one-off interaction that is stateless, cannot be decomposed, and performs no validation. The capability models of the two simply do not match:

• Large models are good at “completing local tasks within a well-defined context,” but not at “planning globally and tracking their own progress.”
• Prompts are good at “expressing intent,” but not at “carrying the completion status of hundreds of requirements.”
• A model’s confident phrasing does not make it factually correct, so its conclusions must be verified with external tools.

So the right way to have an agent build million-line software is not to make the prompt longer and more “advanced.” It is to wrap the agent in an engineering task framework.

A Four-Step Engineering Methodology

1. Decompose the task and plan before coding

Instead of telling the agent to “build an application,” first have it produce a structured implementation plan. You should review this plan. It should break the work into independently verifiable modules and define each module’s inputs and outputs, dependencies, and acceptance criteria. The plan itself should be saved as a file and serve as the master reference for the entire process.

A simplified plan might look like this:

## Project Plan (sample structure)
- [ ] Module 1: Data models and persistence layer
    - Acceptance: entities defined, migration scripts run, unit tests pass
- [ ] Module 2: Core business services
    - Acceptance: contract tests cover the main flows
- [ ] Module 3: Frontend interaction layer
    - Acceptance: key pages reachable, E2E test cases pass
- [ ] Integration and deployment
    - Acceptance: end-to-end flow works, monitoring metrics reported correctly

The key is that every item must be small enough to be completed and verified within a single session.

2. Persist state and manage context

Store “current progress,” “completed items,” “open tasks and blockers,” and “key architecture decisions” in structured files outside the project, rather than in the conversation history. Every time a new session starts, the agent should first read this state file to restore context before doing any work.

• Layered context: Keep core, always-on constraints (architecture principles, coding standards) at the highest priority. Retrieve large chunks of historical detail on demand instead of loading them all at once.
• Retrieval-based loading: The agent should read only the code or documentation it needs for the current step, so irrelevant information doesn’t crowd out the context window.
• Decision records: Just as engineering teams maintain design documents, record “why we did it this way” so later sessions don’t repeatedly overturn decisions that have already been made.

3. Implement incrementally: one thing at a time

Require the agent to follow a strict loop: read state, select one unfinished module, implement it, self-check, update state. Each round advances a single small, verifiable goal. As soon as it is done, the agent updates the state file before starting the next round. If the work is interrupted along the way, the loss is limited to a single module.

4. Close the validation loop: let tools, not confidence, have the final say

This is the core defense against false completion. Every step the agent takes should be objectively verified:

• Executable checks: The agent must actually run compilation, unit tests, integration tests, and static analysis, and get results back.
• Requirements cross-check: The agent should use the plan file as a checklist and verify each item against it rather than judging from memory.
• Fail-and-loop: Any failed check is fed back to the agent as new input, driving it to fix the problem until the check passes.

Only by handing the “is it done?” decision to deterministic tools can optimistic misreports be eliminated.

Engineering Infrastructure That Supports the Methodology

For this methodology to run reliably, you typically need external infrastructure to take on the roles of “memory” and “execution.” All of these capabilities can be built with common categories of cloud products, rather than depending on any specific tool:

• Object storage / code repository: Holds state files, plan documents, and version history to keep sessions consistent.
• Message queue: Decouples long-running tasks and splits module implementation into work units that can run asynchronously and be retried.
• Container platform: Provides an isolated, reproducible runtime environment for every code build and test.
• Log service: Records the agent’s full decision and tool-call traces so failures can be traced back.
• Monitoring and alerting: Observes the progress and anomalies of long-running processes and surfaces blockers promptly.

On cloud platforms such as Baidu AI Cloud, these common capabilities (object storage, message queues, container services, logging, and monitoring) can be combined into an “external brain” for agents. This gives a stateless model a reliable foundation for state and execution.

Conclusion: From “More Advanced Prompts” to “More Engineered Processes”

The fantasy of “building million-line software with a single sentence” collapsed not because models aren’t powerful enough, but because we mismatched their capabilities. The sustainable path is to bring agent work under an engineering framework: plan first, persist state, implement incrementally, and validate in a closed loop. When context is actively managed, progress is recorded externally, and completion is determined by tools, AI coding agents stop being “writers that get lucky” and become productive tools you can actually control. The lesson of this approach is clear: let large models do the local execution they are good at, and leave planning, memory, and validation to the engineering system. Only then does automated construction of large software truly become possible.