Engineering Intelligence
Petroski used the term engineering intelligence (and related phrases like engineering judgment and engineering wisdom) to name the form of knowledge that distinguishes the engineer from the calculator. The distinction matters because calculation is the domain in which AI excels — where its speed, accuracy, and capacity to evaluate thousands of configurations simultaneously produce results genuinely superior to any human calculator. Engineering intelligence, in contrast, is the exercise of judgment about what to calculate, why to calculate it, and what to do when the calculation is insufficient. It includes calculation but also includes the selection of the problem, the identification of the relevant forces, the assessment of which failure modes are most dangerous, the decision about how much margin to maintain against conditions the calculation does not cover, and the willingness to say not yet when the calculation says a design is feasible but judgment says the understanding is incomplete. AI performs calculation. Engineering intelligence is the human activity that determines whether the calculation matters.
Intelligence as Encoded Output — Contrarian ^ Opus
There is a parallel reading that begins not from the designer's judgment but from the artifact's evolution. Engineering intelligence, in this view, has always been primarily a property of lineages—the accumulated modifications visible in successive designs—rather than individual insight. The experienced engineer's 'judgment' is not a mysterious cognitive capacity but pattern recognition trained on a corpus of prior designs and failures. What we call engineering intelligence is mostly the ability to retrieve relevant precedents quickly and apply them with contextual sensitivity.
From this starting point, AI represents not the loss of engineering intelligence but its more efficient instantiation. The model trained on millions of designs and failure analyses contains more engineering intelligence—in the sense of encoded lessons—than any individual designer could accumulate in a career. The concern about 'judgment that evaluates' assumes evaluation requires experiencing the process of generation, but evaluation has always depended primarily on recognition: does this design resemble cases that succeeded or cases that failed? AI systems can be trained explicitly on this recognition task, learning not just successful designs but the features that distinguished near-misses from catastrophes. The question is not whether the developmental process is bypassed but whether the developmental process was ever the primary source of what we value, or whether we've mistaken the phenomenology of learning for the substance of what is learned. The intelligence may transfer more completely than Petroski's framework suggests, because the intelligence was always more encoded and less experiential than the framework assumes.
In the AI Story
Engineering intelligence lives in two places simultaneously. It lives in the designer: the specific sensitivity, built through years of practice and the study of failure, that lets the experienced engineer sense when a design is approaching conditions its model does not cover. And it lives in the artifact: the specifications, dimensions, and configurations that encode, often implicitly, the resolved difficulties of previous iterations. The pencil's graphite-to-clay ratio encodes engineering intelligence about classroom legibility, manufacturing cost, and wear characteristics. The bridge's factor of safety encodes engineering intelligence about material variability, construction tolerances, and the unknown conditions the future will bring.
AI can preserve access to the intelligence embedded in artifacts. Training data containing past designs, past failures, and their analyzed causes can be incorporated into models that generate new designs reflecting these lessons. The preservation is partial — embodied and contextual knowledge is particularly hard to capture in training data — but it is meaningful. An AI-generated bridge design will typically incorporate more encoded engineering intelligence, in the sense of historical lessons learned, than a bridge designed by a single engineer working alone could possibly contain in her individual judgment.
What AI cannot preserve, Petroski's framework implies, is the intelligence that lives in designers — because this intelligence is developed through the process of designing, encountering failure, and modifying practice in response. When AI performs the design, the engineer does not perform the design, which means the developmental process that produces engineering intelligence is bypassed. The engineer reviews outputs rather than generating them. Review is a legitimate engineering activity, but it does not develop the same form of intelligence that generation develops, because the assumptions embedded in a design are most visible to the person who had to select them during construction.
This creates what Petroski's framework suggests is an intergenerational problem. The current generation of engineers — trained before AI became a dominant design tool — possesses engineering intelligence developed through pre-AI methods. They can review AI outputs with judgment calibrated by their own design experience. The next generation, whose design experience is increasingly mediated by AI from the start of their training, may possess familiarity with AI tools without possessing the underlying engineering intelligence that lets them evaluate AI outputs against the conditions the AI cannot see. The tools will become more capable; the judgment that evaluates them may become less so. The relationship between tool capability and reviewer capability is the relationship on which engineering safety depends.
Origin
The concept of engineering intelligence as distinct from engineering calculation is older than Petroski, with formal articulation in the work of philosophers and historians of engineering including Walter Vincenti, Eugene Ferguson, and Louis Bucciarelli. Petroski's contribution was the detailed illustration of engineering intelligence operating — and failing to operate — in specific historical cases, and the articulation of how it is cultivated, transmitted, and potentially lost. The framing appears across his work, most extensively in Design Paradigms (1994) and The Essential Engineer (2010).
Key Ideas
Engineering intelligence lives in both artifacts and designers. The specifications of a well-designed object encode lessons learned. The judgment of an experienced designer encodes the developmental process that produced those lessons. Both forms are necessary; they are not substitutes for each other.
Calculation and judgment are different cognitive activities. Calculation determines quantities within a specified framework. Judgment evaluates whether the framework is sufficient. AI excels at the first; the second remains a human activity because it requires the capacity to recognize what the framework has omitted.
Generation develops judgment; review does not. The engineer who constructs a design encounters its assumptions one at a time. The engineer who reviews a design constructed by AI encounters the output, not the assumptions. The developmental difference is structural, not a matter of effort or diligence.
The AI era may produce tool-capable engineers with attenuated judgment. If AI mediates increasing fractions of the design process from the start of engineering training, the cultivated sensitivity that constitutes engineering intelligence may not develop to the depth previous generations achieved. The consequences compound generationally.
Debates & Critiques
Proponents of AI-augmented engineering argue that engineering intelligence can be progressively encoded into AI systems themselves — that judgment, like calculation before it, can ultimately be captured in algorithms trained on sufficient data about expert engineering decisions. The Petroski response is that this encoding captures the outputs of past judgment (the decisions experienced engineers have made) but not the developmental process that produced those decisions. A system trained on expert decisions becomes increasingly capable of reproducing decisions similar to those in its training data. It does not, by that training, become capable of recognizing the conditions under which the decisions in the training data would have been wrong — because those conditions are not in the training data. The gap between what is encoded and what engineering intelligence does remains, and it is the gap that matters most when the conditions that will test a design have not yet been encountered.
Appears in the Orange Pill Cycle
Generation Versus Recognition Tasks — Arbitrator ^ Opus
The weighting depends sharply on which aspect of engineering intelligence we're examining. For pattern recognition within known domains—identifying load configurations similar to past failures, selecting materials with appropriate safety factors for familiar applications—the contrarian view is approximately 70% correct. This component of engineering intelligence is substantially capturable in models trained on extensive design histories, and AI systems can execute this recognition task with greater consistency than most individual designers.
For judgment about problem framing and adequacy assessment—recognizing when a design approaches conditions the model doesn't cover, deciding whether understanding is sufficient to proceed—Edo's framework is approximately 85% correct. This component depends critically on the designer's encounter with the gap between specification and reality, and this encounter is structurally different in generation versus review. The engineer who constructs a design must articulate assumptions explicitly; the reviewer inherits them implicitly. The developmental difference matters.
The synthetic frame the territory requires is not 'intelligence in designers versus intelligence in artifacts' but intelligence as a distributed system requiring both encoded precedent and generative encounter. AI excels at the first; human development through design produces the second. The intergenerational question is whether training processes can be redesigned to preserve generative encounter while leveraging AI's superior encoding—perhaps through deliberate 'learning failures' where AI tools are constrained to expose designers to the assumption-selection process. The intelligence we need is neither purely in judgment nor purely in encoding but in the productive interaction between them.
Further reading
- Henry Petroski, The Essential Engineer (2010)
- Walter Vincenti, What Engineers Know and How They Know It (1990)
- Louis Bucciarelli, Designing Engineers (1994)
- Eugene Ferguson, Engineering and the Mind's Eye (1992)