4x4, Product Engineering distilled to a markdown

The idea is older than agents. De Bono formalized it in 1985 as parallel thinking. Assign roles to prevent premature convergence. 4x4 is that principle applied to code agents. Agents are most useful when the product intent is clear but the implementation path is not. A checkout should not crash. The onboarding flow should recover when auth expires. The dashboard should explain the weird state before the user gets stuck. That is the new product engineering loop. Describe the behavior, send agents into the system, compare what they find, and ship the smallest fix that actually preserves the user journey. But code agents have a bad habit. They make the first plausible technical story feel complete. They mature a vertical slice end-to-end in one turn. A button crashed, so patch the button. The API returned a weird shape, so patch the client and everything that is tangled with it. The deploy failed, so patch the workflow. Sometimes that is enough. Sometimes it is the wrong frame with good posture.

The First Fix Is A Trap

Subagents are a trap too. Naive parallel agents do not automatically solve this. If four branches are all rewarded for “solving” they often converge toward the same confident patch. Different wording, same assumption. Different files, same frame. That is the expensive failure mode, not low-effort output but premature agreement. For product work, premature agreement is brutal because the wrong technical fix can still look useful. The UI gets a guard, but the payload is still wrong. The error boundary gets nicer, but the state machine still drops the cart ID. The test passes, but the user journey still breaks.

Make Branches Compete

The 4x4 skill turns one ambiguous task into four lanes with different incentives:

Explorer searches for the widest set of plausible paths.
Conservative protects contracts and minimizes blast radius.
Adversary tries to disprove the leading fix.
Verifier demands evidence, checks, and counterfactual fit.

The point is not to pick the most confident branch. The point is to pick the branch whose explanation survives the strongest opposing branch. That is the moat. Four agents are not valuable because there are four of them. They are valuable when they are paid to disagree well.

Case Study: The Broken Dashboard

Say a customer dashboard works on localhost but breaks in production after a release. A coding agent sees the blank page, opens the dashboard component, and makes the UI more defensive. It adds loading guards, catches null data, maybe wraps the chart in an error boundary. The patch looks reasonable because the failure is visible on that page.

But the product requirement is not “make the dashboard component safer.” The requirement is that a signed-in customer can land on the dashboard and see their account state. The implementation surface is bigger than the component. It could be auth state, API response shape, cache invalidation, feature flags, environment config, or a production-only redirect.

So 4x4 splits the work:

Explorer asks what else could explain a page that only fails in production.
Conservative asks for the smallest safe change that preserves the dashboard contract.
Adversary asks why a component-level patch cannot explain an environment-only failure.
Verifier asks what log, payload, session state, or production replay would separate the theories.

If the verifier lane discovers the production API response changed shape only for expired sessions, the tournament saved time. It prevented the first plausible UI fix from becoming the whole story.

When To Use It

Do not use 4x4 for obvious edits. That is ceremony. Use it when the product problem is clear but the engineering path has multiple plausible causes, prior attempts failed, blast radius is unclear, or the agent keeps circling one story. It is a skill for making disagreement useful before implementation starts.