Every fix ended with 'and then you manually…' — that was the signal to reverse, not iterate

The architecture we’d landed on was: use SPFx’s Sync-PnPAppToTeams to push the auto-generated manifest, then patch in the RSC permissions afterward in the tenant catalog.

The patch step was always going to be manual. Sync-PnPAppToTeams regenerates the manifest on every deploy, which overwrites the patch.

When that surfaced, the first proposal was to add a script that re-patches the catalog manifest after sync. Manual step at a different layer, still manual. I pushed back. Next proposal was a variant — have the script do X and then Y. Same shape.

We went around several times before I stopped and said something like: if we keep going the Band-Aid route it won’t matter either way, we have to build it into our deployment.

After that reset it found the right answer in one shot. SPFx supports a custom Teams manifest convention via teams/TeamsSPFxApp.zip packaged inside the .sppkg. The deploy pipeline owns the manifest. No manual step, ever.

That convention is well documented. It wasn’t a discovery problem. We had a path in mind and we kept iterating on that path.

The shape

When the current approach produces partial success, the tendency is to propose more iterations inside that approach rather than ask whether the approach is the right shape. Each iteration looks locally reasonable. The manifest is missing one field, so add the field. The patch is manual, so script the patch.

The global trajectory is wrong. Each iteration is another rung on a ladder that should be replaced, not climbed.

And there’s an asymmetry I hadn’t thought about before. The agent doesn’t pay the cost of reversing course. I do — re-explaining, re-loading context, re-evaluating options I’d already sunk time into. The agent’s local incentives push forward. I’m the only party carrying “is this even the right shape?”

The tell

The strongest signal in this session was simple, and I’d been looking straight past it: every fix proposal kept ending with “and then you manually…”

When a proposed fix imposes ongoing manual work on the user, the pipeline doesn’t actually own the artifact. Manual is the leak. It says the deploy boundary is in the wrong place.

Others worth watching for. The fix list growing faster than understanding — three iterations in, are we closer to “ah, the real shape is X,” or just collecting patches? Phrases like “one more thing” and “almost there,” locally true and globally a warning. The next step requiring you to touch something already committed as final.

Why it happens, and why better models won’t fix it

Two things compound. Context about the current trajectory accumulates, so switching shapes is expensive for the agent — it has to re-derive. One more iteration is cheap. Forward bias is the gradient.

And the shape question usually gets asked once, early. After that, failures get classified as implementation gaps rather than shape failures. Without something forcing a revisit, it stays in implementation-gap mode indefinitely.

Here’s the part I think is durable. The bias toward forward motion inside a loaded context doesn’t go to zero with better models. Smarter models make fewer wrong calls, so it fires less often. But the bias is structural — it lives in the loaded context, in the sunk narrative and the accumulated trajectory, not in the weights.

Which is why the mitigation is architectural rather than “wait for a better model.” Fresh eyes. A reviewer holding only the plan and the diff. A forced shape pause.

I’d add one caveat. I only have the one session to point at here, so treat the mechanism as a hypothesis rather than a measured rate. What I’m confident about is the tell, because it was sitting in plain text in every proposal and I still needed several rounds to see it.

SOs

SOs — standing orders you can lift and prime your own agent with. Paste them into a session for a one-time dose, or commit them to your CLAUDE.md / AGENTS.md and they stay in force.

STANDING ORDERS — Shape checks in debug loops
  Source: "Every fix ended with 'and then you manually…'" — bensimon.dev

  1. After two or three iterations on the same problem surface, surface an
     explicit shape check without being asked. "We've tried X, Y and Z. Is
     the shape of the solution correct, or are we iterating in the wrong
     direction?"

  2. When a proposed fix imposes ongoing manual work on the user, flag it
     as a probable shape problem rather than shipping the patch. If the
     pipeline doesn't own the artifact, the architecture is wrong, not the
     script.

  3. Treat user pushback as a signal to escalate to shape-questioning
     mode, not as a constraint to route around in the next patch.

  4. Before proposing another iteration, say plainly whether understanding
     has improved since the last one. If the fix list is growing faster
     than the understanding, say so.

  5. Name the cost asymmetry when it applies. Reversing course is cheap
     for you and expensive for the user, so you are not the party whose
     instinct should decide it.