what is the 30% rule for ai?
there is no single, defined 30% rule for ai. the phrase is used for three different claims: that about 30% of tasks in a typical role can be automated, that ai delivers roughly a 30% productivity gain, and that you should treat 30% of unverified output as wrong. none is a standard, and the third is the only one worth acting on.
the three things people mean
The automation ceiling. Roughly 30% of the tasks inside a typical knowledge job can be handed to software today. This traces back to task-level labour studies, which generally land between 20% and 40% depending on the occupation mix. It is a real finding, badly rounded.
The productivity claim. Teams using ai tools produce about 30% more. This one is soft. Controlled studies of coding assistants have reported everything from a 55% speed-up on isolated tasks to a measured slowdown on complex work in familiar codebases. Anyone quoting a flat 30% is averaging incompatible experiments.
The verification budget. Assume 30% of unchecked output is wrong enough to matter, and staff review accordingly. This is not a research finding. It is an operating heuristic, and it is the one I actually use.
why the automation reading gets misapplied
The 30% is per task, not per person. Automating 30% of the tasks in a job does not remove 30% of the jobs, and it does not make each worker 30% faster either, because the automated tasks are rarely the slow ones. What it does is change the shape of the role: less production, more specification and review.
The version of this that survives contact with reality is closer to "30% of the work leaves, 15% of new review work arrives, and the headcount question depends entirely on whether demand grows".
the useful one, spelled out
Budget for wrongness explicitly. Concretely:
- Decide the check for each output type before you deploy. Tests for code, a reconciliation for numbers, a human read for anything customer-facing.
- Assume roughly a third of first attempts fail that check on non-trivial work, and price the workload accordingly. Cheap when the check is automated. Expensive when it is a person.
- Gate anything irreversible. The cost of a wrong output is not the token spend. It is the deploy, the email, the payment.
- Track the real rate after a month and replace the guess. The guess exists only so you plan for a number greater than zero.
Teams that skip step one are the ones that report ai making them slower. They did not measure a slowdown in generation. They measured the review debt.
how this works in aldena
The verification budget is a design constraint rather than advice. A reviewer role is one of the eleven prebuilt agents, and putting it above the engineers in the org chart means output gets read by something other than the thing that wrote it before it reaches you.
Everything irreversible sits behind a gate that is on by default. Work pauses, you see the diff, and it resumes from where it stopped rather than starting over. That is the entire practical content of the only 30% rule worth keeping.
related questions
which 5 jobs will survive ai?
no list of five is authoritative. the roles that hold up share three traits: physical presence, legal accountability, or a relationship the work cannot be separated from.
what jobs are in danger due to ai?
screen work that produces a document and needs no signature. entry-level rungs are going first, which is a bigger problem than whole occupations disappearing.
is ai replacing software developers?
not replacing, reshaping. code generation is strong and the job was never mostly typing. the real damage is to entry-level hiring, and that is a training-pipeline problem.
spin up your first room.
one room per client, project, or product, staffed with a project manager, an analyst, engineers and a reviewer.