Signs the loop has gone bad

A session can fail slowly

The failures worth catching are not the dramatic ones. They are the sessions that feel productive for two hours and produce a change nobody should merge. Here are the signals, roughly in the order they appear.

The early signals

The diff is growing and you have stopped reading it. The most reliable indicator of all. If you cannot say roughly how many lines have changed and which files, you are no longer working: you are watching.

You have not run anything for twenty minutes. Steps that end in something executable are what keep the cost of being wrong bounded. A long stretch with no execution means the error, when you find it, could be anywhere in the whole stretch.

You are explaining rather than specifying. Long paragraphs of justification, restating what you already said in different words. That is arguing, and arguing means restart.

You have accepted something you did not understand and told yourself you would come back to it. You will not, and it is now load-bearing.

The middle signals

Tests are being changed to match code. Watch for this specifically in the diff. A test whose assertion moved to accommodate a new implementation is either a genuine correction, in which case somebody should say so out loud, with a reason, or it is the bug being ratified.

New dependencies you did not ask for. Check package.json, requirements.txt, go.mod, Cargo.toml in every session’s diff. Something got added to solve a problem you could have solved with nine lines, and it is now part of your supply chain.

The file count is drifting past what the task needs. A change to date formatting that touches eleven files is doing something else as well.

Suppressions are appearing. # type: ignore, eslint-disable, @SuppressWarnings, any, a widened exception. Each of these is a check being switched off to make progress.

The late signals

You cannot describe the change in one sentence. If “what does this pull request do” needs a paragraph with an “and also” in it, the change is several changes and none of them has been reviewed.

You are hoping the tests are right rather than knowing. The moment you notice yourself relieved that CI is green rather than confirming it, the suite has become a wish.

You would not defend this in review. The strongest signal and the easiest to check. Imagine a colleague asking why line 47 is there. If the honest answer is a shrug, the work is not finished, regardless of whether it functions.

What to do at each stage

Early: stop, run something, read the diff, commit what works and discard the rest. Ten minutes.

Middle: git stash or git checkout ., and go back to the last commit that worked. This is the moment where people push on because so much has been done. There is nothing to lose: the code either works and is understood, or it does not, and no amount of it is worth keeping in the second case.

Late: put it down entirely. Come back tomorrow, or hand it to somebody else, or do it by hand in a quarter of the time now that you know what it involves.

The two-line log that makes this concrete

At the end of any session longer than an hour, write two lines in a scratch file:

2026-09-08  fx conversion.  3 restarts.  ~90 min.  Merged.
            Restart 2 was the real one — it kept using the rate table
            directly because I never attached rate_provider.py.

After a month you will have a list of your own failure patterns, and they will be more specific than anything in this course. Most people find the same two or three recur: a file that was never attached, a constraint never stated, a task too large to have been asked as one thing.

Those are fixable, and they are only fixable if you can see them, which requires writing them down at the moment they happen rather than reconstructing them later, which, as the first module established, you cannot do accurately.

One more signal, from the other side of the desk

If you manage people, the equivalent signal is a pull request whose author cannot answer a question about it within a few seconds. Not a hard question: any question. That gap between submitting and understanding is the whole failure mode of this era, and it is visible for free in a two-minute conversation, long before it is visible in any metric you could put on a dashboard.