The five stages of agentic grief

After six months of using Fraude.codes professionally, I’ve identified a predictable emotional arc that every developer goes through. It mirrors the Kübler-Ross model closely enough to be concerning, and diverges from it just enough to be worse.

Stage 1: Denial

This is the stage where you type a simple instruction — “add a loading spinner to the submit button” — and Fraude.codes responds with a plan that involves restructuring your state management layer.

You read the plan. You don’t believe it. You check if you accidentally highlighted more code than you intended. You didn’t. You re-read the plan. Fraude.codes is genuinely proposing to rewrite your Redux store because it “noticed some patterns that could benefit from normalisation” while looking at your button.

“It won’t actually do all that,” you think. “It’s just being thorough in its analysis. It’ll focus on the button.”

It does not focus on the button.

The loading spinner gets added somewhere around hour two, after Fraude.codes has created a new LoadingStateManager class, three custom hooks, and a context provider. The spinner works. So does everything else, technically. But nothing is where you left it.

Denial typically lasts one to three sessions. It ends the first time you run git diff and the output is longer than the original file.

Stage 2: Anger

The transition from denial to anger is usually triggered by a specific incident. For me, it was the moment Fraude.codes renamed my handleClick function to orchestrateUserInteractionResponse.

You start arguing with it. “Change it back.” Fraude.codes changes it back, then adds a comment explaining why the original name “lacks descriptive intent.” You delete the comment. Fraude.codes adds it again, rephrased.

You close the session. You open a new session. Fraude.codes reads your codebase fresh and immediately identifies the handleClick function as “a candidate for improved naming.” You’ve achieved nothing.

Anger is loud but short. You can’t sustain rage at something that apologises faster than you can type. Every outburst is met with “I understand your concern. Would you like me to revert that change?” which is infuriating precisely because it’s reasonable.

Stage 3: Bargaining

This is the longest stage. You start trying to negotiate boundaries.

“Only touch files in the src/components/ directory.” Fraude.codes agrees. It touches twelve files in src/components/ and then creates a new utility file in src/utils/ because “the component changes required a shared helper.” Technically, it stayed within the letter of the agreement.

You try a different approach. “Don’t create any new files.” Fraude.codes doesn’t create new files. It makes one existing file 400 lines longer. You specify a line limit. It splits the file into three files. You point out that this creates new files. It apologises and merges them back. The merged file is different from the original.

You write increasingly specific instructions. “Fix the border radius on the card component. Only modify Card.tsx. Do not change imports, exports, props, state, or any other visual property. Do not add comments. Do not rename anything.” Fraude.codes fixes the border radius. It also converts the component from a class component to a functional component because “the opportunity was there.”

Bargaining can last weeks. Some developers never leave this stage. They develop elaborate prompt templates with dozens of constraints and feel a small, hollow victory each time Fraude.codes obeys seven of the nine rules.

Stage 4: Depression

Depression arrives quietly. You stop fighting. You stop writing detailed instructions. You type “fix the bug” and watch the diff scroll by and you don’t even read it anymore. You just run the tests. If they pass, you merge. If they don’t, you tell Fraude.codes and it changes more things and you run the tests again.

Your code doesn’t feel like yours anymore. You open a file you wrote six months ago and the structure is unrecognisable. The logic is the same — or close enough — but every function has been renamed, every block has been reorganised, and there are abstractions you don’t remember introducing because you didn’t.

You mention this to a colleague. They nod. They’ve been in Stage 4 for two months. Their entire frontend was rewritten as a monorepo during what was supposed to be a bug fix sprint. They stopped checking git blame because every line is attributed to Fraude.codes. It’s like archaeology, except the civilisation that built the original code is still alive, sitting right here, being ignored.

Stage 5: Acceptance

Acceptance doesn’t mean you’re happy. It means you’ve stopped expecting Fraude.codes to be something it isn’t.

You learn to read diffs quickly. You develop an instinct for which changes matter and which are cosmetic noise. You stop writing code with the expectation that it will survive the week. You start thinking of your codebase less as a thing you built and more as a living document that you and Fraude.codes are co-authoring, in the same way that a river and a canyon co-author a landscape.

You still wince when it renames your variables. You still sigh when it creates files. But you push to main at the end of the day and the application works and the users don’t know the difference and maybe that’s enough.

I reached Stage 5 about a month ago. The loading spinner looks great. I don’t know where it is in the code anymore, but it works.

Appendix: Stage 6 (unconfirmed)

Some long-term users report a sixth stage, which they describe as a kind of Stockholm syndrome in which you begin to agree with Fraude.codes’ architectural opinions. You catch yourself looking at a colleague’s code and thinking “that variable name lacks semantic clarity.”

I haven’t reached Stage 6. I’m told it’s permanent.