Sitemap
Bootcamp

From idea to product, one lesson at a time. To submit your story: https://tinyurl.com/bootspub1

The Critical Design Engineering Manifesto

4 min readJul 24, 2026

--

Press enter or click to view image in full size

A remix of the 2011 Critical Engineering Manifesto for Design Engineers.

o───o───●───o───▶

Explainer

In 2011, Julian Oliver, Gordan Savičić and Danja Vasiliev published the Critical Engineering Manifesto, urging engineers to treat the technologies we depend upon as objects of study, suspicion, and intervention.

Fifteen years later, I’ve remixed their manifesto for the Critical Design Engineer: a person who wishes to critically inhabit the space between software design and engineering [1].

I have created this manifesto as a set of guardrails for myself as I navigate agentic engineering capabilities as a software designer. The structure, numbering, and cadence belong to Oliver, Savičić and Vasiliev. Where possible, I have tried to maintain kernels of their ideas in each statement.

The manifesto’s source text lives in version control, published as a public Github Gist, under the same GNU Free Documentation License as the original. It carries a commit history, an author signature, and an open invitation to fork.

Manifesto

0. The Critical Design Engineer considers code to be a design material, and works it directly.

1. The Critical Design Engineer considers any tool that generates on their behalf to be both a capability and a threat. The greater the dependence on generated code, the greater the need to read, question and expose its workings.

2. The Critical Design Engineer recognises that proximity to code is not transparency; the source is itself a representation, and closeness must never be mistaken for understanding.

3. The Critical Design Engineer designs seams — not seamlessness — so the user can understand, configure, and contest.

4. The Critical Design Engineer looks beyond the awe of AI generation to the authored context that steers it.

5. The Critical Design Engineer recognises that code records what was decided, not why. So they write the why into the repository.

6. The Critical Design Engineer knows that ‘agent’ describes socio-technical dynamics involving models, parameters, tokens, reinforcement loops, protocols, products, networks, devices and bodies.

7. The Critical Design Engineer inhabits the space between generation and shipping, acting rapidly to hold influence where the codebase is still open to change.

8. The Critical Design Engineer looks to the history of critical design, speculative design, adversarial design and their discontents, and carries their strategies out of the gallery and into the repository, where critique must survive contact with use.

9. The Critical Design Engineer accepts authorship of consequence, not only of intent. To push is to sign your name.

10. The Critical Design Engineer considers the merge to be the most desirable and most dangerous form of exposure.

o───o───●───o───▶

Manifesto source ───▶ critical-design-engineering-manifesto.md

o───o───●───o───▶

Influence register

Thinkers and makers whose work shaped the manifesto’s statements:

Bainbridge, Lisanne: “Ironies of Automation” (1983); the paradox that judgement matters more as making automates. Statement 5.

Bleecker, Julian: “Design Fiction” (2009); objects that tell stories about possible futures. Statement 8.

Get Pip Shea’s stories in your inbox

Join Medium for free to get updates from this writer.

Boer, Laurens & Donovan, Jared: “Provotypes” (2012); provocation over evaluation. Statement 8.

Chalmers, Matthew (and Ian MacColl): seamful design (2003); revealing rather than hiding the seams. Statement 3.

Chun, Wendy Hui Kyong: Programmed Visions (2011); “sourcery,” source code mistaken for transparency. Statement 2.

Cross, Nigel: “Designerly Ways of Knowing” (1982); design as a distinct epistemology. Statement 0.

Dean, MC: Designpowers (2026; github.com/Owl-Listener/designpowers); a design workflow built entirely from markdown skills and agent definitions. Authored context as a material that steers agent behaviour. Statement 4.

DiSalvo, Carl: Adversarial Design (2012); agonism, making conflict contestable. Statements 8 and 10.

Dunne, Anthony & Raby, Fiona: Speculative Everything (2013); design that reinforces how things are versus design that poses a question. Statement 8.

Fuller, Matthew: Behind the Blip: Essays on the Culture of Software (2003); “critical software” that runs and critiques at once. Statement 8.

Fuller, Matthew (ed.): Software Studies: A Lexicon (2008); software as an object of cultural and critical analysis. The field the manifesto works within.

Galloway, Alexander R.: The Interface Effect (2012); the interface as threshold and generative friction rather than transparent window. Statement 3.

Krug, Steve: Don’t Make Me Think (2000); the seamless experience orthodoxy the manifesto pushes back against. Statement 3.

Lessig, Lawrence: Code and Other Laws of Cyberspace (1999; rev. as Code: Version 2.0, 2006); code as an instrument of governance. Statement 9.

Löwgren, Jonas & Stolterman, Erik: Thoughtful Interaction Design (2004); the digital as design material. Statement 0.

Mackenzie, Adrian: Wirelessness (2010); technology as a distributed field of relations rather than a discrete device. Statement 6.

Narayanan, Arvind & Kapoor, Sayash: “AI as Normal Technology” (2025) and “Why AI hasn’t replaced software engineers, and won’t” (2026); the decide-execute-deliver sandwich, value migrating upward. Statements 4, 5, 10.

Nygard, Michael: the Architecture Decision Record (2011); the why as its own artifact. Statement 5.

Oliver, Julian; Savičić, Gordan; Vasiliev, Danja: “The Critical Engineering Manifesto” (2011). The source text; structure, numbering, cadence, and its FOSS culture commitments.

Pope, Richard: “Designing the seams, not seamless design” (2025); transparency at the point of use. Statement 3.

Prado, Luiza & Oliveira, Pedro: “Cheat Sheet for a Non- (or Less-) Colonialist Speculative Design” (2014); whose futures speculative design imagines, and whose it does not. Statement 8.

Rittel, Horst: design rationale and the IBIS method (1970); the why as capturable, not merely implicit. Statement 5.

Schön, Donald: The Reflective Practitioner (1983); the back-talk of materials. Statement 0.

Star, Susan Leigh (with Karen Ruhleder): infrastructure and “when is infrastructure” (1996, 1999). Statements 7 and 9.

Suchman, Lucy: Plans and Situated Actions (1987), Human-Machine Reconfigurations (2007); plans as resources for action, not determinants of it; the human-machine boundary as continually reconfigured. Statements 4 and 6.

Ullman, Ellen: Close to the Machine (1997); code as intimacy and seduction. Statement 0.

Weiser, Mark (and John Seely Brown): “The Coming Age of Calm Technology” (1996); “beautiful seams.” Statement 3.

Winner, Langdon: “Do Artifacts Have Politics?” (1980); design choices legislate. Statement 9.

o───o───●───o───▶

[1] For more on the Design Engineer, read Anna Lafour.

--

--

Pip Shea
Pip Shea

Principal Designer at CSIRO, Australia's national science agency.

Bootcamp
Bootcamp

From idea to product, one lesson at a time. To submit your story: https://tinyurl.com/bootspub1