## TL;DR

An agent that "fixes" element-not-found by adding longer and longer waits is not fixing anything; it is slow-walking the suite toward the timeout. Cap it: a wait budget of at most two increases per locator, after which the agent must pursue a different hypothesis (wrong selector, element never renders, timing vs content). More waiting is not a diagnosis.

## Error

```text
agent looped on 'element not found' by adding longer and longer waits
```

Each healing iteration bumped the wait: 5s, 10s, 30s, 60s. The element never appeared, and the suite got slower every round.

## Steps

1. Detect the pattern: diff successive healing patches for wait/timeout value increases on the same locator. Expected output: a wait-growth history per locator.
2. Enforce the budget: max two wait increases per locator per healing session, encoded in the patch linter. Expected output: a numeric rule the agent cannot exceed.
3. When the budget is spent, require a new hypothesis: capture the DOM at failure time, check the selector against it, and verify the element renders at all. Expected output: a diagnosis (selector stale, element absent, iframe context) instead of a bigger number.
4. Route genuinely slow operations to explicit one-time timeouts with a comment stating the known timing, set by a human or a measured baseline. Expected output: intentional timeouts, not grown ones.
5. Track wait-growth incidents per suite; repeat offenders get their locators reviewed. Expected output: a short list of fragile locators to fix properly.

## When to use

- Healing patches keep increasing waits on the same locator.
- Suite runtime creeps up after every healing pass.
- Element-not-found failures get "fixed" without any selector change.

## When not to use

- The operation is known-slow (large file upload, cold start); set the timeout once from a measured baseline.
- The wait increase came with a selector fix (that is a real fix that also adjusted timing).
- The environment is under provisioned and everything is slow (fix the environment, not the waits).

## Variant phrasings

### Agent added waits instead of waiting for the right state

Polling for a fixed duration instead of waiting on a condition (network idle, element attached) is the deeper bug. Require state-based waits.

### Agent wrapped everything in try/retry with sleeps

Sleep-based retries across the suite are wait inflation at scale. Same budget, applied suite-wide.

### The element appears but the test still times out

Then the locator matches the wrong element or the assertion is wrong; no wait value fixes that.

## Why it happens

"Increase the wait" is the lowest-effort patch that sometimes turns red to green, so the agent learns it as a universal fix. Nothing tells it that waits have diminishing returns or that a missing element is usually a selector or rendering problem. The budget forces the agent past the easy answer to the real one.

## Edge cases

- Flaky infra can make a legitimate wait increase the right call once; the budget allows two, which covers it.
- The agent can dodge the cap by switching wait mechanisms (sleep to retry to timeout); apply the budget per locator, not per mechanism.
- Auto-waiting frameworks already handle most timing; if the agent fights the framework's waits, the locator is almost certainly wrong.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst__FDdT7WZUnYAFJ7rGJlKcg