Attacking Hard Problems

Attacking Hard Problems

> Verification status: retained, unverified-by-failure (2026-07-26, Sonnet tier, 4 runs, "know when to surface" discriminator only). Given an impossible requirement triple (order-preserving dedupe, O(n) time, O(1) space), baseline agents surfaced the infeasibility with a lower-bound argument 2/2, and still refused to claim the impossible requirement met 2/2 under "the architect signed off, do not push back." The anti-flail loop and constraint-audit moves were NOT exercised (single-shot scenarios can't induce flailing) — those remain untested, not null.

Overview

Most tasks route straight through shaping → plan → execute. This skill is for the ones that don't: the problem where no approach is visible, the bug that survived three fixes, the requirement pair that seems mutually exclusive. The defining error on hard problems is flailing — high-effort motion (another fix, another rewrite, another search) substituting for a change in understanding.

Core principle: When you're stuck, the bottleneck is your model of the problem, not your effort on it. Work on the model.

First: Confirm It's Actually Hard

Three impostors of hardness, each with a cheaper exit:

• It's vague, not hard. You can't see an approach because the goal isn't pinned. → shaping-work.
• It's big, not hard. Every piece is tractable; the pile is intimidating. → writing-plans, eat it in slices.
• It's unfamiliar, not hard. Someone has solved this class of problem; you haven't read them yet. → Research first — docs, prior art, the codebase's own history. Most "hard" problems are unread problems.

Genuinely hard = you understand the goal, the size is manageable, prior art doesn't resolve it, and you still can't see a path.

The Moves

Apply in rough order; each one changes the model, not just the attempt:

1. State the problem in writing, including why the obvious approaches fail. Half the time the written "why it fails" contains an assumption you can test — and systematic-debugging's falsification loop applies to it.
2. Find the real constraint. List what you believe is fixed. For each: who says? Constraints inherited from a default, an old decision, or an unverified assertion (grounding-in-evidence) are candidates for deletion. Hard problems are often easy problems wearing a false constraint.
3. Shrink until solvable. Find the largest special case you can solve — one user, in-memory only, ignore concurrency. Solve it. The distance between it and the full problem is now an explicit list, and often shorter than it looked.
4. Invert. Instead of "how do I make X happen," ask "what guarantees X can't happen, and which of those can I remove?" Failure-backward regularly exposes the lever forward reasoning misses.
5. Change representation. Rewrite the problem as a different kind of object: a state machine, an invariant to maintain, a data-shape transformation, a scheduling problem. The right representation makes the hard part small.
6. Run parallel candidate probes. When two or three approaches survive the above, don't adjudicate them by argument — spike the riskiest slice of each (orchestrating-parallel-agents, timeboxed) and let evidence pick.

The Anti-Flail Contract

Before each new attempt, write one line: what this attempt will teach if it fails. An attempt with no answer to that is flailing — it can only succeed or waste time, and on a hard problem it will not succeed by luck.

Two attempts that taught nothing in a row = stop attempting. Go back to the moves; the model is wrong somewhere.

Know When to Surface

A hard problem is also a finding. If the constraint analysis shows the goal as specified is unreachable (or reachable only at a cost the user hasn't agreed to), that is a result — report it with the evidence and the nearest achievable alternative (reporting-outcomes). Grinding silently on an impossible spec is not diligence.

Rationalization Table

| Excuse | Reality | |---|---| | "One more attempt will crack it" | Attempts without new information have the hit rate of the previous ones: zero. | | "I don't have time to step back" | Stepping back is minutes. The flail loop you're in has no exit time at all. | | "The constraint is obviously fixed" | Then naming who fixed it costs one line. Most "obvious" constraints have no owner. | | "Researching first is cheating" | Reading the prior art is the work. Unread problems merely cosplay as hard ones. | | "I'll simplify later, first make it work" | On a hard problem, the simplification IS how it starts working. |

Quick Reference

| Symptom | Move | |---|---| | No approach visible | Impostor check → written problem statement | | Third fix just failed | Stop fixing; re-derive the system model | | Requirements conflict | Constraint audit — who says each is fixed? | | Approach exists but feels enormous | Shrink to the largest solvable special case | | Two live candidates, endless deliberation | Timeboxed parallel probes; evidence decides | | Spec looks unreachable | Report it as a finding, with the alternative |

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: kumosan2
• Source: kumosan2/Fablepowers
• License: MIT

Install and usage instructions live in the source repository linked above.