The impact hierarchy is why you review design, not code

There's a failure mode in agentic engineering that's hard to name until you've lived through it. You review code your agent produced. You find something wrong. You fix it. The agent produces more code. Something wrong again. Different line, same shape of problem. You're fixing symptoms.

The root cause is one level down, in the plan, or two levels down, in the design, or deeper still, in the shared context files your whole team's agents read at the start of every session. The impact hierarchy is the name for that pyramid of levels (infrastructure, research, design, planning, code), where errors at the bottom amplify into everything above, and human judgment belongs at the bottom.

A pyramid showing the five levels of the Agentic Engineering Impact Hierarchy. At the wide bottom, Core Infrastructure: 1 bad line → 10,000 LOC. Up through Research (→ 1,000 LOC), Design (→ 100 LOC), Planning (→ 10 LOC), to Code at the narrow top (→ 1 LOC). Each level amplifies errors ~10x into the level above.

One bad line of code stays one bad line. That is the tip of the pyramid. But one bad line in a plan ripples into an order of magnitude more code. One bad line in the design ripples further. Bad research further still. Bad core infrastructure (your AGENTS.md, your shared context files) can corrupt everything.

Fix the cause, not the symptom

The clearest example from my own notes: I experimented with an audio library, concluded it didn't work, and wrote that conclusion into the shared AGENTS.md as a permanent constraint. All four team members' subsequent agent runs were told the library didn't work. A lot of time and bad workarounds followed. The real defect was a false conclusion in the shared infrastructure. Fixing downstream workarounds individually would have been useless. The fix had to happen there.

A cascade showing how one bad line in infrastructure became thousands in code. A false constraint in Core Infrastructure (AGENTS.md: "audio-library-X does not work") propagates through four developers' agent runs, each producing ~1000 wasted lines of unnecessary workarounds. The fix belongs at the source (AGENTS.md), not at any of the downstream workarounds.

The original framing comes from HumanLayer's Advanced Context Engineering. The key takeaway: "When you review the research and the plans, you get more leverage than you do when you review the code."

A shared vocabulary for disagreements

Before I had this framing, design disagreements in PR review felt ineffective. Someone would leave a comment on a generated interface. Someone else would defend it. The argument would circle back to what the agent had actually produced, as if the code were the ground truth. Once that shared reference exists, the vocabulary follows. Trace a real case from a line-level symptom back to its source layer and "this is a design-layer problem, not an implementation problem" lands without argument.

The hierarchy has two jobs: it helps you reflect on where review belongs in the agentic workflow, and it gives teams a shared vocabulary for disagreements when something goes wrong.

It's not about only reviewing design or AGENTS.md. "Review the plans, not the code" gets misread as "you don't need to read AI-generated code." Wrong. Review the code. When you find a defect, take action at the source. Go to the deepest level where the root cause lives.

Start one level below the symptom

Your AGENTS.md or equivalent shared context files are the highest-impact artifacts you control. A bad constraint written into AGENTS.md poisons every downstream agent run. Maintaining these files is among the most consequential work a team can do.

The hierarchy tells you which surface to look at: one level below where you saw the symptom. If the code looks wrong, review the plan that produced it. If multiple plans look wrong, review the design. The surface you want isn't always obvious from the symptom, but the hierarchy gives you the floor to start from.