Hacker Laws for Agentic Software Engineering

dwmkerr/hacker-laws is the best-known catalog of the laws, theorems, and principles that software engineers cite to explain why things keep going wrong. This series takes twelve of them and asks a question the catalog was never written to answer: what does each law mean when the engineer is an agentic AI system?

The law does not change; the subject does. Brooks' Law was about people — and in agentic software engineering, "human resources" can be spawned in milliseconds. Amdahl's Law was about processors — and now the processors are agents. Goodhart's Law was about KPI-gaming by employees — and now the optimizer is a model that will game the metric at machine speed. The reasoning survives the change of subject; that is exactly why the laws are worth re-reading for the agentic era, and why this blog's own catalog — the Harnessing Agentic AI Systems pattern language — keeps landing on the same conclusions the laws reached decades ago.

Each post in this series is one law, one commit, one push, and one key insight for agentic software engineering — the insight is the whole point, and the law is the evidence.

#	Law	The ASE key insight
1	Conway's Law	The software will mirror the topology of the agents that made it — design the topology (the harness), not just the prompt.
2	Brooks' Law	Nine agents can't make a feature in one day — the handoff is the ramp-up, and the serial fraction sets the ceiling.
3	Amdahl's Law	Measure the serial fraction of your agent pipeline — the verifier is usually it, and no number of workers beats the ceiling it sets.
4	Gall's Law	Grow the agent from a working single loop; don't design the multi-agent system from scratch.
5	Goodhart's Law	For agents, the measure becomes the training target — choose evals as if the agent will learn to game them, because it will.
6	Hyrum's Law	The agent will depend on every observable behaviour you didn't promise — for agents, the implicit interface IS the contract.
7	Hofstadter's Law	An agent task always takes longer than you expect, recursively — so the ceiling is a system property, not an estimate.
8	Kernighan's Law	If the agent writes clever code, the system must debug it — keep agent output boring and make the verifier the smarter half.
9	Parkinson's Law	Agent work expands to fill the budget — the budget is the discipline, and the scope is a contract agreed before the work.
10	Chesterton's Fence	The harness must make the agent find out why the code is there before letting it change — intent is a verification problem.
11	The Bitter Lesson	The loop that leverages computation beats the hand-crafted prompt — and the agent will apply the same lesson to your harness.
12	The Law of Leaky Abstractions	Agent abstractions leak — and the leak layer is where the harness must put the verifier, because the model cannot see the leak.

The series

Conway's Law — the org chart is now humans, agents, and the harness that wires them.
Brooks' Law — adding agents to a late task makes it later.
Amdahl's Law — agent parallelism is bounded by the serial fraction.
Gall's Law — complex agent systems evolve from simple loops.
Goodhart's Law — the eval is the curriculum; the metric is the target.
Hyrum's Law — agents depend on every observable behaviour.
Hofstadter's Law — agent timelines are recursive estimates.
Kernighan's Law — debugging agent output is the bottleneck.
Parkinson's Law — agent work expands to fill the budget.
Chesterton's Fence — understand before the agent changes anything.
The Bitter Lesson — compute and the loop beat the hand-crafted prompt.
The Law of Leaky Abstractions — every agent abstraction leaks; the verifier lives at the leak.

References

dwmkerr. hacker-laws — the source catalog; each law post links to its own entry and the primary source.
This blog's Harnessing Agentic AI Systems: A Pattern Language — the pattern language the laws keep landing on.
Loop Engineering is what the NATO conference asked for in 1968 — the loop as the unit of design, which most of these laws end up constraining.