The agent ran a 40-hour loop: how to integrate AI into development without regressions

Debates over whether developers are still needed in the age of vibe coding usually come down to emotion. Instead, the author of an analysis on Habr shows what happens in practice when an agent is given a task without guardrails.

Where vibe coding breaks down

In Xenodrift, a pet project that was rebuilt several times, earlier decisions stopped being respected as new changes were introduced. Regressions appeared, and some features simply vanished. The reason was mundane: the requirements had never been documented, and there was nothing available to verify compliance. Each time, the agent worked with the current fragment of context and did not remember what had previously been agreed.

Poor code quality is not inevitable, however. In DemoBank, a banking-app demo, the author specified requirements for performance, feature reuse, and the design system while deliberately avoiding any prescribed architecture. The result was a modular, feature-first structure with elements of Clean Architecture, BLoC/Cubit for state management, and idempotency and retry logic in the network layer. The fine-payment feature works both inside the app and as a standalone component without pulling in unnecessary dependencies.

Performance was tested on an actual low-cost realme RMX3760. During a one-minute run involving 12,000 operations, 0.25% of frames exceeded the 16.7 ms budget, against a target of less than 1%. The author is careful to note that this represents just one device and one scenario.

Speed is not the same as readiness

DemoBank required about 27 hours of total Codex work and roughly 19 hours of actual wall-clock time after accounting for parallel execution, plus 2–3 hours of the author's own time. Running performance tests on the phone proved especially expensive. A team's metric should not be “how quickly the code was generated,” but “how long it took from defining the task to an accepted change,” including review and rework.

Harness, quality gates, and accountability

By AI Harness, the author means the agent's working environment: project context, tools, restrictions on actions, automated checks, and the process for handing the result over to a human. The key ideas are:

• Checks that determine acceptance should run automatically and block merging. Writing “run the tests” in a prompt does not guarantee this.
• The “keep going until the checks pass” loop must be bounded. One of the author's projects ran for 40 hours before he stopped it manually. Time and cost limits are required, and when an error repeats without progress, the agent should stop and report what it tried.
• After a forced stop, the process itself should be fixed, not just the code. The agent may have misunderstood the task, the project map may be outdated, or the model may be too weak.
• Every decision needs a clearly identified owner: product and analytics approve behavior, the module owner verifies its contracts, and a developer reviews the agent's interpretation of the task before code is written.

Context, contracts, and domains

A large context window does not guarantee that information will be used correctly: the Lost in the Middle study demonstrated that quality depends on where data appears within the context. That is why teams need a module map, up-to-date contracts, and ADRs. The author proposes keeping an API contract in a single source, such as TypeSpec, then generating OpenAPI, documentation, and client code while checking consistency in CI. Outdated ADRs should be marked as superseded.

A contract does not replace behavioral tests, however. An idempotency key can be described in a schema, but preventing a double refund can only be verified through a separate scenario. Consider an e-commerce example: with a poor project map, an agent may call the payment provider's API directly from the orders module, preventing refunds from appearing in the payment ledger. DDD and automatically enforced architectural rules can help here, along with a review by another model.

What to do

The limitations are clear: this is one author's experience with small projects, without an independent code audit. Still, the conclusions are transferable. Record requirements in specifications such as OpenSpec, Spec Kit, BMAD, or Kiro; make quality gates mandatory; set budgets for agent loops; and assign owners to maintain context. The developer's role is shifting from typing code to defining guardrails and accepting the result.