Synthesis, Human and Machine: Bloom's Taxonomy, Program Induction, and the Skill Neither Memorising Nor Automation Can Replace

GenerativeGenerative AI has made it easy to produce something that looks like an original piece of work — an essay, a design, a working program — without a person having done the combining themselves. That's forced a genuinely useful question back onto educators and students alike: what does "synthesis," in the sense education has always claimed to value, actually require, and how much of it can a machine now do? PatLang, an experimental programming language documented extensively elsewhere on this site, happens to have a real, inspectable system that induces new code from examples — not a black-box neural network, but a search process every step of which its own developers have documented in detail, including exactly where it succeeds and exactly where it hits a wall. That transparency is what makes a careful, non-overclaiming comparison to human synthesis possible at all.

Where "synthesis" sits, and why the order of the levels matters

AndersonAnderson and Krathwohl's widely-used revision of Bloom's taxonomy of the cognitive domain orders six levels of increasing demand: remember, understand, apply, analyse, evaluate, create¹. That ordering is a genuine, deliberate correction to Bloom's original sequence, which placed synthesis before evaluation² — and the correction matters substantively here, not just as a historical footnote. Putting evaluate before create reflects a real claim about how synthesis actually works: combining elements into something new requires, as a precondition, the capacity to judge which candidate elements and combinations are actually appropriate. That judgement — discriminating a fitting choice from a plausible-looking wrong one — is itself an act of evaluation. A student (or a system) that cannot evaluate cannot meaningfully create; they can only recombine whatever's put in front of them and hope.

"Create" is not analysis (which takes something apart) and it is not application (which correctly executes a known procedure on a new instance of a familiar problem). It's the level at which someone stops using a given structure and starts producing one — and, per the ordering above, they can only do that reliably once they can also judge, among several plausible combinations, which one actually fits.

Why this matters for employability now

TheThe National Research Council's review of transferable knowledge and skills argues that the specific value of formal education, from an employability standpoint, increasingly lies in skills that transfer across novel situations rather than the specific content mastered in any one course³. Tasks that consist of correctly applying a known procedure to a recognisable, well-specified problem are precisely the tasks most exposed to automation, whether by traditional software or by the current generation of generative AI — a point this site's own material on AI and the workplace develops in more depth⁴. Tasks that require deciding which procedure applies, justifying that choice, or noticing that none of the available procedures actually fit, sit higher up the taxonomy — at the evaluate-then-create end — and, on current evidence, are considerably harder to automate away. Teaching that quietly rewards correct execution of a named technique, dressed up as "synthesis," produces graduates well-drilled at exactly the layer of skill most exposed to automation, and comparatively unpractised at the layer that isn't.

What PatLang's synthesis engine actually does

PatLang'sPatLang's inductive synthesis system reads Given/When/Then BDD scenarios — plain-English worked examples — and searches for a general PatLang rule that explains all of them, without a person writing that rule by hand⁵. A companion page shows the mechanism live: an Account object's withdrawal logic and a three-state ticket workflow, both derived entirely from example tables rather than hand-written, running in the browser via the project's own compiled interpreter⁶. It genuinely earns the word "synthesis": the output is real, compilable, previously-nonexistent code, assembled from a declared library of background facts and primitive operations rather than retrieved or copied from anywhere. Under the hood it combines several techniques depending on the shape of the problem — classical top-down and bottom-up inductive logic programming (ILP) for rule-shaped targets, generalising by anti-unification across witnessed examples^{7 8}, and a separate bottom-up enumerative search over primitive operations for expression-shaped targets, building up from small compositions to larger ones and stopping at the smallest that satisfies every example. Both modes deliberately reject overfitting: worked examples in the project's own documentation include background facts or operations that are true of a positive example but not actually required for the answer, and the engine is tested as carefully on correctly refusing to include that distractor as it is on finding the correct answer at all — that refusal is, in the terms above, the engine performing a genuine act of evaluation before it commits to a synthesis.

Where the comparison to human synthesis holds up

Lake,Lake, Salakhutdinov and Tenenbaum's influential account of human concept learning argues that people acquire new concepts from remarkably few examples by treating learning as a form of program induction: searching a compositional space of already-known primitives for the smallest program consistent with what's been seen, rather than adjusting weights on a purely statistical model¹⁰. Several of PatLang's own documented lessons turn out to be concrete, specific illustrations of a claim usually only stated in the abstract:

