In an advisory conversation, a colleague made an observation that reframed how I think about my own work: a discipline needs a pedagogy, not just a methodology.
The distinction is easy to state and easy to underestimate. A methodology tells practitioners what to do: the methods, the procedures, the checklists, the gates. A pedagogy answers a different question: how people learn to think inside the discipline. How judgment forms. How principles stop being instructions a practitioner follows and become instincts a practitioner has.
I have been building synthesis engineering as a methodology, in public, in installable form. The observation landed hard because it named the half I had been assuming would take care of itself.
Software engineering has both
Software engineering is the discipline I know best, and it has both layers so thoroughly that the second one has become invisible. The methodology layer fills the books and the process wikis: agile rituals, test-driven development, review gates, incident runbooks. The pedagogy layer is everything the field uses to grow engineers who can think. University curricula sequence ideas so that recursion comes years before compilers. Code review works as apprenticeship: a senior engineer’s comments on a pull request are not quality control alone; they are how taste moves from one head to another. Postmortems convert one team’s failure into an institution’s shared instinct. Pair programming, reading unfamiliar code, earning your way into a codebase through small fixes first: none of that is methodology. It is teaching, woven so deeply into ordinary practice that we rarely call it teaching.
Nobody confuses reading a book about test-driven development with being shaped by years of code review under a demanding senior engineer. The book installs the method. The reviews build the engineer.
Synthesis engineering has one of the two
Synthesis engineering is my name for the discipline of doing serious knowledge work, software above all, through structured human-AI collaboration. On the methodology half I can make a strong claim: it exists, it is written down, and it is installable. The open-source catalog now holds dozens of skills, structured instruction files that AI agents load and follow, covering code review, verification, project management, and writing quality. There are checklists, pre-merge gates, and protective hooks that block a commit when a safety check fails. One command installs the whole catalog.
That last fact is exactly what should give us pause. What installs in a minute has not taught anyone anything. An agent that loads a skill will follow it, and for the agent that is the whole point. A person who installs one gets my conclusions without the experiences that produced them. The judgment a skill encodes still has to form inside the practitioner, and installing the file does nothing to form it.
Here is the test that exposes the gap: how does someone go from following the checklists to knowing when a checklist is wrong? Every serious practitioner eventually meets the case the rule never anticipated. What carries them through that case is judgment, and judgment is the one thing a methodology cannot ship.
My colleague’s observation, restated in these terms: a methodology can be adopted by people who already think in compatible ways. A pedagogy can produce practitioners who think this way natively. That is the difference between a practice that stays the size of its founders and a discipline that outgrows them.
The Bauhaus met this problem before us
Looking for a precedent, I did not find the strongest one in software. The Bauhaus opened in Weimar in 1919, merging a fine-art academy with a school of arts and crafts to train a figure the divided school system was not producing: the artist and the craftsman in one person. Its answer was the Vorkurs, a compulsory preliminary course of roughly six months in which every student worked through the fundamentals of design before touching any specialization. The Vorkurs is what made the school reproducible. It did not transmit a style. It built a way of seeing that every workshop afterward could assume.
Two details from that history are worth carrying forward. The first is that the Bauhaus never fully settled the tension inside its own teaching. Johannes Itten pushed intuitive learning and artistic freedom; László Moholy-Nagy pushed systematic exploration of materials and techniques. Synthesis engineering lives with the same tension, between creative, intuitive integration and disciplined, enterprise-grade process, and I read the Bauhaus as evidence that a serious pedagogy sustains that tension on purpose.
The second is how slow it was. Architecture, the discipline the whole school pointed toward, was not formally taught there until 1927, eight years in, and the teaching kept evolving through three directors until the school closed in 1933. A methodology can be written in a season. A pedagogy is grown through cohorts of actual learners, and I see no way to compress that.
What a pedagogy for this discipline requires
Translating that history into this discipline, I count four requirements.
A foundation before specialization. Some equivalent of the Vorkurs: a studio-style experience where people practice the underlying moves on real problems before adopting domain workflows. For synthesis engineering the underlying moves include shifting deliberately between modes of thinking (first principles, systems, design), deciding what to verify and how deeply, and telling the difference between agent output you can trust and agent output you must take apart. A lecture cannot build any of that. Supervised practice can.
A theory of the learner. A methodology assumes a competent practitioner. A pedagogy has to ask what a novice looks like, which failure modes are common, and what progressive mastery looks like. My working sketch has three stages. The novice applies every rule everywhere, including where it does not fit. The practitioner knows which rules are load-bearing in the situation at hand. The expert recognizes the case where a rule fails and can explain why breaking it honors the principle underneath. A pedagogy takes responsibility for moving people up that ladder.
Assessment that is not testing. Architecture schools do not give exams on design; they run crits, where students present work and defend their reasoning in front of faculty and peers. The synthesis equivalent is a review in which the practitioner presents the collaboration rather than the artifact alone: what was delegated to the agent, what was verified and how, where the agent’s output was overridden and why. Code review already does part of this informally. The remaining step is to make the reasoning itself the explicit object of the review.
A canon that includes failures. Every taught discipline keeps a body of exemplary work. The half I find more interesting is the negative canon: worked failure cases. Here the methodology handed me a head start I did not plan. Some rules in the skills catalog carry the anonymized production incident that produced them, written down originally for enforcement, and read differently, they are teaching artifacts. A rule with its origin story attached can be understood; a bare rule can only be obeyed. Teams drop rules they never understood as soon as those rules become inconvenient, which is why the origin stories matter. Software’s postmortem tradition rests on the same premise: an organization learns from a failure it has examined honestly.
What you can do without founding a school
None of this requires an institution. Three practices fit inside any team adopting AI-assisted development.
Attach the failure to the rule. When you write or adopt a rule for how your team works with AI, record the incident that motivated it in the same file. You are building your negative canon as a side effect of process work you were doing anyway, and each rule arrives with the context a newcomer needs to understand it.
Review the reasoning, not just the output. In some reviews, ask the author to walk through the collaboration: what they verified, what they took on trust, and why the line fell where it did. This is where taste transfers. Code review has been the profession’s quiet apprenticeship for decades; extend it to cover the human-AI work itself.
Treat a correct exception as a graduation. The first time someone on your team says a checklist does not apply here, and is right, something important has happened: the judgment behind the rule now lives in a person, not only in a file. Do not let the moment pass silently. Discuss it in the open, because that conversation, repeated, is the pedagogy.
I am at the beginning of this work, and the Bauhaus keeps me honest about the timescale. Years of iteration, three directors, constant revision, for a school whose faculty included Itten, Albers, and Moholy-Nagy. I expect no less iteration here. But the destination is clear enough to state. The methodology is written down, and anyone can install it in a minute. The discipline will be real when it can be taught: when a practitioner who never met its founders can look at one of our checklists and tell us, correctly, that it is wrong.