• Both are searches over a space of already-available building blocks. PatLang's own developers found that the engine's real ceiling was "the shape of its metarule template, not the difficulty of any one problem" — widening the template by one generic shape opened up a whole family of previously-unreachable solutions. This is a precise mechanical echo of Chi, Feltovich and Glaser's finding that novice and expert physicists differ not in raw intelligence but in which underlying principles are available to them as compositional building blocks in the first place⁹. A learner — human or machine — cannot synthesise a structure built from a primitive it doesn't have.
• Both need deliberately varied examples to force genuine evaluation, not narrow ones that let a shortcut pass unnoticed. PatLang's own worked examples build in distractors on purpose, specifically so the engine cannot settle for a spuriously-correlated shortcut without ever having to judge it against a real alternative — the machine-side version of a much more general principle: a narrow set of easy, undiscriminating examples lets a learner of any kind succeed without ever exercising the evaluative step synthesis actually depends on.
• Both require holding out genuinely blind cases before a result can be trusted. More than once, PatLang's own development history records a result that looked correct on the first test and turned out to be vacuous on closer inspection — a search space with only one legal path at every step, for instance, which cannot be evidence of discovery no matter how many times it "passes." A test that can be satisfied without any real evaluative work happening tells you nothing about what's actually been learned, whichever kind of system is being tested.
• Both can produce a technically valid answer that misses the property a human evaluator actually wanted. When PatLang's engine was asked to find not just a correct rule but a natural-looking one, optimising purely for the smallest program did not reliably produce what a human would consider the intuitive answer — sometimes producing something more convoluted instead. That's a direct, mechanical demonstration of the surface-versus-deep distinction Chi and colleagues found in human learners: a technically correct output is not automatically evidence of the kind of understanding "synthesis" is meant to indicate.

Where the comparison breaks down, and it matters that it does

ItIt would be a real overclaim to conclude from the above that PatLang's engine "learns like a person." A more recent, more cautious extension of the program-induction framework is explicit about why: genuinely human-like learning requires compositionality, causality, and the capacity to learn how to learn across domains, together, not any one of these alone¹¹. PatLang's engine has the first in real, working form. It does not have the other two, and being precise about that limit matters as much as the similarities above:

• It has no causal or explanatory model of the domain it's synthesising for. Its gap-diagnosis output — telling a user exactly which example is unsatisfiable and why — is generated from the shape of the search failure (a missing witness, a structural conflict), not from any understanding of what a grandparent, a discount, or a routing table actually is. A student asked to synthesise an original argument is expected to explain why the pieces belong together in terms of the subject matter; PatLang's engine cannot do this in any domain-meaningful sense, however articulate its diagnostic message reads.
• It cannot restructure its own hypothesis space. Every expansion of what the engine could induce, across its entire documented history, came from a human programmer widening the template or adding a new primitive — the engine itself never proposed that its own search space was the wrong shape for a problem. A hallmark of the strongest human synthesis is precisely the reverse move: evaluating the categories a problem has been framed in and finding them wanting, then inventing new ones. Machine synthesis here is powerful recombination within a space a person declared in advance; human synthesis at its best also gets to redraw the space, because the evaluation it depends on can turn on the frame itself, not just on the choices available inside it.
• It has no stake in being right, and no experience of being wrong. A student who synthesises a flawed argument suffers a real, felt consequence and is positioned to learn from the failure directly. PatLang's own engine has no comparable feedback of its own — which is why its developers built the discipline of checking every one of its outputs against held-out cases externally, rather than trusting the engine's own confidence. The evaluation has to come from outside the system, every time, because nothing inside it is capable of noticing on its own that something's wrong.

What this means for educators

IfIf machine synthesis is genuinely strong at combinatorial recombination within a known space, and genuinely weak at re-evaluating that space, explaining causal "why," and transferring the evaluative skill itself to a new domain unaided, curriculum and assessment design has a fairly direct implication. A task that asks a student to "combine these known techniques to solve this labelled problem" tests application, not synthesis, however sophisticated the techniques involved — and it's exactly the layer of skill increasingly automatable. A task that additionally requires the student to justify why a particular combination is the right one, to notice when none of the available tools actually fit and say so, or to question whether the problem as given is even framed correctly, is testing the evaluate-then-create sequence properly. Those three things are hard to fake, hard to grade with a checklist, and — on the evidence above — hard to automate.

What this means for students

PractisePractise deliberately on problems where the right combination of tools isn't handed to you in advance, not just ones where you execute a named technique. When you do combine ideas, write down why you chose that combination over a plausible alternative — the justification is the evaluative work synthesis actually depends on, not the combination itself. And periodically ask, of your own solutions, whether the problem was even framed the way you assumed: that habit of stepping back and re-evaluating your own frame, not any specific technique, is the part of synthesis this page has argued is hardest for a machine to do for you.

Where this connects

• Inductive Synthesis: from BDD scenarios to PatLang code — the full technical account of the engine discussed above, with every worked example and its own documented limits in full.
• BDD to Working Code: Three Synthesis Demos, Given/Then Through to Result — the same mechanism shown live, running in the browser against real example tables.
• AI in Business, Education & Society — the fuller argument about which kinds of work are and aren't exposed to automation.
• Memorising vs Learning and Interleaving Against the Timetable — related material on this site covering the cognitive-science and curriculum-design foundations this page builds on, from a different angle.

References